SMS auditing system and method based on multi-agent collaboration and graph rag

Abstract

The application provides an SMS auditing system and method based on multi-agent cooperation and GraphRAG, and relates to the technical field of safety management system. The system analyzes structured evidence objects containing evidence types, entity binding, applicable scope and positioning information. Compile the regulatory provisions and inspection sheet items into compliance obligation automata, generate evidence pattern constraints for each obligation state, and perform executable evaluation in evidence pattern language. Based on the joint constraint of knowledge graph structure and vector index, the candidate evidence is retrieved and sorted, and the compliance proof object containing obligation coverage mapping, evidence identification set, conflict / immunity resolution path and recomputable verification instruction is constructed. The verification module checks the coverage, pattern satisfaction, resolution consistency and positioning traceability. When the verification fails, the counterexample object is generated and the retrieval constraint and graph traversal boundary are automatically rewritten to close the loop and converge, and the low confidence prompt is output combined with the counterfactual stability check.

Description

Technical Field

[0001] This invention relates to the field of security management system technology, specifically to an SMS auditing system and method based on multi-agent collaboration and GraphRAG. Background Technology

[0002] Safety Management System (SMS) audits are a crucial part of the safety management compliance assessment for civil aviation operators. They typically require a thorough review of numerous closed-loop materials, including regulations, organizational procedures, records, investigation reports, and corrective actions, to determine if they meet regulatory and checklist requirements. Current SMS audits largely rely on manual reading and experience-based judgment, which leads to problems such as high workload, long audit cycles, inconsistent conclusions, unclear evidence positioning, and high review costs. This is especially true when multiple versions of regulations coexist, have different scopes of application, and involve both exemptions and conflicting clauses; manual audits are prone to omissions, misuse of clauses, or inaccurate citation of evidence.

[0003] In recent years, text retrieval, information extraction, and large-model-based question-and-answer assisted auditing technologies have improved retrieval efficiency to some extent, but still have several limitations: First, retrieval or generative outputs are mostly based on natural language interpretation, lacking a machine-verifiable compliance proof structure, making it difficult to perform deterministic recalculation in audit, review, or dispute scenarios; second, evidence recall often relies on similarity ranking, which is prone to mismatch or omission when faced with non-pure text evidence such as table records, flowcharts, and organizational responsibility mappings; third, when the output conclusions have missing evidence, conflicts, or unclear applicable conditions, existing solutions often can only rely on manual trial and error through repeated searches or adjustments to prompts, lacking an automated convergence mechanism based on the reasons for failure, resulting in high iteration costs and insufficient result stability. Therefore, there is an urgent need for an SMS auditing technology solution that can formalize regulatory and checklist requirements into an enforceable obligation structure, categorize and bind evidence, and enable machine-verifiable recalculation of conclusions and closed-loop convergence driven by counterexamples, in order to improve the credibility, traceability, and robustness of audits. Summary of the Invention

[0004] Technical problems to be solved

[0005] To address the shortcomings of existing technologies, this invention provides an SMS auditing system and method based on multi-agent collaboration and GraphRAG, which solves the problems of existing technologies.

[0006] Technical solution

[0007] To achieve the above objectives, the present invention provides the following technical solution: an SMS auditing system based on multi-agent collaboration and GraphRAG, comprising:

[0008] The data management module is used to version-store the documents to be reviewed, the regulatory clause library and the audit checklist, and to generate evidence location metadata for document fragments, including source document identifiers, page numbers or paragraph boundaries, and table row and column coordinates.

[0009] The normalization parsing module is used to parse text paragraphs, table cells, and process / organizational structure type graphic information into a unified structured evidence object. The structured evidence object includes at least an evidence type field, an entity binding field, a time or scope of application field, and the evidence location metadata.

[0010] The regulatory checklist compilation module is used to compile regulatory clauses and checklist items into a compliance obligation automaton, wherein the compliance obligation automaton includes at least: a set of obligation states, a set of triggering conditions, a set of transfer rules, and an evidence pattern constraint corresponding to each obligation state; the evidence pattern constraint at least defines the evidence type, the mandatory entity, the allowed time range, and the applicable subject.

[0011] The graph retrieval enhancement module is used to retrieve a set of candidate evidence objects for each obligation state under the joint constraints of the knowledge graph structure and vector index, and output the ranking results of the candidate evidence objects according to the degree of matching with the evidence pattern constraints.

[0012] The compliance proof construction module is used to select a subset of evidence that satisfies the compliance obligation automaton from the candidate evidence object set and construct a compliance proof object. The compliance proof object includes at least: a conclusion, an obligation state coverage mapping, an evidence object identifier set, a conflict / exemption resolution path, and a recalcible verification instruction.

[0013] The proof verification module is used to perform verification on the compliant proof object according to the recalculated verification instruction. The verification includes at least: obligation status coverage verification, evidence mode constraint satisfaction verification, conflict / exemption resolution consistency verification, and evidence location traceability verification.

[0014] The counterexample-driven evidence convergence module is used to output a counterexample object when the machine verification fails. The counterexample object includes at least the failure obligation state, failure constraint type, missing entity or missing evidence type, and evidence path that leads to conflict. Based on the counterexample object, the module automatically rewrites the retrieval constraints and graph traversal boundaries to trigger the graph retrieval enhancement module and compliance proof construction module again until the machine verification is passed or the iteration limit is reached.

[0015] The task orchestration module is used to schedule the above modules in parallel or serially at the granularity of checking a single item. When the machine verification still fails after reaching the iteration limit, it outputs a low confidence mark and generates a list to be manually reviewed.

[0016] Preferably, the regulation-checklist compilation module decomposes the normative statements in the regulation clauses into at least three types of atomic obligations according to their semantic roles: mandatory obligations, prohibited obligations, and conditional obligations, and maps each atomic obligation to an obligation state in the compliance obligation automaton; wherein the conditional obligations are compiled into Boolean conditions and interval conditions in the triggering condition set, and the transfer rule set includes at least: condition satisfaction transfer, exemption trigger transfer, and conflict priority transfer.

[0017] Preferably, the evidence pattern constraints are defined using an executable evidence pattern language, which includes at least:

[0018] The evidence type predicate is used to specify that the evidence must come from at least one of the following: a text paragraph, a table cell, a process step, or a mapping of organizational responsibilities.

[0019] The entity binding predicate is used to restrict evidence to be bound to at least one organizational entity and at least one responsibility / process entity simultaneously.

[0020] The time interval predicate is used to limit the effective period of the evidence;

[0021] Structural location predicates are used to limit the evidence location metadata to meet preset chapter or table location rules;

[0022] Furthermore, the verification module determines whether the evidence can serve as valid evidence of the corresponding obligation state by evaluating the evidence pattern language.

[0023] Preferably, the recalculable verification instruction includes at least: a retrieval parameter snapshot, a knowledge graph structure version number, an evidence pattern language version number, and a deterministic execution seed; the proof verification module performs recalculable verification on the compliant proof object and outputs a verification report under the condition of fixing the retrieval parameter snapshot and the deterministic execution seed, and the verification report includes at least a list of failed obligation statuses and corresponding counterexample object generation information.

[0024] Preferably, the conflict / exemption resolution path is recorded in the compliance proof object in the form of a directed path, and the directed path includes at least a conflict clause node, a priority rule node, and a covered clause node; when the proof verification module detects that valid evidence corresponding to the same obligation state simultaneously satisfies the mutual exclusion constraint, if the compliance proof object lacks the conflict / exemption resolution path, the verification is deemed to have failed and a counterexample object containing the mutual exclusion evidence path is generated.

[0025] Preferably, the counterexample-driven evidence convergence module executes at least one rewriting strategy based on the counterexample object:

[0026] Promote the missing evidence type in the evidence pattern constraint corresponding to the failure obligation state to a mandatory evidence type constraint.

[0027] Add the missing entity to the set of entities that must be included in the search and restrict graph traversal to only allow passing through the dependent edges or reference edges associated with the missing entity;

[0028] When a counterexample contains a conflicting evidence path, force the retrieval of evidence objects containing exemption triggering conditions or conflict priority rules.

[0029] After each rewrite, the compliance proof object is reconstructed and machine-verified to form a closed-loop convergence of "counterexample-rewrite-machine verification".

[0030] Preferred methods include:

[0031] S1. Perform standardized parsing on the documents to be reviewed to generate structured evidence objects containing evidence type, entity binding, time or scope of application and location metadata;

[0032] S2. Compile the regulatory clauses and checklist items into a compliance obligation automaton, and generate a set of obligation states and the evidence pattern constraints corresponding to each obligation state.

[0033] S3. Based on the knowledge graph structure and vector index, retrieve the set of candidate evidence objects for each obligation state and sort them according to the degree of matching with the evidence pattern constraint.

[0034] S4. Select a subset of evidence from the candidate evidence object set to construct a compliance proof object, wherein the compliance proof object includes at least an obligation state coverage mapping, a conflict / exemption resolution path, and a recalcible verification instruction.

[0035] S5. Perform the verification test. If the verification passes, output the item-level conclusion and the compliance verification object.

[0036] S6. If the machine test fails, generate a counterexample object, and rewrite the retrieval constraints and graph traversal boundaries based on the counterexample object, then return to execute S3 to S5 until the machine test passes or the iteration limit is reached.

[0037] S7. If the machine verification still fails after reaching the iteration limit, output a low confidence level flag and generate a list of items to be manually reviewed.

[0038] Preferably, when constructing the compliance proof object in S4, the obligation state coverage mapping is transformed into a set coverage constraint problem, and under the premise of satisfying all obligation state evidence pattern constraints, the minimum cardinality solution or the minimum weighted cost solution of the evidence object identifier set is obtained, and the minimum solution is used as the evidence subset in the compliance proof object.

[0039] Preferably, stability verification is performed before outputting the entry-level conclusion. The stability verification includes: performing bounded perturbation on the set of triggering conditions in the compliance obligation automaton to generate a set of counterfactual conditions, and repeatedly executing S3 to S5 under each counterfactual condition to obtain a counterfactual compliance proof object; when the difference between the obligation state coverage mapping of the counterfactual compliance proof object and the obligation state coverage mapping of the original compliance proof object exceeds a threshold, the entry-level conclusion is marked as low confidence or requires manual confirmation.

[0040] Preferably, it also includes the step of building and applying a library of counterexample patterns:

[0041] The counterexample objects generated in S6 are used to extract counterexample signatures according to preset signature rules. The counterexample signature includes at least the failure obligation status identifier, failure constraint type, missing evidence type, missing entity set, and relation type sequence of conflicting evidence paths. The counterexample signature and the corresponding retrieval constraint rewriting strategy are stored in the counterexample pattern library. Before executing S3 on a new checklist item, an item feature vector is generated based on the obligation status set and evidence pattern constraints corresponding to the item, and matched with the counterexample signature in the counterexample pattern library. When the matching degree exceeds the threshold, the corresponding retrieval constraint rewriting strategy and graph traversal boundary limit are automatically preset before the first retrieval to reduce the number of counterexample-rewriting-machine verification iterations and improve the machine verification pass rate.

[0042] Beneficial effects

[0043] This invention provides an SMS auditing system and method based on multi-agent collaboration and GraphRAG. It has the following beneficial effects:

[0044] 1. This invention compiles regulatory clauses and checklist items into a compliance obligation automaton, applies executable constraints to the evidence objects using an evidence pattern language, and then outputs a compliance proof object containing an obligation state coverage mapping, evidence location metadata, and recalculated verification instructions by a compliance proof construction module. Finally, a proof verification module verifies the coverage, pattern satisfaction, conflict / exemption resolution consistency, and location tracing. This allows the system output to move beyond natural language "judgments" and be repeatedly verified under fixed parameter snapshots and deterministic seeds, thereby reducing disputes caused by black-box reasoning and supporting auditing and review.

[0045] 2. When the machine verification fails, the present invention outputs a counterexample object containing the failure obligation state, failure constraint type, missing entity / missing evidence type, and conflict path in the counterexample driving evidence convergence module. Based on this, the retrieval constraints and graph traversal boundaries are automatically rewritten, driving the graph retrieval enhancement and proof construction to be re-executed, converging from "wide recall" to the minimum necessary evidence space that "satisfies the gap". At the same time, the common failure modes are signed and the strategy is reused through the counterexample pattern library, so that the rewriting strategy can be preset before the first retrieval of similar entries, thereby reducing the number of counterexample-rewriting-machine verification cycles and shortening the review time. Attached Figure Description

[0046] Fig. 1 This is a block diagram of the overall system structure of the present invention;

[0047] Fig. 2 This is a data structure diagram of the structured evidence object and evidence location metadata of the present invention;

[0048] Fig. 3 This describes the construction and verification process for the compliance certification object of the present invention. Detailed Implementation

[0049] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Specific Implementation Example 1:

[0051] like Figs. 1 to 3 As shown, the SMS auditing system based on multi-agent collaboration and GraphRAG includes: a data management module, which is used to version-store the documents to be audited, the regulatory clause library and the audit checklist, and to generate evidence location metadata for document fragments, including source document identifiers, page numbers or paragraph boundaries, and table row and column coordinates;

[0052] The data management module preferably consists of the following sub-units: Object Registration Unit: Generates globally unique object IDs. Version Control Unit: Versions documents / regulations / checklists; maintains version dependency graphs. Evidence Location Metadata Generation Unit: Generates location metadata for each file fragment. Consistency and Audit Unit: Verifies version, location, and hash and records logs. The versioned storage data model defines version objects as follows:

[0053]

[0054] : A globally unique identifier for an object (e.g., UUID or Snowflake ID). : Object type, values ​​such as . Version number (integer or semantic version). Content hash (e.g., SHA-256). : Entry timestamp. : Parent version ID (used in version chain / version tree). Metadata collection (key-value pairs including uploader, source, organization, and scope of application). Evidence location metadata is defined as: Source file ID. Character range ,in Index for the starting character, This is the index for the end character. Page number (PDF / paged document). Paragraph boundaries Indicates the start and end numbers of the paragraph. Table number (e.g., which table). Cell coordinates ,in For row index, For column indexes. Page frame coordinates . Anchor points (such as heading number "4.2.1" or clause number) facilitate cross-version alignment.

[0055] Data acquisition / processing / output

[0056] Data collection: Upload files, import regulations from the database, import checklists; and receive "version release events".

[0057] Processing: Calculate the hash Establish parent relationships and generate location metadata. .

[0058] Output: Outputs "Traceable Evidence Object ID + Location Metadata" to downstream modules for proof, machine verification, and playback.

[0059] The normalization parsing module is used to parse text paragraphs, table cells, and process / organizational structure graphical information into unified structured evidence objects. The structured evidence objects include at least the evidence type field, entity binding field, time or scope of application field, and evidence location metadata.

[0060] The structured evidence object definition for a single piece of evidence is as follows:

[0061]

[0062] : Evidence object ID. Evidence type (type) . : Evidence content payload; if ,but It is a text string; if ,but For table cell content and row / column context; if ,but For the set of process nodes / edges; if ,but Mapping organizational structure nodes / responsibilities. Entity bindings ;in For entity ID, Entity type (organization, position, process, risk, etc.) To bind confidence levels. : Time or scope field ;in The effective start and end dates; For applicable organizational sets; A collection of regions; For the set of execution scope / execution type. : Evidence location metadata (defined in the previous section).

[0063] The parsing algorithm's operating logic involves text paragraph parsing: chapter detection → paragraph boundary recognition → clause number recognition → slicing (with overlapping windows).

[0064] Table parsing: Table inspection → Row and column structure restoration → Cell extraction → Binding with table header / row header to form contextual evidence.

[0065] Process / Organizational Chart Analysis: For vector graphics / parsable objects: extract node text and connection relationships; for images: perform layout structure detection + OCR / text detection + connection topology fitting; ultimately forming the graph structure. ,in For a set of nodes, Let it be the set of edges.

[0066] Input: Original file version object + File content.

[0067] Output: Collection of evidence objects It also outputs the entity binding index, time range index, and structural location index.

[0068] The regulatory checklist compilation module is used to compile regulatory clauses and checklist items into a compliance obligation automaton. The compliance obligation automaton includes at least: a set of obligation states, a set of triggering conditions, a set of transfer rules, and an evidence pattern constraint corresponding to each obligation state. The evidence pattern constraint at least specifies the evidence type, mandatory entities, allowed time range, and applicable subjects.

[0069] The natural language regulations and checklists are "compiled" into executable obligation automata, making subsequent proof / machine verification "calculated and verifiable".

[0070] The compliance obligation automaton is defined as:

[0071]

[0072] : A set of obligation states (each state represents an atomic obligation / checkpoint), such as "Procedure established", "Training recorded", etc. Initial state. : Acceptable / Completed status set (indicating that all obligations are met or met to the required level). : Triggering condition set Each It is a combination of Boolean and range constraints (such as applicable subject, time effective, and operating range). : Set of transfer rules ,in : Indicates the state Under the following conditions, And read in the evidence object It was then transferred to a new state. Evidence pattern constraint mapping Map each obligation state to an evidence pattern constraint. .in Represents the space of all evidence objects. This represents the set of constraint expressions in the evidence pattern language.

[0073] Evidence model constraints For any state Define evidence pattern constraints:

[0074]

[0075] Allows a set of evidence types (such as {text, table}). : Must contain a set of entities / relationships (e.g., must include “responsible department”, “job responsibilities”, “process nodes”, etc.). : Applicable subject set (organization / position / operating unit constraints). : Permissible time range (effective period). : Structural location constraints (e.g., must come from "Chapter 4.2" or "Record Table").

[0076] The compiled algorithm execution logic checks each checklist entry. : Retrieve the corresponding set of legal provisions For each clause Perform "standard tone recognition" (must / should / must not / may / except, etc.); extract semantic roles: subject (who), action / requirement (what to do), object (to what), condition (under what circumstances), exception (exemption), conflict priority (new law prevails over old law / specific law prevails over general law, etc.); generate a set of atomic obligations and map them to states. Simultaneously generate triggering conditions Transfer Evidence Model The automaton that merges the entries yields the final entry. And it is bound to the checklist entry ID.

[0077] The graph retrieval enhancement module is used to retrieve a set of candidate evidence objects for each obligation state under the joint constraints of knowledge graph structure and vector index, and output the ranking results of candidate evidence objects according to the degree of matching with the evidence pattern constraints.

[0078] The mathematical modeling representation of knowledge graphs and vector indexes is as follows:

[0079]

[0080] Entity node set (organization, position, process, risk, clause, etc.). : A set of relation edges (references, dependencies, applicability, exemptions, conflicts, etc.). Node attribute functions (text, time, scope, etc.). Edge type function.

[0081] Vector index: for each evidence object Calculate the embedding vector:

[0082]

[0083] in For vector dimensions.

[0084] Candidate set retrieval and ranking for the obligation state Construct query representation (Based on a fusion of clause text, checklist descriptions, and the set of mandatory entities, etc.) A set of candidate evidence is obtained. For each candidate piece of evidence Calculate the overall score:

[0085]

[0086] : Learnable or configurable weight coefficients. Vector similarity functions (such as cosine similarity). Graph relevance score represents the graph distance or path confidence from the evidence-bound entity to the state that must contain the entity / relationship. Pattern matching score, representing the evidence object. Constraints on Evidence Patterns The degree of satisfaction (can be 0 / 1 or graded).

[0087] Output the sorted candidate set:

[0088]

[0089] Input: Obligation status Evidence Model Knowledge graph Vector index.

[0090] Output: (Including the ID, location metadata, and matching explanation for each piece of evidence: which predicates are satisfied / not satisfied).

[0091] The compliance proof construction module is used to select a subset of evidence that satisfies the compliance obligation automaton from the candidate evidence object set and construct a compliance proof object. The compliance proof object includes at least: a conclusion, an obligation state coverage mapping, a set of evidence object identifiers, a conflict / exemption resolution path, and a recalcible verification instruction.

[0092] Proof Object Data Structure

[0093] Define the compliance proof object:

[0094]

[0095] Conclusion (compliant / non-compliant / requires manual confirmation / low confidence level, etc.). Obligation state overlay mapping, This indicates which pieces of evidence support each state. : A set of evidence object identifiers (a list of evidence IDs). : Set of conflict / waiver resolution paths (represented as graph paths). : Recalculated verification instructions (including parameter snapshot, version number, random seed, etc., which will be further refined in the fourth section).

[0096] The optimization model for evidence subset selection (set coverage / weighted minimization) transforms "covering all necessary obligation states" into a 0-1 optimization:

[0097]

[0098]

[0099]

[0100] Binary decision variables, choosing evidence Otherwise, it is 0. Evidence cost / penalty (which may consist of evidence length, noise risk, version uncertainty, location reliability, etc.). The set of obligatory states that must be covered (determined by the automaton and the triggering conditions). : Override indicator function, if evidence Satisfied state Pattern constraints (i.e.) And if the applicable conditions are met), then Otherwise, it is 0. :state The set of candidate evidence. Output a subset of evidence: and generate overlay mapping .

[0101] The proof verification module is used to perform verification on compliant proof objects according to recalculated verification instructions. The verification includes at least: obligation status coverage verification, evidence mode constraint satisfaction verification, conflict / exemption resolution consistency verification, and evidence location traceability verification.

[0102] Formal definition of the test function:

[0103]

[0104] in To prove the object, For duty automata, This is a knowledge graph.

[0105] Four types of verification rules: Obligation status overwrite verification:

[0106]

[0107] If it exists make If so, the failure type is "overwrite failure".

[0108] Evidence pattern constraint satisfaction verification: for each ,right :

[0109]

[0110] in For the evidence pattern language interpreter (see Item 3 Preferred), return 0 / 1.

[0111] Conflict / Exemption Resolution Consistency Verification: If a conflicting edge or exemption edge exists in the knowledge graph and affects the current state conclusion, then a corresponding path must exist. And it meets the priority rules; otherwise, the failure type is "resolve missing / inconsistent".

[0112] Evidence location traceability verification: Each evidence ID in the proof must be traceable back to the location metadata. ,and Version exists:

[0113]

[0114] Output verification report (structured): pass / fail; if it fails, it provides the failure status, failure predicate, relevant evidence, conflict path, etc., which is directly consumed by the counterexample module.

[0115] The counterexample-driven evidence convergence module is used to output counterexample objects when the machine verification fails. The counterexample object contains at least the failed obligation state, the failed constraint type, the missing entity or the missing evidence type, and the evidence path that caused the conflict. Based on the counterexample object, the retrieval constraints and graph traversal boundaries are automatically rewritten to trigger the graph retrieval enhancement module and the compliance proof construction module again until the machine verification is passed or the iteration limit is reached.

[0116] Counterexample data structure

[0117]

[0118] : Failed state. Failure constraint type (e.g., coverage / match / conflict / trace). : The set of missing evidence types (e.g., missing table evidence). : Missing entity or set of relationships (e.g., missing "responsible department entity"). : Evidence paths that lead to conflict (graph paths or evidence chain paths).

[0119] Counterexample-driven rewriting (formal update rules) represents the retrieval constraints as follows:

[0120]

[0121] : A set of entities that must be included; : Must contain the set of evidence types; Maximum number of hops in graph traversal; : The set of allowed relation types.

[0122] Update based on counterexamples:

[0123] like ,but ,like ,but and will To narrow the traversal boundaries;

[0124] If it exists This will force the inclusion of "exemption / conflict priority" related relationships. And increase the ranking weight of relevant evidence.

[0125] The closed loop repeats: retrieval → constructing proof → machine verification → generating counterexamples → rewriting, until it passes or reaches the upper limit.

[0126] The task orchestration module is used to schedule the above modules in parallel or serially at the granularity of checking a single item. When the machine verification still fails after reaching the iteration limit, it outputs a low confidence mark and generates a list to be manually reviewed.

[0127] The scheduling object and its dependencies, each task entry is defined as follows:

[0128]

[0129] : Check single entry ID; The automaton of this entry; : Status (pending / running / passed / failed / low-conf). : Current iteration number; Risk level (optional, used for resource allocation). Dependency set (serialized if there are references / precedence relationships between entries).

[0130] Parallel / serial rules:

[0131] like Multiple can be executed in parallel. .

[0132] If a dependency edge exists , then first back .

[0133] like If Verify=0 is still active, then mark it as low-conf and enter the manual review queue.

[0134] Item level: Conclusion + Compliance proof object + Machine verification report / counterexample chain.

[0135] Document level: Review checklist (items, reasons for failure, suggestions for locating missing evidence).

[0136] The regulatory checklist compilation module decomposes statements with normative tone in regulatory clauses into at least three types of atomic obligations according to their semantic roles: mandatory obligations, prohibited obligations, and conditional obligations. Each atomic obligation is mapped to an obligation state in the compliance obligation automaton. Among them, conditional obligations are compiled into Boolean conditions and interval conditions in the triggering condition set, and the transfer rule set includes at least: condition satisfaction transfer, exemption trigger transfer, and conflict priority transfer.

[0137] The conversion from atomic obligations to logical constraints requires class obligations (MUST): generative constraints. (State must be overridden). MUST-NOT obligations: Generate mutual exclusion constraints. Or "negative evidence model". Conditional obligations (IF / WHEN): generate triggering conditions. :

[0138] It is a combination of Boolean predicates; For interval predicates (such as) ).

[0139] satisfy Only then is the corresponding state added. .

[0140] Evidence pattern constraints are defined using an executable evidence pattern language, which includes at least: an evidence type predicate, specifying that the evidence must originate from at least one of the following: a text paragraph, a table cell, a process step, or an organizational responsibility mapping; an entity binding predicate, specifying that the evidence must be bound to at least one organizational entity and at least one responsibility / process entity; a time interval predicate, specifying the effective time interval for which the evidence is applicable; and a structural location predicate, specifying that the evidence's location metadata must satisfy preset chapter or table location rules. The verification module then evaluates the evidence pattern language to determine whether the evidence is valid evidence for the corresponding obligation status.

[0141] The executable syntax and evaluation of the evidence pattern language can be defined as a conjunction of four types of predicates:

[0142]

[0143] : Evidence type predicate, judgment . Entity binding predicate, judgment Organizational entities and process / responsibility entities meet the binding threshold. Time interval predicate, judgment . : Structural position predicate, judgment Or a set of table position matching rules .

[0144] Evaluation function:

[0145]

[0146] The recalculable verification instruction includes at least: a retrieval parameter snapshot, a knowledge graph structure version number, an evidence pattern language version number, and a deterministic execution seed; the proof verification module performs recalculable verification on the compliant proof object under the condition of a fixed retrieval parameter snapshot and a deterministic execution seed and outputs a verification report, which includes at least a list of failed obligation statuses and corresponding counterexample object generation information.

[0147] The "retrieval parameter snapshot" should at least include: TopK, weights, etc. Maximum number of jumps Permissible set of relations Similarity thresholds, etc.

[0148] The "deterministic execution seed" is used to fix the order of candidate set sorting, sampling selection, and parallel merging, ensuring that recalculation can be consistently reproduced.

[0149] The conflict / exemption resolution path is recorded in the compliance proof object in the form of a directed path. The directed path must contain at least the conflict clause node, the priority rule node, and the covered clause node. When the proof verification module detects that valid evidence corresponding to the same obligation state satisfies the mutual exclusion constraint, if the compliance proof object lacks a conflict / exemption resolution path, the verification is deemed to have failed and a counterexample object containing the mutually exclusive evidence path is generated.

[0150] Examples of mutually exclusive constraints: the same obligation requires "records must be kept" and evidence shows "records are exempt / not required"; or two clauses give opposite requirements under the same conditions.

[0151] Priority rule nodes can be encoded as follows: priority of effective time, priority of special law, priority of exemption, etc.; during machine verification, it must be able to explain why one of the rules is selected along the path.

[0152] The counterexample-driven evidence convergence module executes at least one rewriting strategy based on the counterexample object: It elevates the missing evidence type in the evidence pattern constraint corresponding to the failed obligation state to a mandatory evidence type constraint; it adds the missing entity to the set of entities that must be included in the retrieval and restricts graph traversal to only allow traversal of dependency edges or reference edges associated with the missing entity; when the counterexample object contains conflicting evidence paths, it forces the retrieval of evidence objects containing exemption triggering conditions or conflict priority rules; and after each rewriting, it reconstructs the compliant proof object and performs machine verification to form a closed-loop convergence of "counterexample—rewriting—machine verification".

[0153] Counterexamples structure the reasons for failure as The rewrite narrows the retrieval space from "wide recall" to "the minimum necessary space to satisfy the gap"; by fixing "mandatory evidence type / mandatory entity / permitted relation", the candidate set is significantly constrained, and the set coverage constraint of the proof is easier to satisfy and more stable.

[0154] The main workflow includes: S1. Standardizing and parsing the documents to be reviewed to generate structured evidence objects containing evidence type, entity binding, time or scope of application, and location metadata; S2. Compiling regulatory clauses and checklist items into a compliance obligation automaton to generate a set of obligation states and evidence pattern constraints corresponding to each obligation state; S3. Retrieving a set of candidate evidence objects for each obligation state based on a knowledge graph structure and vector index, and sorting them according to their matching degree with the evidence pattern constraints; S4. Selecting a subset of evidence from the candidate evidence object set to construct a compliance proof object, which must at least include an obligation state coverage mapping, conflict / exemption resolution path, and recalculated verification instructions; S5. Performing the proof verification. If the verification passes, outputting an item-level conclusion and a compliance proof object; S6. If the verification fails, generating a counterexample object, rewriting the retrieval constraints and graph traversal boundaries based on the counterexample object, and returning to execute S3 to S5 until the verification passes or the iteration limit is reached; S7. If the verification still fails after reaching the iteration limit, outputting a low-confidence flag and generating a list of objects to be manually reviewed.

[0155] S1 corresponds to the "standardized parsing module + data management module": producing a set of evidence objects. And index. S2 corresponds to the "Regulations - Checklist Compilation Module": Production Automaton Pattern constraints S3 corresponds to the "Graph Retrieval Enhancement Module": it generates a candidate set for each state. S4 corresponds to the "Compliance Proof Construction Module": it solves for set coverage optimization to obtain the proof object. S5 corresponds to the "Proof Verification Module": Verify(P, A, G) completes if successful. S6 corresponds to the "Counterexample-Driven Evidence Convergence Module": Generates a CE, rewrites constraints, and returns to S3. S7 corresponds to the "Task Orchestration Module": Manages the iteration limit and manual review output.

[0156] When constructing the compliance proof object in S4, the obligation state coverage mapping is transformed into a set coverage constraint problem. Under the premise of satisfying all obligation state evidence pattern constraints, the minimum cardinality solution or the minimum weighted cost solution of the evidence object identifier set is obtained, and the minimum solution is taken as the evidence subset in the compliance proof object.

[0157] Minimum cardinality: target It emphasizes "proof with minimal evidence," reducing redundancy and noise. Minimum weighted cost: the objective. Evidence with "low location credibility or uncertain version" can be given a higher price, thus prioritizing more reliable evidence.

[0158] Before outputting the entry-level conclusion, a stability check is performed. The stability check includes: performing a bounded perturbation on the set of triggering conditions in the compliance obligation automaton to generate a set of counterfactual conditions, and repeatedly executing S3 to S5 under each counterfactual condition to obtain a counterfactual compliance proof object; when the difference between the obligation state coverage mapping of the counterfactual compliance proof object and the obligation state coverage mapping of the original compliance proof object exceeds a threshold, the entry-level conclusion is marked as low confidence or requires manual confirmation.

[0159] Bounded perturbation: adding or deleting one organization from the main set, or shifting the time interval forward or backward. Operation types such as switching the operating range. The degree of difference in coverage mapping can be defined as:

[0160]

[0161] in For indicator functions; if (threshold) If it is not stable, then it is considered unstable.

[0162] The counterexample pattern library also includes the steps of building and applying the counterexample pattern library: Extracting counterexample signatures from the counterexample objects generated in S6 according to preset signature rules; the counterexample signature includes at least the failure obligation status identifier, failure constraint type, missing evidence type, missing entity set, and relation type sequence of conflicting evidence paths; storing the counterexample signature and the corresponding retrieval constraint rewriting strategy in the counterexample pattern library; before executing S3 on a new checklist item, generating an item feature vector based on the corresponding obligation status set and evidence pattern constraints, and matching it with the counterexample signature in the counterexample pattern library; when the matching degree exceeds a threshold, automatically presetting the corresponding retrieval constraint rewriting strategy and graph traversal boundary limits before the first retrieval to reduce the number of counterexample-rewriting-machine verification iterations and improve the machine verification pass rate.

[0163] Signature matching and pre-defined strategies: The entry feature vector can be constructed by concatenating the following: histogram of obligation state type, distribution of evidence type requirements, set of mandatory entity categories, and set of relation type requirements. The matching degree can be achieved using cosine similarity or Jaccard similarity; if the threshold is exceeded, the rewriting strategy corresponding to "common failures" is applied in advance to achieve "zero or few iterations" of success. Specific Implementation Example 2:

[0165] SMS training plan and training record compliance verification: In this embodiment, the object to be verified is the SMS training management related materials of an operating unit in 2025. The input files include "SMS Manual V3.2.pdf", "Annual Training Plan 2025.docx" and "Training Record Ledger 2025.xlsx". The regulatory clause library uses the SMS training requirement clause set of version v2024.10. The audit checklist selects item C-TRN-01, whose item description is "whether an SMS training plan has been established and implemented, and whether the training records are kept traceable". The system first uses a data management module to version-store the three documents to be reviewed, the regulatory clause library, and the checklist. It generates a content hash and version number (e.g., ver=3.2, ver=2025.1, etc.) for each document and pre-assigns a source document identifier (doc_id) for subsequent evidence extraction. At the evidence location metadata level, the system retains page numbers (page), paragraph boundaries (para), and character spans (span) for PDF materials, and table numbers (table) and cell row and column coordinates for table materials. It also additionally retains chapter anchors to support cross-version alignment and location verification.

[0166] The system then proceeds to the standardized parsing module. For Word / PDF text, it uses heading level recognition and clause number recognition to determine paragraph structure. For Excel, it uses table area detection and row / column structure recovery to extract cell evidence and uniformly generate a set of structured evidence objects. To enable the evidence object to be directly evaluated by the subsequent evidence pattern language, the evidence object in this embodiment includes at least the following fields: evidence type tau (value is text or table), content payload x (text string or table row context structure), entity binding phi (organization entity, process entity, job entity and its binding confidence conf), scope of application pi (effective time interval, organization set, operating scope set), and location metadata m (doc_id, page / para / span or table / cell, etc.). For example, textual evidence parsed from "Annual Training Plan 2025.docx" can form the following field structure, where m records anchor="2.1" to indicate the chapter where the evidence is located, and phi binds the organizational entity ORG_AOC and the process entity PROC_TRN and provides an example confidence score of conf=0.93 / 0.88; tabular evidence parsed from "Training Record Ledger 2025.xlsx" forms tau=table, and m records positioning fields such as table=2 and cell=(18,4), and the table payload x carries the table header and row data for subsequent pattern predicate checks to ensure the column set is complete.

[0167] After objectifying the evidence, the system enters the regulation-checklist compilation module. In this embodiment, the system performs "normative tone recognition" on the set of regulatory clauses corresponding to C-TRN-01, splitting statements containing normative tones such as "must / shall / shall not / except" into atomic obligations according to their semantic roles, and mapping them to a set of obligation states for the compliance obligation automaton. For this entry, at least two mandatory obligation states are compiled: This indicates that "a training plan has been established." This indicates that "training records have been saved and are traceable"; correspondingly, the system generates evidence pattern constraints. and ,in The mandatory evidence type predicate is "text" and must be bound to two types of entities: "organization" and "process." The structural position predicate must satisfy the condition that the anchor belongs to the "Training Plan" chapter set, and the time interval predicate must require the evidence's effective scope to cover 2025. The mandatory evidence type predicate is `table`, requiring the table column set to contain fields such as "name / position / date / result". Simultaneously, the entity binding predicate requires binding to at least one position entity and one training process entity. To ensure "implementability," the evidence pattern language can employ a four-predicate conjunction execution logic in its implementation. The verification module then performs Eval(p_s,e) on each candidate piece of evidence, returning 0 / 1, thus making the determination of "whether the evidence is valid" a verifiable deterministic judgment.

[0168] In the graph retrieval enhancement module stage, the system uses the obligation state as the retrieval granularity, and simultaneously utilizes the knowledge graph structure and vector index for joint constraint retrieval. Example parameters for this embodiment are as follows: TopK selection... The system sets the maximum hop count to 2, the allowed relation set to `rel_allow` to `{reference, dependency, applicable}`, the vector similarity threshold to `sim_min` to `0.78`, and the entity binding confidence threshold to `conf_min` to `0.80`. It also sets a hard constraint on schema evaluation (i.e., candidates with `Eval(p_s,e)=0` are directly eliminated). During the ranking phase, the system uses a comprehensive scoring method. The weight example is taken Vector similarity is calculated using cosine similarity. KGRel can be obtained by normalizing the shortest path length or path confidence from the mandatory entity to the evidence-bound entity. Match(p_s,e) is composed of the evaluation result from the evidence pattern language and the number of satisfied items. Through this retrieval and sorting, the system targets... Hit and prioritize evidence E_001239, targeting The evidence E_004511 was hit and prioritized, and a snapshot of the search parameters was saved for subsequent recalculation.

[0169] The system then proceeds to the compliance proof construction module, where it transforms the "obligation state coverage" problem into a set coverage constraint problem and solves for the evidence subset. This embodiment employs a minimum cardinality solution priority strategy, meaning that the number of selected evidence is minimized while ensuring that all necessary obligation states are covered and each selected piece of evidence satisfies its corresponding pattern constraint. The output evidence subset is {E_001239, E_004511}, forming an obligation state coverage mapping M(s1)={E_001239} and M(s2)={E_004511}. The system constructs a compliance proof object accordingly, which includes at least the conclusion y=compliant, the evidence object identifier set I, the coverage mapping M, the conflict / waiver resolution path Pi (in this embodiment there is no conflict waiver, so Pi is empty), and the recalculation verification instruction kappa. The kappa includes at least the retrieval parameter snapshot (K, hop, rel_allow, weight, threshold, etc.), the knowledge graph version number kg_ver, the evidence pattern language version number pattern_ver, and the deterministic execution seed (e.g., seed=12345) to ensure that the proof verification can be recalculated consistently under fixed conditions.

[0170] During the verification module phase, the system performs verification on compliant proof objects based on the Kappa-defined fixed retrieval and execution randomness. The verification rules in this embodiment include at least: obligation status coverage verification (checking...). The system performs several checks, including: evidence pattern constraint satisfaction verification (Eval(p_s,e)=1 is executed for each state and its evidence); conflict / exemption consistency verification (if a conflict / exemption edge exists in the knowledge graph that affects the conclusion, the resolution path must be reflected in Pi; this is not triggered in this embodiment); and evidence location traceability verification (each evidence ID must be traceable back to the location metadata m and the corresponding version of doc_id must exist). After the machine verification passes, the system outputs the item-level conclusion "compliant" and the corresponding compliance proof object, and generates a machine verification report for auditing and recalculation.

[0171] Before outputting conclusions, this embodiment further performs stability checks to enhance robustness and review acceptability. The system applies bounded perturbations to the triggering conditions of the compliance obligation automaton; examples of perturbation parameters include time interval perturbations. The event involves altering the applicable subject's disturbance (adding or deleting one adjacent job from the job set), and repeatedly executing the retrieval-construction-mechanical verification process under each counterfactual condition to obtain the counterfactual compliance proof object; an example of the difference threshold is taken. The difference index is based on whether the coverage mapping still covers all necessary states and the similarity of the evidence set. In this embodiment, the counterfactual coverage mapping difference index is D=0.05, which is less than the threshold. Therefore, the system outputs the final conclusion as "compliant and stable", and does not add this item to the manual review list. The task orchestration module only runs once on this item to complete the task. Specific Implementation Example 3:

[0173] Audit of the timeliness of unsafe incident reporting, root cause analysis, and corrective action closure (two-stage convergence of the negative example closure + exemption conflict resolution + stability trigger requires manual confirmation): In this embodiment, the audit object is a certain operating unit's reporting, investigation and analysis, and corrective action closure materials for unsafe incidents. The input files include "Unsafe Incident Reporting Procedure V2.0.pdf", "Incident Reporting Ledger 2025.xlsx", "Incident Investigation and Analysis Report_2025-07-02.docx", and "Corrective Action Tracking Table.xlsx". The regulatory clause library contains both Clause A (v2024.06, requiring "reporting within 24 hours + root cause analysis + corrective action verification") and Clause B (v2025.01, adding the exemption condition of "minor incidents can be summarized and reported periodically"). The audit checklist item is C-EVT-03, whose description is "whether the unsafe incident is reported within the prescribed time limit and whether the root cause analysis and corrective action closure are completed". The system uses a data management module to complete versioning and record differences between clause versions. In particular, it establishes conflict edges and exemption edges in the knowledge graph for the conflict / exemption relationship between clause A and clause B and marks priority rules so that the subsequent resolution path can be verified and reproduced.

[0174] During the standardization and parsing phase, the system extracts event fields (event number, level, discovery time, report time, status, etc.) from ledger tables, extracts paragraph structures such as "event process, cause analysis, responsible department, corrective measures" from investigation reports, and generates text evidence objects. Simultaneously, it extracts column structures such as "measures, responsible person, completion time, verification results" from corrective measure tracking tables. The evidence object fields maintain a consistent structure: `tau` indicates table or text, `x` contains the table header and row data or paragraph text, `phi` binds the event entity, process entity, and responsible department entity (if identifiable) and records `conf`, `pi` records the applicable time range and organizational scope, and `m` records positioning fields such as table / cell or page / para / anchor. For example, the table evidence extracted from the ledger can record the discovery time and report time, allowing for subsequent calculations. If the textual evidence extracted from the investigation report lacks a root cause analysis method or a responsible department entity, it will be captured as a gap by the counterexample module in subsequent machine testing.

[0175] During the regulation-checklist compilation phase, the system decomposes Clauses A and B of C-EVT-03 into atomic obligations according to normative tone and semantic roles, and constructs a compliance obligation automaton to obtain at least three mandatory obligation states: Timely reporting obligation (default requirement) ), Obligation to conduct root cause analysis (requiring the availability of root cause analysis methods and a responsible department). The system establishes a closed-loop verification obligation for corrective actions (requiring measures, responsible persons, completion time, and verification results). Simultaneously, the system compiles Clause B into exemption trigger transfer and conflict priority transfer: when the event level meets the "minor" criterion and the summary cycle condition is met, The "24-hour hard constraint" can be mitigated by an exemption path; when the event level does not meet the criteria for minor or exemption, Clause A takes precedence and requires the hard constraint to be established. To ensure the feasibility of in-situ verification, evidence model constraints are implemented. This embodiment includes not only an evidence type predicate (either table or text) but also a numerical constraint predicate, used to parse the discovery time and reporting time from the evidence object x and calculate... and demand There may be a valid exemption resolution path; The mandatory evidence type is text, and it must simultaneously satisfy the entity binding predicate (responsible department entity DEPT_OWNER) and the method predicate (such as METHOD_5WHY or fishbone diagram method identifier). The evidence type must be table and the table column set must include the verification result field.

[0176] In this embodiment, the graph retrieval enhancement module employs a higher recall configuration to address scenarios where evidence is scattered. An example parameter is TopK. The system has a maximum hop count of 3, a similarity threshold of sim_min of 0.74, an entity binding threshold of conf_min of 0.82, an iteration limit of I_max of 4, and sets a conflict candidate threshold: when the difference between the scores of "satisfactory evidence" and "contradictory evidence" in the same state is less than 0.08, a forced verification of the conflict / exemption path is triggered. After the first retrieval and sorting, the system... The evidence in the ledger, E_100021, is hit and can be calculated. ;right The investigation report evidence E_100332 was found, but it lacks the root cause analysis method and responsible department fields; No closed-loop verification table evidence meeting the column requirements was found. The compliance proof construction module constructed an initial proof object according to the minimum evidence subset strategy, but the proof verification module failed after performing coverage and pattern verification. Numerical constraint failed ( And the exemption has not yet been proven to be applicable. The absence of entity / method predicates causes the pattern to be unsatisfied. The coverage failed. Based on this, the system generates a counterexample object CE_1. The counterexample object contains at least the set of failed obligation states {s1,s2,s3}, the set of failed constraint types {constraint_time, missing_entity, coverage}, the missing evidence type T_miss={table}, and the missing entity or feature R_miss={DEPT_OWNER, METHOD_5WHY}, and indicates that s1 needs supplementary structure of "exemption path or non-compliant conclusion".

[0177] During the counterexample-driven evidence convergence phase, the system automatically rewrites the retrieval constraints and graph traversal boundaries based on CE_1 for the second iteration. The rewriting strategy is specifically manifested as follows: the missing evidence type table is elevated to a mandatory evidence type constraint, and the corrective action tracking table is retrieved first; the missing entities DEPT_OWNER and METHOD_5WHY are added to must_ents and their matching weights are increased; simultaneously, the graph traversal relation set is narrowed to {dependency, reference} to reduce irrelevant expansion, and s1 is forced to retrieve evidence objects containing exemption triggering conditions or conflict priority rules. After the second search, the system added evidence from the corrective action tracking table (e.g., E_100880, with columns including "measure / responsible person / completion time / verification result," thus covering s3), and added supplementary evidence from the root cause analysis in subsequent chapters or appendices of the investigation report (e.g., E_100451, with text including "using the 5 Whys analysis method" and "responsible department: Operations Control Department," thus covering s2). Simultaneously, the system also retrieved evidence for the exemption of Clause B, but because the event level in the ledger was "general," this exemption evidence was not satisfied when evaluating the applicable subject / condition, and therefore could not be used as an exemption resolution path for s1. Based on this, the proof construction module generated a second version of the proof object and performed a machine test. The machine test results showed that s2 and s3 passed, but s1 still failed because... Furthermore, the exemption does not apply. The system generates a second counterexample object CE_2, which converges the failure to the time constraint failure of a single state s1, and prompts that a "provable non-compliant structure" needs to be formed in the proof object, that is, the conclusion is changed from "compliant" to "non-compliant but provable", and provides a resolution path for the applicability of the clause and the inapplicability of the exemption.

[0178] In the third iteration, the system constructs "non-compliant proof objects" without relaxing regulatory requirements; that is, the proof objective of s1 changes from "proving compliance" to "proving that the requirements are met". The statement is transformed into "Proof is not satisfied and is valid under Clause A, Clause B is not applicable," thus achieving a machine-verifiable non-compliance output. At this point, the proof object must contain a conflict / exemption resolution path Pi, using a directed path to record the conflict clause node (LAW_B_v2025.01), priority / exemption rule node (exemption_only_minor), covered clause node (LAW_A_v2024.06), and resolution result (B_not_applicable). The machine verification process confirms that this path matches the event level field. After the proof machine verification passes, the system outputs the conclusion "Time-limited report non-compliant, root cause analysis compliant, corrective action closed-loop compliant," and outputs the corresponding compliance proof object and machine verification report, enabling auditors to directly trace back the position of ledger cells and report paragraphs based on the evidence and metadata.

[0179] In the stability verification phase before output, this embodiment intentionally introduces a high-value engineering scenario: the event level may be subject to classification disputes, thus affecting the applicability of exemption clause B. The system applies bounded perturbations to the triggering conditions, including changing the event level from "general" to "minor" (simulating classification disputes) and adjusting the time field. Minute perturbation (simulated input error), and recalculation of the retrieval-proof-machine verification process under each counterfactual condition. Threshold example. When the cover mapping or conclusion of the object of the counterfactual evidence changes significantly, it is considered unstable. In this embodiment, if the level perturbation is "minor," the exemption of clause B may be triggered, causing the conclusion of s1 to change from "non-compliant" to "exemptible compliance." Therefore, the cover mapping and resolution path change, and the difference calculation result can reach D=0.33, which is greater than the threshold. Based on this, the system marks the entry as "requires manual confirmation" and outputs two sets of recalculated proof objects (original level and disturbance level) for the auditor to verify the event level definition and classification basis. Finally, the system extracts the counterexample signatures (including failure status, failure type, missing evidence type, missing entity set, and conflict path relationship type sequence) from the two counterexample objects CE_1 and CE_2 according to the signature rules, and stores the signatures and rewriting strategies in the counterexample pattern library. This allows subsequent similar entries to be pre-configured with strategies such as must_types={table} and must_ents={DEPT_OWNER,METHOD_5WHY} before the first retrieval, thereby significantly reducing the number of iterations of "counterexample-rewriting-machine verification" and improving the machine verification pass rate.

[0180] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising a reference structure" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0181] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. An SMS auditing system based on multi-agent collaboration and GraphRAG, characterized in that, include: The data management module is used to version-store the documents to be reviewed, the regulatory clause library and the audit checklist, and to generate evidence location metadata for document fragments, including source document identifiers, page numbers or paragraph boundaries, and table row and column coordinates. The normalization parsing module is used to parse text paragraphs, table cells, and process / organizational structure type graphic information into a unified structured evidence object. The structured evidence object includes at least an evidence type field, an entity binding field, a time or scope of application field, and the evidence location metadata. The regulatory checklist compilation module is used to compile regulatory clauses and checklist items into a compliance obligation automaton, wherein the compliance obligation automaton includes at least: a set of obligation states, a set of triggering conditions, a set of transfer rules, and an evidence pattern constraint corresponding to each obligation state; the evidence pattern constraint at least defines the evidence type, the mandatory entity, the allowed time range, and the applicable subject. The graph retrieval enhancement module is used to retrieve a set of candidate evidence objects for each obligation state under the joint constraints of the knowledge graph structure and vector index, and output the ranking results of the candidate evidence objects according to the degree of matching with the evidence pattern constraints. The compliance proof construction module is used to select a subset of evidence that satisfies the compliance obligation automaton from the candidate evidence object set and construct a compliance proof object. The compliance proof object includes at least: a conclusion, an obligation state coverage mapping, an evidence object identifier set, a conflict / exemption resolution path, and a recalcible verification instruction. The proof verification module is used to perform verification on the compliant proof object according to the recalculated verification instruction. The verification includes at least: obligation status coverage verification, evidence mode constraint satisfaction verification, conflict / exemption resolution consistency verification, and evidence location traceability verification. The counterexample-driven evidence convergence module is used to output a counterexample object when the machine verification fails. The counterexample object includes at least the failure obligation state, failure constraint type, missing entity or missing evidence type, and evidence path that leads to conflict. Based on the counterexample object, the module automatically rewrites the retrieval constraints and graph traversal boundaries to trigger the graph retrieval enhancement module and compliance proof construction module again until the machine verification is passed or the iteration limit is reached. The task orchestration module is used to schedule the above modules in parallel or serially at the granularity of checking a single item. When the machine verification still fails after reaching the iteration limit, it outputs a low confidence mark and generates a list to be manually reviewed.

2. The SMS auditing system based on multi-agent collaboration and GraphRAG as described in claim 1, characterized in that, The regulation-checklist compilation module decomposes the normative statements in the regulations into at least three types of atomic obligations according to their semantic roles: mandatory obligations, prohibited obligations, and conditional obligations, and maps each atomic obligation to an obligation state in the compliance obligation automaton; wherein the conditional obligations are compiled into Boolean conditions and interval conditions in the triggering condition set, and the transfer rule set includes at least: condition satisfaction transfer, exemption trigger transfer, and conflict priority transfer.

3. The SMS auditing system based on multi-agent collaboration and GraphRAG as described in claim 1, characterized in that, The evidence pattern constraints are defined using an executable evidence pattern language, which includes at least the following: The evidence type predicate is used to specify that the evidence must come from at least one of the following: a text paragraph, a table cell, a process step, or a mapping of organizational responsibilities. The entity binding predicate is used to restrict evidence to be bound to at least one organizational entity and at least one responsibility / process entity simultaneously. time Interval predicates are used to limit the effective period of evidence. Structural location predicates are used to limit the evidence location metadata to meet preset chapter or table location rules; Furthermore, the verification module determines whether the evidence can serve as valid evidence of the corresponding obligation state by evaluating the evidence pattern language.

4. The SMS auditing system based on multi-agent collaboration and GraphRAG as described in claim 1, characterized in that, The recalculable verification instruction includes at least: a retrieval parameter snapshot, a knowledge graph structure version number, an evidence pattern language version number, and a deterministic execution seed; the proof verification module performs recalculable verification on the compliant proof object and outputs a verification report under the condition of fixing the retrieval parameter snapshot and the deterministic execution seed, and the verification report includes at least a list of failed obligation statuses and corresponding counterexample object generation information.

5. The SMS auditing system based on multi-agent collaboration and GraphRAG according to claim 1, characterized in that, The conflict / exemption resolution path is recorded in the compliance proof object in the form of a directed path. The directed path includes at least a conflict clause node, a priority rule node, and a covered clause node. When the proof verification module detects valid evidence corresponding to the same obligation state that simultaneously satisfies the mutual exclusion constraint, if the compliance proof object lacks the conflict / exemption resolution path, the verification is deemed to have failed and a counterexample object containing the mutually exclusive evidence path is generated.

6. The SMS auditing system based on multi-agent collaboration and GraphRAG according to claim 1, characterized in that, The counterexample-driven evidence convergence module executes at least one rewriting strategy based on the counterexample object: Promote the missing evidence type in the evidence pattern constraint corresponding to the failure obligation state to a mandatory evidence type constraint. Add the missing entity to the set of entities that must be included in the search and restrict graph traversal to only allow passing through the dependent edges or reference edges associated with the missing entity; When a counterexample contains a conflicting evidence path, force the retrieval of evidence objects containing exemption triggering conditions or conflict priority rules. After each rewrite, the compliance proof object is reconstructed and machine-verified to form a closed-loop convergence of "counterexample-rewrite-machine verification".

7. The method corresponding to the SMS auditing system based on multi-agent collaboration and GraphRAG as described in claim 1, characterized in that, include: S1. Perform standardized parsing on the documents to be reviewed to generate structured evidence objects containing evidence type, entity binding, time or scope of application and location metadata; S2. Compile the regulatory clauses and checklist items into a compliance obligation automaton, and generate a set of obligation states and the evidence pattern constraints corresponding to each obligation state. S3. Based on the knowledge graph structure and vector index, retrieve the set of candidate evidence objects for each obligation state and sort them according to the degree of matching with the evidence pattern constraint. S4. Select a subset of evidence from the candidate evidence object set to construct a compliance proof object, wherein the compliance proof object includes at least an obligation state coverage mapping, a conflict / exemption resolution path, and a recalcible verification instruction. S5. Perform the verification test. If the verification passes, output the item-level conclusion and the compliance verification object. S6. If the machine test fails, generate a counterexample object, and rewrite the retrieval constraints and graph traversal boundaries based on the counterexample object, then return to execute S3 to S5 until the machine test passes or the iteration limit is reached. S7. If the machine verification still fails after reaching the iteration limit, output a low confidence level flag and generate a list of items to be manually reviewed.

8. The method corresponding to the SMS auditing system based on multi-agent collaboration and GraphRAG as described in claim 7, characterized in that, When constructing the compliance proof object in S4, the obligation state coverage mapping is transformed into a set coverage constraint problem. Under the premise of satisfying all obligation state evidence pattern constraints, the minimum cardinality solution or the minimum weighted cost solution of the evidence object identifier set is obtained, and the minimum solution is taken as the evidence subset in the compliance proof object.

9. The method corresponding to the SMS auditing system based on multi-agent collaboration and GraphRAG as described in claim 7, characterized in that, Before outputting the entry-level conclusion, a stability check is performed. The stability check includes: performing a bounded perturbation on the set of triggering conditions in the compliance obligation automaton to generate a set of counterfactual conditions, and repeatedly executing S3 to S5 under each counterfactual condition to obtain a counterfactual compliance proof object; when the difference between the obligation state coverage mapping of the counterfactual compliance proof object and the obligation state coverage mapping of the original compliance proof object exceeds a threshold, the entry-level conclusion is marked as low confidence or requires manual confirmation.

10. The method corresponding to the SMS auditing system based on multi-agent collaboration and GraphRAG according to claim 7, characterized in that, It also includes the steps of building and applying a library of counterexample patterns: The counterexample objects generated in S6 are used to extract counterexample signatures according to preset signature rules. The counterexample signature includes at least the failure obligation status identifier, failure constraint type, missing evidence type, missing entity set, and relation type sequence of conflicting evidence paths. The counterexample signature and the corresponding retrieval constraint rewriting strategy are stored in the counterexample pattern library. Before executing S3 on a new checklist item, an item feature vector is generated based on the obligation status set and evidence pattern constraints corresponding to the item, and matched with the counterexample signature in the counterexample pattern library. When the matching degree exceeds the threshold, the corresponding retrieval constraint rewriting strategy and graph traversal boundary limit are automatically preset before the first retrieval to reduce the number of counterexample-rewriting-machine verification iterations and improve the machine verification pass rate.

Images