Action intent based treatment evidence closure determination and decision review method and system
Patent Information
- Application Number
- CN202611311185.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-27
- Publication Date
- 2026-10-27
AI Technical Summary
[0005]有鉴于此,本申请实施例提供了一种基于动作意图的处置证据闭合判定和决策复盘方法及系统,以解决现有技术存在的跨阶段证据因果关系不清、未知状态被错误闭合及异常位置难以复盘的问题
通过获取候选动作及决策上下文,创建动作根对象,对候选动作的意图要素进行规范化处理,生成与动作根对象关联的动作意图摘要;按候选动作的处理进程生成类型化证据对象,使类型化证据对象关联动作根对象和动作意图摘要,并使后继证据对象引用直接前序证据对象的标识及版本或完整性摘要,形成因果引用关系;沿因果引用关系验证必需证据对象的存在状态和前后证据对象的引用匹配状态,根据前后证据对象的动作意图摘要、对象版本及证据状态生成跨阶段校验结果;根据跨阶段校验结果和预设闭合条件确定候选动作的闭合状态,当证据对象或因果引用缺失、动作意图或对象版本冲突、证据状态不能确认时,将候选动作确定为未闭合状态;从动作根对象出发,沿因果引用关系重建证据对象的处理依赖关系,输出闭合状态并定位未闭合状态对应的异常引用位置,生成决策复盘结果。本申请能够提高因果关联准确性、降低未知状态误闭合风险、增强异常复盘定位能力。
Smart Images

Figure CN122989168A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing and decision-making process auditing technology, and in particular to a method and system for determining the closure of disposal evidence and reviewing decisions based on action intent. Background Technology
[0002] With the application of intelligent decision-making and automated handling technologies in production operations, risk control, and business scheduling, a single handling process typically involves multiple stages, including information acquisition, solution generation, review and confirmation, task assignment, and result feedback. To meet process tracking and auditing requirements, the handling system needs to save the data generated at each stage and review the decision-making and execution processes in the event of anomalies.
[0003] Existing technologies typically employ time-series logging to record the processing, generating timestamped log entries for each stage and storing and replaying them chronologically. Some systems also save input snapshots, rule versions, or processing results at critical stages and detect data changes using integrity summaries, hash chains, or version records. However, timestamps or log numbers only indicate the temporal order of different records; they cannot determine whether subsequent records are truly based on their preceding counterparts, nor can they verify whether different stages address the same action or compatible object versions.
[0004] Furthermore, when execution receipts are missing, duplicated, or conflicting, or when external processing results cannot be confirmed temporarily, existing systems may mark the process as successful due to the lack of received failure information, failing to accurately distinguish between states such as not yet executed, executed but with lost receipts, and results still pending confirmation. Traditional time-ordered review methods also struggle to pinpoint missing records, version conflicts, and reference anomalies during the processing. Therefore, existing technologies still suffer from problems such as unclear causal relationships across stages, difficulty in consistently verifying the consistency of action content and object versions, the susceptibility of erroneously closing unknown execution states, and difficulty in accurately reviewing anomaly locations. Summary of the Invention
[0005] In view of this, the embodiments of this application provide a method and system for determining the closure of disposal evidence and reviewing decisions based on action intent, so as to solve the problems of unclear causal relationships of cross-stage evidence, incorrect closure of unknown states, and difficulty in reviewing abnormal locations in the prior art.
[0006] A first aspect of this application provides a method for determining the closure of disposal evidence and conducting decision review based on action intent, comprising: acquiring candidate actions and decision context, creating an action root object, standardizing the intent elements of the candidate actions, and generating an action intent summary associated with the action root object; generating typified evidence objects according to the processing progress of the candidate actions, associating the typified evidence objects with the action root object and the action intent summary, and making subsequent evidence objects reference the identifier and version or integrity summary of the directly preceding evidence object to form a causal reference relationship; verifying the existence state of necessary evidence objects and the reference matching state of preceding and following evidence objects along the causal reference relationship, and generating cross-stage verification results based on the action intent summaries, object versions, and evidence states of preceding and following evidence objects; determining the closure state of candidate actions based on the cross-stage verification results and preset closure conditions, and determining the candidate action as an unclosed state when evidence objects or causal references are missing, action intents or object versions conflict, or evidence states cannot be confirmed; reconstructing the processing dependencies of evidence objects along the causal reference relationship starting from the action root object, outputting the closure state and locating the abnormal reference position corresponding to the unclosed state, and generating decision review results.
[0007] A second aspect of this application provides a system for determining the closure of action intent-based evidence and for decision review, comprising: an acquisition module for acquiring candidate actions and decision context, creating an action root object, standardizing the intent elements of the candidate actions, and generating an action intent summary associated with the action root object; an association module for generating typified evidence objects according to the processing progress of the candidate actions, associating the typified evidence objects with the action root object and the action intent summary, and making subsequent evidence objects reference the identifier and version or integrity summary of the directly preceding evidence object, forming a causal reference relationship; a generation module for verifying the existence state of necessary evidence objects and the reference matching state of preceding and following evidence objects along the causal reference relationship, and generating cross-stage verification results based on the action intent summaries, object versions, and evidence states of preceding and following evidence objects; a determination module for determining the closure state of candidate actions based on the cross-stage verification results and preset closure conditions, and determining the candidate action as an unclosed state when evidence objects or causal references are missing, action intents or object versions conflict, or evidence states cannot be confirmed; and an output module for reconstructing the processing dependencies of evidence objects along the causal reference relationship from the action root object, outputting the closure state and locating the abnormal reference position corresponding to the unclosed state, and generating decision review results.
[0008] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: By acquiring candidate actions and decision context, an action root object is created. The intent elements of the candidate actions are standardized to generate an action intent summary associated with the action root object. Typed evidence objects are generated according to the processing progress of the candidate actions, linking these objects to the action root object and the action intent summary. Subsequent evidence objects reference the identifier and version or integrity summary of their direct predecessor evidence objects, forming a causal reference relationship. The existence status of necessary evidence objects and the reference matching status of preceding and following evidence objects are verified along the causal reference relationship. Cross-stage verification results are generated based on the action intent summaries, object versions, and evidence status of preceding and following evidence objects. The closure status of candidate actions is determined based on the cross-stage verification results and preset closure conditions. When evidence objects or causal references are missing, action intents or object versions conflict, or the evidence status cannot be confirmed, the candidate action is identified as an unclosed state. Starting from the action root object, the processing dependencies of evidence objects are reconstructed along the causal reference relationship, outputting the closed state and locating the abnormal reference position corresponding to the unclosed state, generating a decision review result. This application can improve the accuracy of causal association, reduce the risk of erroneous closure of unknown states, and enhance the ability to locate abnormalities in review. Attached Figure Description
[0009] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0010] Figure 1 This is a flowchart illustrating the method for determining the closure of evidence and reviewing decisions based on action intent provided in the embodiments of this application. Figure 2 This is a schematic diagram of the structure of the system for determining the closure of evidence and reviewing decisions based on action intent provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation
[0011] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.
[0012] In existing technologies, decision-making and handling systems typically use time-series logs to record the stage data generated during a single handling process, and sort and replay the suggestions, reviews, assignments, and execution results according to timestamps. Some systems also save input snapshots, rule versions, and processing results, and verify whether the data has changed through integrity summaries, hash chains, or version records.
[0013] However, timestamps or log numbers only reflect the temporal sequence of records; they cannot confirm whether subsequent records are truly based on their preceding counterparts, nor can they verify whether each processing stage targets the same action intent and compatible object versions. When execution receipts are missing, duplicated, conflicting, or external results cannot be confirmed, existing systems may incorrectly close unknown states as successes, and chronological debriefing makes it difficult to accurately pinpoint missing evidence, version conflicts, and citation anomalies. Therefore, existing technologies suffer from unclear causal relationships across stages, incorrect closure of unknown states, and difficulty in debriefing anomaly locations.
[0014] To address the aforementioned issues, this application creates an action root object for candidate actions, standardizes the intent elements of the candidate actions, and generates an action intent summary associated with the action root object. It then generates categorized evidence objects according to the processing progress of the candidate actions, associating each evidence object with the action root object and the action intent summary. Furthermore, it ensures that subsequent evidence objects reference the identifier and version or integrity summary of their direct predecessor evidence objects, thus forming a causal reference relationship between evidence objects. The system verifies the existence status of necessary evidence objects and the reference matching status of preceding and subsequent evidence objects along this causal reference relationship, and generates cross-stage verification results by combining the action intent summary, object version, and evidence status.
[0015] Furthermore, this application matches the cross-stage verification results with preset closure conditions. When the required evidence object is complete, the causal references are consistent, and the evidence state forms a verifiable final state, the candidate action is determined as either a successful closure or a failed closure. When there are missing evidence objects or causal references, conflicting action intentions or object versions, or the evidence state cannot be confirmed, the candidate action remains in the corresponding unclosed state. During the review, the processing dependencies of the evidence objects are reconstructed along the causal reference relationships starting from the root object of the action, and the abnormal reference positions corresponding to the unclosed states are located.
[0016] Through the above technical solution, this application transforms the temporal correlation between disposal records into a verifiable causal correlation, which can improve the accuracy of cross-stage evidence correlation, identify action intent drift and object version conflict; at the same time, it can reduce the risk of unknown states being erroneously closed, and enhance the ability to locate missing evidence, conflicting references and unknown nodes when reviewing the disposal process.
[0017] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.
[0018] Figure 1 This is a flowchart illustrating the method for determining the closure of evidence and reviewing decisions based on action intent, as provided in the embodiment. Figure 1 As shown, the method may specifically include: S101, Obtain candidate actions and decision context, create action root object, normalize the intent elements of candidate actions, and generate action intent summary associated with action root object; S102, Generate typed evidence objects according to the processing progress of candidate actions, associate typed evidence objects with action root objects and action intent summaries, and make subsequent evidence objects reference the identifier and version or integrity summary of the directly preceding evidence objects to form a causal reference relationship; S103, verify the existence status of the necessary evidence objects and the reference matching status of the preceding and following evidence objects along the causal reference relationship, and generate cross-stage verification results based on the action intent summary, object version and evidence status of the preceding and following evidence objects; S104. Determine the closure status of the candidate action based on the cross-stage verification results and preset closure conditions. When the evidence object or causal reference is missing, the action intent or object version conflicts, or the evidence status cannot be confirmed, the candidate action is determined to be in an unclosed state. S105: Starting from the root object of the action, reconstruct the processing dependency relationship of the evidence object along the causal reference relationship, output the closed state and locate the abnormal reference position corresponding to the unclosed state, and generate the decision review result.
[0019] In some embodiments, candidate actions and decision contexts are obtained, an action root object is created, the intent elements of the candidate actions are normalized, and an action intent summary associated with the action root object is generated, including: Assign a global event identifier to the candidate action, create an action root object based on the global event identifier, and associate the candidate action with the decision context and its version on which the candidate action is based. Intent elements used to define the semantics of action execution are extracted from candidate actions and decision context. The intent elements are then aligned and deterministically encoded according to a predefined intent field structure to form standardized intent data. Perform a digest operation on the normalized intent data to generate an action intent digest. Write the version reference of the action intent digest and the decision context into the action root object and establish a binding relationship between the action intent digest and the candidate action.
[0020] Specifically, this embodiment takes the parameter handling task in the anonymous single-process simulated contract prototype as an example. The decision engine obtains the scenario package version SP-17 and the decision context CTX-2026-031-V4. The decision context records the current version V26, observation status, fact source, observation time, and missing or conflict markers of the target object OBJ-08, and saves the corresponding content summary. The rule engine generates candidate action ACT-031 based on the decision context. The candidate action indicates that the running threshold of the target object will be adjusted from the current value to the target value, while limiting the effective conditions and the expected object version. The candidate action is only in the candidate state and cannot directly enter the dispatch stage.
[0021] Furthermore, upon receiving a candidate action, the system uses an event identifier generator to combine the processing node identifier, monotonic sequence, and random component to generate a global event identifier EVT-031. This global event identifier distinguishes different processing instances and does not directly replace action content verification. The system creates an action root object ROOT-031 using the global event identifier, setting the root object identifier, creation status, candidate action reference, and decision context reference within it. The decision context reference consists of a context identifier, version number, and content summary, enabling subsequent processing to obtain the actual context version used when the candidate action was formed, rather than automatically reading the latest state of the target object. If the same target object subsequently forms version V27, version V27 is saved as the new context reference and does not overwrite the associated record corresponding to version V26.
[0022] The system call intent mode configuration determines the preset intent field structure corresponding to this action. The preset intent field structure definition can change the field position, data type, required status, and normalization rules of the action execution semantics. In this example, the target object identifier, action category, target parameters, applicable conditions, expected object version, and result constraints are extracted as intent elements from candidate actions and the decision context; the interface display order, log write time, and operator remarks are not involved in the action intent calculation. For missing but allowed empty fields, a uniform missing flag is written; for missing required fields that determine the execution boundary, summary generation is paused and candidate actions are marked as pending completion to avoid null values and field omissions generating the same semantics.
[0023] During field alignment, the system maps synonymous fields from candidate actions and decision contexts to a unified field location based on the intent field identifier, and converts numerical precision, units of measurement, Boolean values, and enumeration codes into preset expressions. For nested conditions, they are expanded according to the hierarchical path; for sets that do not affect the order, they are sorted according to the member specification values; for sequences with sequential meanings, the original order is preserved.
[0024] Furthermore, after alignment, the system performs deterministic encoding on each field according to a fixed field order, unified character encoding, and length markers, and adds the intent pattern version to the encoding header to form normalized intent data. The same execution semantics will generate the same normalized result even if the source field names or input formats are different; however, different normalized results will be generated when key parameters, target objects, or expected versions change.
[0025] The summary generator performs a summary operation on the normalized intent data to obtain the action intent summary DG-031. The summary algorithm can be a complete summary algorithm that produces a fixed-length result for a fixed input, and the summary rule used is recorded through the algorithm identifier, without being limited to a specific database. The system writes the action intent summary, intent mode version, decision context version reference, and candidate action identifier into the action root object, and simultaneously writes the action root object identifier and action intent summary back to the candidate actions, forming a bidirectional searchable binding relationship. When generating suggestions, making manual decisions, or dispatching verification evidence objects, this binding relationship is directly inherited, and the action intent summary is not replaced again based on the latest object state.
[0026] To prevent duplicate submissions of candidate actions that result in multiple root objects, the system performs uniqueness checks using global event identifiers. Upon receiving the same global event identifier again, the system first compares the candidate action identifier, the decision context version reference, and the action intent summary. If all three match, the already created action root object is returned; otherwise, an identifier conflict is recorded, and overwriting is rejected. The association between the action root object and the candidate action is written within the same transaction. If any write fails, a root object version that can be referenced in subsequent stages is not published. After binding is complete, a root object version summary is generated for subsequent evidence objects to confirm that the referenced object has not been replaced.
[0027] During prototype validation, if only the display notes are modified after manual approval, the re-normalized summary remains consistent. However, if the target parameter is changed to another value, or the expected object version is changed from V26 to V27, the regenerated summary will be inconsistent with DG-031. The system will recognize the changed content as a new action intent and will not use the original approval record. Through the above processing, the root action object can fix the context version and execution semantics used when the candidate action is formed, providing a unified association basis for subsequent causal references of evidence objects, cross-stage consistency verification, and incomplete closure determination, thereby reducing the risk of action intent drift at different disposal stages.
[0028] In some embodiments, typified evidence objects are generated according to the processing progress of candidate actions, such that the typified evidence objects are associated with the action root object and the action intent summary, and subsequent evidence objects reference the identifier and version or integrity summary of the directly preceding evidence object, forming a causal reference relationship, including: Establish evidence object type constraints based on the processing stages and corresponding processing functions of candidate actions, obtain stage information formed in each processing stage that can characterize the processing basis and processing status, and encapsulate the stage information into typed evidence objects with object identifiers and object versions according to the evidence object type constraints. Write the identifier and action intent summary of the root object of the action into each type of evidence object to establish the attribution relationship between the type of evidence object and the candidate action; The direct preceding evidence object is determined based on the actual evidence used when the subsequent evidence object is formed. The identifier and version or integrity summary of the direct preceding evidence object are written into the reference field of the subsequent evidence object, thus forming a causal reference relationship from the direct preceding evidence object to the subsequent evidence object.
[0029] Specifically, this embodiment continues to use the candidate action ACT-031 from the anonymous single-process simulated contract prototype. The system pre-establishes an evidence object type constraint table, configuring object type codes, stage information patterns, allowed direct preceding types, available evidence status, and version generation rules according to the processing stage of the candidate action. The type constraints do not use chronological order as the sole basis for causality, but rather specify the types of evidence and content that can be cited in the current stage.
[0030] For example, the context phase corresponds to the context evidence object, the suggestion phase corresponds to the suggestion evidence object, the verification phase corresponds to the verification receipt object, the manual review phase corresponds to the manual decision object, and the pre-dispatch check phase corresponds to the dispatch verification object. In this example, the execution receipt and result confirmation only illustrate the object structure through a simulated contract and do not indicate that the actual external execution interface verification has been completed.
[0031] During the context processing phase, the system reads the decision context CTX-2026-031-V4 and encapsulates the factual data, source status, observation time, missing data markers, and conflict markers used when forming candidate actions into a contextual evidence object E-CTX-031-V1. The object identifier E-CTX-031 is generated by combining the root object identifier, type code, and phase sequence. Version V1 indicates that this evidence object is being formed for the first time. The system performs mode verification on the phase information, retains the version reference of the original evidence, and calculates the object integrity summary H-CTX-01. If the factual data is subsequently updated, the system generates a new object version that does not overwrite V1, ensuring that the context used when forming candidate actions remains available.
[0032] The suggestion phase invokes scenario package SP-17 and rule version R8 to generate suggestion content based on E-CTX-031-V1, and encapsulates the suggestion basis, calculation status, and output results into a suggestion evidence object E-ADV-031-V1. The direct preceding type of the suggestion object must be a context evidence type. The system writes the object identifier, version V1, and integrity summary H-CTX-01 of E-CTX-031-V1 into the preceding reference field of the suggestion object to indicate that the suggestion was actually formed based on this version context. Other context records that are only earlier than the suggestion object in time but did not participate in the suggestion calculation are not written into the preceding reference field.
[0033] During the verification phase, constraint checks are performed based on the suggested object and verification rule version C5, generating a verification receipt object E-CHK-031-V1. The verification receipt records the verification input reference, rule version, processing status, and verification result, with its direct preceding reference pointing to E-ADV-031-V1. The manual review interface retrieves the suggested content and verification result from the verification receipt object. After the reviewer makes an approval decision, an approval evidence object E-APR-031-V1 is generated. The approval evidence object references E-CHK-031-V1 and records the actual input version displayed during the review, preventing the approval record from being bound only to the candidate action number without being bound to the actual evidence. If the review conclusion is rejection or supplementary information, the system generates an evidence object with the corresponding status according to the same manual decision type, without changing the already formed preceding evidence object.
[0034] Before dispatch, the system rereads the real-time version of the target object OBJ-08. If the real-time version is still V26, a dispatch verification object E-DSP-031-V1 is created, and it directly references the approval evidence object E-APR-031-V1. The dispatch verification object also records the real-time object version and version source. If the real-time version has changed to V27, the system still generates a dispatch verification object, but records the verification status as version incompatible for subsequent closure determination. The difference cannot be eliminated by rewriting the approval evidence object. When the simulation execution interface returns the receiving status, a receipt evidence object can be generated and referenced by the dispatch verification object; the simulation result confirmation object then references the receipt evidence object, thus maintaining the same reference structure as the aforementioned objects during the execution phase.
[0035] Each typed evidence object is written with ROOT-031 and DG-031 upon creation, along with an attribution reference for the candidate action ACT-031. The object storage layer is indexed using the root object identifier and the object identifier, enabling evidence objects under the same action root to be retrieved, while also detecting incorrectly attributed objects using the action intent summary. For stages with multiple actual bases, the reference field can store multiple direct preceding references, each containing an object identifier and an object version or integrity summary; the system does not substitute indirect preceding objects for direct bases. Before writing an object, the preceding type is checked according to type constraints; if the check fails, the object is retained in a pending generation state, and a formal version that can be referenced by subsequent stages is not released.
[0036] Through the encapsulation and referencing processes described above, a directed causal structure is formed under ROOT-031, from contextual evidence, suggestions, verification receipts, and manual decisions to dispatch verification. Each node not only stores the processing information of its current stage but also clearly records the direct basis used when forming that node. Even if multiple records are from similar times or the object version changes subsequently, it is possible to distinguish between actual processing dependencies and simple temporal adjacency relationships, thereby providing a verifiable data foundation for cross-stage causal reconciliation and decision review.
[0037] In some embodiments, the existence status of necessary evidence objects and the reference matching status of preceding and following evidence objects are verified along causal reference relationships. Cross-stage verification results are generated based on the action intent summary, object version, and evidence status of the preceding and following evidence objects, including: Based on the processing stage constraints of the candidate actions, the necessary evidence objects are determined, and each necessary evidence object and its direct preceding evidence object are retrieved along the causal reference relationship to determine the existence status of the necessary evidence objects. Parse the reference field of the subsequent evidence object, match the corresponding preceding object reference with the actual obtained direct preceding evidence object, and determine the reference matching status based on the evidence object type; Compare the action intent summaries associated with the evidence objects before and after, verify the object version and evidence status according to the preset version constraints and state transition relationships, associate the corresponding verification results with the existence status and reference matching status, and generate cross-stage verification results.
[0038] Specifically, this embodiment continues to perform cross-stage causal reconciliation on the evidence chain under the root object ROOT-031. The system first reads the processing stage constraints corresponding to the candidate action ACT-031. The processing stage constraints are jointly determined by the action category, the current processing branch, and whether the dispatch stage has been entered. The system also configures the required evidence types and allowed preceding and following connections for each processing branch.
[0039] In a specific example, candidate actions proceed to dispatch verification after being suggested, validated, and manually approved. Therefore, the context evidence object E-CTX-031-V1, the suggested evidence object E-ADV-031-V1, the validated receipt object E-CHK-031-V1, the approved evidence object E-APR-031-V1, and the dispatch verification object E-DSP-031-V1 constitute the necessary evidence objects before dispatch. If the manual decision is rejection, the rejection evidence object becomes the termination object of the corresponding branch, and the system will not misjudge the dispatch verification object as a missing object of that branch.
[0040] The reconciliation engine reads the primary ownership object from ROOT-031, and then retrieves the direct preceding evidence object in reverse order based on the preceding references of each object. The retrieval uses object identifiers to locate logical objects and leverages the object version or integrity summary in the references to pinpoint the actual object content used when forming the subsequent object. For each required evidence type, the engine records its existence status: existing, missing object, or missing reference only. Missing object indicates that no evidence object conforming to the type constraints was obtained at the corresponding processing stage; missing reference only indicates that the subsequent evidence object already exists, but the reference field cannot be connected to the required direct preceding evidence object. These two cases are recorded separately to avoid confusing the absence of processing with corrupted reference data as the same exception.
[0041] When parsing E-ADV-031-V1, the engine retrieves E-CTX-031, V1, and H-CTX-01 from the preceding references and reads E-CTX-031-V1 from the object storage layer. The engine first compares the reference identifier with the actual object identifier, then compares the reference version and integrity summary, and subsequently verifies whether the suggested evidence type allows direct reference to the context evidence type. If all three match, the corresponding causal edge is recorded as reference consistency. If the reference identifier does not exist, it is recorded as a dangling reference; if the identifier exists but V2 is actually retrieved, while the reference specifies V1, V1 is searched again, and if it cannot be retrieved, it is recorded as a missing version reference; if the object is retrieved but the type does not conform to the stage constraints, it is recorded as a type conflict. E-CHK-031-V1, E-APR-031-V1, and E-DSP-031-V1 are processed edge-by-edge in the same way. The timestamp is only used to display cross-node time deviations and does not replace object reference verification.
[0042] Furthermore, after completing the reference matching, the engine reads the action intent summary associated with the preceding and following evidence objects. In a normal chain, all objects are associated with DG-031, and the intent verification status is consistent. During prototype testing, the action intent summary referenced by the approval object is replaced with DG-032 generated by another target parameter. Even if the approval object and the verification receipt are temporally adjacent, the engine still marks the causal edge between E-CHK-031-V1 and E-APR-031-V1 as an intent conflict. For changes in display fields that do not carry execution semantics, the normalized summary remains unchanged, and no intent conflict is generated.
[0043] Version verification employs phased version constraints. Recommended objects must reference the context version at the time the recommendation was formed; approved objects must reference the version shown on the verification receipt during manual review; and dispatched verification objects compare the expected object version bound to the approval record with the real-time object version obtained before dispatch. In this example, the approval record is bound to V26, while dispatch verification obtains V27. The engine records this node as an object version incompatibility but retains E-DSP-031-V1 and its version source, without writing back the preceding object. If the real-time version remains V26, the version verification passes.
[0044] State verification checks whether a preceding evidence state can transition to a subsequent evidence state according to state transition relationships. A verified state can proceed to an approved or rejected state; an approved state can proceed to a dispatch verification state; a state awaiting supplementation cannot directly proceed to a dispatch verification state. The engine simultaneously compares the state event records with the object's final state; if the two are inconsistent, a state transition exception is generated. Simulated receipts or result confirmation objects only participate in test validation when the corresponding simulated contract is valid and the preceding state allows it; they are not considered as evidence that a real external result has been confirmed.
[0045] Finally, the engine summarizes the existence state, reference matching state, intent verification state, version verification state, and migration verification state by evidence object and causal edge, generating a cross-stage verification result CR-031. Each anomaly is associated with the object identifier, preceding reference, and occurrence stage, which can be directly read for closure determination. The above processing can discover evidence chains that are chronologically correct but based on incorrect evidence, and distinguish between missing objects, broken references, intent drift, version changes, and illegal state migrations, providing a verification basis for forming an accurate closure state.
[0046] In some embodiments, the process of generating cross-stage verification results further includes: Identify duplicate evidence objects based on idempotency identifiers and evidence object types, and compare the integrity summaries and causal citations of duplicate evidence objects. When the integrity summary and causal reference are consistent, duplicate evidence objects are marked as idempotent duplicates, merged into the same logical evidence object, and the existing causal reference is maintained; When the integrity summary or causal reference is inconsistent, the duplicate evidence object is marked as a conflict object, the abnormal reference position corresponding to the conflict object is determined, and the corresponding conflict state is written into the cross-stage verification result.
[0047] Specifically, this embodiment continues to use the evidence chain under the action root object ROOT-031, and uses the example of duplicate submissions due to response timeout in the simulated dispatch interface to illustrate duplicate evidence handling. When the system submits a task to each processing stage, it generates an idempotent identifier based on the action root object identifier, evidence object type, stage request sequence, and action intent summary. The idempotent identifier is used to identify multiple returns generated by the same stage processing request and is not used to replace evidence content or causal reference verification. In this example, an idempotent identifier IDM-031-R1 is generated for the simulated receive request after dispatch verification, and this identifier is passed to the simulated interface along with the stage request. All evidence objects returned by the interface carry this identifier.
[0048] Before writing evidence objects, the deduplication processor queries the object index according to the idempotency identifier and the evidence object type. Only objects with the same idempotency identifier and the same evidence object type are included in the same duplicate candidate group, avoiding incorrect merging due to the reuse of similar business numbers in different processing stages. For objects without an idempotency identifier, the system retains the independent object status and records a verification mark, and does not directly presume them to be duplicate objects based on proximity in time or similarity in content. The first valid object in the duplicate candidate group is used as the baseline object, and subsequent arriving objects are used as objects to be compared, but the order of arrival does not necessarily mean that their content is correct.
[0049] When calculating the integrity summary, the system extracts stable fields that characterize the processing result according to the content pattern of the corresponding evidence object type, and incorporates the action root object identifier, action intent summary, processing status, and stage data into deterministic encoding. Network arrival time, number of retries, and local storage location are not included in the summary calculation to avoid transmitting additional information that could lead to different summaries for the same processing result. The integrity summary is generated after deterministic encoding is completed. Causal references are separately normalized into an ordered set of references to the direct preceding object identifier, object version, or preceding integrity summary, ensuring that objects with the same content but different bases can still be identified.
[0050] The first simulation returned evidence object E-RCP-031-A, with an idempotency identifier of IDM-031-R1, an integrity digest of H-RCP-11, and a direct preceding reference pointing to E-DSP-031-V1. A timeout retry resulted in E-RCP-031-B. Although the local object identifier and arrival time differed, the idempotency identifier, evidence object type, integrity digest, and direct preceding reference were identical to E-RCP-031-A. The deduplication processor marked the two physical records as idempotent duplicates, created a logical evidence object L-RCP-031, and saved A and B as source instances of the logical object. When subsequent evidence objects already referenced E-RCP-031-A, the system maintained the existing causal reference and mapped E-RCP-031-A to L-RCP-031 in the parsed index, merging without batch rewriting historical objects.
[0051] Furthermore, after logical merging, the system retains the reception time and transmission status of each source instance for troubleshooting retry processes, but only one logical evidence object is counted in the required evidence object count and closure condition calculation. If another object consistent with A is subsequently received, the source instance is added, and causal nodes are not generated repeatedly. This avoids the same receipt being counted multiple times or creating false multi-branch processing paths.
[0052] In another test, the simulated interface returned E-RCP-031-C, with the idempotency identifier still IDM-031-R1, but the processing status changed from received to not received, and the normalized content formed a digest H-RCP-12. Since H-RCP-12 differs from H-RCP-11, the system marks A and C as content conflicts and does not select the later-arriving C to overwrite A. If the integrity digests of the returned objects are the same, but the direct preorder reference is changed to E-DSP-031-V2, the system marks it as a basis conflict, indicating that the same result claims to be based on different dispatch verification versions. Both content conflicts and basis conflicts are considered conflict objects and do not undergo idempotency merging.
[0053] During anomaly localization, the system identifies conflict groups based on the common idempotency identifier of duplicate objects, locates content summary differences to corresponding evidence nodes, and locates pre-reference differences to the causal edge from the dispatched verification object to the receipt object, recording the conflict instance identifier, baseline reference, and difference fields. The cross-stage verification result CR-031 is written to the corresponding anomaly reference location, and the evidence status is updated to conflict pending verification. When this conflict exists, the closure determination cannot determine the candidate action as successfully closed. New reconciliation evidence objects can be supplemented subsequently through external queries or manual reconciliation, but the conflict source instance must not be directly deleted or rewritten.
[0054] In the above embodiments, the receipts are generated by simulated contracts and used to verify the duplicate identification and conflict classification logic. By simultaneously verifying the integrity summary and causal references, the system can both merge idempotent duplicates with completely identical content and basis, and detect changes in processing results or basis drift under the same idempotent identifier, avoiding simply overwriting real conflicts according to the last arrived record.
[0055] In some embodiments, the closure state of a candidate action is determined based on cross-stage verification results and preset closure conditions. When the evidence object or causal reference is missing, the action intent or object version conflicts, or the evidence state cannot be confirmed, the candidate action is determined to be in an unclosed state, including: Extract verification rules for necessary evidence objects, causal references, and verifiable final states from the preset closure conditions, match the cross-stage verification results with the verification rules, and determine the closure condition matching status. When the closure condition matches the state characterization, the necessary evidence object is complete, the causal reference is consistent, and the evidence state forms a verifiable final state, the candidate action is determined as a closed state, and the closure success or failure is determined according to the verifiable final state. When the closure condition matching state fails, the reason for the non-closure is determined according to the failure verification rule. The non-closure state corresponding to the missing, conflict or cannot be confirmed is generated according to the exception type mapping rule. Before a verifiable final state is formed, the candidate action is prohibited from being determined as a successful closure.
[0056] Specifically, in this embodiment, the closure decision maker reads the cross-stage verification result CR-031 of the candidate action ACT-031 and loads the closure condition version CL-6 corresponding to the action category and processing branch. The closure condition is not a single timeout threshold, but rather consists of necessary object rules, causal edge rules, and final state confirmation rules. The necessary object rules define the evidence objects and valid versions that must be formed in the current processing branch; the causal edge rules define direct references, action intent summaries, and version relationships between adjacent processing stages; and the final state confirmation rules define the types of evidence that can prove the end of the process, the result state, and the allowed preceding states. The closure condition version is saved separately as the rules are updated, allowing subsequent reviews to restore the rules actually used when making the closure decision.
[0057] The closure decision maker establishes a rule matching table based on the object identifier and anomaly location in CR-031. For each required object rule, it reads the existence status of the corresponding evidence object; for each causal edge rule, it reads the verification status of reference matching, action intent, object version, and state transition; for final state confirmation rules, it checks whether the final state evidence object exists, whether it references a permitted direct predecessor object, and whether the result content can be determined. The matching results are recorded as passed, failed, or cannot be confirmed, and the indices of the corresponding evidence object and causal edge are retained. Only when all required rules are passed is the closure condition matching state satisfied; otherwise, it is not processed as passed.
[0058] In the successful path of the simulated contract, the contextual evidence, suggestions, verification receipts, approvals, dispatch verifications, simulated receipts, and simulated result confirmation objects under ROOT-031 all exist. Each object is associated with DG-031, and the direct preceding references are consistent with the actual object versions. The simulated result confirmation object records that the processing result has reached the expected state and references the simulated receipt object. The closure decision maker recognizes this result as a verifiable successful final state and generates a closed state version CS-031-V1 with a state value of CLOSED_SUCCEEDED when all rules pass. If the result confirmation object explicitly records execution failure, and the failure result is compatible with the receipt content and state transition, then CLOSED_FAILED is generated. Closure failure indicates that the failure fact has been confirmed by complete causal evidence, which is different from an unclosed state caused by insufficient evidence.
[0059] In the object missing test, the suggested object and the verification receipt object already exist, but the approved evidence object has not been generated, while the dispatch verification object appears in the evidence chain. CR-031 simultaneously records the missing approved object and the dispatch verification object lacking a valid direct preceding reference. The closure determiner maps the failure rule to OPEN_MISSING and records the position of the missing approved node between E-CHK-031-V1 and E-DSP-031-V1 as the reason for the unclosed state. If the approved object exists but the preceding reference field is empty, a missing class unclosed state is also formed, but the reason is marked as missing reference, which facilitates the distinction between object not generated and causal edge breakage.
[0060] In conflict testing, if the approval object is associated with DG-032 while the preceding verification receipt is associated with DG-031, or if the approval record is bound to target object version V26 while the dispatch verification uses V27, CR-031 will indicate intent conflict and version incompatibility, respectively. The closure decision maker generates OPEN_CONFLICT according to the exception type mapping rules and retains the object identifiers, versions, and exception causal edges at both ends of the conflict. Even if subsequent object records are processed successfully, the successful result cannot overwrite the preceding conflict as long as the conflict has not been interpreted through new reconciliation evidence.
[0061] In tests with unknown outcomes, the dispatch request has been submitted, and both the dispatch verification object and the dispatch record exist, but no simulated acknowledgment or result confirmation has been received within the waiting window. Since external effects may have already occurred, the system cannot equate this situation with no execution, nor can it generate a successful closure simply because there is no failure response. The closure determiner records the final state confirmation rule as unconfirmable, generating OPEN_UNKNOWN. If an external query or manual reconciliation has been initiated, RECONCILIATION_REQUIRED can be added to this state; if a compensation decision has been made but the compensation action has not yet been closed, COMPENSATION_PENDING can be added. Adding a state does not eliminate the original unknown cause.
[0062] When multiple anomalies exist simultaneously within the same chain of evidence, the closure decision maker retains all failed rules and determines the primary unclosed state based on the degree of obstruction to the closure conclusion, without deleting secondary causes. Upon arrival of subsequent supplementary evidence, the system re-executes cross-stage verification and closure matching, generating a new closure state version and state events, without directly modifying previous judgment records (e.g., CS-031-V1). The state event chain must be consistent with the current closure state; if the event chain indicates unclosed but the object is directly written as successful, the state update is rejected.
[0063] In this embodiment, the execution receipt and result confirmation use simulated contract data to illustrate the closed logic. In a real environment, only result evidence verified by source and causal citations can constitute a verifiable final state. By using complete evidence, consistent citations, and final state confirmation as closure conditions, the system can distinguish between proven success, proven failure, and insufficient evidence, and ensure that missing, conflicting, or unknown information is not defaulted to success.
[0064] In some embodiments, after a candidate action is determined to be an open state corresponding to an evidence state that cannot be confirmed, the method further includes: Reconciliation tasks are generated based on the reasons for unclosed relationships and the current causal references, and the corresponding external processing results are queried according to the idempotency flag configured for the candidate actions. When feedback confirming the processing result is obtained, a reconciliation evidence object is generated that references the current direct preceding evidence object. The reconciliation evidence object is then incorporated into the causal reference relationship, and cross-stage verification and closure status determination are re-executed. When no feedback confirming the processing result is obtained, the system remains open, generates a manual reconciliation object that records the basis for reconciliation and the processing decision, and keeps the existing typified evidence objects unchanged.
[0065] Specifically, this embodiment continues to process the OPEN_UNKNOWN state corresponding to candidate action ACT-031. Verification object E-DSP-031-V1 and evidence sending object E-SND-031-V1 have been formed, and evidence sending indicates that the phase request has been submitted, but no verifiable receipt has been obtained within the waiting window. The closure decision maker marks the final state confirmation rule as unconfirmable and records the position lacking result evidence after E-SND-031-V1 as the reason for non-closure. The reconciliation scheduler reads this reason and the current causal reference relationship under ROOT-031, generating reconciliation task RT-031-V1.
[0066] The reconciliation task record includes the root object identifier of the action, a summary of the action intent, the last confirmed evidence object, the location of the exception reference, the idempotency identifier of the original stage request, the target query interface, and query control parameters. Query control parameters include the allowed number of queries, the interval between adjacent queries, and the task deadline, used to limit duplicate queries without changing the execution semantics of candidate actions. The reconciliation scheduler obtains the idempotency identifier IDM-031-R1 from the original sent evidence object, without regenerating a new request identifier or resubmitting the execution action, thus avoiding accidental triggering of secondary external processing for the result query.
[0067] Furthermore, upon reaching the query timing, the reconciliation scheduler sends a read-only result query to the simulated external interface, carrying IDM-031-R1, DG-031, and the target object identifier in the request. The interface can return feedback such as processed result, explicit failure, still processing, not found, or incomplete response content. Upon receiving feedback, the system first verifies the feedback source and query identifier, then compares the action intent summary, target object, and result version associated with the feedback. Only when the feedback can be uniquely attributed to ACT-031 and the processing result has a definite status is the feedback recognized as confirming the processing result. Not finding a record does not directly equate to not executing, because the external interface may not have completed indexing or historical receipts may be lost.
[0068] For example, the simulated interface returns a successful processing record corresponding to IDM-031-R1, with the result object version being V26 and the action intent digest being DG-031. The system encapsulates the query request, feedback content, source status, and feedback time into a reconciliation evidence object E-REC-031-V1 and calculates a completeness digest. Since the query targets unknown results after E-SND-031-V1, the reconciliation evidence object uses E-SND-031-V1 as the current direct preceding evidence object, writing its object identifier, version, and completeness digest into the reference field, while also associating it with ROOT-031 and DG-031. The reconciliation object connects to the causal reference relationship by adding a new node, without replacing the previously missing simulated receipt or modifying the sent evidence object.
[0069] After the reconciliation evidence object is added to the chain, the system re-determines the necessary evidence objects for the current processing branch and performs existence, reference, action intent, object version, and state transition checks along the updated causal reference relationship. If E-REC-031-V1 is compatible with the approved content and the distribution version, and forms a verifiable successful final state, the closure decision generator generates a new closed state version CLOSED_SUCCEEDED; if the feedback clearly indicates that the processing failed and the failure state is verifiable, then CLOSED_FAILED is generated. The original OPEN_UNKNOWN state and its formation basis are still retained in the state event chain to indicate that the result was once in an unknown state.
[0070] If the interface continues to return feedback indicating that the process is still in progress, the item was not found, or it cannot be attributed, the reconciliation scheduler will maintain the OPEN_UNKNOWN status and attach a RECONCILIATION_REQUIRED status after the task deadline is reached. The system generates a task to be manually processed, showing the reviewer the action intent, the last confirmed node, the executed queries, and each feedback. The reviewer can decide to continue the query, maintain the unknown status, or initiate a compensation assessment; they cannot directly select successful closure without verifiable evidence. After the review is completed, the system generates an E-MAN-031-V1 manual reconciliation object, recording the review basis, processing decision, and responsible node, and referencing the currently last confirmed evidence object or the most recent query evidence object.
[0071] The manually reconciled object is included in the causal reference relationship as a new type of typified evidence object, but it does not modify E-DSP-031-V1, E-SND-031-V1, or the previously generated verification results. If late feedback is received subsequently, the system generates a separate feedback evidence object and references the corresponding query object, and performs cross-stage verification again; when the late feedback is inconsistent with the manual decision, the conflict state is retained, and no historical object is overwritten by the arrival time.
[0072] This embodiment illustrates the reconciliation process through a simulated query interface. However, actual execution of receipt queries and external result confirmation still requires verifiable data from a specific external system. The above process utilizes the original idempotent identifier to query existing processing results and extends the causal chain with newly added reconciliation evidence objects. This allows unknown results to be closed again when evidence is sufficient, and to remain explicitly open and verifiable when evidence is still insufficient.
[0073] In some embodiments, starting from the root action object, the processing dependencies of the evidence object are reconstructed along causal reference relationships, the closed state is output, and the abnormal reference positions corresponding to the unclosed state are located, generating decision review results, including: Using the root object of the action and the summary of the action intent as search criteria, obtain the typified evidence objects belonging to the candidate actions, and parse the preceding object references of each typified evidence object record; Starting from the root object of the action, traverse each type of evidence object according to the causal hierarchy determined by the references of the preceding objects, restore the corresponding object version and the stage evidence used when forming the type of evidence object, and rebuild the processing dependency relationship. The cross-stage verification results are mapped to the processing dependencies, the abnormal reference positions of the evidence objects or causal references that failed the verification are determined in the processing dependencies, the abnormal reference positions, the corresponding abnormal states and the closure states are associated, and the decision review results are generated.
[0074] Specifically, in this embodiment, the debriefing reconstructor receives the action root object ROOT-031. The debriefing request carries ROOT-031 and the action intent summary DG-031. The debriefing reconstructor first queries the evidence object attribution index using the root object identifier to obtain the typed evidence object set corresponding to the candidate action ACT-031, and then compares the action intent summaries associated with each object. Objects with the same root object identifier but different action intent summaries are not directly included in the normal processing path, but are placed in the verification set and marked as having abnormal intent, to avoid incorrectly attributed objects interfering with the original action debriefing.
[0075] For each retrieved object, the reconstructor parses the object identifier, object type, object version, integrity summary, and preceding reference fields. The preceding reference field can contain one or more direct preceding object references, each corresponding to the evidence actually used when the current object was formed. The system builds a reverse adjacency index based on the preceding object identifier, enabling preceding references stored in subsequent objects to be converted into causal edges pointing from preceding nodes to subsequent nodes. When the object pointed to by a reference cannot be obtained, a missing placeholder node is first created, retaining the target identifier, specified version, and reference source, ensuring that the reconstruction of the remaining paths is not interrupted due to the missing object.
[0076] The root object of the action is at the 0th causal layer. Context evidence objects directly related to the root object and not dependent on evidence from other stages are at the 1st causal layer. Suggested objects are placed in subsequent causal layers according to their references to context evidence. The layers for verifying receipts, making manual decisions, and dispatching verification objects are determined sequentially based on their actual preceding references. When multiple direct preceding objects exist, the current object enters the traversal queue after all available preceding objects, allowing multiple pieces of evidence to converge at the same node. If a loop is found where an object references subsequent nodes, the system stops advancing the corresponding branch and records the loop edge as an illegal causal reference, forcibly eliminating the loop without using a timestamp.
[0077] When traversing nodes, the replay reconstructor reads the contents of historical objects according to the specified object version or integrity summary referenced in the preceding sequence. For example, when E-ADV-031-V1 references E-CTX-031-V1, the system restores the fact source, observation status, and missing markers from version V1, without reading the subsequently formed context V2. When restoring E-APR-031-V1, it also retrieves the verification receipt version, approval status, and action intent summary displayed during manual review; when restoring E-DSP-031-V1, it retrieves the real-time object version and version source used for dispatch verification. If a specified historical version is no longer readable, a version missing placeholder node is retained and cannot be replaced by the latest version.
[0078] The replay reconstructor organizes the recovered stage evidence, processing status, and version information from each node into a processing dependency graph according to a causal hierarchy. Nodes represent typed evidence objects, causal edges represent direct evidence, and action root objects and closed-state objects serve as the entry and result of the processing path. Object timestamps are appended to node attributes to observe processing intervals and cross-node time deviations, but do not participate in causal edge generation. Therefore, even if an object is written later due to network latency, it will still be displayed according to its true dependency position as long as its reference relationship is correct.
[0079] Furthermore, after reconstructing dependencies, the system reads the cross-stage verification result CR-031 and maps the object identifier and preceding reference carried by each verification record to the corresponding node or causal edge. When the approved object is missing, a missing placeholder node is displayed between the verification receipt and the dispatched verification object, and this position is marked as an object missing; when the approved object exists but does not reference the verification receipt, the two are marked as a broken edge; when E-APR-031-V1 is associated with DG-032, the approval node and its incoming edge are marked as intent conflict; when dispatch verification uses V27 but approval is bound to V26, the corresponding causal edge is marked as version conflict. When the sending evidence exists but there is no verifiable result evidence, an unknown node is generated at the end of the path and associated with OPEN_UNKNOWN.
[0080] In a specific example, taking the object missing test as an example, the replay path shows ROOT-031, E-CTX-031-V1, E-ADV-031-V1, E-CHK-031-V1, the missing approval node, and E-DSP-031-V1. The system locates the anomaly reference position after E-CHK-031-V1 and before E-DSP-031-V1, and associates it with OPEN_MISSING and the corresponding rule number. If there are version conflicts on the same path, the replay result also retains the conflicting edges, without overwriting other anomalies with the main closure state. For new states formed after reconciliation, the system displays the change from OPEN_UNKNOWN to CLOSED_SUCCEEDED according to the state version, and retains the reconciliation evidence object that caused the state change.
[0081] The final decision debriefing result RP-031 includes action root information, standardized action intent, causal hierarchy structure, historical evidence for each stage, cross-stage verification results, closure status, and anomaly location index. The debriefing interface allows users to jump from anomaly locations to related object versions and direct preceding evidence. During export, unnecessary fields are hidden according to access levels, without altering the causal relationships between objects. Through this method, the debriefing result not only reconstructs the processes that occurred at each stage but also displays the object versions upon which each process was actually based, and accurately locates missing nodes, conflict edges, and unknown endpoints.
[0082] In some embodiments, after generating the decision review results, the method further includes: When the abnormal state in the decision review results meets the preset compensation conditions, a compensation action is generated according to the corresponding abnormal reference position and typed evidence object. A compensation action root object is created for the compensation action and a compensation action intent summary is generated. Establish the association between the root object of the compensation action and the root object of the original action, so that the starting evidence object of the compensation action references the typed evidence object corresponding to the abnormal reference position, and record the reason for the unclosed original candidate action. Establish independent causal reference relationships according to the processing progress of the compensation action, perform cross-stage verification and closure state determination on the compensation action, and keep the closure state and typified evidence object of the original candidate action unchanged.
[0083] Specifically, this embodiment continues to use the decision review result RP-031. The review result shows that the original candidate action ACT-031 was bound to the target object version V26 during the approval stage, and obtained the real-time version V27 during the dispatch verification stage. The cross-stage verification result marked the corresponding causal edge as a version conflict. The subsequent adjustment of the reconciliation evidence confirmation parameters has produced external effects, but these effects are not formed on the object version used at the time of approval. Therefore, the original action remains OPEN_CONFLICT. The compensation evaluator reads the abnormal state, the abnormal reference location, and the associated evidence object to determine whether an independent compensation action needs to be established.
[0084] The system pre-configures compensation conditions, which at least specify whether the abnormal state has a compensable external effect, whether the compensation target can be determined, and whether the compensation operation has achieved the necessary decisions. In this example, the reconciliation evidence confirms the external effect, the abnormal location is between the approval evidence object E-APR-031-V1 and the dispatch verification object E-DSP-031-V1, and the manual reconciliation object records the compensation decision to restore the safety threshold, thus satisfying the compensation conditions. If the external effect is still unknown, or there is a lack of evidence to determine the recovery target, the system only maintains the reconciliation status and does not automatically generate compensation actions that may cause secondary impacts.
[0085] Once the compensation conditions are met, the compensation generator retrieves E-APR-031-V1, E-DSP-031-V1, and corresponding accounting evidence from the abnormal reference location. It then extracts the parameter changes that have occurred, the current version of the target object, its recoverable state, and compensation constraints, generating the compensation action ACT-CMP-031. This compensation action restores the target object from its abnormally altered state to a verified safe state, without directly copying the original action content. The system assigns a new global event identifier EVT-CMP-031 to ACT-CMP-031 and creates a compensation action root object ROOT-CMP-031, giving the compensation process independent object ownership and state space.
[0086] The compensation generator aligns and deterministically encodes the compensation target, recovery parameters, applicable version, execution boundaries, and result constraints according to the compensation intent field structure, forming standardized compensation intent data. It then calculates the compensation action intent summary DG-CMP-031. Because the execution direction, parameters, and version conditions of the compensation action differ from the original action, DG-CMP-031 is not reused. The system writes the compensation action, the compensation action intent summary, and the context version used when forming the compensation action into ROOT-CMP-031.
[0087] When establishing a cross-action association, the system records the original action root object ROOT-031, the original action intent summary DG-031, the original closed state version, the reason for not closing, and the decision review result version in ROOT-CMP-031. This association is used to explain the source of compensation and does not merge two actions into the same action root. The initial context evidence object E-CMP-CTX-031-V1 of the compensation action references the E-DSP-031-V1 and its integrity summary corresponding to the anomaly location, and includes version conflict records between E-APR-031-V1 and E-DSP-031-V1, so that subsequent reviews can confirm which external effect and anomaly the compensation is based on.
[0088] Subsequently, the system generates compensation suggestion objects, compensation verification receipts, compensation manual decisions, compensation distribution verification, and compensation result evidence according to the processing progress of the compensation action. Each subsequent object is associated with ROOT-CMP-031 and DG-CMP-031, and references the directly preceding object actually used. Before compensation distribution, the real-time version of the target object is obtained again. If the real-time version has changed, a version incompatibility state is generated and the original compensation approval is discontinued. Version verification requirements are not lowered due to the clear purpose of compensation.
[0089] The compensation evidence chain uses independent rules for required objects, state transition relationships, and closure conditions. ROOT-CMP-031 can indicate successful or failed compensation closure when all required objects are complete, causal references are consistent, and the compensation result forms a verifiable final state. If the receipt is missing, there is a version conflict, or the result cannot be confirmed, the compensation action remains in the corresponding unclosed state. Successful compensation action closure only indicates that the compensation process has been verified; it does not rewrite ROOT-031's OPEN_CONFLICT to indicate the original action was successful.
[0090] The object storage layer prohibits the compensation process from updating existing typed evidence objects under ROOT-031. The original action only adds a compensation-related index pointing to ROOT-CMP-031 for reviewing subsequent actions during debriefing; it does not change the original action's evidence content, anomalous edges, or closure status. If compensation fails or requires further processing, the system will create a new subsequent action based on the new anomalous evidence to avoid cyclically overwriting historical records.
[0091] In this embodiment, the external effect confirmation and compensation results are illustrated using simulated contract data to explain the object relationships. By establishing independent action roots, intent summaries, and evidence chains for the compensation actions, and simultaneously referencing the original action's abnormal evidence, the system can review the basis for compensation formation and the execution process, while ensuring that the fact that the original action was not closed is not obscured by the subsequent compensation results.
[0092] The following are system embodiments of this application, which can be used to execute the method embodiments of this application. For details not disclosed in the system embodiments of this application, please refer to the method embodiments of this application.
[0093] Figure 2 This is a schematic diagram of the structure of the system for determining the closure of action intent-based evidence and reviewing decisions, provided in an embodiment of this application. Figure 2 As shown, the system includes: The acquisition module 201 is used to acquire candidate actions and decision context, create action root objects, standardize the intent elements of candidate actions, and generate action intent summaries associated with action root objects. The association module 202 is used to generate typed evidence objects according to the processing progress of candidate actions, so that the typed evidence objects are associated with the root object of the action and the action intent summary, and subsequent evidence objects reference the identifier and version or integrity summary of the directly preceding evidence object, forming a causal reference relationship. The generation module 203 is used to verify the existence status of the necessary evidence objects and the reference matching status of the evidence objects before and after the cause-and-effect relationship, and to generate cross-stage verification results based on the action intent summary, object version and evidence status of the evidence objects before and after the cause-and-effect relationship. The determination module 204 is used to determine the closure state of the candidate action based on the cross-stage verification results and preset closure conditions. When the evidence object or causal reference is missing, the action intent or object version conflicts, or the evidence state cannot be confirmed, the candidate action is determined to be in an unclosed state. Output module 205 is used to reconstruct the processing dependency relationship of the evidence object from the root object of the action along the causal reference relationship, output the closed state and locate the abnormal reference position corresponding to the unclosed state, and generate the decision review result.
[0094] In some embodiments, Figure 2 The acquisition module 201 assigns a global event identifier to the candidate action, creates an action root object based on the global event identifier, and establishes an association between the candidate action and the decision context and its version on which the candidate action is based. It extracts intent elements from the candidate action and the decision context to limit the semantics of the action execution, aligns the intent elements according to the preset intent field structure and performs deterministic encoding to form normalized intent data. It performs a summary operation on the normalized intent data to generate an action intent summary, writes the action intent summary and the version reference of the decision context into the action root object, and establishes a binding relationship between the action intent summary and the candidate action.
[0095] In some embodiments, Figure 2The association module 202 establishes evidence object type constraints based on the processing stages and corresponding processing functions of candidate actions, obtains stage information formed in each processing stage that can characterize the processing basis and processing status, and encapsulates the stage information into typed evidence objects with object identifiers and object versions according to the evidence object type constraints; writes the identifier of the root object of the action and the action intent summary into each typed evidence object, and establishes the attribution relationship between typed evidence objects and candidate actions; determines the direct preceding evidence object based on the actual evidence basis used when forming the subsequent evidence object, and writes the identifier and object version or integrity summary of the direct preceding evidence object into the reference field of the subsequent evidence object, forming a causal reference relationship from the direct preceding evidence object to the subsequent evidence object.
[0096] In some embodiments, Figure 2 The generation module 203 determines the necessary evidence objects based on the processing stage constraints of the candidate actions, retrieves each necessary evidence object and its direct preceding evidence object along the causal reference relationship, and determines the existence state of the necessary evidence objects; it parses the reference field of the subsequent evidence object, matches the corresponding preceding object reference with the actual obtained direct preceding evidence object, and determines the reference matching state in combination with the evidence object type; it compares the action intent summary associated with the preceding and following evidence objects, verifies the object version and evidence state according to the preset version constraints and state transition relationship, associates the corresponding verification results with the existence state and reference matching state, and generates cross-stage verification results.
[0097] In some embodiments, Figure 2 The generation module 203 identifies duplicate evidence objects based on the idempotency identifier and the type of evidence object, and compares the integrity summary and causal reference of the duplicate evidence objects. When the integrity summary and causal reference are consistent, the duplicate evidence objects are marked as idempotent duplicates, merged into the same logical evidence object, and the existing causal reference is maintained. When the integrity summary or causal reference is inconsistent, the duplicate evidence objects are marked as conflict objects, the abnormal reference position corresponding to the conflict object is determined, and the corresponding conflict state is written into the cross-stage verification result.
[0098] In some embodiments, Figure 2 The determination module 204 extracts verification rules for the necessary evidence object, causal reference, and verifiable final state from the preset closure conditions, matches the cross-stage verification results with the verification rules, and determines the closure condition matching state. When the closure condition matching state indicates that the necessary evidence object is complete, the causal reference is consistent, and the evidence state forms a verifiable final state, the candidate action is determined as a closed state, and the closure success or failure is determined according to the verifiable final state. When the closure condition matching state fails, the reason for non-closure is determined according to the failed verification rules, and an unclosed state corresponding to missing, conflicting, or unconfirmable states is generated according to the anomaly type mapping rules. Before the verifiable final state is formed, the candidate action is prohibited from being determined as a successful closure.
[0099] In some embodiments, Figure 2 The determination module 204 generates a reconciliation task based on the reasons for the unclosed state and the current causal reference relationship, and queries the corresponding external processing results according to the idempotency identifier configured for the candidate actions. When feedback that can confirm the processing result is obtained, a reconciliation evidence object that references the current direct preceding evidence object is generated, the reconciliation evidence object is included in the causal reference relationship, and cross-stage verification and closure state determination are re-executed. When no feedback that can confirm the processing result is obtained, the unclosed state is maintained, a manual reconciliation object that records the reconciliation basis and processing decision is generated, and the existing typed evidence object remains unchanged.
[0100] In some embodiments, Figure 2 The output module 205 uses the root object of the action and the action intent summary as search conditions to obtain the typified evidence objects belonging to the candidate actions, and parses the preceding object references recorded in each typified evidence object record. Starting from the root object of the action, it traverses each typified evidence object according to the causal hierarchy determined by the preceding object references, restores the corresponding object version and the stage evidence used when forming the typified evidence object, and reconstructs the processing dependency relationship. It maps the cross-stage verification results to the processing dependency relationship, determines the abnormal reference position of the evidence object or causal reference that failed the verification in the processing dependency relationship, associates the abnormal reference position, the corresponding abnormal state and the closure state, and generates the decision review result.
[0101] In some embodiments, Figure 2 When the abnormal state in the decision review result meets the preset compensation conditions, the output module 205 generates a compensation action based on the corresponding abnormal reference position and typed evidence object, creates a compensation action root object for the compensation action and generates a summary of the compensation action intent; establishes the association between the compensation action root object and the original action root object, so that the starting evidence object of the compensation action references the typed evidence object corresponding to the abnormal reference position, and records the reason for the unclosed state of the original candidate action; establishes an independent causal reference relationship according to the processing process of the compensation action, performs cross-stage verification and closure state determination on the compensation action, and keeps the closure state and typed evidence object of the original candidate action unchanged.
[0102] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments.
[0103] Figure 3 This is a schematic diagram of the electronic device 3 provided in an embodiment of this application. Figure 3As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various system embodiments described above.
[0104] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or different components.
[0105] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
[0106] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 3. The memory 302 can also include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device.
[0107] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0108] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which may be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.
[0109] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.
Claims
1. A method for determining the closure of evidence and reviewing decisions based on action intent, characterized in that, include: Obtain candidate actions and decision contexts, create action root objects, normalize the intent elements of the candidate actions, and generate action intent summaries associated with the action root objects; Generate a typed evidence object according to the processing progress of the candidate action, associate the typed evidence object with the action root object and the action intent summary, and make subsequent evidence objects reference the identifier and version or integrity summary of the directly preceding evidence object to form a causal reference relationship; The existence status of the necessary evidence objects and the reference matching status of the preceding and following evidence objects are verified along the causal reference relationship. Cross-stage verification results are generated based on the action intent summary, object version and evidence status of the preceding and following evidence objects. The closure state of the candidate action is determined based on the cross-stage verification results and the preset closure conditions. When the evidence object or causal reference is missing, the action intent or object version conflicts, or the evidence state cannot be confirmed, the candidate action is determined to be in an unclosed state. Starting from the root object of the action, the processing dependency relationship of the evidence object is reconstructed along the causal reference relationship, the closed state is output and the abnormal reference position corresponding to the unclosed state is located, and the decision review result is generated.
2. The method according to claim 1, characterized in that, The steps of obtaining candidate actions and decision contexts, creating action root objects, standardizing the intent elements of the candidate actions, and generating action intent summaries associated with the action root objects include: Assign a global event identifier to the candidate action, create an action root object based on the global event identifier, and associate the candidate action with the decision context and its version on which the candidate action is based. Intent elements for defining the semantics of action execution are extracted from the candidate actions and decision context. The intent elements are then aligned and deterministically encoded according to a preset intent field structure to form standardized intent data. Perform a digest operation on the normalized intent data to generate an action intent digest, write the action intent digest and the version reference of the decision context into the action root object, and establish a binding relationship between the action intent digest and the candidate action.
3. The method according to claim 1, characterized in that, The process of generating typed evidence objects according to the processing progress of the candidate actions, associating the typed evidence objects with the action root object and the action intent summary, and making subsequent evidence objects reference the identifier and version or integrity summary of the directly preceding evidence object to form a causal reference relationship includes: Based on the processing stages and corresponding processing functions of the candidate actions, establish evidence object type constraints, obtain stage information formed in each processing stage that can characterize the processing basis and processing status, and encapsulate the stage information into a typed evidence object with an object identifier and an object version according to the evidence object type constraints. Write the identifier and action intent summary of the root object of the action into each of the typified evidence objects to establish the attribution relationship between the typified evidence objects and the candidate actions; Based on the evidence actually used when forming the subsequent evidence object, the direct preceding evidence object is determined, and the identifier and object version or integrity summary of the direct preceding evidence object are written into the reference field of the subsequent evidence object, thus forming a causal reference relationship from the direct preceding evidence object to the subsequent evidence object.
4. The method according to claim 1, characterized in that, The verification of the existence status of necessary evidence objects and the reference matching status of preceding and following evidence objects along the causal reference relationship generates cross-stage verification results based on the action intent summary, object version, and evidence status of preceding and following evidence objects, including: The necessary evidence objects are determined based on the processing stage constraints of the candidate actions, and each necessary evidence object and its direct predecessor evidence object are retrieved along the causal reference relationship to determine the existence status of the necessary evidence objects. Parse the reference field of the subsequent evidence object, match the corresponding preceding object reference with the actual obtained direct preceding evidence object, and determine the reference matching status based on the evidence object type; Compare the action intent summaries associated with the evidence objects before and after, verify the object version and evidence status according to the preset version constraints and state transition relationships, associate the corresponding verification results with the existence status and reference matching status, and generate cross-stage verification results.
5. The method according to claim 4, characterized in that, The process of generating cross-stage verification results also includes: Identify duplicate evidence objects based on idempotency identifiers and evidence object types, and compare the integrity summary and causal references of the duplicate evidence objects. When the integrity summary and causal reference are consistent, the duplicate evidence objects are marked as idempotent duplicates, merged into the same logical evidence object, and the existing causal references are maintained. When the integrity summary or causal reference is inconsistent, the duplicate evidence object is marked as a conflict object, the abnormal reference position corresponding to the conflict object is determined, and the corresponding conflict state is written into the cross-stage verification result.
6. The method according to claim 1, characterized in that, The step of determining the closed state of the candidate action based on the cross-stage verification results and preset closure conditions, and determining the candidate action as unclosed when the evidence object or causal reference is missing, the action intent or object version conflicts, or the evidence state cannot be confirmed, includes: Extract verification rules for necessary evidence objects, causal references, and verifiable final states from the preset closure conditions, match the cross-stage verification results with the verification rules, and determine the closure condition matching status. When the closure condition matching state characterizes the completeness of the required evidence object, the consistency of causal references, and the evidence state forming a verifiable final state, the candidate action is determined as a closed state, and the closure is determined to be successful or unsuccessful based on the verifiable final state. When the closure condition matching state fails, the reason for non-closure is determined according to the failure verification rule, and an unclosed state corresponding to missing, conflict or unconfirmable is generated according to the exception type mapping rule. Before a verifiable final state is formed, the candidate action is prohibited from being determined as a successful closure.
7. The method according to claim 6, characterized in that, After the candidate action is determined to be an unclosed state corresponding to the evidence state that cannot be confirmed, the following is also included: A reconciliation task is generated based on the unclosed reasons and the current causal reference relationship, and the corresponding external processing result is queried according to the idempotency flag configured for the candidate action; When feedback confirming the processing result is obtained, a reconciliation evidence object is generated that references the current direct preceding evidence object. The reconciliation evidence object is then incorporated into the causal reference relationship, and cross-stage verification and closure state determination are re-executed. When no feedback confirming the processing result is obtained, the unclosed state is maintained, a manual reconciliation object is generated to record the reconciliation basis and processing decision, and the existing typed evidence object remains unchanged.
8. The method according to claim 1, characterized in that, Starting from the root object of the action, the process of reconstructing the processing dependencies of the evidence object along the causal reference relationship, outputting the closed state and locating the abnormal reference position corresponding to the unclosed state, and generating decision review results includes: Using the root object of the action and the action intent summary as search criteria, obtain the typified evidence objects belonging to the candidate actions, and parse the preceding object references of each typified evidence object record; Starting from the root object of the action, traverse each typed evidence object according to the causal hierarchy determined by the reference of the preceding object, restore the corresponding object version and the stage evidence used when forming the typed evidence object, and rebuild the processing dependency relationship; The cross-stage verification results are mapped to the processing dependencies. The abnormal reference positions of the evidence objects or causal references that failed the verification are determined in the processing dependencies. The abnormal reference positions, corresponding abnormal states, and closure states are associated to generate decision review results.
9. The method according to claim 8, characterized in that, After generating the decision review results, the following is also included: When the abnormal state in the decision review result meets the preset compensation condition, a compensation action is generated according to the corresponding abnormal reference position and typed evidence object. A compensation action root object is created for the compensation action and a compensation action intent summary is generated. Establish the association between the root object of the compensation action and the root object of the original action, so that the starting evidence object of the compensation action references the typed evidence object corresponding to the abnormal reference position, and record the reason for the unclosed original candidate action. Establish an independent causal reference relationship according to the processing progress of the compensation action, perform cross-stage verification and closure state determination on the compensation action, and keep the closure state and typed evidence object of the original candidate action unchanged.
10. A system for determining the closure of evidence and reviewing decisions based on action intent, characterized in that, include: The acquisition module is used to acquire candidate actions and decision context, create an action root object, standardize the intent elements of the candidate actions, and generate an action intent summary associated with the action root object. The association module is used to generate typed evidence objects according to the processing progress of the candidate actions, associate the typed evidence objects with the root object of the action and the action intent summary, and make subsequent evidence objects reference the identifier and version or integrity summary of the directly preceding evidence object to form a causal reference relationship. The generation module is used to verify the existence status of the necessary evidence objects and the reference matching status of the evidence objects before and after the causal reference relationship, and to generate cross-stage verification results based on the action intent summary, object version and evidence status of the evidence objects before and after the causal reference relationship. The determination module is used to determine the closure state of the candidate action based on the cross-stage verification results and preset closure conditions. When the evidence object or causal reference is missing, the action intent or object version conflicts, or the evidence state cannot be confirmed, the candidate action is determined to be in an unclosed state. The output module is used to reconstruct the processing dependency relationship of the evidence object from the root object of the action along the causal reference relationship, output the closed state and locate the abnormal reference position corresponding to the unclosed state, and generate the decision review result.