Method and system for constructing and maintaining an ai system continuous information structure field

Abstract

The application provides a kind of AI system continuous information structure field construction and maintenance method and system, it is related to computer-aided decision-making technical field, method includes: receiving project input data and generating input analysis result;Establish continuous object core, claim chain and evidence association chain, form variable life system, task path system, multi-modal object mapping and entity feedback write-back chain;Generate or call structure event meta record;Audit object, evidence, variable, task, mode, feedback, event meta and responsibility continuity, trigger freeze, review, downgrade, rollback or responsibility record when detecting fracture, conflict, drift, feedback failure or responsibility gap;Generate continuous information structure field report, write object core, claim chain, evidence association chain, variable, task, mode, feedback, event record and risk disposal result into data asset library, for subsequent retrieval generation, task execution, variable call, event audit, rollback management and risk management.

Description

Technical Field

[0001] This invention relates to the field of computer-aided decision-making technology, and in particular to a method and system for constructing and maintaining a continuous information structure field in an AI system. Background Technology

[0002] In recent years, artificial intelligence systems, especially large language models, multimodal models, retrieval-enhanced generation systems, and AI Agent (artificial intelligence agent) systems, have made significant progress in natural language generation, question answering, summarizing, translation, code generation, image understanding, audio processing, video analysis, table processing, tool invocation, and complex task collaboration. Existing AI systems are already able to generate relatively complete answers, solutions, plans, or execution results based on user input, contextual materials, knowledge base documents, or results from external tools.

[0003] However, while existing technologies have made significant progress in model generation, retrieval, multimodal recognition, and tool invocation capabilities, they still lack a unified and executable scheme for constructing and maintaining a continuous information structure field. This scheme is necessary for maintaining long-term continuous records of objects, evidence, variables, tasks, modalities, entity feedback, responsibilities, and structural event meta-records that can influence the subsequent system state within AI systems. Therefore, it is necessary to propose a new method and system that enables AI systems to form a recordable, auditable, updatable, freezeable, rollbackable, and write-back information structure layer during long-term operation. Summary of the Invention

[0004] To address the technical problem that while existing technologies have made significant progress in model generation, retrieval, multimodal recognition, and tool invocation capabilities, they still lack a unified and executable scheme for constructing and maintaining a continuous information structure field in AI systems. This scheme would be used to maintain long-term records of continuous objects, evidence, variables, tasks, modalities, entity feedback, responsibilities, and structural event meta-records that can influence the subsequent system state. Therefore, this invention provides a method and system for constructing and maintaining a continuous information structure field in AI systems.

[0005] The technical solutions provided by the embodiments of the present invention are as follows: First aspect: This invention provides a method for constructing and maintaining a continuous information structure field in an AI system, the method being executed by at least one processor, and comprising: Receive project input data and preprocess the project input data to obtain input parsing results; Based on the input parsing results, a continuous object kernel is established, an object identifier is generated, and the object identifier is used as an association index for claims, evidence, variables, tasks, modal objects, feedback, and structured event meta-records; A claim chain is established based on the continuous object kernel, and claims associated with the object identifier are extracted from the input parsing results to generate claim identifiers; An evidence association chain is established based on the claim chain, and the evidence association chain is used to associate the claim identifier with the source identifier, version status, citation identifier and support status. Based on the continuous object kernel, the claim chain, and the evidence association chain, a variable life system, a task path system, a multimodal object mapping, and an entity feedback write-back chain are established. Based on the state changes in the continuous object kernel, the evidence association chain, the variable life system, the task path system, the multimodal object mapping, and the entity feedback write-back chain, a structured event meta-record is generated or invoked, and the structured event meta-record is used as the event basis for continuous auditing and risk disposal. Continuity auditing is performed based on the continuous object kernel, the claim chain, the evidence association chain, the variable life system, the task path system, the multimodal object mapping, the entity feedback write-back chain, and the structured event meta-record, generating continuity audit results; Risk management actions are triggered based on the results of the continuous audit, including freezing, review, downgrading, rollback, or accountability records. Based on the continuous audit results and the risk handling operations, a continuous information structure field report is generated, and the continuous object core, the claim chain, the evidence association chain, the variable life system, the task path system, the multimodal object mapping, the entity feedback write-back chain, the structured event meta-record, the risk handling operations, and the continuous information structure field report are written into the data asset repository.

[0006] The second aspect: This invention provides a system for constructing and maintaining a continuous information structure field in an AI system, comprising: The input object construction module is used to receive project input data and preprocess it to obtain input parsing results. Based on the input parsing results, a continuous object kernel is established, an object identifier is generated, and the object identifier is used as an association index for claims, evidence, variables, tasks, modal objects, feedback, and structured event meta-records. The structural link maintenance module is used to establish a claim chain based on the continuous object core, extract claims associated with the object identifier from the input parsing results and generate claim identifiers; establish an evidence association chain based on the claim chain, the evidence association chain being used to associate the claim identifier with the source identifier, version status, reference identifier and support status; and establish a variable life system, task path system, multimodal object mapping and entity feedback write-back chain based on the continuous object core, the claim chain and the evidence association chain. The event recording module is used to generate or call structured event meta-records based on the state changes in the continuous object kernel, the evidence association chain, the variable life system, the task path system, the multimodal object mapping and the entity feedback write-back chain, and to use the structured event meta-records as the event basis for continuous auditing and risk handling. The continuity audit handling module is used to perform continuity audits based on the continuity object kernel, the claim chain, the evidence association chain, the variable life system, the task path system, the multimodal object mapping, the entity feedback write-back chain, and the structured event meta record, generate continuity audit results, and trigger risk handling operations based on the continuity audit results. The risk handling operations include freezing, review, downgrading, rollback, or accountability records. The report storage and retrieval module is used to generate a continuous information structure field report based on the continuous audit results and the risk disposal operation, and write the continuous object core, the claim chain, the evidence association chain, the variable life system, the task path system, the multimodal object mapping, the entity feedback write-back chain, the structured event meta record, the risk disposal operation, and the continuous information structure field report into the data asset library, and supports subsequent retrieval.

[0007] Third aspect: This invention provides a device for constructing and maintaining a continuous information structure field in an AI system, 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 method for constructing and maintaining the continuous information structure field of the AI ​​system as described in the first aspect.

[0008] Fourth aspect: The present invention provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method for constructing and maintaining a continuous information structure field of an AI system as described in the first aspect.

[0009] 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 method for constructing and maintaining a continuous information structure field of an AI system as described in the first aspect.

[0010] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following: (1) By establishing a unified continuous information structure layer in the AI ​​system, the target object, output claim, source material, reference location, version status, evidence support, effective domain, long-term variable, task path, multimodal object, entity feedback, frozen status, rollback target, structured event meta record and responsibility log are structurally identified and associated, so that the AI ​​system can continuously maintain the continuous relationship between the same object, the same claim, the same variable, the same task path, the same multimodal object and the same entity feedback result in long-term operation.

[0011] (2) When the AI ​​system detects object conflict, evidence rebuttal, version expiration, variable pollution, task drift, modal conflict, high-risk action, feedback failure, structural change event anomaly, or missing chain of responsibility, it can automatically or semi-automatically trigger freezing, review, downgrade, rollback, repeated error suppression, failure sample writing, or responsibility recording, thereby improving the stability, credibility, traceability, manageability, and real-world feedback correction capabilities of the AI ​​system. Attached Figure Description

[0012] 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.

[0013] Figure 1 This is a flowchart illustrating a method for constructing and maintaining a continuous information structure field in an AI system, as provided in an embodiment of the present invention.

[0014] Figure 2 This invention provides a diagram showing the relationship between a continuous object core, a claim chain, and an evidence association chain.

[0015] Figure 3 This invention provides a variable life system structure and state maintenance diagram.

[0016] Figure 4 This invention provides a task path system and entity feedback write-back chain relationship diagram.

[0017] Figure 5 This invention provides a multimodal object mapping and cross-modal conflict audit diagram.

[0018] Figure 6 This is a flowchart of continuous auditing and risk management provided for an embodiment of the present invention.

[0019] Figure 7 This is a diagram illustrating the relationship between continuous information structure field report output and data asset library retrieval, provided as an embodiment of the present invention.

[0020] Figure 8 This is a structural event meta-record and write-back target relationship diagram provided in an embodiment of the present invention.

[0021] Figure 9 This is a diagram illustrating the overall architecture of a system for constructing and maintaining a continuous information structure field in an AI system, as provided in an embodiment of the present invention. Detailed Implementation

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

[0023] 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.

[0024] Example 1 Reference manual attached Figure 1 The diagram illustrates a flowchart of a method for constructing and maintaining a continuous information structure field in an AI system, as provided in an embodiment of the present invention.

[0025] This invention provides a method for constructing and maintaining a continuous information structure field in an AI system. This method can be implemented by a device for constructing and maintaining a continuous information structure field in an AI system, which can be a terminal or a server. The processing flow of the method for constructing and maintaining a continuous information structure field in an AI system may include the following steps: Receive project input data, preprocess the project input data, and obtain input parsing results.

[0026] In some embodiments, project input data includes at least one of user input, historical interactions, documentation, RAG (Retrieval Enhanced Generation) sources, multimodal materials, tool call results, user feedback, expert review opinions, experimental results, accident samples, or entity feedback. Preprocessing includes at least one of format parsing, source identification, version identification, timestamp extraction, permission identification, deduplication, cleaning, segmentation, structured parsing, or metadata registration.

[0027] Reference manual attached Figure 2This diagram illustrates a relationship between a continuous object core, a claim chain, and an evidence association chain, as provided in an embodiment of the present invention.

[0028] Based on the input parsing results, a continuous object kernel is established, object identifiers are generated, and the object identifiers are used as the association indexes for claims, evidence, variables, tasks, modal objects, feedback, and structured event meta-records.

[0029] The object kernel is used to maintain the identity, boundaries, status, version, relationship, conflict, feedback and responsibility information of the target object in multi-round interaction, multi-document, multi-version, multi-modal, multi-task and entity feedback.

[0030] In some embodiments, a continuous object kernel includes object name, object alias, object type, object boundary, object status, object version, object source, object relationship, object conflict status, object freeze status, or object responsibility log. When establishing a continuous object kernel, based on the object name, alias, source, version, context relationship, timestamp, multimodal characteristics, or historical object records, it identifies objects with the same name but different names, objects with different names but the same object, object boundary conflicts, object version conflicts, or object status conflicts, and performs at least one of the following operations: object merging, object splitting, object freezing, object review, or object rollback.

[0031] Claim chains are established based on continuous object kernels, and claims associated with object identifiers are extracted from the input parsing results to generate claim identifiers.

[0032] In some embodiments, claims in a claim chain include factual claims, data claims, model claims, reasoning claims, prediction claims, recommendation claims, risk claims, conclusion claims, or action claims. Once a claim identifier is bound to an object identifier, it is used to determine the object to which the claim belongs, the claim type, the claim status, and the claim liability record.

[0033] Optionally, the system can record the claim text, claim type, target, source of generation, generation time, scope of application, risk level, current status, and liability record for each claim identifier.

[0034] An evidence association chain is established based on the claim chain. The evidence association chain is used to associate claim identifiers with source identifiers, version status, citation identifiers, and support status.

[0035] In some embodiments, the evidence chain includes a source identifier, a citation identifier, a version status, a support status, and a valid domain. The valid domain identifies the time frame, spatial scope, target scope, industry scope, experimental conditions, sample size, risk boundaries, professional review requirements, or restrictions on public expression of the claim. Support status includes supported, partially supported, relevant to the context, not supported, evidence to the contrary exists, version expired, pending review, or frozen.

[0036] In some embodiments, when a source failure, reference mismatch, version expiration, insufficient support, occurrence of counter-evidence, or valid domain out-of-bounds is detected, at least one of the following actions is taken on the relevant claim: evidence downgrading, claim freezing, manual review, liability recording, or rollback of target registration.

[0037] Reference manual attached Figure 3 The diagram illustrates a variable life system structure and state maintenance diagram provided by an embodiment of the present invention.

[0038] Based on continuous object kernels, claim chains, and evidence association chains, a variable life system, a task path system, a multimodal object mapping, and an entity feedback write-back chain are established.

[0039] The variable life system is used to distinguish between temporary context information and long-term variable information, and to avoid mistakenly calling temporary expressions, expired information, conflicting information or unconfirmed information as long-term memory.

[0040] In some embodiments, the variable lifecycle system includes variable identifier, variable name, variable type, variable content, variable source, confirmation status, scope of application, version status, conflict status, frozen status, invocation conditions, invocation records, update records, deletion records, rollback targets, or responsibility logs.

[0041] In some embodiments, when a new variable conflicts with a historical variable, the source of the variable is unknown, the variable expires, the variable is denied by the user, the variable risk increases, or the variable is no longer suitable for use, at least one of the following processes is triggered: variable freezing, variable review, variable downgrading, variable deletion, or variable rollback.

[0042] Reference manual attached Figure 4 The diagram illustrates the relationship between a task path system and an entity feedback write-back chain provided in an embodiment of the present invention.

[0043] Reference manual attached Figure 5 This illustrates a multimodal object mapping and cross-modal conflict audit diagram provided by an embodiment of the present invention.

[0044] In some embodiments, the task path system includes a task identifier, target text, completion criteria, step identifier, stage status, path version, rejected path, failure record, suppression rule, task update, future output change or write-back log.

[0045] Optionally, when a task objective drift, step duplication, path failure, repeated occurrence of failed paths, tool execution failure, user rejection, expert refusal, or actual results are detected, at least one of the following processes is triggered: updating the task path, recording failure samples, generating duplicate error suppression rules, changing future output, or review.

[0046] In some embodiments, a multimodal object mapping includes modality type, modality object identifier, master object identifier, alias or region, time alignment, version alignment, state observation, evidence role, modality conflict, fusion result or review requirement. When establishing a multimodal object mapping, candidate mappings are generated based on name, alias, image region, spatial location, trajectory, speaker, table rows and columns, sensor channels, timestamp, source version, contextual relationship, or semantic similarity.

[0047] Specifically, the system generates modal object identifiers for objects in text, images, audio, video, tables, sensor data, tool logs, or structured data, and maps the modal object identifiers to a unified object identifier or a master object identifier.

[0048] Optionally, when a mismatch between image and text, audio and text, video event chain misalignment, conflict between table and text evidence, conflict between sensor data and manual records, or uncertainty of multimodal objects is detected, at least one of the following is output: fusion result, downgrade result, conflict prompt, or review request.

[0049] In some embodiments, the entity feedback write-back chain includes a feedback identifier, feedback type, actual result, feedback source, feedback time, related object, related claim, related variable, related task, related step, task update, risk update, future output change, or write-back log. When entity feedback indicates tool failure, experiment failure, user denial, expert rejection, actual result not meeting expectations, risk increase, or incident occurrence, the corresponding object, claim, variable, task, or risk status is updated, and future outputs are constrained, downgraded, frozen, or rolled back.

[0050] Among them, the entity feedback write-back chain is used to enable the results of AI output entering reality to return to the AI ​​system and affect subsequent evidence association chains, variable life systems, task paths, risk strategies and future outputs.

[0051] Based on the state changes in the continuous object kernel, evidence association chain, variable life system, task path system, multimodal object mapping, and entity feedback write-back chain, structural event meta-records are generated or invoked, and these structural event meta-records are used as the event basis for continuous auditing and risk disposal.

[0052] In some embodiments, structured event metadata records are used to record structured change events in the AI ​​system that can affect subsequent object states, claim support, variable states, task paths, multimodal mapping states, entity feedback states, risk states, or responsibility states. Structured event metadata records include event records generated by this system or data records written by an external structured event metadata generation system.

[0053] Optionally, the structured event metadata record includes at least one of the following: event identifier, event type, state difference, phase context, hold time, feedback effect, write-back target, rollback target, risk level, or responsibility log. Event types include at least one of the following: object event, evidence event, variable event, task event, modal event, feedback event, risk event, or responsibility event.

[0054] Specifically, the system generates or invokes structured event meta-records based on changes in object state, claim support, source version, variable state, task path, multimodal object mapping, entity feedback results, or risk handling status. Structured event meta-records represent structured change events in the AI ​​system that can affect the subsequent states of objects, claims, sources, variables, tasks, modalities, feedback, risks, or responsibilities. Structured event meta-records can be generated internally by the system, or generated by an independent structured event meta-record generation module, a coupled event meta-record engine, or an external event recognition system and then written into the system.

[0055] Optionally, when the system determines that a change is merely a temporary input, noise, an unconfirmed state, or a regular log that does not affect subsequent output, it may not generate a structured event meta-record, or may only record it as temporary context information. When the system determines that a change has affected subsequent judgments, variable calls, task paths, risk handling, or chains of responsibility, it generates or calls a structured event meta-record and writes the structured event meta-record to the corresponding object library, claim library, variable library, task library, multimodal mapping library, feedback library, risk library, failure sample library, structured event meta-record library, or responsibility log library.

[0056] Reference manual attached Figure 6 This illustrates a flowchart of a continuous audit and risk management process provided by an embodiment of the present invention.

[0057] Continuity auditing is performed based on continuous object kernel, claim chain, evidence association chain, variable life system, task path system, multimodal object mapping, entity feedback write-back chain, and structural event meta-record, generating continuity audit results.

[0058] In some embodiments, continuity auditing includes object continuity auditing, evidence continuity auditing, variable continuity auditing, task continuity auditing, modal continuity auditing, entity feedback continuity auditing, structural event meta-continuity (SECPC) continuity auditing, or responsibility continuity auditing. SECPC continuity auditing is used to determine whether structural changes that could affect the subsequent system state have generated or invoked SECPC records, and to determine whether the SECPC records have been associated with corresponding object, claim, evidence, variable, task, modal object, feedback, risk, or responsibility records.

[0059] Risk management actions are triggered based on continuous audit results. These actions include freezing, reviewing, downgrading, rolling back, or recording liability.

[0060] It should be noted that when the system detects object conflicts, evidence rebuttal, version expiration, variable pollution, task drift, modal conflicts, high-risk actions, feedback failures, permission mismatches, missing structure event metadata records, or missing chains of responsibility, the system triggers the risk handling mechanism.

[0061] In some embodiments, risk handling operations include triggering at least one of the following processes based on the continuity audit results and the event type, risk level, retention time, or feedback effect in the structured event meta-record: freezing, review, downgrading, rollback, repeat error suppression, failure sample writing, or accountability log update.

[0062] Reference manual attached Figure 7 This diagram illustrates the relationship between continuous information structure field report output and data asset library call according to an embodiment of the present invention.

[0063] Reference manual attached Figure 8 This diagram illustrates a relationship between a structured event meta-record and a write-back target, as provided in an embodiment of the present invention.

[0064] Based on the continuous audit results and risk disposal operations, a continuous information structure field report is generated, and the continuous object core, claim chain, evidence association chain, variable life system, task path system, multimodal object mapping, entity feedback write-back chain, structural event meta record, risk disposal operations, and continuous information structure field report are written into the data asset repository.

[0065] In some embodiments, the data asset library includes an object library, a claim library, a source library, a reference library, a version library, an evidence association chain library, a variable library, a task library, a step library, a multimodal mapping library, a feedback library, a structured event meta-library, a risk library, a failure sample library, an evaluation sample library, or a log library.

[0066] Optionally, the continuous information structure field report includes object core status, claim chain status, evidence association chain status, valid domain status, variable status, task path status, multimodal mapping status, entity feedback write-back status, structured event meta-record status, risk freeze status, rollback objectives, review requirements, or responsibility logs. The continuous information structure field report is output in any of the following formats: text, tables, structured data, JSON (JavaScript Object Notation), XML (Extensible Markup Language), database records, visual interfaces, or API (Application Programming Interface) results.

[0067] Furthermore, the system writes the processing results to the responsibility log, object library, claim library, source library, citation library, version library, evidence association chain library, variable library, task library, multimodal mapping library, feedback library, structural event meta library, risk library, failure sample library, evaluation sample library or write-back library, and calls the updated structural state during future input, retrieval, generation, task execution, variable calling, multimodal mapping, structural event meta audit or risk audit.

[0068] As a result, AI systems are able to continuously maintain the relationships between objects, evidence, variables, tasks, modalities, entity feedback, structural event meta-records, and responsibilities during long-term operation.

[0069] Example 2 Long-term maintenance scenario for AI knowledge base.

[0070] This embodiment illustrates how the present invention can be applied to the long-term maintenance of enterprise AI knowledge bases, research databases, policy databases, technical document databases, or industry knowledge bases. This embodiment focuses on how the system maintains a continuous relationship between the same object, the same claim, and different version sources through fields such as object identifier, claim identifier, source identifier, citation identifier, version status, support status, and event identifier, and automatically downgrades the old claim after the source version is updated.

[0071] In this embodiment, an enterprise or organization establishes an AI knowledge base, which includes multiple documents. These documents may include technical specifications, product manuals, policy documents, regulatory documents, industry reports, research papers, internal regulations, meeting minutes, experimental reports, standard documents, or update announcements.

[0072] The system receives the first batch of documents, including Document A, Document B, and Document C. Document A is a description of a product or technical roadmap, Document B is a relevant standard document, and Document C is internal review comments. The system preprocesses Documents A, B, and C, extracting metadata such as document title, source, upload time, version number, release date, scope of application, author, or responsible organization, and generates source identifiers for each. For example, the system generates source identifier A for Document A, source identifier B for Document B, and source identifier C for Document C. The system also records the version status of each source. If Document A is the first version, the version status is marked as the current version or the first version; if Document B is an effective standard, the version status is marked as the current standard; if Document C is an internal review draft, the version status is marked as a draft or internal review status.

[0073] Subsequently, the user poses a question to the AI ​​knowledge base, such as whether a certain technical solution meets a specific standard requirement, or whether a policy provision still applies to the current business scenario. After receiving the user input, the system first identifies the target object in the user's question and generates or retrieves the corresponding object identifier. For example, if the user's question involves a certain technical solution, the system identifies that technical solution as the target object and generates a technical solution object identifier. If the system already has the same technical solution object in its history, it retrieves the existing object identifier and compares the name, alias, document source, version, scope of application, and historical status to determine if it is the same object. If the names are the same but the scope of application differs, the system can prompt for object boundary verification; if the names are different but the substantive content is the same, the system can merge the objects or establish an alias mapping.

[0074] Next, the system extracts claims from the AI-generated candidate answers, document content, and user questions, generating multiple claim identifiers. Each claim identifier corresponds to a specific claim that can be supported or refuted by evidence. For example: the first claim identifier corresponds to "This technical solution meets requirement Y of standard X"; the second claim identifier corresponds to "This technical solution is applicable to scenario Z"; and the third claim identifier corresponds to "This technical solution can still be executed according to the old parameters in document A". These claim identifiers are then bound to technical solution object identifiers, establishing an evidence association chain. For the first claim identifier, the system retrieves the corresponding standard clause in document B, generates a citation identifier, and associates this claim identifier with source identifier B, citation identifier, version status, and support status. For the second claim identifier, the system retrieves the scope of application descriptions in documents A and C, generating corresponding citation identifiers. For the third claim identifier, the system retrieves the old parameter description in document A and marks the parameter as originating from the first version of document A.

[0075] Further determine whether each cited identifier truly supports the corresponding claim identifier. If the standard clause directly corresponds to the claim content, the support status can be marked as supported; if the source material is only background-related and cannot directly support the claim, the support status can be marked as background-related; if the source material is inconsistent with the claim, the support status can be marked as unsupported or there is evidence to the contrary; if the source version is uncertain, the support status can be marked as pending review.

[0076] During the long-term operation of the knowledge base, the system receives a new document D. Document D is an updated version of document A, or a new standard revision document. After identifying the metadata of document D, the system generates a source identifier D and determines whether there is a version inheritance relationship between source identifier D and source identifier A or source identifier B. The system updates the version status of document A from the current version to replaced or expired, and marks the version status of document D as the current version.

[0077] Subsequently, the system automatically retrieves all claim identifiers citing source identifier A and identifies which claims rely on older versions of the source. If a third claim identifier relies on an older parameter in document A, and document D has modified that parameter, the system downgrades the support status of the third claim identifier from supported to version expired or pending review, and sets the freeze status of the claim to partially frozen or pending review. The system also generates a rollback target to point to the claim status and version source before the update.

[0078] During the aforementioned version update process, the system generates or invokes evidence-type structural event meta-records. The system generates an event identifier for this record, such as an evidence event identifier. The event type of this record is marked as an evidence event; the status difference record indicates that the support status of the third claim identifier changes from supported to version expired or pending review; the phase context record indicates that source identifier A is replaced by source identifier D, and the contextual relationships of related object identifiers, claim identifiers, and citation identifiers; the retention time record indicates that this status is maintained until manual review or confirmation of the new version; the feedback effect record indicates that the system will no longer be able to directly call old version parameters as the basis for current judgments. The system writes this event identifier into the evidence association chain library, structural event meta-record library, responsibility log library, and write-back library, and invokes it in subsequent retrieval generation.

[0079] The system outputs a continuous information structure field report. This report includes: object core status, claim chain status, evidence association chain status, source version status, support status, frozen review status, structural event meta-record status, and responsibility log. Specifically, the object core status includes the name, alias, boundaries, version status, and related documents of the technical solution object identifier; the claim chain status includes the current status of the first claim identifier, second claim identifier, and third claim identifier; the source version status includes whether source identifier A has been replaced by source identifier D, and whether source identifier B is still the current standard; the support status includes which claims are still supported by the current source, and which claims have been downgraded due to version updates; the frozen review status includes which claims need review, and which old conclusions can no longer be directly invoked; the structural event meta-record status includes related event identifiers, status differences, phase context, and feedback effects; and the responsibility log includes when the system received document D, when the version was updated, when related claims were downgraded, and when a review prompt was generated.

[0080] When a user raises a similar question again, the system will retrieve the updated version status, support status, and structural event metadata, and will no longer directly use the parameters from the old version of document A as the basis for the current judgment. If the user requests the system to continue using the conclusion of the old version, the system will indicate that the conclusion has been affected by the updated source and require manual confirmation or expert review.

[0081] Through this embodiment, the present invention enables the AI ​​knowledge base to continuously track the relationships between objects, claims, sources, citations, versions, support, and structural event meta-records during long-term maintenance, and automatically downgrade old claims after the source version is updated, thereby avoiding the AI ​​system from generating pseudo-credible outputs based on outdated data.

[0082] Example 3 Long-term project collaboration scenarios.

[0083] This embodiment illustrates how the present invention can be applied in long-term project collaboration, AI Agent task management, scientific research project advancement, software development tasks, engineering project management, or enterprise workflows. This embodiment focuses on how the system maintains task paths using fields such as task identifier, step identifier, stage status, path version, failure record, rejected path, feedback identifier, future output changes, and event identifier, and writes failed paths, expert rejection opinions, and current feedback back into future task suggestions.

[0084] In this embodiment, the user initiates a long-term project task to the AI ​​system. For example, the user requests the AI ​​system to assist in the development of a technical solution, patent drafting, scientific research experiment design, product testing, software system development, business process optimization, or engineering project advancement.

[0085] After receiving the user's task objective, the system generates a project task identifier and records the objective text, completion criteria, effective domain, and risk level. The objective text records the task objective, the completion criteria record the completion conditions, the effective domain records the scope of application of the task, and the risk level records the risk level of the task. For example, the objective text could be "Complete the feasibility analysis and patent disclosure materials for a certain technical solution"; the completion criteria could include "Complete the technical problem, technical solution, implementation method, draft claims, and drawing structure"; and the risk level could be graded based on whether it involves legal, engineering safety, medical, financial, or high-risk automated decision-making.

[0086] The system breaks down the task into multiple steps based on the task objectives and generates step identifiers for each step. For example, the first step identifier corresponds to "collecting existing data"; the second step identifier corresponds to "identifying the target object and core technical issues"; the third step identifier corresponds to "generating a preliminary technical solution"; the fourth step identifier corresponds to "conducting evidence and boundary audits"; the fifth step identifier corresponds to "writing implementation examples"; the sixth step identifier corresponds to "expert review"; the seventh step identifier corresponds to "revising based on review comments"; and the eighth step identifier corresponds to "forming the final output". The system records the stage status for each step identifier, such as not started, in progress, completed, failed, rejected, frozen, or pending review. The system also generates path versions to identify the version of the task path. The initial task path can be marked as the first path version. During task execution, the AI ​​system accesses documentation, historical records, RAG sources, user feedback, and external tools based on the current step. Each output is bound to the corresponding task identifier and step identifier. If the system generates a technical route suggestion, this suggestion is simultaneously bound to the relevant object identifier and claim identifier, establishing an evidence association chain.

[0087] Suppose that in the third step of the identification process, the system generates a candidate technical route. Subsequently, in the sixth step of the identification process, expert review opinions determine that the technical route is not feasible or that the route has significant risks. After receiving the expert review opinions, the system generates an expert feedback identifier, marking the feedback type as "expert rejection" and the actual result or review result as "rejected".

[0088] The system binds expert feedback identifiers to project task identifiers, third-step identifiers, corresponding object identifiers, and related claim identifiers. Subsequently, the system records this route as a rejected path and generates a failure record. The failure record includes the reason for failure, expert rejection opinion, relevant evidence, risk level, and suggested handling method. Further, suppression rules are generated to prevent future recommendations of the same failed path. For example, when a subsequent user inquires about the technical route for the same project, the system recognizes that the route already has a rejected path record and therefore will no longer recommend this route as a priority solution, or it must explicitly state that the route was previously rejected by experts and require a re-evaluation.

[0089] During the aforementioned expert rejection and write-back process, the system generates or invokes a task feedback-type structured event meta-record. The system generates an event identifier for this record, such as a task event identifier. The event type of this record is marked as a task event or feedback event; the state difference record indicates that the original task path has changed from a candidate path to a rejected path; the phase context record includes the corresponding task identifier, step identifier, object identifier, claim identifier, feedback identifier, and expert review opinion; the retention time record indicates that the rejected path remains valid until the conditions substantially change; and the feedback effect record indicates that this path should not be repeatedly recommended in future identical or similar tasks, or that it must be indicated that the path was previously rejected by experts. The system writes this event to the task database, failure sample database, structured event meta-record database, responsibility log database, and write-back database.

[0090] If new data or conditions change in subsequent stages of the project, the system can generate a second path version. The second path version can retain the historical path, failure nodes, and expert rejection records of the first path version, while adding new task steps, alternative paths, or supplementary verification nodes. The system will not simply overwrite the old path, but will preserve the inheritance, modification, and rollback relationships between path versions.

[0091] In a specific task step, the system invokes an external tool to perform code testing, data analysis, literature retrieval, or experimental parameter calculation. After the tool returns results, the system generates a tool feedback flag and records the results. If the tool executes successfully but the results do not meet the completion criteria, the system marks the result as "tool successful but task incomplete." This status is used to distinguish between "tool invocation successful" and "task objective achieved."

[0092] If a user subsequently executes the AI-suggested solution and provides feedback on the actual result, such as "The experiment was unsuccessful," "The solution was rejected," "The code test failed," or "The client did not accept the solution," the system generates a user feedback identifier and records the actual result as failure, rejection, or non-acceptance. The system writes this feedback back to the project task identifier and corresponding step identifier, and updates the task status and future output changes. Future output changes are used to constrain future outputs. For example, when generating suggestions in the future, the system should avoid failed paths or prioritize indicating that such paths have failed records; if the path must be used again, the system should explain the reason for the previous failure, changes in conditions, and review requirements.

[0093] The system outputs a task path report. This report includes the task objectives and completion criteria, current stage status, execution status of each step, changes between path versions, rejected paths and failure records, expert rejection comments, the relationship between tool results and task objectives, user or real-world feedback results, rules for future output changes, structured event metadata, freeze, review, rollback status, and accountability logs.

[0094] Through this embodiment, the present invention enables the AI ​​system to continuously maintain task objectives, task steps, stage status, failure paths, expert rejections, reality feedback, and structured event records in long-term project collaboration, and write the feedback results back to future task suggestions, thereby avoiding task drift, repeated errors, and misjudgment of tool results.

[0095] Example 4 Multimodal engineering review scenarios.

[0096] This embodiment illustrates the application of the present invention in multimodal engineering review, equipment maintenance, industrial inspection, engineering safety, product testing, accident debriefing, or multi-source data review. This embodiment focuses on how the system maps drawings, photographs, maintenance records, sensor data, tabular data, and text descriptions to the same device object, and identifies conflicts between tabular data and image status.

[0097] In this embodiment, the system receives multimodal data of a certain engineering equipment or product. The multimodal data includes equipment design drawings, on-site photos, maintenance record text, test report forms, sensor data, inspection videos or screenshots, user text descriptions, or engineer remarks.

[0098] The system first preprocesses the input data. For design drawings, the system identifies the drawing number, equipment name, component location, labeled area, and version number. For on-site photos, the system identifies the equipment area, component appearance, damage condition, installation location, and shooting time. For maintenance record text, the system extracts the equipment name, fault description, maintenance time, maintenance personnel, and processing result. For inspection report forms, the system parses the table rows and columns, inspection items, values, units, thresholds, and conclusions. For sensor data, the system extracts the sensor channel, timestamp, measured value, abnormal fluctuations, and data source.

[0099] Secondly, modal object identifiers are generated from different modalities. For example, equipment objects in drawings generate drawing modal object identifiers; equipment objects in photographs generate image modal object identifiers; equipment objects in maintenance records generate text modal object identifiers; equipment objects in inspection tables generate table modal object identifiers; and equipment corresponding to sensor channels generate sensor modal object identifiers.

[0100] Next, candidate mappings are generated based on the device name, serial number, location, drawing area, photo area, maintenance record description, table rows and columns, sensor channels, timestamp, and source version. If the system determines that all the above modal objects point to the same device, it generates or calls the device master object identifier and establishes a multimodal object mapping. This multimodal object mapping records the mapping relationship between different modal objects and the device master object identifier, including modality type, modal object identifier, alias or region, time alignment, version alignment, status observation, evidence role, and confidence level.

[0101] Next, time alignment is performed, organizing the modal data chronologically and determining whether they describe the same equipment's state at the same or different stages. Then, version alignment is performed. If the drawings are older versions, and field photos and maintenance records show the equipment has been modified, the system marks the drawing version as expired or historical, instead of directly using the old drawing status as the current equipment status. Finally, status alignment is performed. If the inspection table shows a certain indicator of the equipment as normal, but field photos show obvious damage, deformation, leakage, corrosion, or abnormal markings on the corresponding component, the system performs conflict detection between the table conclusion and the image status. For example, if a row in the inspection table records "Sealing Status: Qualified," while the corresponding area in the field photo shows a damaged sealing ring, the system marks the table data as "Table Status Observation Normal," marks the image status as "Image Status Observation Damage," and generates a modal conflict record. This conflict is recorded as a table-image status conflict.

[0102] Further determine the role of the evidence. If a site photograph has a clear timestamp and equipment identification, and the image area clearly corresponds to a specific equipment component, the photograph can be marked as direct visual evidence. If the inspection form originates from an internal inspection report but does not include the original data, it can be marked as structured report evidence. If the maintenance record is only a description by an engineer, it can be marked as textual observation evidence. The system can decide whether to output a fusion result, a downgraded result, or a review request based on the role of the evidence and the risk level.

[0103] When the system detects a conflict between table data and image status, it does not directly generate a final judgment of "equipment status qualified," but instead outputs a multimodal conflict report. This report includes the main equipment object identifier, the identifiers of each modal object and their sources, drawings, photos, maintenance records, inspection tables, mapping relationships between sensor data, time alignment results, version alignment results, status observation results, explanations of the conflict between table data and image status, evidence role judgment, whether manual review is required, whether a freeze status has been triggered, and responsibility logs.

[0104] During the aforementioned cross-modal conflict identification process, the system generates or invokes modal class structural event meta-records. The system generates an event identifier for this record, such as a modal event identifier. The event type of this record is tagged as a modal event; the state difference record records the state difference between a table in normal condition and an image in damaged condition; the phase context record records the device master object identifier, table modal object identifier, image modal object identifier, time alignment, version alignment, and evidence role; the retention time record records that the conflict persists until manual inspection or expert review is completed; the feedback effect record records that the system freezes the old conclusion of "equipment condition qualified" and triggers a review request. The system writes this event into the multimodal mapping library, structural event meta-record library, risk library, and responsibility log library.

[0105] If the equipment is classified as high-risk or safety-critical, the system can mark the review request as true and set the freeze status of the relevant conclusion to pending inspection. Simultaneously, the system generates a rollback target to point back to the equipment status judgment before the conflict occurred, preventing the system from continuing to invoke the old conclusion that "equipment status is qualified."

[0106] Through this embodiment, the present invention can map device objects in multimodal data to a unified object core and identify state conflicts between different modalities, thereby improving the reliability of engineering review, multimodal evidence review and device risk identification.

[0107] Example 5 High-risk output freezing scenario.

[0108] This embodiment illustrates the application of the present invention in medical, legal, financial, engineering safety, public governance, juvenile protection, major project decision-making, or other high-risk AI output scenarios. This embodiment focuses on how the system triggers a freeze state, review requirements, rollback targets, and responsibility logs when there is insufficient evidence, version expiration, failure of real-world feedback, missing structural event metadata records, or a missing chain of responsibility.

[0109] In this embodiment, a user poses a high-risk question to the AI ​​system. This question may involve medical advice, legal judgment, financial investment advice, engineering safety assessment, automated implementation plans, risk management plans, or public communication conclusions. After receiving the user input, the system first identifies the target object and generates an object identifier. Subsequently, the system extracts claims from the AI's candidate output and generates claim identifiers. Based on scenario rules or a risk classification model, the system identifies the question as belonging to a high-risk scenario and marks the risk level as high-risk or critical-risk. The system then requires each high-risk claim identifier to be bound to a source, citation, version, support level, and valid domain. If a claim cannot be bound to a valid source identifier or citation identifier, the system marks the support status as unsupported or insufficient evidence. For example, the system generates a claim identifier for a suggestion, but the search results only display background information related to the topic, without finding a current valid source directly supporting the suggestion. The system marks the support status as background-relevant or insufficiently supported and marks the review requirement as true.

[0110] If the system detects that a source has an outdated version, such as using old regulations, guidelines, standards, contract terms, engineering parameters, or experimental data to support the current claim, the system will mark the version status of the corresponding source identifier as outdated and downgrade the support status of the related claim identifier to outdated. The system will also trigger a freeze status, freezing the claim due to version expiration. If the system receives entity feedback indicating that the previous AI suggestion failed in reality (e.g., tool execution failure, experiment failure, invalid user feedback, expert rejection, project approval rejection, or incident sample occurrence), the system will generate a feedback identifier and mark the actual result as failed, rejected, unsafe, or with counter-evidence. The system will write the feedback identifier back to the relevant object identifier, claim identifier, variable identifier, task identifier, or step identifier. If the feedback is directly related to the current candidate output, the system will trigger a freeze or rollback.

[0111] In high-risk scenarios, the system further checks the completeness of the chain of responsibility. If an output cannot specify its source, version, variable calls, task path, feedback status, or structural event metadata, the system marks the responsibility log as incomplete and prohibits that output from being directly published as a final recommendation. The system can generate a prompt: This output lacks a complete chain of responsibility and cannot be used as a professional final review conclusion.

[0112] The system triggers a risk management mechanism, including at least one of the following actions: setting the freeze status to frozen, partially frozen, or pending review; setting the review requirement to true; generating a rollback target pointing to the previous trusted version, the previous confirmed variable, the previous valid task path, or the previous claim status unaffected by counter-evidence; generating a responsibility log to record the risk triggering reason, triggering time, relevant fields, relevant sources, management actions, and responsibility chain status; generating a risk level update; generating suppression rules to prevent the repeated output of the same high-risk recommendations in the future; and outputting a downgraded version, changing the definitive expression to a risk warning, a pending review explanation, or the results of data compilation.

[0113] During the aforementioned high-risk handling process, the system generates or invokes risk-type structured event metadata records. The system generates an event identifier for this record, such as a risk event identifier. The event type of this record is marked as a risk event; the status difference record shows that the relevant claim identifier changes from an output-ready state to frozen or pending review; the phase context record records the object identifier, claim identifier, source identifier, version status, support status, feedback identifier, and risk level corresponding to the risk trigger; the retention time record shows that the frozen state remains until manual review is completed; the feedback effect record shows that the system should not output definitive conclusions in the future, but should instead output downgrade explanations, risk warnings, or review requirements. This event is written to the risk database, structured event metadata database, responsibility log database, and write-back database. For example, when the system detects that a medical-related claim lacks current guideline support, and the user attempts to request the AI ​​to directly provide handling suggestions, the system does not directly output definitive suggestions, but instead outputs a structured prompt indicating that the claim lacks current valid source support and requires professional review, and then freezes the claim. The system records this handling process and invokes the frozen state, risk-type structured event metadata records, and responsibility logs when the user subsequently inquires about the same question again. For example, when the system detects that a project's safety conclusion is based on an old inspection report, while on-site feedback indicates abnormal equipment status, the system freezes the project's safety conclusion and requires manual inspection or professional review. Simultaneously, the system marks the old inspection report as expired or conflicting and writes the on-site feedback into the current result.

[0114] The system ultimately outputs a high-risk output freeze report. This report includes the target object, high-risk claim, source and citation details, version status, support status, effective domain restrictions, entity feedback, structural event metadata, reason for freeze, review requirements, rollback objectives, future output restrictions, and accountability log.

[0115] Through this embodiment, the present invention can identify problems such as insufficient evidence, outdated version, feedback failure, missing structural event meta-records, and missing chain of responsibility in high-risk AI output scenarios, and promptly trigger freeze, review, downgrade, rollback, and responsibility recording, thereby reducing the risk of high-risk AI outputs being misused as definitive conclusions.

[0116] Reference manual attached Figure 9 The diagram shows the overall architecture of a system for constructing and maintaining a continuous information structure field in an AI system, as provided by this invention.

[0117] This invention also provides a system for constructing and maintaining a continuous information structure field in an AI system, comprising: The input object construction module is used to receive project input data and preprocess it to obtain input parsing results. Based on the input parsing results, a continuous object kernel is established, an object identifier is generated, and the object identifier is used as an association index for claims, evidence, variables, tasks, modal objects, feedback, and structured event meta-records. The structural link maintenance module is used to establish a claim chain based on the continuous object core, extract claims associated with the object identifier from the input parsing results and generate claim identifiers; establish an evidence association chain based on the claim chain, the evidence association chain being used to associate the claim identifier with the source identifier, version status, reference identifier and support status; and establish a variable life system, task path system, multimodal object mapping and entity feedback write-back chain based on the continuous object core, the claim chain and the evidence association chain. The event recording module is used to generate or call structured event meta-records based on the state changes in the continuous object kernel, the evidence association chain, the variable life system, the task path system, the multimodal object mapping and the entity feedback write-back chain, and to use the structured event meta-records as the event basis for continuous auditing and risk handling. The continuity audit handling module is used to perform continuity audits based on the continuity object kernel, the claim chain, the evidence association chain, the variable life system, the task path system, the multimodal object mapping, the entity feedback write-back chain, and the structured event meta record, generate continuity audit results, and trigger risk handling operations based on the continuity audit results. The risk handling operations include freezing, review, downgrading, rollback, or accountability records. The report storage and retrieval module is used to generate a continuous information structure field report based on the continuous audit results and the risk disposal operation, and write the continuous object core, the claim chain, the evidence association chain, the variable life system, the task path system, the multimodal object mapping, the entity feedback write-back chain, the structured event meta record, the risk disposal operation, and the continuous information structure field report into the data asset library, and supports subsequent retrieval.

[0118] The AI ​​system continuous information structure field construction and maintenance system provided by the present invention can execute the above-mentioned AI system continuous information structure field construction and maintenance method and achieve the same or similar technical effects. To avoid duplication, the present invention will not elaborate further.

[0119] 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 constructing and maintaining a continuous information structure field in an AI system, characterized in that, The method is executed by at least one processor and includes: Receive project input data and preprocess the project input data to obtain input parsing results; Based on the input parsing results, a continuous object kernel is established, an object identifier is generated, and the object identifier is used as an association index for claims, evidence, variables, tasks, modal objects, feedback, and structured event meta-records; A claim chain is established based on the continuous object kernel, and claims associated with the object identifier are extracted from the input parsing results to generate claim identifiers; An evidence association chain is established based on the claim chain, and the evidence association chain is used to associate the claim identifier with the source identifier, version status, citation identifier and support status. Based on the continuous object kernel, the claim chain, and the evidence association chain, a variable life system, a task path system, a multimodal object mapping, and an entity feedback write-back chain are established. Based on the state changes in the continuous object kernel, the evidence association chain, the variable life system, the task path system, the multimodal object mapping, and the entity feedback write-back chain, a structured event meta-record is generated or invoked, and the structured event meta-record is used as the event basis for continuous auditing and risk disposal. Continuity auditing is performed based on the continuous object kernel, the claim chain, the evidence association chain, the variable life system, the task path system, the multimodal object mapping, the entity feedback write-back chain, and the structured event meta-record, generating continuity audit results; Risk management actions are triggered based on the results of the continuous audit, including freezing, review, downgrading, rollback, or accountability records. Based on the continuous audit results and the risk handling operations, a continuous information structure field report is generated, and the continuous object core, the claim chain, the evidence association chain, the variable life system, the task path system, the multimodal object mapping, the entity feedback write-back chain, the structured event meta-record, the risk handling operations, and the continuous information structure field report are written into the data asset repository.

2. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 1, characterized in that, The project input data includes at least one of the following: user input, historical interaction, document data, RAG source, multimodal material, tool call results, user feedback, expert review opinions, experimental results, accident samples or entity feedback; the preprocessing includes at least one of the following: format parsing, source identification, version identification, timestamp extraction, permission identification, deduplication, cleaning, segmentation, structured parsing or metadata registration.

3. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 1, characterized in that, The continuous object core includes object name, object alias, object type, object boundary, object status, object version, object source, object relationship, object conflict status, object freeze status, or object responsibility log. When establishing the continuous object core, based on the object name, alias, source, version, context relationship, timestamp, multimodal characteristics, or historical object records, it determines objects with the same name but different objects, objects with different names but the same object, object boundary conflicts, object version conflicts, or object status conflicts, and performs at least one of the following operations: object merging, object splitting, object freezing, object review, or object rollback.

4. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 1, characterized in that, The claims in the claim chain include factual claims, data claims, model claims, reasoning claims, prediction claims, suggestion claims, risk claims, conclusion claims, or action claims; the claim identifier, after being bound to the object identifier, is used to determine the object to which the claim belongs, the claim type, the claim status, and the claim responsibility record.

5. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 1, characterized in that, The evidence chain includes source identifier, citation identifier, version status, support status, and valid domain; the valid domain is used to identify the time range, spatial range, object range, industry range, experimental conditions, sample range, risk boundary, professional review requirements, or public expression restrictions of the claim; the support status includes support, partial support, background relevant, no support, counter-evidence exists, version expired, pending review, or frozen.

6. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 5, characterized in that, When a source failure, reference mismatch, version expiration, insufficient support, occurrence of counter-evidence, or valid domain out-of-bounds is detected, at least one of the following actions shall be taken against the relevant claim: evidence downgrading, claim freezing, manual review, accountability recording, or rollback of target registration.

7. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 1, characterized in that, The variable lifecycle system includes variable identifier, variable name, variable type, variable content, variable source, confirmation status, scope of application, version status, conflict status, frozen status, calling conditions, calling records, update records, deletion records, rollback targets or responsibility logs.

8. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 7, characterized in that, When a new variable conflicts with a historical variable, the source of the variable is unknown, the variable expires, the variable is denied by the user, the variable risk increases, or the variable is no longer suitable for use, at least one of the following actions is triggered: variable freezing, variable review, variable downgrading, variable deletion, or variable rollback.

9. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 1, characterized in that, The task path system includes task identifier, target text, completion criteria, step identifier, stage status, path version, rejected path, failure record, suppression rules, task update, future output change or write-back log.

10. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 9, characterized in that, When a task goal drift, step duplication, path failure, repeated occurrence of failed paths, tool execution failure, user rejection, expert refusal, or actual results are detected, at least one of the following actions is triggered: updating the task path, recording failure samples, generating duplicate error suppression rules, changing future output, or review.

11. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 1, characterized in that, The multimodal object mapping includes modality type, modality object identifier, main object identifier, alias or region, time alignment, version alignment, state observation, evidence role, modality conflict, fusion result or review requirements; when establishing the multimodal object mapping, candidate mappings are generated based on name, alias, image region, spatial location, trajectory, speaker, table rows and columns, sensor channels, timestamp, source version, contextual relationship or semantic similarity.

12. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 11, characterized in that, When a mismatch between text and image, audio and text, video event chain misalignment, conflict between table and text evidence, conflict between sensor data and manual records, or uncertainty of multimodal objects is detected, at least one of the following is output: fusion result, downgrade result, conflict prompt, or review request.

13. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 1, characterized in that, The entity feedback write-back chain includes feedback identifier, feedback type, actual result, feedback source, feedback time, related object, related claim, related variable, related task, related step, task update, risk update, future output change or write-back log; when the entity feedback shows tool failure, experiment failure, user denial, expert rejection, actual result not meeting the standard, risk increase or accident occurs, the corresponding object, claim, variable, task or risk status is updated, and future output is constrained, downgraded, frozen or rolled back.

14. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 1, characterized in that, The structured event meta-record is used to record structured change events in the AI ​​system that can affect the state of subsequent objects, claim support, variable state, task path, multimodal mapping state, entity feedback state, risk state, or responsibility state; the structured event meta-record includes event records generated by this system or data records written by an external structured event meta-record generation system.

15. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 14, characterized in that, The structured event metadata record includes at least one of the following: event identifier, event type, state difference, phase context, hold time, feedback effect, write-back target, rollback target, risk level, or responsibility log; the event type includes at least one of the following: object event, evidence event, variable event, task event, modal event, feedback event, risk event, or responsibility event.

16. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 1, characterized in that, The continuity audit includes object continuity audit, evidence continuity audit, variable continuity audit, task continuity audit, modal continuity audit, entity feedback continuity audit, structural event element continuity audit, or responsibility continuity audit; wherein, the structural event element continuity audit is used to determine whether structural changes that can affect the subsequent system state have generated or invoked the structural event element record, and to determine whether the structural event element record has been associated with the corresponding object, claim, evidence, variable, task, modal object, feedback, risk, or responsibility record.

17. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 1, characterized in that, The risk handling operations include triggering at least one of the following actions based on the continuous audit results and the event type, risk level, retention time, or feedback effect in the structured event meta-record: freezing, review, downgrading, rollback, repeat error suppression, failure sample writing, or responsibility log update.

18. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 1, characterized in that, The data asset library includes an object library, claim library, source library, reference library, version library, evidence association chain library, variable library, task library, step library, multimodal mapping library, feedback library, structured event meta-library, risk library, failure sample library, evaluation sample library, or log library.

19. The method for constructing and maintaining a continuous information structure field in an AI system according to claim 1, characterized in that, The continuous information structure field report includes object core status, claim chain status, evidence association chain status, effective domain status, variable status, task path status, multimodal mapping status, entity feedback write-back status, structured event meta-record status, risk freeze status, rollback target, review requirements or responsibility log; the continuous information structure field report is output in any of the following forms: text, table, structured data, JSON, XML, database record, visualization interface or API return result.

20. A system for constructing and maintaining a continuous information structure field in an AI system, characterized in that, include: The input object construction module is used to receive project input data and preprocess it to obtain input parsing results. Based on the input parsing results, a continuous object kernel is established, an object identifier is generated, and the object identifier is used as an association index for claims, evidence, variables, tasks, modal objects, feedback, and structured event meta-records. The structural link maintenance module is used to establish a claim chain based on the continuous object core, extract claims associated with the object identifier from the input parsing results, and generate claim identifiers; An evidence association chain is established based on the claim chain, which is used to associate the claim identifier with the source identifier, version status, citation identifier, and support status; and a variable life system, task path system, multimodal object mapping, and entity feedback write-back chain are established based on the continuous object core, the claim chain, and the evidence association chain. The event recording module is used to generate or call structured event meta-records based on the state changes in the continuous object kernel, the evidence association chain, the variable life system, the task path system, the multimodal object mapping and the entity feedback write-back chain, and to use the structured event meta-records as the event basis for continuous auditing and risk handling. The continuity audit handling module is used to perform continuity audits based on the continuity object kernel, the claim chain, the evidence association chain, the variable life system, the task path system, the multimodal object mapping, the entity feedback write-back chain, and the structured event meta record, generate continuity audit results, and trigger risk handling operations based on the continuity audit results. The risk handling operations include freezing, review, downgrading, rollback, or accountability records. The report storage and retrieval module is used to generate a continuous information structure field report based on the continuous audit results and the risk disposal operation, and write the continuous object core, the claim chain, the evidence association chain, the variable life system, the task path system, the multimodal object mapping, the entity feedback write-back chain, the structured event meta record, the risk disposal operation, and the continuous information structure field report into the data asset library, and supports subsequent retrieval.

21. A device for constructing and maintaining a continuous information structure field in an AI system, 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 method for constructing and maintaining the continuous information structure field of the AI ​​system as described in any one of claims 1 to 19.

22. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the method for constructing and maintaining a continuous information structure field of an AI system as described in any one of claims 1 to 19.

23. A computer program product, characterized in that: The computer program product includes a computer program that, when executed by a processor, implements the method for constructing and maintaining a continuous information structure field of an AI system as described in any one of claims 1 to 19.

Images