Method and system for adjusting process of pre-evaluation compliance field verification

Abstract

The application relates to the technical field of workflow management, and discloses a pre-mark review compliance field verification process adjustment method and system, which comprises the following steps: obtaining a change instruction set of a compliance field semantic dependency graph, performing topological legality pre-verification and generating a new version graph snapshot; obtaining a pre-mark review instance and process topological structure data in a parallel signing execution stage; extracting new and old graph version differences and generating an instance-level graph influence analysis result; analyzing the influence of a change item on a parallel signing structure and generating a parallel structure adjustment instruction set; performing cascaded verification on a completed branch marked as needing to be reverified; merging verification results and branch addition and deletion instructions, classifying and disposing of each branch, and generating a rearranged process topological structure; and updating the rearranged result to a workflow engine and completing version switching and old version recovery.

Description

Technical Field

[0001] This invention relates to the field of workflow management technology, and more specifically, to a method and system for adjusting the process of verifying compliance fields in pre-bid review. Background Technology

[0002] In the pre-bid review system, compliance field validation relies on a pre-configured compliance field semantic dependency graph. This graph is a directed acyclic graph structure that describes the dependencies and constraint expressions between various compliance fields. When a compliance field in a review instance changes, the system determines the cascading validation path by breadth-first traversal of the compliance field semantic dependency graph, and identifies the affected approval nodes based on the state machine configuration. It replaces the unexecuted approval node sequence with a new node sequence fragment that matches the changed field value, retains the executed and unaffected approval node records, and generates a rearranged process instance.

[0003] In existing technologies, adjustments to the pre-bid review process typically employ a linear sequence replacement approach, which only handles the replacement of nodes to be executed caused by changes in field values ​​and directly writes the new node sequence fragments after the changes into the process instance.

[0004] However, existing technologies have the following two drawbacks: First, when the semantic dependency graph of compliant fields is updated online, the branches that have been completed in the parallel signing process reference the old version of the graph verification results, while the branches to be executed should use the new version of the graph. However, the parallel branching-convergence structure requires that the verification basis of all branches be consistent. The existing linear sequence replacement method cannot handle the graph version alignment of different branches within the same parallel structure, resulting in the risk of version mixing in the convergence results. Second, the existing process impact analysis only handles node replacement caused by changes in field values ​​and cannot identify the parallel branch addition and deletion requirements caused by changes in the semantic dependency graph structure of compliant fields. It may mistakenly clear the completed signing results or fail to set the parallel convergence relationship correctly when adding a new signing branch, resulting in inconsistent process instance states or deadlocks. Summary of the Invention

[0005] This invention provides a process adjustment method and system for verifying compliance fields in pre-bid review, which solves the technical problems in related technologies where online updates of the semantic dependency graph of compliance fields cannot perform automated impact analysis and process reordering for pre-bid review instances in the parallel signing execution stage, and where the verification conclusions of completed signing branches cannot be effectively verified and handled after the graph version changes.

[0006] This invention discloses a process adjustment method for compliance field verification in pre-bid review, including: obtaining a change instruction set of the semantic dependency graph of compliance fields, performing topological legality pre-verification on the change instruction set, and generating a new version graph snapshot based on versioned graph storage;

[0007] Obtain the pre-bid review instance, its process topology data, and node execution status that are in the parallel signing execution phase;

[0008] Extract the differences between the old and new compliance field semantic dependency graph versions, and calculate the intersection of the differences with the set of compliance fields involved in the pre-bid review instance to generate instance-level graph impact analysis results;

[0009] Based on the process topology data, analyze the impact of each change item on the parallel signing structure, and generate a set of parallel structure adjustment instructions.

[0010] For completed countersigned branches marked as requiring re-verification, perform cascaded verification based on the new version of the map snapshot, compare the evaluation result with the original verification result, and generate a re-verification result.

[0011] Merge the re-verification results with the branch addition and deletion instructions in the parallel structure adjustment instruction set, classify and process each branch in the parallel branch-convergence structure according to its execution status, update the convergence conditions, and generate the rearranged process topology.

[0012] The reorganized process topology is updated to the workflow engine, completing the version switching and old version recycling of the compliant field semantic dependency graph.

[0013] Further, the pre-verification of topology legality on the change instruction set includes:

[0014] Each atomic change operation in the change instruction set is simulated and applied on a copy of the semantic dependency graph of the compliant fields in the current active version, and the simulation results are then topologically sorted.

[0015] The topological sorting is implemented using the Kahn algorithm, which maintains the in-degree value of each node, adds nodes with an in-degree of zero to the processing queue in sequence, and decrements the in-degree value of all its successor nodes by one for each node processed.

[0016] If the number of nodes processed in the end is less than the total number of nodes in the simulation results, the change instruction set is deemed invalid, execution is refused, and a conflict description containing the identifiers of the nodes involved in the loop is returned; if the number of nodes processed in the end is equal to the total number of nodes, the change instruction set is deemed to have passed the legality pre-verification.

[0017] Furthermore, the step of generating a new version of the atlas snapshot based on versioned atlas storage includes:

[0018] The verified change instruction set is sorted according to the type of atomic change operation to generate an ordered change execution plan. The sorting rule is as follows: delete dependent edge operation is placed first, followed by delete field node operation, then add compliant field node operation, then add dependent edge operation, and finally modify constraint expression on edge operation.

[0019] Create a new version snapshot of the semantic dependency graph of the compliance fields of the current active version, apply the operation instructions in the ordered change execution plan to the new version snapshot one by one, register the version identifier of the new version snapshot as the current active version, and retain the original version's semantic dependency graph of the compliance fields as a historical version;

[0020] The historical version will continue to be referenced by verification requests that have been bound to the historical version identifier until the corresponding version has no active references before it can be released.

[0021] Furthermore, the extraction of differences between the old and new versions of the semantic dependency graph for compliant fields includes:

[0022] Perform set difference operations on the node sets of the new version of the compliance field semantic dependency graph and the node sets of the old version of the compliance field semantic dependency graph respectively to obtain the set of newly added nodes and the set of deleted nodes; perform set difference operations on the edge sets of the new version of the compliance field semantic dependency graph and the edge sets of the old version of the compliance field semantic dependency graph respectively to obtain the set of newly added edges and the set of deleted edges.

[0023] Among the edges that exist in both the old and new versions, extract the edges whose constraint expressions have changed to obtain the set of constraint expression changes;

[0024] The differences include the set of newly added nodes, the set of deleted nodes, the set of newly added edges, the set of deleted edges, and the set of changed constraint expressions.

[0025] Furthermore, the step of analyzing the impact of each change item on the parallel signing structure based on the process topology data, and generating a set of parallel structure adjustment instructions, includes:

[0026] For change items of type "new dependency edge" in the instance-level graph impact analysis results, determine whether the compliance field pointed to by the new dependency edge requires verification by an approval role that does not exist in the current parallel structure in the new version of the compliance field semantic dependency graph. If so, generate a new branch instruction that needs to be added for countersigning. The new branch instruction includes the approval role identifier of the branch to be added, the associated set of compliance field identifiers, and the identifier of the parallel fork-convergence pair to which it belongs.

[0027] For change items of type "delete dependent edge" or "delete node" in the instance-level graph impact analysis results, determine whether the change causes all compliance fields associated with an existing countersigned branch to no longer need to be verified in the new version of the compliance field semantic dependency graph. If so, generate a branch deletion instruction. The branch deletion instruction includes the node identifier of the branch to be deleted and the identifier of the parallel fork-convergence pair to which it belongs.

[0028] For change items of type "modify constraint expression" in the instance-level graph impact analysis results, determine the compliance fields associated with the dependency edges corresponding to the change items, retrieve the countersigning branch node responsible for verifying the compliance fields in the process topology data, and if the execution status of the countersigning branch node is "completed", then mark the countersigning branch node as needing to be re-verified based on the new version of the compliance field semantic dependency graph.

[0029] Furthermore, the cascading verification performed on the completed countersigned branches marked as requiring re-verification, based on the new version of the atlas snapshot, includes:

[0030] Obtain the current field value of each compliance field associated with the completed countersigning branch, and evaluate each constraint expression sequentially according to the dependency edge direction in the new version of the compliance field semantic dependency graph, starting from each compliance field node associated with the completed countersigning branch.

[0031] The Boolean validation conclusion obtained for each constraint expression under the current field value is compared one by one with the Boolean validation conclusion recorded when the completed countersigning branch performs approval under the old version of the compliance field semantic dependency graph.

[0032] If the new version of the verification conclusion is the same as the old version of the verification conclusion for all compliance field nodes associated with the co-signing branch, then the verification conclusion is determined to be unaffected, the approval record of the completed co-signing branch is retained, and its compliance field semantic dependency graph version is bound and updated to the new version identifier.

[0033] If the new version of the verification conclusion for at least one compliance field node is different from the old version of the verification conclusion, the verification conclusion is determined to be invalid due to the update of the compliance field semantic dependency graph. The approval record of the completed countersigning branch is marked as invalid and the execution status is reset to pending execution.

[0034] Furthermore, for change items of type "modify constraint expression" in the instance-level graph impact analysis results, when determining whether completed branches need to be re-validated, the following is also included:

[0035] Starting with the compliance field nodes involved in the change, perform a breadth-first traversal in the new version of the compliance field semantic dependency graph to extract the set of all downstream dependent field nodes;

[0036] Retrieve the signing branch node responsible for verifying the downstream dependent fields in the process topology data. If the execution status of the signing branch node is completed, it is also marked as needing to be re-verified based on the new version of the compliant field semantic dependency graph.

[0037] Before performing the classification and processing on each branch within the parallel bifurcation-convergence structure, the following is also included:

[0038] The parallel fork-convergence pair to be processed acquires an exclusive lock, and releases the exclusive lock after all classification processing and convergence condition updates are completed. During the period of holding the exclusive lock, other process adjustment requests for the same parallel fork-convergence pair enter the waiting queue.

[0039] Furthermore, the classification and handling of each branch within the parallel fork-convergence structure according to its execution status includes:

[0040] For branches that have been completed and whose verification results are consistent, retain their approval records and completed execution status.

[0041] For branches that are invalidated due to invalidation of verification results, reset their execution status to pending execution, clear their associated approval conclusion data, retain the history of approval operations, and add a note indicating the reason for invalidation.

[0042] For branches whose execution status is "in execution" and need to be stopped due to changes in the semantic dependency graph of compliant fields, send a stop instruction to the approval task distribution service associated with the branch, reclaim the pending tasks corresponding to the branch, and set the execution status of the branch to "stopped".

[0043] For branches whose execution status is pending and whose validation content needs to be adjusted, the branch node will be replaced with a new approval node that matches the changed compliance field. The set of approval role identifier and compliance field identifier of the new approval node will be determined according to the configuration in the new version of the compliance field semantic dependency graph.

[0044] For any new countersigning branch that needs to be added, insert a new countersigning branch node after the corresponding parallel fork node, set the inbound edge between the new countersigning branch node and the parallel fork node and the outbound edge between the new countersigning branch node and the parallel convergence node, and set the execution status to pending execution.

[0045] For a countersigning branch that needs to be deleted, if the execution status is pending, remove the branch node and its associated edges from the process topology data; if the execution status is completed, retain its approval record as a historical archive and remove the branch from the active path.

[0046] The aggregation condition has been updated to: Parallel Fork - All branches in the aggregation pair that are in the pending or executing state have reached the completed state, and the compliant fields of the semantic dependency graph version bindings of all completed branches are the current active version.

[0047] Furthermore, before the change instruction set performs topology legality pre-verification, it also includes:

[0048] Each atomic change operation in the change instruction set is pre-screened, and operation instructions that only involve modifying constraint expressions are excluded from the scope of topology legality pre-verification, while operation instructions that involve adding or deleting nodes and edges are included in the scope of topology legality pre-verification.

[0049] Before extracting the differences between the old and new versions of the semantic dependency graph for compliant fields, the following is also included:

[0050] For each pre-bid review instance, determine whether the compliance field semantic dependency graph version identifier bound to the pre-bid review instance is consistent with the current active version identifier. If they are consistent, skip the pre-bid review instance and only perform subsequent difference extraction and intersection calculation on pre-bid review instances with inconsistent version identifiers.

[0051] This invention provides a process adjustment system for verifying compliance fields in pre-bid review, comprising:

[0052] The graph change verification and version generation module is used to obtain the change instruction set of the compliant field semantic dependency graph, perform topological legality pre-verification on the change instruction set, and generate a new version graph snapshot based on the versioned graph storage;

[0053] The instance status acquisition module is used to acquire the pre-bid review instance, its process topology data, and node execution status that are in the parallel signing execution stage.

[0054] The difference extraction and impact analysis module is used to extract the differences between the old and new versions of the semantic dependency graph of compliance fields, and to perform intersection calculation with the set of compliance fields involved in the pre-bid review instance to generate instance-level graph impact analysis results.

[0055] The parallel structure impact analysis module is used to analyze the impact of each change item on the parallel signing structure based on the process topology data, and generate a set of parallel structure adjustment instructions.

[0056] The cascaded verification module is used to perform cascaded verification on the completed countersigned branches marked as needing re-verification, based on the new version of the map snapshot, compare the evaluation result with the original verification result, and generate a re-verification result.

[0057] The classification and reprocessing module is used to merge the re-verification results with the branch addition and deletion instructions in the parallel structure adjustment instruction set, classify and process each branch in the parallel branch-convergence structure according to its execution status, update the convergence conditions, and generate the reprocessed process topology.

[0058] The version switching and recycling module is used to update the rearranged process topology to the workflow engine and complete the version switching and old version recycling of the compliant field semantic dependency graph.

[0059] This invention provides a process adjustment method for compliance field verification in pre-bid review, solving the technical problems of version mixing and inconsistent parallel structure states in scenarios of dynamic updates of the semantic dependency graph of compliance fields and concurrent parallel signing. The method achieves the following technical effects: By storing versioned graphs and binding them to request-level versions, graph update operations do not affect the reference of the old graph by the currently executing verification request, ensuring continuous availability of the verification service during online graph updates; by performing intersection calculations of graph differences and the compliance field sets involved in the instance, and analyzing the impact of each type of change item on the parallel signing structure, the method identifies the need for adding or deleting parallel branches caused by graph structure changes; by re-executing cascade verification on completed signing branches based on the new graph and comparing the results with the original verification results, the method achieves graph version consistency alignment among branches within the same parallel fork-convergence structure; by classifying and handling each branch according to its execution status and synchronously updating the convergence conditions, the method ensures that the status of each parallel branch in the reorganized process topology remains consistent with the convergence conditions. Attached Figure Description

[0060] Figure 1 This is a flowchart of the process adjustment method for pre-bid review compliance field verification provided in this embodiment of the invention;

[0061] Figure 2 This is a schematic diagram of the ordered execution plan of atomic operations of the modified instruction set provided in an embodiment of the present invention;

[0062] Figure 3 This is a schematic diagram of the parallel countersigning branch node status of example INST-20XX-0831 provided in the embodiments of the present invention;

[0063] Figure 4 This is a schematic diagram illustrating the inclusion of change items in the instance-level spectrum impact analysis provided in this embodiment of the invention.

[0064] Figure 5 This is a schematic diagram of the triggering relationship of the parallel structure adjustment instruction set provided in an embodiment of the present invention;

[0065] Figure 6 This is a schematic diagram comparing the execution status of each branch of PFJ-001 before and after reorganization, as provided in an embodiment of the present invention.

[0066] Figure 7 This is a schematic diagram of the consistency comparison of the BR-001 verification conclusion (V-042 vs V-043) provided in an embodiment of the present invention;

[0067] Figure 8This is a schematic diagram comparing the thresholds before and after the change of the price deviation rate constraint expression provided in the embodiment of the present invention. Detailed Implementation

[0068] In the pre-bid review system, compliance field validation relies on a pre-configured compliance field semantic dependency graph. This graph is a directed acyclic graph that describes the dependencies and constraint expressions between compliance fields. When a compliance field in a review instance changes, the system determines the cascading validation path by breadth-first traversal of the compliance field semantic dependency graph. Based on the state machine configuration, it identifies the affected approval nodes, replaces the unexecuted approval node sequence with a new node sequence fragment that matches the changed field value, retains the executed and unaffected approval node records, and generates a rearranged process instance.

[0069] However, in actual pre-bid review processes, frequent adjustments to compliance regulations necessitate incremental updates to the semantic dependency graph of compliance fields during system operation, such as adding compliance field nodes or modifying dependency edge constraint expressions. Simultaneously, there are instances in the review process where parallel signing-out processes are executed, such as simultaneous signing-out by the Business Contract Center and the Supply Chain Management Center. Existing process adjustment methods face the following two technical shortcomings.

[0070] First, when updating the compliance field semantic dependency graph online, the branches already completed in the parallel signing process reference the old version of the compliance field semantic dependency graph verification results. The branches to be executed should apply the new version of the compliance field semantic dependency graph. However, the parallel fork-convergence structure requires that the verification basis of all branches be consistent. The existing linear sequence replacement method cannot handle the version alignment of compliance field semantic dependency graphs of different branches within the same parallel structure, resulting in the risk of version mixing in the convergence results.

[0071] Second, the existing process impact analysis only handles node replacements caused by changes in field values, and cannot identify parallel branch addition and deletion requirements caused by changes in the semantic dependency graph structure of compliant fields, such as adding a co-signing and approval role when adding a new dependency path. Therefore, it may incorrectly delete completed co-signing results, or fail to properly set parallel convergence relationships when adding a new co-signing branch, resulting in inconsistent process instance states or deadlocks.

[0072] According to an embodiment of this implementation, a process adjustment method for verifying compliance fields in pre-bid review is provided to solve the technical problems of version mixing and inconsistent parallel structure states in scenarios involving dynamic updates of the semantic dependency graph of compliance fields and concurrent parallel signing. It should be understood that the execution entity of this implementation is the process orchestration server in the pre-bid review system, which is communicatively connected to the workflow engine service, the graph version storage service, and the approval task distribution service.

[0073] At least one embodiment of the present invention discloses a process adjustment method for pre-bid review compliance field verification, such as... Figure 1 As shown, it includes the following steps:

[0074] Step 1: Obtain the change instruction set of the compliant field dependency graph, perform topology legality pre-verification on the change instruction set, and generate a new version graph snapshot based on the versioned graph storage;

[0075] Obtain the change instruction set of the semantic dependency graph of compliant fields. The change instruction set contains at least one atomic change operation instruction. The types of atomic change operations include adding compliant field nodes, deleting field nodes, adding dependency edges, deleting dependency edges, and modifying constraint expressions on edges.

[0076] A topological validity pre-validation is performed on the change instruction set. Each atomic change operation in the change instruction set is simulated and applied to a copy of the compliant field semantic dependency graph of the currently active version. The result is checked whether the compliant field semantic dependency graph still satisfies the directed acyclic graph constraint. Specifically, after simulating the application of all atomic change operations, a topological sort is performed on the simulated compliant field semantic dependency graph. If a cycle is detected during the topological sorting process, the change instruction set is deemed invalid, execution is rejected, and a conflict description containing the identifiers of the nodes involved in the cycle is returned. If the topological sorting can be completed normally, the change instruction set is deemed to have passed the validity pre-validation.

[0077] Furthermore, the above topological sorting is implemented using the Kahn algorithm, which maintains the in-degree value of each node, adds nodes with an in-degree of zero to the processing queue in sequence, and decrements the in-degree value of all its successor nodes by one for each node processed. If the final number of nodes processed is less than the total number of nodes in the compliant field semantic dependency graph, it indicates that a loop exists and the change instruction set is deemed illegal.

[0078] For the verified change instruction set, it is sorted according to the type of atomic change operation to generate an ordered change execution plan. The sorting rule is as follows: operations to delete dependent edges are listed first, followed by operations to delete field nodes, then operations to add compliant field nodes, then operations to add dependent edges, and finally operations to modify constraint expressions on edges. Based on versioned graph storage, a new version snapshot of the semantic dependency graph of compliant fields in the current active version is created. The operation instructions in the ordered change execution plan are applied to each item in the new version snapshot. The version identifier of the new version snapshot is registered as the current active version, and the semantic dependency graph of compliant fields in the original version is retained as a historical version.

[0079] It should be noted that the sorting rules in the above-mentioned ordered change execution plan refer to the principle of prioritizing deletion operations over addition operations, and structural operations over attribute operations. Deleting dependent edges is placed first because the dependency relationship must be removed before the field node can be safely deleted. Adding field nodes is placed before adding dependent edges because the endpoint nodes of the dependent edges must already exist. Modifying constraint expressions is placed last because this operation does not affect the topology of the compliant field semantic dependency graph, but only changes the attribute values ​​of the edges.

[0080] It should be noted that the aforementioned versioned graph storage refers to assigning a unique, monotonically increasing version identifier to each compliant field semantic dependency graph version in the graph version storage service. Each version contains a complete set of nodes, edges, and constraint expressions on each edge of the compliant field semantic dependency graph. After the original version of the compliant field semantic dependency graph is retained as a historical version, it can still be referenced by ongoing verification requests that have been bound to that historical version identifier, until that version has no active references before it is released.

[0081] In this embodiment of the application, in order to reduce the computational overhead of topology legality pre-verification when the change instruction set contains a large number of atomic operations, the following steps are included before performing topology legality pre-verification on the change instruction set: pre-screening each atomic change operation in the change instruction set, excluding operation instructions that only involve modifying constraint expressions from the scope of topology legality pre-verification, because modifying constraint expressions does not affect the topology of the semantic dependency graph of compliant fields and will not introduce loops; only operation instructions involving node addition and deletion and edge addition and deletion are included in the scope of topology legality pre-verification, thereby reducing the number of operations in the simulated application.

[0082] Step 2: Obtain the pre-bid review instance, its process topology data, and node execution status that are in the parallel signing execution phase;

[0083] Retrieve a list of all pre-bid review instances in the parallel countersigning execution phase within the system, along with the version identifier of the compliance field semantic dependency graph bound to each pre-bid review instance. Simultaneously, obtain the process topology data for each pre-bid review instance. This process topology data is represented as a directed graph, where node types include sequential approval nodes, parallel branch nodes, parallel convergence nodes, and countersigning branch nodes, with edges representing the execution order relationships between nodes. Furthermore, obtain the current execution status of each node in the process topology data, including completed, in progress, pending execution, and aborted.

[0084] It should be noted that the aforementioned parallel fork node refers to the control node in the process topology that splits the execution path into multiple parallel countersigning branches, and the parallel convergence node refers to the control node that converges the execution path after all parallel countersigning branches have been executed. A parallel fork node and a parallel convergence node constitute a parallel fork-convergence pair, representing a complete parallel countersigning structure.

[0085] It should be noted that in the above process topology data, each countersigning branch node is associated with an approval role identifier and a set of compliance field identifiers. The approval role identifier indicates which approval role is responsible for executing the branch, and the set of compliance field identifiers indicates the scope of compliance fields that the branch is responsible for verifying.

[0086] Step 3: Extract the differences between the old and new compliant field semantic dependency graph versions and generate instance-level graph impact analysis results;

[0087] For each pre-bid review instance, the old version of the compliance field semantic dependency graph is determined based on the version identifier of the compliance field semantic dependency graph bound to the pre-bid review instance. The old version of the compliance field semantic dependency graph is compared with the snapshot of the new version of the compliance field semantic dependency graph generated in step 1, and the differences between the old and new versions of the compliance field semantic dependency graph are extracted. The differences include the set of newly added nodes, the set of deleted nodes, the set of newly added edges, the set of deleted edges, and the set of changed constraint expressions.

[0088] The intersection of the differences and the set of compliance fields involved in the pre-bid review instance is calculated to filter out compliance field semantic dependency graph change items related to the pre-bid review instance. Specifically, for each change item in the differences, it is determined whether the compliance field node or the endpoint field node of the dependency edge involved in the change item belongs to the set of compliance fields involved in the pre-bid review instance. If it does, the change item is included in the instance-level graph impact analysis results.

[0089] It should be noted that the set of compliance fields involved in the above pre-bid review example is the union of the set of compliance field identifiers associated with all countersigning branch nodes in the process topology data of the pre-bid review example.

[0090] Furthermore, the extraction of differences between the old and new versions of the compliance field semantic dependency graph is achieved by performing set difference operations on the node sets and edge sets of the two versions respectively: the newly added node set is the difference between the node sets of the new and old versions of the compliance field semantic dependency graph; the deleted node set is the difference between the node sets of the old and new versions of the compliance field semantic dependency graph; the extraction method for the newly added and deleted edge sets is the same as that for the node sets; the constraint expression change set is the set of edges that exist in both the old and new versions, where the constraint expression content has changed.

[0091] Furthermore, let the node set of the old version of the compliant field semantic dependency graph be... The node set of the new version of the compliant field semantic dependency graph is The edge set of the semantic dependency graph for compliant fields in the old version is The edge set of the new version of the compliant field semantic dependency graph is ,in This represents the set of all compliance field nodes in the old version of the compliance field semantic dependency graph. This represents the set of all compliance field nodes in the new version of the compliance field semantic dependency graph. This represents the set of all dependency edges in the semantic dependency graph of the old compliant fields. If the set represents the set of all dependency edges in the semantic dependency graph of the new compliant fields, then the newly added node set is... The set of nodes to be deleted is The new edge set is The set of edges to be deleted is The constraint expression set is changed to ,in This indicates dependency edges that exist in both the old and new versions. Representing an edge The corresponding constraint expression in the old version of the compliance field semantic dependency graph. Representing an edge The corresponding constraint expression in the new version of the compliance field semantic dependency graph.

[0092] In this embodiment of the application, to avoid performing unnecessary difference analysis calculations on irrelevant instances, the following steps are included before extracting the difference content between the old and new compliance field semantic dependency graph versions: For each pre-bid review instance, it is determined whether the compliance field semantic dependency graph version identifier bound to the pre-bid review instance is consistent with the current active version identifier. If they are consistent, the pre-bid review instance does not need to perform compliance field semantic dependency graph impact analysis and is skipped directly; subsequent difference extraction and intersection calculation are only performed on pre-bid review instances whose bound compliance field semantic dependency graph version identifier is inconsistent with the current active version identifier.

[0093] Step 4: Based on the process topology data analysis, analyze the specific impact of compliance field semantic dependency graph changes on the parallel signing structure, and generate a set of parallel structure adjustment instructions;

[0094] For each pre-bid review instance with relevant change items in the instance-level graph impact analysis results, based on the process topology data of the pre-bid review instance, the specific impact of each compliance field semantic dependency graph change item on the parallel signing structure is analyzed item by item, generating a parallel structure adjustment instruction set driven by compliance field semantic dependency graph changes. The specific analysis process includes the following sub-steps:

[0095] Step 401: For change items of type "new dependency edge" in the instance-level graph impact analysis results, determine whether the compliance field pointed to by the new dependency edge requires verification by an approval role that does not exist in the current parallel structure in the new version of the compliance field semantic dependency graph. If so, generate a new branch instruction that needs to be added for countersigning. The new branch instruction includes the approval role identifier of the branch to be added, the set of associated compliance field identifiers, and the identifier of the parallel fork-convergence pair to which it belongs.

[0096] Step 402: For change items of type "delete dependent edge" or "delete node" in the instance-level graph impact analysis results, determine whether the change causes all compliant fields associated with an existing countersigned branch to no longer require validation in the new version of the compliant field semantic dependency graph. If so, generate a branch deletion instruction, which includes the node identifier of the branch to be deleted and the identifier of its parallel fork-convergence pair.

[0097] Step 403: For change items of type "modify constraint expression" in the instance-level graph impact analysis results, determine the compliance fields associated with the dependency edges corresponding to the change items, and retrieve the co-signing branch node responsible for verifying the compliance fields in the process topology data. If the execution status of the co-signing branch node is "completed," then mark the co-signing branch node as needing to be re-verified based on the new version of the compliance field semantic dependency graph.

[0098] Summarize all instructions and tags generated in steps 401 to 403 to generate a parallel structural adjustment instruction set driven by compliance field semantic dependency graph changes for the pre-bid review instance.

[0099] It should be noted that, in step 401 above, determining whether the compliance field pointed to by the newly added dependency edge requires verification by a non-existent approval role is done by querying the approval role attributes configured on the compliance field node in the new version of the compliance field semantic dependency graph, and comparing the approval role attributes with the approval role identifiers associated with each countersigning branch node in the current parallel structure one by one. If no match is found in the comparison results, it is determined that a new countersigning branch needs to be added.

[0100] In this embodiment of the application, in order to accurately handle the multi-layered cascading effects caused by changes in the semantic dependency graph of compliance fields, the following steps are also included in step 403: For change items of type modifying constraint expressions, when determining whether completed branches need to be re-verified, not only are the countersigning branches corresponding to the compliance fields directly associated with the change item checked, but also, starting from the compliance field nodes involved in the change item, a breadth-first traversal is performed in the new version of the semantic dependency graph of compliance fields to extract the set of all downstream dependent field nodes. The countersigning branch nodes responsible for verifying the above-mentioned downstream dependent fields are retrieved in the process topology data. If the execution status of these countersigning branch nodes is completed, they are also marked as needing to be re-verified based on the new version of the semantic dependency graph of compliance fields.

[0101] Step 5: Perform cascading verification based on the new version of the compliance field semantic dependency graph on the completed countersigning branches marked as requiring re-verification, and generate re-verification results;

[0102] For each completed countersigning branch marked as requiring re-verification based on the new version of the compliance field semantic dependency graph in the parallel structure adjustment instruction set, obtain the current field values ​​of each compliance field associated with the countersigning branch approval, and substitute each compliance field value into the corresponding constraint expression in the new version of the compliance field semantic dependency graph to perform cascading verification. The cascading verification process is as follows: starting from each compliance field node associated with the countersigning branch, evaluate each constraint expression sequentially according to the dependency edge direction in the new version of the compliance field semantic dependency graph, and compare the evaluation result of each constraint expression with the original verification result.

[0103] If the evaluation results of all constraint expressions are consistent with the original verification results, it is determined that the verification conclusion of the co-signing branch has not been affected by the update of the compliance field semantic dependency graph. The approval record of the co-signing branch is retained, and the compliance field semantic dependency graph version of the co-signing branch is bound and updated to the new version identifier.

[0104] If the evaluation result of at least one constraint expression is inconsistent with the original verification result, the verification conclusion of the co-signing branch is determined to be invalid due to the update of the semantic dependency graph of the compliance field. The approval record of the co-signing branch is marked as invalid due to the update of the semantic dependency graph of the compliance field, and the execution status of the co-signing branch is reset to pending execution.

[0105] The judgment results of the above branches are summarized to generate a re-verification result.

[0106] It should be noted that the evaluation order in the above cascading verification process is executed in the order of breadth-first traversal along the dependency direction starting from the dependency edge where the changed constraint expression is located in the new version of the compliant field semantic dependency graph. This ensures that when the downstream constraint expression is evaluated, the upstream constraint expression it depends on has already been evaluated.

[0107] Furthermore, comparing the evaluation result of the above constraint expression with the original verification result means comparing the Boolean verification conclusion (pass or fail) obtained by substituting the current field value into the constraint expression of the new version of the compliance field semantic dependency graph with the Boolean verification conclusion recorded by the co-signing branch when performing approval under the old version of the compliance field semantic dependency graph, to determine whether the update of the compliance field semantic dependency graph has caused a reversal of the verification conclusion. Further, let the set of compliance field nodes associated with a certain co-signing branch be... ,in These represent the first and second branches associated with the countersigning branch. The, the The until the first One compliant field node, This indicates the total number of compliance field nodes associated with this co-signing branch. In the new version of the compliance field semantic dependency graph, the nodes related to the field... The evaluation result of the relevant constraint expression under the current field value is: When the countersigning branch performs approval under the old version of the compliance field semantic dependency graph, the corresponding verification conclusion recorded is as follows: ,in Representation field The validation conclusions under the new version of the compliant field semantic dependency graph Representation field The validation conclusion under the old version of the compliant field semantic dependency graph Indicates passage, If the verification fails, the consistency judgment condition for the verification conclusion is as follows: If there exists any Make If so, the verification conclusion of the countersigning branch is deemed invalid due to the update of the semantic dependency graph of the compliance field.

[0108] Step 6: Merge the re-verification results and branch add / delete instructions, perform classification and processing on each branch within the parallel fork-convergence structure, and generate the rearranged process topology.

[0109] The re-verification result generated in step 5 is merged with the new branch and delete branch instructions in the parallel structure adjustment instruction set generated in step 4. Affected branches belonging to the same parallel fork-convergence pair are classified and processed according to their execution status, specifically including the following sub-steps:

[0110] Step 601: For branches that have been completed and whose verification conclusions are consistent, retain their approval records and completed execution status without making any adjustments.

[0111] Step 602: For branches that have been invalidated due to invalidation of the verification conclusion, reset their execution status to pending execution, clear their associated approval conclusion data, retain the history of approval operations and add a note indicating the reason for invalidation.

[0112] Step 603: For branches whose execution status is "in execution" and need to be stopped due to changes in the semantic dependency graph of compliant fields, send a stop instruction to the approval task distribution service associated with the branch, reclaim the pending tasks corresponding to the branch, and set the execution status of the branch to "stopped".

[0113] Step 604: For branches whose execution status is pending and whose verification content needs to be adjusted, replace the branch node with a new approval node that matches the changed compliance field. The set of approval role identifier and compliance field identifier of the new approval node is determined according to the configuration in the new version of the compliance field semantic dependency graph.

[0114] Step 605: For the new countersigning branch to be added, insert the new countersigning branch node after the corresponding parallel fork node, set the incoming edge between the new countersigning branch node and the parallel fork node and the outgoing edge between the new countersigning branch node and the parallel convergence node, and set the execution status of the new countersigning branch node to pending execution.

[0115] Step 606: For the countersigning branch to be deleted, if the execution status of the countersigning branch is pending, remove the countersigning branch node and its associated edges from the process topology data; if the execution status of the countersigning branch is completed, retain its approval record as a historical archive, remove the countersigning branch from the active path of the process topology data, and no longer participate in the calculation of the convergence condition.

[0116] Step 607: Based on the above classification and handling results, update the convergence conditions of the parallel convergence node. The convergence conditions are defined as follows: all branches within the parallel fork-convergence pair that are in the pending or executing state have reached the completed state, and the version bindings of the compliant fields semantic dependency graphs of all completed branches are the current active versions. Based on the updated convergence conditions and the handling results of each branch, generate the rearranged process topology.

[0117] It should be noted that the condition for determining whether a branch in execution needs to be stopped due to changes in the semantic dependency graph of compliant fields in step 603 above refers to the existence of at least one field in the set of compliant field identifiers associated with the branch that belongs to the field involved in the change item of type 'delete node' or 'delete dependency edge' in the instance-level graph impact analysis results. That is, the verification task being executed by the branch is no longer needed in the new version of the semantic dependency graph of compliant fields or the verification basis has undergone structural changes.

[0118] In this embodiment of the application, to avoid inconsistencies in process topology data due to concurrent operations during the reordering process, the following steps are included before performing classification and handling on each branch within the parallel fork-convergence structure: acquiring an exclusive lock on the parallel fork-convergence pair to be handled, and releasing the exclusive lock after all classification and handling and convergence condition updates are completed; while holding the exclusive lock, other process adjustment requests for the same parallel fork-convergence pair enter the waiting queue, thereby ensuring that the reordering operation of the same parallel structure is atomic.

[0119] Step 7: Update the rearranged process topology to the workflow engine, and complete the version switching and old version recycling of the compliant field semantic dependency graph;

[0120] The reorganized process topology was updated in the workflow engine service, and the version bindings of the compliance field semantic dependency graphs of the pre-bid review instances were uniformly switched to the new version identifier. Based on the updated process topology, the workflow engine service activated all approval nodes with an execution status of pending execution, generated corresponding approval tasks, and distributed them to the respective approval roles.

[0121] The process change notification is sent to the affected approvers. The notification includes a description of the change to the compliance field semantic dependency graph and a summary of the parallel structure adjustment. The description of the change to the compliance field semantic dependency graph records the types of changes to the compliance fields and constraint expressions involved in this change, and the summary of the parallel structure adjustment records the handling methods for each countersigning branch.

[0122] The system monitors the execution status of all verification requests and pre-bid review instances that are bound to the semantic dependency graph identifiers of the old version compliance fields. When there are no active references to the semantic dependency graph identifiers of the old version compliance fields, that is, when there are no ongoing verification requests referencing that version and no pre-bid review instances that have not completed version switching are bound to that version, the storage space of the semantic dependency graphs of the old version compliance fields is released.

[0123] The changes to the instruction set, version switching records, and parallel structure reorganization records will be written into the process change audit log. The process change audit log will record the execution results of each atomic change operation, the version switching timestamps of each pre-bid review instance, and the handling type and results of each branch within each parallel fork-convergence.

[0124] It should be noted that the process of monitoring active references to the semantic dependency graph of compliant fields in older versions is achieved by maintaining a reference counter for each version in the graph version storage service. The reference counter increments when a verification request is made or a pre-review instance is bound to a certain version, and decrements when the verification request is completed or the pre-review instance completes the version switch. When the reference counter drops to zero, storage space is released.

[0125] In this embodiment of the application, in order to fully record the decision basis for re-orchestrating in the process change audit log, the following content is also included when writing the re-orchestrating record to the process change audit log: for each affected parallel fork-convergence pair, record the execution status of each branch contained in the parallel fork-convergence pair before re-orchestrating, the version binding of the semantic dependency graph of compliance fields, the classification and disposal type, and the execution status after disposal. At the same time, record the re-verification result comparison details of each completed branch, including the original evaluation result and the new evaluation result of each constraint expression.

[0126] According to the embodiments of this implementation, because versioned graph storage and request-level version binding are used to incrementally update the compliance field semantic dependency graph, the creation of the new version of the compliance field semantic dependency graph and the retention of the old version of the compliance field semantic dependency graph ensure that the compliance field semantic dependency graph update operation does not affect the reference of the old version of the compliance field semantic dependency graph by the ongoing verification request. Therefore, the verification service can remain continuously available during the online update of the compliance field semantic dependency graph, avoiding the interruption of the ongoing verification process due to the update of the compliance field semantic dependency graph.

[0127] Because when generating instance-level graph impact analysis results, the differences between the old and new versions of the compliance field semantic dependency graph are calculated by intersecting the compliance field set involved in the pre-bid review instance. Based on this, the specific impact of each type of change item on each branch in the parallel signing structure is analyzed item by item. This includes identifying the signing branches required by the new dependency path, the deletion of redundant branches, and the impact of constraint expression changes on the verification conclusions of completed branches. Therefore, it can distinguish the different impact types of compliance field semantic dependency graph structure changes and field value changes on the parallel signing process. This overcomes the shortcomings of existing methods that can only handle linear node replacements caused by field value changes and cannot identify the parallel branch addition and deletion requirements caused by compliance field semantic dependency graph structure changes.

[0128] Because for completed branches marked as needing re-verification, cascading verification is re-executed based on the constraint expressions in the new version of the compliance field semantic dependency graph and compared with the original verification results, branches with consistent verification results retain approval records and update version bindings, while branches with inconsistent verification results are marked as invalid and reset to the pending execution state. Therefore, within the same parallel fork-convergence structure, all retained completed branches and subsequently executed branches are based on the verification criteria of the new version of the compliance field semantic dependency graph, achieving version consistency alignment of compliance field semantic dependency graphs for each branch within the parallel structure. This overcomes the defect of existing linear sequence replacement methods that cannot handle version alignment of compliance field semantic dependency graphs for different branches within the same parallel structure.

[0129] Because the parallel branch-convergence structure is rearranged with fine-grained classification and handling according to the execution status of each branch, branches that have been completed and have consistent verification are retained, branches that have failed verification are reset, branches that are affected in execution are stopped, and branches that need to be added or deleted are inserted and removed, and the convergence conditions of the convergence node are updated synchronously, the status of each parallel branch in the rearranged process topology is consistent with the convergence conditions. This avoids inconsistencies in the process instance status or deadlocks caused by incorrectly setting the convergence relationship when adding a new countersigning branch or incorrectly clearing the completed countersigning results.

[0130] like Figure 2-8 As shown, the method in this embodiment operates as follows:

[0131] During the operation of a procurement supervision platform (hereinafter referred to as "Platform GPA")'s pre-bid review system in 20XX, the compliance management department issued a batch of adjustment instructions targeting supplier qualification compliance fields. Simultaneously, there was a pre-bid review instance (Instance No.: INST-20XX-0831) in the parallel signing and execution phase within the system. This instance corresponds to the pre-bid review of a procurement framework agreement, involving three parallel signing branches: business compliance, qualification compliance, and price compliance. The business compliance branch has been approved, the qualification compliance branch is in progress, and the price compliance branch has not yet been executed. The current active version of the compliance field semantic dependency graph is V-042; this change instruction set will generate a new version, V-043.

[0132] The platform's GPA compliance management department submitted a batch of change instruction sets to the workflow orchestration server, containing a total of 5 atomic change operations. During the pre-screening phase, one operation involving only modifying constraint expressions (modifying the constraint expression of the edge dependent on the "price deviation rate" field) was excluded from the topology validity pre-verification scope. Only the remaining 4 operations involving node addition / deletion and edge addition / deletion were subjected to Kahn algorithm topology sorting verification. Simulation showed that nodes with zero in-degree could be sequentially enqueued, and the total number of processed nodes matched the total number of nodes in the graph, thus the verification passed.

[0133] An ordered change execution plan is generated according to the sorting rules: deleting dependent edges is listed first, followed by deleting field nodes, then adding field nodes, then adding dependent edges, and finally modifying constraint expressions. A new version snapshot is created based on V-042 in the graph version storage service. After applying the five operations one by one, the new version identifier is registered as V-043, while V-042 is retained as a historical version.

[0134] Table 1. Atomic Operations and Ordered Execution Plans for Modified Instruction Sets:

[0135]

[0136] The workflow orchestration server retrieved the pre-approval review instance INST-20XX-0831, which is in the parallel countersigning execution phase, from the workflow engine service. The version of the compliance field semantic dependency graph bound to it is V-042. The workflow topology of this instance includes one parallel fork node (PF-001) and one parallel convergence node (PJ-001), forming a parallel fork-convergence pair (PFJ-001). It has three countersigning branch nodes attached to it. The approval roles and compliance fields of each branch node are associated as shown in the table below.

[0137] Table 2 shows the status of parallel countersigning branch nodes in example INST-20XX-0831:

[0138]

[0139] The set of compliance fields involved in the example INST-20XX-0831 (the union of all branch-related fields) is: {Contract subject qualification, business scope compliance, qualification level, registered capital, quotation, price deviation rate}.

[0140] Because the version V-042 bound to INST-20XX-0831 is inconsistent with the currently active version V-043, difference extraction and intersection calculation are performed on them. Based on the set difference operation, the new node set is... The set of nodes to be deleted is The new edge set is The set of edges to be deleted is The constraint expression set is changed to .

[0141] The intersection of the above differences with the set of compliant fields in instance INST-20XX-0831 was used to filter out the changes relevant to this instance. The results are shown in the table below.

[0142] Table 3. Instance-level spectral impact analysis results for instance INST-20XX-0831:

[0143]

[0144] The changes that were ultimately included in the instance-level spectral impact analysis results were CHG-01, CHG-02, and CHG-05.

[0145] For CHG-01 and CHG-02 (delete dependent edges and delete nodes), check the compliance fields {qualification level, registered capital} associated with BR-002 (qualification compliance center branch): the registered capital has been deleted in V-043, which means that some fields associated with BR-002 no longer need to be validated, but the qualification level field still exists in V-043. Not all fields of BR-002 no longer need to be validated, so no branch deletion instruction is generated. However, the current execution status of BR-002 is in execution and its associated field "registered capital" belongs to the fields involved in CHG-02 (delete node), triggering the abort condition and generating an abort instruction.

[0146] For CHG-05 (modified constraint expression), the field "price deviation rate" is involved, and the corresponding countersigning branch is BR-003 (Price Compliance Center, execution status is pending), so there is no need to mark it as re-validation. Further, a breadth-first traversal is performed in V-043 starting with "price deviation rate," and no downstream dependent fields are found, so no cascading flag is triggered. At the same time, it is checked that the related fields {Contract Subject Qualification, Business Scope Compliance} of BR-001 (Business Compliance Center, completed) are unrelated to CHG-05, and therefore do not trigger a re-validation flag.

[0147] In addition, check if there are any new dependent edges requiring the addition of a new branch for countersigning: CHG-04 (new edge: credit rating → performance capability) is not within the scope of the instance and no new branch instruction will be generated.

[0148] The instruction set for parallel structure adjustment is summarized below.

[0149] Table 4 Example INST-20XX-0831 Parallel Structure Adjustment Instruction Set:

[0150]

[0151] Note: The fields associated with BR-001 (completed) have no overlap with those of CHG-01, CHG-02, and CHG-05, and are not marked as revalidation.

[0152] As shown in step 4, BR-001 (Business Compliance Center, Completed) was not marked as requiring re-verification, and BR-002 (Executing, Aborted) and BR-003 (Pending Execution) are not completed branches. Therefore, in this step, it is not necessary to perform cascading verification based on V-043 on any completed branches.

[0153] To illustrate the working logic of cascading checks, assume that if there is a field in the BR-001 associated field that is affected by CHG-05, then the current field value needs to be substituted to perform the comparison.

[0154] Let BR-001 be associated with a set of fields. Number of fields The results of evaluating the constraint expressions of the new and old versions are compared for each field. The consistency judgment condition is: for all fields in BR-001, the new version's verification result is equal to the old version's verification result.

[0155] In this scenario, BR-001 was not actually affected, and the consistency judgment results of the verification conclusion are shown in the table below.

[0156] Table 5 Comparison of BR-001 Re-verification Conclusions (Verification Records That Were Actually Unaffected):

[0157]

[0158] Both fields satisfy the consistency of the verification results between the old and new versions. It is determined that the verification result of BR-001 has not been affected by the update of V-043. The approval record of BR-001 is retained, and its map version is bound and updated to V-043.

[0159] The process orchestration server acquires an exclusive lock on the parallel fork-convergence pair PFJ-001 and performs classified processing based on the status of each branch.

[0160] BR-001 (Completed and verification results are consistent): Retain the approval record and completed status, and update the map version to V-043.

[0161] BR-002 (Affected in Execution): Send a stop instruction to the Qualification and Compliance Center's approval task distribution service, reclaim the pending tasks, and set the status to stopped; then replace BR-002 with the new approval node BR-002', adjust the associated field to {Qualification Level} (remove registered capital), and set the execution status to pending execution.

[0162] BR-003 (Pending Execution and Adjustment Required): Replace BR-003 with the new approval node BR-003', update the upper limit of the price deviation rate constraint expression to 10%, and keep the execution status pending.

[0163] Update the aggregation conditions for aggregation node PJ-001: all branches (BR-002', BR-003') in PFJ-001 that are pending or in execution have reached the completed state, and the graph version binding for all completed branches is V-043. Release the exclusive lock after completing the process.

[0164] Table 6 Comparison of the status of each branch of PFJ-001 before and after reorganization:

[0165]

[0166] The workflow orchestration server pushes the re-orchestrated PFJ-001 workflow topology to the workflow engine service. The workflow engine service activates two pending execution nodes, BR-002' and BR-003', and distributes new approval tasks to the qualification compliance center and price compliance center, respectively. The graph version binding of instance INST-20XX-0831 is uniformly switched to V-043.

[0167] The process change notification was sent to the Business Compliance Center, Qualification Compliance Center, and Price Compliance Center. The notification included an explanation of the V-042→V-043 change (deletion of the registered capital node, adjustment of the price deviation rate threshold, etc.) and a summary of the handling of each branch.

[0168] In the Graph Version Storage Service, the reference counter for V-042 decreases as INST-20XX-0831 completes the version switch. Once it is confirmed that there are no other verification requests in the system or that the instance is still bound to V-042, the reference counter drops to zero, triggering the release of V-042 storage space.

[0169] The contents of the process change audit log are shown in the table below.

[0170] Table 7 Summary of Process Change Audit Log Records:

[0171]

[0172] The entire data flow process embodies a complete logical link: Step 1 generates a new version snapshot of V-043 and an ordered change execution plan, providing a comparison benchmark for difference extraction in Step 3; Step 2 obtains the process topology and field set of instance INST-20XX-0831, providing a structural basis for intersection calculation in Step 3 and branch-level impact localization in Step 4; The three related change items CHG-01, CHG-02, and CHG-05 selected in Step 3 are mapped to specific branches and classification instructions are generated in Step 4; Step 5 performs verification and comparison on BR-001 based on the tags in Step 4 to confirm that it can be safely retained; Step 6 merges the instructions in Step 4 with the conclusions in Step 5, using exclusive locks to ensure the atomic completion of the fine-grained processing and convergence condition update of the three branches within PFJ-001; Step 7 persists the re-arrangement results to the workflow engine and completes the reference count reset and storage release of V-042, realizing a complete closed loop from change instruction input to graph version switching, parallel structure re-arrangement, and old version recycling.

[0173] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A method for adjusting the process of verifying compliance fields in pre-bid review, characterized in that, Includes the following steps: Obtain the change instruction set of the compliant field semantic dependency graph, perform topological legality pre-verification on the change instruction set, and generate a new version graph snapshot based on the versioned graph storage; Obtain the pre-bid review instance, its process topology data, and node execution status that are in the parallel signing execution phase; Extract the differences between the old and new compliance field semantic dependency graph versions, and calculate the intersection of the differences with the set of compliance fields involved in the pre-bid review instance to generate instance-level graph impact analysis results; Based on the process topology data, analyze the impact of each change item on the parallel signing structure, and generate a set of parallel structure adjustment instructions. For completed countersigned branches marked as requiring re-verification, perform cascaded verification based on the new version of the map snapshot, compare the evaluation result with the original verification result, and generate a re-verification result. Merge the re-verification results with the branch addition and deletion instructions in the parallel structure adjustment instruction set, classify and process each branch in the parallel branch-convergence structure according to its execution status, update the convergence conditions, and generate the rearranged process topology. The reorganized process topology is updated to the workflow engine, completing the version switching and old version recycling of the compliant field semantic dependency graph.

2. The process adjustment method for verifying compliance fields in pre-bid review according to claim 1, characterized in that, The topology legality pre-verification of the change instruction set includes: Each atomic change operation in the change instruction set is simulated and applied on a copy of the semantic dependency graph of the compliant fields in the current active version, and the simulation results are then topologically sorted. The topological sorting is implemented using the Kahn algorithm, which maintains the in-degree value of each node, adds nodes with an in-degree of zero to the processing queue in sequence, and decrements the in-degree value of all its successor nodes by one for each node processed. If the number of nodes processed in the end is less than the total number of nodes in the simulation results, the change instruction set is deemed invalid, execution is refused, and a conflict description containing the identifiers of the nodes involved in the loop is returned; if the number of nodes processed in the end is equal to the total number of nodes, the change instruction set is deemed to have passed the legality pre-verification.

3. The process adjustment method for verifying compliance fields in pre-bid review according to claim 2, characterized in that, The process of generating a new version of the map snapshot based on versioned map storage includes: The verified change instruction set is sorted according to the type of atomic change operation to generate an ordered change execution plan. The sorting rule is as follows: delete dependent edge operation is placed first, followed by delete field node operation, then add compliant field node operation, then add dependent edge operation, and finally modify constraint expression on edge operation. Create a new version snapshot of the semantic dependency graph of the compliance fields of the current active version, apply the operation instructions in the ordered change execution plan to the new version snapshot one by one, register the version identifier of the new version snapshot as the current active version, and retain the original version's semantic dependency graph of the compliance fields as a historical version; The historical version will continue to be referenced by verification requests that have been bound to the historical version identifier until the corresponding version has no active references before it can be released.

4. The process adjustment method for verifying compliance fields in pre-bid review according to claim 1, characterized in that, The extraction of differences between the old and new compliant field semantic dependency graph versions includes: Perform set difference operations on the node sets of the new version of the compliance field semantic dependency graph and the node sets of the old version of the compliance field semantic dependency graph respectively to obtain the set of newly added nodes and the set of deleted nodes; perform set difference operations on the edge sets of the new version of the compliance field semantic dependency graph and the edge sets of the old version of the compliance field semantic dependency graph respectively to obtain the set of newly added edges and the set of deleted edges. Among the edges that exist in both the old and new versions, extract the edges whose constraint expressions have changed to obtain the set of constraint expression changes; The differences include the set of newly added nodes, the set of deleted nodes, the set of newly added edges, the set of deleted edges, and the set of changed constraint expressions.

5. The process adjustment method for verifying compliance fields in pre-bid review according to claim 1, characterized in that, The process topology data is used to analyze the impact of each change on the parallel signing structure, generating a set of parallel structure adjustment instructions, including: For change items of type "new dependency edge" in the instance-level graph impact analysis results, determine whether the compliance field pointed to by the new dependency edge requires verification by an approval role that does not exist in the current parallel structure in the new version of the compliance field semantic dependency graph. If so, generate a new branch instruction that needs to be added for countersigning. The new branch instruction includes the approval role identifier of the branch to be added, the associated set of compliance field identifiers, and the identifier of the parallel fork-convergence pair to which it belongs. For change items of type "delete dependent edge" or "delete node" in the instance-level graph impact analysis results, determine whether the change causes all compliance fields associated with an existing countersigned branch to no longer need to be verified in the new version of the compliance field semantic dependency graph. If so, generate a branch deletion instruction. The branch deletion instruction includes the node identifier of the branch to be deleted and the identifier of the parallel fork-convergence pair to which it belongs. For change items of type "modify constraint expression" in the instance-level graph impact analysis results, determine the compliance fields associated with the dependency edges corresponding to the change items, retrieve the countersigning branch node responsible for verifying the compliance fields in the process topology data, and if the execution status of the countersigning branch node is "completed", then mark the countersigning branch node as needing to be re-verified based on the new version of the compliance field semantic dependency graph.

6. The method for adjusting the process of verifying compliance fields in pre-bid review according to claim 5, characterized in that, The cascading verification performed on the completed countersigned branches marked as requiring re-verification, based on the new version of the atlas snapshot, includes: Obtain the current field value of each compliance field associated with the completed countersigning branch, and evaluate each constraint expression sequentially according to the dependency edge direction in the new version of the compliance field semantic dependency graph, starting from each compliance field node associated with the completed countersigning branch. The Boolean validation conclusion obtained for each constraint expression under the current field value is compared one by one with the Boolean validation conclusion recorded when the completed countersigning branch performs approval under the old version of the compliance field semantic dependency graph. If the new version of the verification conclusion is the same as the old version of the verification conclusion for all compliance field nodes associated with the co-signing branch, then the verification conclusion is determined to be unaffected, the approval record of the completed co-signing branch is retained, and its compliance field semantic dependency graph version is bound and updated to the new version identifier. If the new version of the verification conclusion for at least one compliance field node is different from the old version of the verification conclusion, the verification conclusion is determined to be invalid due to the update of the compliance field semantic dependency graph. The approval record of the completed countersigning branch is marked as invalid and the execution status is reset to pending execution.

7. The process adjustment method for verifying compliance fields in pre-bid review according to claim 5, characterized in that, For change items of type "modify constraint expression" in the instance-level graph impact analysis results, when determining whether completed branches need to be re-validated, the following is also included: Starting with the compliance field nodes involved in the change, perform a breadth-first traversal in the new version of the compliance field semantic dependency graph to extract the set of all downstream dependent field nodes; Retrieve the signing branch node responsible for verifying the downstream dependent fields in the process topology data. If the execution status of the signing branch node is completed, it is also marked as needing to be re-verified based on the new version of the compliant field semantic dependency graph. Before performing the classification and processing on each branch within the parallel bifurcation-convergence structure, the following is also included: The parallel fork-convergence pair to be processed acquires an exclusive lock, and releases the exclusive lock after all classification processing and convergence condition updates are completed. During the period of holding the exclusive lock, other process adjustment requests for the same parallel fork-convergence pair enter the waiting queue.

8. The process adjustment method for verifying compliance fields in pre-bid review according to claim 1, characterized in that, The classification and handling of each branch within the parallel forking-converging structure according to its execution status includes: For branches that have been completed and whose verification results are consistent, retain their approval records and completed execution status. For branches that are invalidated due to invalidation of verification results, reset their execution status to pending execution, clear their associated approval conclusion data, retain the history of approval operations, and add a note indicating the reason for invalidation. For branches whose execution status is "in execution" and need to be stopped due to changes in the semantic dependency graph of compliant fields, send a stop instruction to the approval task distribution service associated with the branch, reclaim the pending tasks corresponding to the branch, and set the execution status of the branch to "stopped". For branches whose execution status is pending and whose validation content needs to be adjusted, the branch node will be replaced with a new approval node that matches the changed compliance field. The set of approval role identifier and compliance field identifier of the new approval node will be determined according to the configuration in the new version of the compliance field semantic dependency graph. For any new countersigning branch that needs to be added, insert a new countersigning branch node after the corresponding parallel fork node, set the inbound edge between the new countersigning branch node and the parallel fork node and the outbound edge between the new countersigning branch node and the parallel convergence node, and set the execution status to pending execution. For a countersigning branch that needs to be deleted, if the execution status is pending, remove the branch node and its associated edges from the process topology data; if the execution status is completed, retain its approval record as a historical archive and remove the branch from the active path. The aggregation condition has been updated to: Parallel Fork - All branches in the aggregation pair that are in the pending or executing state have reached the completed state, and the compliant fields of the semantic dependency graph version bindings of all completed branches are the current active version.

9. The process adjustment method for verifying compliance fields in pre-bid review according to claim 1, characterized in that, Before performing topology legality pre-verification on the said change instruction set, the following is also included: Each atomic change operation in the change instruction set is pre-screened, and operation instructions that only involve modifying constraint expressions are excluded from the scope of topology legality pre-verification, while operation instructions that involve adding or deleting nodes and edges are included in the scope of topology legality pre-verification. Before extracting the differences between the old and new versions of the semantic dependency graph for compliant fields, the following is also included: For each pre-bid review instance, determine whether the compliance field semantic dependency graph version identifier bound to the pre-bid review instance is consistent with the current active version identifier. If they are consistent, skip the pre-bid review instance and only perform subsequent difference extraction and intersection calculation on pre-bid review instances with inconsistent version identifiers.

10. A process adjustment system for pre-bid review compliance field verification, used to execute the process adjustment method for pre-bid review compliance field verification as described in any one of claims 1 to 9, characterized in that, include: The graph change verification and version generation module is used to obtain the change instruction set of the compliant field semantic dependency graph, perform topological legality pre-verification on the change instruction set, and generate a new version graph snapshot based on the versioned graph storage; The instance status acquisition module is used to acquire the pre-bid review instance, its process topology data, and node execution status that are in the parallel signing execution stage. The difference extraction and impact analysis module is used to extract the differences between the old and new versions of the semantic dependency graph of compliance fields, and to perform intersection calculation with the set of compliance fields involved in the pre-bid review instance to generate instance-level graph impact analysis results. The parallel structure impact analysis module is used to analyze the impact of each change item on the parallel signing structure based on the process topology data, and generate a set of parallel structure adjustment instructions. The cascaded verification module is used to perform cascaded verification on the completed countersigned branches marked as needing re-verification, based on the new version of the map snapshot, compare the evaluation result with the original verification result, and generate a re-verification result. The classification and reprocessing module is used to merge the re-verification results with the branch addition and deletion instructions in the parallel structure adjustment instruction set, classify and process each branch in the parallel branch-convergence structure according to its execution status, update the convergence conditions, and generate the reprocessed process topology. The version switching and recycling module is used to update the rearranged process topology to the workflow engine and complete the version switching and old version recycling of the compliant field semantic dependency graph.

Images