An electronic contract intelligent auditing and evidence storage method based on deep learning and blockchain

Abstract

The application discloses an electronic contract intelligent auditing and evidence storage method based on deep learning and blockchains, relates to the technical field of deep learning and blockchains, and comprises the following steps: collecting and pre-processing auditing contract data, and generating standard auditing contract data; analyzing contract performance responsibility elements, generating and associating performance atoms of valid auditing basis; constructing performance-liability pairing relationship and electronic contract heterogeneous auditing graph; inputting the electronic contract heterogeneous auditing graph into an improved HGT model to generate responsibility pairing residual error, version account state and first responsibility proof; checking candidate modification fields to generate minimum responsibility repair closure and responsibility repair result; associating contract versions to generate auditing proof inheritance-verification chain; constructing cross-version auditing coupling summary and writing into a blockchain to generate contract auditing evidence storage data; and receiving a verification instruction to generate a contract auditing verification result. The application realizes accurate electronic contract auditing and credible evidence storage, and improves responsibility positioning and cross-version verification capability.

Description

Technical Field

[0001] This invention relates to the fields of deep learning and blockchain, and in particular to a method for intelligent review and evidence storage of electronic contracts based on deep learning and blockchain. Background Technology

[0002] With the widespread application of electronic contracts in financial transactions, supply chain collaboration, engineering construction, procurement performance, and online services, contract texts, attachments, forms, signing records, performance records, and version change data are continuously generated. Existing technologies mostly use natural language processing, knowledge graphs, and deep learning models to extract the contract subjects, rights and obligations, performance conditions, liability for breach of contract, and risk clauses to generate contract review results. Some methods use hash digests, timestamps, and blockchain to record contract documents and the signing process.

[0003] Existing intelligent review methods for electronic contracts mostly revolve around keyword matching, clause classification, and risk scoring. They fail to establish a continuous liability path for the effective date of obligations, performance, evidence of completion, termination of obligations, establishment of breach of contract, assumption of liability, and termination of remedies. This makes it difficult to express the correspondence between the performance path and the accountability path. When the contract version changes, old version clauses, invalid review basis, and historical node information can still affect the current review, which can easily lead to mismatch of responsible parties, shift in risk position, and double counting of review results.

[0004] Existing blockchain-based evidence preservation methods focus on contract document summaries, signing status, and operation time records. They fail to establish a unified binding relationship between contract content, heterogeneous audit diagrams, model versions, audit basis versions, liability breakpoint proofs, and repair results. After contract modifications, it is difficult to determine whether historical audit proofs should be inherited, replaced, or cancelled. During the verification phase, it is also difficult to reenact the audit process and locate data changes. These methods cannot meet the needs of intelligent cross-version auditing, liability repair, and reliable evidence preservation for electronic contracts.

[0005] Therefore, how to provide a method for intelligent review and evidence storage of electronic contracts based on deep learning and blockchain is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] One objective of this invention is to propose an intelligent review and evidence storage method for electronic contracts based on deep learning and blockchain. This invention utilizes heterogeneous graph transformers, responsibility path analysis, and blockchain evidence storage technology to achieve contract responsibility review, version evidence accounting, responsibility breakpoint location, minimal repair, and cross-version verification. It has the advantages of accurate review, small repair scope, reliable evidence storage, and traceable verification.

[0007] According to an embodiment of the present invention, an intelligent auditing and evidence storage method for electronic contracts based on deep learning and blockchain includes: Collect and review contract data, perform preprocessing on the reviewed contract data, and encapsulate it to generate standard reviewed contract data; The contract performance responsibility elements are analyzed from the standard audit contract data to generate performance atoms. The performance atoms are then associated with valid audit basis and encapsulated to generate contract performance audit data. Based on contract performance review data, construct a performance accountability dual relationship, link contract versions, performance elements and valid review basis, and construct a heterogeneous electronic contract review diagram; The heterogeneous audit diagram of the electronic contract is input into the improved HGT model. The responsibility dual residual is generated through the performance-accountability dual mutual attention layer, the version accounting status is generated through the version evidence accounting message layer, the first-judgment liability proof is generated through the first-judgment liability proof decoding head, and the contract liability audit result is encapsulated. Based on the contract liability review results, candidate modification fields are determined and validation is performed. A minimum liability repair closure is generated and encapsulated with the contract liability review results to generate the liability repair result. Based on the version revenue sharing status and initial liability proof in the liability repair results, associate the contract version with the minimum liability repair closure and generate an audit proof inheritance-reversal chain; Based on the audit proof inheritance-verification chain, a cross-version audit coupling summary is constructed and written into the blockchain to generate contract audit evidence storage data; Receive verification instructions for contract review and storage data, and generate contract review and verification results.

[0008] Optionally, the contract data to be reviewed includes electronic contract data, review basis data, and historical contract review and evidence storage data.

[0009] Optionally, the preprocessing of the contract data to be reviewed includes parsing and standardization, and filtering valid review criteria according to the contract signing time, effective time, performance time, breach time, and termination time.

[0010] Optionally, the encapsulation and generation of contract performance verification data includes: Extract the obligor, beneficiary, performance act, subject matter of performance, triggering conditions, performance conditions, performance time, performance amount, evidence of completion, breach of contract conditions, liability assumption method, remedial actions, termination conditions of obligation, and termination conditions of liability from the contract terms. Combine the contract performance liability elements according to the contract terms number and assign performance atom numbers to generate performance atoms. Extract the audit basis number, legal level, scope of application, exception conditions and priority conditions from the valid audit basis; match the performance atoms according to the scope of application; exclude audit basis that meets the exception conditions and sort them to generate a sequence of valid audit basis. Associate the performance atom, contract clause number, contract version number, and valid audit basis sequence, assign data indexes, and generate contract performance audit data.

[0011] Optionally, the construction of the heterogeneous electronic contract review diagram includes: Read the performance atoms, connect the triggering conditions, the obligation takes effect, the performance behavior, the evidence of completion and the termination conditions of the obligation, and generate a closed performance path. After the performance time expires, generate a default trigger state based on the lack of performance behavior and the lack of evidence of completion. Connect the default conditions, the method of assuming liability, the remedial behavior and the termination conditions of liability to generate a default accountability path. Based on the elements of contract performance responsibility, two types of paths are matched, and a dual mapping is established between the corresponding responsibility states to generate a performance-accountability dual relationship; Contract terms, performance atoms, liability status, contract version, and valid review basis are written into heterogeneous nodes. Two types of paths, dual mappings, review basis constraints, and cross-version homogeneous relationships are written into heterogeneous edges. Node numbers, edge numbers, and graph indexes are assigned to construct a heterogeneous review graph for electronic contracts.

[0012] Optionally, the encapsulation of the contract liability audit result includes: An improved HGT model was constructed and the model version was recorded. The improved HGT model includes a heterogeneous node mapping layer, a performance-accountability dual mutual attention layer, a version evidence ledger message layer, and a first-break responsibility proof decoding header. The heterogeneous node mapping layer maps the heterogeneous audit graph of electronic contracts according to node type and edge type, and generates a heterogeneous audit graph representation. The performance-accountability dual mutual attention layer queries the breach accountability path representation using the performance closed path representation, and vice versa queries the performance closed path representation using the breach accountability path representation. By comparing the contract performance responsibility elements and responsibility status in the bidirectional attention representation, the responsibility dual residual is generated. The version evidence accounting message layer matches cross-version same-source nodes. When at least one of the following conditions is met: the previous version node does not exist in the current version or the associated valid audit basis is invalid, it is marked as invalid. When the current version node has no previous version same-source node, it is marked as new. When the content, association relationship, or valid audit basis of the same-source node changes but the audit validity is maintained, it is marked as changed. The remaining same-source nodes are marked as inherited. The node message is reused for the inherited state. The node message is calculated for the new state and the changed state. The historical message is masked along the association relationship for the invalid state. The version accounting status and invalid masking result are generated. The decoding head of the first-break responsibility certificate arranges the responsibility status of the two types of paths respectively. Based on the responsibility dual residual, version accounting status and failure masking result, the reachability is determined. The first position where the previous state is reachable and the current state is unreachable is determined as the first breakpoint. The path, the preceding state, the missing successor state, the contract clause number, the performance atom number, the audit basis number, the affected responsibility path and the responsibility closure deficiency are recorded to generate the first-break responsibility certificate. Encapsulate the dual residuals of responsibility, version accounting status, failure masking results, first-line responsibility proof and data index, allocate result index, and generate contract responsibility audit results.

[0013] Optionally, generating the responsibility repair result includes: Extract the missing subsequent status, contract clause number and affected liability path from the initial liability certificate, read the contract performance liability elements based on the contract performance audit data index, and locate the candidate modification fields; Based on the standard review contract data index, extract similar contract fields from electronic contract data, extract standard contract terms and enterprise review rules from the review basis data, and generate candidate modification operations by combining valid review basis; Perform candidate modification operations, update the performance atom, performance-accountability duality and electronic contract heterogeneous audit diagram, input the updated electronic contract heterogeneous audit diagram into the improved HGT model, and generate candidate repair audit results; Candidate modification operations that retain the responsibility path closure, eliminate the original first breakpoint, maintain the state of the unmodified responsibility path, and do not generate new responsibility dual residuals are generated to generate valid repair results; Sort by the number of modified fields, the number of modified clauses, the number of modified characters, and the number of affected liability paths. The first result is determined as the minimum liability repair closure, which is then encapsulated with the contract liability audit result to generate the liability repair result.

[0014] Optionally, the generation of the audit proof inheritance-reconciliation chain includes: Extract the first breakpoint liability proof, version accounting status and minimum liability repair closure from the liability repair results. Based on the standard audit contract data index, extract the previous version proof branch from the historical contract audit evidence data. Match the previous and previous proof branches according to the path to the first breakpoint, the performance atom number and the missing successor status to generate a proof dependency set and a proof branch summary. A new proof record is generated when the current proof branch does not match the previous proof branch. A proof cancellation record is generated when the previous proof branch does not match the current proof branch and at least one item in the invalid state dependency object of the matching proof branch is true. A proof inheritance record is generated when there is no invalid state dependency object and the digests before and after are consistent. A proof replacement record is generated when there is no invalid state dependency object and at least one item in the changed state dependency object and the new state dependency object exists and the digests before and after are inconsistent. Write the branch number and summary of the proof before and after, the number of the object that triggered the change, the number of the object that triggered the failure, and the minimum liability repair closure. Connect the proof records according to the contract version number to generate the audit proof inheritance-reversal chain.

[0015] Optionally, the generation of contract review and evidence storage data includes: Based on the data index in the audit certificate inheritance-verification chain, standard audit contract data, electronic contract heterogeneous audit diagram, contract liability audit results and liability remediation results are read, and contract content summary, heterogeneous audit diagram summary and audit certificate summary are calculated. Extract the cross-version audit coupling summary of the previous version from the historical contract audit and storage data. For the first contract version, calculate the version succession summary based on the contract identifier and contract version number. For non-first contract versions, use the cross-version audit coupling summary of the previous version as the version succession summary. Combine contract identifier, contract version number, contract content summary, heterogeneous audit diagram summary, audit proof summary, version inheritance summary, model version and audit basis version, and calculate cross-version audit coupling summary; The audit data is saved to off-chain storage space, and the contract identifier, contract version number, cross-version audit coupling summary and off-chain storage index are written into the blockchain ledger to generate contract audit evidence data.

[0016] Optionally, generating the contract review and verification result includes: Extract the contract identifier and contract version number from the verification instruction, and read the on-chain cross-version audit coupling summary, electronic contract heterogeneous audit diagram, contract liability audit result and audit proof inheritance-verification chain based on the contract audit and storage data; Recalculate the cross-version audit coupling digest and compare it with the on-chain digest to generate a digest consistency marker; Input the heterogeneous audit diagram of electronic contract into the improved HGT model of the corresponding model version, recalculate the dual residual of liability, version accounting status and first-time liability proof, and compare it with the contract liability audit results to generate a consistent audit result mark. Check the proof branch numbers and summaries before and after the contract version number, and generate a continuous proof chain marker; If all three tags are consistent, a verification pass result is generated; if at least one tag is inconsistent, a verification failure result is generated and the location of the inconsistent data is recorded, and a contract audit verification result is generated.

[0017] The beneficial effects of this invention are: This invention collects electronic contract data, audit basis data, and historical contract audit and evidence data, extracts contract performance responsibility elements and generates performance atoms, and constructs an electronic contract heterogeneous audit diagram consisting of a performance closure path, a breach of contract accountability path, and a performance-accountability dual relationship. This enables the subject responsibility, performance conditions, completion evidence, breach of contract conditions, and remedial responsibilities scattered in the contract text, attachments, tables, signing records, and performance records to form a structured association, improves the completeness of the expression of contract responsibility relationships, and reduces cross-clause responsibility omissions, subject mismatches, and deviations in the judgment of performance status.

[0018] This invention employs an improved HGT model comprising a performance-accountability dual mutual attention layer, a version evidence accounting message layer, and a first-break responsibility proof decoding head. This model performs bidirectional attention calculations on the performance closure path and the breach accountability path, generating responsibility dual residuals. Furthermore, it performs inheritance, change, addition, and failure status accounting on cross-version same-origin nodes, shields historical messages generated by failure nodes, and locates the first breakpoint based on the reachability of the responsibility status. This improves the accuracy of contract responsibility anomaly identification, reduces interference from old version clauses and failed audit criteria on current audit results, and enhances the location and interpretation capabilities of audit results.

[0019] This invention generates candidate modification operations based on the initial breakpoint liability proof, updates the heterogeneous audit graph of the electronic contract, and re-executes the improved HGT model. It selects the minimum liability repair closure that closes the liability path, eliminates the original initial breakpoint, maintains the unmodified liability path, and does not generate new liability dual residuals. It establishes an audit proof inheritance-reversal chain in conjunction with the version ledger status, and encapsulates the contract content, heterogeneous audit graph, audit proof, model version, audit basis version, and version inheritance relationship into a cross-version audit coupling digest and writes it into the blockchain. This improves the accuracy of contract repair, narrows the scope of modification, and realizes the credible storage and re-verification of contract audit results, liability repair process, and cross-version proof relationships. Attached Figure Description

[0020] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They explain the invention together with the embodiments of the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is an overall flowchart of an intelligent electronic contract review and evidence storage method based on deep learning and blockchain proposed in this invention. Figure 2 This is a schematic diagram of the improved HGT model structure of an intelligent electronic contract review and evidence storage method based on deep learning and blockchain proposed in this invention. Detailed Implementation

[0021] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0022] refer to Figure 1 and Figure 2 A method for intelligent review and evidence storage of electronic contracts based on deep learning and blockchain, comprising: Collect and review contract data, perform preprocessing on the reviewed contract data, and encapsulate it to generate standard reviewed contract data; The contract performance responsibility elements are analyzed from the standard audit contract data to generate performance atoms. The performance atoms are then associated with valid audit basis and encapsulated to generate contract performance audit data. Based on contract performance review data, construct a performance accountability dual relationship, link contract versions, performance elements and valid review basis, and construct a heterogeneous electronic contract review diagram; The heterogeneous audit diagram of the electronic contract is input into the improved HGT model. The responsibility dual residual is generated through the performance-accountability dual mutual attention layer, the version accounting status is generated through the version evidence accounting message layer, the first-judgment liability proof is generated through the first-judgment liability proof decoding head, and the contract liability audit result is encapsulated. Based on the contract liability review results, candidate modification fields are determined and validation is performed. A minimum liability repair closure is generated and encapsulated with the contract liability review results to generate the liability repair result. Based on the version revenue sharing status and initial liability proof in the liability repair results, associate the contract version with the minimum liability repair closure and generate an audit proof inheritance-reversal chain; Based on the audit proof inheritance-verification chain, a cross-version audit coupling summary is constructed and written into the blockchain to generate contract audit evidence storage data; Receive verification instructions for contract review and storage data, and generate contract review and verification results.

[0023] In this embodiment, the contract review data includes electronic contract data, review basis data, and historical contract review and evidence storage data.

[0024] In this embodiment, the preprocessing of the contract data for review includes parsing and standardization, and filtering valid review criteria according to the contract signing time, effective time, performance time, breach time, and termination time.

[0025] In this embodiment, the process of encapsulating and generating contract performance review data includes: Extract the obligor, beneficiary, performance act, subject matter of performance, triggering conditions, performance conditions, performance time, performance amount, evidence of completion, breach conditions, liability assumption method, remedial actions, termination conditions of obligation, and termination conditions of liability from the contract clauses. Combine these contract performance liability elements according to the contract clause numbers and assign performance atom numbers to generate performance atoms. Specifically, generating performance atoms involves: The responsibility statements are arranged according to the contract version number and contract clause number. Within each responsibility statement, the performance actions are arranged in ascending order of the starting character position. Each performance action is used as a combination center. Contract performance responsibility elements that are located in the same responsibility statement as the performance action and have subject-verb, verb-object, prepositional-object, conditional, temporal, monetary, and liability relationships with the performance action are read. The contract clause number, obligor, beneficiary, performance action, performance object, triggering condition, performance condition, and performance time are connected as a combination key. When the combination keys are completely consistent, the performance amount, completion evidence, breach of contract conditions, liability assumption method, remedial action, obligation termination condition, and liability termination condition are merged into the same record. When any field of the combination key is different, a new record is created. A 4-digit sequence number is assigned to the record in ascending order of contract clause number and the starting character position of the performance action. The contract identifier, contract version number, contract clause number, and 4-digit sequence number are sequentially connected to generate a performance atom number. The performance atom number, 14 types of contract performance responsibility elements, the source character position of each field, and the responsibility statement number are encapsulated as a performance atom. Extract the audit basis number, legal level, scope of application, exceptions, and priority conditions from the valid audit basis. Match the performance atoms according to the scope of application, exclude audit basis that meets the exception conditions, and sort them to generate a sequence of valid audit basis, where: Extract the audit basis number, legal level, scope of application, exceptions, and priority conditions from the valid audit basis, specifically as follows: The system reads valid review basis records from the standard contract review data. Each valid review basis record includes the review basis document name, issuing entity, document type, clause number, clause text, effective date, and expiration date. It reads the review basis number from the record metadata. If the review basis number is missing, it concatenates the document name, issuing entity, issuance date, and clause number in a fixed order and calculates a SHA256 digest. The first 16 hexadecimal characters of the digest are extracted as the review basis number. The system reads the document type and assigns values ​​according to the following criteria: law (6), administrative regulations (5), judicial interpretations (4), local regulations (3), and departmental rules (3). The mapping table of national standard assignment 2, industry standard assignment 2, and enterprise audit rule assignment 1 generates legal level values. It extracts the contract type, subject type, subject matter type, geographical scope, and contract stage guided by terms such as applicable, scope of application, applicable objects, applicable regions, and applicable periods from the clause text and encapsulates them as the scope of application. It extracts the condition fields, comparison relationships, and condition values ​​from the restrictive phrases guided by terms such as but, not applicable, excluded, and not included and encapsulates them as exception conditions. It extracts the priority object, applicable conditions, and priority number from the phrases guided by terms such as priority of application, priority of special provisions, priority of special agreements, and priority of new rules and encapsulates them as priority of application conditions. Matching fulfillment atoms according to their applicable scope, specifically: Read the obligor, beneficiary, subject matter, triggering condition, performance condition, performance time, and contract clause number from the performance atom. Extract the contract type, obligor type, beneficiary type, subject matter type, performance region, and contract stage from the electronic contract data. Compare the contract type with the contract types in the scope of application, the obligor type and beneficiary type with the subject types in the scope of application, the subject matter type with the subject types in the scope of application, the performance region with the regional scope in the scope of application, and the performance time and contract stage with the time limit and contract stage in the scope of application. The national applicable mark corresponds to any performance region, the provincial regional mark requires the performance region to be located in the same provincial administrative region, and the municipal regional mark requires the performance region to be located in the same municipal administrative region. When the scope of application field is written with an empty string, no restrictions are set on the corresponding dimension. When there is a clearly defined scope of application field, all corresponding dimensions are required to match. Valid audit basis that matches all is written into the candidate audit basis set of the performance atom. Associate the performance atom, contract clause number, contract version number, and valid audit basis sequence, assign data indexes, and generate contract performance audit data.

[0026] In this embodiment, constructing the heterogeneous audit diagram of electronic contracts includes: Read the performance atoms, connect the triggering conditions, obligation effectiveness, performance behavior, evidence of completion, and obligation termination conditions to generate a closed performance path. After the performance period expires, a breach of contract trigger state is generated based on the lack of performance behavior and lack of evidence of completion. Connect the breach of contract conditions, liability assumption methods, remedial actions, and liability termination conditions to generate a breach of contract accountability path, where: Upon expiration of the performance period, a breach of contract trigger status is generated based on the lack of performance and the lack of evidence of completion, specifically: Read the performance time from the performance atom and the audit time from the standard audit contract data. When the performance time is a date, determine 23:59 on the day of performance as the performance deadline. When the performance time is a period, read the time of occurrence of the period start event and add the number of days of the period to obtain the performance deadline. When the performance time is a time interval, determine the end time of the interval as the performance deadline. If the audit time is earlier than the performance deadline, write the default trigger status value to 0. After the audit time reaches the performance deadline, read the performance behavior status value and the completion evidence status value. When the performance behavior status value is 0, generate a performance behavior missing mark. When the performance behavior status value is 1 and the completion evidence status value is 0, generate a completion evidence missing mark. If at least one of the performance behavior missing mark and the completion evidence missing mark exists, write the default trigger status value to 1 and write the missing mark, performance deadline, audit time, performance atom number and contract clause number into the default trigger status record. If neither of the two missing marks exists, write the default trigger status value to 0. By connecting the conditions of breach of contract, the methods of assuming liability, remedial actions, and the conditions for termination of liability, a path for pursuing liability for breach of contract is generated, specifically as follows: For each default trigger status record, establish a default condition status record, liability assumption method status record, remedial behavior status record, and liability termination condition status record. Default conditions are broken down into condition fields, comparison relationships, and condition values. Missing flags, performance deadlines, review times, and performance amounts from the default trigger status record are written into a condition field comparison table. When the condition field comparison result is true, the default condition status value is written as 1. When the default condition is an empty string, the default condition status value is written as -1 and a default condition missing flag is written. The liability assumption method field is read. When the liability assumption method is not an empty string, the liability assumption method configuration status value is written as 1. When the liability assumption method is an empty string, it is written as 0. Match the liquidated damages payment record, compensation record, refund record, and expense liability record in the contract performance record according to the performance atom number and liability assumption method. If a match is successful, write 1 to the liability assumption method execution status value; otherwise, write 0. Read the remedial action field; if the remedial action is not an empty string, write 1 to the remedial action configuration status value; otherwise, write 0. Match the supplementary delivery record, rework record, repair record, replacement record, re-performance record, and time-limited rectification record in the contract performance record according to the performance atom number and remedial action. If a match is successful, write 1 to the remedial action execution status value. Input 1, write 0 when the match fails, split the liability termination condition into termination field, comparison relationship and termination value and compare it with the contract performance record. When the comparison result is true, write 1 to the liability termination condition status value. When the liability termination condition is an empty string, write -1 and write a liability termination condition missing flag. Establish directed connections in the order of default trigger status record, default condition status record, liability assumption method status record, remedial behavior status record and liability termination condition status record. Record the performance atom number, start status type, termination status type and status sequence corresponding to each connection to generate the default accountability path. Based on the pairing of two types of paths according to the elements of contract performance responsibility, a dual mapping is established between the corresponding responsibility states to generate a performance-accountability dual relationship, wherein: Two paths are matched according to the elements of contract performance responsibility, specifically: Read the performance atom numbers corresponding to the performance closure path and the breach of contract liability path. Establish master pairing records for performance closure paths and breach of contract liability paths originating from the same performance atom number. Read the obligor, beneficiary, performance behavior, performance object, triggering condition, performance condition, performance time, and performance amount corresponding to the two paths. Convert all text fields to standard text (removing spaces, line breaks, and punctuation). Convert the time field to year-month-day-hour-minute format. Convert the amount field to yuan. Compare each of the eight contract performance liability elements, writing 1 for consistent field values ​​and 0 for inconsistent values. The comparison results are arranged in a fixed order: obligor, beneficiary, performance behavior, performance object, triggering condition, performance condition, performance time, and performance amount. Path pairing records are retained when at least 6 out of 8 comparison results are 1, and cancelled when fewer than 6 are 1. The consistency threshold of the 6 fields is determined by testing the consistency conditions of 4, 5, 6, and 7 fields on manually labeled path pairing samples. The path pairing accuracy and recall rate are the highest when the consistency condition of 6 fields is met. The retained path pairing records are arranged according to contract version number, contract clause number, and performance atom number to generate two types of path pairing tables. Establish a dual mapping between corresponding responsibility states to generate a performance-accountability dual relationship, specifically: Read the two types of path pairing tables, establish the first dual mapping between the trigger condition status in the performance closure path and the breach condition status in the breach accountability path, establish the second dual mapping between the obligation effective status and the breach trigger status, establish the third dual mapping between the performance behavior status and the liability assumption method status, establish the fourth dual mapping between the completion evidence status and the remedial behavior status, and establish the fifth dual mapping between the obligation termination condition status and the liability termination condition status. Record the performance atom number, performance status type, accountability status type, performance status value, accountability status value, and dual sequence for each pair of dual mappings. Write a dual closure mark when both state values ​​of the dual are 1, write a dual difference mark when the state values ​​of the dual are inconsistent, and write a dual missing mark when either state value of the dual is negative 1. Arrange all dual mapping records according to the contract version number, performance atom number, and dual sequence to generate the performance-accountability dual relationship. Contract terms, performance atoms, liability status, contract version, and valid review basis are written into heterogeneous nodes. Two types of paths, dual mappings, review basis constraints, and cross-version homology relationships are written into heterogeneous edges. Node numbers, edge numbers, and graph indexes are assigned to construct an electronic contract heterogeneous review graph. Specifically, constructing the electronic contract heterogeneous review graph involves: The heterogeneous node record table is arranged according to node type code, contract clause number, performance atom number, status sequence, and audit basis sequence. Each node record is assigned a 6-digit sequential number starting from 000001. The contract identifier, contract version number, node type code, and node sequence number are concatenated in a fixed order to generate a node number. Similarly, the heterogeneous edge record table is arranged according to edge type code, start node number, and end node number. Each edge record is assigned an 8-digit sequential number starting from 00000001. The contract identifier, contract version number, edge type code, and edge sequence number are concatenated in a fixed order to generate an edge number. All nodes... Records are arranged in ascending order by node number, and all edge records are arranged in ascending order by edge number. Node fields are connected using a vertical bar character, and node records are connected using a newline character. Edge fields are connected using a vertical bar character, and edge records are connected using a newline character. The node record text and edge record text are concatenated sequentially and converted into UTF-8 byte sequences. The SHA-256 digest is calculated on the UTF-8 byte sequences, and the 64-bit hexadecimal digest is used as the graph index. The graph index, heterogeneous node record table, heterogeneous edge record table, node type encoding table, edge type encoding table, contract version number, and contract performance review data index are encapsulated to construct an electronic contract heterogeneous review graph.

[0027] In this embodiment, the process of encapsulating and generating contract liability review results includes: Constructing and recording an improved HGT model, the improved HGT model includes a heterogeneous node mapping layer, a performance-accountability dual mutual attention layer, a version evidence ledger message layer, and a first-break responsibility proof decoding header. Specifically, constructing and recording the improved HGT model and its version involves: In this embodiment, the improved HGT model uses the heterogeneous audit graph of electronic contracts as input. The heterogeneous audit graph of electronic contracts includes five types of nodes: contract clause nodes, performance atomic nodes, responsibility status nodes, contract version nodes, and valid audit basis nodes. It also includes five types of edges: performance path edges, accountability path edges, dual mapping edges, audit basis constraint edges, and cross-version same-origin edges. Let the number of nodes be N, the number of edges be E, the number of performance-accountability pairing paths be P, and the number of nodes jointly participating in the revenue sharing of the previous and subsequent contract versions be M. The model includes a character embedding and pooling stage, a heterogeneous node mapping layer, a 3-layer HGT heterogeneous graph message passing layer, a performance-accountability dual mutual attention layer, a version evidence revenue sharing message layer, and a first-break responsibility proof decoding head. Each node text is truncated or padded to 256 characters. A fixed character vocabulary of 8000 characters is used to map the characters into a 64-dimensional embedding vector. After average pooling and max pooling, a 128-dimensional node text vector is generated. This vector is then connected with a 32-dimensional node attribute auxiliary vector to form a 160-dimensional node initial vector. The heterogeneous node mapping layer converts the node initial vector into an N-row 128-column node representation matrix. Each edge consists of a 16-dimensional edge type vector, a 2-dimensional direction code, and a 3-dimensional edge attribute value. After mapping, a 16-dimensional edge attribute representation is generated. Each of the three HGT heterogeneous graph message passing layers has 8 attention heads, each with a dimension of 16. After three rounds of message passing, an N-row 128-column heterogeneous audit graph representation is generated. The performance-accountability dual mutual attention layer reads the performance closed path representation and the default accountability path representation of P groups. Each path contains 5 responsibility states, and each responsibility state is represented in 128 dimensions. Through bidirectional queries, it generates a 5-row, 128-column responsibility dual residual vector and a P-row, 5-column responsibility dual residual value. The version evidence accounting message layer divides the nodes into inherited states, changed states, newly added states, and invalid states based on the same source nodes, node content, association relationships, and valid audit basis of the previous and subsequent contract versions. It outputs an M-row, 4-column version state encoding matrix, an M-row, 128-column version node message matrix, and invalidation masking results. The first breakpoint responsibility proof decoding head connects a 128-dimensional current node representation, a 128-dimensional preceding responsibility state representation, a 128-dimensional responsibility dual residual vector, a 128-dimensional version node message, a 4-dimensional version state code, and a 1-dimensional failure masking flag for each responsibility state, forming a 517-dimensional decoding input. After passing through a 128-dimensional hidden representation and a Sigmoid output, it generates a state reachability score and outputs a 2P x 5 column responsibility state reachability score matrix. Based on the order of responsibility states, it determines the first breakpoint and generates a first breakpoint responsibility proof that includes the path it belongs to, the preceding state, the missing successor state, the contract clause number, the performance atom number, the audit basis number, the affected responsibility path, and the responsibility closure deficiency. With a character vocabulary of 8000, a node hidden dimension of 128, an attention head of 8, and an HGT message passing layer of 3, the improved HGT model contains approximately 1.9 million trainable parameters. The training data comes from the heterogeneous electronic contract review diagram, contract responsibility review results, and reviewer review records in the historical contract review and evidence storage data. The responsibility dual consistency marker, responsibility status reachability marker, and first breakpoint position confirmed by the reviewer are used as training labels. The data is divided into a 70% training set, a 15% validation set, and a 15% test set according to the contract identifier. Different versions of the same contract are included in the same dataset. The model uses the AdamW optimization method, with a batch size of 8, an initial learning rate of 0.0001, a weight decay coefficient of 0.01, an upper limit of the gradient norm of 5, a maximum number of training epochs of 100, and weights of responsibility duality consistency loss, responsibility state reachability loss, and first breakpoint localization loss of 0.3, 0.4, and 0.3, respectively. Training is stopped and the model parameters corresponding to the highest epoch of validation metrics are saved when the validation metrics do not improve after 10 consecutive epochs. Compared with the existing HGT model, the improved HGT model adds a performance-accountability dual mutual attention layer to identify the mismatch of responsibility elements between the performance closed path and the default accountability path, adds a version evidence accounting message layer to distinguish between inherited, changed, added and failed nodes and to shield failed historical messages, and adds a first-break responsibility proof decoding header to locate the first unreachable location according to the order of responsibility status and generate structured proof, thereby improving the accuracy of contract responsibility review, the efficiency of cross-version message reuse, the ability to locate responsibility anomalies and the interpretability of review results; The heterogeneous node mapping layer maps the heterogeneous audit graph of electronic contracts according to node type and edge type, and generates a heterogeneous audit graph representation. The performance-accountability dual mutual attention layer queries the breach accountability path representation using the performance closed path representation, and conversely queries the performance closed path representation using the breach accountability path representation. By comparing the contract performance liability elements and liability status in the bidirectional attention representation, a liability dual residual is generated, where: The mutual attention layer of performance-accountability pairing includes: Path state ordering unit: Reads the performance closed path node representation and the breach accountability path node representation according to the responsibility state order, and generates the performance closed path representation matrix, the breach accountability path representation matrix and the responsibility state missing marker; Responsibility Element Alignment Encoding Unit: Reads the obligor, beneficiary, performance behavior, performance object, triggering condition, performance condition, performance time, performance amount, completion evidence, breach of contract condition, liability assumption method, remedial behavior, obligation termination condition, and liability termination condition, and generates a performance responsibility element matrix and an accountability responsibility element matrix according to the position of the responsibility status; Positive cross-attention unit: Represents the default accountability path by representing the performance closure path, performs transformations on the query vector, key vector, and value vector, and generates a positive attention coefficient matrix and a performance query accountability attention representation; Reverse Cross Attention Unit: Represents the default accountability path as the query performance closed path representation, performs reverse query vector, key vector, and value vector transformations to generate a reverse attention coefficient matrix and an accountability query performance attention representation; Dual residual fusion unit: compares the bidirectional attention representation, the original responsibility status representation, the performance responsibility element matrix and the accountability responsibility element matrix, and fuses the status difference, responsibility element difference, status difference marker and field missing marker to generate a responsibility dual residual vector; Residual Output Unit: Calculates the vector length of the responsibility dual residual vector, generates the responsibility dual residual value, and outputs the responsibility dual residual, positive attention coefficient matrix, and negative attention coefficient matrix according to the performance atom number and responsibility status sequence. The performance-accountability dual mutual attention layer uses a performance closure path to represent the query default accountability path, specifically: Read the performance-accountability dual relationship and heterogeneous audit diagram representation, find the paired performance closure path and breach of contract accountability path according to the performance atom number, read the 128-dimensional node representation corresponding to the trigger condition state, obligation effective state, performance behavior state, completion evidence state and obligation termination condition state from the node representation matrix, arrange them into a 5-row 128-column performance closure path representation matrix according to the responsibility state order, and read the 128-dimensional node representation corresponding to the breach of contract trigger state, breach of contract condition state, liability assumption method state, remedial behavior state and liability termination condition state from the node representation matrix, arrange them into a 5-row 128-column breach of contract accountability path representation matrix according to the responsibility state order; Multiply the performance closure path representation matrix by the query mapping matrix, and multiply the default accountability path representation matrix by the key mapping matrix and the value mapping matrix. Divide the resulting matrix into 8 groups of 5 rows and 16 columns of sub-matrices. For each attention head, calculate the sum of the products of the corresponding components of the query vector of each responsibility status in the performance closure path and the key vector of each responsibility status in the default accountability path. Divide the sum of the products by 4 to generate a 5-row and 5-column positive attention score matrix. Read the field missing markers and failure masking markers of each responsibility status in the default accountability path, write the positions where the field missing marker is 1 or the failure masking marker is 1 into the attention masking matrix, write -10000 in the attention masking positions, and retain the positive attention score in the remaining positions. Perform exponential normalization according to the 5 accountability responsibility statuses corresponding to each performance responsibility status to generate a positive attention coefficient matrix. Multiply the positive attention coefficient matrix with the default accountability path value matrix to generate a 5-row 128-column positive attention representation. The reverse approach, representing the breach of contract accountability path, queries the performance closure path, specifically as follows: Multiply the default accountability path representation matrix with the reverse query mapping matrix, multiply the performance closure path representation matrix with the reverse key mapping matrix and the reverse value mapping matrix, and calculate the sum of the products of each accountability status query vector and each performance status key vector according to the matrix obtained by dividing the matrix by 8 attention heads. Divide the sum of the products by 4 to generate a 5-row, 5-column reverse attention score matrix. Read the field missing flag and failure mask flag of each responsibility status in the performance closed path, write -10000 at the position where the field is missing or the message is invalid, perform exponential normalization according to the 5 performance responsibility statuses corresponding to each accountability responsibility status, generate the reverse attention coefficient matrix, multiply the reverse attention coefficient matrix with the performance closed path value matrix to generate a 5-row 128-column reverse attention representation. By comparing the contractual performance liability elements and liability status in the bidirectional attention representation, a liability dual residual is generated, specifically as follows: Read 14 types of contract performance responsibility elements from the performance atomic nodes corresponding to the pairing path. Convert each type of contract performance responsibility element into a 128-dimensional field vector by character embedding, average pooling and max pooling operations. According to the correspondence between the responsibility status and the contract performance responsibility elements, write the trigger condition and performance condition field vectors into the obligation effective position. Take the average of the field vectors of the obligor, beneficiary, performance behavior, performance object, performance time and performance amount and write them into the performance behavior position. Write the completion evidence field vector into the completion evidence position. Write the breach condition field vector into the breach condition position. Write the liability assumption method, remedial behavior, obligation termination condition and liability termination condition field vectors into the corresponding responsibility status positions respectively. For each liability state in the performance closed path, the positive attention representation is subtracted from the original performance liability state representation dimension by dimension and the absolute value is taken to generate a positive state difference vector. For each liability state in the breach of contract accountability path, the negative attention representation is subtracted from the original accountability liability state representation dimension by dimension and the absolute value is taken to generate a negative state difference vector. The corresponding contract performance liability element field vector is subtracted from the positive attention representation dimension by dimension and the absolute value is taken. The corresponding contract performance liability element field vector is subtracted from the negative attention representation dimension by dimension and the absolute value is taken to generate a liability element difference vector. The forward state difference vector, reverse state difference vector, responsibility element difference vector, bidirectional responsibility state value difference marker, and field missing marker are concatenated. The responsibility residual mapping matrix is ​​input to generate a 128-dimensional responsibility dual residual vector corresponding to each dual position. The sum of squares of the 128 components is calculated and the square root is taken to generate the responsibility dual residual value. The responsibility dual residual vector and responsibility dual residual value are arranged according to the contract version number, performance atom number, and dual order to generate the responsibility dual residual. The version evidence revenue sharing message layer matches cross-version same-source nodes. A node is marked as invalid when at least one of the following conditions is met: the previous version node does not exist in the current version, or the associated valid audit basis is invalid. A node in the current version is marked as newly added when there is no same-source node from the previous version. A same-source node is marked as changed when its content, association, or valid audit basis changes but retains its audit validity. Remaining same-source nodes are marked as inherited. Node messages are reused for inherited states, node messages are calculated for newly added and changed states, and historical messages for invalid states are masked along the association relationship. Version revenue sharing status and invalidity masking results are generated, where: Version evidence revenue sharing message layer includes: Cross-version evidence alignment unit: Matches the same source nodes in the previous and current contract versions, calculates the node content summary, relationship summary and valid review basis summary of the same source node, and generates the same source evidence comparison results; Version Status Adjudication Unit: Based on the existence of nodes, the differences in the three types of evidence summaries, and the validity of valid audit evidence, nodes are divided into inherited status, changed status, newly added status, and invalid status. Revenue sharing message generation unit: Based on the version status adjudication result, reuse valid historical node messages for inherited states, generate current version node messages for newly added states, and generate change node messages for the node difference before and after merging and the current incoming edge messages for changed states. Failure message masking unit: Sets the coefficients of the historical node message and associated historical edge message corresponding to the failure state to 0, and generates failure node record and masked edge record; The revenue sharing result output unit arranges version status codes, version node messages, node message indexes, and failure masking records to generate version revenue sharing status, version node message matrix, and failure masking results. The version evidence-based revenue sharing message layer matches cross-version same-origin nodes, specifically as follows: Read the cross-version same-source edges in the heterogeneous audit graph of the current version of the electronic contract, read the node number of the previous version and the node number of the current version according to the cross-version same-source edges, read the heterogeneous audit graph of the previous version of the electronic contract and the node message of the previous version from the historical contract audit and evidence storage data, match the contract clause node, performance atom node, responsibility status node and valid audit basis node according to the node type code, and directly match the contract version node according to the previous contract version number, and generate a same-source node matching table containing the node number of the previous version, the node number of the current version, the node type code and the cross-version same-source edge number; For each same-origin node, calculate the node content summary, association summary, and valid review basis summary. The node content summary is calculated according to all business fields corresponding to the node type, without including the node number, character position, and graph sequence number. The association summary is calculated after sorting by incoming edge type, outgoing edge type, and business identifier of same-origin adjacent nodes. The valid review basis summary is calculated after sorting by review basis number, review basis version, legal level, and scope of application. All summaries are generated into 64-bit hexadecimal characters using the SHA-256 algorithm. When the current version node has no same source node as the previous version, it is marked as newly added, specifically: Read all nodes in the heterogeneous audit diagram of the current version of the electronic contract, write nodes that do not appear as nodes of the current version in the same source node matching table into the new status, and record the current version node number, node type code, contract version number and new source. The new source is one of the following: new contract clause, new performance atom, new responsibility status, new audit basis. When the content, relationships, or valid review basis of a node with the same origin changes but the review validity is maintained, the change status is marked as follows: Read the preceding and following nodes that are not marked as invalid in the same source node matching table, and compare the content summary, association summary, and valid review basis summary of the preceding and following nodes one by one. If at least one of the three types of summaries is inconsistent, and the valid review basis connected to the current version node remains valid at the current review time, write the current version node into the change status, and record the changed summary type and the preceding and following summary values. If the set of valid review basis is replaced but the scope of application of the review basis after the replacement covers the current node, write the current version node into the change status. The remaining same-origin nodes are marked with their inheritance status, specifically: Read nodes in the same-source node matching table that are not marked as invalid or changed. When the current version node is consistent with the previous version node in terms of node content summary, association summary, and valid audit basis summary, write the current version node into the inheritance state and record the previous version node number, the current version node number, and the reuse message source index. The message for reusing inherited state nodes is as follows: Read the 128-dimensional node message output by the previous version model according to the previous version node number in the inheritance state record. Check the previous version model version and the current model version. If the model versions are consistent, directly copy the 128-dimensional node message and write it to the current version node message position. If the model versions are inconsistent, read the original field of the previous version node and re-execute the heterogeneous node mapping and 3 rounds of message passing using the current model to avoid directly mixing node messages generated by different model parameters. The specific messages for calculating newly added and changed states of the computing nodes are as follows: For newly added state nodes, read the current version's 128-dimensional node type mapping vector and all incoming edges. Calculate the 128-dimensional newly added node message according to the heterogeneous graph message passing operation in S42. For changed state nodes, read the current node representation and the previous version's same-origin node representation. Subtract the current node representation from the previous node representation dimension by dimension to generate a 128-dimensional version change vector. Concatenate the current node representation, version change vector, and current incoming edge aggregation message. Input a 384-row, 128-column change message mapping matrix, perform GELU activation and layer normalization, and generate a 128-dimensional changed node message. Historical messages related to failure states are masked along their relationships, specifically: Read the previous version node number corresponding to the failed node, write all 128 components of the previous version node message to 0, read the adjacent nodes along the fulfillment path edge, accountability path edge, dual mapping edge and audit basis constraint edge of the previous version node, write the historical edge message coefficient connecting the failed node to 0, and write the failed node number, the blocked edge number, the adjacent node number and the blocking reason into the failure blocking record. Cross-version same source edge is only used to record the source of failure and does not propagate historical messages to the current version. The generated version revenue sharing status and failure masking results are as follows: The records of newly added, changed, and inherited states are arranged according to the node number of the current version, and the records of invalid states are arranged according to the node number of the previous version. The state types are encoded as 01, 02, 03, and 04, respectively, where 01 represents the inherited state, 02 represents the changed state, 03 represents the newly added state, and 04 represents the invalid state. The node number, the same-origin node number, the node type code, the state type code, the summary of the content of the preceding and following nodes, the summary of the preceding and following association relationship, the summary of the preceding and following valid review basis, and the node message index are encapsulated to generate the version accounting status. The invalid node number, the blocked edge number, the adjacent node number, the blocking reason, and the message blocking coefficient are encapsulated to generate the invalid blocking result. The decoding header of the first-breakpoint liability certificate arranges the liability status of two types of paths respectively. Based on the liability dual residual, version accounting status, and failure masking result, it determines the reachability. The first position where the previous state is reachable but the current state is unreachable is determined as the first breakpoint. It records the associated path, preceding state, missing successor state, contract clause number, performance atom number, audit basis number, affected liability path, and liability closure deficit, generating the first-breakpoint liability certificate, where: The first-instance liability proof decoding header includes: Path sequence organization unit: Arrange the performance closed path and the breach accountability path according to the order of responsibility status, configure the preceding responsibility status for each responsibility status, and generate the path status sequence and status continuation relationship; State Reachability Decoding Unit: Integrates current node representation, previous node representation, responsibility dual residual vector, version node message, version state encoding and failure masking flag to generate a local state reachability score; Path reachability recursive unit: Recursively deduce the reachability relationship between the previous state and the current state according to the responsibility state sequence, and generate a responsibility state reachability marker matrix; First break point closure calculation unit: Scans the first responsible state that is reachable from the previous state but unreachable from the current state, determines the first break point and calculates the responsibility closure deficiency; Liability proof encapsulation unit: Reads the contract terms, performance atoms, valid audit basis and affected liability path associated with the first breakpoint, and generates the first breakpoint liability proof; The initial liability proof decoding header arranges the liability status of the two types of paths respectively, as follows: Read the path index table and arrange the performance closed path in the order of trigger condition status, obligation effective status, performance behavior status, completion evidence status and obligation termination condition status. Arrange the breach accountability path in the order of breach trigger status, breach condition status, liability assumption method status, remedial behavior status and liability termination condition status. Assign a status sequence from 1 to 5 to the 5 liability statuses of each path. Write all 0 status vectors and write missing mark 1 at the position of missing liability status node. The reachability is determined based on the responsibility dual residual, version accounting status, and failure masking results, specifically as follows: For each responsibility state, read the 128-dimensional current node representation, the 128-dimensional previous responsibility state representation, the 128-dimensional responsibility dual residual vector, the 4-dimensional version state one-hot encoding, and the 1-dimensional failure masking flag. Concatenate the 389 values ​​in the order of current node representation, previous responsibility state representation, responsibility dual residual vector, version state one-hot encoding, and failure masking flag. Input a 389-row, 128-column decoding matrix, perform GELU activation, input a 128-row, 1-column output matrix, and perform Sigmoid transformation to generate a state local reachability score in the range of 0 to 1. A virtual starting state is added before each path, and the reachability flag of the virtual starting state is set to 1. The preceding state of the first responsibility state uses the virtual starting state. When the local reachability score of the state reaches 0.5 and the reachability flag of the preceding state is 1, the reachability flag of the current responsibility state is written to 1. When the local reachability score of the state is less than 0.5 or the reachability flag of the preceding state is 0, the reachability flag of the current responsibility state is written to 0. When the failure masking flag is 1, the local reachability score is not read and the reachability flag is written to 0. 0.5 is taken as the midpoint of the Sigmoid output interval, which is used to distinguish between reachable and unreachable states. The first position that is reachable in the previous state but unreachable in the current state is determined as the first breakpoint, specifically: Scan each responsibility path from 1 to 5 according to the state sequence. Read the reachability markers of the previous state and the current state. When the reachability marker of the previous state is 1 and the reachability marker of the current state is 0, write the current position into the first breakpoint candidate table, stop scanning the responsibility states after the current position in the same responsibility path, and determine the record with the smallest state sequence in the first breakpoint candidate table as the first breakpoint. When the first responsibility state is unreachable, use the virtual starting state as the previous state. When all 5 responsibility states are reachable, write the path closure marker and do not generate a first breakpoint record. The process of generating proof of primary liability is as follows: Read the path type of the first breakpoint and write the path to which it belongs; read the state type of the first breakpoint and write the preceding state; read the state type of the first breakpoint and write the missing successor state; read the performance atomic number and contract clause number according to the responsibility state node of the first breakpoint; read the audit basis number connected to the responsibility state node and performance atomic node along the audit basis constraint edge; and arrange the audit basis numbers in ascending order according to the audit basis sequence. Starting from the first breakpoint responsibility state node, read the remaining responsibility states within the same path along the directed edges pointing to the end point of the path. Read the corresponding responsibility states in the paired path along the dual mapping edges. Then read the remaining responsibility states along the directed edges pointing to the end point of the paired path. Write the searched responsibility path number into the affected responsibility path. The search scope is limited to the same contract version and the same performance atom to avoid writing independent responsibility paths in other contract clauses into the affected responsibility path. The weights of the five responsibility states in each responsibility path are all set to 0.2. All five responsibility states are essential sequential nodes for responsibility closure. Using the same weight avoids artificially amplifying a single responsibility stage. Starting from the first breakpoint, the reachable responsibility states marked as 0 are counted. The 0.2 values ​​corresponding to each unreachable responsibility state are added together to generate the responsibility closure deficit. The responsibility closure deficit is at least 0.2 and at most 1. The path, first breakpoint sequence, preceding status, missing successor status, contract clause number, performance atom number, audit basis number sequence, affected responsibility path number sequence, responsibility closure deficit, first breakpoint node number, associated edge number, responsibility dual residual value, version status type and failure masking mark are encapsulated in a fixed order, assigned a first breakpoint responsibility certificate number, and generated a first breakpoint responsibility certificate. Encapsulate the dual residuals of responsibility, version accounting status, failure masking results, first-line responsibility proof and data index, allocate result index, and generate contract responsibility audit results.

[0028] In this embodiment, generating the responsibility restoration result includes: Extract the missing subsequent status, contract clause number, and affected liability path from the initial liability certificate. Retrieve contract performance liability elements based on the contract performance audit data index, and locate candidate modification fields, including: Based on the contract performance review data index, the contract performance responsibility elements are retrieved, specifically: Read the contract performance review data index from the contract liability review results, and locate the contract performance review data based on the contract performance review data index; Read the performance atomic table, the performance atomic audit basis association table, and the contract clause number mapping table. According to the performance atomic number in the liability repair starting point record, read the obligor, beneficiary, performance behavior, performance object, triggering condition, performance condition, performance time, performance amount, completion evidence, breach of contract condition, liability assumption method, remedial behavior, obligation termination condition, and liability termination condition in the performance atomic table. Read the field values, source responsibility statement number, start character position, end character position, and field missing flag corresponding to each contract performance responsibility element; read other performance atoms within the same contract clause according to the contract clause number; read all responsibility status and dual mapping records within the affected responsibility path according to the affected responsibility path number; and generate a responsibility repair reading record. Locate the candidate fields to be modified, specifically: Establish a field mapping table between missing subsequent states and contract performance responsibility elements, mapping the obligation effective state to triggering conditions and performance conditions, and mapping the performance behavior state to the obligor, beneficiary, performance behavior, performance object, performance time, and performance amount; Map the status of completed evidence to completed evidence, the status of termination of obligation to the conditions for termination of obligation, the status of breach triggering and breach being established to the conditions for breach, the status of liability assumption to the method of liability assumption, and the status of remedy to remedy behavior. Map the status of termination of liability to the conditions for termination of liability. Read the corresponding field type according to the missing successor status in the responsibility repair starting point record, write the fields with empty string values, fields marked as missing as 1, and fields with status values ​​of 0 into the candidate modification field table, map the feature dimensions in the responsibility dual residual that exceed the residual effective threshold to the corresponding contract performance responsibility elements and write them into the candidate modification field table. The residual effective threshold is taken as the 95th percentile of the absolute value of the responsibility dual residual corresponding to the responsibility path closure sample in the training set. Arrange the candidate modification field table according to the contract clause number, performance atom number, field starting character position and field type, and keep only 1 record for duplicate fields. Based on the standard contract data index, similar contract fields are extracted from electronic contract data, standard contract terms and enterprise review rules are extracted from the review basis data, and candidate modification operations are generated by combining valid review basis. Specifically, generating candidate modification operations by combining valid review basis involves: Candidate modification operation combinations are constructed starting from 1 based on the number of candidate modification fields. Atomic candidate modification operations acting on different fields are combined into the same candidate modification operation. Different atomic candidate modification operations acting on the same field are generated into independent candidate modification operations. Replacement and deletion operations within the same character range are not written into the same combination. Two candidate field values ​​for the same field are not written into the same combination. Candidate modification operations are arranged in ascending order of the number of modified fields, contract clause number, starting character position of the field, and character encoding of the candidate field value. A 6-digit candidate modification operation number starting from 000001 is assigned to each candidate modification operation. Perform candidate modification operations, update the performance atom, performance-accountability duality and electronic contract heterogeneous audit diagram, input the updated electronic contract heterogeneous audit diagram into the improved HGT model, and generate candidate repair audit results; Candidate modification operations that retain the responsibility path closure, eliminate the original initial breakpoint, maintain the state of the unmodified responsibility path, and do not generate new responsibility dual residuals are used to generate valid repair results, including: Candidate modification operations that retain the responsibility path closure, eliminate the original first breakpoint, maintain the state of the unmodified responsibility path, and do not generate new responsibility dual residuals are as follows: Read the updated first-break liability certificate from the candidate repair review results, check the reachability values ​​of all necessary liability states in the affected liability path item by item. When the reachability values ​​of the obligation effective state, performance behavior state, completion evidence state, and obligation termination state in the performance closure path are all 1, write the performance path closure mark. When the breach accountability path has been activated by the breach trigger state, when the reachability values ​​of the breach establishment state, liability assumption state, remedial state, and liability termination state are all 1, write the accountability path closure mark. When the breach accountability path has not been activated, do not perform the accountability path closure check. When the reachability value of the missing successor state corresponding to the original first breakpoint changes from 0 to 1 and the updated first-break liability certificate does not record the first breakpoint in the same position, write the original first breakpoint elimination mark. Candidate modification operations that retain the responsibility path closure, eliminate the original first breakpoint, maintain the state of the unmodified responsibility path, and do not generate new responsibility dual residuals are as follows: Read the original contract responsibility review results and candidate repair review results, match the unmodified responsibility path according to the responsibility path number, compare the status type, status sequence and reachable value of the unmodified responsibility path item by item, and write the unmodified responsibility path status retention flag when all are consistent. Read the original responsibility dual residual and the updated responsibility dual residual, and determine the position where the absolute value of the residual exceeds the residual effective threshold as the effective residual position. If there is no position outside the original effective residual position set in the updated effective residual position set, write the no new responsibility dual residual flag. If the performance path closure flag, accountability path closure flag, original first breakpoint elimination flag, unmodified responsibility path status retention flag and no new responsibility dual residual flag are all satisfied, the candidate modification operation is retained. The generated valid repair results are as follows: The retained candidate modification operation numbers, modified field records, contract terms text before modification, contract terms text after modification, updated performance atoms, updated performance-accountability dual relationship, updated electronic contract heterogeneous audit diagram index, candidate repair audit results, and 5 types of verification marks are associated and assigned a 6-digit valid repair result number starting from 000001, and a valid repair result table is generated. Sort by the number of modified fields, the number of modified clauses, the number of modified characters, and the number of affected liability paths. The first result is determined as the minimum liability remediation closure, which is then encapsulated with the contract liability audit result to generate the liability remediation result, where: The first result is determined as the least-responsible repair closure, specifically: Read the first valid repair result after sorting, and encapsulate the candidate modification operation, candidate modification field, field value before modification, field value after modification, contract clause text before modification, contract clause text after modification, affected performance atom number, affected responsibility path number, updated electronic contract heterogeneous audit diagram index, candidate repair audit result and 5 types of verification marks in the first valid repair result. Calculate the number of modified fields, the number of modified clauses, the number of modified characters and the number of affected responsibility paths, and generate the minimum responsibility repair closure. The contract liability review results are packaged together to generate liability remediation results, specifically: Read the contract liability audit result index, the minimum liability repair closure, the original initial liability certificate, the updated initial liability certificate, the original electronic contract heterogeneous audit diagram index, and the updated electronic contract heterogeneous audit diagram index. Concatenate them in a fixed order according to the contract identifier, contract version number, contract liability audit result index, candidate modification operation number, and updated electronic contract heterogeneous audit diagram index, and calculate the SHA256 digest. Use the 64-bit hexadecimal digest as the liability repair result index. Encapsulate the liability repair result index, contract liability audit result index, minimum liability repair closure, original initial liability certificate, updated initial liability certificate, and candidate repair audit results to generate the liability repair result.

[0029] In this embodiment, the generation of the audit proof inheritance-verification chain includes: Extract the initial breakpoint liability proof, version accounting status, and minimum liability repair closure from the liability repair results. Based on the standard audit contract data index, extract the previous version's proof branch from historical contract audit and evidence storage data. Match the preceding and following proof branches according to the path of the initial breakpoint, the performance atom number, and the missing successor status to generate a proof dependency set and a proof branch summary, where: Based on the standard contract data index, the previous version's proof branch is extracted from the historical contract review and evidence storage data, specifically as follows: Read the standard audited contract data index from the contract liability audit results associated with the liability repair results. Based on the standard audited contract data index, read the contract identifier, the current contract version number, and the previous contract version number. If the current contract version is the first version, write the previous contract version number into an empty string and generate an empty previous version proof branch table. If the current contract version is not the first version, locate the previous version contract audit evidence data in the historical contract audit evidence data according to the contract identifier and the previous contract version number, and read the previous version audit evidence inheritance-reversal chain, the previous version proof branch table, and the previous version proof dependency set. Read the previous version's proof branch table, including the previous proof branch number, proof branch identification key, path of the first breakpoint, performance atom number, missing successor status, proof branch summary, proof record type, and proof dependency object number sequence. Delete branch records whose proof record type is write-off and which have not been reactivated in the current version. When there are multiple non-write-off records for the same proof branch identification key, sort them in descending order of contract version number and ascending order of proof branch number, retain the first record in the sorted list as the valid proof branch of the previous version, and generate the previous version's proof branch read table. The branching is proven according to the path to which the first breakpoint belongs, the fulfillment atom number, and the missing successor state before and after matching, specifically as follows: Read the identification key of the current proof branch one by one, and look for the previous proof branch in the previous version proof branch reading table. The previous proof branch has the same path as the first breakpoint, the same cross-version source relationship in the performance atom number, and the same missing successor state. When the performance atom numbers are completely consistent, the matching relationship is directly established. When the performance atom number changes, look for the previous version performance atom number based on the cross-version source edge in the electronic contract heterogeneous audit diagram. When the previous version performance atom number connected by the cross-version source edge is consistent with the previous proof branch record, the matching relationship is established. When a current proof branch matches multiple previous proof branches, the matching results are sorted in descending order of the previous contract version number, with inheritance taking precedence over replacement in the proof record type, and the proof branch number in ascending order. The first result in the sorted list is retained. If a previous proof branch has already established a matching relationship with other current proof branches, it will not establish a matching relationship with a second current proof branch. The numbers of the proof branches before and after the successful match are written into the proof branch matching table, and the unmatched current proof branches are written into the current unmatched table. The unmatched previous proof branches are written into the previous unmatched table. Generate a set of proof dependencies and a summary of proof branches, specifically as follows: For each current proof branch, read the contract clause node corresponding to the contract clause number, the performance atomic node corresponding to the performance atomic number, the responsibility status node within the affected responsibility path, the valid audit basis node corresponding to the associated audit basis number, the previous version node connected by the cross-version same source edge, and the minimum responsibility repair closure, and write the contract clause node number, performance atomic node number, responsibility status node number, valid audit basis node number, previous version same source node number, and candidate modification operation number into the dependency object record; For each dependent object, the system reads the object type, object number, contract version number, version status flag, object content summary, and source data index. The object content summary of the contract clause node is calculated based on the contract clause text. The object content summary of the performance atom node is calculated based on 14 types of contract performance responsibility elements. The object content summary of the responsibility status node is calculated based on the status type, status value, missing flag, and status sequence. The object content summary of the valid audit basis node is calculated based on the audit basis number, legal level, scope of application, and audit basis version. The object content summary of the minimum responsibility repair closure is calculated based on the modified field type, field value before modification, field value after modification, affected responsibility path number, and updated electronic contract heterogeneous audit graph index. All summaries are generated as 64-bit hexadecimal characters using the SHA-256 algorithm. The dependent object records are arranged in ascending order according to the dependent object type code and dependent object number. The proof branch number, proof branch identification key, dependent object type code, dependent object number, version status flag, object content digest, and source data index are concatenated in a fixed order to generate a proof dependency set. All fields in the proof dependency set are converted to UTF-8 byte sequences. Adjacent dependent object records are concatenated using newline characters. SHA-256 calculation is performed on the concatenation result to generate a 64-bit hexadecimal proof branch digest. A new proof record is generated when the current proof branch does not match the previous proof branch. A proof cancellation record is generated when the previous proof branch does not match the current proof branch and at least one item in the invalid state dependency object of the matching proof branch is true. A proof inheritance record is generated when there is no invalid state dependency object and the digests before and after are consistent. A proof replacement record is generated when there is no invalid state dependency object and at least one item in the changed state dependency object and the new state dependency object exists and the digests before and after are inconsistent. Write the branch numbers and summaries of the proofs before and after, the number of the object triggering the change, the number of the object triggering the failure, and the minimum liability repair closure. Connect the proof records according to the contract version number to generate the audit proof inheritance-reversal chain. Specifically, the generation of the audit proof inheritance-reversal chain is as follows: The complete proof record is used as the proof chain node, and the proof connection record is used as the proof chain edge. The proof chain nodes are arranged in ascending order according to the proof record number, and the proof chain edges are arranged in ascending order according to the previous proof record number and the current proof record number. The proof chain node table and the proof chain edge table are converted into UTF-8 byte sequences and connected in sequence. SHA-256 calculation is performed on the connection result to generate a 64-bit hexadecimal proof chain index. The proof chain index, proof chain node table, proof chain edge table, proof dependency set, proof branch matching table, contract identifier and contract version number are encapsulated to generate the audit proof inheritance-verification chain.

[0030] In this embodiment, generating contract review and evidence storage data includes: Based on the data index in the audit certificate inheritance-verification chain, standard audit contract data, electronic contract heterogeneous audit diagram, contract liability audit results, and liability remediation results are retrieved. Contract content summary, heterogeneous audit diagram summary, and audit certificate summary are calculated, including: Calculate the contract summary, specifically: The system retrieves the contract identifier, contract version number, contract clause number, contract clause text, subject information, subject matter information, performance area, and time information corresponding to the current contract version from the standard contract review data. The contract clause records are arranged in ascending order according to the contract clause number. Carriage returns in the contract clause text are uniformly converted to line breaks. Two or more consecutive spaces are compressed into one space. Full-width numbers and letters are converted to half-width characters. Chinese punctuation marks and clause numbers are retained. Subject information is arranged in ascending order according to subject name and unified social credit code. Subject matter information is arranged in ascending order according to subject matter number. Time information is uniformly converted to year-month-day-hour-minute-second format. The contract identifier, contract version number, subject information, subject matter information, performance region, time information, and contract terms are arranged in a fixed order. For each field, a field name, field value byte length, and field value are written. When the field value is empty, the byte length is written as 0. The arrangement result is converted into a UTF-8 byte sequence. SHA-256 calculation is performed on the UTF-8 byte sequence to generate a contract content summary consisting of 64 hexadecimal characters. The contract content summary is then associated with the standard audited contract data index. The summary of the heterogeneous audit graph is as follows: Read the heterogeneous node record table, heterogeneous edge record table, node type code table, edge type code table, and graph index from the heterogeneous audit graph of electronic contracts. Sort the heterogeneous node records in ascending order by node number and the heterogeneous edge records in ascending order by edge number. The fields of the node records are arranged in the order of node number, node type code, contract version number, contract clause number, performance atom number, status type, status value, audit basis number, and object content. The fields of the edge records are arranged in the order of edge number, edge type code, starting node number, ending node number, contract version number, and edge attribute. The node type encoding table, edge type encoding table, heterogeneous node record table, and heterogeneous edge record table are sequentially converted into UTF-8 byte sequences. The record byte length is written before each record. All byte sequences are concatenated sequentially and SHA-256 calculation is performed to generate a heterogeneous audit graph digest consisting of 64 hexadecimal characters. The heterogeneous audit graph digest is compared bit by bit with the graph index in the heterogeneous audit graph of the electronic contract. If they match, a graph digest consistency flag of 1 is written. If they do not match, a graph digest consistency flag of 0 is written and the blockchain writing operation for the current contract version is stopped. The calculation of the audit certificate summary is as follows: Retrieve the dual residuals of responsibility, version accounting status, failure masking results, and first-line liability proof from the contract liability audit results. Retrieve the minimum liability repair closure, the original first-line liability proof, and the updated first-line liability proof from the liability repair results. Retrieve the proof chain node table, proof chain edge table, and proof dependency set from the audit proof inheritance-verification chain. Arrange the first-line liability proof according to the performance atom number and the liability path number. Arrange the version accounting status according to the object type code and the object number. Arrange the minimum liability repair closure according to the candidate modification operation number. Arrange the proof chain nodes according to the proof record number. Arrange the proof chain edges according to the previous proof record number and the current proof record number. The feature dimension numbers and residual values ​​in the dual responsibility residuals are converted into fixed 6-digit decimal text, and meaningless zeros at the end of the decimals are removed. The version accounting status is written as object number, object type and status flag. The first break responsibility proof is written as the path to which the first break point belongs, the performance atom number, the missing successor status, the affected responsibility path number and the responsibility closure deficit. The minimum responsibility repair closure is written as the candidate modification operation number, the modified field type, the field value before modification, the field value after modification and the updated electronic contract heterogeneous audit graph index. The proof chain nodes and proof chain edges are arranged according to the fixed field order. The arrangement result is converted into a UTF-8 byte sequence and SHA-256 calculation is performed to generate an audit proof digest consisting of 64 hexadecimal characters. Extract the cross-version audit coupling summary of the previous version from the historical contract audit and storage data. For the first contract version, calculate the version succession summary based on the contract identifier and contract version number. For non-first contract versions, use the cross-version audit coupling summary of the previous version as the version succession summary. By combining the contract identifier, contract version number, contract content summary, heterogeneous audit diagram summary, audit certificate summary, version succession summary, model version, and audit basis version, a cross-version audit coupling summary is calculated. Specifically, the calculation of the cross-version audit coupling summary involves: Perform SHA-256 calculation on the input sequence of cross-version audit coupling digest, convert the calculation result into 64 lowercase hexadecimal characters, generate cross-version audit coupling digest, and write the contract identifier, contract version number, contract content digest, heterogeneous audit graph digest, audit proof digest, version inheritance digest, model version, audit basis version sequence and cross-version audit coupling digest into the coupling digest record, and associate the coupling digest record with the proof chain index in the audit proof inheritance-verification chain; The audit data is saved to off-chain storage, and the contract identifier, contract version number, cross-version audit coupling summary, and off-chain storage index are written into the blockchain ledger to generate contract audit evidence data, including: The audit data will be saved to off-chain storage space, specifically as follows: The audit data package is composed of standard audit contract data, electronic contract heterogeneous audit diagram, contract liability audit results, liability repair results, audit proof inheritance-verification chain, and coupled summary records. The data objects are arranged in the order of standard audit contract data, electronic contract heterogeneous audit diagram, contract liability audit results, liability repair results, audit proof inheritance-verification chain, and coupled summary records. For each data object, the object type, data index, data byte length, and data content are written. All data objects are converted to UTF-8 byte sequences and concatenated to generate the audit data package byte sequence. Perform SHA-256 calculation on the byte sequence of the audit data packet to generate a 64-bit audit data packet digest. Concatenate the contract identifier, contract version number and audit data packet digest with slash characters to generate an off-chain object key. Write the byte sequence of the audit data packet to the storage location corresponding to the off-chain object key in the off-chain storage space. After writing, reread the byte sequence of the audit data packet from the off-chain storage space and recalculate the digest. When the recalculated result is consistent with the audit data packet digest, confirm that the saving is successful. Combine the off-chain object key and the audit data packet digest into an off-chain storage index. The contract identifier, contract version number, cross-version audit coupling summary, and off-chain storage index are written into the blockchain ledger, specifically as follows: Construct a blockchain write record. The blockchain write record arranges the fields in the following order: contract identifier, contract version number, cross-version audit coupling digest, off-chain object key, and audit data packet digest. Write the field length in bytes for each field. Convert the blockchain write record into a UTF-8 byte sequence. Submit the blockchain write record through the blockchain ledger write interface and receive the transaction identifier, block height, block time, and transaction status returned by the blockchain ledger. When the transaction status is successful, the write result in the blockchain ledger is read according to the transaction identifier. The contract identifier, contract version number, cross-version audit coupling summary, off-chain object key and audit data package summary in the read result are compared with the submission fields one by one. If all are consistent, the on-chain verification flag 1 is written. If any one item is inconsistent, the on-chain verification flag 0 is written. When the transaction status is failed or the on-chain verification flag is 0, no valid contract audit evidence data is generated and the reason for failure is recorded. Generate contract review and evidence storage data, specifically as follows: When the on-chain verification flag is 1, the contract identifier, contract version number, contract content summary, heterogeneous audit graph summary, audit proof summary, version inheritance summary, cross-version audit coupling summary, model version, audit basis version sequence, off-chain storage index, transaction identifier, block height, and block time are encapsulated in a fixed order. The encapsulation result is converted into a UTF-8 byte sequence and SHA-256 calculation is performed to generate a contract audit evidence data index consisting of 64 hexadecimal characters. The contract audit evidence data index is associated with the encapsulation result to generate contract audit evidence data.

[0031] In this embodiment, generating the contract review and verification result includes: Extract the contract identifier and contract version number from the verification instruction, and read the on-chain cross-version audit coupling summary, electronic contract heterogeneous audit diagram, contract liability audit result and audit proof inheritance-verification chain based on the contract audit and storage data; Recalculate the cross-version audit coupling digest and compare it with the on-chain digest to generate a digest consistency marker; Input the heterogeneous audit diagram of electronic contract into the improved HGT model of the corresponding model version, recalculate the dual residual of liability, version accounting status and first-time liability proof, and compare it with the contract liability audit results to generate a consistent audit result mark. Check the proof branch numbers and summaries before and after the contract version number, and generate a continuous proof chain marker; If all three tags are consistent, a verification pass result is generated; if at least one tag is inconsistent, a verification failure result is generated and the location of the inconsistent data is recorded, and a contract audit verification result is generated.

[0032] Example 1: Cross-version review and verification of electronic contracts were carried out in the contract review center of a certain enterprise. A total of 1,260 purchase contracts, technical service contracts and equipment maintenance contracts were received, resulting in 2,874 contract versions, 38,642 contract clauses, 17,680 performance records, 328 review documents and 2,874 historical contract review and verification records. Traditional methods, such as keyword dictionary matching, 128-dimensional clause text classification network, fixed liability association rules and SHA-256 single file digest for evidence storage, are difficult to continuously express the performance path and accountability path. Old version clauses and invalid review documents also interfere with the current review. 2180 contract versions from 960 contracts were selected as training samples, containing 29460 liability clauses. Reviewers verified the performance closure path, breach of contract accountability path, liability status accessibility, and first breakpoint location, resulting in 18420 sets of liability duality consistency labels, 92100 liability status accessibility labels, and 7356 first breakpoint labels. The training set contained 672 contracts, while the validation and test sets each contained 144 contracts. All versions of the same contract were written into only one dataset. The model used a batch size of 8, an initial learning rate of 0.0001, a weight decay coefficient of 0.01, a gradient norm upper limit of 5, and a maximum training epoch of 100. The three loss weights were set to 0.3, 0.4, and 0.3. The highest validation index was achieved in the 68th epoch: the macro-average F1 score for liability duality consistency was 0.918, the macro-average F1 score for liability status accessibility was 0.931, and the first breakpoint location accuracy was 0.906. The simulated audit object is an equipment procurement contract containing 6 contract versions. The main text contains 42 contract clauses, and the performance records include 18 delivery records, 11 acceptance records, 9 payment records, and 4 remedial records. The audit basis includes 7 legal rules, 12 industry standards, 26 enterprise audit rules, and 18 standard contract clauses. After completing field unification, version sorting, and audit basis validity screening, 42 standard contract clause records and 63 valid audit basis records are generated. 14 types of contract performance responsibility elements are extracted and combined to generate 96 performance atoms. Based on 96 performance atoms, 96 performance closed paths and 38 activated breach accountability paths are constructed, forming 134 liability paths and 670 liability status nodes. The electronic contract heterogeneous audit graph also includes 42 contract clause nodes, 96 performance atom nodes, 6 contract version nodes, and 63 valid audit basis nodes, with a total of 877 nodes and 2946 edges. The improved HGT model generates an 877-row, 128-column node representation matrix. The performance-accountability dual mutual attention layer performs bidirectional queries on 96 paired paths. The version evidence accounting message layer divides the current version's 877 nodes into 664 inherited nodes, 126 changed nodes, and 87 new nodes. 52 nodes from the previous version that did not enter the current version are marked as invalid. 664 sets of historical node messages are reused, 213 sets of changed and new node messages are recalculated, and 52 sets of invalid historical node messages and 164 related historical edge messages are blocked. The initial liability proof decoding head performed reachability judgments on 670 liability statuses, identified 31 initial breakpoints, and resolved 12 cases of missing evidence, 5 cases of missing performance conditions, 6 cases of missing liability assumption methods, 4 cases of missing remedial actions, and 4 cases of missing liability termination conditions. One payment liability path changed from reachable to inaccessible at the acceptance completion evidence location. The model associated 1 contract clause number, 1 performance atom number, 3 valid audit bases, and 2 affected liability paths. The method generated 184 sets of candidate modification operations, and after 4 checks, retained 46 sets of valid repair results. The first result in the sorted list modified 2 fields, 1 contract clause, and 27 characters. After re-auditing, the original initial breakpoints were eliminated, and the consistency rate of the unmodified liability path status was 100%. The method generates 8 new proof records, 17 inherited proof records, and 6 replacement proof records. The 31 current proof records correspond one-to-one with the 31 initial breakpoints. Additionally, it generates write-off records for 5 proofs in the previous version that did not match the current proof branch, resulting in a total of 36 proof records. It concatenates and calculates a cross-version audit coupling summary by combining 8 types of fields: contract identifier, contract version number, contract content summary, heterogeneous audit graph summary, audit proof summary, version inheritance summary, model version, and audit basis version. It saves the 18.6MB audit data package to off-chain storage space and writes the 1.4KB evidence storage field to the blockchain ledger. After modifying one payment ratio field in the off-chain contract terms, the method locates the corresponding contract terms and performance atoms within 0.42 seconds. After deleting one proof inheritance record, the proof chain continuity marker changes from 1 to 0. The comparative experiment was conducted using the same training data, test data, and computing equipment. The classification threshold for both methods was set to 0.5. Each contract was tested three times and the average value was taken. The accuracy rates for identifying liability clauses using the traditional method and the present invention were 82.6% and 94.1%, respectively. The accuracy rates for cross-clause liability association were 71.8% and 92.7%, respectively. The accuracy rates for locating the first breakpoint were 63.5% and 90.4%, respectively. The false alarm rates affected by the old version's invalidation information were 18.9% and 5.7%, respectively. The average number of modified fields was 5. The average number of modified clauses was 3.4 and 1.5 respectively, with 8 and 2.3 respectively. The new liability conflict rates after modification were 14.2% and 3.1% respectively. In the first full review of the contract version, the traditional method took an average of 43.7 seconds and the invention took an average of 48.6 seconds. In the incremental review of the second to sixth contract versions, the traditional method took an average of 46.2 seconds and the invention took an average of 31.8 seconds. The overall average time for the six versions decreased from 45.8 seconds to 34.6 seconds, and the manual review time decreased from 38.5 minutes to 17.6 minutes. In 322 test contract versions with complete data, the consistency rate of the audit reenactment of this invention was 100%. In addition, 5 contract versions were selected to perform off-chain attachment deletion experiments. All 5 contract versions were judged to have failed verification and the missing attachment positions were located. The anomaly detection rate and anomaly location rate were both 100%. This embodiment proves that the present invention can complete the construction of contract responsibility path, cross-version evidence accounting, first-instance responsibility positioning, minimum responsibility repair, audit proof inheritance and cancellation, blockchain notarization and audit process reenactment, verifying the engineering feasibility and effectiveness of the present invention.

[0033] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for intelligent review and evidence storage of electronic contracts based on deep learning and blockchain, characterized in that, include: Collect and review contract data, perform preprocessing on the reviewed contract data, and encapsulate it to generate standard reviewed contract data; The contract performance responsibility elements are analyzed from the standard audit contract data to generate performance atoms. The performance atoms are then associated with valid audit basis and encapsulated to generate contract performance audit data. Based on contract performance review data, construct a performance accountability dual relationship, link contract versions, performance elements and valid review basis, and construct a heterogeneous electronic contract review diagram; The heterogeneous audit diagram of the electronic contract is input into the improved HGT model. The responsibility dual residual is generated through the performance-accountability dual mutual attention layer, the version accounting status is generated through the version evidence accounting message layer, the first-judgment liability proof is generated through the first-judgment liability proof decoding head, and the contract liability audit result is encapsulated. Based on the contract liability review results, candidate modification fields are determined and validation is performed. A minimum liability repair closure is generated and encapsulated with the contract liability review results to generate the liability repair result. Based on the version revenue sharing status and initial liability proof in the liability repair results, associate the contract version with the minimum liability repair closure and generate an audit proof inheritance-reversal chain; Based on the audit proof inheritance-verification chain, a cross-version audit coupling summary is constructed and written into the blockchain to generate contract audit evidence storage data; Receive verification instructions for contract review and storage data, and generate contract review and verification results.

2. The method for intelligent review and evidence storage of electronic contracts based on deep learning and blockchain according to claim 1, characterized in that, The contract data to be reviewed includes electronic contract data, review basis data, and historical contract review and evidence storage data.

3. The method for intelligent review and evidence storage of electronic contracts based on deep learning and blockchain according to claim 1, characterized in that, The preprocessing of the contract data to be reviewed includes parsing and standardization, and filtering valid review criteria according to the contract signing time, effective time, performance time, breach time, and termination time.

4. The method for intelligent review and storage of electronic contracts based on deep learning and blockchain according to claim 1, characterized in that, The packaged contract performance verification data includes: Extract the obligor, beneficiary, performance act, subject matter of performance, triggering conditions, performance conditions, performance time, performance amount, evidence of completion, breach of contract conditions, liability assumption method, remedial actions, termination conditions of obligation, and termination conditions of liability from the contract terms. Combine the contract performance liability elements according to the contract terms number and assign performance atom numbers to generate performance atoms. Extract the audit basis number, legal level, scope of application, exception conditions and priority conditions from the valid audit basis; match the performance atoms according to the scope of application; exclude audit basis that meets the exception conditions and sort them to generate a sequence of valid audit basis. Associate the performance atom, contract clause number, contract version number, and valid audit basis sequence, assign data indexes, and generate contract performance audit data.

5. The method for intelligent review and evidence storage of electronic contracts based on deep learning and blockchain according to claim 1, characterized in that, The construction of the heterogeneous audit diagram for electronic contracts includes: Read the performance atoms, connect the triggering conditions, the obligation takes effect, the performance behavior, the evidence of completion and the termination conditions of the obligation, and generate a closed performance path. After the performance time expires, generate a default trigger state based on the lack of performance behavior and the lack of evidence of completion. Connect the default conditions, the method of assuming liability, the remedial behavior and the termination conditions of liability to generate a default accountability path. Based on the elements of contract performance responsibility, two types of paths are matched, and a dual mapping is established between the corresponding responsibility states to generate a performance-accountability dual relationship; Contract terms, performance atoms, liability status, contract version, and valid review basis are written into heterogeneous nodes. Two types of paths, dual mappings, review basis constraints, and cross-version homogeneous relationships are written into heterogeneous edges. Node numbers, edge numbers, and graph indexes are assigned to construct a heterogeneous review graph for electronic contracts.

6. The method for intelligent review and evidence storage of electronic contracts based on deep learning and blockchain according to claim 1, characterized in that, The encapsulation and generation of contract liability review results includes: An improved HGT model was constructed and the model version was recorded. The improved HGT model includes a heterogeneous node mapping layer, a performance-accountability dual mutual attention layer, a version evidence ledger message layer, and a first-break responsibility proof decoding header. The heterogeneous node mapping layer maps the heterogeneous audit graph of electronic contracts according to node type and edge type, and generates a heterogeneous audit graph representation. The performance-accountability dual mutual attention layer queries the breach accountability path representation using the performance closed path representation, and vice versa queries the performance closed path representation using the breach accountability path representation. By comparing the contract performance responsibility elements and responsibility status in the bidirectional attention representation, the responsibility dual residual is generated. The version evidence accounting message layer matches cross-version same-source nodes. When at least one of the following conditions is met: the previous version node does not exist in the current version or the associated valid audit basis is invalid, it is marked as invalid. When the current version node has no previous version same-source node, it is marked as new. When the content, association relationship, or valid audit basis of the same-source node changes but the audit validity is maintained, it is marked as changed. The remaining same-source nodes are marked as inherited. The node message is reused for the inherited state. The node message is calculated for the new state and the changed state. The historical message is masked along the association relationship for the invalid state. The version accounting status and invalid masking result are generated. The decoding head of the first-break responsibility certificate arranges the responsibility status of the two types of paths respectively. Based on the responsibility dual residual, version accounting status and failure masking result, the reachability is determined. The first position where the previous state is reachable and the current state is unreachable is determined as the first breakpoint. The path, the preceding state, the missing successor state, the contract clause number, the performance atom number, the audit basis number, the affected responsibility path and the responsibility closure deficiency are recorded to generate the first-break responsibility certificate. Encapsulate the dual residuals of responsibility, version accounting status, failure masking results, first-line responsibility proof and data index, allocate result index, and generate contract responsibility audit results.

7. The method for intelligent review and evidence storage of electronic contracts based on deep learning and blockchain according to claim 1, characterized in that, The generated responsibility restoration result includes: Extract the missing subsequent status, contract clause number and affected liability path from the initial liability certificate, read the contract performance liability elements based on the contract performance audit data index, and locate the candidate modification fields; Based on the standard review contract data index, extract similar contract fields from electronic contract data, extract standard contract terms and enterprise review rules from the review basis data, and generate candidate modification operations by combining valid review basis; Perform candidate modification operations, update the performance atom, performance-accountability duality and electronic contract heterogeneous audit diagram, input the updated electronic contract heterogeneous audit diagram into the improved HGT model, and generate candidate repair audit results; Candidate modification operations that retain the responsibility path closure, eliminate the original first breakpoint, maintain the state of the unmodified responsibility path, and do not generate new responsibility dual residuals are generated to generate valid repair results; Sort by the number of modified fields, the number of modified clauses, the number of modified characters, and the number of affected liability paths. The first result is determined as the minimum liability repair closure, which is then encapsulated with the contract liability audit result to generate the liability repair result.

8. The method for intelligent review and evidence storage of electronic contracts based on deep learning and blockchain according to claim 1, characterized in that, The generation of the audit certificate inheritance-verification chain includes: Extract the first breakpoint liability proof, version accounting status and minimum liability repair closure from the liability repair results. Based on the standard audit contract data index, extract the previous version proof branch from the historical contract audit evidence data. Match the previous and previous proof branches according to the path to the first breakpoint, the performance atom number and the missing successor status to generate a proof dependency set and a proof branch summary. A new proof record is generated when the current proof branch does not match the previous proof branch. A proof cancellation record is generated when the previous proof branch does not match the current proof branch and at least one item in the invalid state dependency object of the matching proof branch is true. A proof inheritance record is generated when there is no invalid state dependency object and the digests before and after are consistent. A proof replacement record is generated when there is no invalid state dependency object and at least one item in the changed state dependency object and the new state dependency object exists and the digests before and after are inconsistent. Write the branch number and summary of the proof before and after, the number of the object that triggered the change, the number of the object that triggered the failure, and the minimum liability repair closure. Connect the proof records according to the contract version number to generate the audit proof inheritance-reversal chain.

9. The method for intelligent review and evidence storage of electronic contracts based on deep learning and blockchain according to claim 1, characterized in that, The generated contract review and evidence storage data includes: Based on the data index in the audit certificate inheritance-verification chain, standard audit contract data, electronic contract heterogeneous audit diagram, contract liability audit results and liability remediation results are read, and contract content summary, heterogeneous audit diagram summary and audit certificate summary are calculated. Extract the cross-version audit coupling summary of the previous version from the historical contract audit and storage data. For the first contract version, calculate the version succession summary based on the contract identifier and contract version number. For non-first contract versions, use the cross-version audit coupling summary of the previous version as the version succession summary. Combine contract identifier, contract version number, contract content summary, heterogeneous audit diagram summary, audit proof summary, version inheritance summary, model version and audit basis version, and calculate cross-version audit coupling summary; The audit data is saved to off-chain storage space, and the contract identifier, contract version number, cross-version audit coupling summary and off-chain storage index are written into the blockchain ledger to generate contract audit evidence data.

10. A method for intelligent review and evidence storage of electronic contracts based on deep learning and blockchain according to claim 1, characterized in that, The generated contract review and verification results include: Extract the contract identifier and contract version number from the verification instruction, and read the on-chain cross-version audit coupling summary, electronic contract heterogeneous audit diagram, contract liability audit result and audit proof inheritance-verification chain based on the contract audit and storage data; Recalculate the cross-version audit coupling digest and compare it with the on-chain digest to generate a digest consistency marker; Input the heterogeneous audit diagram of electronic contract into the improved HGT model of the corresponding model version, recalculate the dual residual of liability, version accounting status and first-time liability proof, and compare it with the contract liability audit results to generate a consistent audit result mark. Check the proof branch numbers and summaries before and after the contract version number, and generate a continuous proof chain marker; If all three tags are consistent, a verification pass result is generated; if at least one tag is inconsistent, a verification failure result is generated and the location of the inconsistent data is recorded, and a contract audit verification result is generated.

Images