A field-level workflow local re-planning and safety confirmation method and system

Abstract

The present application belongs to the technical field of workflow orchestration and scheduling, and particularly relates to a field-level workflow local re-planning and safety confirmation method and system. The method comprises a versioned variable storage module, a field fingerprint generation module, a field difference comparison module, an influence subgraph analysis module, a node state machine, a confirmation record generation module and an audit event storage module. Through field fingerprint, field difference comparison and field dependency selector matching, the change detection granularity of workflow variables is lowered to the "field level", thereby refining the re-planning granularity to the field path level and reducing the repeated execution of irrelevant nodes. Through fingerprint comparison and active triggering of influence analysis, the timing of fault discovery and recovery is advanced. Through pre-execution comparison and automatic invalidation of confirmation records and delivery package hashes, the consistency of confirmation actions and data states is ensured, and the risk of erroneous execution of final delivery operations due to background data concurrent updates or asynchronous changes is reduced.

Description

Technical Field

[0001] This invention belongs to the field of workflow orchestration and scheduling technology, specifically relating to a method and system for field-level workflow local replanning and safety verification. Background Technology

[0002] In modern enterprise software architectures and complex data processing systems, workflow orchestration engines play a crucial role. Whether it's data processing pipelines, business collaboration between microservices, or agent task planning based on Large Language Models (LLMs), workflow systems require efficient and accurate scheduling of a series of interdependent task nodes. However, traditional workflow orchestration systems often rerun the entire workflow or downstream link when faced with the failure of a single node or changes in input data, resulting in the repeated execution of many irrelevant nodes and wasting computing resources and time. To address this, several improved technologies have emerged in the industry. Chinese patent CN122288346A proposes a cross-system dynamic workflow orchestration method and system based on user intent recognition; CN121436506A discloses a knowledge-driven agent task planning and workflow generation method in the semiconductor field. CN122288346A and CN121436506A effectively overcome the drawbacks of traditional workflow systems' "global reruns," significantly reducing resource waste. Specifically, they reduce the scope of replanning from "global" to "local," avoiding the repeated execution of irrelevant nodes. CN122288346A, based on the dependency relationships of a directed acyclic graph (DAG), accurately locates the set of affected downstream nodes using a breadth-first search (BFS) algorithm, regenerating the workflow only for the affected subgraph. CN121436506A, based on task output dependencies, analyzes dependencies and only suspends the erroneous subtask and its downstream nodes, resuming execution of the local subgraph after repair. Second, a "successful node protection" mechanism has been implemented to ensure that completed computational results are not wasted and that local replanning is only performed within necessary boundaries: CN122288346A inserts a format conversion node during replanning, cleverly connecting existing execution results and preserving the output of successful nodes; CN121436506A explicitly stipulates that local repair does not affect other branches of the global workflow, and successful subtasks and their outputs remain unchanged.

[0003] However, existing technologies CN122288346A and CN121436506A primarily handle node-level or task-level workflow adjustments, and still have the following three shortcomings when facing more granular data changes and confirmation scenarios: (1) The workflow replanning is coarse-grained and cannot detect changes at the field level; CN122288346A performs failure detection and replanning at the API node level, while CN121436506A performs it at the subtask level. When a local field of a composite input object changes, both can only rerun the entire variable or the entire task as the unit of rerun. For example, in an order processing task, the order variable contains two fields: "shipping address" and "payment amount." If only the "shipping address" is modified, both CN122288346A and CN121436506A will still trigger a rerun of the entire order-related task because they cannot distinguish which fields within the variable have changed and which remain unchanged.

[0004] (2) Passive reaction, unable to proactively predict the scope of impact; CN122288346A relies on API node execution failure events to trigger replanning, and CN121436506A relies on subtask execution errors to trigger repair. Both are "passive reactions" that only take remedial action after node execution fails. They cannot "proactively predict" the scope of impact at the moment data changes occur. For example, an upstream task outputs a JSON variable with 100 fields, of which only one field is abnormally modified. In CN122288346A and CN121436506A, the system can only detect the problem when a downstream node actually uses the field and fails to execute for some reason, resulting in a lag in fault detection.

[0005] (3) Failure to link final delivery confirmation with input data poses a security risk; CN122288346A employs a Saga-style compensation transaction mechanism to handle cross-system consistency, focusing on post-execution compensation; CN121436506A relies on an error diagnosis module and an error cause library for anomaly repair, focusing on error correction; neither binds the final delivery confirmation to the input data. However, in practical applications, there is a time lag between user confirmation and system execution. During this period, the background may update data, undergo concurrent modifications, or be maliciously tampered with. If the underlying data state changes after the user's confirmation, in existing technical solutions, user confirmation based on expired data may still be incorrectly executed, posing a serious security vulnerability. Summary of the Invention

[0006] To address the shortcomings of existing technologies, the technical problem this invention aims to solve is to provide a field-level workflow local replanning and safety verification method and system. This method and system can detect field-level changes and determine the minimum unfinished impact subgraph of data changes before node execution. Simultaneously, it establishes a binding and comparison mechanism between verification records and delivery package hashes to reduce the risk of incorrectly executing the final delivery operation due to changes in the information on which verification is based.

[0007] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: This invention provides a field-level workflow partial replanning and security verification system, including a versioned variable storage module, a field fingerprint generation module, a field difference comparison module, an impact subgraph analysis module, a node state machine, a verification record generation module, and an audit event storage module; The versioned variable storage module is used to provide orderly management and fast retrieval capabilities for each task variable; it is responsible for storing metadata information such as the name, version number, overall content hash, field fingerprint table, production node identifier, and storage location of the task variable; by maintaining this key information, the system can ensure the uniqueness and consistency of task variables in a multi-node collaborative environment, while supporting the tracing and auditing of historical versions.

[0008] Preferably, the versioned variable storage module compares a new version of the task variable with the existing version when the new version is received, and updates or retains the old version information according to preset rules. The output result of a successful node corresponds to the version of the input variable and the content hash when the output result was produced; subsequent nodes read the output result according to the version of the input variable corresponding to the output result reference.

[0009] The field fingerprint generation module generates normalized field paths for structured data formats by recursively traversing object fields and array elements. The module first defines the root path as root, and then constructs a path representation based on the hierarchical relationship between object fields and array elements. For example, for a JSON document containing nested objects, the module will parse it into a path in the form of root.content, while for array elements, it will use the representation method of root.items[0]. Subsequently, the module uses deterministic hash algorithms such as SHA-256 to calculate each normalized field path and its corresponding normalized field value to generate a field fingerprint. For unstructured payloads or payloads that fail to be parsed, the field fingerprint generation module only records the hash value of the overall content of the variable corresponding to the root path root; the main purpose of this design is to reduce processing complexity and computational overhead while ensuring system compatibility. Since unstructured data (such as text files or binary data) usually lacks a clear field structure, it is impossible to generate a detailed field fingerprint table by recursively traversing. In this case, the module processes the overall content of the variable as a single unit and calculates its hash value as the fingerprint of the root path. For arrays, the normalized field path of an array element consists of the array path and the element's position within the array. The array path itself is also a normalized field path, and its corresponding normalized field value is the overall normalized value of the array. The field fingerprint of the array path is calculated based on this overall value. When the order of array members is adjusted, the field fingerprint of the array path changes accordingly. A hit is determined by using the array path or its ancestor paths as dependencies in the field path configuration. When a node explicitly configures element-level field paths, a hit is determined by the difference in the field fingerprint of that element path. When the order of array members is adjusted, the corresponding element path may be identified as an addition or deletion.

[0010] The field difference comparison module is used to compare the field fingerprint tables of old and new task variables to identify the addition, deletion, or changes in field fingerprints. This module employs a combination of set comparison and hash value comparison, with the following steps: First, the module obtains the field fingerprint tables of the old and new variables and extracts the path sets from each. Second, it performs a union operation on the two sets to determine all paths that need to be compared. Finally, for each path, the module compares its hash value in the old and new versions. If the hash values ​​differ or the path does not exist in a certain version, it is marked as a changed field. In this way, the module can accurately capture subtle changes in variable fields and output a set containing added, deleted, and modified fields. When either the old or new variable lacks a field fingerprint table, the module automatically treats it as unstructured data and uses the hash value of the entire content of the variable corresponding to the root path (root) as the comparison benchmark, thus ensuring compatibility.

[0011] This design ensures that the system maintains consistency and correctly executes subsequent tasks even when dealing with heterogeneous data sources. Furthermore, when handling mixed structured and unstructured data, the module prioritizes parsing the structured portions and only applies unstructured processing methods to unparseable content. This flexible compatibility strategy not only enhances the system's fault tolerance but also provides strong support for data management in complex task scenarios.

[0012] The influence subgraph analysis module is used to identify unfinished nodes that directly depend on the changed fields by parsing the field dependency selector; and further propagate downstream along the task dependency edges to generate the minimum unfinished influence subgraph. Field dependency selectors are configuration information used by task nodes to declare their dependencies on variable fields. They contain one or more dependencies, each consisting of a variable name, an optional field path, and an optional expected fingerprint. When a node has multiple dependencies configured, a match in any dependency indicates that the node is directly affected by the variable change. When a dependency has a field path configured, a match is determined if the changed field path is the same as the current field path or is a descendant of the current field path; a miss is determined if the field path does not exist in either the old or new variable's field fingerprint table. When a dependency has no field path configured, a match is determined if any field of the variable changes. Expected fingerprints are optional configuration items and do not participate in field difference comparisons or match determination. Match determination is based on the set of changed fields output by the field difference comparison module. The module checks the dependencies of incomplete nodes one by one to see if they match the changed fields. For example, if a node's dependency selector specifies a particular field path, and that path's hash value has changed in the latest variable version, the module will mark this node as directly affected. In this way, the module can quickly locate nodes that need to be re-executed due to changes in the dependent variable, laying the foundation for the subsequent generation of the influence subgraph. After completing the dependency analysis, the module starts from the directly affected nodes and iteratively traverses their downstream nodes according to the directed acyclic graph (DAG) structure in the task graph. For each downstream node, the module checks whether it is in an incomplete state (such as pending execution, ready, or blocked) and adds it to the influence set until the set no longer expands. This process ensures that the module can fully cover all nodes that need to be re-planned due to changes in the dependent variable, while avoiding unnecessary re-execution of tasks. The final generated influence subgraph not only reflects the specific scope of the impact of variable changes on task execution, but also provides clear failure handling targets for the node state machine, thereby optimizing the system's resource utilization and execution efficiency.

[0013] The node state machine is used to maintain the state transition logic of task nodes and handle failures, ensuring the orderly execution of each node in a complex task graph. The task node states include five categories: pending execution, ready, blocked, successful, and failed. Transitions between each state are subject to strict rules. For example, when all the input variables required by a task node are ready, its state changes from "pending execution" to "ready." During execution, if a node cannot continue running due to insufficient resources or other abnormal reasons, it will enter a "blocked" state. Furthermore, the node state machine supports dynamic adjustment, especially when changes in variables cause some nodes to fail, enabling a rapid response and triggering of corresponding state transitions. Through this refined state management mechanism, the system can achieve efficient task scheduling and resource allocation in a multi-node collaborative environment. The state transition rules for task nodes are as follows: When all the prerequisite nodes required by a node have succeeded and its required input variables are ready, the node transitions from pending execution to ready; if not all prerequisite nodes have succeeded or the input variables are ready, the node remains pending execution; if a node cannot continue execution due to unready input variables or insufficient resources, it transitions from ready to blocked; after the blocking reason is eliminated, it transitions from blocked to pending execution, and then from pending execution to ready; after the node completes execution, it transitions from ready to successful; when the influence subgraph analysis module determines that a node is affected by variable changes, the node transitions from pending execution, ready, or blocked to invalidated. Invalidated nodes are not re-invalidated; only their associated confirmation records are revoked; after completing local replanning, invalidated nodes transition from invalidated to pending execution. Version updates, field difference comparisons, influence subgraph calculations, and state updates for the same task variable are executed sequentially according to the order in which the variable versions are received. The influence subgraph calculation for the later variable version is based on the node state after the previous variable version has been processed.

[0014] Preferably, when the influence subgraph analysis module identifies a node that needs to be re-executed due to a change in the dependent variable, the node state machine marks the pending, ready, or blocked nodes in the influence subgraph as invalid and cancels the associated confirmation records; for invalid nodes, only the associated confirmation records are canceled, and their invalid status remains unchanged; successful nodes whose field dependency selectors do not hit the changed fields retain their output result references unchanged.

[0015] This selective failure handling strategy not only avoids unnecessary resource waste but also improves system response speed. For example, when a task node fails due to a change in an upstream variable, the state machine can revoke the acknowledgment record associated with that node and notify downstream nodes to replan their execution paths. Meanwhile, unaffected branch nodes retain their current state, ensuring that other parts of the task graph continue to operate normally. Through this flexible failure handling mechanism, the system can maintain stable operation in dynamically changing environments. After an acknowledgment record is revoked, the system notifies the corresponding delivery node to reconfirm: the acknowledgment record generation module recalculates the delivery package hash based on the revised variable version and generates the acknowledgment record, which is then confirmed again by the user before final delivery. For successful nodes where the field dependency selector hits a changed field, the version of the input variable bound to the output result reference has been replaced, the output result reference becomes invalid, and execution is re-executed with local replanning; for successful nodes where the field dependency selector does not hit a changed field, the output result reference remains unchanged.

[0016] The confirmation record generation module is used to calculate a delivery package hash by combining the delivery identifier, target address, input variable version, field dependency information digest, and evidence digest to generate a confirmation record. The evidence digest is a digest value calculated from the various evidence artifacts on which this delivery is based. The evidence artifacts include the outputs and their process documents referenced in this delivery. Each evidence artifact has an artifact identifier, name, content hash, content type, and output node identifier. The evidence digest arranges the evidence artifacts in lexicographical order of their artifact identifiers, concatenates the artifact identifier, content hash, and content type of each evidence artifact in sequence, and then calculates the SHA-256 hash value of the concatenation result. The evidence digest only involves the identifier and content of the evidence artifact itself and does not include the field fingerprint table of task variables or the overall content hash. The field fingerprint, overall content hash, and evidence digest are all used as inputs to the delivery package hash. When the evidence artifact changes, the evidence digest and delivery package hash values ​​change accordingly, and the saved confirmation record becomes invalid during the comparison before execution. The module first extracts the delivery identifier, target address, input variable version, and field dependency information digest of this delivery from the system. Subsequently, the module uses deterministic hash algorithms such as SHA-256 to combine this information and the evidence digest to generate a delivery packet hash value. This delivery packet hash value provides verifiable evidence for user confirmation. To ensure the accuracy of the final delivery, the confirmation record generation module saves the delivery packet hash value along with the validity period as a confirmation record during the user confirmation phase.

[0017] Preferably, before performing the final delivery operation, the confirmation record generation module recalculates the current delivery package hash value based on the delivery identifier, target address, input variable version, field dependency information digest, and evidence digest, and compares it with the delivery package hash value stored in the confirmation record. If the two are inconsistent or the validity period of the confirmation record has expired, the confirmation record becomes invalid. After the confirmation record becomes invalid, the confirmation record generation module regenerates the delivery package hash and the confirmation record. The regenerated confirmation record can only be used to perform the final delivery operation after being reconfirmed by the user.

[0018] This dual-verification mechanism not only enhances system security but also effectively reduces the risk of delivery failure due to accidental or malicious operations. Furthermore, by introducing the concept of an expiration date, the module can address asynchronous issues caused by network latency or node failures, thereby further improving system robustness and user experience.

[0019] The audit event storage module records key information such as the variable summary before and after the change, changed fields, affected node set, confirmed failure cause, and replanning result. Specifically, the module automatically triggers the audit event recording process every time a task variable is updated or a node status changes. For example, during a variable update, the module records the variable summary before and after the change, and records the set of changed fields output by the field difference comparison module. For the generation of subgraphs and node failure handling caused by variable changes, the module records the specific information of the affected nodes and the replanned execution path. In addition, the module supports tracking confirmed failure events, including the failure cause, number of retries, and final processing result. Through this comprehensive event recording mechanism, the system can build a complete operation log, providing data support for subsequent troubleshooting and performance optimization.

[0020] This invention also provides a field-level workflow partial replanning and safety verification method, implemented based on the above-mentioned field-level workflow partial replanning and safety verification system, including the following steps: Step 1: Receiving and processing task variables; Preferably, step 1 includes: Step 1.1, receiving the new version; The system receives new versions of task variables through a standardized data receiving interface. This interface supports various data formats, including but not limited to JSON, text files, and binary data. During the receiving process, the system first validates the format of the incoming data to ensure it conforms to predefined specifications. For structured data (such as JSON), the system checks its syntactic correctness, key-value pair integrity, and the validity of nested structures. For unstructured data, it verifies its content integrity and the validity of its encoding format. The system also records the identity information and timestamp of the data source node for subsequent traceability and auditing. This process ensures the initial quality of the data after it enters the system and provides a reliable foundation for subsequent processing.

[0021] Step 1.2, hash calculation; After completing the data reception and format verification in step 1.1, the system initiates a hash calculation process to generate the overall content hash of the task variables. Deterministic hash algorithms such as SHA-256 are used to perform hash operations on both structured and unstructured payloads. Once the calculation is complete, the hash value is recorded and stored in the versioned variable storage module as the core fingerprint information of the variable. This step not only provides the foundation for subsequent field fingerprint generation but also enables rapid verification of data consistency through hash value comparison.

[0022] Step 2, Field fingerprint generation and storage; Preferably, step 2 includes: Step 2.1, generating structured load fingerprints; For structured payloads (such as JSON), the system first parses the payload into a tree structure and recursively traverses the object fields and array elements within it. For each field, the system generates a normalized path based on its position in the tree. For example, the root path is denoted as root, the object field as root.content, and the array element as root.items[0]. Subsequently, the system calculates a hash value for each normalized field path and its corresponding normalized field value to form a field fingerprint table. The final generated field fingerprint table, along with the variable name, version number, and other metadata, is stored in the versioned variable storage module to provide support for subsequent field difference comparison and impact analysis. The normalized field path of an array element consists of the array path and the position of the element in the array. The array path itself is also a normalized field path, and the field fingerprint is calculated based on the overall normalized value of the array. When the order of array members is adjusted, the field fingerprint of the array path changes accordingly. The hit is determined by the dependency configured in the array path or its ancestor path. When a node explicitly configures an element-level field path, the hit is determined by the difference in the field fingerprint of the element path.

[0023] Step 2.2, unstructured load fingerprint processing; For unstructured payloads or structured payloads that fail to parse, the system employs a simplified fingerprinting approach. Since such payloads cannot be decomposed into fine-grained field paths, the system only records the overall hash value of the variable corresponding to its root path. While this approach sacrifices fine-grained field-level management capabilities, it ensures the system's compatibility and robustness, enabling it to handle diverse data formats. After processing, the root path hash value, as the variable's unique fingerprint, is stored in the versioned variable storage module. Together with other metadata, it constitutes the complete record of the variable. This design satisfies the management needs of unstructured data while maintaining consistency with the management logic of structured data.

[0024] Step 3, Field Difference Comparison and Impact Analysis; Preferably, step 3 includes: Step 3.1, compare field differences; The field difference comparison module compares the field fingerprint tables of the old and new variables. First, it loads the field fingerprint tables of both variables and calculates their union as the comparison benchmark. For each path in the union, the module compares the hash values ​​of the old and new variables one by one: if a path does not exist in the old variable or its hash value differs from the new variable, the path is marked as "added" or "modified"; if a path exists only in the old variable, it is marked as "deleted"; if either the old or new variable lacks a field fingerprint table (i.e., unstructured load), the module marks the root path as a changed path to ensure compatibility. Finally, the field difference comparison module outputs a set containing all changed field paths, providing input for subsequent impact analysis.

[0025] Step 3.2, influence subgraph analysis; The influence subgraph analysis module reads the field dependency selector of each incomplete node and determines whether it directly depends on the changed field. If the selector contains one or more dependencies, the node is considered affected by the change if any dependency is matched. If no specific field path is configured for the dependency, a change in any field of the variable is considered a match. If a field path is configured for the dependency, a match is considered if the changed path is the same as or a descendant of the field path; a miss is considered if the field path does not exist in either the old or new variable. Expected fingerprints are not involved in the match determination. Next, the influence subgraph analysis module propagates downstream along the task dependency edges, iteratively adding incomplete downstream nodes of directly matched nodes to the influence set until the set stabilizes. If the field dependency selector does not match a successful node with a changed field, its output reference remains unchanged. If the field dependency selector matches a successful node with a changed field, the version of the input variable bound to its output reference has been replaced, the output reference becomes invalid, and the node is re-executed with local replanning. The final generated minimum unfinished impact subgraph accurately depicts the scope of the impact of variable changes on task execution, providing a basis for subsequent node state updates and replanning.

[0026] Step 4, Node status update and delivery processing; Preferably, step 4 includes: Step 4.1, Node status update; The node state machine performs node state update operations based on the influence subgraph analysis results. For nodes in the influence subgraph that are pending, ready, or blocked, the state machine uniformly marks them as "failed." For failed nodes, the state machine only cancels their associated acknowledgment records, leaving their failed state unchanged; this reflects the impact of variable changes on the execution plan. Simultaneously, the state machine cancels the acknowledgment records associated with these nodes to avoid executing final delivery operations based on failed acknowledgments. For unaffected nodes, the state machine maintains their current state; specifically, successful nodes whose field dependency selectors did not hit the changed fields retain their output references unchanged, ensuring the system can quickly resume execution after variable changes. This mechanism, through fine-grained state management, reduces the impact of variable changes on system operation while ensuring the correctness and consistency of task execution.

[0027] Step 4.2, Final Delivery Confirmation; The confirmation record generation module confirms the final delivery to ensure the accuracy and reliability of the delivery results. During the user confirmation phase, the module calculates a delivery package hash using the delivery identifier, target address, input variable version, field dependency information digest, and evidence digest. This hash value, along with the expiration date, is saved as a confirmation record. Before executing the final delivery, the confirmation record generation module recalculates the current delivery package hash value based on the same information and compares it with the hash value saved in the confirmation record. If they match and the expiration date has not been exceeded, the confirmation record is valid. Otherwise, the confirmation record becomes invalid, and the system regenerates the delivery package hash and confirmation record. The regenerated confirmation record can only be used to execute the final delivery operation after being reconfirmed by the user. This mechanism, through hash comparison and timeliness control, reduces the risk of errors caused by data inconsistency or exceeding the expiration date during the delivery process.

[0028] Step 5: Audit event logging and follow-up planning.

[0029] Preferably, step 5 includes: Step 5.1, Audit event logging; The audit event storage module is responsible for recording audit events related to variable changes. The recorded content includes key information such as a summary of the variable before the change, a summary of the variable after the change, the set of changed fields, the set of affected nodes, confirmed reasons for failure, and replanning results. These events are organized into structured records and stored in a dedicated audit database for subsequent querying and analysis. By meticulously recording key state changes and operation logs during system operation, the audit module provides crucial evidence for troubleshooting, performance optimization, and compliance checks, significantly improving the system's maintainability and reliability.

[0030] Step 5.2, subsequent planning adjustments; After completing the audit event logging, the system performs subsequent task planning and execution adjustments for incomplete nodes in the impact subgraph. Based on the variable change range and impact analysis results recorded in the audit events, the system reassesses the execution priority and dependencies of each node in the affected subgraph. For nodes that fail due to variable changes, the system replans their execution paths and updates the status of related dependent edges. Simultaneously, the system dynamically adjusts the task execution plan based on current resource conditions and task objectives. Successful nodes whose field dependency selectors hit the changed fields are re-executed with the local replanning; successful nodes whose field dependency selectors do not hit the changed fields retain their output references unchanged. This ensures that the overall task can be completed efficiently and orderly.

[0031] Compared with the prior art, the present invention has the following beneficial effects: (1) This invention reduces the granularity of workflow variable change detection to the "field level" through field fingerprint generation in step 2, field difference comparison in step 3, and field dependency selector matching. By generating fingerprints for each valid field path and its corresponding field value in structured data, the system can identify field changes in the data payload and trigger replanning only for nodes that depend on that field. This refines the replanning granularity from the variable as a whole or the task as a whole to the field path level, reducing the repeated execution of irrelevant nodes caused by local modifications of composite objects and helping to save computing resources.

[0032] (2) Through proactive difference perception in step 3, dependency matching and influence subgraph analysis, and precise failure marking of the state machine in step 4, this invention proactively triggers influence analysis by fingerprint comparison when data flows into the entry or intermediate node of the workflow. Even if the downstream node has not yet started execution, the system can complete replanning in advance, realizing the proactive mode of "data change → proactive prediction of influence scope → advance replanning". This moves the timing of fault detection and recovery forward, improving the real-time performance and robustness of the workflow system.

[0033] (3) This invention generates confirmation records in step 4, performs a second comparison before execution, and automatically invalidates them. It calculates the delivery identifier, target address, input variable version, field dependency information digest, and evidence digest at the time of user confirmation as a delivery package hash, and performs a second verification before execution to ensure that the confirmation record corresponds to a specific delivery package hash. This can reduce the risk of incorrect execution of the final delivery operation due to concurrent updates or asynchronous changes in background data. Attached Figure Description

[0034] Figure 1 This is an overall architecture diagram of a field-level workflow local replanning and safety verification system according to the present invention.

[0035] Figure 2 This is a flowchart of a field-level workflow local replanning and safety verification method according to the present invention. Detailed Implementation

[0036] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings.

[0037] This invention provides a field-level workflow partial replanning and safety verification system, such as... Figure 1 As shown, it includes a versioned variable storage module, a field fingerprint generation module, a field difference comparison module, an impact subgraph analysis module, a node state machine, a confirmation record generation module, and an audit event storage module; The versioned variable storage module saves the name, version number, overall content hash, field fingerprint table, production node identifier, and storage location for each variable. A new variable with the same name replaces the current version, but a summary of the variable before the change can be used for audit comparison. The output results of successful nodes correspond to the input variable version and content hash at the time the output result was generated; subsequent nodes read the output result according to the corresponding input variable version referenced by the output result.

[0038] The field fingerprint generation module maps object fields and array elements in the structured payload to normalized paths. For example, the root path is denoted as root, the object field is denoted as root.content, and the array element is denoted as root.items[0]. The hash value is calculated for each path and its corresponding normalized field value. The normalized field path of the array element is composed of the array path and the position of the element in the array. The array path itself is also a normalized field path, and the field fingerprint is calculated according to the overall normalized value of the array. When the order of array members is adjusted, the field fingerprint of the array path changes accordingly. The hit is determined by the dependency configured in the array path or its ancestor path. When the node explicitly configures the element-level field path, the hit is determined by the difference in the field fingerprint of the element path.

[0039] The field difference comparison module compares the field fingerprint tables of the old and new variables, and outputs the field paths where the fingerprints differ due to additions, deletions, or other reasons. If neither the old nor the new variable has a field fingerprint table, it outputs the hash value of the entire variable content corresponding to the root path (root) to ensure compatibility with unstructured data.

[0040] The influence subgraph analysis module identifies incomplete nodes that directly depend on changed fields based on the field dependency selector and propagates this downstream along the task dependency edges to obtain the smallest incomplete influence subgraph. If the field dependency selector does not hit a successful node of a changed field, its output reference remains unchanged; if the field dependency selector hits a successful node of a changed field, the version of the input variable bound to its output reference has been replaced, the output reference becomes invalid, and it is re-executed with local replanning.

[0041] The node state machine only marks the pending, ready, or blocked nodes in the affected subgraph as invalid and revokes the associated acknowledgment records; for invalid nodes, only their associated acknowledgment records are revoked, and their invalid state remains unchanged; successful nodes whose field dependency selectors do not hit the changed fields retain their output references unchanged; unaffected branches retain their original state.

[0042] The confirmation record generation module calculates the delivery package hash by combining the delivery identifier, target address, input variable version, field dependency information digest, and evidence digest. Evidence artifacts are the outputs and process credentials referenced in this delivery; each evidence artifact has an artifact identifier, content hash, and content type. The evidence digest is calculated by concatenating the artifact identifier, content hash, and content type of each evidence artifact in lexicographical order, excluding the field fingerprint table of task variables and the overall content hash. Upon user confirmation, this delivery package hash value and its validity period are saved as a confirmation record. Before executing the final delivery, the current delivery package hash value is recalculated based on the same information and compared with the delivery package hash value saved in the confirmation record. If the two are inconsistent or the validity period of the confirmation record has expired, the confirmation record becomes invalid. The regenerated confirmation record can only be used to execute the final delivery operation after being reconfirmed by the user.

[0043] The audit event storage module records the variable summary before the change, the variable summary after the change, the changed fields, the set of affected nodes, the confirmed cause of failure, and the replanning results.

[0044] This invention also provides a field-level workflow partial replanning and safety verification method, implemented based on the aforementioned field-level workflow partial replanning and safety verification system, such as... Figure 2 As shown, it includes the following steps: S1 receives the new version of the task variable and calculates the hash of the entire variable content.

[0045] S2-S4 recursively traverse object fields and array elements for structured payloads such as JSON, generating field fingerprints based on normalized field paths and corresponding field values. For payloads that cannot be parsed in a structured manner, only the hash value of the overall content of the variable corresponding to the root is recorded. The normalized field path of an array element consists of the array path and the position of the element in the array. The array path itself is also a normalized field path, and the field fingerprint is calculated based on the normalized overall value of the array. When the order of array members is adjusted, the field fingerprint of the array path changes accordingly, and the hit is determined by the dependencies configured in the array path or its ancestor paths. When a node explicitly configures an element-level field path, the hit is determined by the difference in the field fingerprint of the element path.

[0046] S5 compares the field fingerprints of the old and new field fingerprint tables in a union; paths where one side does not exist or the field fingerprints are different are written to the changed field set.

[0047] S6, read the field dependency selector for each incomplete node. When the selector does not have a field path configured, the overall change of the variable is considered a hit; if the selector contains one or more dependencies, the node is considered a hit if any one of them is a hit; if the selector has a field path configured, a hit is only achieved if the changed path is the same as the field path or is a descendant of the field path, and a miss is determined if the field path does not exist in either the old or new variable; expected fingerprints are not involved in the hit determination.

[0048] S7. Based on the dependency edges of the directed acyclic graph of the task, iteratively add the unfinished downstream nodes of the directly hit node to the affected set until the set is stable.

[0049] S8, the state machine only sets the failure state for nodes that are pending, ready, or blocked in the affected set and cancels the associated confirmation records; for nodes that have failed, only cancels the associated confirmation records; successful nodes whose field dependency selectors do not hit the changed fields retain their output references unchanged; nodes that are not in the affected set retain their pending or ready state.

[0050] S9-S11 If there is a final delivery to be confirmed, calculate the hash value of the current delivery package based on the delivery identifier, target address, input variable version, field dependency information digest, and evidence digest, and compare it with the delivery package hash value saved in the confirmation record. If the two are inconsistent or the validity period of the confirmation record is exceeded, the confirmation record becomes invalid. The newly generated confirmation record can only be used to perform the final delivery operation after being reconfirmed by the user.

[0051] S12-S13, record audit events; adjust subsequent plans and execution for incomplete nodes in the impact subgraph; successfully executed nodes whose field dependency selectors hit changed fields are re-executed with subsequent plans and execution adjustments; successfully executed nodes whose field dependency selectors do not hit changed fields retain their output references unchanged.

[0052] The specific algorithm is as follows: Table 1 - Meaning of Algorithm Symbols v_i The i-th task variable i=1,…,N p Normalized field path The root path is root; P_i is the set of paths of variable v_i. h_(i,p) Field fingerprint of variable v_i at path p It is calculated by combining the normalized field path and the corresponding normalized field value; old and new represent the old and new versions, respectively. Δ_i The set of fields that change in variable v_i Δ_i ⊆ P_i n_j The j-th task node j=1,…,M D_j Field dependency selector for node n_j Each item contains a variable name and optional field paths; when a node is configured with multiple dependencies, if any one of them is matched, the node is considered directly affected. A_i The set of nodes whose incomplete impact is caused by changes in variable v_i. A_i ⊆ {n_j} q Delivery package hash Calculated from delivery identifier, target address, input variable version, field dependency information digest, and evidence digest. P_i The set of field paths for variable v_i Normalized field paths including root and structured payload c Change field path c ∈ Δ_i U Incomplete node set Includes nodes that are pending, ready, blocked, or expired. A_i^(0) Set of directly affected nodes A_i^(0) ⊆ U e Summary of Evidence The calculation is performed by concatenating the artifact identifier, content hash, and content type of the evidence artifact in lexicographical order based on the artifact identifier. The set of changing fields is determined by the following formula: When any version is not a structured payload, the field path set of the variable contains only the root path, and the hash of the entire content of the variable is used as the field fingerprint of the root path.

[0053] The set of nodes directly affected is: Then, by calculating the incomplete downstream propagation closure of the task-dependent edges on the directly affected node set A_i^(0), the incomplete affected node set A_i is obtained. The delivery packet hash is calculated from the delivery identifier, target address, input variable version, field dependency information digest, and evidence digest: Where H is a deterministic hash function. Final delivery is allowed when the currently calculated delivery package hash value matches the delivery package hash value stored in the confirmation record, has not exceeded the validity period, and the user has completed reconfirmation.

[0054] Table 2 - Key Technical Parameters Field path format p JSON Pointer or equivalent normalization path A unique locator field within the same variable version; an array element path consists of its array path and the element's position in the array. Field fingerprint h_(i,p) Fixed-length hash string Calculated by normalized field paths and corresponding field values Affected Node Set A_i Includes only incomplete nodes Obtained through the transitive closure of the task dependency edge. Confirmation Record q Fixed-length hash string Save the hash value and validity period of the delivery package. Confirm validity period none Configurable positive time interval Reconfirmation is required upon expiration. Summary of Evidence e Fixed-length hash string The hash is calculated by concatenating the artifact identifier, content hash, and content type of the evidence artifact in lexicographical order of the artifact identifier, excluding the field fingerprint table and the overall content hash. Field Dependency Selector D_j Each item contains a variable name and the path to optional fields. When a node is configured with multiple dependencies, the node is considered directly affected if any one of them is matched; fingerprints are not expected to be included in the match determination. Node state transition none Pending execution / Ready / Blocked / Successful / Invalid Once the cause of the blockage is eliminated, the node is converted from blocked to pending execution; failed nodes are converted to pending execution after local replanning. Confirmation record reconstruction none User confirmation is required after the code expires. After the confirmation record expires, a new delivery package hash and confirmation record are generated, which are then used to execute the final delivery after being reconfirmed by the user. Key technical features of this invention: A mechanism for generating field fingerprints for structured task variables based on normalized field paths and corresponding field values, and for handling unstructured variables using root path-based overall content hashing.

[0055] Nodes construct field dependency selectors using variable names and field paths, and determine the directly affected nodes based on the similarity or ancestor relationship between the changed field and the selector path.

[0056] A mechanism that computes the propagating influence subgraph only along task-dependent edges within the scope of incomplete nodes, maintains the state of unaffected nodes, and references the output results of successful nodes.

[0057] A mechanism that binds the delivery identifier, delivery target, input variable version, field dependency information digest, evidence digest, and validity period to an acknowledgment record, and invalidates the acknowledgment record when the hash value of the current delivery package changes.

[0058] During local replanning, only incomplete nodes in the affected subgraph are replaced, and a mechanism is established to record changed fields, a summary of variables before the change, a summary of variables after the change, a set of affected nodes, and a mechanism to confirm failure events.

[0059] Alternative solutions to this invention include: Use a different field path representation method, such as XPath instead of JSON Pointer. Different deterministic hash functions can be used; in security-sensitive implementations, hash algorithms that meet predetermined security strength requirements can be employed.

[0060] Use different data structures to store field fingerprint tables, such as B-trees, hash tables, or other efficient query structures. The confirmation record includes additional metadata such as timestamps and user IDs. Use different task dependency graph representations, such as directed graphs, acyclic graphs, or other topologies. The effects of implementing this invention include: By reducing the replanning granularity from the overall variable or task to the field path, incomplete branches that only depend on unchanged fields remain executable, reducing irrelevant retries.

[0061] Unstructured data is automatically degraded into a global hash of variables, taking into account both existing task definitions and new field-level task definitions.

[0062] By using the same field snapshot as the impact analysis and validation, inconsistencies in status, such as "correct replanning has been achieved but old validations are still being reused incorrectly," can be avoided.

[0063] Retaining changed fields, impact subgraphs, and confirmation of undo reasons facilitates task recovery, error review, and verification of final side effects.

Claims

1. A field-level workflow partial replanning and safety verification system, characterized in that, It includes a versioned variable storage module, a field fingerprint generation module, a field difference comparison module, an impact subgraph analysis module, a node state machine, an acknowledgment record generation module, and an audit event storage module; The versioned variable storage module is used to store the version information, overall content hash, and field fingerprint table of task variables; The field fingerprint generation module is used to calculate the field fingerprint by combining the normalized field paths and corresponding field values ​​of structured payloads; and to record the hash value of the overall content of the variables corresponding to the root path for unstructured payloads or payloads that fail to be parsed. The field difference comparison module is used to compare the field fingerprint tables of the old and new task variables to identify the addition, deletion or change of field fingerprints; when either the old or new task variable lacks a field fingerprint table, the hash value of the overall content of the variable corresponding to the root path is used as the comparison benchmark. The influence subgraph analysis module is used to parse the field dependency selector, find the incomplete nodes that directly depend on the changed fields, and propagate them downstream along the task dependency edges to generate the smallest incomplete influence subgraph. The node state machine is used to maintain the state transitions and failure handling of task nodes; The status of the task node includes pending execution, ready, blocked, successful, and failed; the failure handling object is the pending execution, ready, or blocked node in the subgraph; the successful node whose field dependency selector does not hit the changed field retains its output result reference unchanged; The confirmation record generation module is used to calculate the delivery identifier, target address, input variable version, field dependency information digest and evidence digest into a delivery package hash, and save the delivery package hash value and validity period as a confirmation record; The audit event storage module is used to record the variable summary before the change, the variable summary after the change, the changed fields, the set of affected nodes, the confirmed cause of failure, and the replanning result.

2. The field-level workflow local replanning and safety verification system according to claim 1, characterized in that, The versioned variable storage module compares the new version of the task variable with the existing version when the new version is received, and updates or retains the old version information according to preset rules. The output result reference of the successful node corresponds to the input variable version and content hash when the output result is produced, and subsequent nodes read the output result according to the input variable version corresponding to the output result reference.

3. The field-level workflow local replanning and safety verification system according to claim 1, characterized in that, When the influence subgraph analysis module identifies a node that needs to be re-executed due to a change in the dependent variable, the node state machine marks the pending, ready, or blocked nodes in the influence subgraph as invalid and cancels the associated confirmation records. For invalid nodes, only the associated confirmation records are canceled, and their invalid status remains unchanged. Successful nodes whose field dependency selectors do not hit the changed fields retain their output result references unchanged.

4. The field-level workflow local replanning and safety verification system according to claim 1, characterized in that, Before performing the final delivery operation, the confirmation record generation module recalculates the current delivery package hash value based on the delivery identifier, target address, input variable version, field dependency information digest, and evidence digest, and compares it with the delivery package hash value stored in the confirmation record. If the two are inconsistent or the validity period of the confirmation record is exceeded, the confirmation record becomes invalid. After the confirmation record becomes invalid, the confirmation record generation module regenerates the delivery package hash and the confirmation record. The regenerated confirmation record is used to perform the final delivery operation after being reconfirmed by the user.

5. A method for partial replanning and safety verification of field-level workflows, implemented based on the field-level workflow partial replanning and safety verification system according to any one of claims 1-4, characterized in that, Includes the following steps: Step 1: Receiving and processing task variables; Step 2, Field fingerprint generation and storage; Step 3, Field Difference Comparison and Impact Analysis; Step 4, Node status update and delivery processing; Step 5: Audit event logging and follow-up planning.

6. The field-level workflow local replanning and safety verification method according to claim 5, characterized in that, Step 1 includes: Step 1.1, receiving the new version; The system receives new versions of task variables through a standardized data receiving interface, which supports data formats including JSON, text files, and binary data. During the receiving process, the system first performs format validation on the incoming data to ensure that it conforms to predefined specifications. For structured data, the system checks its syntactic correctness, key-value pair integrity, and the legality of nested structures. For unstructured data, it verifies its content integrity and the validity of its encoding format. The system also records the identity information and timestamp of the data source node. Step 1.2, hash calculation; After completing the data reception and format verification in step 1.1, the system starts the hash calculation process to generate the overall content hash of the task variables; the SHA-256 deterministic hash algorithm is used to perform hash operations on the structured and unstructured payloads; after the calculation is completed, the hash value is recorded and stored in the versioned variable storage module.

7. The field-level workflow local replanning and safety verification method according to claim 6, characterized in that, Step 2 includes: Step 2.1, generating structured load fingerprints; For structured loads, the system first parses the load into a tree structure and recursively traverses the object fields and array elements within it. For each field, the system generates a normalized path based on its position in the tree. Subsequently, the system calculates a hash value for each normalized field path and its corresponding normalized field value to form a field fingerprint table. The generated field fingerprint table, along with the variable name and version number, is stored in the versioned variable storage module. Step 2.2, Unstructured load fingerprint processing; For unstructured payloads or structured payloads that fail to be parsed, the system only records the hash value of the overall content of the variable corresponding to its root path. After processing, the root path hash value is stored as the unique fingerprint of the variable in the versioned variable storage module.

8. The method for partial replanning and safety verification of field-level workflows according to claim 7, characterized in that, Step 3 includes: Step 3.1, compare field differences; The field difference comparison module compares and analyzes the field fingerprint tables of the old and new variables. First, it loads the field fingerprint tables of both variables and calculates their union as the comparison benchmark. For each path in the union, the module compares the hash values ​​of the old and new variables one by one: if a path does not exist in the old variable or its hash value is different from the new variable, the path is marked as "added" or "modified"; if a path exists only in the old variable, it is marked as "deleted"; if either the old or new task variable lacks a field fingerprint table, the root path is marked as a changed path. The field difference comparison module outputs a set containing all changed field paths. Step 3.2, influence subgraph analysis; The influence subgraph analysis module reads the field dependency selector of each incomplete node and determines whether it directly depends on the changed field. The field dependency selector contains one or more dependencies, each containing a variable name and an optional field path. If any dependency is matched, the node is determined to be directly affected by the change. If no field path is configured for the dependency, a change in any field of the variable is considered a match. If a field path is configured for the dependency, a match is considered if the changed path is the same as or a descendant of the field path. If the field path does not exist in either the old or new variable, it is considered a miss. The influence subgraph analysis module propagates downstream along the task dependency edges, iteratively adding incomplete downstream nodes of directly matched nodes to the influence set. Successful nodes whose field dependency selectors do not match the changed fields retain their output references unchanged.

9. The field-level workflow local replanning and safety verification method according to claim 8, characterized in that, Step 4 includes: Step 4.1, Node status update; The node state machine performs node state update operations based on the results of the influence subgraph analysis. It marks the pending, ready, or blocked nodes in the influence subgraph as "failed" and cancels the confirmation records associated with these nodes. For failed nodes, only their associated confirmation records are canceled, and their failure status remains unchanged. Unaffected nodes retain their current state, and successful nodes whose field dependency selectors do not hit the changed fields retain their output references unchanged. Step 4.2, Final Delivery Confirmation; During the user confirmation phase, the confirmation record generation module calculates the delivery package hash by combining the delivery identifier, target address, input variable version, field dependency information digest, and evidence digest. This delivery package hash value, along with the validity period, is saved as a confirmation record. Before executing the final delivery, the confirmation record generation module recalculates the current delivery package hash value and compares it with the delivery package hash value saved in the confirmation record. If the two match and the validity period has not expired, the confirmation record is valid. Otherwise, the confirmation record becomes invalid, and the system regenerates the delivery package hash and confirmation record. The regenerated confirmation record, after being reconfirmed by the user, is used to execute the final delivery operation.

10. The field-level workflow local replanning and safety verification method according to claim 9, characterized in that, Step 5 includes: Step 5.1, Audit event logging; The audit event storage module is responsible for recording audit events related to variable changes. The recorded content includes a summary of the variable before the change, a summary of the variable after the change, a set of changed fields, a set of affected nodes, confirmation of the cause of failure, and replanning results. These events are organized into structured records and stored in a dedicated audit database. Step 5.2, subsequent planning adjustments; After completing the audit event logging, the system performs subsequent task planning and execution adjustments for incomplete nodes in the impact subgraph; for successful nodes where the field dependency selector does not hit the changed field, the output result reference remains unchanged.

Images