A blockchain-based cross-document compliance risk conflict detection method

Abstract

The application discloses a cross-document compliance risk conflict detection method based on a block chain, relates to the technical field of compliance risk control, and comprises the following steps: S1, standardizing preprocessing a plurality of business documents to be detected, generating a document hash value and uploading the document hash value to a block chain for storage, synchronously uploading a rule model hash value containing a detection rule to a chain for solidification, and obtaining on-chain storage document data; S2, extracting compliance clauses from the on-chain storage document data, and performing boundary recognition, type classification and structured conversion. The cross-document compliance risk conflict detection method provided by the application fuses the block chain technology and a customized semantic algorithm, constructs a full-link trusted detection system, ensures the document authenticity by using the non-tamperable characteristics of the block chain, eliminates the problem that the detection basis is not credible from the source, and breaks through the limitation that the traditional scheme has insufficient implicit conflict identification capability by deeply adapting the compliance scene through the improved BERT algorithm.

Description

Technical Field

[0001] This invention relates to the field of compliance and risk control technology, specifically to a blockchain-based method for detecting cross-document compliance risk conflicts. Background Technology

[0002] In core business scenarios such as enterprise bidding, supply chain management, engineering construction, and contract performance, the consistency of compliance clauses across multiple related business documents is a crucial aspect of enterprise compliance control. As enterprises advance their digital transformation, the demand for cross-document compliance risk management continues to rise, and related technical solutions are constantly evolving. Currently, the industry has established two main control solutions: manual review and automated text comparison based on natural language processing. Blockchain technology is also gradually being applied to the field of electronic document storage and management. These various solutions provide technical support for enterprise compliance control from different dimensions and are widely used in scenarios such as contract management and project compliance control.

[0003] Existing technical solutions still face several bottlenecks in practical applications that require optimization. While manual review solutions offer strong scenario adaptability, they are limited in balancing detection efficiency and manpower costs when faced with the need to compare large amounts of related documents. Automated comparison solutions using general natural language processing still have room for improvement in semantic adaptability within compliance-specific domains, and their ability to identify implicit conflicts in compliance scenarios needs refinement. Existing blockchain-based solutions primarily focus on the static on-chain storage of documents, without deep integration with the conflict detection process. Furthermore, various solutions still have room for improvement in areas such as ensuring the reliability of data sources, the traceability of the entire detection process, and the synergistic optimization of recognition accuracy and detection efficiency. To address these issues, we propose a blockchain-based method for cross-document compliance risk conflict detection. Summary of the Invention

[0004] To address the aforementioned technical challenges, this paper presents a blockchain-based method for detecting cross-document compliance risks and conflicts. This solution addresses the multi-dimensional optimization limitations of existing solutions: balancing efficiency and cost is difficult for manual review when dealing with large volumes of documents; general NLP solutions lack adaptability to compliance scenarios and have limited ability to identify implicit conflicts; and blockchain-related solutions are disconnected from evidence storage and detection, with the overall reliability, accuracy, and efficiency of the detection process still needing improvement.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A blockchain-based method for detecting cross-document compliance risk conflicts includes the following steps: S1. Standardize and preprocess several business documents to be tested, generate document hash values ​​and upload them to the blockchain for evidence storage, synchronize the rule model hash value containing the testing rules to the blockchain for solidification, and obtain on-chain evidence document data. S2. Extract compliance clauses from on-chain evidence document data, and generate standardized compliance clause triplet data through boundary identification, type classification and structure transformation; S3. Based on standardized compliance clause triplet data and detection rules, an improved BERT semantic similarity algorithm that integrates a compliance domain knowledge base is used to compare similar clauses between different documents, identify and generate conflict clause pairs. S4. Generate hash values ​​for the conflict clause data and the on-chain traceability information of the corresponding clause's document, and upload them to the blockchain to complete the notarization.

[0006] Preferably, in step S1, the process of performing standardized preprocessing to generate document hash values ​​and uploading them to the blockchain for evidence storage specifically involves: For business documents to be tested in editable formats, the full text content is extracted using a format parsing tool, preserving the original paragraph hierarchy, punctuation marks, and heading structure information; For non-editable scanned documents and image-based business documents to be inspected, the text content is extracted using OCR optical character recognition technology to complete recognition error correction, layout restoration, and garbled character filtering; All text content extracted from the business documents to be tested is uniformly converted into plain text format with UTF-8 encoding; For the standardized plain text, document metadata information is extracted by matching regular expression rules, and core compliant text paragraphs are defined by a preset compliance keyword library; Filter out redundant content without compliance attributes in plain text to complete the initial screening of the core content to be detected in the document; The national standard SM3 cryptographic hash algorithm is used to generate a unique full-text hash value and a set hash value of core compliant paragraphs for each business document to be tested.

[0007] Preferably, in step S1, obtaining the on-chain evidence document data specifically involves: The full text content and core compliance paragraphs of the business document to be tested are stored off-chain in an encrypted distributed manner to obtain the corresponding unique storage address; for the business scenario of the business document to be tested, the corresponding compliance clause extraction rules, semantic similarity calculation model, and conflict determination rules are pre-configured. For the pre-configured rules and complete model content, the national cryptographic SM3 hash algorithm is used to generate the corresponding unique hash value of the rule model; Integrate the full-text hash value, core compliance paragraph set hash value, document metadata, unique storage address, on-chain operation entity information, and on-chain timestamp of each business document to be tested to generate a standardized document on-chain dataset; Integrate the unique hash value of the rule model, the version number of the rule model, the effective time of the rule model, and the corresponding business scenario information to generate a standardized rule model on-chain dataset; The document on-chain dataset and the rule model on-chain dataset are simultaneously sent to each node of the consortium blockchain, and the multi-node data consistency verification and block consensus confirmation are completed through the PBFT consensus mechanism. Write the document dataset and rule model dataset that have completed consensus confirmation to a new block on the consortium blockchain to complete the on-chain notarization of document data and the on-chain solidification of rule model hash values; Based on the block height, block hash, and unique document identifier of the new block, globally unique on-chain evidence document data is generated for each business document to be tested.

[0008] Preferably, in step S2, the compliance clause extraction operation is only performed on on-chain evidence document data that has passed the consensus verification of the consortium blockchain and whose hash value verification is complete. At the same time, the globally unique document identifier ID, version number, on-chain timestamp, and hash verification value corresponding to the on-chain evidence document data are used as fixed binding attributes of the extracted compliance clauses.

[0009] Preferably, in step S2, generating compliance clauses through boundary identification and type classification specifically involves: Using Chinese periods, semicolons, and paragraph line breaks as basic dividing units, and combining them with a compliance-related keyword library, the candidate boundaries of a single clause are defined, generating a clause candidate set. The BiLSTM-CRF sequence labeling model is used to optimize the boundary of the candidate clause set, correct the boundary recognition error of long sentence nesting and cross-paragraph compound clauses, and output a single clause set with complete and independent semantics. Establish a standardized classification system for compliance clauses, setting three fixed classification dimensions: rights and obligations clauses, standard constraint clauses, and time-limited clauses. Based on a pre-tuned Chinese BERT-base text classification model, all clauses within a single clause set are classified and labeled, outputting a set of compliant clauses with fixed classification labels.

[0010] Preferably, in step S2, generating standardized compliance clause triplet data through structured transformation specifically involves: Dependency parsing technique is used to perform semantic parsing on each clause in a set of compliant clauses with fixed classification labels, and to extract the core semantic elements corresponding to the clauses. Following the fixed triplet format of subject-verb-object, the extracted core semantic elements are structurally encapsulated. The subject corresponds to the responsible party or the right holder of the clause, the verb corresponds to the core behavior or constraint requirement of the clause, and the object corresponds to the implementation object or scope of constraint of the core behavior. Bind the encapsulated triple data with the corresponding clause's category tag, globally unique document identifier ID, version number, on-chain timestamp, and hash check value attributes; Perform format consistency checks on all triplet data after binding attributes, remove invalid data that does not conform to the format specifications, and output standardized and compliant clause triplet data.

[0011] Preferably, in step S3, the pre-construction process of the improved BERT semantic similarity algorithm integrating a compliance domain knowledge base specifically includes: For three fixed target scenarios—contracts, bidding, and technical specifications—a dedicated knowledge base for compliance is built. The knowledge base consists of two fixed modules: a compliance terminology dictionary and a clause logic relationship database. The compliance terminology dictionary includes specific compliance terms, legal and regulatory terms, industry standard numbers, and rights and responsibilities-specific terms for the target scenario, and marks the standard definition, synonyms, antonyms, hypernyms, and mutually exclusive terms for each term; The clause logic relationship library organizes fixed compliance conflict determination logic rules, including mutual exclusion rules for permissive and prohibitive clauses, standard level priority rules, correspondence rules for rights and obligations, and logical rules for the sequence of time nodes; Based on the open-source Chinese BERT-base pre-trained model, we use domain-specific corpora for further pre-training to complete the basic domain adaptation of the model. Based on a manually annotated dataset of compliance clause conflicts, the model that has completed further pre-training is subjected to task-supervised fine-tuning to optimize the semantic encoding layer and output layer of the model, thus completing the construction of an improved BERT semantic similarity algorithm.

[0012] Preferably, in step S3, comparing similar clauses across different documents to identify and generate conflict clause pairs specifically involves: Set up two fixed document pair selection modes: automatic association matching and manual specification, to complete the selection of document pairs and generate the detection task. Based on the classification tags of the standardized compliance clause triplet data, only clauses with the same classification tag within a document pair are matched pairwise to generate a set of clause pairs to be compared. For each pair of clauses to be compared, a comprehensive semantic similarity score is calculated using the improved BERT semantic similarity algorithm. Logical verification is then performed in conjunction with the clause logical relationship database to filter out clause pairs that are suspected of conflict. Clauses suspected of conflict are marked with conflict type and divided into two fixed types: direct conflict and indirect conflict. To generate standardized conflict clause pairs, bind the complete attribute information of the corresponding triplet data to the completed clause pairs.

[0013] Preferably, the matching and verification process for conflict clauses between data and the on-chain traceability information of the document to which the corresponding clause belongs is as follows: Extract the globally unique document identifier ID and version number information bound to the conflict clause within the data, and match and retrieve the full on-chain traceability information of the corresponding document on the blockchain; The retrieved on-chain traceability information and the hash verification value of the conflict clause are checked for consistency to confirm the integrity and authenticity of the document corresponding to the conflict clause. Extract the operation logs, judgment criteria, and algorithm model version information of the entire conflict detection process, and perform consistency verification with the hash value of the rule model fixed on the chain to confirm the compliance of the detection process; For the conflict clauses that pass verification, integrate the data, on-chain traceability information, and detection process information to generate a full dataset of conflict detection to be uploaded to the chain.

[0014] Preferably, in step S4, the specific process of generating a hash value and uploading it to the blockchain to complete the notarization is as follows: The national cryptographic SM3 hash algorithm is used to generate unique and immutable hash values ​​for the full dataset of collision detection to be uploaded to the blockchain; The hash value, dataset metadata, off-chain storage address, operation entity information, and timestamp corresponding to the full conflict detection dataset are used to generate a data on-chain proposal, which is then broadcast to all consensus nodes of the consortium blockchain. All consensus nodes perform consistency verification and voting on the received on-chain proposals, and complete block confirmation through the PBFT consensus mechanism; Once the block is confirmed, the hash value, metadata, off-chain storage address, and consensus verification information of the full dataset of conflict detection will be written into the consortium blockchain block to complete the on-chain notarization. Establish a strong correlation mapping between conflict detection data stored on the blockchain and corresponding document storage data to complete the construction of a trustworthy closed loop with full-chain traceability.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: The cross-document compliance risk conflict detection method proposed in this invention constructs a fully trusted detection system by integrating blockchain technology and customized semantic algorithms. It utilizes the immutability of blockchain to ensure document authenticity, eliminating the problem of untrustworthy detection foundation from the source. Through the improved BERT algorithm, it is deeply adapted to compliance scenarios, overcoming the limitations of traditional solutions in identifying implicit conflicts, achieving accurate capture of direct and indirect conflicts, and significantly improving risk identification coverage. The innovative three-layer standardized processing mechanism transforms unstructured text into computable structured data, and the targeted comparison strategy significantly improves detection efficiency. The full-process rule solidification and detection log on-chain technology make the detection process transparent and traceable, forming a judicial-grade trusted evidence chain. Attached Figure Description

[0016] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0017] The following description is intended to disclose the invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art.

[0018] Reference Figure 1 As shown, a blockchain-based method for detecting cross-document compliance risks includes the following steps: S1. Standardize and preprocess several business documents to be tested, generate document hash values ​​and upload them to the blockchain for evidence storage, synchronize the rule model hash value containing the testing rules to the blockchain for solidification, and obtain on-chain evidence document data. In step S1, the standardization preprocessing to generate document hash values ​​and uploading them to the blockchain for evidence storage specifically involves: For editable business documents to be tested, the full text content is extracted using a format parsing tool, preserving the original paragraph hierarchy, punctuation marks, and heading structure information. For Word and WPS format documents, the full text content is extracted using a format parsing tool, while simultaneously preserving the document's chapter hierarchy, clause numbers, and version identification information in headers and footers. For natively editable PDF documents, the text content is extracted using a vector text parsing engine, avoiding text omissions caused by PDF layer overlays and ensuring the completeness of text extraction and format consistency.

[0019] For non-editable scanned documents and image-based business documents to be inspected, the text content is extracted using OCR optical character recognition technology to complete recognition error correction, layout restoration, and garbled character filtering. First, image preprocessing algorithms are used to correct the tilt of the document image, remove background noise, eliminate shadows, and enhance contrast. Then, OCR optical character recognition technology is used to extract the text content, and handwritten annotations are simultaneously identified, marked, and isolated to avoid interference from non-compliant content in subsequent inspections.

[0020] All text content extracted from the business documents to be tested is uniformly converted into plain text format with UTF-8 encoding; For the standardized plain text, the document metadata information is extracted by regular expression matching, and the core compliant text paragraphs are defined by a preset compliance keyword library. The regular expression matching adopts a multi-round progressive matching strategy. The first round matches basic identifier information such as document title, signing and publishing entity, effective time, document unique number, and version number. The second round matches entity identity information such as the full name, unified social credit code, legal representative, address, and contact information of both parties to the contract. The third round matches related information such as project name, project number, and business scenario identifier, thus completing the full extraction of document metadata.

[0021] The pre-set compliance keyword library adopts a dynamic update mechanism, covering compliance trigger words such as should, must, must not, have the right, prohibit, be responsible, implementation standards, acceptance specifications, deadline, liability for breach of contract, and dispute resolution. At the same time, it supplements exclusive keywords based on business scenarios and defines core text paragraphs containing compliance risks.

[0022] Filter out redundant content without compliance attributes in plain text to complete the initial screening of the core content of the document; the filtered content includes the preface, general instructions, table of contents, signature page, and non-binding promotional content, further narrowing the scope of subsequent content processing.

[0023] The SM3 cryptographic hash algorithm, a national standard, is used to generate a unique full-text hash value and a hash value for the core compliance paragraph set for each document to be inspected. For the full-text content M, its full-text hash value is... The formula for generating it is:

[0024] For the core set of compliant paragraphs, a text sequence is generated by concatenating the paragraphs in the order they appear. Its core compliance paragraph set hash value The formula for generating it is:

[0025] M is a unique hash value for the entire document text, used to verify the integrity and tamper-proof status of the entire document. M is the normalized full-text byte stream data of the document. This is a hash value of the core compliant paragraph set in the document, used to verify the integrity and unaltered status of the core detection content. This is the core compliant paragraph text byte stream data assembled in chronological order.

[0026] In step S1, obtaining the on-chain evidence document data specifically involves: The full text content and core compliance paragraphs of the business documents to be tested are stored off-chain in an encrypted distributed manner to obtain a unique storage address. The off-chain encrypted distributed storage prioritizes the IPFS interplanetary file system, and the document content is encrypted using the AES-256 symmetric encryption algorithm. The encryption key is autonomously controlled by the operating entity, and only the entity holding the corresponding key can read and decrypt the original document. After the document is encrypted, it is written to the IPFS network, generating a unique content addressing CID as the storage address. This address is strongly bound to the document content, and any change to the content will cause the CID to change, further strengthening the immutability of the document content.

[0027] For the business scenarios of the business documents to be tested, the corresponding compliance clause extraction rules, semantic similarity calculation models, and conflict determination rules are pre-configured. During the pre-configuration process, the configuration content of the rules and models must be reviewed and confirmed by the business compliance personnel to ensure that the rules and models meet the compliance control requirements of the corresponding business scenarios and are suitable for the exclusive conflict determination logic of different scenarios such as contracts, bidding, and engineering construction.

[0028] For the pre-configured rules and complete model content, the corresponding unique hash value of the rule model is generated using the national cryptographic SM3 hash algorithm; the complete rule model content sequence is as follows: Its rule model has a unique hash value The formula for generating it is:

[0029] It is a unique hash value for the rule model, used to verify the consistency and tamper-proof status of the rules and model used for detection. This is a byte stream of data containing the complete content of the pre-configured rules and models.

[0030] The system integrates the full-text hash value, core compliance paragraph set hash value, document metadata, unique storage address, on-chain operation entity information, and on-chain timestamp of each business document to be tested, generating a standardized document on-chain dataset. The standardized document on-chain dataset is encapsulated using a fixed JSON structure specification to ensure the consistency of data parsing across nodes. The dataset synchronously includes the business scenario identifier and associated project number of the document for automatic association and matching of subsequent documents.

[0031] By integrating the unique hash value of the rule model, the version number of the rule model, the effective time of the rule model, and the corresponding business scenario information, a standardized rule model on-chain dataset is generated. The standardized rule model on-chain dataset synchronously includes the review record, scope of application, and prohibited scenario information of the rule model, ensuring that the application of the rule model is controllable.

[0032] The document-on-chain dataset and the rule model-on-chain dataset are synchronously sent to all nodes of the consortium blockchain. The PBFT consensus mechanism is used to complete the multi-node data consistency verification and block consensus confirmation. First, the client node initiates the on-chain request. The master node packages the on-chain dataset into a proposal and broadcasts it to all replica nodes. After the replica nodes complete the legality verification of the dataset, they send a preparatory message back to the master node. After the master node collects the preparatory messages from more than two-thirds of the replica nodes, it broadcasts the commit message to all replica nodes. After the replica nodes complete the commit verification, they send a confirmation message back. After the master node collects the confirmation messages from more than two-thirds of the replica nodes, it completes the consensus confirmation process, ensuring the consistency of the on-chain data across all nodes.

[0033] The document dataset and rule model dataset that have completed consensus confirmation are written into a new block of the consortium blockchain, completing the on-chain notarization of document data and the on-chain solidification of rule model hash values. During the writing of the new block, the hash values ​​of the previous blocks are recorded synchronously to form a chain-like association structure, ensuring that the block data is immutable. The data in the block is indexed and stored according to the document identifier and rule model identifier, supporting fast retrieval and retrieval.

[0034] Based on the block height, block hash, and unique document identifier of the new block, generate globally unique on-chain evidence storage document data corresponding to each business document to be tested; Globally unique on-chain evidence document data is generated using fixed-length string encoding. The encoding includes a hexadecimal representation of the block height, the first 16 characters of the block hash, and a hash digest of the document's unique identifier, ensuring the global uniqueness and rapid verifiability of the evidence document data.

[0035] Each document that has been uploaded to the blockchain for notarization is assigned a globally unique document identifier ID. Based on the immutability of the blockchain, a full version management system is built. Each modification or update of the same document generates an independent new version number and a new full-text hash value and a set hash value of core compliant paragraphs. The system synchronously records the operation subject, update time, scope of modified content, and comparison information of the old and new version hashes. All version-related information is written to the blockchain for notarization. The blockchain retains a complete historical version timeline for this unique document identifier ID, allowing users to trace back the complete content and operation records of any historical version through the document identifier ID. At the same time, the latest version currently in effect is clearly marked on the blockchain to avoid detection errors caused by version mixing. Version update operations can only be executed after being verified by the digital signature of the corresponding authorized subject, ensuring the traceability and legality of version changes.

[0036] S2. Extract compliance clauses from on-chain evidence document data, and generate standardized compliance clause triplet data through boundary identification, type classification and structure transformation; In S2, the compliance clause extraction operation is only performed on on-chain evidence document data that has passed the consensus verification of the consortium blockchain and whose hash value verification is complete. At the same time, the globally unique document identifier ID, version number, on-chain timestamp, and hash verification value corresponding to the on-chain evidence document data are used as fixed binding attributes of the extracted compliance clauses.

[0037] Before extracting compliance clauses, a double hash verification of the on-chain evidence document data is performed. First, the hash value of the full text of the document stored on the chain and the hash value of the core compliance paragraph set are retrieved. The hash value of the original content of the document stored off-chain is recalculated. The consistency of the two hash values ​​is compared. Only after the comparison is successful can the compliance clause extraction process be started. If the comparison fails, it is determined that the document content has been tampered with, the extraction process is terminated and an abnormal alarm is triggered to ensure that the data source of the extraction operation is trustworthy throughout the process.

[0038] In S2, generating compliance clauses through boundary identification and type classification specifically involves: Using Chinese periods, semicolons, and paragraph line breaks as basic dividing units, and combining them with a compliance-related keyword library, the candidate boundaries of a single clause are defined, generating a clause candidate set. The basic delimiter matching adopts a context-related matching strategy. When identifying Chinese periods, semicolons, and paragraph line breaks, the semantic integrity of the text before and after the delimiter is checked simultaneously to avoid misidentification of delimiters within quotation marks and parentheses. Combined with a compliance domain trigger keyword library, text paragraphs containing compliance trigger words are identified in a focused manner. Using the trigger words as anchors, the algorithm traces back to the beginning of the sentence and extends forward to the end of the sentence to define the candidate boundaries of a single clause. For composite clauses that span paragraphs, semantic coherence is checked to classify consecutive paragraphs with strong semantic connections as the same candidate clause, avoiding semantic loss caused by clause splitting.

[0039] The BiLSTM-CRF sequence labeling model is used to optimize the boundary of the candidate clause set, correct the boundary recognition error of long sentence nesting and cross-paragraph compound clauses, and output a single clause set with complete and independent semantics. The BiLSTM-CRF sequence labeling model consists of a bidirectional long short-term memory network and a conditional random field layer. The bidirectional long short-term memory network is responsible for extracting the contextual semantic features of the clause text, capturing the positive and negative semantic dependencies of the text, and outputting the label probability distribution corresponding to each character. The conditional random field layer is responsible for global constraint optimization of the label probability distribution, learning the transition dependencies between labels, and avoiding unreasonable label sequence output. The model adopts the BIO labeling system, labeling text characters as three types of labels: clause start position, clause internal position, and clause external position. The model inferences to complete the accurate localization of clause boundaries. During the model training process, a manually labeled compliance clause boundary dataset is used for supervised training to ensure the model's adaptability to compliance domain texts.

[0040] Establish a standardized classification system for compliance clauses, setting three fixed classification dimensions: rights and obligations clauses, standard constraint clauses, and time-limited clauses.

[0041] The rights and obligations clauses are further divided into three sub-dimensions: rights-agreement clauses, obligations-agreement clauses, and prohibition clauses. The rights-agreement clauses cover the claims, demands, exemptions, and other related agreements enjoyed by the subject; the obligations-agreement clauses cover the responsibilities, actions, and payments that the subject should perform. The prohibitive clauses cover the behaviors that the entity is prohibited from engaging in and the restrictions that it is prohibited from breaching. The standard constraint clauses are further subdivided into four sub-dimensions: technical standard clauses, quality requirement clauses, acceptance specification clauses, and implementation specification clauses. The time-limited clauses are further subdivided into four sub-dimensions: effective date clauses, performance period clauses, deadline clauses, and expiration date clauses. This forms a three-tiered standardized classification system for compliance clauses, ensuring that the classification dimensions cover the core elements of compliance management.

[0042] Based on a pre-tuned Chinese BERT-base text classification model, all clauses within a single clause set are classified and labeled, and a set of compliant clauses with fixed classification labels is output. The pre-tuned Chinese BERT-based text classification model is first pre-trained using a large-scale corpus in the compliance domain to learn the semantic expression features of the compliance domain. Then, it is fine-tuned in a supervised manner based on a manually annotated compliance clause classification dataset. During the fine-tuning process, the cross-entropy loss function is used to optimize the model parameters, and an early stopping mechanism is used to avoid model overfitting. The model input is the text content of a single clause, and the output is the probability value of each classification dimension corresponding to the clause. The classification dimension with the highest probability is selected as the final classification label of the clause, thus completing the classification and annotation of all clauses.

[0043] In S2, the standardized compliance clause triplet data is generated through structured transformation as follows: Dependency parsing technique is used to perform semantic parsing on each clause in a set of compliant clauses with fixed classification labels, and to extract the core semantic elements corresponding to the clauses. Dependency parsing employs a pre-trained language model-based dependency parser to parse the syntactic structure of the clause text, identifying dependency relationships between words in the text, including core syntactic relationships such as subject-verb, verb-object, attributive-head, and adverbial-head. Based on the identified dependency relationships, it locates the core subject, core predicate, and core object in the clause, while extracting restrictive content that modifies the core elements and supplementing it to the corresponding core semantic elements. This ensures that the extracted core semantic elements completely cover the constraints of the clause without missing any key information.

[0044] Following the fixed triplet format of subject-verb-object, the extracted core semantic elements are structurally encapsulated. The subject corresponds to the responsible party or the right holder of the clause, the verb corresponds to the core behavior or constraint requirement of the clause, and the object corresponds to the implementation object or scope of constraint of the core behavior. During the structured encapsulation process, for clauses with multiple parallel responsible parties, all parallel parties are integrated into the subject element; for clauses with multiple parallel core behaviors, all parallel behaviors are integrated into the predicate element; and for clauses with multiple constraint scopes, all constraint scopes are integrated into the object element. This ensures that each clause corresponds to a unique triplet of data and avoids comparison errors caused by splitting a single clause.

[0045] Bind the encapsulated triple data with the corresponding clause's category tag, globally unique document identifier ID, version number, on-chain timestamp, and hash check value attributes; During the attribute binding process, the triple data and the corresponding attribute information are strongly associated and encapsulated to generate a unique clause identifier ID. The clause identifier ID is generated based on the document identifier ID, the paragraph number where the clause is located, and the clause sequence number, ensuring the global uniqueness of each clause. The attribute information will accompany the triple data to complete the comparison and detection throughout the entire process, and cannot be tampered with or removed.

[0046] Perform format consistency checks on all triplet data after binding attributes, remove invalid data that does not conform to the format specifications, and output standardized and compliant clause triplet data; The format consistency check includes triple element integrity check, attribute information integrity check, and data format standardization check. The integrity check ensures that the subject, predicate, and object elements of the triple are not empty and that the attribute information is not missing. The format standardization check ensures that the triple data and attribute information conform to the preset structured data format standard. Data that fails the check will be marked as invalid data and removed, and an exception log will be triggered. The final output of standardized and compliant clause triple data can be directly used for subsequent semantic similarity comparison and conflict detection.

[0047] S3. Based on standardized compliance clause triplet data and detection rules, an improved BERT semantic similarity algorithm that integrates a compliance domain knowledge base is used to compare similar clauses between different documents, identify and generate conflict clause pairs. In S3, the pre-construction process of the improved BERT semantic similarity algorithm, which integrates a compliance domain knowledge base, is as follows: For three fixed target scenarios—contracts, bidding, and technical specifications—a dedicated knowledge base for compliance is built. The knowledge base consists of two fixed modules: a compliance terminology dictionary and a clause logic relationship database. The compliance-specific knowledge base adopts a distributed storage architecture, supporting dynamic expansion and updates based on business scenarios. Updates to the knowledge base must be reviewed and confirmed by compliance experts before publication, and the entire update history is recorded to ensure the authority and traceability of the knowledge base content.

[0048] The compliance terminology dictionary includes specific compliance terms, legal and regulatory terms, industry standard numbers, and rights and responsibilities-specific terms for the target scenario, and marks the standard definition, synonyms, antonyms, hypernyms, and mutually exclusive terms for each term; The compliance terminology dictionary covers high-frequency compliance terms found in current national laws and regulations, industry standards and norms, and judicial documents. For each term, the standard definition is manually reviewed and confirmed by compliance experts. The annotation of synonyms, antonyms, hyponyms, and mutually exclusive words is based on the semantic logic of the compliance field, rather than the semantic association of general natural language. This ensures that the term annotation conforms to the semantic expression habits of compliance scenarios, resolves the semantic ambiguity of compliance-specific terms, and provides an accurate semantic benchmark for subsequent semantic similarity calculations.

[0049] The clause logic relationship library organizes fixed compliance conflict determination logic rules, including mutual exclusion rules for permissive and prohibitive clauses, standard level priority rules, correspondence rules for rights and obligations, and logical rules for the sequence of time nodes; The rules for mutual exclusion of permissive and prohibitive clauses are clearly defined. Permissive and prohibitive agreements targeting the same subject and the same behavior directly constitute mutual exclusion and conflict. The rules for the priority of standard levels are clearly defined. The priority of national standards, industry standards, local standards, and enterprise standards decreases in that order. There is no conflict when the requirements of a lower-level standard are stricter than those of a higher-level standard. However, there is a level conflict when the requirements of a lower-level standard are more lenient than the mandatory requirements of a higher-level standard. The rules for the correspondence between rights and obligations are clearly defined. For the same matter, the agreement on rights and obligations must have a correspondence between the subject and the content. Agreements with no corresponding relationship constitute a conflict of rights and responsibilities due to mismatch. The rules for the logical sequence of time nodes are clearly defined. The start time of the same performance matter must be earlier than the deadline, and the completion time of the preceding matter must be earlier than the start time of the subsequent matter. Agreements that do not conform to the logical sequence of time constitute a time-limited conflict. The clause logic relationship library also includes general exception rules in the field of compliance, providing a complete logical basis for conflict determination and avoiding misjudgment.

[0050] Based on the open-source Chinese BERT-base pre-trained model, we use domain-specific corpora for further pre-training to complete the basic domain adaptation of the model. The compliance-specific corpus covers current national laws and regulations, model contracts for various industries, bidding document templates, national and industry standards and norms, judicial rulings issued by the Supreme People's Court, and professional literature in the field of compliance management. Pre-training continues using a masked language model task, randomly masking 15% of the characters in the text and having the model predict the masked characters. This allows the model to learn the semantic features, terminology usage habits, and syntactic expressions in the compliance field. During pre-training, a dynamic learning rate adjustment strategy is employed to avoid catastrophic forgetting and to enable the model to possess a deep semantic understanding capability in the compliance field.

[0051] Based on the manually annotated compliance clause conflict dataset, the model that has completed further pre-training is subjected to task-supervised fine-tuning to optimize the semantic encoding layer and output layer of the model, and to complete the construction of the improved BERT semantic similarity algorithm. The manually annotated compliance clause conflict dataset is annotated by compliance experts. The dataset covers three types of samples: direct conflict, indirect conflict, and no conflict. Among them, the conflict samples account for no less than 40%, ensuring the balance and representativeness of the dataset.

[0052] During fine-tuning, the texts of the two clauses to be compared are concatenated and input into the model. The model outputs the classification probability of whether the two clauses conflict, as well as the semantic vector representations of the two clauses. A joint loss function combining cross-entropy loss and contrastive loss is used to optimize the model parameters. The cross-entropy loss function optimizes the model's conflict classification accuracy, while the contrastive loss function optimizes the model's semantic vector encoding capability. This makes semantically mutually exclusive clause pairs farther apart in the vector space and semantically consistent clause pairs closer together in the vector space, thus completing the optimization of the model's semantic encoding layer and output layer.

[0053] In step S3, comparing similar clauses across different documents to identify and generate conflict clause pairs specifically involves: Set up two fixed document pair selection modes: automatic association matching and manual specification, to complete the selection of document pairs and generate the detection task. In automatic association matching mode, based on the project number, business scenario identifier, and contract association number information in the document metadata stored on the chain, it automatically matches related document pairs under the same business item, including document combinations with strong relationships such as tender documents and bid documents corresponding to the same project, main contract and supporting technical specifications, main contract and supplementary agreement, general contracting contract and subcontracting contract, etc. It automatically generates detection tasks covering all related documents. In manual specification mode, the operating entity can manually select any two or more documents to be detected from the on-chain evidence document library, customize the detection scope, conflict type, and judgment rule threshold, and generate personalized conflict detection tasks. After the detection task is generated, the task information is written to the blockchain to complete the evidence storage and ensure the traceability of the detection task.

[0054] Based on the classification tags of the standardized compliance clause triplet data, only clauses with the same classification tag within a document pair are matched pairwise to generate a set of clause pairs to be compared. During the matching process with the same classification tag, for the classification tag of the subdivision dimension, clauses with the same subdivision dimension are matched first. For example, the rights agreement clause is only matched with the rights agreement clauses of other documents in the same document pair, and the obligation agreement clause is only matched with the obligation agreement clause, which further narrows the comparison scope and reduces invalid comparisons. For clauses with cross-subdivision dimension related logic, supplementary matching is performed based on the clause logic relationship library to ensure that no related omissions.

[0055] For each pair of clauses to be compared, a comprehensive semantic similarity score is calculated using the improved BERT semantic similarity algorithm. Logical verification is then performed in conjunction with the clause logical relationship database to filter out clause pairs that are suspected of conflict. A two-layer weighted fusion similarity calculation mechanism is adopted. The first layer is a weighted calculation of structured triples, in which differentiated weights are assigned to the core elements in the subject-verb-object triples of the clauses. The subject and verb corresponding to the responsible party and the core behavior are assigned the highest weight, accounting for 0.5. The object corresponding to the scope of constraint is assigned the second highest weight, accounting for 0.35. Modifying non-core words are assigned a low weight, accounting for 0.15. The similarity score of each element is calculated by cosine similarity, and then the similarity scores of the structured elements of the clauses are calculated by weighting them according to their corresponding weights. The formula is:

[0056] The subject element weight is set to 0.5. The cosine similarity score is the sum of the subject elements of the two clauses. This is the weight of the predicate element, with a value of 0.35. The cosine similarity score is the sum of the predicate elements of the two clauses. This is the weight of the object element, with a value of 0.15. The cosine similarity score is the sum of the object elements of the two clauses.

[0057] The second layer involves full-text semantic weighting calculation. Based on the fine-tuned BERT model, semantic vectors of the entire clause text are generated. Combined with a compliance terminology dictionary, higher attention weights are assigned to core compliance terms and conflict-triggered words in the text, while the weight of general non-core words is weakened. The similarity between the semantic vectors of two clauses is calculated using cosine similarity to obtain the semantic similarity score of the entire clause text. Finally, the structured element similarity score and the full-text semantic similarity score are weighted and fused according to a preset weight ratio of 6:4 to output the final comprehensive semantic similarity score of the two clauses. The formula is:

[0058] The semantic similarity score ranges from 0 to 1. A lower score indicates stronger semantic mutual exclusion between the two clauses, and a higher probability of conflict. The preset similarity threshold is 0.6. When the semantic similarity score is below 0.6, the clause pair is deemed to be potentially conflicting. Simultaneously, the clause pair with the suspected conflict is logically verified using a clause logic relation library, excluding clause pairs that meet the exception rules, thus filtering out the final clause pairs with the suspected conflict. The threshold can be customized based on business scenarios to adapt to different levels of control.

[0059] Clauses suspected of conflict are marked with conflict type and divided into two fixed types: direct conflict and indirect conflict. Direct conflict refers to a clear semantic mutual exclusion or logical contradiction between two clauses, which can be determined directly without the need for additional rules. This includes mutual exclusion of rights and responsibilities, contradiction of time points, mutual exclusion of implementation standards, and opposite behavioral requirements. For directly conflicting clauses, the core mutual exclusion points of the conflict are marked simultaneously. Indirect conflict refers to a situation where there is no direct literal contradiction between two clauses, but there are potential compliance risks when combined with the logical rules of the compliance field. This includes conflicts of standard levels, mismatch of the scope of rights and responsibilities, and gaps in the connection of time limits. For indirectly conflicting clauses, the logical rules on which the conflict determination is based are marked simultaneously to provide a basis for subsequent result verification.

[0060] To generate standardized conflict clause pairs, bind the full attribute information of the corresponding triplet data to the completed clause pairs; The bound full attribute information includes the globally unique document identifier ID, version number, on-chain timestamp, hash verification value, clause category label, and clause unique identifier ID of the document to which the clause belongs. At the same time, it binds the semantic similarity comprehensive score of the clause pair, conflict type, core conflict point, and judgment basis information. The generated standardized conflict clauses encapsulate the data with a fixed structure to ensure data consistency and parsability.

[0061] For the final output of conflict detection results, a multi-dimensional visualization is achieved. First, the original text is highlighted. In the original text of the document to be detected, the clauses with conflicts are highlighted differently. Different colors are used to distinguish between direct and indirect conflicts. The core points of the conflict and the conflict level are marked at the same time. The conflict level is divided into three levels: high, medium and low, based on the degree of impact of the conflict on the business.

[0062] High-level conflicts are core clause conflicts that directly affect contract performance and project execution; medium-level conflicts are clause conflicts that pose compliance risks and may lead to performance disputes; and low-level conflicts are clause conflicts with differences in wording but no substantial compliance risks. Secondly, conflict clause comparison displays a table clearly showing the original content, document, version, conflict type, conflict level, and judgment basis of each conflict clause, supporting one-click access and comparison of the original clause text. Thirdly, source information is displayed synchronously, showing the on-chain hash value, on-chain time, and version source chain of the document corresponding to the conflict clause, supporting one-click document authenticity verification. Fourthly, conflict risk statistics are displayed, generating conflict risk statistics reports showing the total number of documents detected, the total number of clauses detected, the total number of conflicts identified, and the distribution of different conflict types and levels, providing data support for enterprise compliance management.

[0063] S4. Generate hash values ​​for the conflict clause data and the on-chain traceability information of the corresponding clause's document, and upload them to the blockchain to complete the notarization.

[0064] The specific process for matching and verifying the conflict clauses with the on-chain traceability information of the corresponding clause's document is as follows: Extract the globally unique document identifier ID and version number information bound to the conflict clauses within the data, and match and retrieve the full on-chain traceability information of the corresponding document on the blockchain. The full on-chain traceability information includes the full text hash value of the document, the hash value of the core compliant paragraph set, the entity that performed the on-chain operation, the on-chain timestamp, historical version records, and related business information, ensuring that the retrieved traceability information completely covers the entire lifecycle operation records of the document.

[0065] The retrieved on-chain traceability information and the hash verification value of the conflict clauses are used to perform consistency verification to confirm the integrity and authenticity of the documents corresponding to the conflict clauses. During the consistency verification process, the hash value of the core compliance paragraph of the corresponding document is recalculated and compared with the hash value of the core compliance paragraph set stored on the chain. If the comparison is successful, it is confirmed that the core detection content of the document has not been tampered with and the document is authentic and complete. If the comparison fails, it is determined that the document content is abnormal, the on-chain process is terminated and an abnormal alarm is triggered to ensure that the data source corresponding to the detection result is authentic and trustworthy.

[0066] Extract the operation logs, judgment criteria, and algorithm model version information of the entire conflict detection process, and perform consistency verification with the hash value of the rule model fixed on the chain to confirm the compliance of the detection process; The operation log includes the initiating entity of the detection task, the initiation time, the detection scope settings, and the comparison process record. The judgment criteria include the logical rules used for conflict judgment, the similarity threshold, and the terminology dictionary version. The algorithm model version information includes the version number of the semantic similarity calculation model and the model hash value. After integrating the above content, the hash value is calculated and compared with the hash value of the rule model fixed on the chain. If the comparison is successful, it is confirmed that the detection process strictly follows the rules and models fixed on the chain and has not been tampered with. If the comparison fails, the detection process is determined to be non-compliant, the on-chain process is terminated, and an abnormal alarm is triggered to ensure that the detection process is controllable and compliant throughout.

[0067] For the conflict clauses that have passed the verification, the data, on-chain traceability information, and detection process information are integrated to generate a full conflict detection dataset to be uploaded to the chain. The full conflict detection dataset also includes the full text of the conflict detection report, conflict risk statistics, and index information related to visualization. The dataset is encrypted and stored in an off-chain encrypted distributed storage system, generating a corresponding unique storage address to ensure the storage security and immutability of the dataset.

[0068] In step S4, the specific process of generating a hash value and uploading it to the blockchain to complete the notarization is as follows: The SM3 cryptographic hash algorithm (a national standard) is used to generate unique and immutable hash values ​​for the full collision detection dataset to be uploaded to the blockchain; the content sequence of the full collision detection dataset is as follows: Its unique hash value The formula for generating it is:

[0069] It is a unique, immutable hash value for the entire collision detection dataset, used to verify the integrity and tamper-proof status of the detection results. This is a byte stream of the complete content of the full dataset for conflict detection.

[0070] The hash value, dataset metadata, off-chain storage address, operator information, and timestamp corresponding to the full conflict detection dataset are used to generate a data on-chain proposal, which is then broadcast to all consensus nodes of the consortium blockchain. The dataset metadata includes the detection task number, the scope of the detection documents, the total number of conflict clauses, and the detection completion time. The operator information must be verified by digital signature to ensure that the initiator of the on-chain proposal is legitimate and compliant.

[0071] All consensus nodes perform consistency verification and voting on the received on-chain proposals, and complete the block confirmation through the PBFT consensus mechanism. The consistency verification includes verification of the integrity of the proposal content, verification of the legality of the hash value, verification of the operator's authority, and verification of the compliance of the detection process. Nodes that pass the verification participate in the voting. Only when more than two-thirds of the consensus nodes vote in favor can the block confirmation process be completed, ensuring the consistency and legality of the on-chain detection results data across all nodes.

[0072] Once the block is confirmed, the hash value, metadata, off-chain storage address, and consensus verification information of the full dataset of conflict detection are written into the consortium blockchain block to complete on-chain notarization. During the block writing process, the hash value of the preceding block is recorded synchronously to form a chain association with existing blocks, ensuring that the detection result data cannot be tampered with. The data within the block is indexed according to the detection task number, supporting quick retrieval of the corresponding detection result information by detection task number and document identifier ID.

[0073] A strong correlation mapping is established between the conflict detection data stored on the blockchain and the corresponding document evidence data, completing the construction of a trustworthy closed loop with full traceability. The strong correlation mapping is established through document identifier ID, project number, and business scenario identifier. It supports one-click backtracking of all corresponding conflict detection records through document evidence data, and also supports one-click backtracking of the full evidence information and version chain of the corresponding document through conflict detection data. This achieves full traceability and immutability from document on-chain, clause extraction, conflict detection, and result evidence storage, forming a complete trustworthy closed loop. The detection results can be verified with one click and can be directly used as a trustworthy evidence for compliance management and business dispute resolution.

[0074] This invention uses the national cryptographic SM3 algorithm to generate a dual hash value for each business document to be tested, consisting of the full text and a set of core compliant paragraphs. The business document data and the hash value of the detection rule model are synchronously stored on the blockchain through the consortium blockchain PBFT consensus mechanism. This ensures that the data is tamper-proof from two core dimensions: the detection data source and the judgment rules. At the same time, it establishes a full-version on-chain traceability management system for the document, completely solving the problem of insufficient credibility of the basic detection data in traditional detection solutions.

[0075] By leveraging the BiLSTM-CRF sequence labeling model to optimize the boundaries of compliance clauses, combining it with a pre-tuned BERT model to achieve standardized clause classification, and then using dependency parsing to break down clauses into standardized triplet data of subject-verb-object, and binding on-chain document identifiers, version numbers and other traceability attributes throughout the process, unstructured compliance texts are transformed into structured data that can be directly calculated and compared, which greatly improves the efficiency and accuracy of cross-document clause comparison.

[0076] We construct a dedicated domain knowledge base covering a compliance terminology dictionary and a clause logic relationship library. Using the Chinese BERT-base model as the foundation, we complete the pre-training and supervised fine-tuning of the compliance domain. We adopt a similarity calculation method that combines structured triple weighting and full-text semantic weighting to accurately identify direct and indirect implicit conflicts in compliance scenarios, breaking through the limitations of traditional natural language processing solutions in identifying implicit compliance conflicts.

[0077] After verifying the hash consistency of conflict clause data and on-chain document traceability information, the full set of detection data is integrated to generate hash values ​​for on-chain storage. A strong correlation mapping is established between conflict detection data and original document storage data, constructing a fully traceable and trustworthy closed loop from document on-chain, clause extraction, conflict detection, and result storage. The detection results can be directly used as credible evidence for compliance management and dispute resolution.

[0078] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention. The scope of protection claimed by the appended claims and their equivalents is defined.

Claims

1. A blockchain-based method for detecting cross-document compliance risk conflicts, characterized in that, Includes the following steps: S1. Standardize and preprocess several business documents to be tested, generate document hash values ​​and upload them to the blockchain for evidence storage, synchronize the rule model hash value containing the testing rules to the blockchain for solidification, and obtain on-chain evidence document data. S2. Extract compliance clauses from on-chain evidence document data, and generate standardized compliance clause triplet data through boundary identification, type classification and structure transformation; S3. Based on standardized compliance clause triplet data and detection rules, an improved BERT semantic similarity algorithm that integrates a compliance domain knowledge base is used to compare similar clauses between different documents, identify and generate conflict clause pairs. S4. Generate hash values ​​for the conflict clause data and the on-chain traceability information of the corresponding clause's document, and upload them to the blockchain to complete the notarization.

2. The blockchain-based cross-document compliance risk conflict detection method according to claim 1, characterized in that, In step S1, the standardization preprocessing to generate document hash values ​​and uploading them to the blockchain for evidence storage specifically involves: For business documents to be tested in editable formats, the full text content is extracted using a format parsing tool, preserving the original paragraph hierarchy, punctuation marks, and heading structure information; For non-editable scanned documents and image-based business documents to be inspected, the text content is extracted using OCR optical character recognition technology to complete recognition error correction, layout restoration, and garbled character filtering; All text content extracted from the business documents to be tested is uniformly converted into plain text format with UTF-8 encoding; For the standardized plain text, document metadata information is extracted by matching regular expression rules, and core compliant text paragraphs are defined by a preset compliance keyword library; Filter out redundant content without compliance attributes in plain text to complete the initial screening of the core content to be detected in the document; The national standard SM3 cryptographic hash algorithm is used to generate a unique full-text hash value and a set hash value of core compliant paragraphs for each business document to be tested.

3. The blockchain-based cross-document compliance risk conflict detection method according to claim 1, characterized in that, In step S1, obtaining the on-chain evidence document data specifically involves: The full text content and core compliance paragraphs of the business document to be tested are stored off-chain in an encrypted distributed manner to obtain the corresponding unique storage address; for the business scenario of the business document to be tested, the corresponding compliance clause extraction rules, semantic similarity calculation model, and conflict determination rules are pre-configured. For the pre-configured rules and complete model content, the national cryptographic SM3 hash algorithm is used to generate the corresponding unique hash value of the rule model; Integrate the full-text hash value, core compliance paragraph set hash value, document metadata, unique storage address, on-chain operation entity information, and on-chain timestamp of each business document to be tested to generate a standardized document on-chain dataset; Integrate the unique hash value of the rule model, the version number of the rule model, the effective time of the rule model, and the corresponding business scenario information to generate a standardized rule model on-chain dataset; The document on-chain dataset and the rule model on-chain dataset are simultaneously sent to each node of the consortium blockchain, and the multi-node data consistency verification and block consensus confirmation are completed through the PBFT consensus mechanism. Write the document dataset and rule model dataset that have completed consensus confirmation to a new block on the consortium blockchain to complete the on-chain notarization of document data and the on-chain solidification of rule model hash values; Based on the block height, block hash, and unique document identifier of the new block, globally unique on-chain evidence document data is generated for each business document to be tested.

4. The blockchain-based cross-document compliance risk conflict detection method according to claim 1, characterized in that, In S2, the compliance clause extraction operation is only performed on on-chain evidence document data that has passed the consensus verification of the consortium blockchain and whose hash value verification is complete. At the same time, the globally unique document identifier ID, version number, on-chain timestamp, and hash verification value corresponding to the on-chain evidence document data are used as fixed binding attributes of the extracted compliance clauses.

5. The blockchain-based cross-document compliance risk conflict detection method according to claim 1, characterized in that, In S2, generating compliance clauses through boundary identification and type classification specifically involves: Using Chinese periods, semicolons, and paragraph line breaks as basic dividing units, and combining them with a compliance-related keyword library, the candidate boundaries of a single clause are defined, generating a clause candidate set. The BiLSTM-CRF sequence labeling model is used to optimize the boundary of the candidate clause set, correct the boundary recognition error of long sentence nesting and cross-paragraph compound clauses, and output a single clause set with complete and independent semantics. Establish a standardized classification system for compliance clauses, setting three fixed classification dimensions: rights and obligations clauses, standard constraint clauses, and time-limited clauses. Based on a pre-tuned Chinese BERT-base text classification model, all clauses within a single clause set are classified and labeled, outputting a set of compliant clauses with fixed classification labels.

6. The blockchain-based cross-document compliance risk conflict detection method according to claim 1, characterized in that, In S2, the standardized compliance clause triplet data is generated through structured transformation as follows: Dependency parsing technique is used to perform semantic parsing on each clause in a set of compliant clauses with fixed classification labels, and to extract the core semantic elements corresponding to the clauses. Following the fixed triplet format of subject-verb-object, the extracted core semantic elements are structurally encapsulated. The subject corresponds to the responsible party or the right holder of the clause, the verb corresponds to the core behavior or constraint requirement of the clause, and the object corresponds to the implementation object or scope of constraint of the core behavior. Bind the encapsulated triple data with the corresponding clause's category tag, globally unique document identifier ID, version number, on-chain timestamp, and hash check value attributes; Perform format consistency checks on all triplet data after binding attributes, remove invalid data that does not conform to the format specifications, and output standardized and compliant clause triplet data.

7. The blockchain-based cross-document compliance risk conflict detection method according to claim 1, characterized in that, In S3, the pre-construction process of the improved BERT semantic similarity algorithm, which integrates a compliance domain knowledge base, is as follows: For three fixed target scenarios—contracts, bidding, and technical specifications—a dedicated knowledge base for compliance is built. The knowledge base consists of two fixed modules: a compliance terminology dictionary and a clause logic relationship database. The compliance terminology dictionary includes specific compliance terms, legal and regulatory terms, industry standard numbers, and rights and responsibilities-specific terms for the target scenario, and marks the standard definition, synonyms, antonyms, hypernyms, and mutually exclusive terms for each term; The clause logic relationship library organizes fixed compliance conflict determination logic rules, including mutual exclusion rules for permissive and prohibitive clauses, standard level priority rules, correspondence rules for rights and obligations, and logical rules for the sequence of time nodes; Based on the open-source Chinese BERT-base pre-trained model, we use domain-specific corpora for further pre-training to complete the basic domain adaptation of the model. Based on a manually annotated dataset of compliance clause conflicts, the model that has completed further pre-training is subjected to task-supervised fine-tuning to optimize the semantic encoding layer and output layer of the model, thus completing the construction of an improved BERT semantic similarity algorithm.

8. The blockchain-based cross-document compliance risk conflict detection method according to claim 1, characterized in that, In step S3, comparing similar clauses across different documents to identify and generate conflict clause pairs specifically involves: Set up two fixed document pair selection modes: automatic association matching and manual specification, to complete the selection of document pairs and generate the detection task. Based on the classification tags of the standardized compliance clause triplet data, only clauses with the same classification tag within a document pair are matched pairwise to generate a set of clause pairs to be compared. For each pair of clauses to be compared, a comprehensive semantic similarity score is calculated using the improved BERT semantic similarity algorithm. Logical verification is then performed in conjunction with the clause logical relationship database to filter out clause pairs that are suspected of conflict. Clauses suspected of conflict are marked with conflict type and divided into two fixed types: direct conflict and indirect conflict. To generate standardized conflict clause pairs, bind the complete attribute information of the corresponding triplet data to the completed clause pairs.

9. A blockchain-based cross-document compliance risk conflict detection method according to claim 1, characterized in that, The specific process for matching and verifying the conflict clauses with the on-chain traceability information of the corresponding clause's document is as follows: Extract the globally unique document identifier ID and version number information bound to the conflict clause within the data, and match and retrieve the full on-chain traceability information of the corresponding document on the blockchain; The retrieved on-chain traceability information and the hash verification value of the conflict clause are checked for consistency to confirm the integrity and authenticity of the document corresponding to the conflict clause. Extract the operation logs, judgment criteria, and algorithm model version information of the entire conflict detection process, and perform consistency verification with the hash value of the rule model fixed on the chain to confirm the compliance of the detection process; For the conflict clauses that pass verification, integrate the data, on-chain traceability information, and detection process information to generate a full dataset of conflict detection to be uploaded to the chain.

10. A blockchain-based cross-document compliance risk conflict detection method according to claim 1, characterized in that, In step S4, the specific process of generating a hash value and uploading it to the blockchain to complete the notarization is as follows: The national cryptographic SM3 hash algorithm is used to generate unique and immutable hash values ​​for the full dataset of collision detection to be uploaded to the blockchain; The hash value, dataset metadata, off-chain storage address, operation entity information, and timestamp corresponding to the full conflict detection dataset are used to generate a data on-chain proposal, which is then broadcast to all consensus nodes of the consortium blockchain. All consensus nodes perform consistency verification and voting on the received on-chain proposals, and complete block confirmation through the PBFT consensus mechanism; Once the block is confirmed, the hash value, metadata, off-chain storage address, and consensus verification information of the full dataset of conflict detection will be written into the consortium blockchain block to complete the on-chain notarization. Establish a strong correlation mapping between conflict detection data stored on the blockchain and corresponding document storage data to complete the construction of a trustworthy closed loop with full-chain traceability.

Images