Local self-evolution method and device for health examination skill package

Abstract

The application discloses a local self-evolution method and device for a health examination skill package. The method records the component execution evidence when a benchmark skill package processes the collected examination data, and converts the audit error correction information into evolution events. The cause component set is located along the field blood relationship and the actual execution path of the target field, the local patch is determined through the candidate component subset, the heuristic patch and the isolated playback, the influence component set is generated by using the target component downstream closure of the benchmark dependency graph and the candidate dependency graph, the candidate version identification and the verification range are determined under the freezing condition, the data processing hard constraint is recalculated by the independent checker and is item-gated, and the immutable version with the environment routing condition is saved. The application can limit the propagation range of local error correction and reduce the version risk caused by the new path.

Description

Technical Field

[0001] This invention relates to the fields of health checkup data processing, artificial intelligence agents, and computer software version control, and particularly to a method and apparatus for performing component-level positioning, local patch verification, and environment-oriented version management of an agent's skill package based on the audit and error correction evidence of the collected health checkup data. Background Technology

[0002] The health checkup information processing system needs to perform field mapping, format conversion, unit conversion, cross-project association, and candidate content generation on collected data from information systems, questionnaire systems, and testing equipment. To reuse these capabilities, prompt resources, rules, scripts, tool interfaces, and workflows can be encapsulated into intelligent agent skill packages with input / output field contracts and independent version identifiers.

[0003] Existing methods for maintaining skill packages typically involve directly modifying rules, replacing hint resources, or retraining the base model based on the final error correction results. While this approach can generate new output content, it often lacks a unified content addressing relationship between execution inputs, environmental conditions, component versions, component call paths, intermediate results, and final error correction, making it difficult to form component execution evidence that can be isolated and replayed.

[0004] The closest approach to this invention is to save the results before and after correction and update the entire workflow according to the business steps where the differences occurred; another approach is to evaluate candidate versions based on historical samples and then decide whether to release them based on the total score. The former typically modifies at the workflow level, while the latter tends to average multiple constraints into the same evaluation value, neither of which establishes independent verification boundaries for new dependency paths and prohibited change fields.

[0005] Therefore, the existing technology has at least two interrelated technical problems: First, it is difficult to determine the component location where the difference first appears by only saving the final error correction result, which may cause local error correction to spread to irrelevant components; Second, after the candidate skill package changes the components or dependencies, the fixed sample set is difficult to cover the old path, the new path and the unregistered dependency edge, and the aggregate evaluation is difficult to guarantee that the hard constraints of data processing and the fields that prohibit changes will not be offset by other indicators. Summary of the Invention

[0006] The technical problem to be solved by this invention is: to establish a reproducible evidentiary relationship between audit and error correction information and input, environment, component execution path and intermediate results; to locate the causal component and determine the minimum complete patch range on the evidentiary relationship; and to implement stabilization verification on the baseline path, candidate new paths and independent data processing hard constraints, so that the verified local modifications form an environment-oriented immutable version.

[0007] To address the aforementioned technical problems, this invention provides a method for the local self-evolution of a health checkup skills package, comprising:

[0008] The benchmark skill package is used to process the collected physical examination data, record the execution evidence of components, receive audit and error correction information, and generate evolution events. Among them, the fields of the candidate output in the evolution events are divided into target fields, derived fields that are allowed to change together, fields that are prohibited from changing, and audit fields, and mutual exclusion checks are performed. Evolution events with intersections or conflicts are set to manual review status.

[0009] By tracing back along the field lineage from the target field of the evolution event, and comparing the component input-output snapshots with intermediate results within the actual execution path, a set of reason components for eliminating locked components and forced verification nodes is obtained.

[0010] Construct a subset of candidate components covering the target field, generate trial patches and isolate replays, and determine local patches and candidate skill packs according to patch range, lineage distance and number of operations;

[0011] Using the components defined by the local patch as target components, a candidate dependency graph is formed. The closure hash of the artifacts of non-target components is verified to remain unchanged. The baseline dependency graph and the downstream closures of the target components in the candidate dependency graph are merged to obtain the set of affected components.

[0012] Select the record that hits the set of affected components in the execution path, run the baseline skill pack and the candidate skill pack under frozen conditions, and determine the candidate version identifier, the set of affected components and the set of replay samples based on the newly added dependency edges;

[0013] The hard constraints of data processing are recalculated by an independent verifier and gating is performed item by item. Zero tolerance judgment is performed on the violation results of the hard constraints of data processing and the violation results of the prohibited change fields. It is prohibited to offset any zero tolerance judgment result with other gating indicators. After passing, an immutable version with environmental routing conditions is saved.

[0014] Furthermore, the formation of component execution evidence includes: performing protocol decoding, integrity verification, lossless encapsulation of original fields, extraction and desensitization of source metadata on the collected physical examination data, generating an input snapshot and input hash; generating a pre-execution environment configuration vector based on the data source system, interface version, device identifier, detection method, project code, original unit, applicable object attributes, and reference configuration version. This pre-execution environment configuration vector is an environment judgment vector generated by encoding fields obtainable from source metadata or audit configuration in a fixed order before the skill package execution, used for version positive applicability matching; running the registered components within the benchmark skill package, and generating a post-execution environment log set based on the actual standard unit, actual reference configuration version, and data generation time. The post-execution environment log set is an environment evidence set generated by expanding the pre-execution environment configuration vector with actual standard units, reference interval versions, and reagent batches, and then using a fixed field pattern for execution evidence verification. For each called component, the following are recorded: component identifier, content hash, artifact closure hash, input / output field pattern version, component input / output snapshot, execution order, and intermediate results. The artifact closure hash is the content hash value calculated by normalizing and serializing the component itself and all artifact resources that it directly or recursively references and that can change the execution result. External model responses, tool responses, and runtime parameters are associated with the corresponding called component using content addressing. Only records that can reproduce the intermediate results are used as component execution evidence to locate the first occurrence of the difference.

[0015] Furthermore, the formation of evolution events includes: displaying candidate outputs and component execution evidence associated with the candidate outputs; receiving the audited and confirmed target outputs, and saving the output before correction, the target output, the audit terminal, the confirmation status, and the confirmation time; writing the structured error correction reason, applicable environment field, target acceptance condition, and evidence index into the evolution event; dividing the fields of the candidate outputs into target fields, derived fields that are allowed to change together, fields that are prohibited from changing, and audit fields; performing mutual exclusion checks on the target fields, the derived fields that are allowed to change together, the fields that are prohibited from changing, and the audit fields; setting evolution events with overlaps or conflicts to a manual review status; and excluding evolution events that only involve expressing preferences from the production version evolution process.

[0016] Furthermore, the formation of the cause component set includes: traversing backwards from the field lineage node corresponding to each target field to the data source node to obtain field lineage candidate paths; performing intersection filtering on the field lineage candidate paths using the actual execution path to obtain executed candidate paths; comparing the component input / output snapshots and intermediate results of adjacent components according to the topological order of the executed candidate paths to locate the first occurrence of the difference; excluding components unrelated to the target difference that deviates from the audited and confirmed target output based on the structured error correction reasons in the evolution event to obtain an initial cause component set; reading the component locking attribute and mandatory verification attribute in the machine-readable manifest of the skill pack, excluding locked components and mandatory verification nodes from the initial cause component set, and retaining the upstream variable components of the mandatory verification nodes as the cause component set.

[0017] Furthermore, the formation of local patches and candidate skill sets includes: enumerating existing component combinations that can structurally affect all target fields from the set of causal components, and determining anchor components and candidate insertion positions for new components when new components are needed, thus obtaining a subset of candidate components; performing deterministic pruning on the subset of candidate components based on field lineage distance, component locking attributes, and component identifiers according to the maximum number of causal components, the maximum number of candidate subsets, the maximum number of trial patches, and the time budget; generating trial patches corresponding to the subset of candidate components under fixed patch generator version, configuration, random seed, and deterministic parameters, and performing local replay using the corresponding component's evidence in an isolated environment; and verifying the parent version hash and target hash for each trial patch. The dependency graph includes several key parameters: dependency contract, dependency integrity, permission resources, component signature, executableness, and mandatory verification node dominance. The mandatory verification node dominance refers to the fact that every executable path from the entry node to each production output node in the candidate dependency graph passes through a corresponding mandatory verification node. Trial patches that meet the target acceptance criteria and whose applicable environment can be expressed by routing conditions are retained. The algorithm compares the size of the union of the component to be modified, the anchored component, and the newly added component, the sum of the lineage distances from the components within the union to the target field, the number of patch operations, and the sorted component identifiers in a lexicographical order. The trial patch at the top of the sorted list is determined as the local patch. Candidate skill packs are generated based on these local patches, and the structured reasons why other trial patches were not adopted are recorded.

[0018] Furthermore, the formation of the affected component set includes: performing addition, replacement, deletion, or rearrangement operations only on the target components defined by the local patch; verifying that the component content, field contracts, environmental conditions, and artifact closure hashes of the corresponding components other than the target components remain consistent before and after the patch; calculating the first downstream closure of the target components that existed before the patch in the baseline dependency graph; calculating the second downstream closure of all target components after the patch in the candidate dependency graph; merging the target components, the first downstream closure, and the second downstream closure into the affected component set, and registering both the old paths in the baseline dependency graph and the newly added paths in the candidate dependency graph as paths to be verified.

[0019] Furthermore, replay stabilization includes: selecting historical records of the baseline actual execution path hitting the set of affected components or candidate statically conservatively reachable components hitting the set of affected components as initial replay records. The candidate statically conservatively reachable components refer to the set of components that can be reached by the candidate skill package, determined based on the candidate dependency graph and frozen input fields, without executing the candidate skill package, by treating all post-execution fields that may be changed by the target component or downstream affected components as unknown values, and including all structurally feasible branches; frozen input, unmodified dependencies, valid configuration, runtime, time zone, random parameters, and evaluator version. The baseline skill pack and the candidate skill pack are run on the initial replay records respectively; in response to the presence of an unregistered dependency edge in the candidate actual execution path, the current candidate version identity and existing verification evidence are invalidated; when the unregistered dependency edge involves the target component, the candidate version identity is re-formed and all selected replay records are replayed; when the unregistered dependency edge is completely outside the target component, the candidate skill pack is isolated; in response to the presence of a registered new branch in the candidate actual execution path, the set of affected components is expanded and supplemented with replay history records until the candidate version identity, the set of affected components, and the set of replay samples no longer change.

[0020] Furthermore, independent verification and sub-item gating include: deploying the independent verifier outside the write permission domain of the local patch, and prohibiting the candidate skill package from being written to the audit configuration of the independent verifier; the independent verifier reads frozen inputs, candidate valid configurations, and candidate outputs, and recalculates required fields, data types, numerical ranges, consistency of projects, equipment, and units, applicable conditions of reference configurations, consistency of associated fields, source traceability, and data access permissions; calculating the target acceptance result, non-target field degradation result within the impact domain, environment out-of-bounds result, path out-of-bounds result, prohibited change field violation result, and performance degradation result between the target field and the audited and confirmed target output, respectively; performing zero-tolerance judgment on data processing hard constraint violation results and prohibited change field violation results, and prohibiting the offsetting of any zero-tolerance judgment result by other gating indicators; outputting the gating pass result only when the evidence is complete, all zero-tolerance judgment results are not violated, and the remaining sub-item gating results meet the corresponding sub-item gating threshold.

[0021] Furthermore, after obtaining the set of causal components, a set of causal hypotheses is generated based on the set of causal components, the field lineage, the component execution evidence, and the field differences between the audited and confirmed target output and the candidate output; a univariate intervention copy is constructed for each causal hypothesis, modifying only one candidate component variable; the earliest abnormal intermediate results, target fields, non-target fields, and data processing hard constraints are compared and recalculated under the same freeze conditions; based on this, primacy candidates and compensation candidates are distinguished, a patch priority queue is formed, and writing the univariate intervention copy into the production version is prohibited.

[0022] The present invention also provides a local self-evolution device for a health check-up skill package, including an evidence and event generation module, a cause component location module, a local patch determination module, an impact set generation module, a replay stabilization module, and a gating and version saving module, each module being used to execute the corresponding technical features in the above method.

[0023] By employing a joint localization mechanism that combines component execution evidence, field lineage, and actual execution paths, the final error correction can be traced back to the component where the difference first appeared and the intermediate results. This alleviates the problem of overly coarse localization granularity caused by only saving the final results and reduces the probability of non-target components being modified in tandem. The use of dual downstream closures of the baseline dependency graph and candidate dependency graphs, stable replay, and independent zero-tolerance gating ensures that old paths, new paths, and unregistered dependency edges can all trigger corresponding verifications. Simultaneously, it prevents hard constraints in data processing and fields prohibiting change from being offset by other metrics, thereby improving the reproducibility of local version changes and structural security. Attached Figure Description

[0024] Figure 1This is a flowchart illustrating the local self-evolution method for the health check-up skill package provided in an embodiment of the present invention.

[0025] Figure 2 A schematic diagram illustrating the process of forming evidence of component execution and locating the cause component provided in an embodiment of the present invention;

[0026] Figure 3 A schematic diagram illustrating the process of candidate component subset selection and local patch determination provided in an embodiment of the present invention;

[0027] Figure 4 A schematic diagram illustrating the process of how dual dependency graphs affect closure and replay stabilization in an embodiment of the present invention;

[0028] Figure 5 This is a schematic diagram of the module structure of the local self-evolution device for the health check-up skill package provided in an embodiment of the present invention;

[0029] Figure 6 A schematic diagram illustrating the correspondence between existing intelligent inspection project business code flow and the technical modules of the present invention, provided for embodiments of the present invention;

[0030] Figure 7 UML activity diagram of the local self-evolution method for the health checkup skill package provided in this embodiment of the invention;

[0031] Figure 8 This is an activity diagram illustrating a business scenario for hospital-targeted blood lipid conclusion correction and partial version release, provided in an embodiment of the present invention. Detailed Implementation

[0032] The present invention will be further described below with reference to the accompanying drawings and embodiments. The health checkup data mentioned are all data that has been collected by an external system and provided with authorization. The processing objects of the present invention are data, software components, dependencies, verification evidence, and version artifacts; candidate outputs only enter the review process, and the endpoint of the method is the generation and routing management of immutable software versions.

[0033] This invention is applied to the intelligent overall examination business of health check-up institutions. The institutions send completed laboratory tests, ultrasound, radiological images, electrocardiograms, internal and surgical examinations, health questionnaires, and historical examination records to the intelligent overall examination platform. Based on the examinee's attributes, hospital configuration rules, and the original evidence of each examination item, the platform generates candidate overall examination conclusions, conclusion rankings, medical interpretations, and treatment suggestions for review by the chief physician. The chief physician can perform operations such as confirmation, modification, merging, splitting, reordering, deletion, or supplementation on the candidate content. However, these physician operations do not directly overwrite the production skill package; instead, they generate review and correction information pointing to the original execution record.

[0034] In practice, different medical examination institutions may use different naming, merging, and sorting methods for the same examination evidence. For example, for the same set of evidence of dyslipidemia, one institution may require it to be merged into "dyslipidemia," another institution may require it to retain two abnormal items: "elevated total cholesterol" and "elevated low-density lipoprotein cholesterol," and a third institution may output "hypercholesterolemia" according to its own standards. These differences are differences in business expression with clearly defined applicable environments and cannot be covered by a single global rule for all institutions.

[0035] Therefore, this invention writes the hospital identifier, interface version, examination item code, testing method, equipment identifier, reference configuration version, and applicable object attributes into the environment sub-fingerprint, ensuring that candidate versions generated during review and correction can only be routed within an environment that matches their verification evidence. For corrections that only involve the institution's own expression habits, the system does not modify valid versions from other institutions; for corrections involving data types, units, reference ranges, evidence sources, or access permissions, an independent validator still recalculates according to unified hard constraints, and institutional preferences are not allowed to override data processing hard constraints.

[0036] Existing project business code processes and baseline skill sets, such as Figure 6 As shown, the existing project business code constitutes the forward execution chain of the baseline skill package. The system first receives raw physical examination data, then atomically decomposes the examination results containing multiple medical facts; generates model input while preserving the department and combined project context; executes hospital-configured diagnostic rules and model diagnoses; performs deterministic verification on abnormal items clearly marked as elevated, decreased, or positive; merges medical relationships of diagnostic conclusions; performs risk priority ranking and generates interpretations and suggestions in parallel; and finally assembles a candidate final examination report. If any stage fails, it enters a failure branch and does not generate a formal report that can be submitted.

[0037] C1 Inspection results split components split_exam_results_node; split_exam_results_concurrently Break down multiple independent facts in a long text of images or ultrasound into atomic results while preserving the original text. C2 Input preparation components prepare_llm_input;compact_data Create a snapshot of the data to be processed, preserving the hierarchical relationship between departments, combined projects, and examination subjects. C3 Diagnostic and anomaly verification components run_diagnosis;diagnose_exam;reconcile_marked_abnormal_findings Implement hospital configuration rules and model diagnosis, verify clear abnormal markers, and generate diagnostic results with source evidence. C4 Conclusion: Merging Components merge_result; merge_diagnosis_result Group conclusions based on organ systems or common disease mechanisms to ensure that each conclusion identifier appears only once. C5 Sorting and suggestion components sort_and_generate_advice; sort_diagnoses_and_generate_advice The data is prioritized according to short-term risk, organ damage, and urgency of treatment, and explanations and recommendations are generated. C6 Report assembly components assemble_medical_report The ranked conclusions, evidence, explanations, and recommendations are assembled into a candidate final inspection report. C7 Failure handling components assemble_failed_report and conditional routes An interrupted state is formed when an error occurs during the input, diagnosis, merging, or suggestion phase.

[0038] In this invention, a unified execution evidence collection interface is added to components C1 to C7. Each execution is assigned a unique execution identifier, and each called component records the component identifier, component content hash, component artifact closure hash, input field mode version, input snapshot digest, output snapshot digest, execution order, actual read fields, actual write fields, external model response identity, and exception status. Therefore, existing project code can be loaded and tracked as the baseline skill package described in this invention without needing to remove its existing order and failure handling logic.

[0039] The correspondence between the project's business codes and the technical modules of this invention is shown in the table below:

[0040] Evidence and Event Generation Module Set up execution interceptors outside of C1 to C7; set up error correction collection interface in the report review interface. Input snapshot, component execution evidence, candidate output, confirmed target output, evolution event Cause component location module Read the read / write relationships of fields C1 to C6 and the actual call order in this operation. Field lineage candidate path, executed candidate path, first occurrence position of difference, and set of cause components. Local patch determination module Generate restricted probe patches for the located prompt resources, hospital rules, parameters, or component connection conditions. Candidate component subsets, trial patches, partial patches, candidate skill packs Affecting the set generation module Compare the dependency edges between the baseline workflow and the candidate workflow, and verify the closure of non-target component artifacts. First downstream closure, second downstream closure, affected component set, path to be verified Playback stabilization module Reuse historical raw inputs and recorded external responses to run the baseline skill pack and candidate skill packs separately. Replay sample set, candidate actual paths, newly added dependency edges, and stable round list Gating and version saving module Deploy independent validators and version repositories outside of the patch write permission domain. Sub-project gating results, environment routing conditions, immutable versions, shadow loading records

[0041] The above correspondence does not directly convert the doctor's final modification into a model training sample. Instead, it first converts the modification into an evolution event with a target field, a prohibited change field, a review reason, and an applicable environment. Subsequently, all positioning, patching, replay, gating, and version release are bound to this evolution event and its baseline execution identifier.

[0042] Reproducible data objects include:

[0043] Enter snapshot Original physical examination subject, applicable attributes of the examinee, department level, combined items, item code, examination results, unit, reference range, prompts, examination findings, historical record index Component execution evidence Execution identifier, component identifier, content hash, artifact closure hash, input / output field pattern, input / output snapshot, intermediate results, actual call order, and external response identity. Evolutionary events Benchmark execution identifier, pre-correction output, audited and confirmed target output, target field, allowed common variation field, prohibited variation field, structured error correction reason, environment field, acceptance criteria Candidate version identity Parent version hash, target component artifact closure hash, candidate dependency graph summary, valid configuration summary, runtime summary, evaluator version, and environment routing condition summary Stable round list Round number, candidate version identity, summary of affected component set, summary of replay sample set, summary of actual path, newly added dependency edge, and state before gating.

[0044] Each data object is stored using content addressing. Missing fields are marked with explicit missing tags, and text uses a unified character encoding. Mapped objects are normalized according to a fixed key order before the summary is calculated to avoid different identities arising from different serialization orders for the same logical content. Fields involving natural persons are anonymized before generating replay samples. Component localization and patch generation only read the minimum range of evidence required to locate the target field.

[0045] Example 1

[0046] like Figure 1 As shown in the figure, this embodiment provides a local self-evolution method for a health check-up skill package, and its main processing line is as follows.

[0047] S1. Run the benchmark skill package to process the collected physical examination data, record component execution evidence, receive audit and error correction information and generate evolution events; wherein, the candidate output fields in the evolution events are divided into target fields, derived fields that are allowed to change together, fields that are prohibited from changing and audit fields, and mutual exclusion checks are performed, and evolution events with intersections or conflicts are set to manual review status.

[0048] Specifically, the baseline skill package is a loadable resource set consisting of a machine-readable manifest, executable components, input / output field contracts, dependency graphs, environmental conditions, and version metadata. The computing device assigns an execution identifier to each execution, binding input snapshots, component versions, component call order, component input / output snapshots, intermediate results, external responses, and final candidate outputs to the execution identifier. After the auditing terminal corrects the candidate output, it does not directly overwrite the original execution record but instead creates an evolution event pointing to the original execution identifier, allowing both the pre-correction state and the post-correction target to be replayed. The four-category classification and mutual exclusion verification of candidate output fields are detailed in Example 3.

[0049] S2. Tracing backwards along the field lineage from the target field of the evolution event, comparing the component input / output snapshots with intermediate results within the actual execution path, to obtain the set of reason components for removing locked components and forced verification nodes.

[0050] Field lineage can be represented as a directed acyclic graph, with nodes corresponding to original fields, intermediate fields, and candidate output fields, and edges corresponding to read, transform, aggregate, or write actions. The system performs a reverse reachability traversal starting from the target field and filters static reachability edges using the actual call edges in the current execution record. For retained components, the system compares the component's input snapshot with the expected input, the component's output snapshot with the audited and confirmed target, and the first deviation position of intermediate fields. Because the localization process is constrained by both the causal direction of the field and the actual path, components with the same name but not participating in this execution will not enter the cause component set. Locked components and mandatory verification nodes exist only as lineage boundaries and are not included in the modifiable set.

[0051] S3. Construct a subset of candidate components covering the target field, generate trial patches and isolate replays, and determine local patches and candidate skill packs according to patch range, lineage distance and number of operations.

[0052] Candidate component subsets should structurally affect all target fields, but structural coverage is not equivalent to target acceptance. The patch generator generates add, replace, delete, or rearrange operations for each candidate component subset, generating trial patches within a candidate version area isolated from production write permissions. The system reuses input snapshots from S1 and component execution evidence for partial replay, first eliminating patches for incompatible field contracts, missing dependencies, out-of-bounds permissions, or bypassed mandatory validation nodes, and then deterministically selecting solutions with more concentrated modification objects, shorter lineage distances, and fewer operations.

[0053] S4. Using the components defined by the local patch as target components, form a candidate dependency graph, verify that the closure hash of the artifacts of non-target components remains unchanged, merge the baseline dependency graph and the downstream closures of the target components in the candidate dependency graph to obtain the set of affected components.

[0054] Component artifact closures include the component's own content as well as hint resources, model bindings, rule files, runtime dependencies, reference configurations, and permission configurations that can change the component's behavior. Comparing only the component's text hash might miss external resource replacements; therefore, this embodiment calculates the overall hash after normalizing and sorting the artifact closures. The closure hashes of non-target components must be consistent in the base version and candidate versions. For target components, downstream closures are calculated simultaneously from both the base dependency graph and the candidate dependency graph to cover deleted old paths, still existing paths, and paths added in patches.

[0055] S5. Select the record that hits the set of affected components in the execution path, run the baseline skill pack and the candidate skill pack under the frozen condition, and determine the candidate version identifier, the set of affected components and the set of replay samples based on the newly added dependency edges.

[0056] Freezing conditions include at least the input, non-target component artifact closure, valid configuration, runtime, time zone, random parameters, and evaluator version. If a call edge not registered in the static dependency graph is found during candidate execution, the original candidate identity is insufficient to uniquely represent the actual executed artifact, and existing replay results are no longer considered as publication evidence. The system recalculates the candidate identity or isolates candidates based on the position of the newly added dependency edge, and continues to expand the affected component set and sample set until all three remain unchanged within a single complete replay cycle. This stabilization mechanism avoids obtaining a pass conclusion using a narrow sample set initially, only to have the actual impact range altered by newly added branches.

[0057] S6. The hard constraints of data processing are recalculated by an independent verifier and gating is performed on each item. Zero tolerance judgment is performed on the violation results of the hard constraints of data processing and the violation results of the prohibited change fields. It is prohibited to offset any zero tolerance judgment result with other gating indicators. After passing, an immutable version with environmental routing conditions is saved.

[0058] Independent validators and patch generators belong to different write permission domains, and the self-check flags given by candidate skill packs are not used as gating conclusions. Gating outputs target acceptance, non-target degradation, environment out-of-bounds, path out-of-bounds, violation of prohibited change fields, and performance degradation separately, without first aggregating them into an average score. Data processing hard constraints and prohibited change fields are judged with zero tolerance. After gating passes, the system solidifies the candidate skill pack, valid configuration, artifact closure hash, environment routing conditions, and validity period into an immutable version; this version is only loaded at runtime if the environment fields meet the aforementioned environment routing conditions before execution.

[0059] Because the cause localization is based on reproducible intermediate results of components rather than final text similarity, local modifications can be applied to the execution unit where the first difference occurs. Because the impact on the closure and sample set is stable under the addition of dependency edges, the verification boundary of the candidate version is consistent with the actual execution boundary, thereby addressing and mitigating the problems of excessively coarse localization granularity and insufficient verification of new paths mentioned in the background technology.

[0060] It should be noted that the "version identity" in this embodiment is not a single version number, but an immutable identifier that uniquely points to the actual execution artifact combination. When forming a version identity, the system normalizes and arranges the skill package machine-readable manifest, valid configuration, artifact closure hash, dependency graph summary, environment routing conditions, runtime identifier, and evaluator version, and then generates a combination summary from the arrangement result. A different version identity is formed when any component object changes; even if the skill package's display name and component text remain unchanged, the original version identity cannot be reused. By distinguishing between the display version and the combination version, the incorrect reuse of old verification evidence after changes in runtime dependencies or reference configurations can be avoided.

[0061] Specifically, the main process saves the input object, output object, execution status, and failure reason at each stage. When evidence is incomplete in S1, the evolutionary event only enters the pending evidence state; when a set of cause components cannot be formed in S2, the cause set is not replaced by all components; when no trial patch passes structural verification in S3, a candidate skill set is not formed; when a stable state cannot be reached within a limited number of rounds in S5, the candidate version is set to an unstable state; when evidence is insufficient in S6, the default pass is not executed. All the above failure states retain the original execution identifier and failure stage, allowing authorized operators to supplement evidence and restart the corresponding stage without overwriting the immutable records already formed in the previous stage.

[0062] Furthermore, the outputs of each stage are linked through explicit data contracts. Evolutionary events provide the cause localization stage with target fields, structured error correction causes, applicable environment fields, and evidence indexes; the cause component set provides the patching stage with component identifiers, initial difference fields, field lineage distances, and lockout boundaries; local patches provide the impact analysis stage with an operation list, target components, and hashes before and after the patch; stabilization replay provides the gating stage with freeze conditions, sample indexes, actual paths, and version identities. If the output fields of the previous stage are missing, the schema version is incompatible, or the hashes are inconsistent, the subsequent stage will refuse to execute. This contractual linkage ensures that local self-evolution is not a loose chain of functions, but a controlled software change pipeline capable of verifying the sufficiency of inputs and the identity of outputs stage by stage. Thus, the overall activity relationship from S1 to S6, including the audit and error correction entry point, the splitting of unregistered dependency edges and registered new branches, and the gating pass / fail termination paths, such as... Figure 7 The UML activity diagram is shown below.

[0063] Example 2

[0064] like Figure 2 As shown, in S1 of Example 1, this embodiment forms component execution evidence. The running benchmark skill pack processes the collected physical examination data, records the component execution evidence, receives review and error correction information, and generates evolution events. The recorded component execution evidence includes:

[0065] S1.1. Perform protocol decoding, integrity verification, lossless encapsulation of original fields, extraction of source metadata, and desensitization processing on the collected physical examination data to generate an input snapshot and input hash.

[0066] The data access layer does not handle field semantic mapping, unit conversion, or candidate content generation to prevent unregistered processing in the access layer from compromising evidence boundaries. Input snapshots are generated using a standardized field order and encoding method, and binary attachments can record content addressing addresses. Records that fail integrity verification are placed in a blocked state and do not enter the automatic patch generation process.

[0067] S1.2. Generate a pre-execution environment configuration vector based on the data source system, interface version, device identifier, detection method, project code, original unit, applicable object attributes, and reference configuration version. The pre-execution environment configuration vector is an environment judgment vector for version positive applicability matching generated by encoding fields that can be obtained from source metadata or audit configuration in a fixed order before the skill package is executed.

[0068] The pre-execution environment configuration vector uses only fields available before execution to select the baseline skill set and effective configuration. Each field is first converted to a normalized representation according to the field contract, then concatenated in fixed-key order and a digest is calculated. Missing fields are explicitly marked as missing and not confused with empty strings. In other implementations, a key-value tree root hash can be used instead of concatenated digests to support local proofs of subfields.

[0069] S1.3. Run the registered components in the benchmark skill package and generate a post-execution environment log set based on the actual standard units, the actual reference configuration version and the data generation time. The post-execution environment log set is an environment evidence set for execution evidence verification generated by expanding the pre-execution environment configuration vector with the actual standard units, reference interval versions and reagent batches according to a fixed field pattern.

[0070] The post-execution environment log set is only used to describe the actual environmental conditions in which this execution occurred and does not reverse the routing. The actual standard units and actual reference configuration versions come from the output of registered components, and the data generation time is normalized according to a unified time zone. The pre-execution environment configuration vector and the post-execution environment log set are jointly stored in the execution evidence index to distinguish between "the conditions on which the version selection is based" and "the conditions observed after execution".

[0071] S1.4. For each called component, record the component identifier, content hash, artifact closure hash, input / output field mode version, component input / output snapshot, execution order, and intermediate results. The artifact closure hash is the content hash value calculated by normalizing and serializing the component itself and all artifact resources that are directly or recursively referenced and can change the execution result.

[0072] Component identifiers are unique within the same skill pack version. Component input / output snapshots can be stored directly, or, when dealing with large amounts of data, their content addressing address and summary can be stored. Execution order records both the logical sequence number and the parent call identifier to represent branches and parallel execution. Artifact closure hashes cover all external bindings that may affect component behavior; therefore, the same component body but different external configurations will result in different evidence identities.

[0073] S1.5. Associate the external model response, tool response, and runtime parameters with the corresponding called component using content addressing, and use only the record that can reproduce the intermediate result as component execution evidence for the first occurrence of the location difference.

[0074] The reproduction check should at least verify the input hash, artifact closure hash, runtime parameters, external response summary, and output hash. For components that cannot be replayed deterministically, the random seed, sampling parameters, and original external response can be recorded to reproduce the component's downstream behavior using response injection. If intermediate results still cannot be reproduced, this record can be used for statistical evaluation, but it does not serve as sole proof of the location of the first occurrence of the difference.

[0075] The five sub-steps described above enable the execution evidence to describe not only "what was executed," but also "what intermediate results were obtained under what inputs, environment, and artifact closure." Since each difference point can point back to a replayable input-output snapshot, field lineage localization can exclude components that are only temporally correlated but lack execution causality, thus providing a stable evidentiary basis for subsequent causal component sets.

[0076] Specifically, input snapshots undergo deterministic normalization before hash generation. For key-value data, they are sorted according to field identifiers defined by the field schema, and character encoding, date / time zone, decimal precision, null value representation, and array order are standardized. For tabular data, column identifiers, record primary keys, and page boundaries are fixed. For binary attachments, attachment content summaries, media types, and association identifiers with structured fields are recorded. Normalization only changes the serialization format, not the original field values. The original lossless encapsulation and the normalized snapshot are saved separately, enabling the system to trace the original input and generate consistent input hashes for semantically identical data with different serialization orders.

[0077] Preferably, the component input / output snapshots adopt a hierarchical structure of "field list plus content address". The field list records the field identifier, field schema version, value type, unit, source component, and content address; the field values ​​are stored in a content-addressed storage area with access control. During the localization phase, the field list and necessary difference fields are typically read, and the complete field value is dereferenced only when the appropriate permissions are obtained. This structure reduces the storage volume of duplicate snapshots and prevents the entire health check data from being read without boundaries in order to locate a target field. For data with a retention period, the hash, field schema, and execution relationship are still retained after the content address expires, but the record is marked as not being able to be precisely replayed and does not serve as the sole evidence for the initial difference localization.

[0078] When external models or tools cannot guarantee that the same input will produce the same response, the system saves the original request summary, the original response content address, the called interface version, sampling parameters, timeout settings, and retry sequence number. Isolated replay prioritizes injecting the original response to verify downstream components; when it is necessary to verify a new version of an external service, the new response is written as a new external artifact into the candidate version identity and replayed separately from the original response. This distinguishes between two sources of difference: "internal component logic changes" and "external response drift," avoiding incorrectly classifying changes to external services into skill package components.

[0079] Example 3

[0080] This embodiment further defines the structure of the evolution event. The running benchmark skill package processes the collected physical examination data, records component execution evidence, receives audit and error correction information, and generates an evolution event; wherein, receiving audit and error correction information and generating an evolution event includes:

[0081] S1.6. Display candidate outputs and evidence of component execution associated with the candidate outputs.

[0082] The review interface should at least display the candidate field value, data source, the final-level component that generated the candidate field value, and the evidence entry point. The evidence entry point can display a full snapshot or an anonymized summary according to permissions; this invention does not limit this.

[0083] S1.7. Receive the target output after review and confirmation, and save the output before correction, the target output, the review terminal, the confirmation status, and the confirmation time.

[0084] The target output is saved with structured field differences and shares the same field pattern version as the output before correction. Confirmation status can include pending review, confirmed, and withdrawn. The auditing terminal uses an authorized terminal identifier and does not record real identity information that could point to a natural person.

[0085] S1.8. Write the structured error correction reason, applicable environment field, target acceptance condition and evidence index into the evolution event.

[0086] The structured error correction reason is selected from the preset reason code table and can be supplemented with explanations; the applicable environment field is used to limit the interface version, device category or reference configuration to which the error correction can be generalized; the target acceptance condition mechanizes the exact matching, set inclusion or format consistency relationship allowed by the target field; and the evidence index is connected to the execution identifier of Example 2.

[0087] S1.9. Divide the fields of the candidate output into target fields, derived fields that are allowed to change together, fields that are prohibited from changing, and audit fields.

[0088] The target field is the field directly specified by the audit and correction; the derived fields that are allowed to change together are fields that may be updated synchronously with the target field based on the registered dependencies and have been authorized; the fields that are prohibited from changing must remain consistent field by field in this evolution event; the audit fields only record the execution source, version and time information, and do not participate in the target acceptance of the candidate patch.

[0089] S1.10. Perform mutual exclusion checks on the target field, the derived field that is allowed to change together, the field that is prohibited from changing and the audit field, set the evolution events that have intersections or conflicts to manual review status, and exclude the evolution events that only involve expressing preferences from the production version evolution process.

[0090] Mutual exclusion checks can be implemented by comparing the pairwise intersection of the field identifier sets. If the same field is marked as both allowed and prohibited from changing, the system must not automatically select the priority. Events that only change punctuation, spaces, or unstructured expressions of preference can be stored in the personalized preference area, but the component content of the production skill pack will not be changed. This avoids unclear field scopes being carried over to subsequent gating.

[0091] In this embodiment, an evolution event can sequentially be in the states of draft, pending review, confirmed, locating, candidate verification, accepted, rejected, or withdrawn. State transitions are jointly verified by the event identifier, current state, and expected previous state to avoid duplicate submissions of the same review correction, thus preventing the generation of multiple parallel patches. If an event already in candidate verification is withdrawn, the corresponding candidate skill package immediately stops subsequent gating, but the already formed component execution evidence and replay evidence continue to be retained in read-only mode to explain the reason for the candidate's cessation.

[0092] It is important to note that the target acceptance criteria should be compatible with the data type of the target field. Scalar fields can use normalized equality or allowable error ranges; set fields can use set equality, inclusion, or intersection ranges; structured text fields can be limited to required fields, field order independence, and format patterns; derived fields should simultaneously verify whether the derivation relationship is maintained. Target acceptance criteria are frozen upon confirmation of the evolution event, and the patch generator has no right to relax them. If the audited correction content cannot be converted into machine-executable conditions, the evolution event remains under manual review and does not enter the automatic patching process, thus avoiding the patch generator's self-interpretation of ambiguous targets.

[0093] Example 4

[0094] This embodiment further defines the generation of the cause component set. The step of tracing backwards along the field lineage from the target field of the evolutionary event, comparing component input / output snapshots with intermediate results within the actual execution path, and obtaining the cause component set by removing locked components and forced verification nodes includes:

[0095] S2.1. Traverse backwards from the field lineage node corresponding to each target field to the data source node to obtain the field lineage candidate path.

[0096] Reverse traversal preserves all parent nodes for multi-input components and does not forcibly split multi-input actions into linear paths. If a circular call exists, the system expands the current execution instance into a directed execution graph with call cycles before performing reverse traversal.

[0097] S2.2. Perform intersection filtering on the candidate paths of the field lineage using the actual execution path to obtain the executed candidate paths.

[0098] Intersection filtering uses component identifier, call round, and field edge for matching. Branches reachable in the static dependency graph but not triggered in this instance are excluded from the localization evidence but retained as conservatively reachable branches of candidate versions for use in subsequent sample selection.

[0099] S2.3. Compare the component input / output snapshots and intermediate results of adjacent components according to the topological order of the executed candidate paths, and locate the position where the difference first appears.

[0100] During the comparison, it is first determined whether the upstream output is consistent with the downstream input, and then it is determined whether the downstream output deviates from the target acceptance criteria for the first time. If a difference has occurred upstream but the difference is only propagated downstream, the downstream is not marked as the first position; if a difference occurs downstream with consistent input, the downstream is added to the candidate for the first difference component. For parallel convergence components, all actual input snapshots are used as the comparison boundary.

[0101] S2.4. Based on the structured error correction reasons in the evolution event, exclude components that are not related to the target difference of the target field deviating from the audited and confirmed target output, and obtain the initial cause component set.

[0102] The structured error correction reason is only used as an exclusion signal and does not independently prove that a component is a causal component. The exclusion operation must save the reason code, the excluded component, and the evidence field to facilitate reversing the exclusion if subsequent playback fails to meet the requirements. In other implementations, a preset rule engine or an interpretable classifier can be used to complete the exclusion; this invention does not limit this approach.

[0103] S2.5. Read the component locking attribute and forced verification attribute from the machine-readable manifest of the skill pack, exclude the locked component and forced verification node from the initial cause component set, and retain the upstream variable component of the forced verification node as the cause component set.

[0104] Locked components include basic protocol parsing, permission checks, and independent audit configuration loading components; mandatory validation nodes require that every production candidate output path passes through this node. Cause localization can demonstrate that a difference has passed through a mandatory validation node, but the patch scope must not reduce the mandatory attribute of this node. For target fields that must be processed by a mandatory validation node, the set of cause components stops expanding downstream at this node, retaining only upstream variable components that can modify the node's input.

[0105] The aforementioned localization mechanism combines four types of evidence: static field lineage, actual path, intermediate results, and component attributes. Since static reachability explains "potential impact," actual path explains "participation in this instance," intermediate results explain "where the difference originates," and component attributes limit "what can be modified," these four elements have different constraining effects, thus narrowing down the scope of causal components without modifying the mandatory validation structure.

[0106] Specifically, the comparison key for inter-component snapshot comparison consists of component identifier, call round, field identifier, and field pattern version. The system first checks whether the content addresses of the upstream output and downstream input are consistent; if the addresses are inconsistent, it then compares the normalized field values ​​and transformation records to distinguish between data transmission errors and normal format conversions. For cases where a single component writes multiple fields, only the write field edges where target-related differences occur are marked as difference edges. The system does not exclude a component because other outputs of the same component are normal, nor does it judge all outputs as abnormal because one field is abnormal.

[0107] Specifically, the initial difference location of the multi-input convergence component is based on all actual inputs. When an input has deviated from the baseline and the component output only deterministically propagates the deviation, the initial difference location remains upstream. When all inputs are consistent with the baseline but the component output deviates, the convergence component becomes a candidate for the initial difference component. When multiple inputs deviate simultaneously from mutually exclusive upstream branches, the system retains multiple competing locations and does not force them to be merged into a single cause. Subsequent trial patches generate candidate subsets for each competing location and use isolated replay results to determine whether a single location or a combination of locations can cover all target fields.

[0108] In another possible implementation, the field lineage graph includes cyclic workflows or retry calls. Instead of directly determining the order on the static cyclic graph, the system expands each call into execution instance nodes with rounds based on component execution evidence, forming a partial order using timestamps and parent call identifiers. When timeout retries produce the same output, only the last valid output is retained as downstream input, while the previous failure record is also preserved; when different rounds produce different outputs, the lineage edge is determined by the output actually consumed. Through execution instance expansion, loops and retries do not cause infinite backward tracing loops, nor do they mistakenly identify failed outputs not consumed downstream as the source of the first difference.

[0109] Example 5

[0110] like Figure 3 As shown, this embodiment further defines the candidate component subset screening and local patch determination. The process of constructing a candidate component subset covering the target field, generating trial patches and isolating replays, and determining local patches and candidate skill packs based on patch range, lineage distance, and number of operations includes:

[0111] S3.1. Enumerate existing component combinations that can structurally affect all target fields from the set of cause components, and determine anchor components and candidate insertion positions for the new components when new components are needed, to obtain a subset of candidate components.

[0112] For multiple target fields, the candidate component subset should ensure that each target field has at least one reachable path from a component within the subset to that target field. Existing component combinations can be generated through bounded set overlay search. Newly added components are not counted in isolation but are registered together with their predecessor anchor components, successor field edges, and candidate insertion positions to make the boundaries before and after the patch comparable.

[0113] S3.2. Perform deterministic pruning on the candidate component subsets based on the field lineage distance, component locking attribute, and component identifier, according to the maximum number of cause components, the maximum number of candidate subsets, the maximum number of trial patches, and the time budget.

[0114] Deterministic pruning first deletes subsets containing locked components or mandatory validation nodes, then deletes subsets that do not cover all target fields. For subsets with the same coverage relationship, subsets with shorter field lineage and earlier component identifiers are retained first. The maximum number of cause components can be set to 8 to 20, and the maximum number of candidate subsets can be set to 20 to 200, with specific values ​​configured according to the skill set size. When the time budget is exceeded, the system saves the completed enumeration range and transfers it to manual analysis, without declaring incomplete search results as the minimum range.

[0115] S3.3. Generate a probe patch corresponding to the subset of candidate components under the conditions of fixed patch generator version, configuration, random seed and deterministic parameters, and perform local replay using the corresponding component execution evidence in an isolated environment.

[0116] The isolated environment is read-only for the production repository but writable for the candidate version area. The patch generator outputs a structured list of operations, with each operation recording the parent version, target component, hashes before and after modification, applicable conditions, and generator identity. Local replay uses a snapshot of the input at the time of error correction, external responses, and unmodified dependencies; thus, the differences in results between different candidate subsets mainly come from patch operations, rather than random parameters or runtime environment drift.

[0117] S3.4. For each of the aforementioned test patches, verify the parent version hash, target hash, field contract, dependency integrity, permission resources, component signature, executableness, and mandatory verification node dominance relationship. The mandatory verification node dominance relationship means that every executable path from the entry node to each production output node in the candidate dependency graph passes through the corresponding mandatory verification node, and test patches that meet the target acceptance criteria and whose applicable environment can be expressed by routing conditions are retained.

[0118] The mandatory verification node dominance relationship means that the path from the skill pack entry point to any production candidate output node passes through the corresponding mandatory verification node. Verification checks both the pre-patch and post-patch paths separately. The applicable environment can be expressed by routing conditions, meaning that the verified environment fields can be obtained before execution and converted into deterministic Boolean conditions, avoiding the use of fields known only after execution to select the current version.

[0119] S3.5. Perform a lexicographical comparison in sequence according to the size of the union of the component to be modified, the anchored component, and the newly added component, the sum of the bloodline distances of the components in the union to the target field, the number of patch operations, and the sorted component identifiers. Determine the first-ranked trial patch as the local patch, generate the candidate skill pack based on the local patch, and record the structured reasons why other trial patches were not adopted.

[0120] To facilitate the explanation of lexicographical comparison, the u-th trial patch that passes the aforementioned verification can be represented as:

[0121] (1)

[0122] in, This represents the ordered comparison key for the u-th trial patch; This represents the size of the union of the component to be modified, the anchored component, and the newly added component; This represents the sum of the lineage distances from the components within the union to all target fields; Indicates the number of patch operations; This represents the sorted sequence of component identifiers. Comparisons are performed sequentially. , , and If the first term is not equal, the second term is not compared. Equation (1) is not a weighted summation, so the larger range of modifications will not be offset by other better indicators.

[0123] In one example, the first probe patch only replaces cross-project related components, with the comparison key being... The second trial patch simultaneously replaces cross-project related components and candidate generated components, with the comparison key being... When both patches pass the target acceptance test, the first probe patch is selected as the local patch due to its smaller first value. This example value is for illustrative purposes only and does not limit the number of components or the form of identification.

[0124] Since all candidates are executed under the same input, external response, and operating conditions, the target acceptance results are comparable. Furthermore, since the selection order first constrains the actual set of modified components, and then constrains the lineage distance and number of operations, the local patch is a smaller complete patch that meets the acceptance and structural constraints, rather than the smallest subgraph inferred solely from the static graph distance. This reduces the probability of incomplete patches failing in subsequent environments.

[0125] In this embodiment, the add operation declares at least the new component identifier, anchor component, predecessor field, successor field, and insertion condition; the replace operation declares the hash of the replaced component, the hash of the replaced component, and field contract compatibility relationships; the delete operation declares the input and output edges of the deleted component and the replacement connections after deletion; the rearrangement operation declares the set of components participating in the rearrangement, the old topology relationships, and the new topology relationships. Each operation carries execution preconditions and execution postconditions. If the preconditions are not met, the patch will not be executed; if the postconditions are not met, the isolation environment will roll back to the parent version snapshot to prevent some operations from succeeding and forming an unregistered mixed candidate version.

[0126] It's important to note that deterministic pruning does not directly delete candidate subsets that uniquely cover the target field based on prediction scores. The system first establishes candidate families based on structural coverage relationships, then prunes within the same coverage relationship based on field lineage distance, locking attributes, and component identifiers. If the number of candidates still exceeds the budget, at least one covering candidate is retained for each target field, and the unenumerated range is recorded. The maximum number of candidate subsets and the maximum number of trial patches can be configured based on the total number of components, the number of target fields, and the concurrency capacity of the isolation environment; these configuration values ​​are frozen based on the candidate version identity. This ensures that even when the search is budget-constrained, it clearly distinguishes between "verified first-ranked candidate" and "absolutely smallest candidate in the entire search space," avoiding conclusions that exceed the weight of evidence.

[0127] Furthermore, lexicographical comparison is performed after all candidates have passed the same acceptance threshold. The union size reflects the actual component boundaries that need to be changed or introduced; the sum of lineage distances reflects the potential propagation length of the impact from the modification location to the target field; the number of patch operations reflects the complexity of artifact differences; and the component identifier sequence is only used as a deterministic deciding key when the first three items are the same. This approach of first filtering based on feasibility and then sorting by range avoids patches with small ranges that cannot complete the target correction being incorrectly selected, and also avoids the use of weighted averages to cancel out the amplified impact of an additional target component with a short lineage distance.

[0128] Example 6

[0129] This embodiment further defines the dual dependency graph as influencing the closure. The component defined by the local patch is used as the target component to form a candidate dependency graph. The hash of the artifact closure of non-target components is verified to remain unchanged. The downstream closures of the target components in the baseline dependency graph and the candidate dependency graph are merged to obtain the set of influencing components, including:

[0130] S4.1. Perform add, replace, delete, or rearrange operations only on the target components defined by the local patch.

[0131] Local patches are written using a whitelist method, meaning only target components and connecting edges declared in the operation list can be modified. Deletion operations retain the baseline hash and boundary interface of the deleted component, while rearrangement operations record both the old and new topology order to support replay selection of old paths.

[0132] S4.2. Verify that the corresponding components other than the target component maintain consistency in component content, field contracts, environmental conditions, and artifact closure hashes before and after the patch.

[0133] The computation of component artifact closures recursively includes direct resource references up to the content addressing artifact, which cannot be expanded further. Dynamic service bindings record service versions, interface patterns, and response caching strategies. If the hash of any non-target component closure changes, the system reclassifies it as a target component and invalidates its original candidate identity, rather than hiding the change in external dependencies.

[0134] S4.3. The first downstream closure of the target component already exists before the patch is calculated in the baseline dependency graph.

[0135] The first downstream closure starts from the target component that existed before the patch and performs a reachability traversal along field write edges, control edges, and tool call edges. Paths deleted by the candidate version are still retained in the first downstream closure and are used to select records to verify whether the removal of the old behavior affects non-target output.

[0136] S4.4. Calculate the second downstream closure of all target components after patching in the candidate dependency graph.

[0137] The second downstream closure starts from the retained target component, the newly added target component, and the rearranged target component simultaneously. Conditional branches are treated as conservatively reachable when there is a lack of operational evidence; only branches that can be proven unreachable by static mutual exclusion conditions are excluded.

[0138] S4.5. Merge the target component, the first downstream closure, and the second downstream closure into the set of influencing components, and register both the old path in the baseline dependency graph and the newly added path in the candidate dependency graph as paths to be verified.

[0139] To illustrate the impact on the construction of the component collection, it can be represented as:

[0140] (2)

[0141] in, This represents the set of influencing components corresponding to the v-th candidate version; This represents the set of target components for the v-th candidate version; This represents the first downstream closure calculated from the baseline dependency graph; This represents the second downstream closure calculated from the candidate dependency graph; Labels for the baseline dependency graph. The candidate dependency graph is labeled. The union operation of equation (2) causes the old path that exists only in the baseline version and the new path that exists only in the candidate version to enter the verification boundary at the same time.

[0142] In other implementations, the dependency graph can be a component node graph, a field-component bipartite graph, or a property graph with control conditions, as long as it can compute the downstream reachable sets of the baseline and candidate views from the target component. Since the non-target component closure hash and the bipartite reachable sets jointly define the domain of influence, patches cannot escape the verification scope by replacing external bindings or adding implicit paths.

[0143] Specifically, component nodes in the dependency graph record at least the component identifier, component type, field pattern version, and artifact closure hash; field edges record at least the source component, target component, field identifier, read / write direction, and conditional branch; tool call edges also record the tool interface version and call permissions. The baseline dependency graph is derived from the baseline skill package machine-readable manifest and corrected by the baseline actual execution path. The candidate dependency graph is generated by applying partial patches to the parent version dependency graph. If the static manifest is inconsistent with the actual execution edge, the inconsistent edge is marked as an unregistered dependency edge and handled by Implementation Example 7, instead of being silently added during closure calculation.

[0144] Both the first and second downstream closures can be implemented using graph traversal with a visit set. Traversal starts from each target component, adding target nodes of field-writing edges, control edges, and tool-call edges to the visit queue; already visited components are not expanded again, edges with conditions determined to be false are not added to the queue, and edges with unknown conditions are added to the queue based on conservative reachability. For deleted components, the first downstream closure continues to expand along the baseline edge to identify non-target components that may be affected by the missing old output; for added components, the second downstream closure expands together from the added component and the anchored component to cover the newly inserted path and bypass branches.

[0145] It is worth noting that the "immutability" of the non-target artifact closure hash requires that both the closure member set and the content of each member remain unchanged. The system first generates a typified list of prompt resources, rule files, model bindings, runtime libraries, reference configurations, and permission configurations, and then generates a closure summary by sorting by type and content address. If a candidate version only changes the external binding address without changing the component body, the closure member set will still change, thus triggering non-target component change handling. The dual-graph closure is responsible for limiting the scope of dependency propagation, and the artifact closure hash is responsible for limiting the scope of behavior sources. The combination of the two can respectively intercept "new path escape" and "external resource replacement escape".

[0146] Example 7

[0147] like Figure 4 As shown, this embodiment further defines replay stabilization. The selected execution path hits the record of the affected component set, and the baseline skill pack and the candidate skill pack are run under frozen conditions. The candidate version identifier, the affected component set, and the replay sample set are determined based on the newly added dependency edges, including:

[0148] S5.1. Select the historical records of the actual execution path hitting the set of affected components or the candidate statically conservative reachable components hitting the set of affected components as the initial replay records. The candidate statically conservative reachable components refer to the set of components that can be reached by the candidate skill package, which is determined based on the candidate dependency graph and frozen input fields, without executing the candidate skill package, by treating all post-execution fields that may be changed by the target component or downstream affected components as unknown values ​​and including all structurally feasible branches.

[0149] The first type of record is used to cover the baseline path that has already occurred, and the second type of record is used to cover the conditional branches that may be newly triggered by the candidate version. Sample selection can also be hierarchically based on environmental sub-fingerprints, so that records matching the candidate routing conditions, boundary records, and environmental mismatch records are all included. If the historical records are insufficient, the system does not replace the evidence integrity requirement with the synthesized result, but sets the candidate to an insufficient evidence state.

[0150] S5.2. Freeze the input, unmodified dependencies, valid configuration, runtime, time zone, random parameters, and evaluator version, and run the baseline skill pack and the candidate skill pack on the initial replay record respectively.

[0151] Baseline and candidate runs share the same frozen inputs and evaluator, but load their respective valid configurations and version artifacts. External tools can use the same recorded response replay, or record new response identities and incorporate them into candidate version identities when real-time invocation is permitted. Performance evaluations use the same hardware tier and resource quotas to minimize the impact of environmental differences on performance degradation results.

[0152] S5.3. In response to the presence of unregistered dependency edges in the candidate's actual execution path, invalidate the identity of the current candidate version and existing verification evidence.

[0153] Unregistered dependency edges include tool calls outside the component call list, read-write relationships not declared in the field pattern, and resources dynamically loaded at runtime. This edge indicates that the previous candidate dependency graph was incomplete, therefore the existing set of affected components and sample sets are no longer sufficient. The system saves the trigger record, source component, target component, and field conditions for subsequent reconstruction.

[0154] S5.4. When the unregistered dependency edge involves the target component, re-form the candidate version identity and replay all selected replay records; when the unregistered dependency edge is completely outside the target component, isolate the candidate skill pack.

[0155] New dependencies involving the target component can be included in a local patch, but the artifact closure hash, candidate dependency graph, and version identity must be recalculated, and the process must be replayed starting from the first selected record. New dependencies completely outside the target component indicate changes in the behavior of non-target components, violating the local patch boundary, and are therefore isolated directly without expanding the patch scope.

[0156] S5.5. In response to the appearance of a registered new branch in the candidate actual execution path, expand the set of affected components and supplement and replay historical records until the candidate version identity, the set of affected components and the set of replay samples no longer change.

[0157] The stabilization condition employs a ternary joint condition; a new verification round begins whenever any object changes. The maximum number of stabilization rounds can be set from 3 to 10. If instability persists after reaching the upper limit, manual analysis is initiated, and no gating pass result is output. In one example, the first round of candidate execution triggers the registered unit conversion branch, increasing the affected component set by two components. The system then selects the record corresponding to the original unit and enters the second round. Since none of the ternary objects change in the second round, stabilization is complete.

[0158] The key to this mechanism is not increasing the fixed number of replay samples, but rather updating the sample selection based on feedback from real candidate paths. Since unregistered dependency edges will withdraw existing evidence, and registered new branches will expand the influence domain and samples, the narrower validation boundaries in the early stages cannot continue to support the wider candidate behavior in the later stages, thus mitigating the problem of missing new paths with a fixed sample set.

[0159] In this embodiment, the replay sample set can be used to build a coverage matrix based on environmental routing conditions, target field categories, baseline actual paths, and candidate conservative paths. Records within the boundaries of the environmental routing conditions are used to evaluate the expected applicability of candidates, records on the boundaries are used to check routing critical conditions, and records outside the boundaries are used to confirm that candidates will not be incorrectly loaded. For candidate new condition branches, at least records that can make the branch conditions true and false are selected; if one type of record cannot be obtained, the corresponding branch is marked as insufficient evidence, and the missing coverage is not replaced by a large number of records from other branches.

[0160] Specifically, each stabilization round generates a round list, recording the candidate version identity, a summary of the affected component set, a summary of the replay sample set, a summary of the actual path, newly added dependency edges, and gating pre-check results. Before the next round begins, each of these summaries is compared. If only samples are added while the candidate version identity and affected component set remain unchanged, the new samples and existing samples continue to execute under the same version identity. If dependency edges or artifact closures change, a new candidate version identity is formed, and all passing results under the previous identity cannot be transferred to the new identity. Evidence from the previous round can be retained as problem localization data but is not included in the evidence completeness calculation for the new identity.

[0161] The system sets the stabilization termination condition as follows: the candidate version identity, the set of affected components, and the set of replay samples all remain unchanged after a complete round of execution, and all selected records have completed baseline and candidate pair replays. If there are timeout records, missing external responses, or evaluator failures, the round is not considered complete even if the summaries of the three sets have not changed. The upper limit of stabilization rounds is used to limit computational resources, not to lower the stabilization condition; when the upper limit is reached, the reason for instability, the last changed object, and incomplete records are output for authorized operators to determine whether to adjust local patches or supplement samples.

[0162] Example 8

[0163] This embodiment further defines independent verification and itemized gating. The independent verifier recalculates the hard constraints of data processing and performs itemized gating. Zero-tolerance judgment is applied to violations of the hard constraints and violations of the prohibited change fields. It is prohibited to offset any zero-tolerance judgment result with other gating indicators. After passing the judgment, an immutable version with environmental routing conditions is saved. The independent verifier recalculates the hard constraints of data processing and performs itemized gating, which includes:

[0164] S6.1. Deploy the independent verifier outside the write permission domain of the local patch, and prohibit the candidate skill pack from being written into the audit configuration of the independent verifier.

[0165] The independent verifier obtains candidate outputs and valid configurations through a read-only interface, and the verification configuration is fixed by an independent version identifier. Candidate skill packs can output self-check information for debugging, but this self-check information does not participate in final gating. Access control can be achieved through independent process accounts, read-only mounting, and signature configuration.

[0166] S6.2. The independent validator reads the frozen input, candidate valid configurations and candidate outputs, and recalculates the required fields, data types, numerical ranges, consistency of items, equipment and units, applicable conditions of reference configurations, consistency of associated fields, source traceability and data access permissions.

[0167] The recalculation starts from the frozen input and does not reuse the "passed" status given within the candidate skill pack. The reference configuration application conditions should at least associate the project code, device category, detection method, unit, applicable object attributes, and validity period. Source tracing checks whether each key candidate field can point back to an input snapshot or a registered intermediate field; data access permission checks whether the fields actually read by the component belong to the field contract's allowed set.

[0168] S6.3. Calculate the target acceptance result, non-target field degradation result within the influence domain, environment boundary crossing result, path boundary crossing result, prohibited change field violation result, and performance degradation result between the target field and the audited and confirmed target output, respectively.

[0169] The target acceptance results can be determined by exact matching, normalized matching, or set relationship; the non-target field degradation results only count general fields within the influence domain, and do not misjudge derived fields that are allowed to change together as degradation; the environment out-of-bounds results compare the pre-execution environment configuration vector of the replay record with the candidate environment routing conditions; the path out-of-bounds results check whether the actual path exceeds the set of influence components after stabilization.

[0170] S6.4. Zero tolerance judgment shall be performed on the results of violations of hard constraints in data processing and the results of violations of the prohibited change fields, and it is prohibited to offset any zero tolerance judgment result with other gating indicators.

[0171] Zero-tolerance criteria mean that if a single definite violation is found, the record will not be included in the average evaluation. For general non-target field degradation and performance degradation, thresholds can be set separately according to environment stratification, but the thresholds, evaluator version, and sample stratification rules must be frozen before replay.

[0172] S6.5. Output the gate pass result only when the evidence is complete, all zero-tolerance judgment results are not violated, and the remaining sub-gate control results meet the corresponding sub-gate control threshold.

[0173] Gating logic can be represented as:

[0174] (3)

[0175] in, This represents the gating result of the w-th candidate validation; This indicates a Boolean result where no hard constraints or fields requiring no change in the data processing have been violated. A Boolean result indicating complete evidence; This represents a Boolean result indicating that the target acceptance condition has been met. This indicates a Boolean result where neither the environment nor the path has exceeded the bounds. This represents the Boolean result of general non-target field degradation and performance degradation meeting the corresponding threshold. Equation (3) uses logical conjunction instead of weighted average, and the gate pass result should not be output if any Boolean result is false.

[0176] After gating passes, the system re-verifies that the skill pack content, component artifact closures, valid configurations, environmental conditions, and validity periods have not changed during the verification period before saving the immutable version. The new version can sequentially enter shadow run, restricted environment run, and official activation states. In the event of a production anomaly, the system can only switch to an immutable version that has passed the same gating and is compatible with the current pre-execution environment; it cannot load old artifacts that have not been verified by the current configuration based solely on parent version relationships.

[0177] Specifically, the independent validator's audit configuration includes rule identifier, rule version, applicable field pattern, applicable environmental conditions, severity level, and failure handling. When loading the audit configuration, the configuration signature and validity period are verified first, and then the applicable rule is selected based on the field pattern of the candidate output. Candidate skill packs can only submit frozen inputs, candidate valid configurations, and candidate outputs through a read-only request interface; skipped rules cannot be specified, and the rule severity level cannot be changed. The independent validator outputs the input evidence, recalculation result, and configuration version for each rule, enabling the gating conclusions to be reviewed again.

[0178] Evidence integrity includes at least the following: readable input snapshots, parsable component artifact closures, completed baseline and candidate replays, recorded actual paths, completed stabilization rounds, consistent evaluator versions, and complete gating environment fields. If any condition is missing, the gating result is insufficient evidence, not no violation found. For fields prohibited from change, the system uses a three-item consistency comparison: field identifier, field schema version, and normalized field value. For source tracing, key candidate fields must have a continuous field lineage from the input snapshot or registered intermediate fields to the candidate output. These checks are output separately to facilitate determining whether the failure stems from the candidate content, the verification environment, or the evidence chain itself.

[0179] Furthermore, during the shadow runtime phase, no candidate outputs are submitted to the official downstream; only the path, field differences, and performance of the candidate versions are compared with the currently effective version. During the restricted environment runtime phase, candidate versions are loaded only within a preset range that meets the routing conditions of the verified environment, and a fast switching interface is retained. Before the official implementation, it is checked again whether any new dependency edges or new environment combinations have appeared during the shadow runtime and restricted environment runtime. If new dependency edges appear, a stable replay is returned; if only unverified environment combinations appear, the current routing range is maintained, and the environment combinations are not automatically incorporated into the applicable conditions. Thus, the version release range expands with evidence, rather than automatically expanding with runtime.

[0180] Example 9

[0181] This embodiment adds a univariate intervention validation branch after obtaining the causal component set in embodiment 4. After obtaining the causal component set, it also includes:

[0182] S2.6. Generate a set of cause hypotheses based on the set of cause components, the lineage of fields, the evidence of the execution of the components, and the field differences between the audited and confirmed target output and the candidate output. Each cause hypothesis includes a candidate component, an expected abnormal intermediate result, a suggested intervention action, and an expected repair field.

[0183] The causal hypothesis is formed based on the earliest difference location, data dependency direction, and component write field range. Multiple components sharing the same upstream anomaly are recorded as competing hypotheses, and the system does not directly identify all components as the causal component simply because logs appear simultaneously.

[0184] S2.7. Copy the baseline skill pack and the corresponding input snapshot, and for each of the stated causes, assume that only the intermediate output, component parameters, rule conditions, or component call order of a candidate component are changed to obtain a single-variable intervention copy.

[0185] Intervention values ​​are derived from audited and verified target values, baseline evidence, or independently audited configurations, and are not arbitrarily constructed by the patch generator. Except for the target variable, component artifact closures, inputs, external responses, and operating parameters are consistent with baseline execution. Intervention copies are stored in an isolated area and marked as unpublishable.

[0186] S2.8. Run the univariate intervention copy under the same freeze execution conditions, compare the earliest abnormal intermediate results, the target field, the non-target field, and the data processing hard constraint recalculation results to obtain the target repair contribution and the non-target perturbation amount.

[0187] The contribution of target repair can be calculated based on the proportion of target fields that change from not meeting acceptance criteria to meeting acceptance criteria. Non-target disturbances can be calculated based on the number of differences in general fields other than those prohibited from change. Hard constraints in data processing are still recalculated by an independent validator, and the verification flags that interfere with the copy itself are not used.

[0188] S2.9. Mark the cause hypothesis that both the earliest abnormal intermediate result and the target field are restored as primary cause candidates, mark the cause hypothesis that only the target field is restored as compensation candidates, and eliminate the cause hypothesis that the hard constraint of the newly added data processing is violated.

[0189] The primary cause candidate indicates that a controlled change simultaneously restores the earliest point of difference and its downstream outputs; the compensation candidate only indicates that a downstream component can mask an existing anomaly, without interpreting the downstream component as the primary cause. Retaining both types of labels is beneficial for evaluating compensation schemes when the primary cause component cannot be modified, but the compensation scheme still needs to undergo full patch scope and gating verification.

[0190] S2.10. Form a patch priority queue according to the descending order of the target repair contribution, the ascending order of the non-target perturbation amount, and the ascending order of the number of modified components. Submit the candidate components and suggested intervention actions in the patch priority queue to the trial patch generation process, and prohibit writing the univariate intervention copy to the production version.

[0191] Univariate interventions only provide ranking evidence for the generation of trial patches and do not replace the field contracts, dependency integrity, and mandatory check node dominance checks in Example 5. Since each intervention only changes one candidate factor, the output differencing can provide stronger counterfactual evidence for causal hypotheses than static correlations; at the same time, preserving the distinction between primary and compensatory candidates reduces the risk of mistakenly writing downstream compensatory capacity as a root cause localization conclusion.

[0192] In this embodiment, the causal hypothesis is a structured record that can be isolated and replayed for falsification, not free text speculation. In addition to candidate components, expected abnormal intermediate results, suggested intervention actions, and expected repair fields, supporting evidence identifiers, competing hypothesis identifiers, and intervention application conditions can also be recorded. Expected abnormal intermediate results must be locatable within the component execution evidence; suggested intervention actions must fall within the scope of intermediate outputs, component parameters, rule conditions, or call order that the candidate component is allowed to modify; hypotheses exceeding the component field contract are excluded during the generation phase.

[0193] Specifically, the univariate principle uses one variable in the candidate version identity as the boundary. When replacing the intermediate output of a component, the component parameters, component artifact closures, and invocation order remain unchanged; when adjusting component parameters, the intermediate output is recalculated by the component and not directly injected; when adjusting the invocation order, only the order of registered components with field contract compatibility is changed. If an intervention changes two variables simultaneously, the intervention is split into two univariate copies; only when neither univariate copy satisfies the target acceptance is component combination considered in the trial patching phase, and the combination result is not used to prove that a single component is the primary cause.

[0194] To control the number of interventions, the system first filters causal hypotheses based on the initial occurrence of the difference, the overlap of written fields, and the distance of field lineage. Then, it executes interventions within the preset maximum number of intervention copies and time budget. When the budget is exhausted, the system retains the results of completed interventions and the list of unverified hypotheses, without marking unverified hypotheses as non-contributing. In one example, after intervention by the upstream related component, the earliest abnormal intermediate result and the target field recovered simultaneously, while after intervention by the downstream candidate generation component, only the target field recovered. The system marks these as primacy candidates and compensation candidates, respectively, and prioritizes submitting the upstream related component to the trial patch generation process.

[0195] Example 10

[0196] like Figure 5 As shown, this embodiment provides a local self-evolution device for a health checkup skill package, including:

[0197] The evidence and event generation module is used to process the collected physical examination data by running the benchmark skill package, record the execution evidence of the components, receive the review and error correction information and generate evolution events; wherein, the fields of the candidate output in the evolution events are divided into target fields, derived fields that are allowed to change together, fields that are prohibited from changing and audit fields, and mutual exclusion checks are performed, and evolution events with intersections or conflicts are set to manual review status;

[0198] The cause component localization module is used to trace backward from the target field of the evolution event along the field lineage, compare the component input-output snapshots with intermediate results within the actual execution path, and obtain the set of cause components to be removed from locked components and forced verification nodes;

[0199] The local patch determination module is used to construct a subset of candidate components that cover the target field, generate trial patches and isolate replays, and determine local patches and candidate skill packs according to patch range, bloodline distance and number of operations;

[0200] The influence set generation module is used to form a candidate dependency graph with the component defined by the local patch as the target component, verify that the closure hash of the artifact of the non-target component remains unchanged, and merge the downstream closure of the target component of the baseline dependency graph and the candidate dependency graph to obtain the influence component set.

[0201] The replay stabilization module is used to select the records that the execution path hits the set of affected components, run the baseline skill pack and the candidate skill pack under frozen conditions, and determine the candidate version identifier, the set of affected components and the replay sample set based on the newly added dependency edges;

[0202] The gating and version saving module is used to recalculate the hard constraints of data processing by an independent validator and perform item-by-item gating. The module performs zero-tolerance judgment on the violation results of the hard constraints of data processing and the violation results of the prohibited change fields. It prohibits the cancellation of any zero-tolerance judgment result by other gating indicators. After passing the judgment, an immutable version with environmental routing conditions is saved.

[0203] The aforementioned modules can be implemented by different software processes on the same computing device, or distributed across skill package runtime nodes, isolated replay nodes, and independent verification nodes. The evidence and event generation module, cause component location module, local patch determination module, impact set generation module, and replay stabilization module cannot obtain write permissions for the independent verifier's audit configuration; the gating and version saving module can only bind the passing result to the frozen candidate version identity and cannot regenerate patches after gating. Data is passed between modules through execution identifiers, content hashes, and candidate version identities to maintain the evidentiary relationships in the method embodiment.

[0204] Specifically, the evidence and event generation module outputs evolution event identifiers and component execution evidence indexes; the cause component location module reads the indexes and outputs a set of cause components and an initial difference field; the local patch determination module outputs a patch operation list, candidate skill pack addresses, and candidate version identities; the influence set generation module outputs an influence component set summary and paths to be verified; the replay stabilization module outputs a list of stable rounds and a replay sample set summary; and the gating and version saving module reads the aforementioned outputs and generates an immutable version address. Each message transmitted between modules carries an execution identifier, mode version, and content summary. The receiving module verifies all three before processing, thereby preventing the cross-use of data from different evolution events or different candidate rounds.

[0205] Each module is deployed decoupled through a persistent task queue. Task messages contain idempotent keys; if the same idempotent key arrives repeatedly, the already formed immutable processing result is returned, and patches or versions are not generated repeatedly. When a module fails, only the current stage is retried; the output of completed stages remains read-only. Independent verification nodes cannot call the patch generation interface, and patch generation nodes cannot write to the gating results. For deployments on different compute nodes, module identity can be verified through two-way authentication and message signatures, and the scope of readable field snapshots can be limited by the least privilege account. The above deployment method does not change the functional boundaries of the six modules, but only provides them with auditable communication and fault isolation implementation.

[0206] Example 11

[0207] This embodiment provides an alternative method for locating cause components using hierarchical reasoning and dual-signal sorting. When a skill package contains multiple sub-processes, reused components, or fields with the same name undergoing transformation, the system first traverses all upstream paths backward along the baseline dependency graph from the target field, and then aggregates them into candidate containers for sub-processes based on the entry data source, processing task, and mandatory verification boundary. Mandatory verification nodes serve as container boundaries and are not included in modifiable components.

[0208] The system generates a structured explanation record for each candidate sub-process container. This record includes supporting evidence identifiers, counter-evidence identifiers, potential discrepancy mechanisms, and expected affected fields. The explanation generation process can only reference components, fields, and intermediate results already existing in the component execution evidence; objects not appearing in the execution evidence cannot be written into the explanation record as facts. The system calculates the semantic judgment score between the explanation record and the structured error correction reason, as well as the embedding similarity between the target field evidence vector and the sub-process evidence vector, and uses both as independent ranking signals.

[0209] When the difference between two sorting signals does not exceed a preset conflict threshold, the system sorts the sub-processes according to preset combination rules; when the difference exceeds the preset conflict threshold, the corresponding sub-process enters a manual review state instead of being automatically eliminated. The system repeatedly performs structured interpretation and dual-signal sorting on components in sub-processes whose rankings are within a preset range, and then combines field lineage distance, the first occurrence position of the difference, and the overlap of write fields to obtain component-level sorting. Embedded similarity is only used for sorting and is not used as causal proof; a component is only included in the causal component set if it simultaneously meets the conditions of field lineage reachability, actual path participation, and intermediate result evidence.

[0210] By first locating the sub-process container and then locating the components, the search space is narrowed from the entire skill set component set to several local subgraphs related to the target field; by separately retaining semantic judgment signals and computable similarity signals, signal conflicts are not masked by the average value. The output of this alternative approach is still a set of causal components with evidence and ranking information, which can be directly connected to the candidate component subset and trial patch process of Example 5.

[0211] Specifically, candidate containers for sub-processes are formed based on the set of entry fields, the set of output fields, and mandatory validation boundaries. Two upstream paths with the same entry data source and passing through the same mandatory validation node before reaching the target field can be grouped into the same container; those with different entry data sources, different processing tasks, or crossing different mandatory validation boundaries are formed into separate containers. Each container records its internal component set, boundary input fields, boundary output fields, actual hit count, and earliest discrepancy location. This record ensures that coarse-grained sorting is still constrained by field lineage boundaries, preventing unreachable sub-processes from being prioritized solely based on text topic.

[0212] Evidence vectors can be formed by encoding field identifiers, field patterns, write field sets, difference locations, component types, and structured error correction reasons. Semantic judgment scores and embedding similarities are normalized at the same candidate level before entering the combined sorting process, avoiding direct comparison between component-level and sub-process-level scores. A preset conflict threshold is set based on historically confirmed events or validation sets and is frozen along with the sorter version. If a semantic judgment supports a container but the field lineage is unreachable, the system directly excludes it based on structural constraints; if the field lineage is reachable but two sorting signals conflict, the candidate is retained and transferred to manual review. Thus, the dual signals are used to narrow down the review order, rather than replacing the hard conditions of execution evidence and lineage reachability.

[0213] In one example, the skill set includes a field standardization sub-process, a cross-project association sub-process, and a candidate content generation sub-process. All three sub-processes contain field names identical to the target field. Field lineage indicates that the target field is only reachable by the latter two sub-processes; therefore, the field standardization sub-process, even with high semantic similarity, does not proceed to refined localization. The earliest difference position and the write field overlap are both high in the cross-project association sub-process. The system first performs component-level sorting within this container and then passes the sorting results to the trial patching process for verification, avoiding unbounded reasoning across all skill set components.

[0214] Example 12

[0215] This embodiment provides a structural verification method for formal component contracts and counterexample trajectories. The system generates a dual-interface component contract, including a formal interface and an execution interface, based on the component's input / output field contracts, permission scope, mandatory validation attributes, and execution order. The formal interface at least describes field existence, field type, unit domain, fields that cannot be changed, component read / write permissions, and required nodes; the execution interface associates component-hinted resources, rules, scripts, or tool call descriptions. Both types of interfaces share the component identifier and version hash.

[0216] After the candidate skill pack is formed, the system only performs contract consistency filtering on the influence subgraph and boundary interfaces where the local patch is located. This checks whether each input is generated by an upstream boundary or component within the subgraph, whether each output satisfies the downstream field pattern, whether the component's reading range exceeds the permission domain, and whether the mandatory verification node still dominates the production of candidate outputs. Continuous numerical fields can be abstracted into unit domains, range buckets, and missing states to reduce the number of verification states; the specific values ​​are still recalculated by an independent validator during sample playback.

[0217] For candidate dependency graphs that pass consistency filtering, the system verifies that every production candidate output path passes through a corresponding mandatory verification node before forming a candidate output, and verifies that failed branches enter a blocked state or a manual review state. If verification fails, the system outputs the shortest counterexample trajectory from the candidate entry point to the first violation state. The shortest counterexample trajectory includes the first component that violates the contract, dependency edges, field conditions, and expected state, and is converted into a restricted correction instruction that can only adjust the target component interface or connection conditions in a local patch; the restricted correction instruction cannot modify the independent audit configuration.

[0218] Formal verification only demonstrates that field contracts, permissions, and path structures satisfy preset invariants, without replacing the sample replay of Example 7 and the independent gating of Example 8. Candidate skill packages can only be saved as immutable versions after sequentially passing contract consistency, path temporal invariants, stable replay, and itemized gating. Therefore, violation paths not covered by historical samples but reachable from the dependency structure can be detected in advance through counterexample trajectories, and corrections are still limited to local patch boundaries.

[0219] In this embodiment, the formal interface uses finite states to represent field conditions. Field existence includes existent, missing, and inapplicable states; numerical range uses a preset range bucket; units use the set of units allowed by the field contract; permissions use readable, writable, and blocked states; and mandatory validation attributes use not passed, passed, and blocked states. Component calls in the execution interface are converted into state transitions, with preconditions from the input field contract and postconditions from the output field contract. The abstraction of continuous values ​​is only used to check structural reachability; the actual field values ​​are not removed from the sample replay.

[0220] The shortest counterexample trajectory is recorded sequentially according to the candidate entry point, component call, field status, and validation status, until the first position that does not meet the contract. When generating restricted correction instructions, the system only extracts the first violation belonging to the target component or candidate connection edge in the counterexample, along with the expected field status; when the counterexample falls on a non-target component or an independent audit configuration, the local patch is not automatically expanded, but the candidate is isolated. The corrected candidate forms a new artifact closure hash and candidate version identity, and execution starts from the contract consistency check again, without using the old candidate's form to verify the passing result.

[0221] The system clusters multiple counterexamples based on the first violating component, field identifier, and expected state, prioritizing the processing of the same interface condition that covers multiple counterexamples. This clustering only adjusts the correction order and does not merge multiple different violations into an unverified composite modification. If formal verification does not find a counterexample, the candidate continues into stabilization replay; if formal verification produces a counterexample but it cannot be eliminated within a preset correction round, the candidate remains rejected and the last counterexample is saved. This closed loop ensures that structural defects have clear input conditions, violation locations, and handling results, rather than simply outputting an unexecutable "verification failed" flag.

[0222] Example 13

[0223] This embodiment provides a complete software processing example. A physical examination data processing platform loads a benchmark skill package and generates candidate content for review from the collected structured examination fields, imaging examination findings fields, questionnaire fields, and historical physical examination fields. The review terminal discovers that a candidate content is missing an examination findings field that already exists in the input snapshot, confirms the target output, and selects "cross-item related omission" as the reason for structured error correction.

[0224] The system traced the target field's lineage backwards and found that the output snapshots of the field mapping component, unit conversion component, and reference configuration selection component were consistent with the baseline evidence. The first discrepancy appeared in the cross-project association rule component. This component was not a locked component and was located upstream of the mandatory verification node, thus entering the cause component set. The system formed two candidate component subsets: the first candidate component subset contained only the cross-project association rule component; the second candidate component subset contained both the cross-project association rule component and the candidate content generation component.

[0225] Two subsets of candidate components generate trial patches and are replayed in an isolated environment. The first trial patch ensures the target field meets the review objectives, and the prohibited change fields remain unchanged. The second trial patch also meets the acceptance objectives, but modifies more components and performs more operations. Based on this, the system selects the first trial patch to generate a partial patch and a candidate skill pack. A new registered branch is added to the candidate dependency graph, from the cross-project association rule component to the candidate content generation component. The system includes this branch in the second downstream closure, expands the set of affected components, and supplements the historical records that hit this branch.

[0226] After stabilization, the independent validator recalculates required fields, data types, numerical ranges, unit consistency, applicable conditions of the reference configuration, consistency of associated fields, source traceability, and access permissions. Target fields meet the confirmation objectives, fields requiring no change show no differences, hard constraints on data processing are not violated, and general degradation of non-target fields and performance degradation are within the freeze threshold. The system saves candidate skill packages, valid configurations, artifact closure hashes, and applicable environmental conditions as immutable versions and loads them first within the shadow runtime scope matching the environmental conditions. The above example is only for illustrating the complete processing chain and does not impose limitations on the categories of health check items, the number of components, or environmental fields.

[0227] In one verification configuration of this example, the system selects 48 records from historical records matching the routing conditions of the candidate environment, and 12 records from records of routing boundaries and environment mismatches. The first round of replay reveals 8 records that trigger newly added but already registered cross-project related branches, affecting the component set by adding candidate content generation components and field consistency verification components; the system then selects 12 additional records that match the new branches. In the second round, the candidate version identity, affected component set, and replay sample set remain unchanged, and all 72 records complete baseline and candidate pair replays, ending the stabilization phase. The number of records mentioned is an exemplary configuration; the actual number can be determined based on environment combinations, target field categories, and branch coverage.

[0228] Furthermore, during shadow execution, the system continues to record candidate actual paths but does not submit candidate outputs to the formal downstream. If the shadow record hits the same path and environment combination as the verification phase, runtime evidence is accumulated; if an unregistered dependency edge appears, candidate loading is immediately stopped and the system returns to the impact analysis phase; if a new environment combination appears but the path remains unchanged, the original environment routing conditions are maintained and a verification task to be expanded is formed. Thus, the immutable version in the example can be gradually deployed within the already verified scope without unchecked expansion of its applicability due to the observation of new data after deployment.

[0229] Example 14

[0230] (a) Business Scenarios

[0231] This example illustrates a conclusion merging and error correction process that occurs during a real-world medical examination at a healthcare institution. For clarity, the following values ​​are an anonymized example using actual field structures and do not contain information that could identify the examinee. Environment HA corresponds to healthcare institution A, interface version V3, blood lipid reference configuration R12, and overall examination expression specification P7. After receiving two abnormal pieces of evidence from the four blood lipid items, baseline skill package B0 generates two candidate conclusions: "elevated total cholesterol" and "elevated low-density lipoprotein cholesterol." The attending physician at institution A, based on the institution's overall examination specifications, merges the two conclusions and modifies them to "abnormal blood lipids."

[0232] E1 Medical Laboratory Four blood lipid tests Total cholesterol 5.27 mmol / L ↑ E2 Medical Laboratory Four blood lipid tests Low-density lipoprotein cholesterol 3.36 mmol / L ↑

[0233] Output before correction merged_diagnoses[3].title Elevated total cholesterol; elevated LDL cholesterol Benchmark execution R0 generation Target output confirmed by review merged_diagnoses[3].title dyslipidemia Confirmed by the chief physician of Institution A Fields that are prohibited from changing evidence[*] The items, values, units, reference ranges, and sources for E1 and E2 must not be changed. Zero tolerance Allowed fields to change sort_index, explain, advise Recalculation is permitted due to changes in merged headings, but no new diagnoses may be added. Independent evaluation

[0234] (ii) Generation and Evolution Events

[0235] The audit terminal saves the output before correction, the target output, the audit terminal identifier, the confirmation status, and the confirmation time, and sets the structured error correction reason to "The hospital-oriented merging method under the same disease mechanism does not comply with institutional standards." The system sets the title field and grouping field as target fields, sorting, interpretation, and recommendation as fields that allow common changes, and original evidence objects, values, units, reference ranges, source departments, and combined items as fields that prohibit changes. The system also records the environment HA and generates an evolution event EV-A1.

[0236] If the doctor only inputs free text without confirming the target output, or if the target field overlaps with a prohibited change field, the system will not initiate automatic patch generation but will instead place the evolution event in a manual review state. Only evolution events that have been confirmed and whose field sets are mutually exclusive can proceed to subsequent localization steps.

[0237] (III) Component for locating the cause of lineage along the field

[0238] The system iterates through the field lineage from merged_diagnoses[3].title and the grouping identifier of the conclusion in reverse order. The actual path after intersecting with R0 of this execution is: original blood lipid evidence → input preparation component C2 → diagnosis and abnormality verification component C3 → conclusion merging component C4 → sorting and suggestion component C5 → report assembly component C6. The system compares the input and output snapshots of the components level by level, confirming that the output of C2 still contains E1 and E2, and C3 has formed two abnormal conclusions with complete original evidence respectively. The difference first appears in the grouping and title of the output of C4. Therefore, C4 enters the causal component set, C2 and C3 are only retained as upstream evidence nodes, and C5 and C6 are downstream components within the influence domain, not as causal components.

[0239] (iv) Forming a subset of candidate components and selecting local patches

[0240] P1 Only C4 institutions A merge rule resources Add a restrictive rule that "dyslipidemia is a combination of environmental HA and the simultaneous presence of E1 and E2". 1 pass P2 C4 Merge Resource Hints and C5 Suggestion Resource Hints Simultaneously modify the merging method and suggestion generation method. 2 The target was reached, but the scope was large. P3 C3 Diagnostic Rules Resources Rewrite the two inputs directly into one diagnosis. 1 Change upstream diagnostic semantics, eliminate

[0241] The system first verifies the parent version hash, target component hash, field contract, permission scope, and mandatory verification node dominance. Both P1 and P2 can achieve the target title, but P1 modifies fewer components, has a shorter lineage distance to the target field, and performs fewer operations; P3 changes the original diagnostic semantics and alters the source relationship of fields that are prohibited from change. The system selects P1 as a local patch according to deterministic lexicographical order, generating candidate skill pack B1.

[0242] (v) Forming a set of influencing components

[0243] The system uses C4 and its institution A merge rule resources as target components, confirming that the component content, field contracts, permission configurations, and artifact closure hashes of C1, C2, C3, and C7 are consistent between B0 and B1. In the baseline dependency graph, the downstream closure of C4 includes C5 and C6; in the candidate dependency graph, the downstream closure of C4 also includes C5 and C6, and a new registered condition edge is added from the institution rule selection node to C4. Therefore, the system merges C4, C5, C6, and the aforementioned institution rule selection node into an affected component set I-A1.

[0244] (vi) Freeze-paired playback and stabilization

[0245] The system selects historical records based on environmental routing conditions, target field category, baseline actual path, and candidate conservative paths. Input snapshots, non-target component artifact closures, valid configurations, runtime, time zone, random parameters, external model responses, and evaluator versions are all frozen. Each record is run by B0 and B1 respectively, yielding pairwise results that can be compared field by field.

[0246] Institution A and both of the above increased. Covering the true branch of the target rule The candidate title should be "Dyslipidemia," and both E1 and E2 should be retained. Institution A and only one item increased Covering target rule pseudo-branch and boundary conditions No incorrect merging is allowed, and no additional evidence may be fabricated. Institution A and both are normal Covering normal boundaries The conclusion of dyslipidemia must not be generated. The same anomalous combination of agency B or agency C Coverage environment mismatch Each base version must continue loading; B1 must not be hit. The field name is either the organization's abbreviation or the interface alias. Covering semantic mapping boundaries A match is only allowed if both the project code and the medical meaning are a match.

[0247] If a new conditional branch appears in the first round of candidate replay, the system expands the set of affected components and adds records that match that branch. If an unregistered dependency edge appears, the current candidate version identity and existing verification evidence become invalid. If an unregistered dependency edge involves the target component, a new candidate version identity is formed and replay begins from the first record. If the dependency edge is completely outside the target component, the candidate skill set is isolated. The stabilization phase ends only when the candidate version identity, the set of affected components, and the set of replay samples remain unchanged throughout a complete replay cycle.

[0248] (vii) Independent gating and environmentally targeted release

[0249] Target Acceptance When both of Institution A's criteria are elevated, the headings and groupings are consistent with the physician's confirmed goals. Must pass Hard constraints of original evidence Check that the items, values, units, reference ranges, prompts, source department, and combined items are consistent with the input snapshot. Zero tolerance Completeness of conclusions Each diagnostic indicator must appear only once; no diagnoses without evidence may be omitted, repeated, or newly added. Zero tolerance Environmental transgression Organizations B and C, as well as those with incompatible configurations, must not load B1. Zero tolerance Path out of bounds Candidate actual paths must not bypass anomaly verification and report integrity check nodes. Zero tolerance Non-target degradation Other conclusions, evidence, and their order unrelated to the blood lipid findings must not exceed a preset degradation threshold. Sub-item thresholds Performance degradation Processing time and failure rate under the same resource quota must not exceed the preset threshold. Sub-item thresholds

[0250] The independent validator is deployed outside the local patch write permission domain, and B1 cannot write to the gating rules or change the gating results. After all zero-tolerance items are not violated and the remaining sub-gating passes, the system binds B1, the parent version identity, the valid configuration of organization A, the component artifact closure hash, and the environment HA to an immutable version V-A1. V-A1 first enters the shadow execution scope of organization A, and the shadow output is not submitted to the formal downstream; only after no unregistered dependency edges are found in the shadow stage is it allowed to be loaded step by step according to the environment HA. Organizations B and C continue to use their original versions. The specific activity relationships are as follows: Figure 8 As shown.

[0251] (viii) Technical effects of this embodiment

[0252] This embodiment does not directly propagate a single doctor's modification to the global model behavior. Instead, it uses original evidence, actual execution paths, and field lineage to pinpoint differences within the conclusion merging component. It limits the scope of modification through local patches and downstream closures in the dual-dependency graph; verifies the applicability of the version through environment matching records, routing boundary records, and environment mismatch records; and ensures that original values, units, and source evidence are not altered by institutional preferences through independent zero-tolerance access control. Thus, while supporting personalized overall review standards across multiple institutions, it reduces the probability of irrelevant hospitals and conclusions being modified in conjunction with the changes.

[0253] Example 15

[0254] (a) Business Scenarios

[0255] This embodiment is used to handle situations where imaging or ultrasound examination results contain multiple independently established medical facts. For example, if the original examination result is "benign prostatic hyperplasia with calcification," the examination result splitting component C1 should form two atomic results: "benign prostatic hyperplasia" and "prostatic calcification," each retaining the source identifier of the same original examination object. If the baseline candidate report only contains "benign prostatic hyperplasia," and the attending physician adds "prostatic calcification" and confirms it, the system generates an evolution event where the target field is a newly added item in the list of abnormal conclusions.

[0256] Another possible input is a lung CT scan result containing multiple numbered conclusions. The system must not mechanically break down the entire text into subjectless fragments, nor should it omit independently established nodules, calcifications, bullae, or follow-up recommendations. The splitting component is only responsible for factual breakdown and does not directly form a disease diagnosis; the diagnosis and anomaly verification component determines whether to retain an abnormal fact or form a further diagnosis based on the splitting results and original evidence.

[0257] (ii) Determination of the initial location of difference

[0258] The system first compares the output snapshots of C1. If C1 only outputs "benign prostatic hyperplasia", then the difference first appears in C1, and the cause component set includes C1; if C1 has already output two atomic results, while C3 omits "prostatic calcification", then the difference first appears in C3, and the cause component set includes C3. The system does not modify C1, C3, C4, and C6 simultaneously simply because they all appear to be omitted in the final report.

[0259] For the two competing cause locations, the system constructs univariate intervention copies: the first copy replaces only the intermediate output of C1 with the two verified atomic results; the second copy keeps the output of C1 unchanged and only adjusts the anomaly retention conditions of C3. Under the same freeze conditions, the earliest abnormal intermediate result and the target field are compared. Components that can simultaneously recover both the earliest abnormal intermediate result and the target field are marked as primary cause candidates; components that can only supplement the target field downstream but cannot recover the earliest intermediate result are marked as compensation candidates.

[0260] (III) Local Patching and Gating

[0261] When C1 is identified as the primacy component, the trial patch only adjusts the compound phrase splitting rules or splitting hint resources, maintaining the component contract of "no filtering, no diagnosis, no interpretation, and preservation of all original information." Replay samples must cover at least single facts, compound facts from shared sites, numbered imaging conclusions, normal outcomes, postoperative status, and complete medical facts containing conjunctions such as "with," "and," "as well as," and "and" but which should not be mechanically split.

[0262] Target integrity Any omitted facts confirmed by a doctor must be present, and the original examination data must be traceable. Reconstruction is prohibited No parts, values, diagnoses, or suggestions that do not exist in the snapshot should appear. Non-target maintenance Other atomic results, test values, and diagnostic conclusions in the same record must not be deleted or rewritten. Component boundary C1 must not directly output a disease diagnosis; C3 must not rewrite the original examination facts. Failure path If the structure cannot be reliably split, revert to the original text item; incomplete fragments must not be output.

[0263] This example illustrates that omissions in the same final report may originate from different business code components. By comparing the intermediate results at each stage, rather than just comparing the final text, patches can be limited to the earliest component where differences occurred, preventing downstream prompts from masking upstream splitting errors.

[0264] Examples 14 and 15 use the splitting, diagnosis, anomaly verification, merging, sorting, suggestion, and report assembly nodes in the actual intelligent general inspection business code as baseline skill package components. They specifically illustrate how doctor review and error correction are transformed into evolutionary events, and how the six technical modules of this invention connect to existing project business code. Example 14 emphasizes that environment-oriented business preferences cannot be globally propagated, while Example 15 emphasizes that the same final difference requires locating different primacy components along the field lineage. Both examples sequentially execute baseline evidence recording, causal component location, local patch determination, dual dependency graph impact analysis, frozen pairing replay, stabilization, independent gating, and immutable version saving, without changing the main methodological line described in the preceding examples.

[0265] Those skilled in the art can make equivalent substitutions for the field names, component identifiers, number of replay records, and gating thresholds in the example based on the specific medical examination institution's examination items, interface fields, number of components, and review specifications. Such equivalent substitutions, as long as they maintain the reproducible correlation between component execution evidence and review corrections, patch local boundaries, replay stabilization conditions, and independent gating and environment-oriented version constraints, fall within the scope of the present invention's technical concept.

Claims

1. A method for local self-evolution of a health checkup skills package, characterized in that, Applied to health checkup data processing, the skill package is an executable resource set organized according to processing dependencies, consisting of multiple processing components with clearly defined input and output field contracts, capable of being loaded and executed by computing devices and independently version-managed, used to perform structured processing on collected health checkup data and generate candidate outputs for review by medical personnel, including: The benchmark skill package is used to process the collected physical examination data, record the execution evidence of components, receive audit and error correction information, and generate evolution events. Among them, the fields of the candidate output in the evolution events are divided into target fields, derived fields that are allowed to change together, fields that are prohibited from changing, and audit fields, and mutual exclusion checks are performed. Evolution events with intersections or conflicts are set to manual review status. By tracing back along the field lineage from the target field of the evolution event, and comparing the component input-output snapshots with intermediate results within the actual execution path, a set of reason components for eliminating locked components and forced verification nodes is obtained. Construct a subset of candidate components covering the target field, generate trial patches and isolate replays, and determine local patches and candidate skill packs according to patch range, lineage distance and number of operations; Using the components defined by the local patch as target components, a candidate dependency graph is formed. The closure hash of the artifacts of non-target components is verified to remain unchanged. The baseline dependency graph and the downstream closures of the target components in the candidate dependency graph are merged to obtain the set of affected components. Select the record that hits the set of affected components in the execution path, run the baseline skill pack and the candidate skill pack under frozen conditions, and determine the candidate version identifier, the set of affected components and the set of replay samples based on the newly added dependency edges; The hard constraints of data processing are recalculated by an independent verifier and gating is performed item by item. Zero tolerance judgment is performed on the violation results of the hard constraints of data processing and the violation results of the prohibited change fields. It is prohibited to offset any zero tolerance judgment result with other gating indicators. After passing, an immutable version with environmental routing conditions is saved.

2. The local self-evolution method for the health check-up skill package according to claim 1, characterized in that, The operational benchmark skill package processes the collected physical examination data, records component execution evidence, receives review and error correction information, and generates evolution events; wherein, the recorded component execution evidence includes: The collected physical examination data is processed by protocol decoding, integrity verification, lossless encapsulation of original fields, extraction of source metadata, and desensitization to generate an input snapshot and input hash. A pre-execution environment configuration vector is generated based on the data source system, interface version, device identifier, detection method, project code, original unit, applicable object attributes, and reference configuration version. The pre-execution environment configuration vector is an environment judgment vector for version positive applicability matching generated by encoding fields that can be obtained from source metadata or audit configuration in a fixed order before the skill package is executed. Run the registered components within the benchmark skill package and generate a post-execution environment log set based on the actual standard units, the actual reference configuration version, and the data generation time. The post-execution environment log set is an environmental evidence set for execution evidence verification generated by expanding the pre-execution environment configuration vector with the actual standard units, reference interval versions, and reagent batches according to a fixed field pattern. For each called component, record the component identifier, content hash, artifact closure hash, input / output field mode version, component input / output snapshot, execution order and intermediate results. The artifact closure hash is the content hash value calculated by normalizing and serializing the component itself and all artifact resources that directly or recursively reference it and can change the execution result. External model responses, tool responses, and runtime parameters are associated with the corresponding invoked components using content addressing, and only records that can reproduce the intermediate results are used as component execution evidence to locate the first occurrence of the difference.

3. The local self-evolution method for the health check-up skill package according to claim 2, characterized in that, The operational benchmark skill package processes the collected physical examination data, records component execution evidence, receives audit and error correction information, and generates evolutionary events; wherein, receiving audit and error correction information and generating evolutionary events includes: Display candidate outputs and evidence of component execution associated with those candidate outputs; Receive the target output after review and confirmation, and save the output before correction, the target output, the review terminal, the confirmation status, and the confirmation time. Write the structured error correction reason, applicable environment field, target acceptance conditions, and evidence index into the evolution event; Evolutionary events that only involve expressing preferences are excluded from the production version evolution process.

4. The local self-evolution method for the health check-up skill package according to claim 1, characterized in that, The process involves tracing backwards along the field lineage from the target field of the evolutionary event, comparing component input / output snapshots with intermediate results within the actual execution path, to obtain a set of reason components for removing locked components and forced verification nodes, including: By traversing backwards from the field lineage node corresponding to each target field to the data source node, the field lineage candidate path is obtained; The actual execution path is used to perform intersection filtering on the candidate paths of the lineage in the field to obtain the executed candidate paths; The component input-output snapshots and intermediate results of adjacent components are compared according to the topological order of the executed candidate paths to locate the first occurrence of the difference; Based on the structured error correction causes in the evolutionary events, components that are not related to the target difference between the target field and the audited and confirmed target output are excluded, resulting in an initial set of cause components; Read the component locking attribute and forced validation attribute from the machine-readable manifest of the skill pack, exclude the locked component and forced validation node from the initial cause component set, and retain the upstream variable component of the forced validation node as the cause component set.

5. The local self-evolution method for the health check-up skill package according to claim 4, characterized in that, The process involves constructing a subset of candidate components covering the target field, generating probe patches and isolating replays, and determining local patches and candidate skill packs based on patch range, lineage distance, and number of operations, including: Enumerate existing component combinations that can structurally affect all target fields from the set of cause components, and determine anchor components and candidate insertion positions for the new components when new components are needed, to obtain a subset of candidate components; Deterministic pruning is performed on the candidate component subset based on the maximum number of cause components, the maximum number of candidate subsets, the maximum number of trial patches, and the time budget, using the field lineage distance, component locking attribute, and component identifier. Under the conditions of fixed patch generator version, configuration, random seed and deterministic parameters, generate probe patches corresponding to the subset of candidate components, and perform local replay using the corresponding component execution evidence in an isolated environment; For each of the probe patches, verify the parent version hash, target hash, field contract, dependency integrity, permission resources, component signature, executableness, and mandatory verification node dominance relationship. The mandatory verification node dominance relationship means that every executable path from the entry node to each production output node in the candidate dependency graph passes through the corresponding mandatory verification node. Probe patches that meet the target acceptance criteria and whose applicable environment can be expressed by routing conditions are retained. The components are compared lexicographically according to the size of the union of the component to be modified, the anchored component, and the newly added component, the sum of the bloodline distances of the components in the union to the target field, the number of patch operations, and the sorted component identifiers. The first probe patch in the sorted order is determined as the local patch, and the candidate skill pack is generated based on the local patch. The structured reasons why other probe patches were not adopted are recorded.

6. The local self-evolution method for the health check-up skill package according to claim 1, characterized in that, The process involves using the components defined by the local patch as target components to form a candidate dependency graph. Verification is performed to ensure that the artifact closure hashes of non-target components remain unchanged. The baseline dependency graph and the downstream closures of the target components in the candidate dependency graphs are merged to obtain a set of affected components, including: Only add, replace, delete, or rearrange operations are performed on the target components defined by the local patch; Verify that the corresponding components other than the target component maintain consistency in component content, field contracts, environmental conditions, and artifact closure hashes before and after the patch; The first downstream closure of the target component already exists before the patch is calculated in the baseline dependency graph; The second downstream closure of all target components after patching is calculated in the candidate dependency graph; The target component, the first downstream closure, and the second downstream closure are merged into the set of influencing components, and the old paths in the baseline dependency graph and the newly added paths in the candidate dependency graph are all registered as paths to be verified.

7. The local self-evolution method for the health check-up skill package according to claim 6, characterized in that, The selected execution path hits the records of the affected component set, and the baseline skill pack and the candidate skill pack are run under frozen conditions. The candidate version identifier, the affected component set, and the replay sample set are determined based on the newly added dependency edges, including: The historical records of the actual execution path hitting the set of affected components or the candidate statically conservative reachable components hitting the set of affected components are selected as the initial replay records. The candidate statically conservative reachable components refer to the set of components that can be reached by the candidate skill package, which are determined based on the candidate dependency graph and frozen input fields, without executing the candidate skill package, after treating all post-execution fields that may be changed by the target component or downstream affected components as unknown values ​​and including all structurally feasible branches. Freeze the input, unmodified dependencies, valid configuration, runtime, time zone, random parameters, and evaluator version, and run the baseline skill pack and the candidate skill pack on the initial replay record respectively; In response to the presence of unregistered dependency edges in the candidate's actual execution path, the identity of the current candidate version and existing verification evidence become invalid. When the unregistered dependency edge involves the target component, the candidate version identity is reconstructed and all selected replay records are replayed; when the unregistered dependency edge is completely outside the target component, the candidate skill pack is isolated. In response to the appearance of a newly registered branch in the candidate actual execution path, the set of affected components is expanded and supplemented with additional replay history records until the candidate version identity, the set of affected components, and the set of replay samples no longer change.

8. The local self-evolution method for the health check-up skill package according to claim 7, characterized in that, The process involves recalculating hard constraints in data processing by an independent verifier and then performing itemized gating. This includes applying zero-tolerance judgment to violations of hard constraints and prohibited change fields, prohibiting the use of other gating indicators to offset any zero-tolerance judgment result, and saving an immutable version with environmental routing conditions after passing the judgment. The process of recalculating hard constraints in data processing by an independent verifier and then performing itemized gating includes: Deploy the independent verifier outside the write permission domain of the local patch, and prohibit the candidate skill pack from being written to the audit configuration of the independent verifier; The independent verifier reads the frozen input, candidate valid configurations, and candidate outputs, and recalculates the required fields, data types, numerical ranges, consistency between items, equipment, and units, applicable conditions of reference configurations, consistency of associated fields, source traceability, and data access permissions. Calculate the target acceptance result, non-target field degradation result within the influence domain, environment boundary crossing result, path boundary crossing result, prohibited change field violation result, and performance degradation result between the target field and the audited and confirmed target output, respectively. The gating pass result is output only when the evidence is complete, all zero-tolerance judgment results are not violated, and the remaining sub-gating results meet the corresponding sub-gating threshold.

9. The local self-evolution method for the health check-up skill package according to claim 4, characterized in that, After obtaining the set of cause components, the following is also included: A set of cause hypotheses is generated based on the set of cause components, the lineage of fields, the evidence of component execution, and the field differences between the audited and confirmed target output and the candidate output. Each cause hypothesis includes a candidate component, an expected abnormal intermediate result, a suggested intervention action, and an expected repair field. Copy the baseline skill set and corresponding input snapshot, and for each of the stated causes, assume that only the intermediate output, component parameters, rule conditions, or component call order of a candidate component are changed to obtain a single-variable intervention copy; Run the univariate intervention copy under the same freeze execution conditions, compare the earliest abnormal intermediate results, the target field, the non-target field, and the data processing hard constraint recalculation results to obtain the target repair contribution and the non-target perturbation amount; The cause hypothesis that both the earliest abnormal intermediate result and the target field are restored is marked as the primary cause candidate, the cause hypothesis that only the target field is restored is marked as the compensation candidate, and the cause hypothesis that the hard constraint of the newly added data processing is eliminated. A patch priority queue is formed according to the descending order of the target repair contribution, the ascending order of the non-target perturbation amount, and the ascending order of the number of modified components. Candidate components and suggested intervention actions in the patch priority queue are submitted to the trial patch generation process, and the univariate intervention copy is prohibited from being written to the production version.

10. A locally self-evolving device for a health checkup skill package, characterized in that, include: The evidence and event generation module is used to process the collected physical examination data by running the benchmark skill package, record the execution evidence of the components, receive the review and error correction information and generate evolution events; wherein, the fields of the candidate output in the evolution events are divided into target fields, derived fields that are allowed to change together, fields that are prohibited from changing and audit fields, and mutual exclusion checks are performed, and evolution events with intersections or conflicts are set to manual review status; The cause component localization module is used to trace backward from the target field of the evolution event along the field lineage, compare the component input-output snapshots with intermediate results within the actual execution path, and obtain the set of cause components to be removed from locked components and forced verification nodes; The local patch determination module is used to construct a subset of candidate components that cover the target field, generate trial patches and isolate replays, and determine local patches and candidate skill packs according to patch range, bloodline distance and number of operations; The influence set generation module is used to form a candidate dependency graph with the component defined by the local patch as the target component, verify that the closure hash of the artifact of the non-target component remains unchanged, and merge the downstream closure of the target component of the baseline dependency graph and the candidate dependency graph to obtain the influence component set. The replay stabilization module is used to select the records that the execution path hits the set of affected components, run the baseline skill pack and the candidate skill pack under frozen conditions, and determine the candidate version identifier, the set of affected components and the replay sample set based on the newly added dependency edges; The gating and version saving module is used to recalculate the hard constraints of data processing by an independent validator and perform item-by-item gating. The module performs zero-tolerance judgment on the violation results of the hard constraints of data processing and the violation results of the prohibited change fields. It prohibits the cancellation of any zero-tolerance judgment result by other gating indicators. After passing the judgment, an immutable version with environmental routing conditions is saved.

Images