Method and device for editing and storing double-layered medical examination report

Abstract

The application discloses a physical examination report double-layer graph editing memory processing method and device. The method converts structured physical examination data into versioned evidence nodes, constructs a report semantic graph and a report presentation graph, gates candidate memories in an institutional memory library snapshot, binds target memories with current graph nodes and compiles them into a memory execution plan, a model input context and an output verification rule, generates an initial report data package with stable anchor points, receives an authoritative final state report signed and confirmed by an operator with final review authority, forms a learning baseline report according to data or version changes, identifies graph editing events through double-layer graph matching, consolidates into institutional long-term memory through scenario memory writing and matching positive examples and near-miss negative examples playback, and recalculates subsequent tasks according to version dependence. The application can reduce pseudo-learning and error generalization, and improve the verifiability and traceability of report generation.

Description

Technical Field

[0001] This invention relates to the fields of medical information data processing, artificial intelligence agents, natural language processing, and graph data processing, and in particular to a two-layer graph editing and memory processing method and apparatus for the data processing of physical examination report generation and review. Background Technology

[0002] Medical examination reports typically require the integration of information from multiple examination sources to form a structured report. Existing computer-aided reporting systems can receive structured or semi-structured medical examination data, utilize rule engines, template engines, or generative models to generate initial report data, which is then revised by authorized personnel to form the final report data. Different institutions may differ in their semantic combination, display grouping, naming format, relative order, and interpretation and prompts for the same set of evidence. Therefore, the system usually needs to extract institution-specific processing strategies from historical revision results.

[0003] One common approach is to save the full text of the final report, retrieve similar text in subsequent tasks, and add the search results to the generation context. Another approach is to generate rules based on the character differences between the initial and final texts, or to use a unified generation model updated with the entire final report. These approaches mainly work with flat text and lack a hierarchical expression of the relationship between evidence, report item semantics, and display structure. When multiple health analysis items are simply placed in the same display group, the text differences may be similar to the text differences when multiple health analysis items form new semantic nodes. The system may have difficulty determining whether the revision affects the report semantics or the report presentation, thus easily solidifying presentation preference errors into semantic strategies. Furthermore, directly using retrieved historical text as model instructions makes it impossible to confirm whether historical processing strategies correspond to the current task evidence and current graph nodes, and it is also difficult to generate executable actions and verifiable conditions from the same processing strategy.

[0004] During the report review process, source data supplementation, field correction, reference range switching, terminology upgrades, or model version switching may also occur. If the direct differences between the initial report and the final report are used as the learning object, differences arising from changes in source data or running versions may be mistakenly interpreted as institutional preferences; special revisions for a single task or historical revisions lacking key applicability conditions may also be incorrectly generalized to subsequent tasks. Therefore, existing solutions suffer from at least two interrelated technical problems: first, the lack of a mechanism for binding, compiling, executing, and verifying institutional memory with current evidence and bi-level graph nodes; and second, the lack of a closed-loop mechanism to identify genuine bi-level graph edits after excluding the influence of source data and version changes, and to control long-term memory promotion using matching positive examples and near-mismatch negative examples. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a method and apparatus for processing the dual-layer diagram editing memory of a physical examination report, so that the institutional memory can be deterministically executed and verified by the same source within the scope of evidence and diagram nodes of the current task, while excluding data changes, version changes and false feedback that do not meet the applicable conditions from the final report revision, forming a long-term institutional memory that can be replayed, downgraded and partially invalidated.

[0006] To address the aforementioned technical problems, this invention provides a method for editing and remembering a two-layer diagram in a medical examination report, executed by a computer device. The two-layer diagram comprises a report semantic diagram and a report presentation diagram that are interconnected but have separate responsibilities, sharing common diagram transaction identifiers and diagram version pairs. The method includes:

[0007] The process involves acquiring structured medical examination data, generating source data snapshots, version vectors, and versioned evidence nodes, and constructing associated report semantic graphs and report presentation graphs. Specifically, this includes: normalizing object keys, null values, time, numerical values, units, and reference ranges in the structured medical examination data to form normalized data objects; calculating snapshot hashes for the normalized data objects and writing data versions, reference range versions, terminology versions, baseline rule versions, knowledge versions, prompt template versions, report template versions, generation model versions, and institutional memory catalog versions into the version vector; generating versioned evidence nodes according to field location paths, inspection identifiers, inspection methods, observation times, and source versions, retaining evidence nodes from different sources corresponding to the same health information object, and connecting the evidence nodes before and after correction using substitution relationships; establishing health analysis item nodes, evidence support relationships, and semantic combination relationships in the report semantic graph; and establishing references, presentation groupings, name formats, relative orders, and paragraph layouts for the health analysis item nodes in the report presentation graph; and configuring common graph transaction identifiers and graph version pairs for the report semantic graph and the report presentation graph.

[0008] Recall and gate candidate memories from the institutional memory snapshot, bind the obtained target memory to the current graph node, compile it into a memory application package containing the memory execution plan, model input context and output validation rules, and generate an initial report data package carrying stable anchors;

[0009] Receive an authoritative final state report signed and confirmed by an operator with final review authority; replay the initial generation process for changes in source data or version to obtain a learning baseline report; perform stable anchor point alignment and two-layer graph matching on the learning baseline report and the authoritative final state report to obtain semantic graph editing events and presentation graph editing events.

[0010] Manually revised graph editing events are written into contextual memory and generated as candidate long-term memories. Matching positive examples and near mismatch negative examples are used for replay verification. Candidate long-term memories that meet the promotion criteria are consolidated into institutional long-term memories.

[0011] In subsequent tasks, the matching institutional long-term memory is compiled and executed, the execution results are verified according to the output verification rules, and the affected subgraph is locally recalculated based on the reverse dependency index when the version of the dependent object changes.

[0012] Furthermore, the acquisition of structured physical examination data, forming source data snapshots, version vectors, and versioned evidence nodes, and constructing associated report semantic graphs and report presentation graphs, includes: normalizing the object keys, null values, time, numerical values, units, and reference ranges in the structured physical examination data to form normalized data objects; calculating snapshot hashes for the normalized data objects and writing the data version, reference range version, terminology version, baseline rule version, knowledge version, prompt template version, report template version, generation model version, and institutional memory catalog version into the version vector; generating the versioned evidence nodes according to field location path, inspection identifier, inspection method, observation time, and source version, retaining evidence nodes from different sources corresponding to the same health information object, and connecting the evidence nodes before and after correction with substitution relationships; establishing health analysis item nodes, evidence support relationships, and semantic combination relationships in the report semantic graph, and establishing references, presentation groupings, name formats, relative orders, and paragraph layouts for the health analysis item nodes in the report presentation graph; and configuring common graph transaction identifiers and graph version pairs for the report semantic graph and the report presentation graph.

[0013] Furthermore, the process of recalling and gating candidate memories in the institutional memory snapshot, binding the obtained target memories to the current graph nodes, compiling them into a memory application package containing a memory execution plan, model input context, and output validation rules, and generating an initial report data package carrying stable anchors includes: establishing a read-consistent institutional memory snapshot at the start of initial report generation, recording the memory catalog version, snapshot time, memory identifier, memory version, and lifecycle state; recalling the candidate memories according to a combined index of institutional tenant, scope, lifecycle state, target semantic encoding, and template version; performing hard gating on the candidate memories based on applicable predicates, necessary evidence, exclusion conditions, version compatibility status, candidate memory credibility, and memory conflict status, and according to strong... Conflict resolution is performed based on constraints, current task evidence, published baseline rules, memory hierarchy, and scope specificity; abstract target objects in the target memory are bound to the current graph node, and target memories that cannot be uniquely bound are transferred to a memoryless baseline branch or a manually reviewed branch; a memory execution plan with bound targets, graph operators, preconditions, invariants, and rollback information is generated from the same target memory, along with a model input context with priorities, necessary actions, and prohibited actions, and output verification rules with expected results and prohibited operations; deterministic graph actions are executed in graph transactions, the model input context is passed to the report generator through structured request fields or message interfaces, and the returned results are verified according to the output verification rules.

[0014] Furthermore, each visible report item in the initial report data packet carrying stable anchors is associated with a report item identifier, a semantic node identifier, a presentation group identifier, an evidence reference, and a semantic hash; the initial report data packet also includes an applied memory identifier, an institutional memory snapshot identifier, a candidate memory version, a generation configuration identifier, and an output mode; the verification of the returned results according to the output verification rules includes: verifying whether the applied memory identifier is consistent with the memory execution plan; verifying whether the semantic node identifier and the evidence reference exist in the current task context; verifying whether each visible report item in the report presentation graph references a valid health analysis item node; verifying whether the protected attributes, knowledge basis, and graph transaction invariants satisfy the corresponding mandatory constraints; rolling back the corresponding graph transaction when any verification fails, and performing a memoryless rollback, replanning, or partial recalculation of the failed node.

[0015] Further, the step of receiving an authoritative final-state report signed and confirmed by an operator with final review authority, replaying the initial generation process for changes in source data or version, and obtaining a learning baseline report; performing stable anchor point alignment and two-layer graph matching on the learning baseline report and the authoritative final-state report, and obtaining semantic graph editing events and presentation graph editing events; wherein, the step of replaying the initial generation process for changes in source data or version to obtain the learning baseline report includes: obtaining a snapshot of the final-state source data and a final-state version vector at the time corresponding to the authoritative final-state report; when the snapshot hash of the final-state source data snapshot is different from that of the initial source data snapshot, or when the final-state version vector is incompatible with the initial version vector, the final-state source data is used. The initial generation process is replayed using snapshots and version parameters in the final version vector, excluding the institutional memory catalog version. During the replay, the institutional memory snapshot from the initial generation is used, and the decoding parameters, random seed, or deterministic template version in the initial generation configuration are reused. Memories added, promoted, updated, or invalidated after the initial generation are not read. The replay result is used as the learning baseline report, and differences that can be explained by source data or version changes are marked as data-induced differences. When the report generation tool cannot deterministically reproduce the differences, the normalized report semantic graph and the report presentation graph are compared, and wording differences that do not change graph nodes, graph relationships, and protected attributes are excluded.

[0016] Further, the step of receiving an authoritative final state report signed and confirmed by an operator with final review authority, replaying the initial generation process for changes in source data or version, and obtaining a learning baseline report; performing stable anchor point alignment and two-layer graph matching on the learning baseline report and the authoritative final state report to obtain semantic graph editing events and presentation graph editing events; wherein, the step of performing stable anchor point alignment and two-layer graph matching on the learning baseline report and the authoritative final state report to obtain semantic graph editing events and presentation graph editing events includes: prioritizing the matching of report items in the learning baseline report and the authoritative final state report according to the report item identifier and the semantic node identifier; for unmatched report items, generating candidate node pairs according to semantic encoding, object category, protected attribute, inspection source, and evidence intersection; and according to the encoding... The matching cost of each candidate node pair is calculated based on code similarity, text similarity, evidence overlap, attribute conflict, relation difference, and node type difference. The matching cost of protected attribute mutually exclusive node pairs without legal transformation rules is set as a blocking value. One-to-one node matching is solved based on the matching cost, and then one-to-many and many-to-one hyperedge matching is solved for subsets of the same type of candidate nodes within a preset combination size. When the difference between the optimal matching cost and the suboptimal matching cost is less than the ambiguity threshold, the corresponding candidate node pair is marked as an ambiguous match and automatic learning is prevented. Graph editing operations that generate new health analysis item nodes or change evidence dependencies are classified as semantic graph editing events, and graph editing operations that only change the presentation grouping, name format, relative order, separator, or paragraph layout are classified as presentation graph editing events.

[0017] Furthermore, the process of writing manually revised graph editing events into contextual memory and generating candidate long-term memories, and using matching positive examples and near-mismatch negative examples for replay verification, consolidates candidate long-term memories that meet the promotion criteria into organizational long-term memories; wherein, the process of writing manually revised graph editing events into contextual memory and generating candidate long-term memories includes: classifying the reasons for revision of graph editing events into data change events, case-specific events, format repair events, presentation preference events, health analysis strategy events, knowledge update events, or pending events; recording learning permission flags, case-specific flags, source change filtering status, revision source, and editing trajectory for each graph editing event; and linking each graph editing event with... The learning baseline report, the authoritative final state report, the corresponding source data snapshot summary, and the revision branch are written into the context memory; only graph editing events with a true learning permission flag, a false case-specific flag, and not belonging to data change events, incomplete knowledge update events, or pending events are converted into candidate semantic memories or candidate program memories; combined operations that generate new health analysis item nodes are written into the candidate semantic memory, and presentation grouping operations that retain the original health analysis item nodes and evidence citations are written into the candidate program memory; protected attribute preservation, permission restrictions, and evidence integrity rules are written into independently published constraint memories, and automatic modification of the constraint memories by a single graph editing event is prohibited.

[0018] Further, the step of writing manually revised graph editing events into contextual memory and generating candidate long-term memories, and using matching positive examples and near mismatch negative examples for replay verification, consolidates candidate long-term memories that meet the promotion conditions into institutional long-term memories; wherein, the step of using matching positive examples and near mismatch negative examples for replay verification, and consolidating candidate long-term memories that meet the promotion conditions into institutional long-term memories, includes: configuring memory identifiers, memory types, lifecycle states, scopes, applicable predicates, target graph objects, graph actions, necessary evidence, exclusion conditions, graph invariants, version dependencies, and source tracing for the candidate long-term memories; selecting matching positive examples from historical contextual memories that satisfy the scope, applicable predicates, necessary evidence, and version dependencies, and selecting near mismatch negative examples that lack a necessary condition, meet an exclusion condition, or are version incompatible; respectively in the matching positive examples and the near mismatch negative examples On the near mismatch counterexample, candidate long-term memory replay is performed, and the distance gain, near mismatch error trigger rate, and protected attribute retention rate of the weighted graph edit distance before and after replay are calculated. The number of valid support attempts and valid conflict attempts are counted according to different tasks for deduplication. The credibility of the candidate memory is calculated by combining evidence completeness, the distance gain, signing role permissions, support source independence, version compatibility, and time decay. When the number of valid support attempts, the distance gain, the near mismatch error trigger rate, the protected attribute retention rate, and the candidate memory credibility reach the promotion threshold for the corresponding memory type, and there is no conflict with the constrained memory, the candidate long-term memory is consolidated into the institutional long-term memory. Candidate long-term memories that do not reach the promotion threshold are kept under observation, candidate long-term memories that have conflicts are downgraded, and candidate long-term memories with incompatible version dependencies are set to a pending review status.

[0019] Furthermore, the authoritative final state report signed and confirmed by the operator with final review authority is determined in the following way: two or more report revision versions are organized into a revision directed acyclic graph, and each revision node records the revision identifier, parent node identifier, report hash, two-layer graph version, source data snapshot hash, operator role, time, revision reason, signature, and authority status; the revision node with valid signature, operator role with final review authority, true authority status, and no subsequent signing replacement node is determined as the authoritative final state node; when there are two or more competing authoritative final state nodes, the cumulative positive support is suspended, the unsigned branch is retained as contextual evidence, and the graph editing operation revoked by the authoritative final state node is recorded as a conflict sample; the local recalculation of the affected subgraph based on the reverse dependency index includes determining the direct impact set according to the dependent objects that have undergone version changes, obtaining the semantic impact closure along the evidence support relationship, semantic combination relationship, and knowledge application relationship, obtaining the presentation impact closure according to the semantic node identifier, only adding the nodes in the semantic impact closure and the presentation impact closure to the local recalculation plan, and keeping the text hash of the non-dependent nodes unchanged.

[0020] This invention also provides a two-layer graph editing and memory processing device for physical examination reports, comprising: a two-layer graph construction module for acquiring structured physical examination data, forming source data snapshots, version vectors, and versioned evidence nodes, and constructing associated report semantic graphs and report presentation graphs; a memory compilation and generation module for recalling and gating candidate memories in the institutional memory bank snapshot, binding the obtained target memories with the current graph nodes, compiling them into a memory application package containing a memory execution plan, model input context, and output verification rules, and generating an initial report data package carrying stable anchor points; and a graph editing recognition module for receiving authoritative final reports signed and confirmed by operators with final review authority, and for handling changes in source data or versions. The initial generation process is replayed to obtain a learning baseline report. Stable anchor alignment and two-layer graph matching are performed on the learning baseline report and the authoritative final state report to obtain semantic graph editing events and presentation graph editing events. A memory consolidation module is used to write manually revised graph editing events into contextual memory and generate candidate long-term memories. Replay verification is performed using matching positive examples and near-mismatch negative examples to consolidate candidate long-term memories that meet the promotion criteria into institutional long-term memories. A memory application and local recalculation module is used to compile and execute the matched institutional long-term memories in subsequent tasks, verify the execution results according to the output verification rules, and perform local recalculation of the affected subgraphs based on the reverse dependency index when the version of the dependent object changes.

[0021] Compared with existing technologies, this invention has the following advantages: By separating the report semantic graph from the report presentation graph, it can separately identify edits that change the semantics and evidence dependencies of health analysis items from edits that only change grouping, name, sorting, and layout; through institutional memory snapshots, node binding, and homologous compilation, the same target memory can simultaneously form deterministic graph actions, model input context, and output verification rules, avoiding unparsed historical text from directly affecting the generated results by bypassing the current evidence and scope; by forming a counterfactual learning baseline on the initial institutional memory snapshot, it can eliminate false feedback caused by late-arriving data, data correction, and changes in running versions; by jointly replaying matched positive examples and near-mismatched negative examples, it can improve the reproducibility of historical final states while limiting error triggering when key conditions are missing; through version dependency and reverse dependency indexing, only the semantic subgraph and presentation subgraph related to the changed object need to be recalculated, thereby reducing the repeated processing of irrelevant nodes and maintaining the traceability of processing results. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the overall process of the two-layer diagram editing and memory processing method for physical examination reports of the present invention;

[0023] Figure 2 This is a schematic diagram illustrating the association structure of the versioned evidence nodes, report semantic graph, and report presentation graph of this invention.

[0024] Figure 3 This is a schematic diagram of the candidate memory retrieval, node binding, context compilation, and result verification process of the present invention;

[0025] Figure 4 This is a schematic diagram of the counterfactual replay, stable anchor point alignment, and two-layer graph editing and recognition process of the present invention;

[0026] Figure 5 This is a schematic diagram of the candidate long-term memory playback consolidation, authoritative final state determination, and local recalculation process of the present invention.

[0027] Figure 6 This is a schematic diagram of the module structure of the dual-layer image editing and memory processing device for physical examination reports of the present invention;

[0028] Figure 7 This is a flowchart of the code for physical examination data access, initial report generation, and final state feedback in this invention;

[0029] Figure 8 This is a flowchart illustrating the historical sample verification, controlled reuse, and partial recalculation code of this invention. Detailed Implementation

[0030] The present invention will be further described below with reference to the accompanying drawings and embodiments. The embodiments are used to illustrate possible implementations of the present invention, and are not intended to limit the present invention to a particular generative model, graph database, serialization format, rule language, or field name. Unless otherwise stated, the thresholds and example values ​​in this embodiment can be configured based on the target organization's de-identified historical task set; the output is candidate report data for confirmation by operators with review authority, and does not directly replace the final manual review conclusion with computer output.

[0031] In this embodiment, the two-layer graph editing memory processing task for the physical examination report is run by a computer device. The computer device may include a task state manager, a planner, a tool invocation controller, a memory controller, a memory context compiler, a two-layer graph processor, a report generator, and a verification and reflection unit. The task state manager stores the task identifier, organizational scope, source data snapshot, version vector, execution status, and failure nodes; the planner breaks down the task into dependent processing nodes such as evidence construction, memory retrieval, node binding, graph action execution, report generation, output verification, and reflective learning; the tool invocation controller only invokes pre-registered parsing tools, terminology tools, rule tools, graph processing tools, generation tools, and verification tools, and stores tool versions, input / output summaries, idempotency flags, and error states; the writing, promotion, demotion, and rollback of long-term memory are executed by the memory controller according to permission and lifecycle rules.

[0032] The table provides explanations of relevant terms used in this invention. Terms with clearly defined meanings in the computer field are given their common meanings. The combined terms representing the data structures and processing conditions of this invention are defined according to their input objects, processing actions, and output results as follows. The following explanations are intended to clarify content already described in the original application and do not constitute new technical features or limitations on the scope of the claims.

[0033] 1 Double-layer diagram It consists of a semantic graph of reports and a presentation graph of reports that are related but have separate responsibilities; the two have common graph transaction identifiers and graph version pairs, and are not two display layers of the same image. 2 Report semantic graph Using health analysis items as the processing object, it preserves the evidence support relationship and semantic combination relationship; it is used to express the health analysis object represented by the report content and its evidence basis. 3 The report presents a chart. The semantic nodes are used to identify the report semantic graph, which only saves grouping, name format, relative order, separators and paragraph layout; they are used to express how the content is displayed, and do not change the report semantic graph in reverse. 4 Health Analysis Items The processing objects in the report semantic graph can be supported by one or more evidence nodes; multiple health analysis items in the same presentation group still retain their respective semantic identities. 5 Versioned Evidence Nodes Save field location path, inspection identifier, inspection method, observation time, source version, and snapshot hash; when evidence is corrected, a new version is generated and the source traceability is retained. 6 Version Vector Record versions of data, reference ranges, terminology, rules, knowledge, prompt templates, report templates, generated models, and institutional memory directories to determine version compatibility for replay and memory retrieval. 7 Stable anchor point At least the associated report item identifier, semantic node identifier, presentation group identifier, evidence citation, and semantic hash should be included; the correspondence between visible report items, semantic nodes, and source evidence should be maintained even after changes in name, order, or grouping. 8 memory A computer-readable record with identifiers, types, scope, applicable conditions, target graph objects, graph actions, version dependencies, and source traceability; it is neither human memory nor a full-text historical report. 9 Institutional memory snapshot The set of read-consistent memories frozen at the start of the task; memories added, promoted, updated, demoted, or invalidated during task execution do not change the task snapshot. 10 Recall, Gating and Binding Recalling retrieves candidate records; gating checks apply predicates, necessary evidence, exclusion conditions, version, credibility, and conflicts; binding uniquely maps the abstract target to the current evidence node, semantic node, or presentation group. Automatic execution does not occur if any necessary condition is not met or the binding is not unique. 11 Memory application package The current task executable instance generated from the same target memory and the same binding mapping includes the memory execution plan, model input context, output validation rules, target graph version, and rollback information. 12 Authoritative final state report Reports that have been validly signed, have final review authority and authoritative status, and have no subsequent signing replacement nodes are not considered as automatic learning bases; intermediate versions that do not meet the above conditions will not be used as the basis for automatic learning. 13 Counterfactual replay and learning baseline When data or runtime versions change during the audit, the initial process is replayed with the final input under the initial institutional memory snapshot and initial generation configuration; the resulting learning baseline is used to absorb data-induced differences. 14 Semantic graph edit events and rendering graph edit events Operations that generate new health analysis items or change the evidence reliance are classified as semantic graph editing events; operations that only change grouping, name format, relative order, separators, or paragraph layout are classified as presentation graph editing events. 15 Episodic memory, candidate memory, matching positive examples and near mismatch negative examples Contextual memory stores the task-level baseline, final state, and edit trajectory; learnable events form candidate semantic memory or candidate program memory. Matching positive examples satisfy all conditions; near-mismatch negative examples are only missing one necessary condition, hit an exclusion condition, or are version incompatible, used to verify call boundaries. 16 Reverse dependency indexes, affecting closures and local recalculation When a version changes, the directly affected objects are determined by the reverse dependency index, and then the affected closure is formed by evidence support, semantic composition, and presentation of reference relationships; only the nodes within the closure are recalculated.

[0034] Example 1

[0035] like Figure 1 As shown in the figure, this embodiment provides a method for editing and storing a two-layer diagram of a physical examination report, the execution process of which includes the following steps.

[0036] S1. Acquire structured physical examination data, form source data snapshots, version vectors, and versioned evidence nodes, and construct associated report semantic graphs and report presentation graphs. Specifically, this includes: normalizing the object keys, null values, time, numerical values, units, and reference ranges in the structured physical examination data to form normalized data objects; calculating snapshot hashes for the normalized data objects and writing the data version, reference range version, terminology version, baseline rule version, knowledge version, prompt template version, report template version, generation model version, and institutional memory catalog version into the version vector; generating the versioned evidence nodes according to field location path, inspection identifier, inspection method, observation time, and source version; retaining evidence nodes from different sources corresponding to the same health information object, and connecting the evidence nodes before and after correction with substitution relationships; establishing health analysis item nodes, evidence support relationships, and semantic combination relationships in the report semantic graph; establishing references, presentation groupings, name formats, relative order, and paragraph layouts for the health analysis item nodes in the report presentation graph; and configuring common graph transaction identifiers and graph version pairs for the report semantic graph and the report presentation graph.

[0037] Structured medical examination data can be input in JSON, XML, relational tables, or message objects. Data content can be layered according to examination source, examination combination, and detailed items. Upon receiving the task, the computer freezes the currently visible data range, standardizes object key order, null value representation, time format, numerical precision, units, and reference range representation to form a normalized data object, and calculates a snapshot hash on the normalized data object. Each evidence node stores the location path of the corresponding field in the source data, examination identifier, examination method, observation time, data status, source version, and snapshot hash, enabling subsequent report items to trace back to the actual input field. For multiple sources of the same health information object, one source does not overwrite others; instead, separately addressable evidence nodes and supporting, supplementary, or source difference relationships are established.

[0038] The report semantic graph primarily processes health analysis item nodes, storing evidence support relationships, semantic combination relationships, and applicability relationships with versioned knowledge nodes. The report presentation graph references health analysis item nodes from the report semantic graph, storing display groupings, naming formats, relative order, separators, and paragraph layouts. The presentation graph does not copy the factual content of semantic nodes, nor does it have the authority to add health analysis items through presentation operations. Through this separation of responsibilities, the same group of health analysis items can have their display groupings adjusted without changing the semantic nodes and evidence references. However, when creating new health analysis items or changing evidence dependencies, a identifiable graph editing operation must be left in the report semantic graph.

[0039] Specifically, structured medical examination data can pass through a field pattern validator before entering the evidence construction process. The field pattern validator selects the corresponding field pattern based on the type of inspection source, checking required keys, data types, unit dimensions, chronological order, and the legality of item codes. Fields whose equivalent units can be determined using a unit conversion table are first converted to standard units, and then the original value, original unit, standard value, and standard unit are saved. Fields whose conversion relationship cannot be determined are left in a pending verification state and do not participate in semantic combinations requiring numerical comparison. For duplicate data packets, the system forms an idempotent key using the organization's scope, task identifier, inspection identifier, source version, and content hash. Evidence nodes with the same idempotent key are not created repeatedly, thus avoiding the artificial increase in the number of evidence due to retries.

[0040] Optionally, the evidence node may also carry a parser version, field pattern version, data quality flag, and source chain summary. The data quality flag can distinguish between states such as complete, missing non-critical fields, missing critical fields, unit pending verification, and source conflict. When non-critical fields are missing, the evidence node continues to be constructed, but the evidence completeness is reduced in subsequent verification; when critical fields are missing, the original location path and error reason are retained, but the corresponding evidence node is prevented from entering automatic semantic combination. This processing provides a clear degradation path for abnormal inputs, avoiding the loss of the entire task due to a single non-standard field, and also avoiding the generation of sourceless information by filling key facts with default values.

[0041] S2. Recall and gate candidate memories in the institutional memory snapshot, bind the obtained target memory to the current graph node, compile it into a memory application package containing the memory execution plan, model input context and output validation rules, and generate an initial report data package carrying stable anchors.

[0042] The institutional memory snapshot is a read-consistent version view established for the isolated namespace of the target medical institution at the start of the initial report generation. The read-consistent version view records at least the memory catalog version, snapshot time, and the identifier, version, and lifecycle status of each memory within the snapshot, and can read the content of the corresponding historical memory version according to the snapshot identifier. Memory added, promoted, updated, downgraded, or expired during task execution does not change the institutional memory snapshot.

[0043] At the start of the initial generation, the memory controller establishes a read-consistent snapshot of the institution's memory for the isolated namespace of the target institution. Candidate recall, gating, conflict resolution, and subsequent counterfactual replay all use this institution memory snapshot as the consistency boundary. The recall index can consist of institution, hospital area, department, role, report template, target semantic encoding, and lifecycle state; the gating process checks whether the current evidence meets the necessary conditions, whether it hits the exclusion conditions, whether version dependencies are compatible, whether the candidate memory reaches the call credibility, and whether there are high-priority conflicts.

[0044] The gated target memory does not directly incorporate unparsed historical text into the generation prompts. The memory context compiler first binds the abstract target object in the target memory to the evidence node, health analysis item node, presentation group, or knowledge node of the current task. Then, it generates three corresponding outputs from the same target memory: a memory execution plan for deterministic execution by the graph processor; a model input context for constraining the expression range of the report generator; and output verification rules for verifying whether the generated results conform to the invariants, prohibited actions, and expected results of the target memory. When a target object cannot be uniquely bound, the corresponding target memory is blocked or transferred to manual review to avoid mechanically applying historical node identifiers to the current task.

[0045] In the cold start state, the institution memory snapshot may only contain published general baseline rules, report templates actively configured by the target institution, and constraint memories. The cold start branch does not presume that the target institution has not yet formed name, grouping, and sorting preferences, and high-impact nodes in the generated results that require institution confirmation carry a "pending review" flag. If the institution already has long-term memories but no candidate memories pass the gating in the current task, the task status manager sets the "no applicable institution memory" flag and enters the same baseline generation path; the cause codes for both states are retained so that subsequent statistics can determine whether it is "no historical memory yet" or "memory exists but current conditions do not match".

[0046] It should be noted that the institutional memory snapshot adopts read-consistent semantics throughout the task lifecycle, while long-term memory writes can still be performed normally outside of snapshots. Each candidate record returned by the candidate recall carries a memory identifier, the memory version within the snapshot, and a content summary. The compiler checks the consistency of these three elements again before execution. If the historical content corresponding to the snapshot is no longer readable, the target memory will not enter the automatic execution path. The system will instead use the baseline branch and record the snapshot read exception to avoid using the current version, which is inconsistent with the retrospective record, to replace the historical version.

[0047] S3. Receive the authoritative final state report signed and confirmed by an operator with final review authority, replay the initial generation process for changes in source data or version to obtain a learning baseline report; perform stable anchor point alignment and two-layer graph matching on the learning baseline report and the authoritative final state report to obtain semantic graph editing events and presentation graph editing events.

[0048] After the review process is completed, the computer equipment obtains the report version designated as the authoritative final state, along with a snapshot of the final state source data and the final state version vector visible at that moment. If data was added, corrected, reference scopes were switched, or terminology, rules, knowledge, templates, or generative models were upgraded during the review, the computer equipment replays the initial generation process using the final state data and compatible version parameters on the initial institutional memory snapshot to obtain the learning baseline report that should be generated under the condition of "no manual revisions but with final state input conditions." In this way, report differences that can be explained by changes in input or running versions will not be considered as institutional processing preferences.

[0049] Two-layer graph matching prioritizes restoring stable anchor point correspondences; when anchor points are missing or incomplete, matching is then performed based on semantic encoding, evidence intersection, protected attributes, inspection source, text similarity, and graph relationships. The matching results are then converted into graph editing operations such as semantic node addition / deletion, semantic combination / splitting, evidence dependency changes, presentation grouping, name format, relative order, separators, and layout. Graph editing operations applied to new health analysis items or semantic dependencies are categorized as semantic graph editing events; those applied only to the display structure are categorized as presentation graph editing events.

[0050] S4. Write the manually revised graph editing events into the contextual memory and generate candidate long-term memories. Use matching positive examples and near mismatch negative examples for replay verification, and consolidate the candidate long-term memories that meet the promotion conditions into the organization's long-term memories.

[0051] The contextual memory is a computer-readable memory that is written in an append-on manner according to the case, with memory identifiers and source traceability. It at least saves the task-level source data snapshot summary, learning baseline report, authoritative final state report, revision branch, graph editing trajectory, revision reason, reason classification, and version traceability. The contextual memory is not the full text of the historical report, nor does it become the institution's long-term memory directly due to a single revision.

[0052] All graph editing events are first appended to the context memory, which stores a task snapshot summary, learning baseline report, authoritative final state report, revision branches, graph editing trajectory, cause classification, and version tracking. Only events that pass the source change filter, are marked as learnable, and are not case-specific are further converted into candidate semantic memory or candidate procedural memory. Constraint memory is maintained by a separate authorized release process and does not change automatically with a single revision.

[0053] Candidate long-term memories need to be replayed on two types of historical tasks. Matching positive examples satisfy all scopes, necessary evidence, applicable predicates, and version conditions of the candidate long-term memory, used to test whether executing the candidate long-term memory can reduce the two-layer graph edit distance with the authoritative final state report. Near-mismatch negative examples have a similar graph structure to the positive examples but lack a necessary condition, meet an exclusion condition, or have an incompatible version, used to test whether the candidate long-term memory will trigger out of bounds. A candidate long-term memory only becomes effective when the positive example distance gain, near-mismatch error trigger rate, protected attribute retention rate, number of valid supports, number of valid conflicts, and candidate memory credibility all meet the corresponding promotion conditions.

[0054] S5. In subsequent tasks, compile and execute the matching institutional long-term memory, verify the execution results according to the output verification rules, and perform local recalculation of the affected subgraph based on the reverse dependency index when the version of the dependent object changes.

[0055] Subsequent tasks perform the same recall, gating, binding, and compilation processes on the organization's long-term memory as the initial task. The execution result must simultaneously comply with evidence integrity, protected attribute preservation, graph reference integrity, knowledge versioning, and access control rules. If any necessary verification fails, the system can roll back the corresponding graph transaction, switch to a memoryless baseline, replan, or transfer the failed node to manual review.

[0056] Each evidence node, rule, knowledge node, institutional long-term memory, and two-layer graph node records dependent objects and their versions. The reverse dependency index maps from dependent object identifiers to institutional long-term memory, health analysis item nodes, presentation groups, and report items. When a dependent object version changes, the system first determines the direct impact set, then forms a semantic impact closure along semantic relationships, and finally forms a presentation impact closure based on semantic node identifiers. The semantic impact closure is the set of affected nodes formed in the report semantic graph from the direct impact set along evidence support relationships, semantic combination relationships, and applicable relationships of explanation, recommendation, and risk. The presentation impact closure is the set of affected display groups, report items, and layout nodes determined in the report presentation graph based on the semantic node identifiers of each health analysis item node within the semantic impact closure. Only the semantic impact closure and the nodes within the presentation impact closure are included in the local recalculation plan. Report items without dependencies are not included in the local recalculation plan, and their text hashes and graph version mappings remain unchanged.

[0057] Preferably, the local recalculation plan stores the old input summary, target input summary, set of predecessor nodes, and expected output pattern for each node to be recalculated. Before executing a node, the old input summary is compared with the target input summary. If they are the same, the original node's result is reused directly; otherwise, the corresponding rule tool, graph processing tool, or generation tool is invoked. For duplicate notifications generated by the same version change event, a local recalculation idempotent key can be generated based on the change event identifier and the target graph version, ensuring that committed local graph transactions are not executed repeatedly. If a dependent object version change occurs again during local recalculation, the system discards the uncommitted temporary results and re-establishes the impact closure with the latest compatible version.

[0058] In one exception handling method, after a local recalculation node fails consecutively to reach a preset number of retries, the recalculation scope is not expanded further. Instead, the failed node and its downstream presenting nodes are marked as uncommittable, and the original content of nodes without dependencies is preserved. The preset number of retries can be configured to 1 to 3 times, and the retry interval adopts a fixed interval or exponential backoff depending on the type of tool error. Data missing, version incompatibility, and constraint conflicts are considered non-retryable errors and are directly transferred to memoryless rollback or manual review; network timeouts and temporary service unavailability are considered retryable errors. This error classification reduces invalid duplicate calls and prevents irrelevant parts of the entire report from being regenerated due to local failures.

[0059] Example 2

[0060] like Figure 2 As shown in the figure, this embodiment further explains the evidence processing of structured physical examination data and the construction of a two-layer graph.

[0061] S1.1. Standardize the object keys, null values, time, numerical values, units, and reference ranges in the structured physical examination data to form standardized data objects.

[0062] Normalization processing can include standardizing key names according to a preset field dictionary, outputting objects in lexicographical order of key names, distinguishing and encoding missing values ​​from explicitly null values, converting time to a unified time zone timestamp, converting numerical values ​​to a unified precision decimal fixed-point representation, converting units to standard units, and representing the reference range as a structured object containing lower bounds, upper bounds, open and closed intervals, and applicable object conditions. For source summaries containing only isolated values, the computer device binds them by combining field location paths, corresponding detailed items, check combination identifiers, and units, and does not directly convert isolated values ​​into health analysis item nodes in the absence of definite semantics.

[0063] In a data processing example, the source fields record the value "0.58", the unit "A", and the observation time "2026-01-01T10:15:20+08:00". Normalization preserves the original strings while generating the decimal specified-point value, standard unit code, and Coordinated Universal Time (UTC) representation. If a detail item in the same field records the value 58 and a unit conversion table indicates that the two source units are not convertible, the system does not merge the two fields based on text similarity. Instead, it establishes a source conflict relationship and awaits upstream verification. This mechanism ensures that subsequent evidence overlap calculations are based on confirmed equivalent data objects, rather than on unverified string similarity.

[0064] S1.2. Calculate a snapshot hash for the normalized data object and write the data version, reference range version, terminology version, baseline rule version, knowledge version, prompt template version, report template version, generated model version, and organization memory catalog version into the version vector.

[0065] Snapshot hashes can be obtained by applying SHA-256 or a hash algorithm with equivalent collision safety to the deterministic serialization result of a normalized data object. Each dimension of the version vector stores a version identifier and compatibility status, rather than just the last update time. Version publishers can maintain a compatibility matrix to determine whether two versions require a compatible replacement, partial recalculation, or a complete replay.

[0066] Version vectors can be serialized using ordered key-value pairs, where the key corresponds to the version dimension and the value includes the version identifier, release time, and compatibility family identifier. Deterministic serialization fixes the key order, character encoding, numeric format, and null value representation, ensuring that the same data yields the same snapshot hash across different nodes. Versions that only add non-critical field schemas not referenced in the current report can be marked as backward compatible in the compatibility matrix. Versions that change the reference scope determination logic, terminology mapping targets, or report template structure are marked as partially compatible or incompatible, and the affected object types are also provided for counterfactual replay and partial recalculation to select the processing scope.

[0067] S1.3. Generate the versioned evidence nodes according to the field location path, inspection identifier, inspection method, observation time and source version. Retain evidence nodes for different sources corresponding to the same health information object, and connect the evidence nodes before and after the correction with a substitution relationship.

[0068] An evidence node includes an evidence identifier, field location path, inspection identifier, inspection method, project code, result value, unit, reference range, observation time, source version, snapshot hash, and evidence status. A new evidence node is created when a source field is modified. The new evidence node points to the old evidence node through a substitution relationship, and the old evidence node is retained as historical evidence visible at the time of initial generation. When multiple sources describe the same health information object, same-object relationships, primary support relationships, or secondary support relationships can be established, enabling the report semantic graph to preserve source differences.

[0069] Furthermore, substitution relationships can carry the substitution reason, substitution time, upstream revision identifier, and field-level difference summary. When querying along a substitution relationship, the system selects the currently valid evidence node based on the target task time and the source data snapshot, rather than simply selecting the latest node. If the substitution chain forks, it indicates that there are two competing revision versions of the same old evidence. The system marks both new nodes as conflicting and prevents automatic semantic combination until the upstream data source specifies an authoritative branch. This allows the system to recover the evidence version truly visible in the initial task during counterfactual replay.

[0070] S1.4. Establish health analysis item nodes, evidence support relationships, and semantic combination relationships in the report semantic graph, and establish references, presentation groupings, name formats, relative order, and paragraph layouts for the health analysis item nodes in the report presentation graph.

[0071] The report semantic graph can contain atomic health analysis item nodes, composite health analysis item nodes, explanation nodes, prompt nodes, and knowledge basis nodes. Semantic composition uses hyperedges to record input health analysis items, necessary evidence, exclusion conditions, output health analysis items, and sub-item mappings. Display items in the report presentation graph reference the report semantic graph through semantic node identifiers, without copying semantic facts. When two atomic health analysis items are configured to the same presentation group, their semantic node identifiers and evidence references remain independent; semantic composition only occurs when semantic composition rules generate new semantic node identifiers and save the input-to-output mapping.

[0072] Both the semantic graph and the presentation graph of the report can be implemented using attribute graphs, relational tables, or document collections, as long as node identifiers, edge types, and version relationships can be preserved. When implemented using attribute graphs, semantic composite hyperedges can be implemented as composite event nodes with input and output edges; when implemented using relational tables, the same relationships can be expressed through composite event tables, composite input tables, and composite output tables. All of the above alternative implementations retain the invariant that "presentation nodes only reference semantic nodes," so changes in the database type will not alter the two-layer graph editing and classification logic.

[0073] S1.5. Configure common graph transaction identifiers and graph version pairs for the report semantic graph and the report presentation graph.

[0074] The two-layer graph processor first executes graph actions in the staging version. Before committing, it checks whether each visible report item references exactly one valid health analysis item node, whether each health analysis item node to be displayed is in at least one presentation group, whether evidence references exist, and whether protected attributes are complete. If all checks pass, it simultaneously increments the report semantic graph version and the report presentation graph version and commits; if any check fails, it rolls back both layers of the graph according to the common graph transaction identifier to avoid dangling presentation references or presentation modifications without semantic authorization.

[0075] A common graph transaction can include four states: prepare, validate, commit, and rollback. The prepare state records the temporary version of the semantic graph and the temporary version of the presentation graph; the validate state freezes the set of nodes to be committed to prevent modification by other tasks during validation; the commit state atomically writes graph version pairs and a transaction summary; the rollback state deletes the temporary edges and restores the previous version reference of the modified nodes. For distributed storage, equivalent commit semantics can be achieved through transaction logs and compensation actions; the recovery process uses transaction logs to determine whether incomplete transactions should continue to be committed or perform compensation, thereby avoiding inconsistencies in the two-layer graph versions after service restart.

[0076] Example 3

[0077] like Figure 3 As shown, this embodiment further explains candidate memory retrieval, node binding, context compilation, and execution verification.

[0078] S2.1. At the start of the initial report generation, establish a read-consistent snapshot of the organization's memory bank, recording the memory catalog version, snapshot time, memory identifier, memory version, and lifecycle status.

[0079] Organizational memory snapshots have snapshot identifiers that allow reading of historical versions. Memory additions, updates, promotions, demotions, or invalidations after a task has begun do not alter the visible set within the current task snapshot, thus ensuring that initial generation, output retrospection, and subsequent counterfactual replays use consistent long-term memory boundaries.

[0080] S2.2. Recall the candidate memories by combining the institutional tenant, scope, lifecycle state, target semantic encoding, and template version index.

[0081] The scope can be refined to the level of institution, hospital area, department, role, and report template. The composite index first performs a coarse-grained search to obtain potentially relevant semantic memory, procedural memory, and constrained memory. Episodic memory is only retrieved as a small sample reference when permissions allow and de-identification processing is completed, and it does not directly obtain the priority of ordinary long-term memory.

[0082] S2.3. Apply hard gating to the candidate memory based on the applicable predicate, necessary evidence, exclusion conditions, version compatibility status, candidate memory credibility, and memory conflict status, and resolve conflicts according to mandatory constraints, current task evidence, published baseline rules, memory level, and scope specificity.

[0083] The hard-gating result of the candidate memory can be calculated according to equation (1):

[0084] (1)

[0085] in, Indicates the candidate memory sequence number; Indicates the first Hard-gated results for each candidate memory; An indicator function that takes the value 1 when the condition is true and 0 when the condition is false; Indicates the first Applicable predicates for each candidate memory; Indicates the current task context; Indicates the first The necessary set of evidence for each candidate memory; This represents the set of evidence for the current task; Indicates the first A set of exclusion criteria for candidate memories; Indicates the first Version dependencies of each candidate memory; Represents the current task version vector; symbol This indicates that the preset version compatibility matrix is ​​met; Indicates the first The credibility of calling each candidate memory; Indicates the first The call threshold for each candidate memory type. Only when At this point, candidate memories enter the conflict resolution phase.

[0086] Conflict resolution prioritizes preserving blocking-level mandatory constraints and direct evidence from the current task, followed by published baseline rules, institution-level semantic memories, lower-scope semantic memories, institution-level procedural memories, and lower-scope procedural memories in that order. Candidates at the same level can be ranked according to scope specificity, evidence coverage, signing role permissions, candidate memory credibility, version compatibility, and conflict rate.

[0087] S2.4. Bind the abstract target object in the target memory to the current graph node, and transfer the target memory that cannot be uniquely bound to the memoryless baseline branch or the manual review branch.

[0088] The binding process generates candidate binding maps based on the target semantic encoding, necessary evidence, node type, protected attributes, and graph adjacency relationships. For example, if the target memory requires two independent health analysis items to enter the same presentation group, the compiler searches for two current health analysis item nodes that satisfy the target encoding and evidence conditions, and verifies that the semantic node identifiers of the two nodes are different. If an abstract target corresponds to multiple equivalent candidates and cannot be disambiguated by evidence paths or protected attributes, automatic binding is not performed.

[0089] S2.5. Generate the memory execution plan from the same target memory, which has the bound target, graph operator, preconditions, invariants and rollback information, the model input context with priority, necessary actions and prohibited actions, and the output verification rules with expected results and prohibited operations.

[0090] The memory execution plan can be organized as a directed acyclic plan. Plan nodes include control item identifiers, target graphs, whitelist graph operators, bound targets, parameters, preconditions, invariants, dependent nodes, and compensation actions. Semantic memories are primarily compiled into deterministic graph actions acting on the report semantic graph; procedural memories are compiled into deterministic graph actions and expression instructions acting on the report presentation graph; constraint memories are compiled into blocking rules. The model input context stores structured conditions of "must execute," "suggest execution," and "prohibit execution," and carries bound nodes and evidence references. Output validation rules are generated from invariants, prohibited actions, and expected results of the same target memory, thus verifying whether the target memory is actually executed, rather than simply checking whether the generated text contains similar words.

[0091] The memory application package is essentially an executable instance of the target memory on the current task graph, rather than a copy of the original content of the target memory. The target memory stores cross-task abstract objects and abstract relationships, while the memory application package stores the current task node identifier, evidence identifier, and graph version. A memory application package may include an application package identifier, source memory identifier and version, binding mapping, memory execution plan, model input context, output validation rules, target graph version, expiration date, and rollback pointer. The application package identifier is jointly determined by the task identifier, source memory version, binding mapping summary, and target graph version, enabling the same memory to generate isolated execution instances on different tasks or different graph versions.

[0092] Specifically, node binding can sequentially complete candidate discovery, type filtering, evidence filtering, attribute filtering, adjacency filtering, and uniqueness determination. Candidate discovery retrieves candidate nodes from the current report semantic graph based on the semantic encoding of the abstract target. Type filtering excludes candidates with inconsistent atomic, composite, or knowledge node types. Evidence filtering checks whether necessary evidence can reach the candidate node along the evidence-supporting edges. Attribute filtering compares protected attributes such as object location, side, quantity, form, degree, and inspection method. Adjacency filtering checks whether candidate nodes have parent-child, mutually exclusive, or co-presentation relationships required by the target memory. A definite binding is formed when only one candidate remains after filtering; if there are still two or more candidates, they are sorted according to evidence path coverage and graph adjacency consistency, but if the best candidate and the second-best candidate cannot be significantly different, it is still considered a non-unique binding.

[0093] In a binding example, the candidate program memory requires configuring two independent health analysis items of type A and type B into the same presentation group, requiring that they have evidence types EA and EB respectively. The current task has three semantic nodes: A1, A2, and B1. A1 has EA and retains the required attributes, A2 lacks EA, and B1 has EB. The compiler first binds abstract target A to A1 and abstract target B to B1, then generates grouping actions acting on the presentation graph. If both A1 and A2 have EA and their protected attributes, evidence paths, and adjacency relationships are indistinguishable, the compiler does not randomly select a node but marks the control item as binding ambiguity and maintains the original presentation state of the two health analysis items.

[0094] Each plan node in the memorized execution plan can store a read set, a write set, and a preceding graph version. The read set lists the evidence nodes, semantic nodes, and knowledge nodes upon which node bindings and conditional judgments depend, while the write set lists the graph nodes and edges that can be added or modified. Before execution, the graph processor checks whether the read set version is still consistent with the compile-time version; after execution, the verifier checks whether the actual write set is a subset of the permitted write set. The generation tool can only read the already parsed model input context and cannot expand the write set. This read-write set constraint gives the memorized compilation results a clear boundary of action and allows version drift in concurrent tasks to be detected before graph transactions are committed.

[0095] The three compilation outputs have a common origin. If the memory execution plan requires grouping two independent health analysis items, the necessary actions in the model input context must be synchronized to output two independent items according to the established grouping; action synchronization is prohibited, and the creation of composite health analysis items is prohibited. Output verification rule synchronization requires that the original semantic node identifier, evidence reference, and protected attributes remain unchanged. Since all three outputs are generated from the same target memory and the same binding mapping, when any target object or condition changes, the compiler will regenerate all three outputs simultaneously, avoiding situations where the graph actions have been updated but the generation or verification conditions remain in the old version.

[0096] S2.6. Execute deterministic graph actions in graph transactions, pass the model input context to the report generator through structured request fields or message interfaces, and verify the returned results according to the output verification rules.

[0097] The report generator can be a large language generation model, a specialized text generation model, a rule engine, a template engine, or a combination thereof. A structured request must include at least a task identifier, an institutional memory snapshot identifier, bound semantic nodes, a presentation plan, evidence references, a parsed model input context, mandatory constraints, a version vector, a generation configuration, and an output mode. The generator only generates representations within the semantic nodes and presentation plans of executed graph actions and does not have direct write permissions to long-term memory. Upon verification failure, the system executes compensatory actions according to the rollback information in the memory execution plan and can switch to a memoryless baseline branch.

[0098] In the implementation of the report generator as a large language generation model, the model input context can be split into fixed system conditions, institutional-level expression conditions, current task evidence summary, and structured output mode. Fixed system conditions declare that the output can only reference the semantic nodes and evidence given in the request; institutional-level expression conditions come from the compiled program's memory; the current task evidence summary only provides de-identified fields related to the target node; the structured output mode specifies fields such as report item identifier, semantic node identifier, presentation group identifier, evidence reference, and display text. The decoding temperature can be set from 0 to 0.3, with 0 and a fixed random seed preferred in tasks requiring counterfactual replay. The model's returned results are first parsed into structured objects before participating in two-layer graph verification; free text that fails to be parsed is not directly included in the formal report data package.

[0099] In implementations where the report generator is a rule engine or a template engine, the model input context is converted into template variables, conditional branches, and prohibited output fields. The memory execution plan is still deterministically executed by the graph processor, and the output validation rules are still validated in the same way. This alternative implementation demonstrates that memory context compilation does not depend on any particular generative model; the generation tool only changes the implementation path of the natural language expression, without altering the node bindings, graph action boundaries, and homology verification mechanisms of the target memory.

[0100] The validator can perform short-circuit checks in the order of "application identifier—graph action—evidence citation—attribute preservation—prohibited operation—output mode". If a previous step fails, subsequent checks that depend on the previous step are not executed, and the cause of failure is located to the corresponding planned node. For cases where the applied memory identifier is missing but the graph action result is correct, the retrospective check is still deemed to have failed; for cases where the applied memory identifier is declared but the graph action has not occurred, the consistency check is deemed to have failed; for cases where both the graph action and the identifier are correct but the displayed text is missing protected attributes, only the expression write of the corresponding report item is rolled back, and irrelevant nodes are not rolled back. This hierarchical processing can limit the scope of failure repair to the minimum necessary subgraph.

[0101] Example 4

[0102] This embodiment further explains the stable anchor point and output verification.

[0103] S2.7. Each visible report item in the initial report data packet carrying a stable anchor point is associated with a report item identifier, a semantic node identifier, a presentation group identifier, an evidence reference, and a semantic hash; the initial report data packet also includes an applied memory identifier, an institutional memory snapshot identifier, a candidate memory version, a generation configuration identifier, and an output mode.

[0104] Report item identifiers distinguish visible items in the current report; semantic node identifiers locate health analysis items in the report's semantic graph; presentation group identifiers locate display groups in the report's presentation graph; evidence references point to versioned evidence nodes; semantic hashes are calculated from normalized semantic encodings, protected attributes, and evidence references. Stable anchors can be transmitted as hidden fields along with the visible report text, or they can be returned separately through the revision log. Generation configuration identifiers further associate decoding methods, random seeds, or deterministic template versions to support traceability of the generation process and counterfactual replay.

[0105] The technical role of stable anchors is to establish persistent connections between visible text and the two-layer graph and source evidence, independent of display names. When display names are rewritten, delimiters are replaced, or the presentation order changes, the report item identifier and semantic node identifier remain unchanged. When health analysis items undergo semantic synthesis, splitting, or changes in evidence dependencies, a new semantic hash is generated, and the graph editing relationship with the old nodes is preserved. Therefore, the system does not need to rely solely on character similarity as the sole basis for correspondence; it can first determine whether the change occurred at the presentation layer or the semantic layer, and then select the appropriate learning path.

[0106] When the audit client only retains the report item identifier and does not return other anchor fields, the computer device can recover the semantic node identifier, presentation group identifier, evidence reference, and semantic hash based on the anchor mapping in the initial report data packet. When the report item identifier is also lost but the revision log retains the operation position, the candidate range can be narrowed down first based on the paragraph position and adjacent unmodified anchors, and then backup graph matching can be performed. When only plain text is returned, all correspondences enter the backup graph matching and ambiguity gating described in Example 6. The recovered fields are marked with the recovery source and recovery trust status, and are not confused with the stable anchors originally returned by the client.

[0107] The input to a semantic hash can be ordered semantic encoding, protected attributes sorted by attribute name, evidence citations sorted by evidence identifier, and a version of the semantic combination rule. Presentation group identifiers and display names are not included in the semantic hash; therefore, simple presentation modifications will not change the semantic hash. When the evidence version, protected attributes, or semantic combination rule changes, the semantic hash changes accordingly. To avoid serialization differences between different implementations, a unified character encoding, null value representation, and array sorting rule are used before hash calculation, and the hash algorithm version is saved.

[0108] S2.8. Verify whether the applied memory identifier is consistent with the memory execution plan.

[0109] The validator compares the applied memory identifiers returned by the report generator with the control item identifiers in the memory execution plan, and checks whether the corresponding deterministic graph actions have been committed in the common graph transaction. Cases with unknown memory identifiers, missing necessary memory identifiers, or only declarations of application without corresponding graph results are all considered failures.

[0110] S2.9. Verify whether the semantic node identifier and the evidence reference exist in the current task context.

[0111] The validator uses the evidence visibility set and report semantic graph version stored in the task state manager to check the existence of nodes. If a report item references a node that was not visible in the initial task, an evidence node that has been replaced and is unavailable, or a node that does not belong to the current organization's scope, the corresponding report item will not be included in the submission results.

[0112] S2.10. Verify that each visible report item in the report presentation graph references a valid health analysis item node.

[0113] Presentation graph nodes must be connected to the report semantic graph via semantic node identifiers, and the referenced health analysis item nodes must be in a displayable state. A presentation group can reference multiple independent health analysis item nodes, but the group itself is not interpreted as a new health analysis item node. After a semantic node is split or combined, presentation references must be updated synchronously within the same graph transaction.

[0114] S2.11. Verify whether the protected attributes, knowledge base, and graph transaction invariants satisfy the corresponding mandatory constraints.

[0115] Protected attributes can include object location, side, quantity, size, shape, classification, degree, inspection method, and time attributes. Name compression, semantic combination, and presentation merging must not result in the unfounded loss of protected attributes. When explanations or prompts require knowledge-based evidence, the validator simultaneously checks the knowledge node version, applicable conditions, and validity status.

[0116] S2.12. If any check fails, roll back the corresponding graph transaction and perform a memoryless rollback, replanning, or partial recalculation of the failed node.

[0117] Blocking-level failures cause the entire corresponding graph transaction to roll back; failures affecting only a single report item's evidence or expression can add the failed node to a new local plan, while other verified nodes remain unchanged. For binding ambiguities or high-impact rule conflicts, the system outputs a manual review flag, without obtaining a superficial pass result by relaxing mandatory constraints.

[0118] Example 5

[0119] like Figure 4 As shown, this embodiment further illustrates counterfactual replay in cases where the source data or version has changed.

[0120] S3.1. Obtain the final state source data snapshot and final state version vector at the corresponding moment of the authoritative final state report.

[0121] During the initial generation phase, the system saves an initial source data snapshot, an initial snapshot hash, an initial version vector, an institutional memory snapshot identifier, and an initial generation configuration. After the final report is confirmed, the system saves a final source data snapshot, a final snapshot hash, and a final version vector under the same task identifier to avoid inferring whether input changes occurred during the review process based solely on the report text.

[0122] S3.2. When the snapshot hash of the final source data snapshot is different from that of the initial source data snapshot, or when the final version vector is incompatible with the initial version vector, the initial generation process is replayed using the final source data snapshot and the version parameters in the final version vector other than the institutional memory catalog version.

[0123] The version compatibility matrix categorizes version relationships into fully compatible, partially compatible, and incompatible. Fully compatible changes at the expression layer do not trigger a global replay; partially compatible changes determine the replay subgraph based on dependencies; when data, reference scope, terminology, rules, knowledge, templates, or generative models undergo incompatible changes, the corresponding generative path is replayed. The institutional memory catalog version does not use the final version but is fixed by the initial institutional memory snapshot.

[0124] S3.3. When replaying the initial generation process, use the snapshot of the organization memory at the time of initial generation and reuse the decoding parameters, random seed or deterministic template version in the initial generation configuration, without reading memories that have been added, promoted, updated or invalidated since the initial generation.

[0125] This process allows counterfactual replay to modify only the source data and the runtime version that needs to be replaced, without introducing new memories generated during the audit period from the same or other tasks into the baseline. For generators that support deterministic decoding, a temperature of 0, a fixed random seed, and a fixed tool version can be used; for template engines, deterministic template versions and the same input sorting can be reused.

[0126] Counterfactual replay can be performed in an isolated replay context. This replay context replicates the execution plan structure, tool whitelist, institutional memory snapshot identifier, and generation configuration of the initial task, but replaces the source data entry with the final-state source data snapshot, and replaces the dimensions in the version vector that need to be aligned to the final state with the final-state version. The replay context read-only accesses the initial institutional memory snapshot, does not write support counts, conflict counts, or lifecycle states to long-term memory, and does not trigger the generation of new contextual memories, thus avoiding a self-reinforcing loop of "generating new learning feedback to construct a learning baseline."

[0127] Specifically, before replaying, a version replacement list is generated based on the version compatibility matrix. When the data version and reference scope version change, replay starts from the evidence construction node; when the terminology version changes, replay starts from the semantic node that depends on the corresponding term mapping; when the report template version changes, only the presentation diagram and expression node are rebuilt; when the generated model version changes and is marked as incompatible, replay starts from the structured generation node. If multiple dimensions change simultaneously, the union of the nodes affected by each dimension is taken as the replay starting set, and the process is extended downstream according to the execution plan dependencies to avoid indiscriminately re-executing all tools.

[0128] The reproducible information saved in the initial generation configuration includes at least the generation configuration identifier and may include decoding strategy, temperature, candidate truncation parameters, random seed, tool version, and deterministic template version. For cases where the return order of external tools may change, the tool results are sorted by a stable key before replay. For time-related fields, the task time recorded in the final state source data snapshot is used instead of the actual execution time during replay. For external knowledge queries, the knowledge version specified by the version vector or the corresponding historical snapshot is used. These measures reduce runtime noise in the replay results that is irrelevant to the input facts.

[0129] S3.4. The replay results are identified as the learning baseline report, and differences that can be explained by source data or version changes are marked as data-induced differences.

[0130] For example, if a certain inspection item is not present in the initial source data but is added to the final source data, and counterfactual replay has generated a health analysis item node corresponding to that inspection item, then the addition of this node relative to the initial report is explained by data change and is not converted into institutional semantic preferences. Only the two-layer graph differences that still exist between the learning baseline report and the authoritative final report are included in the editing category.

[0131] Data-induced discrepancies can save changed evidence nodes, affected semantic nodes, before-and-after graph versions, and discrepancy attribution types. If a final-state edit is affected by both data changes and manual revisions, the system first marks the graph edit between the learning baseline report and the initial report as the data-induced part, and then treats the remaining graph edit between the authoritative final-state report and the learning baseline report as the unclassified part, without simply marking the entire final-state report item as learnable or unlearnable. For example, if new health analysis items are generated after adding evidence to the final-state source data, and the reviewer only adjusts the presentation order of the new health analysis items, then the node addition can be classified as a data change event, while the order adjustment can still be classified as a presentation preference event.

[0132] In another example, the final state version vector only changes the report template version. After counterfactual replay, the paragraph positions and separators are consistent with the authoritative final state report, while the health analysis item nodes, evidence citations, and protected attributes remain unchanged. In this case, the presentation differences explained by the template change do not increase the number of support counts for the candidate program memory. If the authoritative final state report configures two independent health analysis items into the same group in addition to the new template results, and this grouping operation was not automatically generated by the new template, then the grouping operation still enters the subsequent learning permission gating.

[0133] S3.5. When the report generation tool cannot reproduce the results definitively, compare the differences between the normalized report semantic graph and the report presentation graph, and exclude wording differences that do not change the graph nodes, graph relationships, and protected attributes.

[0134] Normalization can unify synonym mapping, whitespace, punctuation, and semantically unrelated formats. If two generated texts are different, but the semantic nodes, presentation groups, evidence citations, knowledge bases, and protected attributes are completely consistent, the corresponding differences are marked as non-learning phrasing fluctuations to prevent random decoding noise from entering the learnable event set of contextual memory.

[0135] For generation tools that cannot be reproducibly determined, a replay strategy can be used for normalized two-layer graph comparison. The system performs 2 to 5 generation iterations within the same replay context, identifying consistent semantic nodes, evidence citations, and presentation relationships across all repetitions as stable graph components, and identifying those that fluctuate only in the displayed terminology as unstable representations. If inconsistencies appear in the repetitions regarding semantic nodes or protected attributes, the corresponding generated nodes are marked as unsuitable as automatic learning baselines. The system then uses a structured baseline generated by a rule engine or template engine, or proceeds to manual review. This strategy does not substitute the majority of generated texts for the authoritative final state, but only uses it to determine whether the counterfactual baseline possesses sufficient graph structural stability.

[0136] After counterfactual replay is completed, a replay list and an exclusion list are saved. The replay list records the source data snapshot, version dimension, tool version, and generation configuration that were replaced; the exclusion list records graph edits that were determined to be data-induced discrepancies or non-learning wording fluctuations. Each learnable event in subsequent episodic memories can be traced back to the remaining graph edits not in the exclusion list, thus providing verifiable evidence for tracing the source of candidate long-term memories.

[0137] Example 6

[0138] This embodiment further explains the two-layer graph matching with priority given to stable anchor points.

[0139] S3.6. Prioritize matching of report items in the learning baseline report and the authoritative final state report based on the report item identifier and the semantic node identifier.

[0140] When the audit client returns a complete stable anchor point, report items with the same report item identifier and semantic node identifier are directly established in a one-to-one correspondence. If the report item identifier changes but the semantic node identifier and semantic hash remain the same, the semantic correspondence is maintained and the change is interpreted as a presentation layer reconstruction. If the semantic node identifier is the same but the semantic hash is different, the check continues to examine whether the evidence citation or protected attribute has changed, rather than directly identifying it as the same semantic state.

[0141] S3.7. For unmatched report items, generate candidate node pairs according to semantic encoding, object category, protected attribute, inspection source, and evidence intersection.

[0142] Candidate generation first filters out nodes that cannot be matched using semantic encoding and object category. Then, it performs attribute gating based on object location, side, quantity, shape, degree, inspection method, and time attributes. Finally, it calculates the intersection of evidence citations. Nodes with the same source but different object categories will not become candidates solely because of text similarity; nodes with the same semantic encoding but mutually exclusive protected attributes require the existence of legal attribute transformation rules to enter subsequent matching.

[0143] Candidate node pair generation can employ a hierarchical blocking key to reduce the comparison scale. The first-level blocking key consists of the object category and the inspection source type, used to exclude node combinations that cross categories, cross sources, and lack mapping rules. The second-level blocking key consists of the semantically encoded superclass and object part, used to retain synonymous, superordinate, or combined candidates. The third level compares the intersection of protected attributes and evidence. Assuming that the learning baseline report and the authoritative final state report each have one hundred nodes, direct pairwise comparison would require generating ten thousand node pairs. Through hierarchical blocking, the number of candidates can be limited to a subset with similar semantics and evidence associations, thereby reducing the processing load of matching cost calculation and hyperedge enumeration.

[0144] Attribute gating does not require all attribute text to be identical; instead, it selects comparison rules based on attribute type. Enumerated attributes require identical text or a published mapping relationship; numerical attributes can be compared by unifying units and comparing numerical ranges; set attributes compare intersections and inclusion relationships; and time-based attributes compare observation windows. When a protected attribute is missing on one side, mutual exclusion is not directly determined; instead, the attribute conflict threshold is increased and the automatic learning qualification is reduced. Only when attributes on both sides clearly conflict and there is no valid conversion rule are the corresponding node pairs set as unmatchable.

[0145] S3.8. Calculate the matching cost of each candidate node pair based on encoding similarity, text similarity, evidence overlap, attribute conflict, relation difference, and node type difference, and set the matching cost of protected attribute mutually exclusive node pairs that do not have legal conversion rules as the blocking value.

[0146] The matching cost of candidate node pairs can be calculated according to equation (2):

[0147] (2)

[0148] in, Indicates nodes in the learning baseline report Nodes in the authoritative final state report The matching cost between them; Represents a node With nodes Semantic encoding similarity; Represents a node With nodes Normalized text similarity; Represents a node With nodes The degree of overlap in evidence; Represents a node With nodes The amount of protected attribute conflicts; Represents a node With nodes The difference in adjacency relationships; Represents a node With nodes The amount of difference in node types; to These represent the non-negative weights of the six matching features mentioned above; Indicates the matching feature index, and In one example, to The values ​​were successively set to 0.22, 0.18, 0.25, 0.20, 0.10, and 0.05; all matching features were normalized to 0 to 1. If protected attributes such as lateral, object location, or inspection method are mutually exclusive and no valid conversion rule exists, then... Set to infinity or a pre-defined unmatchable upper bound.

[0149] Matching weights can be configured using historical node pairs that have already undergone anchor point recovery and manual verification. Configuration data is divided into parameter selection and validation sets based on institution and time, preventing different revision nodes for the same task from simultaneously entering both parts. The parameter selection process searches for weight combinations that reduce the false match rate while maintaining sufficient weight for conflicting protected attributes. The validation set is used to determine the upper bound of the same semantics, the interval for further verification, and the lower bound for adding or deleting candidates. When there is insufficient institutional data, a general initial weight can be used with a higher ambiguity threshold, and the weight version is updated as manually verified node pairs accumulate. Each update saves the weight version, validation sample range, and false match statistics, ensuring that historical counterfactual replays still retain the matching configuration used at the time.

[0150] In a numerical example, node With nodes The encoding similarity, text similarity, and evidence overlap are 0.95, 0.90, and 0.80, respectively, while the attribute conflict, relation difference, and node type difference are 0, 0.10, and 0, respectively. Using the above example weights, the matching cost is 0.102, placing them within the same semantic candidate interval. Another candidate node... Although the text similarity is 0.96, the evidence overlap is 0.20 and the attribute conflict is 0.50, significantly increasing the matching cost. This example illustrates that the matching result is not dominated by a single text similarity, but is constrained by both evidence and protected attributes.

[0151] S3.9. Solve one-to-one node matching based on the matching cost, and then solve one-to-many and many-to-one hyperedge matching for subsets of candidate nodes of the same type within a preset combination size.

[0152] One-to-one node matching can be solved using the Hungarian algorithm, minimum-cost maximum flow, or equivalent integer programming. For nodes not included in the one-to-one results, superedge combinations are enumerated within a subset of candidate nodes of the same object category, the same check chain, or with published combination rules. The upper limit of the combination size can be set to 2 to 6; in one example, 4 is chosen to limit the complexity of the combination search. One-to-many and many-to-one results need to store the input node set, output node set, evidence map, and combination rule identifier.

[0153] Hyperedge matching employs a "rule constraint first, cost calculation later" approach. The system first generates allowed input / output cardinality and node type combinations based on published semantic combination or splitting rules. Then, within the allowed combinations, it calculates evidence coverage, attribute preservation, and adjacency changes before and after combination. Node sets without combination rule support, even if the merged displayed text is highly similar, will not be included in the automatic semantic synthesis candidate. When multiple hyperedge candidates share the same node, the node is set as a conflict resource with a capacity of 1. Combinations with lower total matching cost and no duplicate node usage are selected through minimum cost solution or branch and bound.

[0154] To control the size of the super-edge enumeration, candidate clusters can be first divided according to common object categories, common knowledge applicability relationships, or common higher-level semantic codes. Only subsets of 2 to the maximum combination size are enumerated within each cluster. A larger maximum combination size allows for the identification of more many-to-one relationships, but also increases computational complexity and the risk of incorrect combinations. For common small-scale combinations in medical examination reports, a value of 3 or 4 is usually sufficient to cover the main combination forms. Edits exceeding the maximum combination size do not automatically form long-term memory but are retained as contextual memory, requiring manual confirmation of the splitting method.

[0155] S3.10. When the difference between the optimal matching cost and the suboptimal matching cost is less than the ambiguity threshold, the corresponding candidate node pair is marked as an ambiguous match and automatic learning is prevented.

[0156] The ambiguity threshold can be set from 0.02 to 0.10 based on the misalignment rate on the validation set; in one example, it is set to 0.05. When the matching costs of the best and second-best candidates are close, the system retains both candidates and their corresponding evidence paths, outputs a flag indicating that the matching result is pending review, and prohibits the accumulation of positive support counts in the candidate's long-term memory.

[0157] S3.11. Graph editing operations that generate new health analysis item nodes or change evidence dependencies are classified as semantic graph editing events, and graph editing operations that only change the presentation grouping, name format, relative order, separator, or paragraph layout are classified as presentation graph editing events.

[0158] For example, if two atomic health analysis items still use the original semantic node identifiers and retain their respective evidence references, but are placed in the same presentation group and use a preset delimiter, a presentation graph edit event is generated. If two input nodes generate new semantic node identifiers using published combination rules, and the new nodes save sub-item mappings, common applicable conditions, and evidence dependencies, a semantic graph edit event is generated. This classification is based on whether graph nodes and edges change, not on whether connectors appear in the final displayed text.

[0159] The two-layer graph editing event can further preserve the minimal editing script. Operators in the semantic graph editing script can include creating semantic nodes, deleting semantic nodes, connecting evidence-supporting edges, disconnecting evidence-supporting edges, establishing semantic combinations, and splitting semantic combinations; operators in the presentation graph editing script can include creating presentation groups, moving display items, changing name formats, changing relative order, changing separators, and adjusting paragraph layout. Each operator records the object version before the operation, the object version after the operation, input nodes, output nodes, and evidence references. The minimal editing script serves both as the editing trajectory of episodic memory and as the source of candidate long-term memory graph actions.

[0160] The distinction prevents the display structure from contaminating the semantic structure. If the reviewer moves two independent health analysis items to the same group, the editing script only includes the presentation grouping operation, and the invariants of the candidate program memory require that the two semantic nodes and their respective evidence references remain unchanged. If the reviewer transforms the two input nodes into a new health analysis item according to the published rules, the editing script includes the semantic combination operation, and the candidate semantic memory must simultaneously preserve the necessary evidence, exclusion conditions, and sub-item mappings. Even if the rendered visible text of the two types of events is the same, they form isolated candidate memories due to differences in the target graph, operators, and invariants.

[0161] Example 7

[0162] This embodiment further explains the learning permission gating and candidate long-term memory generation for graph editing events.

[0163] S4.1. Classify the reasons for revisions in graph editing events into data change events, case-specific events, format repair events, presentation preference events, health analysis strategy events, knowledge update events, or pending events.

[0164] The cause classifier can combine source data differences, two-level graph operation types, cause codes in audit logs, knowledge version changes, and operation roles to generate classification results. Events whose causes cannot be determined by existing evidence are marked as pending events. Formatting correction events only involve punctuation, blanks, or typos; health analysis strategy events change semantic combinations, evidence dependencies, or suggest applicable conditions; presentation preference events only change the report presentation graph.

[0165] Cause classification can be prioritized using interpretable rules. Events that match the data-induced difference list are directly classified as data change events; those involving only punctuation, spaces, and character replacements that do not change anchor points are classified as format repair events; edits that only affect the report presentation graph and repeatedly appear in different tasks are classified as presentation preference candidates; edits that change the report semantic graph but lack published knowledge or rule basis are first classified as pending events. When rules cannot uniquely classify an event, the system retains all candidate causes and judgment criteria, and does not enter the automatic learning path with a low-confidence classification.

[0166] Optionally, the cause classifier can also employ a supervised classification model. Training samples are derived from desensitized contextual memories whose causes have been confirmed by authorized personnel. Each sample includes source change features, version change features, graph edit operator counts, target graph type, protected attribute changes, revision role, and log cause encoding. The output is the cause category. Before training, duplicates are removed according to task identifiers, and the dataset is divided into training, validation, and test sets by time. Revision branches for the same task only enter one dataset. Gradient boosting trees or classification networks with structured input interfaces can be used. When there is class imbalance, the loss weights are increased for pending events and case-specific events. Training iterations stop when the macro-average F1 score on the validation set no longer improves for 5 to 10 consecutive rounds, and the model version and feature dictionary version are recorded together.

[0167] In an exemplary training configuration, approximately 10,000 desensitized map editing events are used, with the training, validation, and test sets divided at 70%, 15%, and 15% respectively. The gradient boosting tree depth is set to 4 to 8, the learning rate to 0.03 to 0.10, and the number of weak learners to 100 to 500. The classification model serves only as an auxiliary tool when rules are unresolved; events remain unresolved when the model outputs a class probability below 0.80 or the difference between the probabilities of the first and second classes is less than 0.15. Model predictions do not modify the source change filtering results, nor can they rewrite conflicting events as learnable events.

[0168] S4.2. For each figure editing event, record the learning permission flag, case-specific flag, source change filtering status, revision source, and editing trajectory.

[0169] Learning permission indicators are determined by reason category, authority, evidence integrity, and constraint conflict. Case-specific indicators can be explicitly given in the review log or set when the event only applies to temporary conditions for a single task and lacks reusable predicates. The editing trajectory saves the graph object before editing, graph operators, operation parameters, the graph object after editing, and the corresponding revision node.

[0170] Revision sources can be categorized into direct manual editing, batch template application, upstream data synchronization, knowledge rule updates, and system automatic rollback. Edits from system automatic rollback are not considered as human preference support; edits from batch template application require recording the template version to avoid repeatedly counting changes from the same batch of template upgrades as multiple independent supports; events from direct manual editing still need to undergo source change filtering and case-specific judgment. By saving the source type, the subsequent effective support count can reflect the true repetition in independent tasks, rather than batch copying of the same automated operation.

[0171] S4.3. Write each graph editing event, along with the learning baseline report, the authoritative final state report, the corresponding source data snapshot summary, and the revision branch, into the context memory.

[0172] Contextual memories are appended to and saved on a task-by-task basis, and are not overwritten by subsequent reports. Source data snapshot summaries can save only de-identified evidence citations, snapshot hashes, and version vectors to reduce the amount of sensitive information stored long-term. Revision branches save parent node relationships and authority status, ensuring that multiple revisions to the same task are not treated as multiple independent sources of support.

[0173] Episodic memory writing employs a separation of immutable event records and variable indexes. The immutable records store the baseline, final state, edit scripts, and version dependencies at the time of writing; the variable index stores whether the episode was used in a candidate long-term memory, whether it was later marked as conflicting, and whether it ceased participation in replay due to version expiration. Error correction of episodic memories is accomplished by adding correction records without overwriting the original records, thus preserving the actual set of evidence used during the promotion of candidate long-term memories.

[0174] S4.4. Only graph editing events with a true learning permission flag, a false case-specific flag, and that do not belong to data change events, unfinished knowledge update events, or pending events are converted into candidate semantic memories or candidate program memories.

[0175] Data change events have already been absorbed by the learning baseline and do not carry institutional preference implications; case-specific events lack cross-task reuse conditions; knowledge update events that have not yet been published need to enter the knowledge publication process first; pending events lack verifiable causes. These events can be retained as situational evidence or conflict samples, but will not enter the automatic promotion path.

[0176] S4.5. Write the combined operation that generates new health analysis item nodes into the candidate semantic memory, and write the presentation grouping operation that retains the original health analysis item nodes and evidence citations into the candidate program memory.

[0177] Candidate semantic memory stores at least the input node type, combined predicates, necessary evidence, exclusion conditions, output node type, sub-item mappings, and knowledge dependencies. Candidate program memory stores at least the target node type, presentation grouping actions, name format, relative order or paragraph template, and invariants that prevent changes to semantic nodes. Thus, the same visible text can enter different memory layers based on differences in graph structure.

[0178] S4.6. Write the rules for protected attribute preservation, access restrictions, and evidence integrity into the independently published constraint memory, and prohibit the automatic modification of the constraint memory by a single graph edit event.

[0179] Constraint memories must undergo schema validation, static conflict checking, history replay, authorization confirmation, and version signing before entering the release state. Constraint memories have higher priority than candidate semantic memories and candidate program memories. Low-privilege revisions cannot reduce the severity of blocking constraints, nor can they override protected attribute preservation rules by increasing the number of support iterations.

[0180] Example 8

[0181] like Figure 5 As shown in the figure, this embodiment further illustrates the positive and negative example playback and promotion of candidate long-term memory.

[0182] S4.7. Configure the candidate long-term memory with memory identifier, memory type, life cycle state, scope, applicable predicate, target graph object, graph action, necessary evidence, exclusion conditions, graph invariants, version dependency, and source tracing.

[0183] Memory types can include candidate semantic memories and candidate procedural memories, and lifecycle states can include candidate, observed, effective, downgraded, pending review, and invalid. Source tracing preserves contextual memory identifiers, learning baseline snapshot hashes, authoritative final state revision nodes, and confirmation records; version dependencies include at least the versions of terms, baseline rules, knowledge, report templates, constraint sets, and graph actions in the generative model.

[0184] S4.8. Select positive examples from historical context memory that satisfy the scope, the applicable predicate, the necessary evidence, and the version dependency, and select near mismatch negative examples that are missing a necessary condition, meet an exclusion condition, or are version incompatible.

[0185] Near-mismatch counterexamples are not arbitrary negative samples, but rather tasks that have similar semantic node types and presentation structures to matching positive examples, and fail to meet the candidate long-term memory requirement only on one decisive condition. Selecting such counterexamples allows for direct testing of gating boundaries. For example, if candidate program memory requires both health analysis item A and health analysis item B to have complete evidence and compatible template versions, then tasks lacking necessary evidence for health analysis item B or with incompatible template versions can serve as near-mismatch counterexamples.

[0186] Near-mismatch counterexamples can be obtained in three ways. The first is by retrieving real tasks from historical contextual memories that have a similar graph structure to the matched positive example but failed gating. The second is by controlling the masking of the matched positive example, removing a necessary evidence reference or replacing a version dependency with a known incompatible version, creating a derived counterexample that changes only one key condition. The third is by selecting one condition from the exclusion criteria of candidate long-term memories and retrieving matching instances from historical tasks with similar node combinations. Derived counterexamples are only used for replay gating verification; they are not considered new contextual memories and are not counted towards the number of real task support attempts.

[0187] To prevent overly simplistic counterexamples, near-mismatch counterexamples can be stratified according to their proximity. Level 1 counterexamples lack only one necessary piece of evidence; Level 2 counterexamples have all necessary evidence but conflicting protected attributes; Level 3 counterexamples have similar graph structures and attributes but are version incompatible. Candidate long-term memories must replay at least all types of near-mismatch counterexamples corresponding to the declared gating conditions. If a certain exclusion condition has no instances in historical data, the candidate long-term memory remains under observation or requires manual confirmation, rather than interpreting "no error triggering" as proof of verified safety.

[0188] S4.9. Perform candidate long memory replay on the matched positive examples and the near mismatch negative examples respectively, and calculate the distance gain of the weighted graph edit distance before and after replay, the near mismatch error trigger rate and the protected attribute retention rate.

[0189] The normalized weighted edit distance of the report semantic graph or report presentation graph can be calculated according to formula (3):

[0190] (3)

[0191] in, Representation type The image to be evaluated Compared with similar authoritative final state diagrams Normalized weighted graph edit distance between them; Pick Time represents the semantic graph of the report, taking The report will display a graph; Representation type The corresponding set of image editing types; Indicates the image editing type sequence number; Indicates the first Non-negative risk weights for class diagram editing; This indicates that the image to be evaluated is... Convert to authoritative final state diagram The required first Minimum number of edits per class; Indicates the first The number of objects that can be edited in a class diagram, and ; This represents a positive smoothing constant to prevent the denominator from being zero. It is relevant to semantic node additions / deletions, changes in evidence dependencies, and semantic combinations. It can be edited larger than the name punctuation. Distance gain is the pre-replay image editing distance minus the post-replay image editing distance; near mismatch error trigger rate is the ratio of the number of near mismatch counterexamples that were erroneously executed in the candidate long memory to the total number of near mismatch counterexamples; protected attribute retention rate is the ratio of the number of protected attributes that were still fully retained after replay to the number of attributes that should have been retained before replay.

[0192] The edit type weights for weighted graph edit distance are configured based on their potential impact. Edits that change evidence dependencies, create or delete health analysis items, and alter semantic composition relationships have higher weights than those that render separators and blanks; edits that lose protected attributes can be set to blocking level, not offset by numerous low-impact rendering improvements. The distance denominator is normalized using the number of actionable objects, allowing tasks with different numbers of nodes to still compare replay gains. Semantic distance and rendering distance can be stored separately. Candidate semantic memory primarily considers semantic distance and requires that the rendering distance not increase abnormally, while candidate program memory primarily considers rendering distance and requires that the semantic distance remain zero.

[0193] A complete replay establishes an independent temporary graph for candidate long-term memories. First, the baseline path without applying candidate long-term memories is run, and the distance before replay is recorded. Then, the candidate long-term memories are applied through the same gating, binding, compilation, graph transactions, and output verification process as the formal task, and the distance after replay is recorded. If a candidate long-term memory can only gain distance gains by bypassing a certain formal verification step, the replay is considered a failure. All positive examples and near-mismatch negative examples use a fixed graph matching configuration and a fixed distance weight version to ensure that the results of the same round of replays are comparable.

[0194] S4.10. Count the number of valid support and valid conflict according to different tasks, and calculate the credibility of candidate memories by combining evidence completeness, distance gain, signing role permissions, independence of support source, version adaptability and time decay.

[0195] The reliability of candidate memories can be calculated according to equation (4):

[0196] (4)

[0197] in, Indicates the reliability of candidate long-term memories; Represents the Sigmoid function; Indicates the confidence bias term; to This represents the confidence coefficient corresponding to each input quantity; This represents the effective support quantity after deduplication and normalization according to different tasks; This represents the effective number of collisions after deduplication and normalization according to different tasks. Indicate the completeness of necessary evidence; This represents the average distance gain from matching positive examples; This indicates the score for signing role permissions; This indicates support for the independence of the source; Indicates version compatibility; This indicates the amount of time decay. In one example, Take -2.0, to The values ​​are 1.4, 1.8, 1.2, 1.5, 0.5, 0.4, 0.6, and 0.8 in sequence. The same revision branch in different tasks can accumulate a maximum of one support, and repeated reversals in the same task can accumulate a maximum of one conflict, avoiding the dominance of reliability by the frequency of single-task operations.

[0198] Credibility coefficients can be calibrated using historical candidate memories that have already undergone promotion or demotion confirmation. Calibration samples are calculated per candidate memory, not per individual event; the input is the statistic of the candidate memory at a specific time cutoff point, and the label indicates whether it remains valid during the subsequent observation period. To avoid future information leakage, training samples only use support, conflict, and replay results prior to the time cutoff point. When samples are insufficient, preset coefficients are used, and automatic coefficient updates are not initiated; once the preset number of samples is reached, logistic regression can be used to fit the coefficients, and the consistency between the credibility binning and the actual effective proportion can be verified in independent time periods. The coefficient version is saved along with the promotion rules.

[0199] Effective support for source independence is determined based on task identifiers, revised directed acyclic graphs, and source operation batches. Events from different tasks but generated by the same batch template operation may lower the independence score; identical edits across multiple branches within the same task are counted as only one support; scenarios with different institutional scopes are not directly merged into target institutional support. Time decay is used to reduce the impact of preferences that have not reappeared for a long time on the current task, but blocking-level constraints and published baseline rules do not use the candidate memory time decay method.

[0200] S4.11. When the number of effective support counts, the distance gain, the near mismatch error trigger rate, the protected attribute retention rate, and the candidate memory credibility reach the promotion threshold of the corresponding memory type, and do not conflict with the constrained memory, the candidate long-term memory is consolidated into the institutional long-term memory.

[0201] In one exemplary configuration, candidate semantic memories require valid support from five different tasks, an average distance gain of no less than 0.15, a near mismatch error trigger rate of no more than 0.02, a protected attribute retention rate of 1, a candidate memory credibility of no less than 0.85, and confirmation by an operator with appropriate permissions. Candidate program memories may require valid support from two different tasks, an average distance gain of no less than 0.10, a near mismatch error trigger rate of no more than 0.05, and a candidate memory credibility of no less than 0.70. Both thresholds and calculation rules retain version identifiers and do not limit other implementation methods to example values.

[0202] Promotion is determined by simultaneously meeting all conditions, without compensating for lost protected attributes or excessive near-mismatch error triggering rates with higher confidence levels. Candidate semantic memories with semantic impact or high impact indicators still enter the authorization confirmation queue after passing automatic indicators; candidate program memories that only change delimiters, relative order, or paragraph layout can be automatically promoted according to organizational configuration. Confirmation records save the confirming role, confirmation time, viewed replay summary, and promotion rule version. A new long-term memory version is generated after promotion, and the candidate version continues to be retained as a source tracing object.

[0203] In a candidate program memory example, three different tasks all involved editing to configure health analysis item A and health analysis item B into the same presentation group. After replaying the two positive matches, the presentation distance decreased by 0.20 and 0.18 respectively. None of the three near mismatch negatives were triggered, the protected attribute retention rate was 1, and the confidence level was 0.79. If the program promotion threshold is 0.70, the candidate program memory can enter the active state. Subsequently, if a task lacking necessary evidence is found to have been erroneously triggered, the number of valid conflicts increases, the near mismatch error trigger rate exceeds the threshold, the system generates a downgrade event, and restores the previous active version or baseline presentation path.

[0204] S4.12. Maintain an observation state for candidate long-term memories that have not reached the promotion threshold, downgrade candidate long-term memories that have conflicts, and set a pending review state for candidate long-term memories with incompatible version dependencies.

[0205] Candidate long-term memories in the observation state continue to receive new, independent contextual evidence, but do not enter the default automatic execution path. During downgrades, the previous effective version and the reason for the downgrade are retained to support rollback. After dependency versions are re-compatible, candidates awaiting review can re-execute matching positive examples and near-mismatch negative examples replay on the new version's historical task set, instead of directly restoring the effective version.

[0206] Lifecycle transitions for candidate long-term memories can be event-driven. New features include: independent support for triggering replay of observed states; conflict-triggered immediate review of effective memories; compatibility checks triggered by dependency version releases; conflict scans triggered by constraint memory upgrades; and time decay updates triggered by long-term misses. Each lifecycle transition generates a new memory version and saves the old version, without directly overwriting the state in the original record. Subsequent task snapshots of the organization's memory only read the defined version that is in a callable state at the time of the snapshot, thus ensuring compatibility between downgrades, rollbacks, and history replays.

[0207] Example 9

[0208] like Figure 5 As shown in the figure, this embodiment further explains the determination of the authoritative final state and the version-dependent local recalculation.

[0209] S3.12. Organize two or more report revision versions into a revision directed acyclic graph. Each revision node records the revision identifier, parent node identifier, report hash, two-level graph version, source data snapshot hash, operation role, time, revision reason, signature, and authority status.

[0210] A single save operation creates a revision node; concurrent revisions can share a parent node; merged revisions can have multiple parent nodes. Report hashes and two-level graph versions are used to determine if two revision nodes have the same content state, source data snapshot hashes are used to determine if the revisions are based on the same input, and signatures are used to verify that the revision node has not been tampered with after being written.

[0211] S3.13. A revision node that has a valid signature, the operating role has final review authority, the authority status is true, and there are no subsequent signing replacement nodes is identified as an authority final state node.

[0212] The role permission table is jointly defined by the organization's scope and report type. Nodes created by operational roles that only have editing permissions but not final review permissions are saved as intermediate revision evidence. Subsequent signing of replacement nodes removes the previous authoritative node from its current authoritative status, but the previous node and its graph editing trajectory are still retained for auditing and conflict analysis.

[0213] S3.14. When there are two or more competing authoritative final state nodes, pause the cumulative positive support, retain the unsigned branches as scenario evidence, and record the graph editing operations revoked by the authoritative final state nodes as conflict samples.

[0214] Two authoritative final state nodes have no ancestor relationship and different content, thus forming a competing final state. The system can request an operator with higher authority to select or merge the final states. Before the competition is resolved, related graph editing events do not increase the effective support of candidate long-term memory; edits revoked by the final authoritative node are used to construct conflict samples to prevent the system from only saving the last text and ignoring evidence of reverse revisions.

[0215] S5.1. The local recalculation of the affected subgraph based on the reverse dependency index includes determining the direct impact set according to the dependent objects that have undergone version changes, obtaining the semantic impact closure along the evidence support relationship, semantic composition relationship and knowledge application relationship, obtaining the presentation impact closure according to the semantic node identifier, adding only the nodes in the semantic impact closure and the presentation impact closure to the local recalculation plan, and keeping the text hash of the non-dependent nodes unchanged.

[0216] The key of a reverse dependency index can be an evidence identifier, rule identifier, knowledge identifier, memory identifier, template identifier, or model version identifier. Values ​​include health analysis item nodes that depend on the object, presentation groups, report items, and candidate long-term memories. The direct impact set is obtained through index constant-time or logarithmic-time queries. The semantic impact closure extends along evidence-supporting edges, semantic combination superedges, and explanatory or suggestive applicable edges; the presentation impact closure extends from the semantic node identifier along the presentation reference edge. The local recalculation plan is executed in a new common graph transaction and records the changed objects, affected nodes, old graph version, and new graph version. If only the presentation group memory changes, the report semantic graph version can remain unchanged, and only the corresponding report presentation graph subgraph is updated; if the reference scope changes, only health analysis items that depend on that reference scope and their downstream presentation nodes are recalculated.

[0217] Semantic influence closures can be implemented using queue traversal. The system adds nodes from the directly affected set to the queue, and reads the evidence support outgoing edges, semantic combination outgoing edges, and knowledge application outgoing edges of each node one by one; unvisited downstream nodes are added to the closure and the queue until no new nodes are added. To prevent configuration errors from forming loops, the traversal process records the set of visited nodes and sets a task-level node limit; when a loop relationship is detected, all nodes within the loop are retained as a component to be recalculated, and a graph structure anomaly record is generated. The presentation influence closure only expands along the reference direction from semantic nodes to presentation items, presentation items to presentation groups, and presentation groups to paragraphs, without modifying the semantic graph in the reverse direction.

[0218] Before committing a partial recalculation, a version comparison is performed. If the current version of the node to be recalculated is still equal to the planned previous version, the new result is allowed to be written; if the current version has been updated by other transactions, the current transaction terminates its commit and recalculates the impact closure. For disjoint impact closures, different common graph transactions can be used for parallel recalculation; when two impact closures share semantic nodes or are presented as grouped transactions, they are merged into the same transaction to avoid lost updates due to concurrent writes. After a successful commit, the inverse dependency index and report item text hash are updated; the index items and text hashes that did not enter the closure remain unchanged.

[0219] In a partial recalculation example, the reference range version is updated from R1 to R2, and the reverse dependency index returns semantic nodes A and B. Semantic node A also serves as input to composite node C, and semantic node B has no downstream semantic combination; therefore, the semantic influence closure consists of A, B, and C. In the rendering graph, A and C enter group G1, and B enters group G2. The rendering influence closure further includes the corresponding display item, G1, G2, and their respective paragraphs. The system only reconstructs the above closures; other semantic nodes, rendering groups, and paragraphs do not invoke the generation tool, thus reducing irrelevant text changes caused by version updates.

[0220] When the changed object is program memory and only affects the presentation group, the direct impact set starts from the presentation graph, without needing to traverse evidence support and semantic combination relationships. When the changed object is semantic memory, evidence node, or knowledge node, the semantic impact closure is calculated first, followed by the presentation impact closure. The method of selecting the starting point according to dependency type ensures that semantic changes can be propagated to the display layer, while preventing pure presentation changes from triggering recalculation of irrelevant semantic nodes.

[0221] Example 10

[0222] like Figure 6 As shown, this embodiment provides a dual-layer image editing and memory processing device for physical examination reports.

[0223] The two-layer graph construction module is used to acquire structured physical examination data, form source data snapshots, version vectors and versioned evidence nodes, and construct related report semantic graphs and report presentation graphs.

[0224] The two-layer graph construction module may include a data normalization unit, an evidence versioning unit, a report semantic graph unit, and a report presentation graph unit. The data normalization unit forms a snapshot of deterministic source data; the evidence versioning unit establishes evidence nodes that can be replaced but not overwritten; the report semantic graph unit maintains the relationships between health analysis items and evidence support; and the report presentation graph unit maintains the reference and display structure for health analysis items.

[0225] The memory compilation and generation module is used to recall and gate candidate memories in the institutional memory snapshot, bind the obtained target memory to the current graph node, compile it into a memory application package containing the memory execution plan, model input context and output validation rules, and generate an initial report data package carrying stable anchors.

[0226] The memory compilation and generation module can perform candidate recall through combined indexes, and hard gate control through applicable predicates, necessary evidence, exclusion conditions, version compatibility, and credibility. Then, the memory context compiler generates homologous deterministic graph actions, generation conditions, and verification conditions. Each visible report item output by the module is associated with a report item identifier, semantic node identifier, presentation group identifier, evidence reference, and semantic hash.

[0227] The graph editing recognition module is used to receive an authoritative final state report signed and confirmed by an operator with final review authority, replay the initial generation process for changes in source data or version to obtain a learning baseline report, and perform stable anchor point alignment and two-layer graph matching on the learning baseline report and the authoritative final state report to obtain semantic graph editing events and presentation graph editing events.

[0228] The graph editing recognition module may include an authoritative final state selection unit, a counterfactual replay unit, a stable anchor alignment unit, a backup graph matching unit, and an event classification unit. The backup graph matching unit is configured to solve one-to-one, one-to-many, and many-to-one matching; the event classification unit distinguishes between semantic graph editing events and presentation graph editing events based on whether the graph editing generates new health analysis item nodes or changes semantic dependencies.

[0229] The memory consolidation module is used to write manually revised graph editing events into contextual memory and generate candidate long-term memories. It uses matching positive examples and near mismatch negative examples for replay verification and consolidates the candidate long-term memories that meet the promotion conditions into institutional long-term memories.

[0230] The memory consolidation module stores the scope, applicable predicates, necessary evidence, exclusion conditions, graph actions, graph invariants, version dependencies, and source tracing of candidate long-term memories; it measures distance gains by matching positive examples, measures error triggering rates by matching near mismatch negative examples, and determines the lifecycle state by combining the retention rate of protected attributes, support and conflict statistics, and credibility.

[0231] The memory application and local recalculation module is used to compile and execute the matching institutional long-term memory in subsequent tasks, verify the execution results according to the output verification rules, and perform local recalculation of the affected subgraph based on the reverse dependency index when the version of the dependent object changes.

[0232] The memory application and local recalculation module can reuse the gating, binding, and compilation interfaces of the memory compilation and generation module. The local recalculation unit determines the semantic impact closure and the presentation impact closure based on the dependent objects, updates only the affected nodes in the common graph transaction, and keeps the text hash of the dependency-free report item unchanged.

[0233] In a complete task, the two-layer graph and stable anchor points output by the two-layer graph construction module are passed to the memory compilation and generation module; the semantic graph editing events and presentation graph editing events output by the graph editing and recognition module are passed to the memory consolidation module; the memory application and local recalculation module reuses the gating, binding, and compilation interfaces of the memory compilation and generation module to complete the memory calls for subsequent tasks. When gating fails, target binding is not unique, graph matching is ambiguous, or output verification fails, the corresponding module switches to the memoryless baseline branch or manual review branch, and only performs graph transaction rollback or local recalculation on the failed nodes, without continuing automatic learning or automatic commit.

[0234] Each module in the above-described device can be implemented by a processor executing a computer program stored in memory, or by a programmable logic device, an application-specific integrated circuit (ASIC), or a combination of software and hardware. The division of modules is functional; in actual deployment, one module can be implemented by multiple service instances, and multiple modules can be deployed on the same computing node. When the computer program is executed by the processor, it can implement all or part of the steps of the methods described in Embodiments 1 to 9; a non-transitory computer-readable storage medium storing the computer program is also a viable implementation carrier.

[0235] Example 11

[0236] The process of processing a medical examination report is illustrated using the following example: structured data input, initial report generation, manual review to form an authoritative final report, and identification of editable data for controlled reuse in subsequent tasks. Each step is based on the data objects, two-layer diagrams, memory application packages, and version control mechanisms described in the original application, and does not depend on specific program names, interface paths, source code files, or field names; different software implementations can adopt this implementation method as long as they achieve the same input, processing, and output relationships.

[0237] (a) Business scenarios and input data

[0238] In a report generation scenario at a medical examination institution, computer equipment receives structured medical examination data. Each examination record includes at least a task identifier, examination source, combined items, examination items, examination results, unit, reference range, observation time, and source version; the task identifier uses a de-identified identifier, and personal identification information is not required to be written into the institution's memory.

[0239] (ii) S1: Data Evidence Formulation and Two-Layer Graph Construction

[0240] The computer equipment first standardizes object keys, null values, time formats, numerical formats, units, and reference ranges, saves the normalization result as a snapshot of the source data, and calculates the snapshot hash. Subsequently, the data version, reference range version, terminology version, rule version, knowledge version, report template version, generated model version, and institutional memory catalog version are written into the version vector.

[0241] For each standardized inspection record, computer equipment generates versioned evidence nodes based on field location path, inspection identifier, inspection method, observation time, and source version. Health analysis items and their supporting evidence relationships and semantic combination relationships are written into the report semantic graph; display grouping, naming format, relative order, and paragraph layout are written into the report presentation graph. Each visible report item is simultaneously associated with a report item identifier, semantic node identifier, presentation group identifier, evidence citation, and semantic hash, serving as a stable anchor point for subsequent review and alignment.

[0242] (iii) S2: Controlled memory retrieval and initial report generation

[0243] When the initial report generation begins, the computer equipment freezes a snapshot of the organization's memory and recalls candidate memories according to the organization's scope, lifecycle state, target semantic encoding, and template version. For each candidate memory, the applicable predicate, necessary evidence, exclusion conditions, version compatibility status, credibility, and conflict status are checked in sequence, and then the gated abstract target is uniquely bound to the current evidence node, semantic node, or presentation group.

[0244] After successful binding, the computer device generates a memory application package based on the same target memory and the same binding mapping. This package includes the memory execution plan, model input context, output validation rules, target graph version, and rollback information. The computer device first executes deterministic graph actions and then calls the report generator to form an initial report data package with stable anchors. If the gating fails or the target cannot be uniquely bound, the candidate memory is not used, and the process transitions to a memoryless baseline or a manual review branch.

[0245] (iv) S3: Authoritative final state confirmation and graph editing recognition

[0246] After the reviewer revises the initial report, the system saves the revised version, the operator's role, the time, the signature, and the authority status. Only the version with a valid signature, an operator's final review authority, a true authority status, and no subsequent signing replacement nodes is determined to be the authoritative final report signed and confirmed by an operator with final review authority.

[0247] If new inspection data is added, original fields are corrected, or the reference scope, terminology, rules, knowledge, templates, or generation model version changes during the review process, the computer equipment uses the final source data and the final version parameters that need to be replaced to replay the initial generation process under the initial organization memory snapshot and initial generation configuration to obtain the learning baseline report. Differences between the initial report and the learning baseline report that can be explained by data or version changes are marked as data-induced differences and are not considered as organization preference learning.

[0248] The computer equipment then compares the baseline report with the authoritative final report signed and confirmed by an operator with final review authority. Items with the same report item identifier and semantic node identifier are preferentially matched through stable anchor points; items with missing anchor points are matched using a two-layer graph based on semantic encoding, object category, protected attribute, inspection source, and evidence intersection. Operations that only change the display grouping, name format, relative order, separator, or paragraph layout are identified as presentation graph editing events; operations that generate new health analysis items or change evidence dependencies are identified as semantic graph editing events. When the best match and the second-best match cannot be reliably distinguished, the system retains the candidate relationship and stops automatic learning.

[0249] (V) S4: Candidate Memory Verification and Promotion

[0250] The computer device first categorizes graph editing events into data change events, case-specific events, format repair events, presentation preference events, health analysis strategy events, knowledge update events, or pending events, and records learning permission indicators. Data change events, case-specific events, knowledge update events that have not been published, and pending events are only saved as contextual memories; only events that meet the learning permission conditions are formed into candidate semantic memories or candidate procedural memories.

[0251] Candidate memories are replayed on matching positive examples and near-mismatch negative examples respectively. Matching positive examples satisfy all applicable conditions of the candidate memory; near-mismatch negative examples are missing only one necessary condition, meet one exclusion condition, or have version incompatibility. For example, if the necessary evidence for a candidate memory includes two health analysis items and their corresponding evidence nodes, but the current task only has one of the health analysis items, the task is a near-mismatch negative example that lacks one necessary condition, and the candidate memory should not be triggered.

[0252] After playback, the computer system counts the number of valid supports and valid conflicts, and calculates distance gains, near mismatch error trigger rate, protected attribute retention rate, and candidate memory credibility. Only when all indicators meet the promotion conditions for the corresponding memory type, do not conflict with constrained memories, and complete the required permission confirmation, are candidate memories consolidated into the organization's long-term memories; otherwise, they remain under observation, downgraded, or pending review.

[0253] (vi) S5: Subsequent applications, output verification and local recalculation

[0254] In subsequent tasks, the computer equipment re-executes candidate memory retrieval, gating, and unique binding based on the new task context, and recompiles the memory application package. The report generation results are verified according to the applied memory identifier, graph action, evidence reference, protected attribute, prohibited operation, and output mode; if any blocking condition fails, the system rolls back the corresponding graph transaction and uses a memoryless baseline, replanning, or local recalculation of the failed node.

[0255] When reference scope, terminology, rules, knowledge, report templates, generation models, or institutional memory versions change, the computer device retrieves the directly affected objects through the reverse dependency index, forms an impact closure along evidence support relationships, semantic composition relationships, and presentation reference relationships, and only adds nodes within the closure to the local recalculation plan. Semantic nodes, presentation groups, and report items that are not included in the impact closure retain their original versions and text hashes.

[0256] (vii) Correspondence between code flowcharts

[0257] Figure 7Corresponding to the online generation and final review closed loop of T1 to T3 in this embodiment: the business entry point inspection() receives structured physical examination data, predict() and its preprocessing, retrieval, diagnosis and merging components form an initial report with evidentiary relationships and save a snapshot; after the doctor reviews, the final state data is returned through learning(), and match_snap_item() matches the final state items with the initial snapshot, thereby providing traceable input for the identification of semantic editing and presentation editing.

[0258] Figure 8 Corresponding to the learning verification and controlled reuse in T4 to T5 of this embodiment: final_data_search() recalls historical samples by institution, doctor and conclusion name, can_study() verifies the learning conditions, and check_study() cleans content that is only applicable to individuals; this application further sets up matching positive examples, near mismatch negative examples, promotion threshold, output verification and version impact closure on this business link, so that only the verified memories can be called by predict() in subsequent reports, and failed nodes can be locally regenerated by re_predict().

[0259] The listed code names are only used to illustrate a specific implementation and its running location, and do not constitute new technical features, nor do they constitute a limitation on the scope of protection of the claims.

[0260] (viii) Implementation Results

[0261] Using the implementation method of Example 11, modifications to the display order, grouping, or naming format by reviewers will not be mistaken for new health analysis conclusions; data or version changes during the review period are first absorbed by the learning baseline to avoid spurious learning; candidate memories can only be invoked in subsequent calls when positive examples are valid, near mismatch negative examples are not triggered, protected attributes are complete, and there are no constraint conflicts; when versions change, recalculation can be restricted to the affected subgraphs, while unaffected semantic nodes, presentation groups, and report items retain their original versions and text hashes, thereby reducing the amount of repeated modifications by physicians, avoiding error generalization, and maintaining the traceability between health analysis items and source data evidence.

[0262] The above descriptions are merely preferred embodiments of the present invention. Examples 1 to 11 illustrate feasible implementation methods for two-layer graph construction and evidence versioning, memory gating and homologous compilation, stable anchor points and output verification, counterfactual replay and learning baseline formation, two-layer graph matching and edit event classification, candidate long-term memory replay promotion, authority final state determination and local recalculation, and the overall business process, respectively. The specific data structures, threshold values, algorithm selections, and storage implementations in each embodiment are exemplary configurations and can be combined with each other or adjusted according to the actual task data of the target organization. All equivalent substitutions, modifications, and improvements made based on the technical concept of the present invention should fall within the protection scope of the present invention.

Claims

1. A method for editing and storing two-layer diagrams in a physical examination report, characterized in that, Executed by computer equipment, the two-layer diagram is an interrelated but separately responsible report semantic diagram and report presentation diagram with common graph transaction identifiers and graph version pairs, including: The process involves acquiring structured medical examination data, generating source data snapshots, version vectors, and versioned evidence nodes, and constructing associated report semantic graphs and report presentation graphs. Specifically, this includes: normalizing object keys, null values, time, numerical values, units, and reference ranges in the structured medical examination data to form normalized data objects; calculating snapshot hashes for the normalized data objects and writing data versions, reference range versions, terminology versions, baseline rule versions, knowledge versions, prompt template versions, report template versions, generation model versions, and institutional memory catalog versions into the version vector; generating versioned evidence nodes according to field location paths, inspection identifiers, inspection methods, observation times, and source versions, retaining evidence nodes from different sources corresponding to the same health information object, and connecting the evidence nodes before and after correction using substitution relationships; establishing health analysis item nodes, evidence support relationships, and semantic combination relationships in the report semantic graph; and establishing references, presentation groupings, name formats, relative orders, and paragraph layouts for the health analysis item nodes in the report presentation graph; and configuring common graph transaction identifiers and graph version pairs for the report semantic graph and the report presentation graph. Recall and gate candidate memories from the institutional memory snapshot, bind the obtained target memory to the current graph node, compile it into a memory application package containing the memory execution plan, model input context and output validation rules, and generate an initial report data package carrying stable anchors; Receive an authoritative final state report signed and confirmed by an operator with final review authority; replay the initial generation process for changes in source data or version to obtain a learning baseline report; perform stable anchor point alignment and two-layer graph matching on the learning baseline report and the authoritative final state report to obtain semantic graph editing events and presentation graph editing events. Manually revised graph editing events are written into contextual memory and generated as candidate long-term memories. Matching positive examples and near mismatch negative examples are used for replay verification. Candidate long-term memories that meet the promotion criteria are consolidated into institutional long-term memories. In subsequent tasks, the matching institutional long-term memory is compiled and executed, the execution results are verified according to the output verification rules, and the affected subgraph is locally recalculated based on the reverse dependency index when the version of the dependent object changes.

2. The method for editing and storing dual-layer images in a physical examination report according to claim 1, characterized in that, The process involves recalling and gating candidate memories from the institutional memory snapshot, binding the obtained target memories to the current graph nodes, compiling them into a memory application package containing a memory execution plan, model input context, and output validation rules, and generating an initial report data package carrying stable anchors, including: At the start of the initial report generation, a read-consistent snapshot of the organization's memory is created, recording the memory catalog version, snapshot time, memory identifier, memory version, and lifecycle status; The candidate memories are recalled by a combined index of institutional tenant, scope, lifecycle state, target semantic encoding, and template version; Hard gating is applied to the candidate memories based on applicable predicates, necessary evidence, exclusion conditions, version compatibility status, candidate memory credibility, and memory conflict status, and conflict resolution is performed according to mandatory constraints, current task evidence, published baseline rules, memory level, and scope specificity. Bind the abstract target object in the target memory to the current graph node, and transfer the target memory that cannot be uniquely bound to the memoryless baseline branch or the manual review branch; The memory execution plan generated from the same target memory has the bound target, graph operator, preconditions, invariants and rollback information, the model input context has the priority, necessary actions and prohibited actions, and the output verification rules have the expected results and prohibited operations; In a graph transaction, a deterministic graph action is performed, in which the model input context is passed to the report generator through a structured request field or message interface, and the returned result is verified according to the output verification rules.

3. The method for editing and storing dual-layer images in a physical examination report according to claim 2, characterized in that, Each visible report item in the initial report data packet carrying stable anchors is associated with a report item identifier, a semantic node identifier, a presentation group identifier, an evidence reference, and a semantic hash; the initial report data packet also includes an applied memory identifier, an institutional memory snapshot identifier, a candidate memory version, a generation configuration identifier, and an output mode; the verification of the returned results according to the output verification rules includes: Verify whether the applied memory identifier is consistent with the memory execution plan; Verify whether the semantic node identifier and the evidence reference exist in the current task context; Verify that each visible report item in the report presentation graph references a valid health analysis item node; Verify whether the protected attributes, knowledge base, and graph transaction invariants satisfy the corresponding mandatory constraints; If any check fails, roll back the corresponding graph transaction and perform a memoryless rollback, replanning, or partial recalculation of the failed node.

4. The method for editing and storing dual-layer images in a physical examination report according to claim 1, characterized in that, The process involves receiving an authoritative final state report signed and confirmed by an operator with final review authority, replaying the initial generation process for changes to the source data or version, and obtaining a learning baseline report. Stable anchor point alignment and two-layer graph matching are then performed on the learning baseline report and the authoritative final state report to obtain semantic graph editing events and presentation graph editing events. The replaying of the initial generation process for changes to the source data or version to obtain the learning baseline report includes: Obtain the final state source data snapshot and final state version vector at the corresponding moment in the authoritative final state report; When the snapshot hash of the final source data snapshot is different from that of the initial source data snapshot, or when the final version vector is incompatible with the initial version vector, the initial generation process is replayed using the final source data snapshot and the version parameters in the final version vector other than the institutional memory catalog version. When replaying the initial generation process, the snapshot of the organization's memory bank at the time of initial generation is used, and the decoding parameters, random seed, or deterministic template version in the initial generation configuration are reused. Memories added, promoted, updated, or invalidated after the initial generation are not read. The replay results are identified as the learning baseline report, and differences that can be explained by source data or version changes are marked as data-induced differences. When the report generation tool cannot reproduce the results definitively, the differences between the normalized report semantic graph and the report presentation graph are compared, and wording differences that do not change the graph nodes, graph relationships, and protected attributes are excluded.

5. The method for editing and storing dual-layer images in a physical examination report according to claim 3, characterized in that, The process involves receiving an authoritative final state report signed and confirmed by an operator with final review authority, replaying the initial generation process for changes in source data or version, and obtaining a learning baseline report. Then, stable anchor point alignment and two-layer graph matching are performed on the learning baseline report and the authoritative final state report to obtain semantic graph editing events and presentation graph editing events. Specifically, the process of performing stable anchor point alignment and two-layer graph matching on the learning baseline report and the authoritative final state report to obtain semantic graph editing events and presentation graph editing events includes: The learning baseline report and the authoritative final state report are preferentially matched based on the report item identifier and the semantic node identifier. For unmatched report items, candidate node pairs are generated based on semantic encoding, object category, protected attribute, inspection source, and evidence intersection; The matching cost of each candidate node pair is calculated based on encoding similarity, text similarity, evidence overlap, attribute conflict, relation difference, and node type difference. The matching cost of protected attribute mutually exclusive node pairs that do not have legal conversion rules is set as the blocking value. Based on the matching cost, one-to-one node matching is solved, and then one-to-many and many-to-one hyperedge matching is solved for subsets of candidate nodes of the same type within a preset combination size. When the difference between the optimal matching cost and the suboptimal matching cost is less than the ambiguity threshold, the corresponding candidate node pair is marked as an ambiguous match and automatic learning is prevented. Graph editing operations that generate new health analysis item nodes or change evidence dependencies are classified as semantic graph editing events, while graph editing operations that only change the presentation grouping, name format, relative order, separator, or paragraph layout are classified as presentation graph editing events.

6. The method for editing and storing dual-layer images in a physical examination report according to claim 1, characterized in that, The process of writing manually revised graph editing events into contextual memory and generating candidate long-term memories, and then using matching positive examples and near-mismatch negative examples for replay verification, consolidates candidate long-term memories that meet the promotion criteria into organizational long-term memories; wherein, the process of writing manually revised graph editing events into contextual memory and generating candidate long-term memories includes: The reasons for revising graph editing events can be categorized as data change events, case-specific events, format repair events, presentation preference events, health analysis strategy events, knowledge update events, or pending events. For each image editing event, record the learning permission flag, case-specific flag, source change filtering status, revision source, and editing trajectory; Each graph editing event, along with the learning baseline report, the authoritative final state report, the corresponding source data snapshot summary, and the revision branch, is written into the context memory; Only graph editing events with a true learning permission flag, a false case-specific flag, and that do not belong to data change events, unfinished knowledge update events, or pending events are converted into candidate semantic memories or candidate program memories. The combined operation that generates new health analysis item nodes is written into the candidate semantic memory, and the presentation grouping operation that retains the original health analysis item nodes and evidence citations is written into the candidate program memory. Rules for protecting attributes, limiting access, and ensuring the integrity of evidence are written into independently published constraint memories, and these constraint memories are prohibited from being automatically modified by one-time graph edit events.

7. The method for editing and storing dual-layer images in a physical examination report according to claim 6, characterized in that, The process of writing manually revised graph editing events into contextual memory and generating candidate long-term memories, and then using matching positive examples and near mismatch negative examples for replay verification to consolidate candidate long-term memories that meet the promotion criteria into organizational long-term memories; wherein, the process of using matching positive examples and near mismatch negative examples for replay verification to consolidate candidate long-term memories that meet the promotion criteria into organizational long-term memories includes: Configure the candidate long-term memory with memory identifier, memory type, life cycle state, scope, applicable predicate, target graph object, graph action, necessary evidence, exclusion conditions, graph invariants, version dependency, and source tracing; Select positive examples from historical context memory that satisfy the scope, the applicable predicate, the necessary evidence, and the version dependency, and select near mismatch negative examples that are missing a necessary condition, meet an exclusion condition, or are version incompatible. Perform candidate long memory replay on the positive matching examples and the near mismatch negative examples respectively, and calculate the distance gain of the weighted graph edit distance, the near mismatch error trigger rate and the protected attribute retention rate before and after replay; The number of valid support and valid conflict counts are counted according to different tasks, and the credibility of candidate memories is calculated by combining evidence completeness, distance gain, signing role permissions, independence of support source, version compatibility and time decay. When the number of effective support counts, the distance gain, the near mismatch error trigger rate, the protected attribute retention rate, and the candidate memory credibility reach the promotion threshold of the corresponding memory type, and do not conflict with the constrained memory, the candidate long-term memory is consolidated into the institutional long-term memory. Candidate long-term memories that have not reached the promotion threshold are kept under observation; candidate long-term memories that have conflicts are downgraded; and candidate long-term memories with incompatible version dependencies are set to a pending review status.

8. The method for editing and storing dual-layer images in a physical examination report according to claim 1, characterized in that, The authoritative final status report, signed and confirmed by an operator with final review authority, is determined in the following manner: Organize two or more report revision versions into a revision directed acyclic graph. Each revision node records the revision identifier, parent node identifier, report hash, two-level graph version, source data snapshot hash, operation role, time, revision reason, signature, and authority status. A revision node with a valid signature, an operation role with final review authority, an authoritative status of true, and no subsequent signing replacement node is defined as an authoritative final state node. When there are two or more competing authoritative final state nodes, the cumulative positive support is suspended, the unsigned branches are retained as scenario evidence, and the graph editing operations revoked by the authoritative final state nodes are recorded as conflict samples. The method of performing local recalculation on the affected subgraph based on the reverse dependency index includes determining the direct impact set based on the dependent objects that have undergone version changes, obtaining the semantic impact closure along the evidence support relationship, semantic composition relationship and knowledge application relationship, obtaining the presentation impact closure based on the semantic node identifier, adding only the nodes in the semantic impact closure and the presentation impact closure to the local recalculation plan, and keeping the text hash of the non-dependent nodes unchanged.

9. A dual-layer image editing and memory processing device for physical examination reports, characterized in that, include: A two-layer graph construction module is used to acquire structured physical examination data, form source data snapshots, version vectors, and versioned evidence nodes, and construct associated report semantic graphs and report presentation graphs. Specifically, this includes: normalizing the object keys, null values, time, numerical values, units, and reference ranges in the structured physical examination data to form normalized data objects; calculating snapshot hashes for the normalized data objects and writing the data version, reference range version, terminology version, baseline rule version, knowledge version, prompt template version, report template version, generation model version, and institutional memory catalog version into the version vector; generating the versioned evidence nodes according to field location path, inspection identifier, inspection method, observation time, and source version, retaining evidence nodes from different sources corresponding to the same health information object, and connecting the evidence nodes before and after correction using substitution relationships; establishing health analysis item nodes, evidence support relationships, and semantic combination relationships in the report semantic graph; establishing references, presentation groupings, name formats, relative order, and paragraph layouts for the health analysis item nodes in the report presentation graph; and configuring common graph transaction identifiers and graph version pairs for the report semantic graph and the report presentation graph. The memory compilation and generation module is used to recall and gate candidate memories in the institutional memory snapshot, bind the obtained target memory to the current graph node, compile it into a memory application package containing the memory execution plan, model input context and output validation rules, and generate an initial report data package carrying stable anchor points. The graph editing recognition module is used to receive an authoritative final state report signed and confirmed by an operator with final review authority, replay the initial generation process for changes in source data or version to obtain a learning baseline report, and perform stable anchor point alignment and two-layer graph matching on the learning baseline report and the authoritative final state report to obtain semantic graph editing events and presentation graph editing events. The memory consolidation module is used to write manually revised graph editing events into contextual memory and generate candidate long-term memories. It uses matching positive examples and near mismatch negative examples for replay verification and consolidates the candidate long-term memories that meet the promotion conditions into institutional long-term memories. The memory application and local recalculation module is used to compile and execute the matching institutional long-term memory in subsequent tasks, verify the execution results according to the output verification rules, and perform local recalculation of the affected subgraph based on the reverse dependency index when the version of the dependent object changes.

Images