A multi-agent constrained selection method and apparatus

Abstract

The application discloses a multi-agent constrained selection method and device applied to an auxiliary generation scene of a physical examination report. A fixed capability permission graph is formed by reading a capability contract of an intelligent analysis unit; a structured department discovery is obtained and mapped to a risk hyperedge template, and a task requirement set is generated when a hard constraint and an activation condition are met; an effective coverage matrix is formed based on the task requirement set and the fixed capability permission graph, intelligent analysis unit sets are selected according to five-dimensional costs under coverage, main responsibility and resource constraints, and task evidence capsules are generated; a temporary execution coverage graph is created, intelligent analysis unit nodes of the temporary execution coverage graph refer to nodes of the fixed capability permission graph, and runtime edges are independently stored. The scheme converts evidence combination into task requirements, uniformly constrains capability, permission, credibility and cost, and isolates control information and runtime relationship.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence, distributed intelligent analysis, and graph data processing, and in particular to a method and apparatus for constrained selection of multiple agents. Background Technology

[0002] Physical examination information processing typically involves data objects from different projects and specialties. When multiple intelligent analysis units collaborate, each unit can be implemented using rule-based procedures, dedicated machine learning models, language models, retrieval modules, or a combination thereof. To enable multiple intelligent analysis units to complete auxiliary analysis around the same batch of physical examinations, the system needs to determine the capabilities required for the current task and, under the conditions of satisfying data access boundaries and computing resource limitations, determine the actual participating units.

[0003] Existing multi-agent orchestration typically employs fixed call lists, pre-defined role chains, or routing methods based on single capability tags. Fixed call lists may still invoke processing units unrelated to the current task when the evidence state changes; while single capability tag routing can reduce the scope of invocation, capability tags usually cannot simultaneously express input / output patterns, field access ranges, trust versions, and resource policies, making it difficult to combine task requirements with machine-verifiable access boundaries for runtime selection.

[0004] In existing technologies, candidate intelligent analysis units are first filtered according to department or role tags, and then the actual execution unit is selected based on priority or individual cost. This type of solution still mainly expresses task requirements through ordinary lists or fixed job relationships, making it difficult to express the combined relationships of multiple structured departments discovering and triggering a cross-professional task requirement; at the same time, if the collaborative edges are directly written to the global topology at runtime, the temporary relationships generated by a single task will also be stored mixed with stable capability and permission relationships.

[0005] Therefore, existing technologies suffer from at least two interconnected technical problems: First, current evidence combinations are difficult to convert into machine-computable task requirements that simultaneously include necessary capabilities, primary responsibility capabilities, minimum coverage counts, and output boundaries. The candidate selection process also struggles to simultaneously verify field-level permissions and calibrate credibility, easily leading to irrelevant calls, capability gaps, or unnecessary data exposure. Second, when runtime collaboration relationships and stable control relationships lack isolation, temporary edges may remain in the global structure, making it difficult to independently version, disable, and audit runtime relationships between concurrent tasks. A technical solution is needed that generates task requirements from dynamic evidence states, optimizes costs under multiple hard constraints, and isolates the construction of runtime execution relationships. Summary of the Invention

[0006] The technical problem to be solved by this invention is: how to convert the combination relationship that changes with the status of evidence during the processing of physical examination information into machine-computable task requirements, and select intelligent analysis units within the boundaries of capabilities, evidence, field-level permissions, calibration credibility, coverage, primary responsibility and resource boundaries; and how to isolate the runtime relationship formed by a single task from the stable capability and permission control information to support independent version management, deactivation and auditing.

[0007] To address the aforementioned technical problems, this invention provides a multi-agent constrained selection method, applied to a scenario of assisting in the generation of medical examination reports, comprising:

[0008] Read the capability contract of the intelligent analysis unit to form a fixed capability permission graph with the intelligent analysis unit as the node and allowed collaboration relationships and data flow relationships as static edges;

[0009] Obtaining structured departmental findings;

[0010] The structured department discovery is mapped to a risk hyperedge template. When the hard constraints and activation conditions of the risk hyperedge template are met, the risk hyperedge is instantiated to generate a set of task requirements.

[0011] Based on the task requirement set and the fixed capability and permission graph, the candidate intelligent analysis units are verified for capability, evidence, field-level permissions and calibration credibility to form an effective coverage matrix. Under the constraints of coverage, primary responsibility and resources, the intelligent analysis unit set is selected according to the five-dimensional cost and a task evidence capsule is generated.

[0012] A temporary execution overlay graph is created based on the task requirement set, the intelligent analysis unit set, and the task evidence capsule. The intelligent analysis unit nodes in the temporary execution overlay graph reference the nodes in the fixed capability permission graph, and the edges are stored independently during runtime, thus isolating the execution of the intelligent analysis unit set.

[0013] Furthermore, the read capability contract of the intelligent analysis unit forms a fixed capability permission graph with the intelligent analysis unit as the node and permitted collaboration relationships and data flow relationships as static edges, including:

[0014] Read the currently valid versioned capability contract from the capability contract registry. The versioned capability contract at least registers the intelligent analysis unit identifier and version, role, capability code, supported task type and supported concept code.

[0015] The versioned capability contract registers the allowed input modes, output modes, negotiation message types, data tags, field ranges, uses, and departmental permissions.

[0016] The versioned capability contract registers rules, model or program versions, trust configurations, resource cost configurations, latency configurations, conflict configurations, and timeout, retry, and abstention policies.

[0017] Configure the validity period, contract hash, and signature for the versioned capability contract, and generate a new contract version when the capability, permissions, or configuration are updated;

[0018] The fixed capability permission graph is generated based on the currently valid versioned capability contract, so that the fixed capability permission graph only stores stable control information and does not store subject data, and runtime tasks are prohibited from writing temporary edges to the fixed capability permission graph.

[0019] Furthermore, the step of mapping the structured department discovery to a risk hyperedge template, and instantiating the risk hyperedge when the hard constraints and activation conditions of the risk hyperedge template are met, generates a task requirement set, including:

[0020] The risk over-edge template includes a necessary discovery set, an optional discovery set, a limited or negative evidence set, directional constraints, a time window, evidence quality constraints, a minimum number of supports, a necessary capability set, primary responsibility capabilities, negotiation role requirements, output object patterns, scoring parameters, activation thresholds, template versions, and applicable scope.

[0021] The effective matching status of the structured department findings with the discovery conditions in the risk super-edge template is determined based on concept mapping, anomaly direction, time window, evidence quality, content version, and calibration confidence.

[0022] Hard constraint verification is performed on the necessary discovery set, the directional constraint, the time window, the evidence quality constraint, and the minimum number of supports;

[0023] Based on the effective matching state, evidence quality, calibration confidence, conditional weight, combined gain, and constraint penalty, the activation score of the risk hyperedge template is calculated.

[0024] When the hard constraint verification is passed and the activation score reaches the activation threshold, the risk superedge is instantiated. The risk superedge instance outputs the target evidence set, the necessary capability set, the primary responsibility capability, the minimum coverage count, the negotiation role requirements, the information level upper limit, and the output object pattern to form the task requirement set.

[0025] Further, the calculation of the activation score of the risk superedge template based on the effective matching state, evidence quality, calibration confidence, conditional weights, combined gain, and constraint penalty includes:

[0026] For each discovery condition in the risk superedge template, obtain the corresponding effective matching state, evidence quality, calibration confidence level, and condition weight;

[0027] The product of the effective matching state, the evidence quality, the calibration confidence, and the condition weight is used as the weighted support quantity for the corresponding discovery condition;

[0028] The combined support quantity is calculated based on the combination of preset discovery conditions that are met simultaneously and the corresponding combined gain.

[0029] The restriction deduction amount is calculated based on the missing or unmet quality requirements and the corresponding restriction penalties.

[0030] The sum of the weighted support and the combined support, minus the restriction deduction, is normalized according to the total amount of the conditional weights and the combined gain, and the normalization result is restricted to the range of zero to one to obtain the activation score.

[0031] The predetermined full value is used as the calibration confidence level for the deterministic rule output, and the calibrated confidence level corresponding to the model version is used for the model output. The activation score is used to determine the activation after the hard constraint verification is completed.

[0032] Further, the process of verifying the capabilities, evidence, field-level permissions, and calibration credibility of candidate intelligent analysis units based on the task requirement set and the fixed capability permission graph to form an effective coverage matrix, and selecting a set of intelligent analysis units and generating a task evidence capsule based on five-dimensional cost under coverage, primary responsibility, and resource constraints, includes:

[0033] Based on the necessary and primary capabilities included in the task requirement set, the candidate intelligent analysis units are determined in the fixed capability permission diagram;

[0034] For each task requirement and each candidate intelligent analysis unit, the capability coverage, evidence availability, usage permissions, departmental permissions, field-level permissions, and minimum calibration confidence are verified separately. Only when all verifications pass are the corresponding valid coverage matrix elements set to valid.

[0035] Based on the effective coverage matrix, verify the minimum number of coverages required for each necessary task, the participation status of the responsible intelligent analysis unit, and the resource consumption of candidate combinations, and eliminate candidate combinations that do not meet the coverage, responsibility, or resource constraints;

[0036] For the retained candidate combinations, determine the resource cost, expected latency, output uncertainty, exposure of additional sensitive fields, and expected conflict between intelligent analysis units;

[0037] A multi-objective cost solution is performed on the resource cost, the expected latency, the output uncertainty, the exposure of additional sensitive fields, and the expected conflict degree between the intelligent analysis units. The set of intelligent analysis units is selected, and the task evidence capsule is generated according to the capability contract, corresponding task requirements, and field-level permissions of the selected intelligent analysis units.

[0038] Furthermore, for each task requirement and each candidate intelligent analysis unit, capability coverage, evidence availability, usage permissions, departmental permissions, field-level permissions, and minimum calibration confidence are verified respectively. Only when all verifications pass are the corresponding valid coverage matrix elements set to valid, including:

[0039] Match the capability codes declared in the capability contract of the corresponding candidate intelligent analysis unit with the necessary capabilities required by the corresponding task to determine the basic coverage status;

[0040] Verify the availability and validity of the evidence required for the corresponding task in the current medical evidence snapshot;

[0041] Verify whether the task purpose and department required for the corresponding task fall within the purpose and department permissions registered in the capability contract;

[0042] Compare the access tags of the fields required by the corresponding task requirements with the data tags allowed by the capability contract, and verify that the required fields fall within the field range registered in the capability contract.

[0043] The calibration confidence is determined based on historical comparable outputs and subsequent verification results under the same task type, concept scope and intelligent analysis unit version, and the versioned confidence prior is invoked when historical samples are lacking.

[0044] The effective coverage matrix elements are synthesized from the basic coverage status, the evidence availability status, the content version validity status, the usage permissions, the department permissions, the field-level permissions, and the comparison results of the calibration confidence and the corresponding minimum calibration confidence.

[0045] Further, the process of solving a multi-objective cost equation for the resource cost, the expected latency, the output uncertainty, the exposure of additional sensitive fields, and the expected conflict degree between the intelligent analysis units, selecting the set of intelligent analysis units, and generating the task evidence capsule based on the capability contract, corresponding task requirements, and field-level permissions of the selected intelligent analysis units includes:

[0046] Normalize the resource cost, the expected latency, the output uncertainty, and the exposure of additional sensitive fields, respectively.

[0047] The weighted sum of the normalized resource cost, normalized expected delay, normalized output uncertainty, and normalized exposure of additional sensitive fields of each candidate intelligent analysis unit in the candidate combination is combined with the expected conflict degree weighting term of each pair of candidate intelligent analysis units to form the total cost of multiple objectives.

[0048] The candidate combinations that minimize the total cost of the multi-objectives or whose difference from the minimum value does not exceed a preset approximate threshold under the constraints of coverage, primary responsibility, and resources are used as the set of intelligent analysis units.

[0049] If no feasible candidate combination exists that satisfies the coverage, primary responsibility, and resource constraints, as well as the field-level permissions and the minimum calibration confidence level, an infeasible selection object is generated, the reasons for the lack of coverage and the constraint conflict are recorded, and the corresponding task is transferred to evidence supplementation or manual review without relaxing the access permissions or the minimum calibration confidence level.

[0050] Furthermore, the weighted sum of the normalized resource cost, normalized expected latency, normalized output uncertainty, and normalized exposure of additional sensitive fields for each candidate intelligent analysis unit within the candidate combination, combined with the expected conflict degree weighting term for each pair of candidate intelligent analysis units, to form a multi-objective total cost, includes:

[0051] The normalized resource cost is determined based on the version conversion factors of processor consumption, graphics processor consumption, and model call consumption, as well as the resource budget.

[0052] The normalized estimated latency is determined based on the predicted execution latency and task time limit of the corresponding candidate intelligent analysis unit version;

[0053] The normalized output uncertainty is determined based on the importance of each task requirement, the effective coverage status of the corresponding candidate intelligent analysis unit, and the calibration confidence.

[0054] The normalized additional sensitive field exposure amount is determined based on the fields sent across the original security domain and the corresponding sensitive weights of those fields.

[0055] The expected conflict degree is determined based on the historical substantive divergence number and comparable output number of each pair of candidate intelligent analysis units under the same task type, concept scope and intelligent analysis unit version, and a versioned conflict degree default value is adopted when historical data is lacking.

[0056] The normalized resource cost, the normalized expected delay, the normalized output uncertainty, the normalized additional sensitive field exposure, and the expected conflict degree are weighted using non-negative cost weights.

[0057] When the total cost of the multi-objectives of multiple candidate combinations is the same, a unique set of intelligent analysis units is determined in sequence according to the number of intelligent analysis units, the expected total latency, the number of additional sensitive fields, and the lexicographical order of the intelligent analysis unit identifiers.

[0058] Further, the step of creating a temporary execution overlay graph based on the task requirement set, the intelligent analysis unit set, and the task evidence capsule, such that the intelligent analysis unit nodes in the temporary execution overlay graph reference the nodes in the fixed capability permission graph and that runtime edges are stored independently, and the intelligent analysis unit set is executed in isolation, includes:

[0059] The effective scope of the temporary execution overlay map is limited by the current examinee, examination batch, consultation task, medical evidence image snapshot, and input content version.

[0060] In the temporary execution coverage graph, task nodes, evidence or capability requirement nodes, selected intelligent analysis unit nodes, task evidence capsule nodes, and message nodes are established.

[0061] The runtime edges are established based on the relationships of demand, coverage, authorization, allocation, delivery, response, and dependency.

[0062] The selected intelligent analysis unit node is made to only store the node identifier reference of the corresponding intelligent analysis unit node in the fixed capability permission graph, and the task edge and negotiation edge are stored in an independent runtime edge set.

[0063] The temporary execution coverage graph is saved with the execution graph identifier, graph version, snapshot identifier, risk superedge template version, selected smart analysis unit, uncovered requirements, status, validity period, and graph hash.

[0064] The corresponding runtime edges are deactivated when the task ends, the input version becomes invalid, the temporary execution overlay graph is replaced by a new graph, or a manual termination instruction is received, and the audit records of the temporary execution overlay graph are retained.

[0065] This invention also provides a multi-agent constrained selection device, applied to a scenario of assisting in the generation of medical examination reports, comprising:

[0066] The capability and permission graph construction module is used to read the capability contract of the intelligent analysis unit and form a fixed capability and permission graph with the intelligent analysis unit as the node and the allowed collaboration relationship and data flow relationship as the static edge;

[0067] The department discovery acquisition module is used to acquire structured department discoveries;

[0068] The task requirement generation module is used to map the structured department discovery to the risk hyperedge template, and instantiate the risk hyperedge when the hard constraints and activation conditions of the risk hyperedge template are met, thereby generating a set of task requirements.

[0069] The constrained selection module is used to verify the capabilities, evidence, field-level permissions, and calibration credibility of candidate intelligent analysis units based on the task requirement set and the fixed capability permission graph, forming an effective coverage matrix. Under the constraints of coverage, primary responsibility, and resources, it selects a set of intelligent analysis units based on five-dimensional costs and generates a task evidence capsule.

[0070] The execution coverage graph construction module is used to create a temporary execution coverage graph based on the task requirement set, the intelligent analysis unit set, and the task evidence capsule, so that the intelligent analysis unit nodes of the temporary execution coverage graph reference the nodes of the fixed capability permission graph and the edges are stored independently during runtime, and the intelligent analysis unit set is executed in isolation.

[0071] The beneficial technical effects of this invention are as follows:

[0072] This invention transforms the combined relationships discovered by the current structured departments into machine-computable requirements such as necessary capabilities, primary responsibility capabilities, minimum coverage times, and output object patterns using a risk super-edge template. Furthermore, the effective coverage matrix incorporates capabilities, evidence, field-level permissions, and calibration credibility into the candidate validity judgment. Therefore, the selection process no longer relies solely on fixed roles or single capability labels, reducing calls unrelated to the current task and data delivery exceeding task requirements, while preserving necessary capability coverage. Since the temporary execution coverage graph only references intelligent analysis unit nodes in the fixed capability permission graph and saves task edges and negotiation edges as independent runtime edges, the temporary networking of a single task does not change stable capability permission relationships. By combining graph version, input content version, validity period, and deactivation conditions, concurrent tasks can maintain their own runtime relationships and deactivate them after the task ends, while retaining traceable audit records. Attached Figure Description

[0073] Figure 1 This is a flowchart illustrating a constrained selection method for multiple agents provided in an embodiment of the present invention.

[0074] Figure 2 A flowchart illustrating the process of instantiating risk hyperedges and generating task requirements provided in an embodiment of the present invention;

[0075] Figure 3 A flowchart illustrating the effective coverage matrix and multi-objective cost selection process provided in an embodiment of the present invention;

[0076] Figure 4 A flowchart illustrating the temporary execution coverage graph construction and runtime edge isolation process provided in this embodiment of the invention;

[0077] Figure 5This is a schematic diagram of the module structure of a multi-agent constrained selection device provided in an embodiment of the present invention. Detailed Implementation

[0078] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments. The output in the scenario of assisting in the generation of the physical examination report is a structured intermediate object in the process of processing physical examination information, used for subsequent manual confirmation or other information processing flows; the main line of the method of the present invention ends with the task requirements, the selection result of the intelligent analysis unit, and the temporary execution relationship, without performing physical operations on the target object. The intelligent analysis unit can be composed of deterministic rule programs, dedicated machine learning models, language models, retrieval modules, or combinations of the aforementioned implementations. The specific implementation type is registered by the corresponding capability contract and is constrained by its input, output, and permission boundaries.

[0079] Example 1

[0080] like Figure 1 As shown, the method in this embodiment is applied to the scenario of assisting in the generation of physical examination reports, and includes the following steps.

[0081] S1. Read the capability contract of the intelligent analysis unit to form a fixed capability permission graph with the intelligent analysis unit as the node and the allowed collaboration relationship and data flow relationship as static edges;

[0082] Capability contracts serve as the machine-verifiable entry point for intelligent analysis units to enter the scheduling scope. During registration, each intelligent analysis unit is assigned a stable identifier and version, and its capability code, supported tasks, allowed input / output modes, field range, usage scope, trust configuration, and execution resource configuration are associated with that version. The fixed capability permission graph only expresses relatively stable control information; node attributes can store the contract version and capability summary, and static edges represent allowed collaborative relationships or allowed data flow directions, without carrying specific evidence of a particular subject. In this way, the available capabilities and access boundaries of candidate intelligent analysis units can be uniformly verified before tasks are generated.

[0083] S2. Obtain structured departmental findings;

[0084] The structured departmental findings can be retrieved from the preceding physical examination information processing stage. Each object carries at least a concept code, status or direction, time range, evidence identifier, content version, and calibration confidence level. This step only obtains the already structured intermediate objects, and this invention does not limit the specific implementation of the preceding objectification process.

[0085] Specifically, structured departmental findings can also carry a finding identifier, location, side, structured fact slot, evidence identifier set, source evidence capsule identifier, information level, output uncertainty, input content version vector, and the actual capability contract version used when generating the object. The structured fact slot stores discrete, continuous, or enumerated values ​​that can be directly compared to subsequent risk hyperedge templates. The evidence identifier set maintains the traceability between the finding and the source evidence. The input content version vector determines whether the finding read during risk hyperedge instantiation still corresponds to the current content version. When obtaining structured departmental findings, the object pattern version, required fields, enumeration range, and content version can be validated. Objects that fail validation are retained in the anomaly handling area and do not participate in the current template matching.

[0086] In one optional implementation, structured departmental findings are serialized using a format of "object header + fact slot + evidence reference + version information". The object header stores the discovery identifier and concept code, the fact slot stores the status, direction, and normalization value, the evidence reference stores the evidence identifier that allows backtracking, and the version information stores the object schema version, the input content version vector, and the capability contract version. This organization allows the risk superedge template to read only the declared fields, eliminating the need to copy the complete original record to the template matching process, thus providing a consistent data boundary for subsequent least privilege selection and task evidence capsule projection.

[0087] S3. Map the structured department discovery to the risk hyperedge template, and instantiate the risk hyperedge when the hard constraints and activation conditions of the risk hyperedge template are met, and generate a task requirement set;

[0088] Risk hyperedge templates are used to convert the combined relationships between multiple structured departmental findings into task-side constraints. Unlike routing that maps only a single anomaly to a single processing unit, a risk hyperedge template can simultaneously connect necessary findings, optional findings, and limited evidence, and register the direction, time, quality, and minimum number of supports for the combination. During execution, candidate matches are first established according to concept encoding and content version, and then hard constraints such as direction, time window, evidence quality, and minimum number of supports are verified in sequence; only templates that meet the hard constraints enter the activation scoring stage. The specific calculation of the activation score can adopt Equation (1) of Example 4. After the score reaches the activation threshold of the corresponding template version, a risk hyperedge instance is generated.

[0089] Risk super-edge instances are not text labels for risk names, but rather data structures geared towards the subsequent selection process. Their output fields include the target evidence set, necessary capability set, primary responsibility capability, minimum coverage count, negotiation role requirements, information level cap, and output object pattern. Because task requirements are directly generated from the structured departmental discovery combination under the current content version, when the content version of any participating discovery changes, template matching can be re-executed to generate a new risk super-edge instance. Therefore, the needs of participating units can change with the evidence status, rather than remaining fixed in the job list.

[0090] S4. Based on the task requirement set and the fixed capability and permission graph, the candidate intelligent analysis units are verified for capability, evidence, field-level permissions and calibration credibility to form an effective coverage matrix. Under the constraints of coverage, primary responsibility and resources, the intelligent analysis unit set is selected according to the five-dimensional cost and a task evidence capsule is generated.

[0091] The selection process is divided into two levels: candidate validity judgment and candidate combination optimization. Candidate validity judgment uses task requirements as rows and candidate intelligent analysis units as columns. Only when capability coverage, available evidence, intended use and departmental scope, required field access permissions, and minimum calibration confidence are all met are the corresponding matrix elements set as valid. The specific calculation of field-level permissions and calibration confidence can be performed using equations (2) and (3) of Example 6. This matrix distinguishes between "having a certain capability" and "allowing and confidently executing that capability under the current task, current field, and current version," avoiding entry into combination optimization based solely on capability labels.

[0092] The combinatorial optimization first eliminates combinations that do not meet the minimum coverage count, primary responsibility participation conditions, or resource budget. Then, it calculates the resource cost, expected latency, output uncertainty, additional sensitive field exposure, and expected conflict degree between intelligent analysis units for the remaining combinations. The total cost of the multi-objectives can be determined according to equation (4) in Example 8. After the selected intelligent analysis units are determined, task evidence capsules are projected from the current medical evidence map snapshot according to the corresponding capability contract, task requirements, and field-level permissions, so that each capsule contains only the nodes and fields required for the unit to complete the assigned task and are allowed to be read.

[0093] S5. Create a temporary execution overlay graph based on the task requirement set, the intelligent analysis unit set, and the task evidence capsule, so that the intelligent analysis unit nodes of the temporary execution overlay graph reference the nodes of the fixed capability permission graph and the edges are stored independently during runtime, and the intelligent analysis unit set is executed in isolation.

[0094] The temporary execution overlay graph is a runtime view of a single task. Selected intelligent analysis unit nodes only retain references to fixed capability and permission graph nodes; task relationships, evidence delivery relationships, and runtime dependencies are written to an independent runtime edge set. This implementation allows capability and permission control information to have different lifecycles than single-task networking information. In other implementations, the independent runtime edge set can be stored in a separate graph namespace, an independent edge table, or a graph partition with task scope, as long as the runtime edges do not reverse-engineer the fixed capability and permission graph.

[0095] Example 2

[0096] This embodiment further illustrates the implementation of fixed capability permission graphs and versioned capability contracts.

[0097] S1. The read capability contract of the intelligent analysis unit forms a fixed capability permission graph with the intelligent analysis unit as the node and permitted collaboration relationships and data flow relationships as static edges, including:

[0098] This step uses the capability contract registry as the entry point for control information. The registry maintains immutable semantics for each contract version; when the configuration changes, a new version is created without overwriting versions that have participated in historical tasks.

[0099] S1.1. Read the currently valid versioned capability contract from the capability contract registry. The versioned capability contract shall at least register the intelligent analysis unit identifier and version, role, capability code, supported task type and supported concept code.

[0100] The intelligent analysis unit identifier is used to locate logical units across versions, while the intelligent analysis unit version is used to locate the actual execution component. Capability coding can use a preset enumeration table, supporting task type and concept coding to narrow down the candidate range. Roles can include machine-recognizable values ​​such as primary responsibility, analysis, verification, disproving, or coordination.

[0101] S1.2. Register the allowed input modes, output modes, negotiation message types, data tags, field ranges, uses, and departmental permissions in the versioned capability contract;

[0102] Input and output modes can be represented using versioned structured description files, and data labels and field ranges are used to perform field projection. Purpose and departmental permissions can be implemented as Boolean predicates, access control policies, or policy tables; in other implementations, attribute-based access control policies can also be used to express the same boundaries.

[0103] S1.3. Register the rules, model or program version, trust configuration, resource cost configuration, latency configuration, conflict configuration, and timeout, retry, and abstention policies in the versioned capability contract.

[0104] Rules, models, or program versions are used to trace execution results back to specific software components. Trustworthiness configurations can point to historical verification configurations statistically analyzed by task type and concept scope; resource cost configurations record conversion information for processor, graphics processor, or model calls; latency and conflict configurations can be periodically updated by offline statistics, forming new contracts or configuration versions when new configurations are released.

[0105] For intelligent analysis units implemented using machine learning models, model versions and credibility configurations can be established through a separate version release process. In one example, structured training samples are obtained from anonymized historical medical examination information, grouped by examinee key, and then... , and The model is divided into training, validation, and test sets to ensure that samples from the same subject do not cross sets. Input fields are constructed according to the structured fields allowed by the corresponding task's evidence capsule, and outputs are encoded according to the output pattern registered in the capability contract. Model training can utilize different batch sizes. Initial learning rate Maximum number of training rounds and with the validation set target continuous The failure to improve the wheel is used as an early termination condition. The above values ​​are all exemplary configurations and do not constitute a limitation on specific model structures.

[0106] After the model completes training, the output probabilities can be calibrated on an independent validation set. Then, the calibrator version, applicable task type, concept scope, sample time range, and calibration error summary are written into the credibility configuration. For deterministic rule-based procedures, the rule version, applicable prerequisites, and necessary field completeness requirements are written into the corresponding configuration. Therefore, the calibration credibility read at the selection stage is not a fixed constant independent of the version, but rather a versioned statistic traceable to the specific intelligent analysis unit version and applicable task scope. The credibility configuration is regenerated when the model is updated, rules are updated, or field definitions change, preventing the direct migration of statistical results from the old version to the new version.

[0107] S1.4. Configure the validity period, contract hash and signature for the versioned capability contract, and generate a new contract version when the capability, permissions or configuration are updated;

[0108] Contract hashes are used to verify the consistency of serialized content, while signatures are used to verify the contract's origin and integrity. At the start of a task, the actual parsed contract version is recorded. If a new version is released during task execution, it does not directly replace the version already bound to the current task; instead, a versioning strategy determines whether to continue the current task or create a new execution graph.

[0109] S1.5. Generate the fixed capability permission graph based on the currently valid versioned capability contract, so that the fixed capability permission graph only stores stable control information and does not store the subject data, and prohibit runtime tasks from writing temporary edges to the fixed capability permission graph.

[0110] The fixed capability permission graph can be implemented using an attribute graph or a graph storage that supports typed edges. Nodes can store the intelligent analysis unit identifier, contract version, and capability index, while static edges store the allowed collaboration types and allowed data flow directions. Runtime services only have permissions to read the fixed graph and write to the runtime graph space, blocking temporary task edges from being written back to the fixed graph from the storage layer.

[0111] It's important to note that "fixed" in the fixed capability permission graph means that stable control information and single-task execution information are separated in terms of lifecycle and write path; it does not mean that the capability configuration is permanently unchanged. When a versioned capability contract expires or a new contract takes effect, a new version of the fixed capability permission graph can be constructed, and subsequent new tasks can read the new version through version pointer switching. Tasks that have already started continue to be bound to the fixed capability permission graph version recorded when the execution graph was created, until the task ends or a re-networking is triggered by a version expiration policy. This avoids the formation of an unreproducible candidate set due to the same task reading two different permission versions sequentially during configuration deployment.

[0112] Example 3

[0113] like Figure 2 As shown in the figure, this embodiment further illustrates the process of generating the risk superedge template into a set of task requirements.

[0114] S3. The step of mapping the structured department discovery to a risk hyperedge template, instantiating the risk hyperedge when the hard constraints and activation conditions of the risk hyperedge template are met, and generating a task requirement set includes:

[0115] The risk over-border template uses a versioned saving method. Each instantiation records both the template version and the input content version, so that the processing results of the same structured department can be distinguished under different template versions.

[0116] S3.1. The risk over-edge template includes the necessary discovery set, the optional discovery set, the limited or negative evidence set, directional constraints, time window, evidence quality constraints, minimum support quantity, necessary capability set, primary responsibility capability, negotiation role requirements, output object mode, scoring parameters, activation threshold, template version and scope of application;

[0117] The necessary discovery set expresses the combination of conditions that must be met, the optional discovery set provides additional support, and the limited or negative evidence set is used to impose restrictions on the activation score. The necessary capability set, primary responsibility capability, and negotiation role requirements belong to the output configuration of the task generation side. The output object pattern is used to constrain the type of structured object that the subsequent intelligent analysis unit should produce, without requiring the risk over-edge itself to form the final assessment conclusion.

[0118] Risk over-boundary templates can be uniquely keyed by template identifier and template version, and a conceptual coding inverted index can be built for each template. When a new structured department is discovered, the set of potentially related templates is first retrieved based on the conceptual coding, and then only the candidate templates are verified for direction, time, and quality, avoiding scanning all templates with each discovery update. The scope of application of the template can also be limited to the type of physical examination item, information level, or preset task type; these limitations are all fixed when the template version is released and recorded with the instance so that the actual applicable template conditions can be restored during subsequent audits.

[0119] When updating the template version, existing risk super-edge instances are not directly modified. If the update only affects subsequent new tasks, the old instance continues to be bound to the original template version. If the update involves security boundaries, field permissions, or hard constraints that render the original instance inapplicable, the old instance can be marked as invalid and re-matched based on the current structured department discovery. The re-matching still starts from the current content version and does not inherit the activation status of the old instance, thereby avoiding the continued use of historical activation results that no longer meet the new hard constraints after the template upgrade.

[0120] S3.2. Determine the effective matching status of the structured department findings with the discovery conditions in the risk super-edge template based on concept mapping, anomaly direction, time window, evidence quality, content version, and calibration confidence.

[0121] During matching, the candidate relationship between structured department findings and template findings is first established using concept encoding. Then, it is checked whether the anomaly direction meets the template direction constraints, whether the discovery time is within the template time window, whether the evidence quality reaches the template lower limit, and whether the content version is still the current valid version. For structured department findings generated by rules, a preset full value can be used as the calibration confidence level; for structured department findings generated by the model, the calibrated confidence level bound to the actual model version is read.

[0122] To ensure auditable matching results, each conditional match can simultaneously save the template condition identifier, the matched structured departmental finding identifier, the content version used during matching, the direction verification result, the time verification result, and the quality verification result. If multiple available findings exist for a single template condition, the finding with the latest content version and meeting the evidence quality requirements can be prioritized. Alternatively, multiple findings can be retained and constrained by the minimum number of supported findings. Matching records only save the structured fields and identifier references required to complete the template judgment; other medical examination fields not involved in the template condition do not need to be copied to the risk hyperedge instance.

[0123] S3.3. Perform hard constraint verification on the necessary discovery set, the directional constraint, the time window, the evidence quality constraint, and the minimum number of supports;

[0124] Hard constraints are applied before scoring is activated. If any necessary discovery is missing, the direction of necessary discovery is incorrect, the allowed time window is exceeded, the quality of evidence is below the set lower limit, or the number of valid supporting evidences is insufficient, the current template will not enter the scoring activation path. This prevents a large number of low-quality optional evidences from offsetting the lack of necessary conditions through weighted accumulation.

[0125] S3.4. Based on the effective matching state, evidence quality, calibration confidence, conditional weight, combined gain, and constraint penalty, calculate the activation score of the risk hyperedge template;

[0126] Effective matching status controls whether a discovery contributes to the support level. Evidence quality and calibration confidence further adjust this contribution, and conditional weights reflect the relative importance of template versions to different discovery conditions. For preset condition pairs that are only meaningful when they co-occur, joint support is increased through combined gains; for missing or quality-inadequate restrictions, restriction deductions are calculated. See Example 4 for specific mathematical expressions and numerical calculations.

[0127] S3.5. When the hard constraint verification is passed and the activation score reaches the activation threshold, the risk superedge is instantiated, and the risk superedge instance outputs the target evidence set, the necessary capability set, the primary responsibility capability, the minimum coverage count, the negotiation role requirements, the information level upper limit, and the output object pattern to form the task requirement set.

[0128] In one example, a cross-disciplinary review template contains five anonymized discovery conditions. The first and second conditions are derived from structured class checks, while the third through fifth conditions are derived from structured fact checks. The template requires at least one structured condition, at least one structured condition, and at least two valid supporting conditions. If all five conditions meet the content version and quality requirements, the calculated activation score is [value missing]. The activation threshold for the corresponding template version is If the instantiation risk exceeds the boundary, the instance only generates the structural interpretation capability, verification interpretation capability, and comprehensive analysis capability required for the task, and the output is still a structured intermediate object in the process of physical examination information processing.

[0129] In this embodiment, the risk hyperedge essentially serves as a transformation from "combined evidence states to task requirements." While ordinary binary edges typically only express the direct relationship between two objects, the risk hyperedge can calculate multiple necessary discoveries, optional discoveries, and limiting evidence as a single combination condition, outputting multiple necessary capabilities and coverage requirements within the same instance. Because hard constraints are executed before activation scoring, missing necessary discoveries are not offset by a large number of optional discoveries through accumulated scoring; and because instances carry both template and input content versions, task requirements can be mapped to defined evidence and rule states. These two points together ensure that the subsequent selection phase receives not vague risk labels, but structured task requirements that can directly participate in coverage matrix calculations.

[0130] When new structured departmental findings emerge for the same subject during subsequent data synchronization, only the affected templates need to be re-evaluated. If the new findings belong only to the optional set of findings for a certain risk super-edge template, the activation score of that template is recalculated and a new instance version is generated. If the new findings change the necessary finding status, time validity, or quality status, hard constraint verification is re-executed. Templates unaffected by related concept encoding remain unchanged. This incremental update method limits the propagation of evidence changes to the task network while preserving the version association between old and new instances, facilitating the explanation of why different sets of intelligent analysis units were selected at two adjacent time points.

[0131] Through the above processing, the effect of risk over-margining is not dependent on a specific organ, test item, or fixed department combination. As long as the template can express the combination triggering relationship with the conceptual encoding, direction, time, and quality conditions of structured departmental findings, and express the task requirements with necessary capabilities, primary responsibility capabilities, minimum coverage times, and output object patterns, the same instantiation mechanism can be reused. In other implementations, the number of optional findings in the template can be increased or decreased, the combination gain and activation threshold can be adjusted, but the processing order of hard constraint verification first, scoring followed by activation, and the structured task requirements of instance output can still be maintained.

[0132] Example 4

[0133] This embodiment further elaborates on the activation scoring of the risk hyperedge template.

[0134] S3.4. The calculation of the activation score of the risk superedge template based on the effective matching state, evidence quality, calibration confidence, conditional weights, combined gain, and constraint penalty includes:

[0135] The activation score is normalized using a combination of support quantity, combined gain, and limitation deduction, so that different templates can still use a unified dimension of zero to one for threshold comparison even when the number of conditions is different.

[0136] S3.4.1. For each discovery condition in the risk superedge template, obtain the corresponding effective matching state, the evidence quality, the calibration confidence level, and the condition weight;

[0137] Each discovery condition has an independent condition weight in the current template version. The valid match status is 0 or 1, and the evidence quality and calibration confidence are both normalized values ​​in the range of zero to one; the condition weights are non-negative and can be determined by historical task replay or manual configuration before the template version is released.

[0138] S3.4.2. The product of the effective matching state, the evidence quality, the calibration confidence level, and the condition weight is used as the weighted support quantity of the corresponding discovery condition;

[0139] The product form ensures that the discovery condition for any valid matching state of 0 does not generate positive support, while low-quality evidence or low calibration confidence will proportionally reduce the support contribution of the corresponding condition.

[0140] S3.4.3. Calculate the combined support quantity based on the combination of preset discovery conditions that are satisfied simultaneously and the corresponding combination gain;

[0141] The combination gain is calculated only for combinations of discovery conditions pre-registered in the template. If a combination requires both conditions to be valid simultaneously, the corresponding combination gain is included in the combination support only when both conditions have a valid match state of 1, thus avoiding adding support for any unregistered co-occurrence relationships.

[0142] S3.4.4. Calculate the restriction deduction amount based on the missing or unmet quality requirements and the corresponding restriction penalties;

[0143] The constraints are independent of the hard constraints that must be discovered: activation stops directly when a hard constraint is not met, while constraints are used to reduce the score when a hard constraint has already been met. The penalty for constraints is a non-negative value and can be set according to the importance of the constraint.

[0144] S3.4.5. Summing the weighted support quantity and the combined support quantity and subtracting the restriction deduction quantity, normalizing the sum according to the total amount of the conditional weight and the combined gain, and limiting the normalization result to the range of zero to one, to obtain the activation score;

[0145] An activation score can be expressed as equation (1):

[0146] Equation (1)

[0147] in, Indicates the current risk over-edge template identifier; This indicates the activation score of the current risk super-edge template; This represents a cutoff function that restricts the input to the range of zero to one. This represents the set of indexes for the discovery conditions of the current risk superedge template; and Indicates the discovery of a conditional index; Indicates the first The condition weights of each discovery condition; Indicates the first The valid matching status of the discovery conditions; Indicates the first The quality of evidence for each discovery condition; Indicates the first The calibration confidence level of each discovery condition; This represents the set of discovery condition index pairs pre-registered for combined gains; Indicates the first The discovery condition and the first The combined gain when all discovery conditions are met simultaneously; Represents the set of restrictive indexes; Indicates the index of the restricted items; Indicates the first Penalties for each restriction item; Indicates the first The status value indicating whether a restriction has been triggered; This represents a positive, stable term that prevents the normalized denominator from being zero. The above symbols maintain the same physical meaning throughout the text.

[0148] In one example, the condition weights of the five discovery conditions are set as follows: , , , and The quality of evidence is set as follows: , , , and The calibration confidence levels are set sequentially to... , , , and All five valid matching states are 1, no combined gain is set and the limiting condition is not triggered, and the stability condition is... Pick Substituting into equation (1) yields The activation threshold can be set at... to The validation set is calibrated according to the template; in this example, it is taken as... This allows highly supported combinations to enter the instantiation process while preserving the space for manual review of boundary combinations.

[0149] S3.4.6. The preset full value is used as the calibration confidence level for the deterministic rule output, the calibrated confidence level corresponding to the model version is used for the model output, and the activation score is used for activation determination after the hard constraint verification is completed.

[0150] The calibration confidence level of the model output can be probabilistically calibrated based on independent validation samples before the model version is released, and the calibrator version and the model version are written together into the capability contract or confidence configuration. Deterministic rules can use 1 as the preset maximum value when their preconditions are fully met; when the required fields of the rule are missing or the content version is invalid, the valid matching status verification is not passed, instead of compensating for the missing input with the maximum value.

[0151] The activation threshold can be versioned using template replay data. Specifically, historical structured departmental discovery combinations that have undergone subsequent manual verification can be selected, and the template activation rate, invalid activation rate, and omission rate under candidate thresholds can be calculated respectively. The threshold with the lowest omission rate is selected from the candidate intervals that meet the preset upper limit for invalid activation, and the sample time range, template version, and threshold are saved together. For new templates with insufficient sample size, a conservative initial threshold of similar templates can be used, and recalibrated after accumulating sufficient replay samples. Threshold updates only create new parameter versions and do not rewrite or change historical risk super-edge instances.

[0152] It is worth noting that in Equation (1), the quality of evidence, calibration confidence, and conditional weights play different roles: the quality of evidence reflects whether the current evidence itself is sufficient; the calibration confidence reflects the reliability of the rules or models discovered by the generated structured departments within the corresponding version range; and the conditional weights reflect the importance of the discovery to the combined trigger in the template definition. Multiplying the three can avoid misinterpreting the impact of low-quality evidence as a decrease in model credibility, and also avoids using large conditional weights to compensate for invalid matching states. The combined gain only applies to pre-registered conditional combinations, and the constraint penalty only reduces the score of templates that have passed hard constraints, thus maintaining a clear separation of the physical meaning of each parameter in the computational chain.

[0153] Example 5

[0154] like Figure 3 As shown in the figure, this embodiment further illustrates the effective coverage matrix and the multi-objective cost selection process.

[0155] S4. The step of verifying the capabilities, evidence, field-level permissions, and calibration credibility of candidate intelligent analysis units based on the task requirement set and the fixed capability permission graph to form an effective coverage matrix, and selecting a set of intelligent analysis units and generating a task evidence capsule based on five-dimensional cost under coverage, primary responsibility, and resource constraints, includes:

[0156] The process first determines whether a single candidate intelligent analysis unit effectively covers the requirements of a single task. Then, it performs hard constraint pruning and total cost comparison on the combination of effective candidates, so that candidates that do not meet the permission or credibility requirements are eliminated before cost optimization.

[0157] S4.1. Based on the necessary capabilities and primary responsibilities included in the task requirement set, determine the candidate intelligent analysis unit in the fixed capability permission diagram;

[0158] First, node indices in the fixed capability permission graph can be retrieved according to the necessary capability codes, and then combined with the primary responsibility capabilities to form a candidate primary responsibility subset. This stage only performs candidate discovery and does not introduce intelligent analysis units lacking necessary capabilities into the candidate set due to low resource costs.

[0159] S4.2. For each task requirement and each candidate intelligent analysis unit, verify the capability coverage, evidence availability, usage permissions, department permissions, field-level permissions, and minimum calibration confidence respectively, and only set the corresponding valid coverage matrix element as valid when all verifications pass.

[0160] An effective coverage matrix can be achieved using Boolean elements, with each matrix row corresponding to a task requirement and the matrix columns arranged in a fixed order according to the intelligent analysis unit identifiers. The calculation of field-level permissions and calibration credibility are shown in equations (2) and (3) of Example 6, respectively. By performing a logical AND operation on multiple verification results, a matrix bound to the current task and the current version can be obtained, instead of reusing a static capability matrix that is detached from the task context.

[0161] Specifically, in addition to storing valid or invalid states, matrix elements can also store the basis for state formation in the bypass audit log, including capability coding matching results, missing evidence identifiers, failure types for purpose or departmental permissions, the first disallowed field, actual calibration confidence level, and corresponding minimum calibration confidence level. The bypass audit log does not change the Boolean semantics of the valid coverage matrix; instead, it is used to locate the cause of candidate failures when infeasible options exist. For the same task requirements and the same intelligent analysis unit, as long as the capability contract version, medical evidence graph snapshot, content version vector, and task purpose remain unchanged, validated matrix elements can be reused; if any dependent version changes, the corresponding element becomes invalid and is recalculated.

[0162] S4.3. Based on the effective coverage matrix, verify the minimum number of coverages required for each necessary task, the participation status of the responsible intelligent analysis unit, and the resource consumption of the candidate combinations, and eliminate candidate combinations that do not meet the coverage, responsibility, or resource constraints.

[0163] When a required minimum coverage count for a certain task is 2, the candidate combination must select at least two valid elements in the matrix row corresponding to that requirement. The primary responsibility capability can be verified by ensuring that the number of selected primary responsibility candidate subsets is not less than 1; resource constraints are verified using unnormalized resource consumption to prevent normalized values ​​from masking actual budget overruns.

[0164] Candidate combination pruning can be performed in advance by leveraging the sparsity of the effective coverage matrix. If the number of effective candidates corresponding to a certain necessary task requirement is less than the minimum coverage count, then it is possible to determine that the current selection problem is infeasible without enumerating candidate combinations. If a candidate intelligent analysis unit only covers the task requirements that have already reached the minimum coverage count, and adding the unit would cause resource overruns, it can be excluded before combination enumeration. For the primary responsibility capabilities that must participate, the primary responsibility candidates can be fixed first, and then the coverage search for other necessary task requirements can be completed from the remaining candidates. This does not change the hard constraints, but also reduces the search space of integer programming or approximate solvers.

[0165] S4.4. For the retained candidate combinations, determine the resource cost, expected latency, output uncertainty, additional sensitive field exposure, and expected conflict between intelligent analysis units;

[0166] Resource costs are predicted by the processor, graphics processor, and model call consumption of the current intelligent analysis unit version; the expected latency can be obtained from the historical quantiles or online predictions of the same version and similar tasks; the output uncertainty is jointly determined by the importance of task requirements, effective coverage, and calibration reliability; the exposure of additional sensitive fields only counts the field delivery added relative to the original security domain; the expected conflict level is obtained by statistically analyzing the historical substantive disagreements under similar tasks, concept scopes, and versions.

[0167] All five cost categories are bound to candidate intelligent analysis unit versions or combinations, and are converted to a uniform range of zero to one before entering the weighted objective. Resource cost reflects the computational resources required for execution; expected latency reflects the current task's time budget utilization; output uncertainty reflects the remaining uncertainty caused by insufficient effective coverage and calibration reliability; additional sensitive field exposure reflects the new data delivery relative to the original security domain after selecting this unit; and expected conflict degree describes the substantial divergence tendency of two simultaneously participating intelligent analysis units in comparable historical outputs. Modeling the five categories separately before weighting avoids using a single abstract cost field to simultaneously carry different technical meanings, and also facilitates adjusting the focus through parameter versions under different task types.

[0168] S4.5. Solve the multi-objective cost for the resource cost, the expected delay, the output uncertainty, the exposure of additional sensitive fields, and the expected conflict degree between the intelligent analysis units, select the set of intelligent analysis units, and generate the task evidence capsule according to the capability contract, corresponding task requirements, and field-level permissions of the selected intelligent analysis units.

[0169] Multi-objective costs can be solved using integer programming or a greedy approximation algorithm with fixed parallel sorting rules. When using an approximation algorithm, the approximation threshold and parallel sorting rules should be saved in the parameter configuration to ensure consistent results can be obtained repeatedly under the same input content version, contract version, and parameter version. After selecting the set, project task evidence capsules cell by cell. Each capsule should at least record the source snapshot, allowed evidence set, field projection, corresponding task requirements, and content version, which are used to verify input boundaries during isolated execution.

[0170] The key to constrained selection is to first define the feasible region before comparing total costs. Field-level permissions, minimum calibration confidence, minimum coverage count, primary responsibility participation, and resource budget jointly define the feasible region. The five cost categories are only ranked within the feasible region; therefore, any adjustment to cost weights cannot bring back candidates with inadequate permissions or insufficient confidence into the selection results. This calculation order makes "whether it can be selected" and "which of the selected options is more suitable" two independently auditable stages. When subsequent audits find that a unit should not participate, the effective coverage matrix and hard constraint records can be examined first, without having to deduce the permission reasons from the weighted total cost.

[0171] In one example, the task requirement set contains three necessary task requirements with minimum coverage counts of 1, 1, and 1, respectively, where the third requirement also requires the primary responsibility capability. A fixed capability permission graph retrieval yields four candidate intelligent analysis units. The first three candidates in the effective coverage matrix each cover one requirement, while the fourth candidate covers both of the first two requirements. If the combination of the first three candidates and the combination of the fourth candidate + the primary responsibility candidate both satisfy the resource budget, then the total cost across five categories is compared. If the fourth candidate requires submitting more sensitive fields and has a high historical conflict level when accessing the first two requirements, even if it covers two requirements with a single unit, it may still have a high total cost. This example illustrates that the present invention does not solely aim to minimize the number of intelligent analysis units, but rather performs unified optimization across multiple executable dimensions while satisfying hard constraints.

[0172] Example 6

[0173] This embodiment further illustrates the effective method for generating coverage elements between individual task requirements and candidate intelligent analysis units.

[0174] S4.2. For each task requirement and each candidate intelligent analysis unit, the capability coverage, evidence availability, usage permissions, departmental permissions, field-level permissions, and minimum calibration confidence are verified respectively. Only when all verifications pass are the corresponding valid coverage matrix elements set to valid, including:

[0175] The effective coverage element is determined by multiple Boolean constraints and a confidence threshold. Any field exceeding its authority or content version being invalid will directly invalidate the corresponding element.

[0176] S4.2.1. Match the capability codes declared in the capability contract of the corresponding candidate intelligent analysis unit with the necessary capabilities required by the corresponding task to determine the basic coverage status;

[0177] The basic coverage status only indicates coverage at the capability coding level and does not represent that data access permission for the current task has been obtained. Therefore, subsequent independent verification of fields and credibility is still required, and the static capability matching results should not be directly used as the final valid coverage results.

[0178] Capability coding matching can employ precise coding matching or pre-registered parent-child capability mapping, but the mapping relationship must belong to the stable control information of the current version of the fixed capability permission graph. If a candidate intelligent analysis unit declares a higher-level capability code, but the task requires the use of a lower-level capability code, the basic coverage is only considered valid if there is an explicit inclusion mapping in the fixed graph version; capability relationships cannot be temporarily inferred at runtime through text similarity. This ensures the determinism of the basic coverage results under the same fixed graph version.

[0179] S4.2.2. Verify the availability and validity of the evidence required for the corresponding task in the current medical evidence snapshot;

[0180] Evidence availability can be verified through the existence of evidence identifiers in the snapshot, status markers, and content version vectors. If an input content version is updated after the task is created, the availability status corresponding to the old version is invalidated, and the relevant matrix elements are recalculated.

[0181] For a task requirement that depends on multiple evidence objects, first check if all evidence identifiers exist, then check if the content version of each piece of evidence is consistent with the version recorded when the task requirement was generated. When using updated versions, the task requirement set should be regenerated from a new medical evidence map snapshot, rather than directly replacing a single evidence version on the original valid coverage matrix. This is to prevent the task requirement from being generated by an old evidence combination, but the actual selection reads a new evidence combination version.

[0182] S4.2.3. Verify whether the task purpose and department required for the corresponding task fall within the purpose permissions and department permissions registered in the capability contract;

[0183] Purpose permissions and department permissions can be represented using either enumerated sets or policy predicates. Field-level comparisons are only performed when both the current task purpose and the source department satisfy the contractual policy, thus forming the first layer of access scope filtering before field judgment.

[0184] S4.2.4. Compare the access tags of the fields required by the corresponding task requirements with the data tags allowed by the capability contract, and verify that the required fields fall within the field range registered in the capability contract;

[0185] A field-level permission result can be represented as equation (2):

[0186] Equation (2)

[0187] in, Indicates task requirements With candidate intelligent analysis unit Field-level permission results between; Indicates the index required by the task; Indicates the index of candidate intelligent analysis units; Indicates task requirements A set of required fields; Indicates a field index; The indicator function is defined as taking the value 1 if the condition is true and 0 otherwise. Representation field Access tags; This indicates a partial order relation that allows access to tags; Indicates candidate intelligent analysis unit The set of allowed data tags; Indicates task requirements The purpose of the task; Indicates candidate intelligent analysis unit The set of permitted uses; Representation field The field range identifier; Indicates candidate intelligent analysis unit The set of allowed field ranges. If any required field does not meet the access tag or field range, or if the task purpose is not within the allowed scope, That is, 0.

[0188] Field-level permission comparison can be completed before field projection. The task requirement first provides the minimum set of fields needed to complete the requirement, and the capability contract provides the range of tags and fields that the intelligent analysis unit is allowed to access. The corresponding field projection is only created when the result of equation (2) is 1. If the task requirement includes 10 candidate fields but only 4 of them are actually needed to form the current task evidence capsule, then permission judgment and capsule projection are both based on the required 4 fields as boundaries, and the input range is not automatically expanded because the capability contract allows more fields. This approach separates the maximum range that can be read from the minimum range that is actually needed for this task, reducing unnecessary fields from entering the execution environment.

[0189] S4.2.5. Determine the calibration confidence level based on historical comparable outputs and subsequent verification results under the same task type, concept scope and intelligent analysis unit version, and call the versioned confidence prior when historical samples are lacking;

[0190] A smoothed calibration confidence level can be expressed as Equation (3):

[0191] Equation (3)

[0192] in, Indicates task requirements With candidate intelligent analysis unit Corresponding calibration reliability; This indicates the number of historical outputs that have passed subsequent validation under the same task type, concept scope, and intelligent analysis unit version. This indicates the total number of comparable historical outputs within the same range. and represents the first and second smoothing parameters, respectively, representing the versioning confidence prior; both are positive numbers. In one example, , , , ,get .when At that time, it can be directly adopted by and A predetermined prior mean is used, and after accumulating a preset number of comparable outputs, the results are switched to historical statistics.

[0193] Historical statistics are binned according to task type, concept scope, and intelligent analysis unit version to avoid directly mixing outputs from different versions or tasks of different difficulties. When the total number of comparable outputs is small, and This has a significant impact on the results, causing the calibration confidence to shrink towards the versioned prior; with As the number of historical verification results increases, they gradually become the primary factor. In one implementation, the minimum number of valid samples for the credibility configuration can be set to... to Between these values, when the number is below this threshold, the prior dominant state is recorded simultaneously. After reaching the minimum effective sample size, the state transitions to the historical statistical dominant state. This state can be written into the bypass audit log, but it does not change the meaning of the calculation in equation (3).

[0194] S4.2.6. Combine the basic coverage status, the evidence availability status, the content version validity status, the usage permission, the department permission, the field-level permission, and the comparison result of the calibration confidence and the corresponding minimum calibration confidence to form the effective coverage matrix element.

[0195] The synthesis process uses a logical AND relation: only the basic coverage status is valid, evidence is available, content version is valid, and the purpose and departmental permissions are approved. and Meet the task requirements The minimum calibration confidence level is set to 1 only when the corresponding effective coverage matrix element is at its lowest setting. The minimum calibration confidence level can be set according to the task type. to For new versions lacking historical samples, the minimum number of comparable samples can be increased or a more conservative versioned credibility prior can be adopted, rather than bypassing credibility verification.

[0196] Once the effective coverage matrix is ​​completed, a matrix version summary can be generated. This summary must at least associate the task requirement set version, the fixed capability permission graph version, the medical evidence graph snapshot identifier, and the credibility configuration version. Subsequent combinatorial optimizers only accept matrices that are completely consistent with the current task context version; if any upstream version changes, the old matrix is ​​discontinued and the corresponding verification is re-executed. This version gating prevents cached matrices from continuing to participate in combinatorial solutions after permission updates, evidence updates, or intelligent analysis unit upgrades.

[0197] Example 7

[0198] This embodiment further illustrates the multi-objective cost solution, feasible combination selection, and infeasible combination handling.

[0199] S4.5. The multi-objective cost solution for the resource cost, the expected latency, the output uncertainty, the exposure of additional sensitive fields, and the expected conflict degree between intelligent analysis units, the selection of the intelligent analysis unit set, and the generation of the task evidence capsule based on the capability contract, corresponding task requirements, and field-level permissions of the selected intelligent analysis units, includes:

[0200] Cost calculation is performed only on candidate combinations that have already passed effective coverage and hard constraint pruning, so lower total costs cannot cover field permissions or minimum calibration confidence failures.

[0201] S4.5.1. Normalize the resource cost, the expected delay, the output uncertainty, and the exposure of the additional sensitive fields, respectively;

[0202] Resource costs are normalized based on the task resource budget, and expected latency is normalized based on the task time limit. Output uncertainty and exposure of additional sensitive fields are limited to the range of zero to one, respectively, by preset maximum values ​​or normalization weights. The original resource consumption is retained before normalization for resource hard constraint verification as described in Example 5.

[0203] Normalization configuration and task type form parameter versions. Resource budget and task time limit serve as the external boundaries of the current task. During normalization, they are only used for scaling transformation and do not change the original resource hard constraints. Output uncertainty and exposure of additional sensitive fields are scaled using the preset maximum amount or total weight. If a certain original cost exceeds the normalization benchmark, the corresponding normalized value can be truncated to 1, while the original value is still retained for hard constraint judgment and auditing. This ensures that the dimensions of each component of equation (4) are consistent and also prevents normalization truncation from masking the actual resource overrun.

[0204] S4.5.2. Combine the weighted sum of the normalized resource cost, normalized expected delay, normalized output uncertainty and normalized exposure of additional sensitive fields of each candidate intelligent analysis unit in the candidate combination with the expected conflict degree weighting terms of each pair of candidate intelligent analysis units to form the multi-objective total cost.

[0205] The total cost of multi-objective analysis includes both the cost of the unit itself and the combination of conflict terms between pairs of units. The cost of the unit itself can be directly accumulated, and the conflict term is only included when two intelligent analysis units are selected at the same time. The specific mathematical expression is shown in Equation (4) of Example 8.

[0206] S4.5.3. Under the constraints of coverage, primary responsibility, and resources, find candidate combinations that minimize the total cost of the multi-objectives or whose difference from the minimum value does not exceed a preset approximate threshold, and use these combinations as the set of intelligent analysis units;

[0207] When the number of candidates is small, integer programming or exhaustive pruning can be used to obtain the minimum value; when the number of candidates is large, a greedy approximation algorithm with a fixed order can be used to successively select candidates whose unit increase in coverage benefit is better than the total increase cost, and the primary responsibility and resource constraints are re-checked after each candidate is added. The preset approximation threshold can be set to the minimum total cost. to In tasks requiring deterministic optimality, take .

[0208] When using integer programming, the participation status of each candidate intelligent analysis unit can be represented as a binary selection variable, and the minimum coverage count required for each necessary task, the participation status of the responsible intelligent analysis unit, and the resource budget can be directly treated as hard constraints by the solver. After reaching the optimal stopping condition, the solver reads the feasible solution with the smallest objective value. If the time limit is reached but a feasible solution has been obtained, output is only allowed if the difference between this solution and the current known lower bound meets a preset approximation threshold; otherwise, it is treated as infeasible or pending verification. When using a greedy approximation algorithm, the candidate traversal order is fixed to the lexicographical order of the intelligent analysis unit identifiers. After each round of selection, the remaining uncovered requirements and new costs are recalculated until all hard constraints are satisfied or no more candidates can be added. Fixed traversal and parallel rules ensure the reproducibility of the approximation algorithm under the same input version.

[0209] S4.5.4. When there is no feasible candidate combination that satisfies the coverage, primary responsibility and resource constraints, as well as the field-level permissions and the minimum calibration confidence, generate an infeasible selection object, record the reasons for the lack of coverage requirements and constraint conflicts, and transfer the corresponding task to evidence supplementation or manual review without relaxing the access permissions or the minimum calibration confidence.

[0210] The list of infeasible options can record the current task identifier, input content version, uncovered task requirements, constraint type that caused the candidate to fail, and candidate statistical summary. If the infeasibility is due to missing required evidence, the subsequent process can request supplementary evidence and regenerate the task; if it is due to permission issues or the minimum calibration confidence level, the hard constraint remains unchanged and the process is transferred to manual review, thus preventing the optimizer from forcibly obtaining a feasible solution by expanding the field range or lowering the confidence threshold.

[0211] The infeasible selection criteria can also store versions of the fixed capability permission graph, task requirement set, effective coverage matrix, resource budget, and a set of candidate failure reasons for each uncovered requirement. Failure reasons are represented by a pre-defined enumeration, including capability coverage, unavailable evidence, invalid usage permissions, invalid departmental permissions, invalid field-level permissions, insufficient calibration credibility, missing primary responsibility capability, and insufficient resource budget. When multiple reasons exist simultaneously, all are retained, not just the first failure reason. This allows for differentiation between different infeasibility scenarios such as "the current system does not have the corresponding capability" and "the capability exists but the current task does not have the authority to invoke it."

[0212] Infeasibility handling is part of the constrained selection mechanism, not a fallback for solver anomalies. Its technical significance lies in solidifying the non-relaxability of hard constraints into deterministic data branches: when the feasible domain is empty, the system outputs structured infeasible options that can be consumed by subsequent processes, rather than automatically reducing a permission condition or minimum calibration confidence level and solving again. If new structured departmental findings are subsequently added, a new capability contract version is released, or the resource budget is legally adjusted, the effective coverage matrix and candidate combinations are regenerated in the new version context, and the original infeasible options continue to be retained as audit records of the old version.

[0213] Example 8

[0214] This embodiment further provides the methods for determining the components of the total cost of multiple objectives and the deterministic parallel selection method.

[0215] S4.5.2. The weighted sum of the normalized resource cost, normalized expected latency, normalized output uncertainty, and normalized exposure of additional sensitive fields of each candidate intelligent analysis unit within the candidate combination, combined with the expected conflict degree weighting term of each pair of candidate intelligent analysis units, to form the multi-objective total cost, includes:

[0216] The values ​​of different units are normalized separately before being weighted to avoid the direct addition of processor consumption, millisecond-level latency and sensitive field weights, which would lead to the dominance of units.

[0217] S4.5.2.1. Determine the normalized resource cost based on the version conversion factors of processor consumption, graphics processor consumption, and model call consumption, as well as the resource budget;

[0218] Versioning conversion factors can be converted to a uniform resource unit based on unit processor time, graphics processor time, and model call volume. For intelligent analysis units that do not use the graphics processor or do not perform model calls, the corresponding consumption is set to zero, and resource costs are not increased by virtual placeholders.

[0219] Version conversion factors can be determined through periodic benchmarking. A fixed-size set of de-identified task samples is repeatedly executed on the same version of the intelligent analysis unit, recording processor time, GPU time, model call input / output, and peak memory usage. The median or high-quantile statistics of multiple run batches are then written into the resource cost configuration. A new resource cost configuration version is generated when the hardware environment or model service metering method changes, avoiding the direct application of resource conversion factors measured in the old environment to the new environment.

[0220] S4.5.2.2. Determine the normalized estimated latency based on the predicted execution latency and task time limit of the corresponding candidate intelligent analysis unit version;

[0221] Execution latency prediction can be achieved using historical execution latency quantiles for the same intelligent analysis unit version and task type, or it can be provided by an online latency predictor. To reduce the optimistic bias caused by occasional short latency, statistical values ​​between the 75th and 95th percentiles of historical latency can be used as versioned predicted latency.

[0222] In one example, the median execution latency of the most recent 100 comparable tasks for the same Smart Analytics Unit version was [value missing]. The 90th percentile is The current task time limit is The 90th percentile can be used as the input normalization process for the expected latency. For new versions with insufficient historical samples, a versioned default latency can be used, or a short benchmark task can be performed in an isolated environment to obtain the initial configuration, and the latency configuration can be updated after actual task samples have been accumulated.

[0223] S4.5.2.3. Determine the normalized output uncertainty based on the importance of each task requirement, the effective coverage status of the corresponding candidate intelligent analysis unit, and the calibration confidence.

[0224] The importance of task requirements is used to increase the uncertainty contribution when critical requirements are not covered by high-confidence elements. Under the same coverage conditions, the closer the calibration confidence is to 1, the smaller the corresponding uncertainty contribution. When multiple valid elements cover the same requirement, the marginal contribution of repeated coverage can be adjusted based on whether there is an independent source of evidence.

[0225] The calculation of output uncertainty uses task requirements as the basic unit, avoiding the direct use of the model's own uncalibrated confidence output. For a task requirement covered by multiple candidates, the residual uncertainty of the requirement can be formed by combining the candidate calibration confidence, task requirement importance, and number of independent coverages. This uncertainty is then summarized and normalized according to the importance of all necessary task requirements. The resulting output uncertainty uses the same calibration confidence fact source as the effective coverage matrix, preventing a candidate from being considered reliable during the coverage verification phase but then using a different set of unversion-bound confidence metrics during the cost calculation phase.

[0226] S4.5.2.4. Determine the normalized additional sensitive field exposure amount based on the fields sent across the original security domain and the sensitivity weights of the corresponding fields;

[0227] The original security domain can be determined by the data tag, storage domain, or the domain where the field is located when the task is started. Only fields newly delivered across domains after a candidate intelligent analysis unit is selected are counted in the additional sensitive field exposure count; fields that are already available within the original security domain and do not need to be sent across domains are not counted again.

[0228] Additional sensitive field exposure can be calculated by first taking the union of the cross-domain fields required for the candidate combination, and then accumulating them according to the field sensitivity weight. This avoids duplicate calculations when two intelligent analysis units both require the same field. The field sensitivity weight is obtained by mapping data labels and is saved with the permission configuration version. If two candidates are deployed in different security domains, even if the required field names are the same, they can be recorded separately according to the actual cross-domain delivery path. This ensures that the cost reflects the true changes in data boundaries rather than simply counting the number of fields.

[0229] S4.5.2.5. Determine the expected conflict degree based on the historical substantive divergence number and comparable output number of each pair of candidate intelligent analysis units under the same task type, concept scope and intelligent analysis unit version, and adopt the versioned conflict degree default value when historical data is lacking;

[0230] Substantial discrepancies refer to historical events that produce inconsistent outputs for preset key fact slots within the same structured object, excluding format differences or equivalent coding differences. When the number of comparable historical outputs is lower than the preset sample size, the smoothing strength can be increased; when historical data is completely lacking, the default conflict level associated with the cell type and version is used.

[0231] Conflict statistics are also bucketed by task type, conceptual scope, and the versions of the two intelligent analysis units. Records are only included in the comparable output count if both intelligent analysis units have handled the same or comparable task requirements and have consistent output object patterns. If either unit upgrades, the old and new versions are counted separately; when historical samples are insufficient, versioned default values ​​are used to avoid mistaking "no discrepancies observed" for "expected conflict level is zero." This process ensures that conflict items reflect actual collaboration history, rather than being modified by immediate differences of opinion in a single task.

[0232] S4.5.2.6. Apply non-negative cost weights to weight the normalized resource cost, the normalized expected delay, the normalized output uncertainty, the normalized additional sensitive field exposure, and the expected conflict degree;

[0233] Let the selection state of the candidate intelligent analysis unit be composed of a vector. The total cost of a multi-objective problem can be expressed as equation (4):

[0234] Equation (4)

[0235] in, This represents the total cost of the multi-objective combination of candidate combinations; This indicates the state vector selected by the candidate intelligent analysis unit; Indicates candidate intelligent analysis unit The selection variable takes the value 1 when selected and 0 when not selected; and Both represent candidate intelligent analysis unit indices, and Used to avoid repeatedly calculating the same pair of intelligent analysis units; Indicates the normalized resource cost weight; Indicates the normalized expected delay weight; This represents the weight of the normalized output uncertainty; This indicates the weight of the normalized exposure of additional sensitive fields; The expected conflict level weights are represented by five non-negative values, and their sum is 1. Indicates candidate intelligent analysis unit Normalized resource costs; Indicates candidate intelligent analysis unit Normalized projected latency; Indicates candidate intelligent analysis unit The normalized output uncertainty; Indicates candidate intelligent analysis unit Normalized exposure of additional sensitive fields; Indicates candidate intelligent analysis unit With candidate intelligent analysis unit The expected degree of conflict between them.

[0236] In one example, it can be set , , , , For a combination of three dedicated intelligent analysis units that respectively cover structural interpretation, verification interpretation, and comprehensive analysis requirements, the following calculations are performed based on example resources, latency, uncertainty, sensitive field exposure, and pairwise conflict degree. For a combination consisting of a general intelligent analysis unit that simultaneously covers the first two requirements and a comprehensive intelligent analysis unit, the calculation yields... If both groups satisfy the hard constraints, the former group is selected. This example illustrates that having more coverage requirements does not necessarily result in a lower total cost; the selection is determined by both coverage feasibility and the five types of costs.

[0237] Cost weights can be generated as immutable parameter versions based on task type. Before releasing a parameter version, historical tasks can be replayed offline to observe the contributions of resource consumption, estimated latency, output uncertainty, exposure of additional sensitive fields, and expected conflict level to the candidate solution ranking. If an adjustment to a certain weight causes a large number of task selection results to change, it can be checked before release whether the change comes from the expected cost focus, rather than an anomaly in the normalization scale. At runtime, only the released parameter versions are read, and weights are not temporarily modified based on the current candidate results, thus avoiding the need to reverse-adjust the objective function to select a particular candidate.

[0238] S4.5.2.7. When the total cost of the multi-objectives of multiple candidate combinations is the same, a unique set of intelligent analysis units is determined in sequence according to the number of intelligent analysis units, the expected total delay, the number of additional sensitive fields, and the lexicographical order of the intelligent analysis unit identifiers.

[0239] The parallel sorting is performed as a deterministic post-processing rule outside the solver: first, the combination with fewer intelligent analysis units is selected; if the number is still the same, the combination with the smaller expected total latency is selected; if still the same, the combination with fewer additional sensitive fields is selected; finally, the combination is compared according to the lexicographical order of the intelligent analysis unit identifiers. By fixing the sorting rules, different computation nodes can avoid outputting different equivalent optimal combinations due to different set traversal orders.

[0240] Example 9

[0241] like Figure 4 As shown, this embodiment further illustrates the temporary execution coverage graph and runtime edge isolation mechanism.

[0242] S5. The step of creating a temporary execution overlay graph based on the task requirement set, the intelligent analysis unit set, and the task evidence capsule, such that the intelligent analysis unit nodes of the temporary execution overlay graph reference the nodes of the fixed capability permission graph and that the runtime edges are stored independently, and the intelligent analysis unit set is executed in isolation, includes:

[0243] The temporary execution overlay graph establishes an independent scope for a single task. The graph references stable intelligent analysis unit nodes but does not copy or modify the static relationships of the fixed capability permission graph.

[0244] The temporary execution overlay graph can be understood as a task execution view overlaid on the stable control plane. The fixed capability and permission graph answers what capabilities a given intelligent analysis unit possesses in the current contract version, what scope it is allowed to access, and which units it is allowed to establish stable collaborative relationships with. The temporary execution overlay graph answers which units are actually selected for a specific task, which task evidence capsules are delivered to which units, and the dependencies of these units in the current version. Both types of graphs use node references to establish connections but store edges through different write paths, separating long-term configuration changes from short-term task orchestration at the data structure level.

[0245] S5.1. The effective scope of the temporary execution overlay map is limited by the current examinee, physical examination batch, consultation task, medical evidence image snapshot, and input content version;

[0246] When creating the graph, the current examinee's desensitization task key, physical examination batch key, cross-departmental review task key, medical evidence graph snapshot identifier, and input content version vector are all written into the execution context. Different context dimensions create different runtime scopes, ensuring that two concurrent tasks do not share temporary task edges even when using the same intelligent analysis unit node.

[0247] In cases where two cross-departmental review tasks are concurrently generated for the same examinee within the same medical examination batch, the two tasks can reference the same intelligent analysis unit node, but each has a different execution graph identifier and an independent set of runtime edges. When querying task edges using the execution service, both the execution graph identifier and the graph version must be included; querying all runtime relationships using only the intelligent analysis unit identifier is not allowed. Therefore, the allocation, delivery, or dependency edges of the first task will not appear in the execution query results of the second task, maintaining runtime scope isolation even if the two tasks overlap in time.

[0248] S5.2. Establish task nodes, evidence or capability requirement nodes, selected intelligent analysis unit nodes, task evidence capsule nodes, and message nodes in the temporary execution coverage diagram;

[0249] Task nodes carry the current task status; evidence or capability requirement nodes correspond to machine-computable requirements in the task requirement set; selected intelligent analysis unit nodes store references to stable nodes; task evidence capsule nodes record the actual delivery objects; and message nodes only store references to structured messages in the current execution scope. Nodes can be implemented using attribute graphs, relational tables with type fields, or labeled nodes in a graph database.

[0250] S5.3. Establish the runtime edges based on the relationships of requirement, coverage, authorization, allocation, delivery, response, and dependency;

[0251] The requirements relationships are as follows: Connection relationships link tasks to task requirements; coverage relationships link requirements to coverable units; authorization relationships express access permissions for task evidence capsules; assignment relationships link tasks to selected intelligent analysis units; delivery relationships link capsules to selected intelligent analysis units; response relationships link intelligent analysis units to message nodes; and dependency relationships represent execution order or data dependencies. All of these relationships carry execution graph identifiers and graph versions as scope fields.

[0252] S5.4. Ensure that the selected intelligent analysis unit node only stores the node identifier reference of the corresponding intelligent analysis unit node in the fixed capability permission graph, and store the task edge and negotiation edge in an independent runtime edge set;

[0253] For the fixed capability and permission graph, only node reading and contract parsing operations are performed; no task identifiers are appended to the fixed graph. The edge set at independent runtime can be implemented using a separate edge table, a key-value set partitioned by execution graph identifier, or an independent graph namespace, logically maintaining separation from the write path of the fixed graph.

[0254] In one database implementation, the fixed capability permission graph uses read-only connections or grants write permissions only to the configuration management service, while the task execution service only has write permissions to the runtime edge storage area. When creating a new temporary execution overlay graph, all task edges and negotiation edges are first written in the unpublished state. After completing node references, task evidence capsule references, and version consistency checks, it is atomically switched to the executable state. If a write failure occurs, the unpublished graph is not visible to the execution service, thus preventing the scheduling of a half-finished execution graph with only partial runtime edges written.

[0255] S5.5. Save the execution graph identifier, graph version, snapshot identifier, risk superedge template version, selected smart analysis unit, uncovered requirements, status, validity period, and graph hash for the temporary execution coverage graph;

[0256] Graph hashes can be calculated from execution graph metadata serialized in stable field order and runtime edge summaries, used during auditing to verify whether the graph structure has undergone changes not recorded in the version log. Graph versions increment when there are substantial changes in input content, selected intelligent analysis units, or task requirements, and older versions become unwritable.

[0257] Before calculating the graph hash, node references and runtime edges can be normalized and sorted according to a preset sorting key. Then, fields such as execution graph identifier, graph version, snapshot identifier, template version, list of selected intelligent analysis units, uncovered requirements, and validity period are stably serialized. This ensures that the same logical graph will not generate different graph hashes due to different return orders from the underlying database. During auditing, the same normalization process can be re-executed and the graph hashes compared to determine whether the structure and key version information of historical execution graphs remain consistent.

[0258] S5.6. When the task ends, the input version becomes invalid, the temporary execution overlay graph is replaced by a new graph, or a manual termination instruction is received, the corresponding runtime edge is deactivated, and the audit record of the temporary execution overlay graph is retained.

[0259] Deactivation does not delete historical records; instead, it changes the runtime edge state to a terminated state, preventing it from participating in new executions, while recording the deactivation time and reason. Thus, the fixed capability permission graph remains stable in the long term, while the temporary execution overlay graph has a lifespan consistent with a single task. In other implementations, the same isolation and traceability effects can be achieved by migrating the entire old graph to read-only audit storage.

[0260] Temporary execution overlay graphs can be configured with states such as creation, executable, deactivated, and replaced. When the input content version becomes invalid or task requirements change, the constrained selection is re-executed based on the new version, and a new graph is constructed. After the new graph passes the integrity check, it enters the executable state, and then the old graph is switched to the replaced state. For manual termination or natural task completion, the current graph is directly switched to the deactivated state. State changes only affect whether runtime edges can continue to participate in scheduling; they do not modify previously recorded historical node references, version information, or graph hashes.

[0261] This isolation mechanism addresses the issue of write pollution of stable control information caused by runtime networking. Because the fixed capability permission graph does not accept edges from single tasks, an increase in the number of tasks will not cause the stable graph to continuously accumulate temporary relationships. Since each execution graph carries an independent scope and version, concurrent tasks will not accidentally share task edges through shared nodes. Because old graphs are deactivated but not deleted, historical selection results can still correspond to the contract version, template version, and input snapshot at the time. Compared to directly adding temporary edges to the global graph and then attempting post-cleanup, this mechanism moves the isolation conditions forward to the storage and query path, reducing the risk of subsequent tasks reading incorrect relationships due to overlooking the cleanup of a temporary edge.

[0262] In a concurrent example, both the first and second tasks select the same analytical intelligence unit. However, the first task also selects a verification intelligence unit, while the second task selects a different support intelligence unit. The system creates two temporary execution coverage graphs, and all three intelligence unit nodes reference the same fixed capability permission graph through node identifiers. The allocation and dependency edges of the first task are only written to the first runtime edge set, and the edges of the second task are only written to the second runtime edge set. When the first task terminates first, only the first runtime edge set is deactivated; the second task can still continue execution, and its execution relationship is unaffected by the first task's deactivation. This example demonstrates that node reuse and runtime relationship isolation can coexist.

[0263] Example 10

[0264] like Figure 5 As shown, this embodiment provides a multi-agent constrained selection device.

[0265] Applications include: assisting in the generation of medical examination reports.

[0266] The capability and permission graph construction module is used to read the capability contract of the intelligent analysis unit and form a fixed capability and permission graph with the intelligent analysis unit as the node and the allowed collaboration relationship and data flow relationship as the static edge;

[0267] The capability and permission graph construction module may include a contract reading interface, a contract integrity verifier, and a fixed graph writing interface. The execution result is consistent with the S1 step of Embodiment 1 and the corresponding step of Embodiment 2.

[0268] The capability and permission graph construction module can also provide read-only graph version handles to other modules, instead of directly exposing write connections to the fixed capability and permission graph. The graph version handle contains the fixed capability and permission graph version and the contract registry snapshot version. The task requirement generation module and the constrained selection module use the same handle in the same task, thereby ensuring that candidate retrieval and subsequent permission verification are based on the same stable control version.

[0269] The department discovery acquisition module is used to acquire structured department discoveries;

[0270] The department discovery module reads the structured department discovery from the preceding physical examination information processing storage area and verifies the object schema and content version without changing the preceding objectification process.

[0271] The department discovery acquisition module can read objects according to the physical examination batch and the current input content version, and pass the structured department discovery identifier, concept code, fact slot, evidence reference, and content version to the task requirement generation module. For objects with mismatched pattern versions or expired content versions, the module returns a status that they cannot participate in the current matching, and does not send incomplete objects to the risk super-edge template for verification.

[0272] The task requirement generation module is used to map the structured department discovery to the risk hyperedge template, and instantiate the risk hyperedge when the hard constraints and activation conditions of the risk hyperedge template are met, thereby generating a set of task requirements.

[0273] The task requirement generation module may include a risk hyperedge template reader, a hard constraint verifier, an activation scorer, and a risk hyperedge instantiator, and generate a set of task requirements according to the processing relationships in Examples 3 and 4.

[0274] In addition to the set of task requirements, the output object of the task requirement generation module can also carry risk hyperedge instance identifiers, template versions, and input content version vectors. After receiving the above version information, the constrained selection module writes it together with the fixed capability permission graph version into the selection context. If any version inconsistency occurs during the selection process, the current solution is terminated and a consistent snapshot is obtained again. The module interface layer maintains the closure between the risk hyperedge instance and the data version used by the candidate selection.

[0275] The constrained selection module is used to verify the capabilities, evidence, field-level permissions, and calibration credibility of candidate intelligent analysis units based on the task requirement set and the fixed capability permission graph, forming an effective coverage matrix. Under the constraints of coverage, primary responsibility, and resources, it selects a set of intelligent analysis units based on five-dimensional costs and generates a task evidence capsule.

[0276] The constrained selection module may include a candidate retrieval unit, an effective coverage matrix generator, a hard constraint checker, a multi-objective cost solver, and a task evidence capsule projector, and completes the candidate validity judgment and combination selection according to the process of Examples 5 to 8.

[0277] The effective coverage matrix generator can simultaneously output a matrix version summary and a record of element failure reasons. The multi-objective cost solver only reads valid candidates from the matrix and first performs coverage, responsibility, and resource hard constraint checks. After receiving the final set of intelligent analysis units, the task evidence capsule projector generates capsules according to the capability contract, corresponding task requirements, and field-level permissions of each selected intelligent analysis unit, so that two selected intelligent analysis units can obtain different field projections even if they are processing the same task.

[0278] The execution coverage graph construction module is used to create a temporary execution coverage graph based on the task requirement set, the intelligent analysis unit set, and the task evidence capsule, so that the intelligent analysis unit nodes of the temporary execution coverage graph reference the nodes of the fixed capability permission graph and the edges are stored independently during runtime, and the intelligent analysis unit set is executed in isolation.

[0279] The execution coverage graph construction module establishes the task scope and independent runtime edge set described in Example 9, and can execute the selected intelligent analysis unit through containers, process sandboxes, restricted execution services, or other runtime environments with input boundary control capabilities. The modules in the device can be implemented by different software functional units on a single processor, or by service components on multiple processors working together, as long as the data input / output relationships between modules remain consistent with the method described.

[0280] During device operation, results can be exchanged between modules via structured objects with version metadata. The capability and permission graph construction module outputs a fixed capability and permission graph version handle, the department discovery acquisition module outputs the current structured department discovery, the task requirement generation module outputs a set of task requirements and corresponding template versions, the constrained selection module outputs a set of intelligent analysis units and task evidence capsules, and the execution coverage graph construction module solidifies the above results into the current execution graph. If the version carried by any intermediate object is inconsistent with the current task context, it is not submitted downstream, but the corresponding version data object is re-acquired, thereby implementing the version consistency requirements described in Examples 1 to 9 at the interface layer between device modules.

[0281] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A constrained selection method for multiple agents, characterized in that, Applications include: assisting in the generation of medical examination reports. Read the capability contract of the intelligent analysis unit to form a fixed capability permission graph with the intelligent analysis unit as the node and allowed collaboration relationships and data flow relationships as static edges; Obtain structured departmental findings; The structured department discovery is mapped to a risk hyperedge template. When the hard constraints and activation conditions of the risk hyperedge template are met, the risk hyperedge is instantiated to generate a set of task requirements. Based on the task requirement set and the fixed capability permission graph, candidate intelligent analysis units are verified for capability, evidence, field-level permissions, and calibration credibility to form an effective coverage matrix. Under the constraints of coverage, primary responsibility, and resources, a set of intelligent analysis units is selected based on five-dimensional costs, and a task evidence capsule is generated. This includes: determining the candidate intelligent analysis units in the fixed capability permission graph according to the necessary capabilities and primary responsibility capabilities included in the task requirement set; for each task requirement and each candidate intelligent analysis unit, verifying capability coverage, evidence availability, usage permissions, departmental permissions, field-level permissions, and minimum calibration credibility, and setting the corresponding effective coverage matrix element as valid only when all verifications pass; based on... The effective coverage matrix verifies the minimum number of coverages required for each necessary task, the participation status of the responsible intelligent analysis unit, and the resource consumption of candidate combinations, eliminating candidate combinations that do not meet the coverage, responsibility, or resource constraints. For the retained candidate combinations, the resource cost, expected latency, output uncertainty, additional sensitive field exposure, and expected conflict degree between intelligent analysis units are determined. A multi-objective cost solution is performed on the resource cost, expected latency, output uncertainty, additional sensitive field exposure, and expected conflict degree between intelligent analysis units to select the set of intelligent analysis units, and the task evidence capsule is generated based on the capability contract, corresponding task requirements, and field-level permissions of the selected intelligent analysis units. Based on the task requirement set, the intelligent analysis unit set, and the task evidence capsule, a temporary execution coverage graph is created. The intelligent analysis unit nodes in the temporary execution coverage graph reference the nodes in the fixed capability permission graph, and their runtime edges are stored independently. The intelligent analysis unit set is executed in isolation. This includes: limiting the effective scope of the temporary execution coverage graph based on the current examinee, examination batch, consultation task, medical evidence graph snapshot, and input content version; establishing task nodes, evidence or capability requirement nodes, selected intelligent analysis unit nodes, task evidence capsule nodes, and message nodes in the temporary execution coverage graph; and using requirement relationships, coverage relationships, authorization relationships, and distribution relationships... The runtime edges are established based on the relationships of assignment, delivery, response, and dependency; the selected intelligent analysis unit node only stores the node identifier reference of the corresponding intelligent analysis unit node in the fixed capability permission graph, and the task edge and negotiation edge are stored in an independent runtime edge set; the execution graph identifier, graph version, snapshot identifier, risk superedge template version, selected intelligent analysis unit, uncovered requirement, status, validity period, and graph hash are stored for the temporary execution coverage graph; the corresponding runtime edges are deactivated when the task ends, the input version expires, the temporary execution coverage graph is replaced by a new graph, or a manual termination instruction is received, and the audit records of the temporary execution coverage graph are retained.

2. The method according to claim 1, characterized in that, The capability contract for reading the intelligent analysis unit forms a fixed capability permission graph with the intelligent analysis unit as nodes and permitted collaboration relationships and data flow relationships as static edges, including: Read the currently valid versioned capability contract from the capability contract registry. The versioned capability contract at least registers the intelligent analysis unit identifier and version, role, capability code, supported task type and supported concept code. The versioned capability contract registers the allowed input modes, output modes, negotiation message types, data tags, field ranges, uses, and departmental permissions. The versioned capability contract registers rules, model or program versions, trust configurations, resource cost configurations, latency configurations, conflict configurations, and timeout, retry, and abstention policies. Configure the validity period, contract hash, and signature for the versioned capability contract, and generate a new contract version when the capability, permissions, or configuration are updated; The fixed capability permission graph is generated based on the currently valid versioned capability contract, so that the fixed capability permission graph only stores stable control information and does not store subject data, and runtime tasks are prohibited from writing temporary edges to the fixed capability permission graph.

3. The method according to claim 1, characterized in that, The process involves mapping the structured department findings to a risk hyperedge template, instantiating the risk hyperedge when the hard constraints and activation conditions of the risk hyperedge template are met, and generating a task requirement set, including: The risk over-edge template includes a necessary discovery set, an optional discovery set, a limited or negative evidence set, directional constraints, a time window, evidence quality constraints, a minimum number of supports, a necessary capability set, primary responsibility capabilities, negotiation role requirements, output object patterns, scoring parameters, activation thresholds, template versions, and applicable scope. The effective matching status of the structured department findings with the discovery conditions in the risk super-edge template is determined based on concept mapping, anomaly direction, time window, evidence quality, content version, and calibration confidence. Hard constraint verification is performed on the necessary discovery set, the directional constraint, the time window, the evidence quality constraint, and the minimum number of supports; Based on the effective matching state, evidence quality, calibration confidence, conditional weight, combined gain, and constraint penalty, the activation score of the risk hyperedge template is calculated. When the hard constraint verification is passed and the activation score reaches the activation threshold, the risk superedge is instantiated. The risk superedge instance outputs the target evidence set, the necessary capability set, the primary responsibility capability, the minimum coverage count, the negotiation role requirements, the information level upper limit, and the output object pattern to form the task requirement set.

4. The method according to claim 3, characterized in that, The activation score of the risk hyperedge template is calculated based on the effective matching state, evidence quality, calibration confidence, conditional weights, combined gain, and constraint penalty, including: For each discovery condition in the risk superedge template, obtain the corresponding effective matching state, evidence quality, calibration confidence level, and condition weight; The product of the effective matching state, the evidence quality, the calibration confidence, and the condition weight is used as the weighted support quantity for the corresponding discovery condition; The combined support quantity is calculated based on the combination of preset discovery conditions that are met simultaneously and the corresponding combined gain. The restriction deduction amount is calculated based on the missing or unmet quality requirements and the corresponding restriction penalties. The sum of the weighted support and the combined support, minus the restriction deduction, is normalized according to the total amount of the conditional weights and the combined gain, and the normalization result is restricted to the range of zero to one to obtain the activation score. The predetermined full value is used as the calibration confidence level for the deterministic rule output, and the calibrated confidence level corresponding to the model version is used for the model output. The activation score is used to determine the activation after the hard constraint verification is completed.

5. The method according to claim 1, characterized in that, For each task requirement and each candidate intelligent analysis unit, the capability coverage, evidence availability, usage permissions, departmental permissions, field-level permissions, and minimum calibration confidence are verified. Only when all verifications pass are the corresponding valid coverage matrix elements set to valid, including: Match the capability codes declared in the capability contract of the corresponding candidate intelligent analysis unit with the necessary capabilities required by the corresponding task to determine the basic coverage status; Verify the availability and validity of the evidence required for the corresponding task in the current medical evidence snapshot; Verify whether the task purpose and department required for the corresponding task fall within the purpose and department permissions registered in the capability contract; Compare the access tags of the fields required by the corresponding task requirements with the data tags allowed by the capability contract, and verify that the required fields fall within the field range registered in the capability contract. The calibration confidence is determined based on historical comparable outputs and subsequent verification results under the same task type, concept scope and intelligent analysis unit version, and the versioned confidence prior is invoked when historical samples are lacking. The effective coverage matrix elements are synthesized from the basic coverage status, the evidence availability status, the content version validity status, the usage permissions, the department permissions, the field-level permissions, and the comparison results of the calibration confidence and the corresponding minimum calibration confidence.

6. The method according to claim 1, characterized in that, The process involves solving a multi-objective cost equation for the resource cost, the expected latency, the output uncertainty, the exposure of additional sensitive fields, and the expected conflict degree between the intelligent analysis units. This process selects the set of intelligent analysis units and generates the task evidence capsule based on the selected intelligent analysis units' capability contracts, corresponding task requirements, and field-level permissions. Normalize the resource cost, the expected latency, the output uncertainty, and the exposure of additional sensitive fields, respectively. The weighted sum of the normalized resource cost, normalized expected delay, normalized output uncertainty, and normalized exposure of additional sensitive fields of each candidate intelligent analysis unit in the candidate combination is combined with the expected conflict degree weighting term of each pair of candidate intelligent analysis units to form the total cost of multiple objectives. The candidate combinations that minimize the total cost of the multi-objectives or whose difference from the minimum value does not exceed a preset approximate threshold under the constraints of coverage, primary responsibility, and resources are used as the set of intelligent analysis units. If no feasible candidate combination exists that satisfies the coverage, primary responsibility, and resource constraints, as well as the field-level permissions and the minimum calibration confidence level, an infeasible selection object is generated, the reasons for the lack of coverage and the constraint conflict are recorded, and the corresponding task is transferred to evidence supplementation or manual review without relaxing the access permissions or the minimum calibration confidence level.

7. The method according to claim 6, characterized in that, The weighted sum of the normalized resource cost, normalized expected latency, normalized output uncertainty, and normalized exposure of additional sensitive fields for each candidate intelligent analysis unit within the candidate combination, combined with the expected conflict degree weighting term for each pair of candidate intelligent analysis units, constitutes the multi-objective total cost, including: The normalized resource cost is determined based on the version conversion factors of processor consumption, graphics processor consumption, and model call consumption, as well as the resource budget. The normalized estimated latency is determined based on the predicted execution latency and task time limit of the corresponding candidate intelligent analysis unit version; The normalized output uncertainty is determined based on the importance of each task requirement, the effective coverage status of the corresponding candidate intelligent analysis unit, and the calibration confidence. The normalized additional sensitive field exposure amount is determined based on the fields sent across the original security domain and the corresponding sensitive weights of those fields. The expected conflict degree is determined based on the historical substantive divergence number and comparable output number of each pair of candidate intelligent analysis units under the same task type, concept scope and intelligent analysis unit version, and a versioned conflict degree default value is adopted when historical data is lacking. The normalized resource cost, the normalized expected delay, the normalized output uncertainty, the normalized additional sensitive field exposure, and the expected conflict degree are weighted using non-negative cost weights. When the total cost of the multi-objectives of multiple candidate combinations is the same, a unique set of intelligent analysis units is determined in sequence according to the number of intelligent analysis units, the expected total latency, the number of additional sensitive fields, and the lexicographical order of the intelligent analysis unit identifiers.

8. A multi-agent constrained selection device, characterized in that, Applications include: assisting in the generation of medical examination reports. The capability permission graph construction module is used to read the capability contract of the intelligent analysis unit and form a fixed capability permission graph with the intelligent analysis unit as the node and the allowed collaboration relationship and data flow relationship as the static edge; The department discovery acquisition module is used to acquire structured department discoveries; The task requirement generation module is used to map the structured department discovery to the risk hyperedge template, and instantiate the risk hyperedge when the hard constraints and activation conditions of the risk hyperedge template are met, thereby generating a set of task requirements. The constrained selection module is used to verify the capabilities, evidence, field-level permissions, and calibration credibility of candidate intelligent analysis units based on the task requirement set and the fixed capability permission graph, forming an effective coverage matrix. Under coverage, responsibility, and resource constraints, it selects a set of intelligent analysis units based on five-dimensional costs and generates a task evidence capsule. This includes: determining the candidate intelligent analysis units in the fixed capability permission graph based on the necessary capabilities and responsibility capabilities included in the task requirement set; verifying capability coverage, evidence availability, usage permissions, departmental permissions, field-level permissions, and minimum calibration credibility for each task requirement and each candidate intelligent analysis unit; and setting the corresponding effective coverage matrix element only when all verifications pass. Valid; based on the valid coverage matrix, verify the minimum number of coverages required for each necessary task, the participation status of the responsible intelligent analysis unit, and the resource consumption of candidate combinations, and eliminate candidate combinations that do not meet the coverage, responsibility, or resource constraints; for the retained candidate combinations, determine the resource cost, expected latency, output uncertainty, additional sensitive field exposure, and expected conflict degree between intelligent analysis units; perform multi-objective cost solving on the resource cost, expected latency, output uncertainty, additional sensitive field exposure, and expected conflict degree between intelligent analysis units, select the set of intelligent analysis units, and generate the task evidence capsule according to the capability contract, corresponding task requirements, and field-level permissions of the selected intelligent analysis units; The execution coverage graph construction module is used to create a temporary execution coverage graph based on the task requirement set, the intelligent analysis unit set, and the task evidence capsule. This ensures that the intelligent analysis unit nodes in the temporary execution coverage graph reference nodes in the fixed capability permission graph, and that runtime edges are stored independently, isolating the execution of the intelligent analysis unit set. This includes: limiting the effective scope of the temporary execution coverage graph based on the current examinee, examination batch, consultation task, medical evidence graph snapshot, and input content version; establishing task nodes, evidence or capability requirement nodes, selected intelligent analysis unit nodes, task evidence capsule nodes, and message nodes in the temporary execution coverage graph; and using requirement relationships, coverage relationships, and other parameters to define the effective scope of the temporary execution coverage graph. The runtime edges are established based on authorization relationships, allocation relationships, delivery relationships, response relationships, and dependency relationships; the selected intelligent analysis unit node only stores node identifier references to the corresponding intelligent analysis unit node in the fixed capability permission graph, and the task edge and negotiation edge are stored in an independent runtime edge set; the execution graph identifier, graph version, snapshot identifier, risk superedge template version, selected intelligent analysis unit, uncovered requirement, status, validity period, and graph hash are stored for the temporary execution coverage graph; the corresponding runtime edges are deactivated when the task ends, the input version expires, the temporary execution coverage graph is replaced by a new graph, or a manual termination instruction is received, and the audit records of the temporary execution coverage graph are retained.

Images