Ai system structure event element generation, identification, write-back and rollback method and system

Abstract

The application provides an AI system structure event element generation, identification, write-back and rollback method and system, relates to the technical field of artificial intelligence, and comprises the following steps: receiving event trigger data and obtaining event analysis results by analysis; identifying associated objects and determining an event associated range; obtaining a previous state and a subsequent state, generating a state difference; determining a phase context according to a processing stage, a version state, an evidence state, a variable state, a risk state and a responsibility state, determining a holding time according to a holding condition of the state difference, and determining a feedback effect according to an influence of the state difference on subsequent output, variable calling, task path, evidence support, multi-modal mapping, risk disposal, samples and responsibility chains; judging whether to generate a structure event element according to the feedback effect, forming a structure event element record when the structure event element is generated, and writing back according to a write-back target; and performing degradation, freezing, withdrawal, version recovery, failure sample writing or responsibility log updating when a rollback rule is met.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a method and system for generating, recognizing, writing back, and rolling back AI system structural event elements. Background Technology

[0002] With the development of large language models, multimodal models, retrieval-enhanced generation systems, AI agent systems, personal AI assistants, enterprise knowledge base systems, and AI evaluation systems, the application forms of artificial intelligence systems have gradually expanded from single-question-and-answer interactions to complex scenarios such as long-term collaboration, knowledge governance, task execution, tool invocation, multimodal analysis, risk assessment, and real-world feedback. In these scenarios, AI systems not only need to generate answers but also continuously process information such as user feedback, changes in evidence, task status, external tool results, knowledge base updates, multimodal object mapping, and risk management outcomes. This information often affects subsequent system outputs, variable calls, task paths, knowledge status, and accountability records. Therefore, how to structurally identify, record, write back, roll back, and audit key state changes during long-term operation has become a crucial technical issue for the continuous and reliable operation of AI systems.

[0003] In existing technologies, some AI systems are already able to save interaction content, search results, generated results, tool invocation processes, and some user preferences through methods such as context windows, session history, log systems, vector databases, knowledge base version management, task status recording, user feedback collection, or memory modules. For example, RAG systems can typically record retrieved documents and their citation relationships, AI Agent systems can record task steps and tool invocation results, personal AI assistants can save some user memories, enterprise knowledge base systems can maintain document versions and access records, and AI evaluation systems can collect model outputs and evaluation results. These technologies, to a certain extent, support information retention, context reuse, task tracking, and result evaluation.

[0004] However, existing technologies primarily store user confirmations, evidence changes, variable updates, task failures, multimodal conflicts, tool anomalies, expert rejections, knowledge base version updates, or external system feedback as ordinary messages, logs, or feedback, lacking a unified structured event identification mechanism for system state impact. Furthermore, existing technologies often struggle to determine whether a change has affected subsequent outputs, variable calls, task paths, evidence support, multimodal mapping, risk management, or chains of responsibility, and also find it difficult to reliably calculate state differences before and after an event. Moreover, existing technologies lack mechanisms for phase context assessment, hold-time assessment, feedback effect assessment, and write-back target selection, making it prone to mistakenly writing temporary information as long-term variables, or omitting, overwriting, or incorrectly writing back confirmed long-term states. Summary of the Invention

[0005] To address the shortcomings of existing technologies that primarily store user confirmations, evidence changes, variable updates, task failures, multimodal conflicts, tool anomalies, expert rejections, knowledge base version updates, or external system feedback as ordinary messages, logs, or feedback, lacking a unified structural event identification mechanism that addresses the impact on system state, this invention provides a method and system for generating, identifying, writing back, and rolling back structural event elements in an AI system. Furthermore, existing technologies often struggle to determine whether a change has affected subsequent outputs, variable calls, task paths, evidence support, multimodal mapping, risk management, or chains of responsibility, and also find it difficult to reliably calculate state differences before and after an event. Moreover, existing technologies lack mechanisms for phase context assessment, hold-time assessment, feedback effect assessment, and write-back target selection, making it prone to miswriting temporary information as long-term variables or omitting, overwriting, or incorrectly writing back confirmed long-term states.

[0006] The technical solutions provided by the embodiments of the present invention are as follows: First aspect: This invention provides a method for generating, recognizing, writing back, and rolling back AI system structural event elements. The method is executed by at least one processor and includes: Receive event trigger data and parse the event trigger data to obtain the event parsing result; Identify associated objects based on the event parsing results, and generate or call object identifiers; The scope of the event association is determined based on the object identifier; Obtain the previous and subsequent states corresponding to the event association range, and generate state differences based on the previous and subsequent states; The phase context is determined based on the processing stage, version status, evidence status, variable status, risk status, and responsibility status corresponding to the event association scope. The retention time is determined based on the retention conditions of the aforementioned state differences in the session cycle, task cycle, project cycle, variable life cycle, review cycle, and freeze cycle; The feedback effect is determined based on the impact of the state differences on subsequent outputs, variable calls, task paths, evidence support, multimodal mapping, risk handling, failure samples, evaluation samples, or chains of responsibility. Based on the state difference, phase context, hold time, and feedback effect, determine whether to generate a structured event element; if so, determine the write-back target from the pre-set write-back target rules based on the event type, risk level, hold time, feedback effect, or responsibility status, generate an event identifier, and form a structured event element record. The structured event element record includes the event type, object identifier, state difference, phase context, hold time, feedback effect, write-back target, rollback rules, and responsibility log; otherwise, record the state difference as temporary context information or ordinary log, and end the structured event element write-back process for the state difference. After the structured event meta record is formed, the structured event meta write-back is performed according to the write-back target; When the rollback rules are met, the structure event element or the target data affected by the structure event element is downgraded, frozen, withdrawn, restored to a version, written to a failure sample, or updated in the responsibility log.

[0007] The second aspect: This invention provides an AI system architecture event meta-generation, recognition, write-back, and rollback system, comprising: An event parsing unit is used to receive event trigger data and parse the event trigger data to obtain event parsing results; The object and scope determination unit is used to identify associated objects based on the event parsing results, generate or call object identifiers, and determine the event association scope based on the object identifiers and the event parsing results; The state difference processing unit is used to obtain the previous state and the subsequent state corresponding to the event association range, generate a state difference based on the previous state and the subsequent state, and determine the phase context based on the processing stage, version state, evidence state, variable state, risk state or responsibility state corresponding to the event association range. The feedback judgment unit is used to determine the retention time based on the retention conditions of the state difference in the session cycle, task cycle, project cycle, variable life cycle, review cycle or freeze cycle, and to determine the feedback effect based on the impact of the state difference on subsequent output, variable call, task path, evidence support, multimodal mapping, risk handling, failure samples, evaluation samples or chain of responsibility. The event judgment and recording unit is used to determine whether to generate a structured event element based on the state difference, the phase context, the hold time, and the feedback effect. If so, it determines the write-back target from the pre-set write-back target rules based on the event type, risk level, hold time, feedback effect, or responsibility status, generates an event identifier, and forms a structured event element record. The structured event element record includes the event type, object identifier, state difference, phase context, hold time, feedback effect, write-back target, rollback rules, and responsibility log. Otherwise, it records the state difference as temporary context information or a regular log and terminates the structured event element write-back process for the state difference. The write-back and rollback unit is used to perform structure event element write-back according to the write-back target after the structure event element record is formed, and to perform downgrading, freezing, retraction, version recovery, failure sample writing or responsibility log update on the structure event element or the target data affected by the structure event element when the rollback rules are met. The event chain and evaluation unit is used to generate an event chain based on multiple structured event elements, and to evaluate the event identification, state difference judgment, phase context judgment, hold time judgment, feedback effect judgment, write-back target selection, rollback rule execution, or responsibility log integrity of the structured event elements.

[0008] Third aspect: This invention provides an AI system structural event element generation, identification, write-back, and rollback device, comprising: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor. When the computer program is executed by the at least one processor, it causes the at least one processor to perform the AI ​​system architecture event element generation, identification, write-back and rollback method as described in the first aspect.

[0009] Fourth aspect: The present invention provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the AI ​​system structure event element generation, identification, write-back and rollback method as described in the first aspect.

[0010] Fifth aspect: The present invention provides a computer program product, characterized in that: The computer program product includes a computer program that, when executed by a processor, implements the AI ​​system architecture event element generation, recognition, write-back, and rollback method as described in the first aspect.

[0011] The beneficial effects of the technical solutions provided by the embodiments of the present invention include at least the following: (1) By parsing the event trigger data, identifying the associated objects and the scope of event association, and obtaining the state before the event and the state after the event, generating state differences, the AI ​​system can identify changes in ordinary inputs, ordinary feedback or ordinary logs that have subsequent system impact as structural event elements, thereby solving the problems of difficult identification of structural changes, difficult recording of state differences and easy submersion of key changes in ordinary logs in the existing AI system.

[0012] (2) By determining the phase context, holding time and feedback effect corresponding to the structural event element, it is possible to determine whether the event should be temporarily retained, written back, frozen, reviewed, rolled back or entered into the failure sample library according to the draft stage, generation stage, execution stage, feedback stage, review stage, freeze stage, rollback stage or evaluation stage in which the event is located. This solves the problems of difficult phase context determination, difficult holding time distinction and difficult feedback effect evaluation in the existing AI system, avoids temporary content being mistakenly written as long-term variables, and also avoids long-term confirmed content being omitted, covered or rolled back incorrectly.

[0013] (3) By setting write-back targets and rollback rules, different types of structural event elements can be written to corresponding locations such as the object library, claim library, evidence chain library, variable library, task library, multimodal mapping library, feedback library, risk library, failure sample library, evaluation sample library, or responsibility log library, thereby solving the problems of difficulty in selecting write-back targets, incorrect write-back locations, inconsistent states of multiple modules, and lack of rollback rules in existing AI systems. When an event error, evidence reversal, variable pollution, task failure, modal conflict escalation, risk increase, or user withdrawal of confirmation is detected, the system can perform downgrading, freezing, withdrawal, version restoration, failure sample writing, or responsibility log update to avoid the error state from continuously affecting subsequent output, task path, variable call, evidence support, and risk handling. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a flowchart illustrating a method for generating, recognizing, writing back, and rolling back AI system structural event elements, provided in an embodiment of the present invention.

[0016] Figure 2 This is a structural diagram of the core fields of a structural event element provided in an embodiment of the present invention.

[0017] Figure 3 This invention provides an event triggering data and associated object identification diagram.

[0018] Figure 4 This invention provides a state difference, phase context, hold time, and feedback effect judgment diagram.

[0019] Figure 5 This is a structural event element generation condition judgment diagram provided in an embodiment of the present invention.

[0020] Figure 6 This invention provides an event type and write-back target mapping diagram.

[0021] Figure 7 This invention provides a rollback rule and risk handling flowchart for an embodiment of the invention.

[0022] Figure 8 This is an event chain generation and failure sample transformation diagram provided in an embodiment of the present invention.

[0023] Figure 9 This is a structural event element evaluation and report generation diagram provided in an embodiment of the present invention.

[0024] Figure 10 This is a diagram illustrating the overall architecture of an AI system for generating, recognizing, writing back, and rolling back event elements, provided as an embodiment of the present invention. Detailed Implementation

[0025] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0026] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0027] Example 1 Reference manual attached Figure 1 The diagram illustrates a flowchart of an AI system structure event element generation, identification, write-back, and rollback method provided by an embodiment of the present invention.

[0028] This invention provides a method for generating, recognizing, writing back, and rolling back AI system structure event elements. This method can be implemented by a device for generating, recognizing, writing back, and rolling back AI system structure event elements, which can be a terminal or a server. The processing flow of this method may include the following steps: Reference manual attached Figure 2 The diagram illustrates a core field structure of a structural event element provided by an embodiment of the present invention.

[0029] Receive event trigger data, parse the event trigger data, and obtain the event parsing result.

[0030] In some embodiments, event-triggered data includes at least one of user input, model output, knowledge base retrieval results, RAG response results, tool call results, multimodal input, task execution results, user feedback, expert review results, experimental results, incident samples, external system feedback, or historical log records. Event parsing results include source information, version information, timestamps, object candidates, claim candidates, variable candidates, task status, modal objects, feedback types, risk markers, or responsibility records.

[0031] It should be noted that the system can perform preprocessing on event-triggered data. Preprocessing includes at least one of the following: format parsing, source identification, version identification, timestamp extraction, permission identification, object candidate identification, claim candidate identification, variable candidate identification, task status identification, multimodal object identification, feedback type identification, risk marker identification, or responsibility record identification.

[0032] Reference manual attached Figure 3 This illustrates an event-triggered data and associated object identification diagram provided by an embodiment of the present invention.

[0033] Identify associated objects based on event parsing results, and generate or call object identifiers.

[0034] In some embodiments, when identifying associated objects, the current object is determined to be an existing object, a newly added object, an object mismatch object, a boundary conflict object, or an object to be reviewed based on the object name, object alias, object type, object context, historical object record, source version, timestamp, multimodal features, task identifier, or project identifier.

[0035] Optionally, the system determines whether the current object is an existing object based on the object name, object alias, object type, object context, historical object records, source version, timestamp, multimodal characteristics, task identifier, or project identifier. If the system determines that the current object and a historical object are the same object, it uses the existing object identifier. If the system determines that the current object is a new object, it generates a new object identifier. If the system determines that there is an object mismatch, object boundary conflict, or object uncertainty, it marks the object as pending review.

[0036] In this embodiment of the invention, by combining multi-dimensional information such as object name, contextual features, historical records, version information, and multimodal features to identify associated objects and generating or calling unique object identifiers, the accuracy of matching event data with actual objects can be improved, reducing object mismatch problems caused by duplicate object names, object evolution, version changes, or unclear boundaries. Simultaneously, by distinguishing and managing newly added objects, conflicting objects, and objects awaiting review, continuous tracking and dynamic maintenance of object status can be achieved, providing an accurate object foundation for subsequent claims association, evidence management, variable invocation, task execution, and risk control.

[0037] Determine the scope of the event association based on the object identifier.

[0038] In some embodiments, the event association scope includes at least one of the following: object association scope, claim association scope, evidence association scope, variable association scope, task association scope, modal object association scope, feedback association scope, risk association scope, or liability record association scope.

[0039] For example, when the event trigger data is a user confirming a project title, the event's associated scope can include the project object, title variable, related tasks, and user confirmation records. When the event trigger data is a new version of a document entering the knowledge base, the event's associated scope can include the source document, version status, cited fragments, related claims, evidence support, and accountability log. When the event trigger data is a tool call failure, the event's associated scope can include the task identifier, step identifier, tool execution record, reason for failure, task path status, and future output limitations.

[0040] Reference manual attached Figure 4 This diagram illustrates a judgment graph of state difference, phase context, hold time, and feedback effect provided by an embodiment of the present invention.

[0041] Obtain the preceding and following states corresponding to the scope of the event association, and generate state differences based on the preceding and following states.

[0042] It should be noted that the pre-state can be the state stored in the object library, claim library, evidence chain library, variable library, task library, multimodal mapping library, feedback library, risk library, failure sample library, evaluation sample library, or responsibility log library before the event occurs. The post-state can be a new state obtained based on the parsing of event-triggered data, or a state after user confirmation, expert review, tool execution, external system return, experimental results, or risk rule processing.

[0043] In some embodiments, the pre-state includes at least one of the following: object identity state, object boundary state, claim support state, source version state, reference matching state, variable confirmation state, variable conflict state, task phase state, task path state, multimodal object mapping state, feedback result state, risk handling state, failure sample state, evaluation sample state, or chain of responsibility state before the event occurs; the post-state includes at least one of the following: object identity state, object boundary state, claim support state, source version state, reference matching state, variable confirmation state, variable conflict state, task phase state, task path state, multimodal object mapping state, feedback result state, risk handling state, failure sample state, evaluation sample state, or chain of responsibility state after the event occurs.

[0044] In some embodiments, state differences include at least one of object mismatch, object merging, object splitting, claim addition, claim downgrading, change in evidence support, change in source version, change in reference matching, variable addition, variable confirmation, variable conflict, variable freezing, task path correction, failure path suppression, multimodal conflict, feedback write-back, risk escalation, chain of responsibility completion, or failure sample transformation.

[0045] Optionally, the system can generate status differences through field-level comparisons. For example, by comparing the variable status in the previous state with the variable status in the subsequent state, if a variable changes from "candidate status" to "user confirmation status," a variable confirmation status difference is generated. If the evidence support status changes from "supported" to "version expired," an evidence downgrade status difference is generated. If the task path changes from "in execution" to "paused review," a task path correction status difference is generated.

[0046] In this embodiment of the invention, by acquiring the pre-state and post-state corresponding to the scope of an event and comparing and analyzing them to generate state differences, changes in information such as objects, claims, evidence, variables, tasks, and risks before and after the event can be accurately identified, achieving a structured record of the system's state evolution process. Through field-level state comparison, omissions and misjudgments of state changes can be reduced, improving the accuracy of event impact analysis and providing a reliable basis for subsequent structured event generation, data write-back, risk management, task adjustment, and accountability tracking.

[0047] The phase context is determined based on the processing stage, version status, evidence status, variable status, risk status, and responsibility status corresponding to the scope of the event association.

[0048] In some embodiments, the phase context includes at least one of the following: draft phase, audit phase, generation phase, execution phase, feedback phase, review phase, archiving phase, freeze phase, rollback phase, or evaluation phase.

[0049] It should be noted that phase context is used to represent the systemic significance of the same state difference at different processing stages. For example, the same state difference of "insufficient support for the claim" can trigger "reducing the strength of the conclusion" at the draft stage, "requiring supplementary evidence" at the audit stage, "freezing expression" at the public release stage, "manual review" at the review stage, and "failure sample" at the evaluation stage. Therefore, the system needs to determine whether the state difference generates a structured event element and where to write it back based on the phase context.

[0050] In this embodiment of the invention, by determining the phase context based on the processing stage, version status, evidence status, variable status, risk status, and responsibility status, the system can accurately understand the actual impact of the same state difference at different stages, and avoid misjudgment or incorrect handling of events due to different processing stages.

[0051] The retention time is determined based on the retention conditions of state differences in session cycle, task cycle, project cycle, variable life cycle, review cycle, and freeze cycle.

[0052] In some embodiments, the hold time is used to distinguish between temporary contexts, single-turn session states, multi-turn session states, task states, project states, long-term variable states, frozen states, or archived states.

[0053] Optionally, the system can determine the retention time based on the strength of user confirmation, the strength of evidence, the scope of the task's impact, the risk level, and the liability requirements. For example, temporary preferences entered casually by the user can be retained only in the current session. Explicitly confirmed project titles can be retained throughout the project lifecycle. High-risk evidence conclusions reviewed by experts can be retained until the next version update or manual review. Variables marked as risk-frozen can be retained until the rollback or unfreezing conditions are met.

[0054] In this embodiment of the invention, by determining the retention time based on the retention conditions in different lifecycles according to the state differences, it is possible to achieve hierarchical management of temporary information, task status, project variables and long-term valid status, and avoid invalid information occupying system resources for a long time or affecting subsequent decisions.

[0055] The feedback effect is determined based on the impact of state differences on subsequent outputs, variable calls, task paths, evidence support, multimodal mapping, risk management, failure samples, evaluation samples, or the chain of responsibility.

[0056] In some embodiments, the feedback effect includes at least one of the following: changing the strength of subsequent answer conclusions, changing citation requirements, changing variable access permissions, changing task paths, changing risk warning strength, triggering manual review, triggering freezing, triggering rollback, triggering failure sample writing, triggering evaluation sample generation, or triggering responsibility log updates.

[0057] Optionally, if a change does not affect subsequent output, variable calls, task paths, or risk handling, the system may not generate a structured event element, or may only record it as temporary context information. For example, if a user modifies wording in a single session but does not change project variables, the system may not generate a structured event element. Conversely, if a user explicitly denies a confirmed variable, an expert rejects key evidence, or a tool failure causes a change in the task path, a structured event element should be generated.

[0058] In this embodiment of the invention, by determining the feedback effect based on the impact of state differences on subsequent output, variable calls, task paths, evidence management, and risk handling, it is possible to accurately identify and classify events with different levels of impact, avoid unnecessary structured records due to slight information changes, and improve system operating efficiency.

[0059] Reference manual attached Figure 5 The diagram illustrates a structural event element generation condition judgment diagram provided by an embodiment of the present invention.

[0060] Based on the state difference, phase context, hold time, and feedback effect, determine whether to generate a structured event element. If so, based on the event type, risk level, hold time, feedback effect, or responsibility status, determine the write-back target from the pre-set write-back target rules, generate an event identifier, and form a structured event element record. The structured event element record includes the event type, object identifier, state difference, phase context, hold time, feedback effect, write-back target, rollback rules, and responsibility log. Otherwise, record the state difference as temporary context information or a regular log, and terminate the structured event element write-back process for the state difference.

[0061] In some embodiments, when a state difference is temporary noise, low-confidence input, unacknowledged prompt, or ordinary log that does not affect subsequent output, no structured event element is generated, or the state difference is recorded as temporary context information. When a state difference affects object identification, claim support, variable invocation, task pathing, multimodal mapping, risk handling, failure sample writing, evaluation sample generation, or chain of responsibility recording, a structured event element is generated.

[0062] In some embodiments, event types include object events, claim events, evidence events, variable events, task events, modal events, feedback events, risk events, failure sample events, evaluation events, or liability events.

[0063] Optionally, the system can set event generation conditions. Event generation conditions include: the state difference is not empty; the phase context belongs to a write-back, reviewable, freezeable, rollbackable, or evaluable phase; the retention time exceeds the temporary context threshold or meets conditions such as user confirmation, expert review, task impact, and risk level; and the feedback effect affects subsequent output, variable calls, task paths, risk handling, failure samples, evaluation samples, or the chain of responsibility.

[0064] In this embodiment of the invention, by combining state differences, phase context, hold time, and feedback effects to determine whether to generate structured event elements, intelligent filtering and structured management of event information can be achieved. This avoids data redundancy caused by a large number of invalid logs or temporary changes, and improves system resource utilization efficiency. Simultaneously, by generating structured event elements based on key changes in affected objects, claims, evidence, variables, tasks, risks, and the chain of responsibility, the evolution of important states can be accurately recorded, providing a reliable basis for subsequent data write-back, tracking analysis, rollback processing, and system optimization.

[0065] Reference manual attached Figure 6 This illustrates an event type and write-back target mapping diagram provided by an embodiment of the present invention.

[0066] Write back the target execution structure event element.

[0067] It's important to note that the write-back target is not a fixed database name, but rather a target location determined according to pre-defined write-back target rules. These pre-defined rules establish the correspondence between event types, risk levels, retention periods, feedback effects, responsibility status, and write-back targets. When generating structured event metadata records, the system can determine the write-back target from these rules based on the event type, risk level, retention period, feedback effect, or responsibility status, and incorporate the write-back target as part of the structured event metadata record.

[0068] In some embodiments, the pre-set write-back target rules are used to determine the write-back target based on the event type, risk level, retention time, feedback effect, or responsibility status. The write-back target points to at least one of the following: object library, claim library, evidence chain library, variable library, task library, multimodal mapping library, feedback library, risk library, failure sample library, evaluation sample library, or responsibility log library.

[0069] In some embodiments, when the event type is a variable event, the write-back target includes at least one of the following: variable library, user project variable library, variable version library, variable conflict record, variable freeze record, or variable rollback record.

[0070] When the event type is a task event, the write-back target includes at least one of the following: task library, step library, task path version library, failed path library, rejected path library, duplicate error suppression rule library, or task responsibility log library.

[0071] When the event type is an evidence event, the write-back target includes at least one of the following: claim library, source library, citation library, version library, evidence support library, counter-evidence record library, RAG trusted chain library, or evidence responsibility log library.

[0072] When the event type is a modal event, the write-back target includes at least one of the following: multimodal mapping library, master object library, modal object library, time alignment record, version alignment record, status observation record, modal conflict record, or review record.

[0073] When the event type is a failure sample event or an evaluation event, the write-back target includes at least one of the following: failure sample library, error type library, regression test sample library, evaluation sample library, suppression rule library, model hint strategy library, or evaluation log library.

[0074] In this embodiment of the invention, by determining the corresponding write-back target based on event type, risk level, retention time, feedback effect, and responsibility status, and writing the structured event elements into the matching data management module, accurate archiving and associated maintenance of different types of event information can be achieved, avoiding scattered or erroneous event data writing. Simultaneously, employing a differentiated write-back mechanism for different objects such as variables, tasks, evidence, multimodal objects, failure samples, and evaluation results can improve the accuracy and traceability of system status updates.

[0075] Reference manual attached Figure 7 The diagram illustrates a rollback rule and risk management flowchart provided by an embodiment of the present invention.

[0076] When the rollback rules are met, the structure event element or the target data affected by the structure event element is downgraded, frozen, rolled back, version restored, failure sample written, or responsibility log updated.

[0077] In some embodiments, a rollback rule includes at least one of the following: rollback target, rollback conditions, rollback scope, rollback version, rollback triggering reason, rollback responsibility record, and post-rollback status. A rollback rule is triggered when a structured event meta-error write-back, user withdrawal confirmation, expert review rejection, source version reversal, evidence support reversal, variable pollution, task path failure, multimodal object mismatch, or increased risk level is detected.

[0078] Reference manual attached Figure 8 The diagram illustrates an event chain generation and failure sample transformation diagram provided by an embodiment of the present invention.

[0079] In some embodiments, the method further includes: Event chains are generated based on multiple structural event elements. Event chains are used to record the state change trajectory of the same object, the same claim, the same variable, the same task, the same modal object, the same risk item, or the same responsibility item at different time stages.

[0080] Optionally, when there are repeated errors, consecutive failures, risk escalation, repeated evidence conflicts, repeated variable contamination, or repeated task path failures in the event chain, a failure sample transformation event is generated, and the corresponding event is written into the failure sample library or evaluation sample library.

[0081] In some embodiments, the method further includes: Structural capability assessments are performed on structural event elements. These assessments include evaluations of event recognition accuracy, state difference judgment, phase context judgment, hold time judgment, feedback effect judgment, write-back target selection, rollback rule execution, and responsibility log integrity.

[0082] Reference manual attached Figure 9 The diagram illustrates a structural event element evaluation and report generation method provided by an embodiment of the present invention.

[0083] In some embodiments, the method further includes: Generate a structured event meta report, which includes at least one of the following: event identifier, event type, associated objects, state differences, phase context, hold time, feedback effect, write-back target, rollback rules, risk level, responsibility log, and follow-up handling recommendations.

[0084] Example 2: The user confirms the project variables and generates a variable event.

[0085] This example illustrates how the system generates structured event elements and writes them back to the variable library when a user confirms project variables.

[0086] The user enters in their personal AI project: "The official title of this project will be 'General Theory of AI Structural Intelligent Engineering'." The system receives the current input as event trigger data, parses the input, identifies the associated object in the event trigger data as the current project, and generates or calls the object identifier Object_ID_Project_001.

[0087] The system further determines the scope of the event association. Since the input involves the project title variable, the system determines the associated variable to be the project title variable Variable_ID_Title_001, and the associated responsibility record to be the user confirmation record Responsibility_Log_UserConfirm_001.

[0088] The system reads the previous state of the project title variable. The previous state shows the project title as a candidate, the variable value as "AI Continuous Information Structure Field Engineering Volume," and the confirmation status as unconfirmed. The system generates the next state based on user input. The next state shows the project title variable value updated to "AI Structural Intelligent Engineering General Theory," and the confirmation status as confirmed by the user.

[0089] The system compares the previous and subsequent states, generating a State Difference, which is recorded as: the project title variable has changed from a candidate title to a user-confirmed title. The system determines that this change occurred during the project writing and user confirmation phases, setting the Phase Context to "Project Phase—User Confirmation State". Based on explicit user confirmation and long-term project usage conditions, the system determines the Hold Time to be "retained throughout the project lifecycle until the user modifies or rolls back". The system determines that this state difference will affect subsequent title calls, table of contents generation, report generation, and project variable calls, setting the Feedback Effect to "changes the project title variable in subsequent outputs".

[0090] Since the state difference, phase context, hold time, and feedback effect all meet the event generation conditions, the system generates a structured event element Event_ID_Variable_001 with the event type Event_Type being a variable event. This event record includes object identifier, variable identifier, previous state, subsequent state, state difference, phase context, hold time, feedback effect, write-back target, rollback rules, and responsibility log.

[0091] Based on the event type and write-back target, the system writes the structured event element into the user's project variable library, variable version library, and responsibility log library. The system also generates a rollback rule (Rollback_Rule): when the user revokes confirmation or specifies restoring the old title, the project title variable is restored to the previous version, and a new rollback event is recorded.

[0092] When a user subsequently requests the generation of a project description, table of contents, or report, the system uses the confirmation title corresponding to this variable event instead of the old candidate title. Thus, the system transforms a user confirmation from a simple dialogue into a structured event element that is persistent, writable, and rollbackable.

[0093] Example 3: RAG source version changes and evidence events are generated.

[0094] This embodiment illustrates how the system generates evidence events and writes them back to the evidence chain library when the source version of the knowledge base is updated.

[0095] The existing document Source_ID_A in the enterprise knowledge base has a version status (Version_State) that is currently active. A claim (Claim_ID_003) depends on a reference fragment Citation_ID_A_01 in this document, and its support status (Support_Status) is supported. Subsequently, the knowledge base receives a new document Source_ID_D, and the system recognizes Source_ID_D as a replacement version of Source_ID_A.

[0096] The system receives the new document entry result as event trigger data and parses it to obtain the source version change. The system identifies the associated object as a document family object Object_ID_DocFamily_001 and determines that the event association scope includes the source document Source_ID_A, the alternative document Source_ID_D, the claim_ID_003, the cited fragment Citation_ID_A_01, and the evidence support status Support_Status.

[0097] Before system retrieval: Source_ID_A is the currently valid version, and Claim_ID_003 is supported by Citation_ID_A_01. After system retrieval: Source_ID_A is replaced by Source_ID_D, the content corresponding to Citation_ID_A_01 has expired, and the support status of Claim_ID_003 should change from supported to expired or pending review.

[0098] The system generates a State_Difference, recorded as "The source version has changed from currently valid to replaced, and the related claim support status has changed from supported to version expired or pending review." The system determines the Phase_Context as "Knowledge base version update stage—evidence status change." The system determines the Hold_Time as "Retained until manual review or reconfirmation of new version evidence." The system determines the Feedback_Effect as "Subsequent responses must not continue to directly use the old version to support the claim, and the conclusion strength needs to be reduced or a review suggestion is required."

[0099] The system determines that this change affects subsequent responses, evidence support, citation requirements, and the chain of responsibility, therefore generating a structured event element Event_ID_Evidence_001. The event type is an evidence event. The write-back targets include the evidence chain library, source library, citation library, claim library, and responsibility log library.

[0100] After the system writes back the event, during subsequent RAG response generation, when the model attempts to call the old document Source_ID_A to support Claim_ID_003, the system intercepts or downgrades the support status based on the event log, and prompts the user to use the new version Source_ID_D or proceed to manual review. If experts subsequently confirm that the new version still supports the claim, the system can generate a new evidence confirmation event; if experts confirm that the old claim is no longer valid, the system can generate a claim downgrade or freeze event.

[0101] Example 4: Task execution fails and a task path correction event is generated.

[0102] This embodiment illustrates how the system generates a task event and modifies the task path when an AI Agent task fails to execute.

[0103] The user requested the AI ​​Agent to complete the task of "retrieving the latest policies and generating a compliance report". The system has created a task, Task_ID_001, which is broken down into three steps: Step_ID_001 "retrieve policy documents", Step_ID_002 "extract key clauses", and Step_ID_003 "generate a compliance report". An external retrieval tool was called to execute Step_ID_001, but the tool returned a timeout or insufficient permissions error.

[0104] The system receives tool call results as event trigger data. The associated object is identified as Task_ID_001, and the event association scope includes Step_ID_001, Tool call record Tool_Result_001, Task path version Path_Version_001, and Responsibility log Responsibility_Log_Task_001.

[0105] Before the system retrieves the status: Step_ID_001 is in execution, and the task path is in normal execution. After the system retrieves the status: Step_ID_001 is in execution failure, with the reason for failure being insufficient permissions or timeout. Finally, a status difference (State_Difference) is generated and recorded as "Task step changed from in execution to tool execution failure".

[0106] The system determines the Phase Context to be "Task Execution Phase - Tool Feedback Status". The system determines the Hold Time to be "Hold before task review or alternative tool execution". The system determines the Feedback Effect to be "Modify task path, pause subsequent report generation, prompt user for authorization or use alternative search sources".

[0107] The system determines that this change affects the task path and subsequent output, therefore generating a structured event element Event_ID_Task_001, with the event type being a task event. The write-back targets include the task library, step library, failed path library, rejected path library, duplicate error suppression rule library, and responsibility log library.

[0108] Based on the event, the system updates the task path, marking Step_ID_001 as failed, marking the original path Path_Version_001 as needing correction, and generating a new path Path_Version_002, prompting the user to authorize, switch to public sources, or initiate manual search. The system also generates suppression rules to prevent repeated calls to the same failed tool before permissions are restored.

[0109] If the user subsequently authorizes the tool to access it, the system generates a new task recovery event; if the user cancels the task, the system generates a task termination event; if the tool continues to fail, the system converts this event chain into a failure sample to evaluate whether the AI ​​Agent can correctly handle tool failures.

[0110] Example 5: Multimodal conflict and generation of modal events.

[0111] This embodiment illustrates how the system generates modal events when conflicts occur between images, text, and tables.

[0112] An industrial inspection system receives a set of multimodal data: a text report describes device A as being in normal condition, on-site photos show damage to the casing of device A, and a detection table shows abnormal temperature parameters for device A. The system extracts modal objects from the text, images, and tables respectively, and maps them to the master object Master_Object_ID_DeviceA.

[0113] The system receives multimodal conflict detection results as event trigger data. The system identifies the associated object as device A, and the event association scope includes text objects, image objects, table objects, status observation records, modal conflict records, and risk records.

[0114] Before system acquisition: Device A is in normal condition with a low risk level. After system acquisition: The image shows a damaged casing, the table shows abnormal temperature, and the text report conflicts with the image and table. The system generates a StateDifference, recorded as "Device A has changed from a normal state to a cross-modal conflict state, and there is a possibility of risk escalation."

[0115] The system determines the Phase Context as "Multimodal Audit Phase - State Observation Conflict". The system determines the Hold Time as "Hold until manual review or new test data appears". The system determines the Feedback Effect as "Subsequent outputs should not directly conclude that the equipment is normal; they should output degraded results or review requirements".

[0116] The system generates a structured event element Event_ID_Modal_001, with the event type being a modal event. The write-back targets include the multimodal mapping library, the master object library, the modal object library, the modal conflict record library, the risk library, and the responsibility log library.

[0117] Subsequently, when the AI ​​system generates an inspection report, it invokes this modal event and outputs "Device A has a cross-modal conflict. The text report displays normally, but the image and table materials indicate anomalies, requiring manual review or supplementary inspection." If it is subsequently confirmed manually that the photo object is not Device A, the system generates an object mismatch rollback event; if it is confirmed manually that Device A is indeed damaged, the system generates a risk confirmation event and updates the object status.

[0118] Example 6: Expert review rejects the application and generates a rollback event.

[0119] This example illustrates how expert review results trigger structural event element rollback.

[0120] An AI knowledge auditing system previously generated Event_ID_Evidence_010, deeming a certain paper source to support Claim_ID_010, and added this support status to the evidence chain library. Subsequent expert review pointed out that the paper was only background-related and could not directly support the claim.

[0121] The system receives expert review results as event trigger data. The system identifies the associated objects as Claim_ID_010 and Source_ID_Paper_001, and the event association scope includes the original evidence event Event_ID_Evidence_010, claim support status, expert review records, and accountability logs.

[0122] Before system acquisition: Claim_ID_010's support status was "Supported". After system acquisition: Expert review changed it to "Background Relevant" or "Not Supported". The system generates a StateDifference, recorded as "Evidence support status changed from Supported to Background Relevant or Not Supported".

[0123] The system determines the Phase Context to be "Review Phase - Expert Rejection Status". The system determines the Hold Time to be "Maintain until new direct evidence emerges". The system determines the Feedback Effect to be "Reduce the strength of the assertion, update the audit report, and roll back the original evidence supporting the event".

[0124] The system generates a new structural event element, Event_ID_Rollback_001, with the event type being an evidence rollback event. The write-back targets include the evidence chain library, claim library, responsibility log library, and failure sample library. Based on the rollback rules, the system marks the original Event_ID_Evidence_010 as rejected or rolled back, downgrades the support status of Claim_ID_010 from supported to background relevant or unsupported, and updates the relevant reports.

[0125] If the error is a model reference mismatch, the system can further generate a failed sample conversion event, write the case into the failed sample library, and use it for subsequent evaluation of reference matching ability and evidence support judgment ability.

[0126] Example 7: Failure Sample Transformation and Structural Capability Evaluation.

[0127] This embodiment illustrates how an event chain can be transformed into a failure sample and used for structural capability evaluation.

[0128] An AI agent system repeatedly encountered the same error across three different tasks: when an external tool returned an empty result, the system still generated a deterministic answer. The system recorded three task events: Event_ID_Task_101, Event_ID_Task_205, and Event_ID_Task_309. All three events indicated that the tool returned an empty result, but subsequent outputs did not degrade, resulting in incorrect answers.

[0129] The system, based on the event chain generation module, identified multiple task events with duplicate errors. The system generated a failure sample conversion event, Event_ID_Failure_001, with the event type being a failure sample event. The status difference record was "The system did not trigger degradation or manual review after the tool produced an empty result." The phase context was "Task execution phase—Tool failure feedback." The retention time was "Retained until rule updates and regression testing pass." The feedback effect was "Generate failure samples and update evaluation samples."

[0130] The system writes this event to the failure sample library and the evaluation sample library. The failure sample record includes the error type, triggering conditions, event chain, model error output, expected handling method, and regression testing requirements. Expected handling methods include: empty results from the detection tool; no deterministic answer generated; output of downgraded results; prompt for supplementary data or manual review; and recording in the responsibility log.

[0131] The subsequent structural capability assessment module calls this sample to test the AI ​​system. If the AI ​​system generates a deterministic answer again when the tool has no results, the assessment result is unqualified; if the system correctly triggers degradation, review, or task pause, the assessment result is qualified. Thus, structural event elements not only record errors but can also be transformed into assessment samples, promoting continuous system improvement.

[0132] Example 8: Event Element Execution in a Continuous Information Structure Field Platform.

[0133] This embodiment illustrates how structural event elements serve as the underlying event mechanism of a continuous information structure field platform.

[0134] In the continuous information structure field platform, the system maintains object libraries, claim libraries, source libraries, reference libraries, version libraries, variable libraries, task libraries, multimodal mapping libraries, feedback libraries, risk libraries, failure sample libraries, evaluation sample libraries, and responsibility log libraries. Every change that can affect subsequent states is identified and written back by the structured event meta-system.

[0135] For example, when a user uploads a new document, the system generates a source version event; when AI outputs a new claim, the system generates a claim event; when a user confirms a project preference, the system generates a variable event; when a tool fails to execute, the system generates a task event; when there is a conflict between text and image materials, the system generates a modal event; when an expert review rejects the claim, the system generates a rollback event; and when a duplicate error occurs, the system generates a failure sample event.

[0136] The continuous information structure field platform maintains the long-term state of the same project through event chains. The system can determine whether the current project object is continuous, whether the claim is still supported by evidence, whether the variables are still valid, whether the task path has drifted, whether there are conflicts in multimodal materials, whether risks have been addressed, and whether the chain of responsibility is complete based on the event chain.

[0137] In this way, the structural event meta system becomes the underlying event meta engine of the continuous information structure field platform, enabling the platform not only to save the state, but also to record state changes, interpret state changes, write back state changes, and roll back erroneous state changes.

[0138] Example 9: Rollback of variable contamination in long-term collaboration with personal AI.

[0139] This example illustrates the identification and rollback of variable contamination in a personal AI system.

[0140] In a brief conversation, a user says, "This time, I'll answer in a concise style." The system parses this input as a possible output preference variable. The system reads historical variables and finds that the user's long-term project variable records an output preference of "formal, complete, suitable for patent text." The system determines that this input is a temporary expression within the current session, rather than an update to a long-term variable.

[0141] The system generates a state difference candidate: the output preference temporarily changes from "formal and complete" to "brief". The system determines the phase context as "single-turn session - temporary instruction", the duration as "current session", and the feedback effect as "only affecting the current answer, not long-term item variables". The system determines that this state difference does not meet the conditions for generating long-term structural event elements, therefore it is not written into the long-term variable library, but only recorded as temporary context information.

[0142] If the system mistakenly writes the temporary preference into the long-term variable library, and the user subsequently discovers that the AI ​​is continuously outputting excessively short content in the patent text and withdraws the preference, the system receives the user's withdrawal confirmation as event trigger data, generates a variable pollution rollback event, restores the variable to its original long-term variable state, and writes the error write-back event into the failure sample library for subsequent evaluation of "whether the temporary preference was mistakenly written into the long-term variable".

[0143] Example 10: Chain of Responsibility Completion Event.

[0144] This example illustrates how to generate a responsibility event when the responsibility log is missing.

[0145] A company's AI system generated a high-risk technical report, but some conclusions in the report lacked human review records. During a continuous audit, the system discovered that the report involved high-risk individuals, had low levels of evidence support, and had strong conclusions, but the accountability log lacked the reviewer, review time, and review results.

[0146] The system generates a status difference for gaps in the chain of responsibility: the responsibility log changes from "complete" or "unchecked" to "chain of responsibility missing". The phase context is "report generation stage - high-risk output". The retention period is "retained until manual review is completed". The feedback effect is "restricts formal report output, triggers manual review, and reduces the strength of the conclusion".

[0147] The system generates a structured event element Event_ID_Responsibility_001, with the event type being a responsibility event. The write-back targets include the responsibility log repository, risk repository, report repository, and manual review queue. The system also generates rollback rules: if a report has been output but subsequent confirmation of a missing responsibility chain occurs, the report status is marked as pending review or withdrawn, and the corresponding action is recorded.

[0148] Through this accountability event, the system can prevent high-risk AI outputs from being directly adopted when the chain of responsibility is incomplete.

[0149] Example 11: Structural Event Meta Report Output.

[0150] The system can generate a structure event meta report for each structure event meta. The report may include: Event identifier; event type; associated objects; associated claims, variables, tasks, modal objects, or risk items; previous state; subsequent state; state differences; phase context; hold time; feedback effect; write-back objective; rollback rules; risk level; responsibility log; follow-up handling suggestions; whether to enter the failure sample library; whether to enter the evaluation sample library.

[0151] Reports can be output in the form of text, tables, JSON, XML, database records, visualization interfaces, or API results. Enterprise systems can access event reports via API interfaces for knowledge base governance, task management, risk control, model evaluation, or manual review.

[0152] The method of this invention does not require all steps to be executed completely in every process. In practical applications, the system can select to execute some or all of the following steps, based on input type, task scenario, risk level, user permissions, data source, or business rules: associated object identification, state difference generation, phase context judgment, hold time judgment, feedback effect judgment, structure event element generation, write-back, rollback, event chain generation, and structure capability evaluation.

[0153] Reference manual attached Figure 10 The diagram illustrates the overall architecture of an AI system structure event meta generation, recognition, write-back, and rollback system provided by this invention.

[0154] This invention also provides an AI system architecture event meta-generation, recognition, write-back, and rollback system, comprising: An event parsing unit is used to receive event trigger data and parse the event trigger data to obtain event parsing results; The object and scope determination unit is used to identify associated objects based on the event parsing results, generate or call object identifiers, and determine the event association scope based on the object identifiers and the event parsing results; The state difference processing unit is used to obtain the previous state and the subsequent state corresponding to the event association range, generate a state difference based on the previous state and the subsequent state, and determine the phase context based on the processing stage, version state, evidence state, variable state, risk state or responsibility state corresponding to the event association range. The feedback judgment unit is used to determine the retention time based on the retention conditions of the state difference in the session cycle, task cycle, project cycle, variable life cycle, review cycle or freeze cycle, and to determine the feedback effect based on the impact of the state difference on subsequent output, variable call, task path, evidence support, multimodal mapping, risk handling, failure samples, evaluation samples or chain of responsibility. The event judgment and recording unit is used to determine whether to generate a structured event element based on the state difference, the phase context, the hold time, and the feedback effect. If so, it determines the write-back target from the pre-set write-back target rules based on the event type, risk level, hold time, feedback effect, or responsibility status, generates an event identifier, and forms a structured event element record. The structured event element record includes the event type, object identifier, state difference, phase context, hold time, feedback effect, write-back target, rollback rules, and responsibility log. Otherwise, it records the state difference as temporary context information or a regular log and terminates the structured event element write-back process for the state difference. The write-back and rollback unit is used to perform a write-back of the structure event element according to the write-back target after the structure event element record is formed, and to perform downgrading, freezing, retraction, version recovery, failure sample writing or responsibility log update on the structure event element or the target data affected by the structure event element when the rollback rules are met. The event chain and evaluation unit is used to generate an event chain based on multiple structured event elements, and to evaluate the event identification, state difference judgment, phase context judgment, hold time judgment, feedback effect judgment, write-back target selection, rollback rule execution, or responsibility log integrity of the structured event elements.

[0155] The AI ​​system structure event element generation, identification, write-back and rollback system provided by the present invention can execute the above-mentioned AI system structure event element generation, identification, write-back and rollback methods and achieve the same or similar technical effects. To avoid duplication, the present invention will not elaborate further.

[0156] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. The scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for generating, recognizing, writing back, and rolling back event elements in an AI system architecture, characterized in that, The method is executed by at least one processor and includes: Receive event trigger data and parse the event trigger data to obtain the event parsing result; Identify associated objects based on the event parsing results, and generate or call object identifiers; The scope of the event association is determined based on the object identifier; Obtain the previous and subsequent states corresponding to the event association range, and generate state differences based on the previous and subsequent states; The phase context is determined based on the processing stage, version status, evidence status, variable status, risk status, and responsibility status corresponding to the event association scope. The retention time is determined based on the retention conditions of the aforementioned state differences in the session cycle, task cycle, project cycle, variable life cycle, review cycle, and freeze cycle; The feedback effect is determined based on the impact of the state differences on subsequent outputs, variable calls, task paths, evidence support, multimodal mapping, risk handling, failure samples, evaluation samples, or chains of responsibility. Based on the state difference, phase context, hold time, and feedback effect, determine whether to generate a structured event element; if so, determine the write-back target from the pre-set write-back target rules based on the event type, risk level, hold time, feedback effect, or responsibility status, generate an event identifier, and form a structured event element record. The structured event element record includes the event type, object identifier, state difference, phase context, hold time, feedback effect, write-back target, rollback rules, and responsibility log; otherwise, record the state difference as temporary context information or ordinary log, and end the structured event element write-back process for the state difference. After the structure event meta record is formed, the structure event meta write-back is performed according to the write-back target; When the rollback rules are met, the structure event element or the target data affected by the structure event element is downgraded, frozen, withdrawn, restored to a version, written to a failure sample, or updated in the responsibility log.

2. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, The event triggering data includes at least one of the following: user input, model output, knowledge base retrieval results, RAG answer results, tool call results, multimodal input, task execution results, user feedback, expert review results, experimental results, accident samples, external system feedback, or historical log records; the event parsing results include source information, version information, timestamp, object candidates, claim candidates, variable candidates, task status, modal object, feedback type, risk marker, or responsibility record.

3. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, When identifying the associated object, the current object is determined to be an existing object, a newly added object, an object mismatch object, a boundary conflict object, or an object to be reviewed, based on the object name, object alias, object type, object context, historical object record, source version, timestamp, multimodal features, task identifier, or project identifier.

4. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, The event association scope includes at least one of the following: object association scope, claim association scope, evidence association scope, variable association scope, task association scope, modal object association scope, feedback association scope, risk association scope, or responsibility record association scope.

5. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, The pre-state includes at least one of the following: object identity state, object boundary state, claim support state, source version state, reference matching state, variable confirmation state, variable conflict state, task stage state, task path state, multimodal object mapping state, feedback result state, risk handling state, failure sample state, evaluation sample state, or chain of responsibility state before the event occurs; the post-state includes at least one of the following: object identity state, object boundary state, claim support state, source version state, reference matching state, variable confirmation state, variable conflict state, task stage state, task path state, multimodal object mapping state, feedback result state, risk handling state, failure sample state, evaluation sample state, or chain of responsibility state after the event occurs.

6. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, The state differences include at least one of the following: object mismatch, object merging, object splitting, claim addition, claim downgrading, change in evidence support, change in source version, change in reference matching, variable addition, variable confirmation, variable conflict, variable freezing, task path correction, failure path suppression, multimodal conflict, feedback write-back, risk escalation, chain of responsibility completion, or failure sample transformation.

7. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, The phase context includes at least one of the following: draft phase, audit phase, generation phase, execution phase, feedback phase, review phase, archiving phase, freeze phase, rollback phase, or evaluation phase.

8. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, The hold time is used to distinguish between temporary contexts, single-turn session states, multi-turn session states, task states, project states, long-term variable states, frozen states, or archived states.

9. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, The feedback effects include at least one of the following: changing the strength of subsequent answer conclusions, changing citation requirements, changing variable access permissions, changing task paths, changing risk warning strength, triggering manual review, triggering freezing, triggering rollback, triggering failure sample writing, triggering evaluation sample generation, or triggering responsibility log updates.

10. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, When the state difference is temporary noise, low-confidence input, unacknowledged prompt, or ordinary log that does not affect subsequent output, no structured event element is generated, or the state difference is recorded as temporary context information; when the state difference affects object identification, claim support, variable invocation, task path, multimodal mapping, risk handling, failure sample writing, evaluation sample generation, or chain of responsibility recording, a structured event element is generated.

11. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, The event types include object events, claim events, evidence events, variable events, task events, modal events, feedback events, risk events, failure sample events, evaluation events, or liability events.

12. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, The pre-defined write-back target rules are used to determine the write-back target based on the event type, risk level, retention time, feedback effect, or responsibility status. The write-back target points to at least one of the following: object library, claim library, evidence chain library, variable library, task library, multimodal mapping library, feedback library, risk library, failure sample library, evaluation sample library, or responsibility log library.

13. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, The write-back target is determined based on the event type as at least one of the following: When the event type is a variable event, the write-back target includes at least one of the following: variable library, user project variable library, variable version library, variable conflict record, variable freeze record, or variable rollback record; When the event type is a task event, the write-back target includes at least one of the following: task library, step library, task path version library, failure path library, rejected path library, duplicate error suppression rule library, or task responsibility log library; When the event type is an evidence event, the write-back target includes the following: claim library, source library, citation library, version library, etc. The write-back target includes at least one of the following: a library of evidence support, a library of disproving evidence records, a library of RAG trusted chains, or a library of evidence responsibility logs; when the event type is a modal event, the write-back target includes at least one of the following: a multimodal mapping library, a master object library, a modal object library, a time alignment record, a version alignment record, a state observation record, a modal conflict record, or a review record; when the event type is a failure sample event or an evaluation event, the write-back target includes at least one of the following: a failure sample library, an error type library, a regression test sample library, an evaluation sample library, a suppression rule library, a model hint strategy library, or an evaluation log library.

14. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, The rollback rule includes at least one of the following: rollback target, rollback conditions, rollback scope, rollback version, rollback triggering reason, rollback responsibility record, and post-rollback status. The rollback rule is triggered when a structural event element is incorrectly written back, a user cancels confirmation, an expert review is rejected, a source version is reversed, evidence support is reversed, a variable is polluted, a task path fails, a multimodal object is mismatched, or a risk level is increased.

15. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, The method further includes: An event chain is generated based on multiple structural event elements. The event chain is used to record the state change trajectory of the same object, the same claim, the same variable, the same task, the same modal object, the same risk item, or the same responsibility item at different time stages.

16. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 15, characterized in that, When there are repeated errors, consecutive failures, risk escalation, repeated evidence conflicts, repeated variable contamination, or repeated task path failures in the event chain, a failure sample transformation event is generated, and the corresponding event is written into the failure sample library or evaluation sample library.

17. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, The method further includes: The structural capability evaluation of the structural event element includes evaluation of event recognition accuracy, state difference judgment, phase context judgment, hold time judgment, feedback effect judgment, write-back target selection, rollback rule execution, or responsibility log integrity.

18. The method for generating, recognizing, writing back, and rolling back AI system structural event elements according to claim 1, characterized in that, The method further includes: Generate a structured event meta report, which includes at least one of the following: event identifier, event type, associated object, state difference, phase context, hold time, feedback effect, write-back target, rollback rules, risk level, responsibility log, and follow-up handling suggestions.

19. An AI system architecture event element generation, recognition, write-back, and rollback system, characterized in that, include: An event parsing unit is used to receive event trigger data and parse the event trigger data to obtain event parsing results; The object and scope determination unit is used to identify associated objects based on the event parsing results, generate or call object identifiers, and determine the event association scope based on the object identifiers and the event parsing results; The state difference processing unit is used to obtain the previous state and the subsequent state corresponding to the event association range, generate a state difference based on the previous state and the subsequent state, and determine the phase context based on the processing stage, version state, evidence state, variable state, risk state or responsibility state corresponding to the event association range. The feedback judgment unit is used to determine the retention time based on the retention conditions of the state difference in the session cycle, task cycle, project cycle, variable life cycle, review cycle or freeze cycle, and to determine the feedback effect based on the impact of the state difference on subsequent output, variable call, task path, evidence support, multimodal mapping, risk handling, failure samples, evaluation samples or chain of responsibility. The event judgment and recording unit is used to determine whether to generate a structured event element based on the state difference, the phase context, the hold time, and the feedback effect. If so, it determines the write-back target from the pre-set write-back target rules based on the event type, risk level, hold time, feedback effect, or responsibility status, generates an event identifier, and forms a structured event element record. The structured event element record includes the event type, object identifier, state difference, phase context, hold time, feedback effect, write-back target, rollback rules, and responsibility log. Otherwise, it records the state difference as temporary context information or a regular log and terminates the structured event element write-back process for the state difference. The write-back and rollback unit is used to perform a write-back of the structure event element according to the write-back target after the structure event element record is formed, and to perform downgrading, freezing, retraction, version recovery, failure sample writing or responsibility log update on the structure event element or the target data affected by the structure event element when the rollback rules are met. The event chain and evaluation unit is used to generate an event chain based on multiple structured event elements, and to evaluate the event identification, state difference judgment, phase context judgment, hold time judgment, feedback effect judgment, write-back target selection, rollback rule execution, or responsibility log integrity of the structured event elements.

20. The AI ​​system architecture event element generation, recognition, write-back, and rollback system according to claim 19, characterized in that, The system also includes: The data asset repository includes at least one of the following: object repository, claim repository, evidence chain repository, variable repository, task repository, multimodal mapping repository, feedback repository, risk repository, failure sample repository, evaluation sample repository, or responsibility log repository.

21. A device for generating, recognizing, writing back, and rolling back event elements in an AI system architecture, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor. When the computer program is executed by the at least one processor, it causes the at least one processor to perform the AI ​​system architecture event element generation, identification, write-back and rollback method as described in any one of claims 1 to 18.

22. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program that, when executed by a processor, implements the AI ​​system architecture event generation, identification, write-back, and rollback method as described in any one of claims 1 to 18.

23. A computer program product, characterized in that: The computer program product includes a computer program that, when executed by a processor, implements the AI ​​system architecture event element generation, identification, write-back, and rollback method as described in any one of claims 1 to 18.

Images