A method and system for front-driven self-growth of a medical object graph

Abstract

The application discloses a kind of front driving self-growth methods and systems of medical examination object graph, configure limited type meta graph and generate medical examination object initial graph according to the medical examination data that has been collected, form expansion task set according to new object, state change object and unsaturated object;Determined hard filtering and branch perception heterogeneous graph state coding obtain restricted local subgraph, use local complexity evaluation with hard gate condition to select direct generation or nested subfrontier;Candidate generation is divided into two stages of topological plan and complete incremental generation, dynamically allocate candidate slot under the constraint of relationship signature coverage;Candidate increment is versioned after being verified by independent graph execution component, and is submitted, and with the complete round of complete applicable relationship signature is judged fixed point without graph state change. Thus, the expansion granularity and computing resources can be adjusted with the local structure state, while maintaining the integrity of candidate isolation and fixed point determination.

Description

Technical Field

[0001] This invention relates to the field of data processing technology for health check-up information, and in particular to a method and system for generating a health check-up object-level information graph using finite type metagraphs, dynamic graph state coding, and frontier task scheduling for collected health check-up data. Background Technology

[0002] Health checkup information systems typically need to receive collected data from various sources, including test results, imaging findings, functional examination results, and specialist examination descriptions. They then organize the data into a comprehensive information structure at the level of the individual examinee, considering the underlying reasons, constraints, contradictory relationships, and hierarchical relationships among these different data objects. Because different examinees have different combinations of examination items, temporal relationships, and data gaps, the final information structure varies in the number of nodes, relationship types, and hierarchical levels.

[0003] A common approach is to use a fixed workflow, preset combination rules, or a fixed number of rounds of generative model calls to combine data objects that meet predetermined conditions. The fixed workflow uses essentially the same control nodes for different data objects, the preset combination rules expand as the number of check items increases, and the fixed number of rounds of calls primarily uses external limit counts as the stopping condition. Another approach uses a finite type metagraph to limit the allowed node types, relationship types, levels, and states, selects local subgraphs based on the unsaturated frontier, and has the generative component propose candidate increments which are then verified by independent components.

[0004] The front-driven self-growth approach enables previously submitted synthesis nodes to become inputs for subsequent expansions, and identifies fixed points in the graph state through a complete round of no-submission increments. However, existing front expansions typically employ a uniform processing granularity across different local subgraphs, and candidate generation often allocates a fixed number of candidate slots for each task; compatibility object selection mainly relies on paired conditions such as concepts, locations, and times, and rarely utilizes multi-hop relationships, constraint relationships, and conflicting activity relationships in the current graph.

[0005] Therefore, the existing solutions still have the following technical problems: the uniform processing granularity is difficult to adapt to both simple local combinations and local combinations containing missing roles, activity conflicts or cross-layer dependencies at the same time, and direct generation may compress complex dependencies into a single candidate target. Summary of the Invention

[0006] This invention aims to provide a frontier-driven self-growth method and system for physical examination object graphs, in order to solve the problems that the frontier expansion granularity cannot be adjusted with the local structural complexity, the difficulty in balancing candidate resource allocation and complete round coverage, and the possibility that structural state encoding may destroy candidate isolation.

[0007] The present invention adopts the following technical solution:

[0008] A frontier-driven self-growth method for a physical examination object graph, wherein the frontier is the range of objects in the currently submitted physical examination object graph that can trigger subsequent expansion, including:

[0009] Configure a finite type metagraph with limited node types, relationship types, levels, states, and maximum depth, and generate an initial graph of the physical examination objects based on the collected physical examination data;

[0010] Based on the initial or updated image of the physical examination subjects, newly added objects, objects with changed states, and unsaturated objects are identified to form an extended task set with leading-edge fingerprints;

[0011] Perform deterministic hard filtering and branch-aware heterogeneous graph state encoding on the extended task set to obtain a restricted local subgraph set;

[0012] Perform a local complexity evaluation with hard gate conditions on the set of restricted local subgraphs, and divide the restricted local subgraphs in the set of restricted local subgraphs into direct generation tasks or nested subfronts with directed acyclic dependencies;

[0013] For the directly generated task or the nested sub-front generation topology plan, after pre-examination, candidate slots are allocated according to relation signature coverage constraints and expected submission benefit gains, and candidate physical examination object graph increments are generated.

[0014] The independent graph execution component verifies and version submits the legal candidate physical examination object graph increment, updates the frontier, and determines the fixed point or resource stopping result based on the graph state changes of the complete round.

[0015] Furthermore, the finite type metagraph defines the original observation node, discovery node, restriction node, conflict node, and comprehensive node, as well as the ordinary edge type, directed superedge signature, node level, node state, applicable conditions for relation signature, maximum node depth, and allowed state migration; the initial graph of the physical examination object is formed by the physical examination data through graph compilation, deterministic discovery, and consistency verification.

[0016] Furthermore, the local complexity gating first checks for missing forming roles, conflicting activity roles, and hard gate conditions for cross-layer dependencies, and then calculates the weighted complexity based on the versioned and normalized local complexity vector; when recursive decomposition is triggered, a bounded nested sub-front directed acyclic graph is constructed according to organ systems, forming roles, and dependency directions, and subsequent tasks can only read the submitted intermediate goals.

[0017] Furthermore, candidate generation first generates a topology plan containing only the source node role combination, target node type, target level, and necessary dependencies. After relation signature, object identifier, level, state permissions, and hard conflict pre-check, a complete candidate increment is generated. Budget allocation first allocates a minimum number of slots to tasks with unprocessed relation signatures and tasks that have reached the maximum waiting round, and then allocates flexible slots according to the expected submission benefit gain.

[0018] Furthermore, the branch-aware heterogeneous graph state encoding processes the confirmation view and the candidate view separately. The confirmation view blocks candidate node messages, while the candidate view allows reading committed node messages but prohibits different candidate source branches from passing messages to each other. The encoded branch state vector is only used for candidate recall and sorting and does not change the node confirmation permissions.

[0019] Furthermore, the independent graph execution component verifies the candidate incremental execution type, source, object identifier, level, loop, activity conflict, and state transition permissions; a fixed point is formed only when there are no committable incremental points and no incomplete tasks in a complete round covering all applicable relation signatures, and a resource stop result is formed when the resource limit is reached but there are still incomplete tasks.

[0020] This invention employs a recursive decomposition mechanism combining hard-gate conditions and weighted complexity. This allows local subgraphs triggering missing roles, conflicting roles, or cross-layer dependencies to be decomposed into sub-fronts with a dependency order, while local subgraphs not triggering these conditions can still be directly generated. This maintains bounded recursion while adapting the processing granularity to the local structural state. By separating the generation of the topology plan from the generation of complete candidate increments, and using relation signatures to cover guaranteed slots, waiting guaranteed slots, and expected submission benefit gain elastic slots, all applicable relation signatures can be processed, while reducing the generation of complete content for structures that fail the pre-check. Since the confirmation view and candidate view execute message passing with branch masks respectively, the confirmation front does not receive candidate node messages. This allows for improved recall using multi-hop structural relationships while maintaining isolation between committed and provisional states. Since the establishment of a fixed point requires complete round coverage, unchanged graph state, completed saturation vectors, and an empty task queue, insufficient resources will not be misjudged as a graph state fixed point. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the overall process of the frontal-driven self-growth method for physical examination objects provided in an embodiment of the present invention;

[0022] Figure 2 This is a schematic diagram showing the correspondence between the steps of the frontier-driven self-growth method for physical examination objects provided in this embodiment of the invention and the reference implementation carrier in the overall physical examination business;

[0023] Figure 3This is a schematic diagram of the process for local complexity gating and nested sub-front generation provided in an embodiment of the present invention;

[0024] Figure 4 A schematic diagram illustrating the process of dynamic candidate budget allocation under coverage constraints provided in an embodiment of the present invention;

[0025] Figure 5 A schematic diagram of the branch-aware heterogeneous graph state encoding process provided in an embodiment of the present invention;

[0026] Figure 6 An activity graph for data and control transfer between graph state management, frontier and candidate processing, and independent verification, provided in embodiments of the present invention;

[0027] Figure 7 This is a schematic diagram of the module structure of the front-end driven self-growth system for physical examination objects provided in an embodiment of the present invention. Detailed Implementation

[0028] The embodiments of the present invention will be described below with reference to the accompanying drawings. Each embodiment processes the collected physical examination data to form a graph structure, graph state, and resource stop markers for subsequent information aggregation or review, without outputting qualitative conclusions or intervention plans regarding the health status of individuals. The present invention processes the collected physical examination data, with inputs including test results, imaging findings, functional examination results, and specialist examination descriptions, along with object identifiers, examination cycle, time, location, side, and source information. The present invention does not control the data collected by the examination equipment; it directly outputs a physical examination object graph and its graph state constrained by a finite-type metagraph, including verified and submitted nodes and relationships, graph version, frontier information, fixed point markers, or resource stop markers. Downstream information aggregation, manual review, or report assembly are not necessary steps added to the self-growth process of the present invention. The self-growth referred to in the present invention is not the unconstrained addition of content, nor is it the self-training of model parameters, but rather the repeated execution of frontier identification, candidate proposal, independent verification, and versioned submission based on the currently submitted graph. In terms of hardware, each implementation can be implemented by one or more processors executing computer programs in memory, or it can be deployed as a graph compilation service, task scheduling service, candidate generation service, and independent graph execution service that communicate with each other. The candidate generation entity only writes candidate views, while the independent graph execution entity has the authority to submit the confirmed views. The thresholds, weights, dimensions, number of candidates, and rounds given in the implementation are only for illustrating possible implementations and do not constitute a limitation on the scope of protection.

[0029] Example 1

[0030] like Figure 1As shown, this embodiment provides a frontier-driven self-growth method for a physical examination object map, wherein the frontier is the range of objects in the currently submitted physical examination object map that can trigger subsequent expansion, including the following steps.

[0031] S1. Configure a finite type metagraph with limited node types, relationship types, levels, states, and maximum depth, and generate an initial graph of the physical examination objects based on the collected physical examination data;

[0032] A finite-type metagraph is a data structure that restricts the graph language that can be generated, rather than a complete instance topology pre-written for a specific health checkup object. Nodes represent objects in the graph, edges represent relationships between objects, a directed acyclic graph means that dependent edges are directed and non-cyclic, and topological order represents the processing order that satisfies the dependent direction. Node types can include original observation nodes, discovery nodes, constraint nodes, conflict nodes, and synthesis nodes; relationship types can include source relationships, formation relationships, constraint relationships, contradictory relationships, and version relationships. Each relationship signature declares at least the source role set, target node type, allowed hierarchical range, applicable state, and maximum in-degree, thereby limiting the range of structures that the generation component can propose. The collected health checkup data is compiled into original observation nodes after field normalization and object identifier binding. Deterministic discovery rules can further form discovery nodes with clear sources. The initial health checkup object graph is an object-level graph structure formed based on the collected health checkup data and constrained by the finite-type metagraph. The updated health checkup object graph is a graph structure formed by incremental submission based on the initial health checkup object graph. This step can be implemented using a rule interpreter, graph database constraints, or typed object storage; this invention does not limit the specific implementation.

[0033] S2. Identify newly added objects, objects with changed states, and unsaturated objects based on the initial or updated image of the physical examination objects, forming an extended task set with leading-edge fingerprints;

[0034] The frontier is the range of objects in the currently submitted medical examination object graph that can trigger subsequent expansions. Subsequent expansions refer to the process of generating expansion tasks from objects within this range and incrementally submitting independently verified and valid candidate medical examination object graphs to the medical examination object graph. The currently submitted medical examination object graph refers to the initial medical examination object graph or the updated medical examination object graph obtained after versioned submission. The initial medical examination object graph constitutes the initial baseline graph version. The frontier fingerprint can be composed of the graph version number, target node identifier, relation signature identifier, node state summary, and applicable rule version. For expansion tasks with the same frontier fingerprint under the same graph version, the task scheduler performs idempotent merging. When a node changes from a provisional state to a committed state, or the activity state of a constraint relation changes, a new frontier fingerprint is generated. New objects refer to objects that appear newly relative to the previous graph version, and objects with changed states refer to objects whose node state or the activity state of a constraint relation changes relative to the previous graph version. Expansion tasks refer to pending tasks generated for new objects, objects with changed states, or unsaturated objects. The set of expansion tasks consists of all expansion tasks in the current round. An unsaturated object is an object for which at least one applicable relation signature has not yet yielded a processed result. Processed results include both submitting a valid increment and obtaining a deterministic result without a valid increment under the current evidence.

[0035] S3. Perform deterministic hard filtering and branch-aware heterogeneous graph state encoding on the extended task set to obtain a restricted local subgraph set;

[0036] Deterministic hard filtering first excludes objects incompatible by object identifier, health check period, time interval, location, side, or relation signature. Before learning-based matching or sorting, deterministic hard filtering is performed based on non-learnable Boolean conditions. After passing these conditions, only candidate objects, necessary paths, activity constraint nodes, and version nodes are retained, forming a restricted local subgraph. Subsequently, the encoder aggregates formation, constraint, conflict, and version relationships in the confirmation view and candidate view, respectively. The confirmation view only contains committed and currently valid nodes and relationships, while the candidate view stores uncommitted candidate content. Branch masks prevent candidate nodes from sending messages to the confirmation view and prevent candidate nodes from different candidate source branches from passing messages to each other. Local node semantics and multi-hop dependency structures are combined into a branch state vector. The branch state vector serves only as the basis for recalling rule fragments and candidate objects; it cannot rewrite candidate nodes as committed nodes, nor can it bypass subsequent verification by the independent graph execution component.

[0037] S4. Perform a local complexity evaluation with hard gate conditions on the set of restricted local subgraphs, and divide the restricted local subgraphs in the set of restricted local subgraphs into direct generation tasks or nested subfronts with directed acyclic dependencies;

[0038] Local complexity assessment comprises two levels: hard-gate judgment and weighted judgment. Hard-gate judgment captures local structures where the number of nodes may not be large, but the combined risk is concentrated. This includes situations where necessary forming roles are missing, the same forming role has at least two sources of conflict, and the target formation depends on spanning a preset number of levels. If the hard gate is not triggered, a weighted judgment is then made based on a local complexity vector formed by the number of source types, cross-departmental span, number of conflicts, number of missing roles, expected target level span, and upper bound of candidate combinations. Directly generated tasks maintain the current constrained local subgraph; recursive decomposition tasks are broken down into directed acyclic sub-frontier tasks, limited by the number of nodes and recursion depth.

[0039] S5. For the directly generated task or the nested sub-front generation topology plan, after pre-examination, candidate slots are allocated according to relation signature coverage constraints and expected submission benefit gains, and candidate physical examination object graph increments are generated;

[0040] The topology plan only contains structural layer information and does not generate large segments of node content. Pre-screening excludes plans that violate relation signatures, hierarchy, object identifiers, or state permissions. A backup slot is reserved for each unprocessed relation signature, and a waiting backup slot is reserved for tasks that have reached the maximum waiting round. The remaining candidate slots are allocated according to the expected submission reward gain. Only topology plans that obtain candidate slots proceed to the generation of complete attributes, edges, and directed hyperedges, thus separating the evaluation of structure selection from content generation. Tasks that do not obtain candidate slots remain as incomplete task keys.

[0041] S6. Verify and version the legal candidate physical examination object graph increments through the independent graph execution component, update the frontier, and determine the fixed point or resource stopping result based on the graph state changes of the complete round.

[0042] The generation component is only responsible for proposing candidate instance structures, while the independent graph execution component has the authority to confirm them. Verification items include node type, relation signature, source, object identifier, level, loop, activity conflict, and state transition permissions. Verified candidate increments are atomically committed based on the graph version number; failures do not result in partial writes. New nodes, their formation basis, and state changes after committing re-enter the frontier. Fixed-point determination requires that there are no committable increments within a complete round covering all applicable relation signatures, the task queue of the extended task set is empty, the graph state hash remains unchanged, and the saturation vector is complete. If the upper limit of candidate slots, recursion depth, number of subtasks, or runtime is reached, and there are still unfinished tasks, a resource stop result is output, and the continuation status is saved. A fixed point indicates graph state convergence; a resource stop result only indicates the end of the current running window and that continuation can be achieved using the saved graph version, frontier fingerprint, and unfinished task key. These two use different status codes and cannot be confused.

[0043] In one example, the initial graph of a medical examination subject includes a test observation node, an image view node, a specialist description node, and an activity restriction node. The system first generates an extended task for unprocessed cross-source formation relationships, which, after hard filtering, yields local objects compatible with the same examination cycle and location. If two sources within this local object give mutually exclusive states to the same formation role, a conflict role hard gate is triggered, first constructing a nested sub-frontier of "conflict evidence processing—restriction condition analysis—comprehensive goal formation." Only after the intermediate goals of the first two sub-frontiers are submitted through the independent graph execution component will these intermediate goals enter the comprehensive goal formation task. Therefore, the candidate generation process does not treat unconfirmed intermediate results as formal evidence.

[0044] like Figure 2 As shown in the table below, the execution methods of each step in this embodiment within the overall physical examination business scenario, and the corresponding relationships between them and reference implementation vehicles undertaking similar processing responsibilities, are as follows:

[0045] Graph initialization The system receives, breaks down, and standardizes physical examination data, converting institutional interface records into original observation nodes with object identifiers, examination cycles, departments, combined items, and the source of examination items, thus forming an initial processing state. For example, physical examination subject P-001, examination cycle C-001, alanine aminotransferase (ALT) level of 57 U / L with an elevated indication, normal chest X-ray, and body mass index (BMI) of 28.88, retaining the original values, units, reference ranges, indications, and sources. The report status class is MedicalReportState; the result splitting function is split_exam_results_node(); the model input preparation function is prepare_llm_input(); the format compatibility function is format_compatible(); and the useless prefix removal function is remove_useless_prefix(). Frontier Formation The system identifies newly added objects, objects with changed states, and objects awaiting processing. It extracts unprocessed anomalies, identifies normal items, and identifies available rule information from the current state. It then generates extended tasks with state fingerprints and merges them with tasks that share the same fingerprint. For example, elevated ALT levels trigger anomaly processing, a normal chest X-ray serves as the context for judgment, and BMI records are entered into corresponding candidate processing. The diagnostic execution function is `run_diagnosis()`; the single-item diagnostic function is `diagnose_exam()`; the combined retrieval function is `search_compose_x()`; and the report classification class is `MedicalReportClassifier.classify()`. Structural recall Hard filtering is performed based on the same physical examination subject, examination cycle, department, combination of items, source of evidence, and permissible relationship, retaining only the subjects and dependencies required for this round of processing; records with inconsistent sources, examination groups, and original examination items, or with inconsistent subjects or cycles, are not included in this round of subgraph. The functions for anomaly detection are: `reconcile_marked_abnormal_findings()`; `validate_evidence_context()`; `TreeSearch.match()`; and `check_determine_reinforce()`. Recursive gating Process directly when there are no missing dependencies or conflicts; split into subtasks when necessary dependencies or conflicts exist, and collect the processing results in topological order. For example, a single ALT anomaly can be directly formed as a candidate, while multiple pieces of evidence need to be combined for judgment, and necessary evidence should be waited for. Failed branches are kept isolated. The workflow construction function is `build_workflow()`; the state graph class is `StateGraph.add_conditional_edges()`; the diagnostic routing function is `route_after_diagnosis()`; the diagnostic configuration class is `DiagnosisConfig`; and the diagnostic execution function is `diagnosis_execute()`. Candidate generation In the candidate region, merge duplicate or rule-permitted related conclusions, retain the original evidence, and sort them according to risk and business rules. These conclusions are not included in the final report at this stage. For example, abnormalities such as elevated ALT retain the original evidence, and normal chest X-rays are not mistakenly classified as abnormal. Combined conclusions lacking supporting evidence continue to await further investigation. The functions for merging results are: `merge_result()`; merging diagnostic results is: `merge_diagnosis_result()`; sorting and suggestion generation is: `sort_and_generate_advice()`; the merging class is: `DiagnosisMerge.merge_by()`; the merging execution function is: `merge_execute()`; and the special sorting rule is: `special_sort_rule()`. Validation and Submission Verify the source of evidence, the uniqueness of candidates, structure, and processing status. If verification fails, proceed to the failure or recalculation branch. Only after successful verification will a final report be generated. Confirm that each diagnostic identifier appears only once and has source and examination group information. If successful, output conclusions, explanations, and recommendations. If unsuccessful, do not submit. The functions for merging groups are: normalize_merge_groups(); validate_evidence_context(); assemble_medical_report(); assemble_failed_report(); back_process(); tags_process(); and remove_html().

[0046] The function names and class names in the table above are taken from the reference implementation and only indicate the implementation carrier. They do not change the node type, relationship type, processing steps or termination conditions defined in this embodiment, nor are they considered as new technical features. Candidate results still need to be verified by the independent graph execution component before they can enter the submission view.

[0047] In a specific example, the collected data for the same physical examination subject P-001 and the same physical examination cycle C-001 are grouped according to "Department - Combined Items - Examination Items". The example input is shown in the table below. The example numbers are all internal references and do not use real names, ID numbers or contact information.

[0048] OBS-01 Laboratory ALT 57 U / L; Reference range 9-50; Indicates elevated level Structured inspection record OBS-02 Radiology Chest X-ray (PA view) No obvious abnormalities were found in the lungs and diaphragm. Video Record OBS-03 Electrocardiogram Room electrocardiogram Normal electrocardiogram Functional check log OBS-04 ophthalmology Left eye vision / (Placeholder) Original records with available results are missing.

[0049] During the graph initialization phase, the system loads a finite-type metagraph that allows for raw observation, discovery, restriction, conflict, and synthesis nodes. After normalizing OBS-01 to OBS-04, it compiles them into raw observation nodes and establishes source relationships. OBS-01 can form structured discoveries "above the reference upper limit" based on a defined numerical range; OBS-04, lacking usable results, is retained but marked as restricted input or forms restricted nodes. After performing consistency checks on object identification, examination period, time interval, location, side, and source for the formed nodes and relationships, the initial graph G0 is formed.

[0050] During the front formation phase, the system scans newly added objects, state-changed objects, and unsaturated objects in G0. If there is a formation relation in OBS-01 that is applicable but has not yet yielded a processing result, then an extension task T-01 is formed; the front fingerprint of T-01 includes the graph version number of G0, the target node identifier, the relation signature identifier, the node state summary, and the applicable rule version.

[0051] During the structure recall phase, the system first excludes records with incompatible object identifiers, health check cycles, time compatibility conditions, locations, sides, or relationship signatures. Then, it constructs a confirmation view and a candidate view and performs branch-aware coding, retaining candidate objects, necessary paths, activity restriction nodes, and version nodes to obtain the restricted local subgraph LG-01.

[0052] During the recursive gating phase, if all the necessary forming roles of LG-01 are satisfied and no activity conflict role threshold or cross-layer dependency threshold is triggered, then direct processing is performed according to version-weighted complexity; if a hard gate condition is triggered, then subtasks are split according to forming roles and dependency directions, acyclic dependencies are established and executed in topological order. The upper limit of recursion depth and the upper limit of the number of subtasks in a single nested graph are pre-defined by a finite type metagraph.

[0053] During the candidate generation phase, the system first generates a topology plan containing only the source node role combination, target node type, target level, and necessary dependencies. It then pre-checks relationship signatures, object identifiers, levels, state permissions, and hard conflicts in sequence. If approved, it allocates a coverage slot to unprocessed relationship signatures, and a waiting slot to topology plans that have reached the maximum waiting round. Remaining elastic slots are allocated according to the expected submission benefit gain, forming the candidate graph increment CG-01. Tasks corresponding to topology plans that do not receive a candidate slot are retained as incomplete task keys.

[0054] During the convergence verification phase, the independent graph execution component verifies CG-01. If all verifications pass and the baseline graph version number remains unchanged, the incremental overall atomic commit forms the updated physical examination object graph G1; otherwise, it is rejected or re-verified on the new graph version. After the complete round ends, the fixed point conditions are checked; if the resource limit has been reached and there are still unfinished task keys, the continuation status is saved and a resource stop result is generated.

[0055] The reference implementation of this embodiment can be summarized into five types of procedural actions: data splitting, input organization, context verification, duplicate evidence merging, and processing order arrangement. Data splitting and input organization undertake the input normalization during the initial graph generation stage of the physical examination object; context verification provides object identification, physical examination cycle, and source information for deterministic hard filtering; duplicate evidence merging and processing order arrangement serve as the engineering carrier for candidate structure generation. These procedural actions only provide input data or candidate content, which still must sequentially undergo frontier identification, structure recall, recursive gating, and independent verification. The existing physical examination general inspection business procedure can be summarized into five types of procedural actions: entry reception, pre-normalization, local candidate retrieval, rule formation, and candidate merging. The result of pre-normalization enters the compilation and verification of the initial graph of the physical examination object; the output of local candidate retrieval only serves as the candidate source after deterministic hard filtering; cross-source merging first forms the incremental candidate physical examination object graph, which is then verified and versioned by the independent graph execution component. Thus, the existing business procedure undertakes data access and candidate calculation, while the method of this embodiment undertakes graph structure constraints, candidate isolation, and submission control; the responsibilities of both are clear. Existing fields include object identifier, inspection item, result, unit, reference range, prompt, and source. Structural constraints, source tracing, candidate isolation, and atomic commit are added without changing business inputs and outputs. When organizational rules and conditional branches grow in the future, only the affected frontier can be rebuilt, reducing the duplication of irrelevant objects and clearly distinguishing between fixed points and the stopped state of recalculable resources.

[0056] Example 2

[0057] This embodiment further explains the formation of finite type meta-graphs and initial graphs of physical examination subjects, specifically including the following steps.

[0058] S1.1. Configure the set of node types for the original observation node, discovery node, restriction node, conflict node, and synthesis node;

[0059] Each node type in the node type set includes a type identifier, attribute pattern, allowed status, and source requirements. Original observation nodes store the collected data and source index; discovery nodes store structured discoveries derived from the original observation nodes by deterministic rules; restriction nodes are subject to constraints such as missing records, temporal incompatibility, or source limitations; conflict nodes record candidate relationships that cannot be simultaneously valid in the same confirmation branch; and synthesis nodes carry verified, hierarchical combination results.

[0060] S1.2. Configure the ordinary edge type, directed hyperedge signature, node level, node state, applicable conditions for relation signature, maximum node depth, and allowed state transitions for each node type to obtain the finite type metagraph;

[0061] Ordinary edges are suitable for expressing single-source, constraint, or version relationships; directed superedge signatures are suitable for expressing compositional relationships where at least two source roles jointly form a target node. Allowed state transitions can be limited to predefined directed transitions within the "pending—candidate—committed—invalid" range. Invalidated objects are not allowed to be directly restored to a committed state; instead, they must re-enter the frontier through a new version node.

[0062] S1.3. Compile the collected physical examination data into original observation nodes that conform to the finite type metagraph, and form corresponding discovery nodes, source edges and restriction edges according to the deterministic discovery rules;

[0063] The graph compilation component normalizes field names, data types, units, collection time, and source identifiers, and writes the normalization results into the corresponding original observation nodes. Deterministic discovery rules are rules that derive discovery nodes from original observation nodes based on preset field conditions, and output the same results under the same input and rule version. Deterministic discovery rules only process structured states that can be derived from explicit field conditions. The rule output carries the input node identifier, rule version, and execution time, facilitating the independent graph execution component's traceability of the formation basis.

[0064] S1.4. Perform consistency checks on the object identifier, examination cycle, time interval, location, side, and source of the formed nodes and relationships to obtain the initial image of the examination object.

[0065] When consistency checks are not met, the corresponding node is retained as a restricted input or becomes a restricted node, instead of directly deleting the original data. This process enables subsequent frontier tasks to identify data gaps and constraints, while avoiding combining data from different objects, different periods, or incompatible parts into the same target node.

[0066] Example 3

[0067] like Figure 3 As shown, this embodiment illustrates the local complexity evaluation with hard gate conditions, specifically including the following steps.

[0068] S4.1. For each restricted local subgraph, extract the number of source types, cross-disciplinary span, number of missing roles, number of conflicting roles, expected target level span, and upper bound of candidate combinations to obtain the local complexity vector;

[0069] The number of source types reflects the number of source categories participating in the current relationship formation; the cross-subject span can be obtained from the versioned distance table between the inspection categories to which the sources belong; the number of missing forming roles is obtained by subtracting the currently satisfied role set from the set of necessary roles required for the relationship signature; the number of conflicting roles is counted as mutually exclusive sources that are still in the valid time interval and point to the same target role; the expected target level span represents the difference from the current highest source node level to the planned target level; the upper bound of the candidate combination can be obtained by multiplying the number of valid candidates of each necessary role and truncating it with an upper limit.

[0070] S4.2. When the number of missing roles reaches the missing role threshold, the number of conflicting roles reaches the conflicting role threshold, or the expected target level span reaches the cross-level dependency threshold, a recursive decomposition identifier is generated.

[0071] The three hard gate conditions are logically ORed, and if any one of the conditions is true, the weighted judgment is skipped. The missing role threshold can be configured to 1, indicating that if any necessary role is missing, a supplementary or restricted subtask will be formed first; the conflicting role threshold can be configured to 2, indicating that if there are at least two mutually exclusive sources of the same forming role, the conflict will be resolved first; the cross-layer dependency threshold can be set according to the direct forming span allowed by the metagraph. The thresholds are stored in the versioned configuration and recorded with the front-end fingerprint, so that the same configuration and graph state can reproduce the same gating results.

[0072] S4.3. When the missing role threshold, the conflicting role threshold, and the cross-layer dependency threshold are not triggered, a direct generation identifier or a recursive decomposition identifier is generated based on the comparison results of the local complexity vector with the versioned direct processing domain and the recursive processing domain.

[0073] For local subgraphs that do not trigger hard gates, the weighted complexity is calculated after transforming each complexity component to the same numerical range. The weighted complexity can be expressed as equation (1):

[0074] Equation (1)

[0075] in, This represents the weighted complexity of the current restricted local subgraph; Indicates the number of local complexity components; Indicates the first The versioning weights of each local complexity component are given, and the sum of the versioning weights is 1. Indicates the first The local complexity components are version-normalized values. The versioning directly processes the domain as follows: For intervals not greater than the first boundary, the recursive processing domain can be set as follows: The interval is greater than the second boundary; tasks located between the two boundaries can select a processing branch based on the historical verification failure rate of the target relation signature. Boundaries are defined by offline replay data and saved along with the configuration version. A direct generation flag indicates that the corresponding restricted local subgraph is processed as a direct generation task, while a recursive decomposition flag indicates that the corresponding restricted local subgraph enters recursive decomposition.

[0076] Because hard gate conditions directly capture missing roles, activity conflicts, and cross-layer dependencies, and do not depend on the size of local nodes, tasks with a limited number of nodes but concentrated structural risks will not be masked by weighted averaging; weighted judgment is only responsible for handling continuous complexity differences that have not triggered hard gates, thus forming a hierarchical control between risk constraints and operational overhead.

[0077] Example 4

[0078] This embodiment describes the recursive decomposition and nested sub-front execution based on embodiment 3, specifically including the following steps.

[0079] S4.3.1. Perform version normalization on the components with different dimensions in the local complexity vector to obtain the normalized complexity components;

[0080] Normalization parameters are generated from historical playback samples under the same institutional configuration version, and the impact of outliers on the scale is limited by truncation of extreme values ​​or quantile boundaries. If a component lacks sufficient historical samples, linear normalization can be performed using the upper and lower bounds given by the metagraph configuration, and the source of normalization is recorded in the task audit information.

[0081] S4.3.2. Calculate the weighted complexity based on the normalized complexity components and their corresponding complexity weights, and determine the direct generation identifier or the recursive decomposition identifier based on the versioned direct processing domain or the recursive processing domain in which the weighted complexity is located;

[0082] Complexity weights are bound to the target relation signature, and the same relation signature uses the same weight within the same configuration version. A hysteresis interval can be set between the direct processing domain and the recursive processing domain. Tasks that have entered recursive processing will only return to direct processing when the complexity decreases to a low return boundary, in order to avoid repeated switching near the boundary.

[0083] S4.3.3. Based on the recursive decomposition identifier, the corresponding restricted local subgraphs are split according to organ system, formation role, and dependency direction to obtain the sub-frontier task;

[0084] When splitting, priority is given to keeping candidate objects with the same essential role in the same subtask, and common constraint nodes are copied as read-only contexts. Cross-category objects are configured to predecessor or successor subtasks according to the dependency direction. The copied read-only context does not generate new node identifiers and is not counted as a committed intermediate target.

[0085] S4.3.4. Based on the input and output roles between the sub-front tasks, establish directed dependency edges, delete duplicate dependency edges and reject dependency edges that form directed cycles, to obtain a nested sub-front directed acyclic graph;

[0086] When constructing dependency edges, the connection condition is whether the target role of one subtask satisfies the necessary input role of another subtask. Incremental topology checks are performed before adding a dependency edge; if adding a dependency edge would form a directed cycle, the dependency edge is rejected and the involved subtasks are merged into a conflict resolution task, or the corresponding relationship is written to a constraint node for processing in subsequent data versions.

[0087] S4.3.5. Define the recursion depth, number of subtasks, and target level of the nested sub-front directed acyclic graph according to the finite type metagraph, and mark the subtasks that have reached the defined boundaries but have not yet been completed as incomplete task keys;

[0088] The upper limit of recursion depth, the upper limit of the number of subtasks in a single nested graph, and the upper limit of allowed target levels together constitute the termination boundary. Reaching the termination boundary does not mean that a fixed point has been formed; unfinished task keys are retained, carrying the most recently committed graph version and the frontier fingerprint.

[0089] S4.3.6. Process the sub-front tasks in the nested sub-front directed acyclic graph according to the topological order, and only provide the intermediate targets submitted by the independent graph execution component to the successor sub-front tasks.

[0090] The scheduler can process child frontier tasks without dependencies in parallel, but tasks with dependencies must wait for their predecessors to complete verification and commit. Candidate intermediate targets are stored in the candidate view and do not enter the confirmation input of subsequent tasks; only the new graph version nodes generated after the commit can be read by subsequent tasks. This isolation prevents local errors in the recursive process from amplifying along the dependency chain into the final graph state.

[0091] In one example, the maximum recursion depth is set to 3, and the maximum number of subtasks in a single nested graph is set to 12. A local task that checks sources across three categories triggers a hard gate due to a missing forming role. The system then splits the task into three subtasks: source integrity processing, conflict relationship processing, and target formation. After source integrity processing forms and submits a constraint node, the target formation task reads the constraint node and generates candidate targets with constraint states. If there are still incomplete tasks at the third level, they are saved as incomplete task keys without outputting fixed points.

[0092] Example 5

[0093] This embodiment describes the separation of topology planning and complete candidate increment generation, specifically including the following steps.

[0094] S5.1. For the directly generated task or the nested sub-frontier, only the source node role combination, target node type, target level and necessary dependencies are generated to obtain the topology plan set;

[0095] Topology plans do not contain complete natural language attributes; they only reference source node identifiers, target type identifiers, target levels, and necessary dependencies. Therefore, they can be generated and cached in batches as structured objects. Topology plans with identical structure fields under the same task key have the same plan fingerprint after normalization and sorting, which can be used for deduplication.

[0096] S5.2. Perform relationship signature, object identifier, hierarchy, status permissions, and hard conflict pre-checks on the set of topology plans, and delete the topology plans that fail the pre-checks;

[0097] The relationship signature preflight checks the number of source roles and the target type; the object identifier preflight prevents cross-object composition; the hierarchy preflight checks for directly forming spans; the status and permission preflight prevents invalid nodes from acting as activity sources; and the hard conflict preflight checks whether mutually exclusive relationships are simultaneously established in the same confirmation branch. The preflight process only reads the structure fields and does not need to generate complete node content.

[0098] S5.3. Based on the plan novelty, source completeness, expected relation signature coverage gain, and historical valid commit rate, form an executable topology plan queue;

[0099] Plan novelty measures the difference between the plan fingerprint and the existing structure in the current graph; source completeness measures the proportion of necessary roles satisfied; expected relation signature coverage gain measures the number of unprocessed signatures that can be completed after executing the plan; historical valid commit rate is calculated separately for relation signatures and configuration versions. The aforementioned metrics are only used for queue sorting and do not replace the legality judgment of independent graph execution components. The executable topology plan queue consists of topology plans that have passed the pre-check, arranged according to the sorting results of the aforementioned metrics.

[0100] S5.4. Based on the executable topology plan queue and the total round budget, a frontier budget allocation table is formed, and node attributes, edges, directed super edges, and direct dependencies are generated only for the topology plans that have obtained candidate slots, to obtain the candidate physical examination object graph increment.

[0101] A candidate slot is a resource quota for generating a complete candidate increment. The generator reads the topology plan constraints and the corresponding restricted local subgraph, and can only propose node attributes, edges, directed superedges, and direct dependencies allowed in the metagraph. At least one candidate slot can be configured for the same topology plan to generate different candidate instances that all satisfy the structural constraints; the specific number of slots is determined by the budget allocation process described in Example 6.

[0102] Example 6

[0103] like Figure 4 As shown, this embodiment illustrates the candidate budget allocation under coverage constraints, specifically including the following steps.

[0104] S5.4.1. Count the relation signatures that have not yet been processed in the current complete round to obtain the set of unprocessed relation signatures;

[0105] The processing results include submitted valid increments and results that have been pre-checked or verified to have no valid increments under the current graph version. Results that only generate a topology plan but have not yet obtained execution slots are not included in the processing results; the corresponding relation signatures remain in the unprocessed relation signature set.

[0106] S5.4.2. Count the consecutive waiting rounds of each topology plan in the executable topology plan queue, and add the topology plan that has reached the maximum waiting rounds to the forced execution set;

[0107] The enforced set consists of topology plans in the executable topology plan queue that have reached the maximum waiting rounds and have not yet obtained a processing result, wherein each topology plan has obtained at least one guaranteed waiting slot in the current round. The consecutive waiting rounds are reset to zero when a topology plan obtains at least one candidate slot, and incremented by one when a complete round ends without obtaining a candidate slot. The maximum waiting rounds can be configured according to the relation signature type; rare relation signatures can be set with a shorter maximum waiting round to avoid continuous delays caused by insufficient historical samples.

[0108] S5.4.3. Allocate at least one cover spare slot for each relation signature in the unprocessed relation signature set, and allocate at least one wait spare slot for each topology plan in the enforcement set;

[0109] When a topology plan simultaneously meets both the coverage guarantee and waiting guarantee conditions, the same candidate slot is reused, and both allocation reasons are recorded to avoid duplicate budget deductions. When the total budget for a round is insufficient to cover all guaranteed slots, this round is marked as a resource stop round. Existing slots are allocated according to the deterministic order of waiting rounds and relation signatures, and the remaining tasks retain an incomplete state. A resource stop round indicates that the current round's budget is insufficient to cover all guaranteed slots, and is distinct from the resource stop result that is the output of the run's termination.

[0110] S5.4.4. Subtract the coverage guarantee slot and the waiting guarantee slot from the total budget of the round to obtain the number of flexible slots;

[0111] The total budget for each round can be configured based on the number of candidates, the number of tokens generated, computation time, or a combination of the aforementioned resources. For ease of replay, the budget allocation table also records the total budget, the minimum budget used, the flexible budget, and the budget unit of measurement.

[0112] S5.4.5. Calculate the expected commit gain for each remaining topology plan based on the current conflict intensity, the number of uncovered relation signatures, the planned gains, and the historical valid commit rate;

[0113] The remaining topology plan refers to the topology plan in the executable topology plan queue that has not yet obtained a guaranteed coverage slot or is waiting for a guaranteed slot in the current round; the plan revenue is used to measure the expected output of executing a single topology plan, and can be determined based on the expected number of new relationships, the expected number of new nodes, or the expected relationship signature coverage gain. The expected commit revenue gain can be expressed as Equation (2):

[0114] Equation (2)

[0115] in, Indicates the first The projected contribution gain for each remaining topology plan; Configuration coefficients representing the current conflict intensity; Indicates the first The normalized value of the current conflict intensity of each remaining topology plan; A configuration coefficient representing the number of uncovered relation signatures; Indicates the first The normalized value of the number of uncovered relation signatures that each remaining topology plan can handle; The allocation coefficient representing the planned returns; Indicates the first Normalized value of the planned revenue of each remaining topology plan; A configuration coefficient representing the historical effective commit rate; Indicates the first The historical valid commit rate of each remaining topology plan under the corresponding relation signature and configuration version. , , and All are non-negative numbers and their sum is 1.

[0116] The current conflict intensity is not used to reward the conflict itself, but to provide resilient resources for local structures that require more candidate exploration; if the number of historical samples of a certain relation signature does not reach the statistical threshold, the historical valid submission rate adopts a versioned prior value and is marked as a prior estimate in the budget allocation basis.

[0117] S5.4.6. Allocate the elastic slots according to the sorting of the expected submitted revenue gains, and record the allocation basis of each candidate slot to obtain the frontier budget allocation table;

[0118] When two topology plans have the same expected delivery gain, they are sorted sequentially by waiting round, number of uncovered relationship signatures, and plan fingerprint to ensure a consistent replay result. Elastic slots can be allocated in batches using a round-robin approach. After each allocation, the queue is updated based on the latest pre-check or verification feedback, but already allocated guaranteed slots cannot be reclaimed. Allocation criteria records the slot type, the value of the underlying metric, and whether it is a priori estimate, for auditing and replay purposes.

[0119] The frontier budget allocation table consists of a budget summary section and a candidate slot details section. The budget summary section records the total budget for each round, the used minimum budget, and the remaining flexible budget, all measured in budget units. Each row in the candidate slot details section corresponds to an allocated candidate slot, recording the plan fingerprint and source relationship signature of the topology plan that obtained the candidate slot, the slot type, the expected delivery gain value, and whether it is a priori estimate. The following diagram illustrates a schematic structure of a frontier budget allocation table.

[0120] FP-21 Relationship signature F1 Coverage Guarantee not applicable no FP-35 Relationship signature F2 Waiting for a guaranteed minimum not applicable no FP-42 Relationship Signature F1 elasticity 0.62 no FP-48 Relationship Signature F3 elasticity 0.37 yes

[0121] The planned fingerprints, relationship signatures, and values ​​in the table are for illustrative purposes only. Rows with slot types of "covered guarantee" and "awaiting guarantee" are written during the guarantee allocation phase and do not participate in elastic sorting; rows with slot type of "elastic" are written sequentially according to the expected submission benefit gain, and when there are ties in the sorting, the order is determined by the waiting round, the number of uncovered relationship signatures, and the order of planned fingerprints.

[0122] S5.4.7. Retain the tasks corresponding to the topology plans that have not obtained candidate slots as incomplete task keys, and prohibit the determination of fixed point establishment when the incomplete task keys exist.

[0123] The phrase "prohibit inclusion in the fixed-point condition" here means that the fixed-point condition is not met when any incomplete task key exists, rather than ignoring the incomplete task keys. Therefore, even if the flexible budget favors tasks expected to yield greater returns, the relationship signature coverage guarantee, maximum waiting rounds, and incomplete task keys collectively prevent rare tasks from being continuously shelved or incorrectly considered saturated.

[0124] Example 7

[0125] This embodiment describes deterministic hard filtering and branch-aware heterogeneous graph state encoding, specifically including the following steps.

[0126] S3.1. Based on the object identifier, physical examination cycle, time compatibility condition, location, side and relation signature of the finite type metagraph, perform deterministic hard filtering on the objects associated with the extended task set to obtain a legitimate compatibility candidate pool;

[0127] Hard filtering is performed based on non-learnable Boolean conditions, with each exclusion result carrying a condition identifier and a summary of the input values. Time compatibility conditions can be determined by checking whether time intervals overlap, whether they are within the same health check period, or whether they meet the time window declared for the rule segment. The candidate pool after hard filtering contains only objects that are structurally allowed to participate in the current relation signature.

[0128] S3.2. Construct a confirmed view consisting of committed nodes and a candidate view consisting of candidate nodes and readable committed nodes, respectively;

[0129] The confirmed view is based on the current committed graph version and contains only nodes and relationships that are committed and valid in the current time interval. Candidate views are constructed by candidate source branches. Each candidate source branch can read a read-only snapshot of the confirmed view, but candidate nodes are not written back to the read-only snapshot.

[0130] S3.3. In the confirmed view and the candidate view, initialize node features according to node type, and perform relationship-aware message passing according to forming relationship, restrictive relationship, contradictory relationship and version relationship respectively to obtain branch state vector;

[0131] The initial features of a node can be formed by concatenating node type embedding, state embedding, source category embedding, time interval encoding, and structural statistics. Different message transformation parameters are used for different relationship types to ensure that forming relationships, restrictive relationships, contradictory relationships, and version relationships have a distinguishable structural impact on the target node state. See Example 8 for specific message passing and branch isolation methods.

[0132] S3.4. Match the branch state vector with the versioned rule fragment vector and the candidate node structure vector, and form a structure-aware recall ranking based on the matching results;

[0133] The rule fragment vector is formed by encoding the rule signature, necessary roles, applicable level, state conditions, and semantic description, and is bound to the rule version. Matching can be implemented using vector inner product, cosine similarity, or a trained matching network. In other implementations, path template-based structural matching can be used instead of vector matching, as long as it is still performed after hard filtering and the confirmation permissions are not changed.

[0134] S3.5. Select a preset number of candidate objects based on the structure-aware recall ranking, and attach hard-filtered evidence, recall score and branch identifier to obtain the restricted local subgraph set.

[0135] The preset quantity can be set according to relation signatures and task categories, and is constrained by the upper limit of the number of input tokens or nodes. Hard filtering evidence records the various filtering conditions and corresponding input values ​​that candidate objects pass. The recall score is the matching score in the structure-aware recall ranking, and the branch identifier indicates the candidate source branch to which the candidate object belongs. In addition to the selected candidate objects, the restricted local subgraph also retains the necessary paths connecting the frontier objects and candidate objects, activity restriction nodes, and version nodes for subsequent complexity gating and topology plan generation.

[0136] Example 8

[0137] like Figure 5 As shown, this embodiment describes the message passing of branch-aware heterogeneous graphs, specifically including the following steps.

[0138] S3.3.1. Set a confirmation branch mask for the confirmed view, and set a candidate branch mask for each candidate source branch in the candidate view;

[0139] The branch mask is stored together with the node state and candidate source identifier. The confirmation branch mask only covers committed nodes; the candidate branch mask covers candidate nodes of the corresponding candidate source branch as well as allowed copies of committed nodes. A candidate node belongs to only one candidate source branch, avoiding the accumulation of weights across branches for the same provisional state.

[0140] S3.3.2. When encoding the confirmed view, only committed nodes are allowed to pass messages along the forming relationship, the restricting relationship, the contradictory relationship, and the version relationship, and messages sent by candidate nodes are blocked;

[0141] The encoder removes incoming edges from candidate nodes when constructing the adjacency list of the confirmation view, so candidate nodes cannot enter the message aggregation of the confirmation view even if they are stored in the same physical graph storage. This isolation is performed before feature computation and does not depend on whether the trained weights are close to zero.

[0142] S3.3.3. When encoding the candidate view, candidate nodes are allowed to read messages from committed nodes, while candidate nodes from different candidate source branches are prohibited from sending messages to each other;

[0143] Each candidate view constructs an adjacency subgraph using the corresponding candidate branch mask. Committed nodes participate in message passing with read-only anchors, and messages sent by candidate nodes only propagate within the same candidate source branch. If two candidate source branches share the same committed node, the committed node creates read-only representations in both candidate views, and the aggregate state is not written back to each other.

[0144] S3.3.4. Aggregate the messages of adjacent nodes according to the relationship type, and combine the aggregation results with the current node features to obtain the confirmed node structure vector and the candidate node structure vector;

[0145] A relation-aware message passing mechanism can be represented by equation (3):

[0146] Equation (3)

[0147] in, Represents a node In the The node structure vector after layer message passing; Indicates the target node for receiving the message; Indicates the message passing layer sequence number; Represents a nonlinear activation function; Indicates the first Layer bias vector; This represents the set of relation types consisting of constructive, restrictive, contradictory, and versionary relations. This represents one of the relation types in the set of relation types; Indicates by relation type With the target node The set of adjacent nodes that satisfy the current branch mask; Represents adjacent nodes in the node set; Represents the target node Regarding relation types Message normalization factor; Indicates the first Layers based on relation types The message transformation matrix; Indicates adjacent nodes In the Layer node structure vector. Branch mask is defined by... This confirms that the set of adjacent nodes in the view does not contain candidate nodes, and there are no available candidate node adjacent edges between the two candidate source branches.

[0148] S3.3.5. Perform pooling on the confirmed node structure vector to obtain the confirmed branch state vector, and perform pooling on the candidate node structure vectors with the same candidate branch mask to obtain the candidate branch state vectors respectively;

[0149] Pooling can employ attention-weighted aggregation, mean aggregation, or aggregation by node type followed by concatenation. Attention weights are normalized only within the set of nodes covered by the current branch mask. In other implementations, deterministic structural fingerprints based on relational path counts can be used instead of learned pooling to provide a structural state representation independent of training data.

[0150] S3.3.6. When performing structure-aware recall sorting, the confirmation branch state vector is used to control the formal frontier recall, and the candidate branch state vector is used only for the internal sorting of the corresponding candidate source branch;

[0151] The formal frontier recall determines which submitted objects and rule fragments can enter the subsequent restricted local subgraph, therefore only the confirmation branch state vector is read. The candidate branch state vector is only ranked within the branch after the corresponding candidate source branch has been selected, without changing the weight of other branches or the confirmation view.

[0152] S3.3.7. Write the branch mask and message source record into the recall audit record so that the independent graph execution component can verify the candidate isolation status.

[0153] The recall audit log should include at least the graph version number, front fingerprint, branch identifier, node identifier summary, allowed message direction, number of masked edges, encoder version, and rule version. The independent graph execution component can check and confirm whether candidate message sources exist in the view; if inconsistent branch masks or cross-candidate branch messages are found, the corresponding candidate increment is rejected from entering the versioned commit process.

[0154] Example 9

[0155] This embodiment describes candidate verification, versioned submission, fixed points, and resource stopping, specifically including the following steps.

[0156] S6.1. Verify the node type, relation signature, data source, object identifier, level, loop, activity conflict, and state transition permission of the incremental graph of the candidate physical examination object to obtain the candidate processing result;

[0157] Verification is performed in a deterministic order. If a previous verification item fails, the reason for the failure is recorded, and subsequent verifications dependent on that item can be skipped. For directed hyperedges, relation signature verification also includes source role cardinality, necessary role completeness, and target type consistency. Candidate processing results include three states: passed, rejected, or awaiting supplementary input.

[0158] S6.2. Perform an atomic commit with the baseline graph version number on the incremental candidate physical examination object graph that has passed the verification, and write the new nodes, the basis for formation and the state changes into the updated physical examination object graph;

[0159] Before committing, compare the baseline graph version number with the current graph version number; if they are inconsistent, re-execute the affected conflict and state permission verification. An atomic commit simultaneously writes nodes, edges, directed superedges, source indexes, and audit logs. If any write fails, the increment is rolled back, and no partially visible state is generated.

[0160] S6.3. Generate the next round of expansion tasks based on the newly added nodes, the formation basis, and the state changes, and calculate the graph state hash and relation signature saturation vector;

[0161] Graph state hashing is calculated based on normalized sorted committed node identifiers, relation identifiers, node states, and configuration versions. Each component of the relation signature saturation vector corresponds to an applicable relation signature, with values ​​including unprocessed, committed increments, and no valid increments in the current version. Candidate states do not participate in the formal graph state hashing.

[0162] S6.4. The fixed point is generated when there are no committable increments in the complete round covering all applicable relation signatures, the task queue of the extended task set is empty, the graph state hash remains unchanged, and the relation signature saturation vector indicates that all applicable relation signatures have been processed;

[0163] A complete round begins when the set of applicable relation signatures for the current graph version is established and ends when every relation signature in the set has been processed. If any valid increment is submitted during a round, the graph version changes and the next complete round begins; the fixed point condition is only met if there are no commits and the task queue is empty during a single complete round.

[0164] S6.5. When the candidate slot, recursion depth, number of subtasks, or runtime reaches the resource limit and there are still unfinished task keys, generate the resource stop result and save the graph version, front fingerprint, and unfinished task keys required for continued computation.

[0165] Resource termination results use different status codes than fixed points. Upon resumption, the system loads the saved graph version, leading-edge fingerprint, and incomplete task keys, checks the configuration version, and continues allocating backup slots; if the configuration version changes, a new leading-edge fingerprint is generated for the affected tasks, and a pre-check is performed again. This design ensures that budget exhaustion only indicates the end of the current running window, not that all executable local states have been processed.

[0166] like Figure 6As shown in the diagram, this embodiment illustrates the data and control transfer relationships between graph state management, frontier and candidate processing, and independent verification in the form of an activity graph. The graph state management entity maintains the submitted state and collected examination data, provides standardized data and benchmark information to the graph initialization stage, and provides object identifiers, examination cycles, and benchmark identifiers to the frontier formation stage. The frontier and candidate processing stages sequentially execute frontier formation, structure recall, recursive gating, and candidate generation, writing candidate graph increments into the candidate area without writing them into the submitted view. The independent graph execution stage receives candidate increments and verifies their source, uniqueness, structure, and processing status. If verification is successful and the processing benchmark is consistent, the increment is submitted, forming a new submitted state; if verification fails, the increment is rejected or recalculated. After submission, the next round of pending frontiers is formed, and processing continues until the fixed point condition is met, or until resources are exhausted, the recalculation-ready state is saved, and a resource stop result is formed. Candidate results must not be written into the submitted view before verification is successful and the processing benchmark is consistent. The function and class names appearing in the diagram are taken from the reference implementation. For example, the report state class maintains the graph state, the workflow construction function orchestrates the frontier and candidate processing, the evidence context verification function performs independent verification, the condition graph asynchronous evaluation method CompiledStateGraph.ainvoke() determines whether the verification passes and the processing benchmark are consistent, the failure report assembly function takes over the failed branches, and the report assembly function forms a new committed state. These are only examples of engineering implementation and do not change the node types, relationship types, processing steps or termination conditions defined in this embodiment.

[0167] Example 10

[0168] like Figure 7 As shown, this embodiment provides a front-end driven self-growth system for physical examination object maps, including the following modules.

[0169] The graph initialization module configures a finite-type metagraph with defined node types, relationship types, levels, states, and maximum depths. It generates an initial graph of the physical examination subjects based on the collected physical examination data. Deployed in the graph compilation or initialization service, the loaded finite-type metagraph pre-defines the set of node types for original observation nodes, discovery nodes, restricted nodes, conflict nodes, and comprehensive nodes, as well as the types of ordinary edges, directed hyperedge signatures, node levels, node states, applicable conditions for relationship signatures, maximum node depth, and allowed state transitions for each node type. The module normalizes the field names, data types, units, collection time, and source identifiers of the collected physical examination data. It compiles the normalization results into original observation nodes conforming to the finite-type metagraph, forms discovery nodes, source edges, and restricted edges according to deterministic discovery rules, and performs consistency checks on the formed nodes and relationships for object identifiers, physical examination cycles, time intervals, body parts, sides, and sources. Nodes that fail the checks are retained as restricted inputs or become restricted nodes without deleting the original data. This yields the initial graph of the physical examination subjects, providing a type-constrained graph foundation for subsequent extended tasks.

[0170] The frontier formation module is used to identify newly added objects, objects with changed states, and unsaturated objects based on the initial or updated graph of the physical examination objects, forming a set of extension tasks with frontier fingerprints. Deployed in the task scheduling service, the frontier formation module takes the graph version number, node status, and relation signature processing progress recorded in the graph storage as input. For each object to be extended, it constructs a frontier fingerprint composed of the graph version number, target node identifier, relation signature identifier, node status summary, and applicable rule version. Idempotent merging is performed on extension tasks with the same frontier fingerprint under the same graph version. A new frontier fingerprint is generated when a node changes from a provisional state to a committed state or when the activity state of a restricted relation changes. An unsaturated object is an object for which at least one applicable relation signature has not yet been processed. Processed results include both submitted legitimate increments and deterministic results with no legitimate increments under the current evidence. The set of extension tasks output by the frontier formation module carries the frontier fingerprint and applicable relation signatures, which are used by the structure recall module to screen legitimate and compatible candidates and construct restricted local subgraphs, ensuring that subsequent extensions always start from the current committed graph state and remain reproducible.

[0171] The structure recall module performs deterministic hard filtering and branch-aware heterogeneous graph state encoding on the extended task set to obtain a restricted local subgraph set. Deployed on the encoder of the candidate generation service, the structure recall module first performs non-learnable Boolean conditional hard filtering on the objects associated with the extended task set based on object identifiers, examination cycles, time compatibility conditions, location, side, and relational signatures of the finite type metagraph, obtaining a legitimate compatible candidate pool. Then, it constructs a confirmation view composed of submitted nodes and a candidate view composed of candidate nodes and readable submitted nodes. Under the constraints of confirmation branch masks and candidate branch masks, it initializes node features according to node type and performs relation-aware message passing according to forming relationships, restrictive relationships, contradictory relationships, and version relationships, obtaining branch state vectors. The structure recall module matches the branch state vectors with versioned rule fragment vectors and candidate node structure vectors to form a structure-aware recall ranking. It selects a preset number of candidate objects and attaches hard filtering evidence, recall scores, and branch identifiers to obtain a restricted local subgraph set, enabling multi-hop structural relationships to participate in the recall while candidate node messages do not enter the confirmation view.

[0172] The recursive gating module performs a hard-gated local complexity evaluation on the set of restricted local subgraphs, dividing the restricted local subgraphs into directly generated tasks or nested subfronts with directed acyclic dependencies. Deployed in the gating component of the task scheduling service, the recursive gating module extracts the number of source types, cross-disciplinary span, number of missing roles, number of conflicting roles, expected target level span, and upper bound of candidate combinations for each restricted local subgraph, obtaining a local complexity vector. Direct generation is performed when the number of missing roles reaches the missing role threshold, the number of conflicting roles reaches the conflicting role threshold, or the expected target level span reaches the cross-dependency threshold. Recursive decomposition identifiers are generated. When the hard gate condition is not triggered, versioning normalization is performed on the different dimensional components of the local complexity vector and the weighted complexity is calculated. The direct generation identifier or recursive decomposition identifier is determined based on the comparison result of the versioned direct processing domain and the recursive processing domain. When recursive decomposition is triggered, the recursive gating module splits the sub-frontier tasks according to organ system, forming role and dependency direction, establishes directed dependency edges and refuses to form directed cycles, limits the recursion depth, number of sub-tasks and target level, marks the sub-tasks that have reached the limit boundary but have not yet been completed as incomplete task keys, and processes nested sub-frontiers according to topological order, only providing intermediate targets submitted by the independent graph execution component to the successor sub-frontier tasks.

[0173] The candidate generation module is used to generate topology plans for the directly generated task or the nested sub-frontier. After pre-checking, candidate slots are allocated according to relation signature coverage constraints and expected submission benefit gains, and candidate health check object graph increments are generated. The candidate generation module is deployed on the candidate generation service and only has write permissions for candidate views. The candidate generation module first generates only topology plans containing source node role combinations, target node types, target levels, and necessary dependencies. It performs relation signature, object identifier, level, status permissions, and hard conflict pre-checks on the topology plans and deletes topology plans that fail the pre-check. Then, it calculates the topology plans based on plan novelty, source completeness, and expected dependencies. The signature coverage gain and historical valid submission rate form an executable topology plan queue; the candidate generation module forms a frontier budget allocation table according to the total budget of each round, allocates coverage guarantee slots for relation signatures that have not yet obtained processing results in the current complete round, allocates waiting guarantee slots for topology plans that have reached the maximum waiting round, and allocates remaining elastic slots according to the order of expected submission benefit gain and records the allocation basis of each candidate slot; only for topology plans that have obtained candidate slots, node attributes, edges, directed super edges and direct dependencies are generated to obtain the candidate physical examination object graph increment, and the tasks corresponding to topology plans that have not obtained candidate slots are retained as incomplete task keys.

[0174] The verification convergence module is used to verify and version the submitted graph increments of the candidate physical examination objects through the independent graph execution component, update the frontier, and determine the fixed point or resource stopping result based on the graph state changes of the complete round. The verification and convergence module is deployed on an independent graph execution service and has the authority to confirm view submissions. It uses different access credentials and submission interfaces than the candidate generation service, maintaining the separation of permissions between candidate generation and confirmation submissions at the deployment level. The verification and convergence module verifies the node type, relation signature, data source, object identifier, level, loop, activity conflict, and state transition permissions of the candidate health check object graph increments in a deterministic order. For increments that pass verification, it performs atomic submissions with the baseline graph version number, writes the new node, formation basis, and state change into the updated health check object graph, and generates the next round of expansion tasks and computation graph state hash and relation signature saturation vector. When there are no increments to submit in a complete round covering all applicable relation signatures, the task queue of the expansion task set is empty, the graph state hash remains unchanged, and the relation signature saturation vector indicates that all applicable relation signatures have been processed, the fixed point is determined to be valid. When the candidate slot, recursion depth, number of subtasks, or runtime reaches the resource limit and there are still unfinished task keys, a resource stop result is generated, and the graph version, leading edge fingerprint, and unfinished task keys required for continued computation are saved.

[0175] The graph initialization module, front formation module, structure recall module, recursive gating module, candidate generation module, and verification and convergence module can be implemented by one or at least two processors executing computer programs in memory, or they can be deployed in interconnected graph compilation service, task scheduling service, candidate generation service, and independent graph execution service. The candidate generation service only has write permissions for candidate views, while the independent graph execution service has commit permissions for confirming views. The two use different access credentials and commit interfaces to maintain the separation of permissions between candidate generation and commit confirmation at the deployment level.

[0176] Those skilled in the art will understand that the aforementioned methods can be implemented by a computer program. When the computer program is executed by a processor, it causes the processor to perform the methods described in any of the foregoing embodiments; the computer program can be stored in a non-transitory computer-readable storage medium. The division of modules is used to illustrate functional relationships; without changing the module inputs, processing, and outputs, they can be deployed in a combined or distributed manner.

Claims

1. A frontier-driven self-growth method for physical examination object maps, characterized in that, The frontier refers to the range of objects in the currently submitted medical examination object map that can trigger subsequent expansion, including: Configure a finite type metagraph with limited node types, relationship types, levels, states, and maximum depth, and generate an initial graph of the physical examination objects based on the collected physical examination data; Based on the initial or updated image of the physical examination subjects, newly added objects, objects with changed states, and unsaturated objects are identified to form an extended task set with leading-edge fingerprints; Perform deterministic hard filtering and branch-aware heterogeneous graph state encoding on the extended task set to obtain a restricted local subgraph set; Perform a local complexity evaluation with hard gate conditions on the set of restricted local subgraphs, and divide the restricted local subgraphs in the set of restricted local subgraphs into direct generation tasks or nested subfronts with directed acyclic dependencies; For the directly generated task or the nested sub-front generation topology plan, after pre-examination, candidate slots are allocated according to relation signature coverage constraints and expected submission benefit gains, and candidate physical examination object graph increments are generated. The independent graph execution component verifies and version submits the legal candidate physical examination object graph increment, updates the frontier, and determines the fixed point or resource stopping result based on the graph state changes of the complete round.

2. The method according to claim 1, characterized in that, The configuration defines a finite-type metagraph with limited node types, relationship types, levels, states, and maximum depths, and generates an initial graph of the physical examination subjects based on the collected physical examination data, including: Configure the set of node types for original observation nodes, discovery nodes, restriction nodes, conflict nodes, and comprehensive nodes; Configure the ordinary edge type, directed hyperedge signature, node level, node state, applicable conditions for relation signature, maximum node depth, and allowed state transitions for each node type to obtain the finite type metagraph; The collected physical examination data is compiled into original observation nodes that conform to the finite type metagraph, and corresponding discovery nodes, source edges, and restriction edges are formed according to the deterministic discovery rules. Perform consistency checks on the object identifier, examination cycle, time interval, location, side, and source of the formed nodes and relationships to obtain the initial image of the examination object.

3. The method according to claim 1, characterized in that, The step of performing a hard-gate conditional local complexity evaluation on the set of restricted local subgraphs, and dividing the restricted local subgraphs in the set into direct generation tasks or nested subfronts with directed acyclic dependencies, includes: For each restricted local subgraph, extract the number of source types, cross-disciplinary span, number of missing roles, number of conflicting roles, expected target level span, and upper bound of candidate combinations to obtain a local complexity vector; When the number of missing roles reaches the missing role threshold, the number of conflicting roles reaches the conflicting role threshold, or the expected target level span reaches the cross-level dependency threshold, a recursive decomposition identifier is generated. When the missing role threshold, the conflicting role threshold, and the cross-layer dependency threshold are not triggered, a direct generation identifier or a recursive decomposition identifier is generated based on the comparison results of the local complexity vector with the versioned direct processing domain and the recursive processing domain.

4. The method according to claim 3, characterized in that, When the missing role threshold, the conflicting role threshold, and the cross-layer dependency threshold are not triggered, a direct generation identifier or a recursive decomposition identifier is generated based on the comparison results of the local complexity vector with the versioned direct processing domain and the recursive processing domain, including: Version normalization is performed on the components of different dimensions in the local complexity vector to obtain normalized complexity components; The weighted complexity is calculated based on the normalized complexity components and their corresponding complexity weights, and the direct generation identifier or the recursive decomposition identifier is determined based on the versioned direct processing domain or the recursive processing domain in which the weighted complexity is located. Based on the recursive decomposition identifier, the corresponding restricted local subgraphs are split according to organ system, formation role, and dependency direction to obtain the sub-frontier task; Based on the input and output roles between the sub-front tasks, directed dependency edges are established, duplicate dependency edges are deleted, and dependency edges that form directed cycles are rejected, resulting in a nested sub-front directed acyclic graph. The recursion depth, number of subtasks, and target level of the nested sub-front directed acyclic graph are defined according to the finite type metagraph, and subtasks that have reached the defined boundaries but have not yet been completed are marked as incomplete task keys. Sub-front tasks in the nested sub-front directed acyclic graph are processed in topological order, and only intermediate targets submitted by the independent graph execution component are provided to subsequent sub-front tasks.

5. The method according to claim 1, characterized in that, The process of generating a topology plan for the directly generated task or the nested sub-front, after pre-examination, allocates candidate slots according to relation signature coverage constraints and expected submission benefit gains, and generates candidate health check object graph increments, including: For the directly generated task or the nested sub-frontier, only the source node role combination, target node type, target level and necessary dependencies are generated to obtain the topology plan set; Perform relationship signature, object identifier, hierarchy, status permissions, and hard conflict pre-checks on the set of topology plans, and delete topology plans that fail the pre-checks; An executable topology plan queue is formed based on the plan's novelty, source completeness, expected relation signature coverage gain, and historical valid commit rate. A frontier budget allocation table is formed based on the executable topology plan queue and the total budget for each round, and node attributes, edges, directed superedges, and direct dependencies are generated only for the topology plans that have obtained candidate slots, thus obtaining the incremental graph of the candidate health check object.

6. The method according to claim 5, characterized in that, The step of forming a frontier budget allocation table based on the executable topology plan queue and the total round budget includes: Collect the relation signatures that have not yet been processed in the current complete round to obtain the set of unprocessed relation signatures; The consecutive waiting rounds of each topology plan in the executable topology plan queue are counted, and the topology plan that has reached the maximum waiting rounds is added to the forced execution set; Allocate at least one cover slot for each relation signature in the unprocessed relation signature set, and allocate at least one wait slot for each topology plan in the enforcement set; The number of flexible slots is obtained by subtracting the coverage guarantee slots and the waiting guarantee slots from the total budget of the round. Calculate the expected commit gain for each remaining topology plan based on the current conflict intensity, the number of uncovered relation signatures, the planned gains, and the historical valid commit rate; The elastic slots are allocated according to the order of the expected delivery revenue gain, and the allocation basis for each candidate slot is recorded to obtain the frontier budget allocation table. The tasks corresponding to topology plans that have not obtained candidate slots are retained as incomplete task keys, and the determination of fixed point establishment is prohibited when such incomplete task keys exist.

7. The method according to claim 1, characterized in that, The process of performing deterministic hard filtering and branch-aware heterogeneous graph state encoding on the extended task set yields a restricted local subgraph set, including: Based on the object identifier, physical examination cycle, time compatibility condition, location, side and relation signature of the finite type metagraph, a deterministic hard filter is performed on the objects associated with the extended task set to obtain a legitimate compatibility candidate pool; Construct a confirmed view consisting of committed nodes and a candidate view consisting of candidate nodes and readable committed nodes, respectively. In the confirmed view and the candidate view, node features are initialized according to node type, and relationship-aware message passing is performed according to forming relationship, restrictive relationship, contradictory relationship and version relationship respectively to obtain branch state vector; The branch state vector is matched with the versioned rule fragment vector and the candidate node structure vector, and a structure-aware recall ranking is formed based on the matching results. Based on the structure-aware recall ranking, a preset number of candidate objects are selected, and hard-filtered evidence, recall scores, and branch identifiers are added to obtain the restricted local subgraph set.

8. The method according to claim 7, characterized in that, In the confirmed view and the candidate view, node features are initialized according to node type, and relationship-aware message passing is performed according to forming relationships, restrictive relationships, contradictory relationships, and version relationships respectively to obtain a branch state vector, including: Set a confirmation branch mask for the confirmed view, and set a candidate branch mask for each candidate source branch in the candidate view; When encoding the confirmation view, only committed nodes are allowed to pass messages along the forming relationship, the restricting relationship, the contradictory relationship, and the version relationship, while messages sent by candidate nodes are blocked. When encoding the candidate view, candidate nodes are allowed to read messages from committed nodes, while candidate nodes from different candidate source branches are prohibited from sending messages to each other. Aggregate messages from adjacent nodes according to their relationship types, and combine the aggregation results with the current node features to obtain the confirmed node structure vector and the candidate node structure vector. Pooling is performed on the confirmed node structure vector to obtain the confirmed branch state vector, and pooling is performed on the candidate node structure vectors with the same candidate branch mask to obtain the candidate branch state vectors respectively. When performing structure-aware recall sorting, the confirmation branch state vector is used to control the formal frontier recall, and the candidate branch state vector is used only for the internal sorting of the corresponding candidate source branch. Write the branch mask and message source record into the recall audit log so that the independent graph execution component can verify the candidate isolation status.

9. The method according to claim 1, characterized in that, The process of verifying and versioning the graph increments of the candidate medical examination objects through an independent graph execution component, updating the frontier, and determining the fixed point or resource stopping result based on the graph state changes of the complete round includes: Verify the node type, relationship signature, data source, object identifier, level, loop, activity conflict, and state transition permission of the candidate physical examination object graph increment to obtain the candidate processing result; An atomic commit with the baseline graph version number is performed on the incremental candidate physical examination object graph that has passed the verification, and the newly added nodes, the basis for their formation, and the state changes are written into the updated physical examination object graph. The next round of expansion tasks is generated based on the newly added nodes, the formation basis, and the state changes, and the graph state hash and relation signature saturation vector are calculated. The fixed point is generated when there are no committable increments in the complete round covering all applicable relation signatures, the task queue of the extended task set is empty, the graph state hash remains unchanged, and the relation signature saturation vector indicates that all applicable relation signatures have been processed. When the number of candidate slots, recursion depth, number of subtasks, or runtime reaches the resource limit and there are still unfinished task keys, the resource stop result is generated, and the graph version, front fingerprint, and unfinished task keys required for continued computation are saved.

10. A front-end-driven self-growth system for physical examination object maps, characterized in that, The frontier refers to the range of objects in the currently submitted medical examination object map that can trigger subsequent expansion, including: The graph initialization module is used to configure a finite type metagraph with limited node types, relationship types, levels, states, and maximum depth, and to generate an initial graph of the physical examination objects based on the collected physical examination data. The front formation module is used to identify newly added objects, objects with changed states, and unsaturated objects based on the initial or updated image of the physical examination objects, and to form an extended task set with front fingerprints. The structure recall module is used to perform deterministic hard filtering and branch-aware heterogeneous graph state encoding on the extended task set to obtain a set of restricted local subgraphs; The recursive gating module is used to perform local complexity evaluation with hard gate conditions on the set of restricted local subgraphs, and to divide the restricted local subgraphs in the set of restricted local subgraphs into direct generation tasks or nested subfronts with directed acyclic dependencies. The candidate generation module is used to generate a topology plan for the direct generation task or the nested sub-frontier, allocate candidate slots according to relation signature coverage constraints and expected submission benefit gains after pre-examination, and generate candidate physical examination object graph increments. The verification convergence module is used to verify and version the submitted graph increments of the candidate physical examination objects through the independent graph execution component, update the frontier, and determine the fixed point or resource stopping result based on the graph state changes of the complete round.

Images