A digital contract semantic mapping and strategy conflict resolution method across trusted data spaces

Abstract

The application discloses a kind of digital contract semantic mapping and strategy conflict resolution across trusted data space, it is related to trusted data space interconnection and data element circulation technical field.The method receives the data circulation request initiated by source trusted data space to target trusted data space, obtains source digital contract, source space model description file and target space model description file;Source digital contract is parsed into source contract constraint graph, and identity model, directory model, use classification, authority action, running environment, audit log and execution capability list are extracted;Based on semantic ontology and field dictionary, generate target constraint mapping candidate, and calculate semantic coverage, execution reachability and risk difference;According to three-dimensional check result, identify constraint missing, authority expansion, semantic ambiguity, insufficient execution capability and audit evidence inconsistency etc.Conflict;Through tightening mapping, compensation control, artificial review or mutual recognition rejection, generate target space executable policy package, and write into cross-space audit record.The application can convert digital contract from text mutual recognition to executable policy mutual recognition, reduce cross-space over-authorization use and audit evidence missing risk.

Description

Technical Field

[0001] This invention relates to the fields of data element circulation, trusted data space, digital contracts, usage control, cross-domain identity mutual recognition, data security auditing, and policy engine technology, and in particular to a method, system, electronic device, and computer-readable storage medium for semantic mapping of digital contracts, verification of execution capabilities, and resolution of policy conflicts between different trusted data spaces. Background Technology

[0002] Trusted data spaces are typically based on digital identities, data catalogs, digital contracts, usage controls, connectors, privacy computing, data sandboxes, and audit evidence storage to enable cross-entity data flow and controlled use. As different regions, industries, and enterprises build their own trusted data spaces, cross-space interconnectivity has become a key issue in the flow of data elements.

[0003] Existing technologies include solutions that can attach digital contracts to data resources within a single trusted data space, or manage authorization for data users through blockchain, access control, and trusted execution environments. These solutions primarily address data access control issues within the same platform, strategy model, and connector capability system.

[0004] However, different trusted data spaces often have inconsistencies in identity systems, directory fields, usage classifications, permission actions, environmental constraints, log formats, and execution capabilities. For example, a source space's "research modeling only, no export of details, log retention for three years" might correspond to multiple different usage codes, computational task types, export control rules, and audit fields in the target space; the target space may also lack watermarking, sandboxing, usage limits, or log signing capabilities.

[0005] If only the source digital contract text is copied to the target space, the target space cannot guarantee that its strategy engine will execute correctly; if the mapping relationship is configured manually, it is difficult to detect risks such as expanded scope of permissions, missing constraints, semantic ambiguity, and inconsistent audit evidence. These problems can lead to technical defects in cross-space mutual recognition, such as unauthorized use, invalid contract constraints, and incomplete evidence chains after disputes occur.

[0006] Therefore, there is a need for an underlying platform technology for interconnection and interoperability across trusted data spaces, which can convert source space digital contracts into policy packages that can be executed by the target space, and automatically identify and resolve semantic, capability and risk conflicts during the conversion process, thus distinguishing it from existing single-space contract attachment and access control schemes. Summary of the Invention

[0007] I. Technical problems to be solved The technical problem this invention aims to solve is that when data flows between different trusted data spaces, constraints such as the subject, data object, purpose, action, time, region, operating environment, output control, and audit evidence in digital contracts are difficult to directly map to the target space; insufficient execution capabilities of the target space or different policy semantics can lead to expanded permissions, missing constraints, and inconsistent audit evidence; manually configuring mapping relationships is inefficient and makes it difficult to form a verifiable chain of technical evidence.

[0008] II. Technical Solution To address the aforementioned technical problems, this invention provides a method for semantic mapping and policy conflict resolution of digital contracts across trusted data spaces. This method does not simply replace fields in the source digital contract; instead, it abstracts the source digital contract into a heterogeneous constraint graph and the target trusted data space into a target space capability semantic graph. Semantic matching, structural matching, capability matching, audit matching, and risk constraint optimization are then performed between the two graphs. Through this process, usage control requirements expressed in contract terms, policy fields, or natural language in the source space are transformed into target policy packages that can be actually executed by the target space connector, policy engine, data sandbox, privacy computing engine, API gateway, output review module, and audit module.

[0009] Specifically, the system first receives a cross-space data flow request and obtains the source digital contract, the source space model description file, and the target space model description file. The source space model description file describes the expression of digital identities, data directories, usage categories, permission actions, spatiotemporal constraints, output constraints, and audit evidence in the source space; the target space model description file describes the identifiable subjects, objects, uses, actions, environment, outputs, log fields, and executable capabilities of the target space. All of the above model description files undergo integrity verification through space signatures; if verification fails, the mapping process is not initiated.

[0010] Subsequently, the system performs standardized parsing of the source digital contract, converting structured strategies, smart contract events, XML / JSON strategy terms, and natural language contract terms into unified atomic constraint objects. Each atomic constraint object includes at least a constraint category, constraint value domain, comparison operator, granularity level, mandatory identifier, risk level, evidence field, triggering condition, effective window, failure condition, and obligatory action. The system further constructs a heterogeneous constraint graph Gs of the source contract based on the relationships of inclusion, dependency, exclusion, sequence, joint effectiveness, condition triggering, obligation assumption, and evidence support among the atomic constraints.

[0011] Simultaneously, the system constructs a target space capability semantic graph Gt based on the target space model description file. This graph not only includes policy fields for the target space but also technical capability nodes capable of executing those policies, such as connector access control nodes, API gateway usage limit nodes, data sandbox isolation nodes, trusted execution environment nodes, privacy computing task nodes, output review nodes, watermark embedding nodes, log signing nodes, and evidence retention nodes. Edges in the target space capability semantic graph represent semantic hierarchical relationships, field mappings, capability carrying, policy execution, and evidence generation.

[0012] After the graph is constructed, the system performs vectorization encoding on both the source constraint nodes and the target nodes. Source constraint nodes generate constraint semantic vectors, structural context vectors, risk level vectors, and evidence requirement vectors; target nodes generate target semantic vectors, capacity carrying capacity vectors, log evidence vectors, and compensation control vectors. The system generates a candidate set of target constraint mappings based on vector similarity, classification path similarity, value range inclusion relationship, granularity matching relationship, graph neighborhood consistency, and historical mapping weights.

[0013] To avoid reducing cross-space mutual recognition to simple field mapping, the system introduces a unified constraint tensor and a target capability tensor during the candidate generation phase. The unified constraint tensor records dimensions such as the subject set, object set, action set, purpose path, spatiotemporal window, environment level, output granularity, audit fields, and obligatory actions. The target capability tensor records the strategy expression capability, execution capacity, compensation control capability, audit generation capability, and rollback capability of the target space. Both are encoded in the same feature space through semantic ontology encoding, classification path encoding, value range normalization encoding, and graph structure encoding, enabling contract terms to be transformed into computable matching, constraint, and optimization problems.

[0014] In the underlying platform implementation, the system denotes the candidate target set for each source constraint node i as Mi, and the optional compensation control set for the target space as C. Candidate target nodes express the native strategy of the target space, while compensation control nodes express equivalent or stricter controls achieved through additional technical measures such as sandboxing, privacy computation, export blocking, output aggregation, watermarking, log extension, and manual approval. The system does not directly use the highest semantic similarity as the final mapping result, but instead solves for the globally minimum conflict cost among all candidate nodes and compensation nodes to ensure that the exclusion, dependency, co-operation, and audit support relationships between different constraints are not disrupted.

[0015] For each candidate mapping, the system calculates semantic coverage (SC), graph structure consistency (GC), execution reachability (ER), audit completeness (AC), and risk increment (RD). Then, a conflict cost function J is established, with constraints including no permission expansion, no loss of mandatory constraints, generation of audit evidence, risk increment not exceeding a threshold, and no simultaneous release of exclusionary constraints. This function is used to perform combinatorial optimization on the candidate mappings to obtain the optimal combination of mappings in the target space. This combinatorial optimization can be implemented using branch and bound, dynamic programming, integer programming, or heuristic graph matching methods.

[0016] The solution process for the combinatorial optimization includes two stages: hard constraint elimination and soft cost ranking. Hard constraint elimination removes candidates with expanded subject scope, expanded action scope, higher-level purpose, finer output granularity, or missing and irreparable audit fields. Soft cost ranking selects combinations with higher semantic coverage, lower execution cost, smaller risk increment, and more complete evidence chain among multiple feasible candidates. For cases where the same source constraint is covered by multiple target capabilities, the system generates a combinatorial mapping hyperedge and calculates the combinatorial coverage, combinatorial execution order, and combinatorial audit verifiability for this hyperedge, avoiding the superposition of multiple weak control terms with insufficient actual control strength.

[0017] When unmet constraints exist in the optimal mapping combination, the system identifies constraint missing conflicts, granularity mismatch conflicts, permission expansion conflicts, semantic ambiguity conflicts, insufficient execution capability conflicts, inconsistent audit evidence conflicts, and constraint propagation conflicts based on the type of unmet item. For permission expansion conflicts, the system performs tightening mapping; for granularity mismatch conflicts, it performs constraint splitting or result aggregation; for insufficient execution capability conflicts, it selects the minimum compensation control set; for inconsistent audit evidence conflicts, it adds log fields, signature digests, and retention requirements; for semantic ambiguity conflicts, it generates tasks to be reviewed; and for uncompensated constraint missing conflicts, it generates a mutual recognition rejection record.

[0018] After conflict resolution is completed, the system generates a target policy package. The target policy package includes at least a target space policy identifier, policy version, subject mapping table, object mapping table, purpose mapping table, action control rules, environment execution rules, output control rules, audit log rules, compensation control instructions, rollback policy, signature summary, and validity period. Before the target policy package is issued, the system automatically generates compliance and default samples based on the source contract constraint diagram to simulate and verify the target policy package. Only after successful verification is the target space connector allowed to load the policy package; otherwise, verification fails, and the system either reverts to the conflict resolution step or terminates mutual recognition.

[0019] Strategy simulation verification goes beyond simply checking whether the strategy file can be parsed. It generates positive compliance samples and negative default samples based on the source contract constraint diagram. Positive samples cover legitimate entities, legitimate uses, valid time periods, compliant regions, and permitted outputs. Negative samples cover unauthorized entities, out-of-bounds uses, expired time periods, out-of-bounds regions, exported details, operation outside the sandbox, missing log fields, and invalid signatures. The system inputs these samples into the strategy engine or simulation strategy engine corresponding to the target strategy package, calculating the pass rate, reverse interception rate, evidence field generation rate, and rollback success rate, which serve as components of mutual recognition reliability.

[0020] The method can be deployed in trusted data space interconnection service platforms, cross-space connectors, data trading platforms, public data authorization operation platforms, or data element circulation supervision platforms. Its inputs include source digital contracts, spatial model description files, semantic ontology, field dictionaries, classification trees, historical mapping libraries, risk weight tables, and strategy execution capability lists; its outputs include target strategy packages, mapping matrices, conflict cost function values, conflict resolution records, compensation control sets, strategy simulation verification results, strategy drift monitoring results, and cross-space audit evidence chains.

[0021] III. Beneficial Effects 1. This invention transforms the mutual recognition of digital contracts from the text level to the mutual recognition at the executable strategy level. The target space only generates a strategy package when the conditions of semantic coverage, execution reachability, and risk control are met, thus avoiding the problem of cross-space contract copying failing to execute.

[0022] 2. This invention can automatically detect conflicts such as expanded permissions, missing constraints, semantic ambiguity, insufficient execution capabilities, and inconsistent audit evidence, and generate handling actions such as tightening mapping, mandatory sandboxing, calculation without export, watermarking, manual approval, or refusal to recognize for different conflict types, thereby reducing the risk of unauthorized use.

[0023] 3. This invention establishes an evidence chain consisting of mapping version, policy version, conflict record, simulation test and audit hash, making the policy conversion process in cross-space data circulation traceable, verifiable and supervised.

[0024] 4. This invention is applicable not only to the authorized operation of public data and the interconnection of industry data spaces, but also to the mutual recognition of contracts for multi-domain data circulation within enterprise groups, cross-regional data transactions, and multi-party privacy computing tasks.

[0025] IV. Core Algorithm and Scoring Model This invention employs a multi-indicator joint scoring model encompassing semantic coverage, structural consistency, execution reachability, audit completeness, and risk increment. Unlike methods that only compare field names or strategy text similarity, this invention simultaneously considers the graph relationships between constraints in the source digital contract, the actual execution capability of the target space, whether evidence can be formed after strategy execution, and whether the target mapping expands the risk boundary.

[0026] In the above formula, Cos represents the vector cosine similarity; PathSim represents the similarity between paths of purpose, action, or directory classification; RangeCover represents the coverage relationship between the target constraint domain and the source constraint domain, and when the target domain is strictly larger than the source domain, a permission expansion penalty is added; GranMatch represents the granularity matching function, used to determine whether the target space can maintain the field-level, record-level, dataset-level, task-level, or result-level control granularity required by the source contract; eta is used to constrain the inclusion, dependency, exclusion, and co-operation equilateral relationships in the source and target graphs to be semantically compatible.

[0027] In actual calculations, the system first generates a set of candidate target nodes Mi for each source constraint node i, and calculates Scoreij for each target candidate node j in Mi. Then, using xij as a binary decision variable, it solves for the minimum value of the conflict cost function J. The following hard constraints must be satisfied during the solution process: First, mandatory constraints in the source digital contract must be covered by the target's native capabilities or compensation controls; second, the target's mapped subject, object, action, purpose, time, region, and output range must not be wider than the source contract; third, two source constraints with exclusive edges cannot be mapped to the same permitted action in the target space; fourth, audit completeness must not be lower than the audit threshold; fifth, risk increment must not exceed the risk threshold.

[0028] The minimum compensation set C* is used to handle situations where the native capabilities of the target space are insufficient. The system first calculates the set of uncovered mandatory constraints U, then selects the control combination from the candidate compensation control set that covers U and minimizes the increase in overall risk, operational overhead, latency, and audit fields. If C* still cannot ensure that ER, AC, and RD simultaneously meet the thresholds, the system does not generate a target policy package but instead outputs a rejection record for mutual recognition or a manual review task. This process makes compensation control a computable technical choice, rather than a manually configured option based on experience.

[0029] To ensure the policy conversion is executable, the system performs positive and negative sample simulations after the target policy package is generated. Positive samples verify that requests from compliant entities, for compliant purposes, and under compliant environments can be approved. Negative samples verify that requests from unauthorized entities, for unauthorized purposes, timeouts, out-of-bounds access, exceeding the allowed number of calls, exporting detailed information, running outside the sandbox, missing logs, and invalid signatures can be rejected, downgraded, or transferred to manual approval. The simulation pass rate, reverse interception rate, evidence field generation rate, and rollback success rate together form the mutual recognition trust map.

[0030] When the target space model version, connector version, usage classification tree, log fields, or execution capabilities change, the system uses the policy drift value (Drift) to re-evaluate the effective policy package. If the drift exceeds a threshold, the system automatically pauses the policy package, reduces the scope of executable actions, triggers remapping, or generates a task awaiting manual review, thereby preventing the source contract constraints from silently failing due to target space upgrades.

[0031] V. Key Data Structures VI. Types of Conflict and Resolving Actions Instruction manual illustrations Figure 1 This is a flowchart illustrating the overall process of semantic mapping and conflict resolution of digital contracts across trusted data spaces in this invention.

[0032] Figure 2 This is a diagram illustrating the source space and target space model mapping architecture of this invention.

[0033] Figure 3 This is a flowchart illustrating the three-dimensional verification process for semantic coverage, execution reachability, and risk differences in this invention.

[0034] Figure 4 This is a schematic diagram of the conflict resolution state machine and compensation control strategy of the present invention. Detailed Implementation

[0035] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings. The following embodiments use the sharing of public transportation data products between two trusted data spaces as an example, where the source space is a trusted data space for urban public data, and the target space is a trusted data space for industry applications. The field names, thresholds, risk weights, and execution capability items in the embodiments can be configured according to actual space specifications; the present invention is not limited to this example.

[0036] Example 1: System Deployment and Initialization The system in this embodiment is deployed in a cross-space interconnection service platform, and connects to the source space connector, target space connector, data catalog service, digital contract service, policy engine, data sandbox, privacy computing engine, and audit and evidence storage service. The system includes a request receiving module, a contract parsing module, a spatial model acquisition module, a constraint graph generation module, a mapping candidate generation module, a 3D verification module, a conflict identification module, a conflict resolution module, a policy package generation module, an executability simulation module, and an audit and evidence storage module.

[0037] During initialization, the system loads a semantic ontology library, a data directory field dictionary, a purpose classification mapping table, a permission action mapping table, an environment constraint template, an audit field template, a risk weight table, and a historical mapping library. The semantic ontology library at least stores the synonym, superordinate, subordinate, inclusion, and mutual exclusion relationships between concepts related to subjects, data resources, purposes, actions, outputs, environments, and audits. For example, scientific research modeling in the source space can have a superordinate relationship with model training and statistical analysis in the target space; the prohibition of exporting details in the source space can be mapped to the prohibition of downloading original records and the result output aggregation threshold in the target space.

[0038] Example 2: Receiving Cross-Space Data Flow Requests When a user of the target space requests to use data products from the source space, the request receiving module obtains a data flow request. This request includes the source space identifier, target space identifier, data directory identifier, user identity, purpose of request, expected action, operating environment, output format, contract number, and request time. The system simultaneously retrieves the source digital contract and source space model description file from the source space, and the target space model description file from the target space.

[0039] The source digital contract can be a structured policy file, JSON policy, XML policy, natural language contract terms, or a hybrid format. Both the source and target space model description files contain connector version, identity model, directory model, usage category, permission actions, environment constraints, audit log fields, signature algorithm, and policy execution capability items. If the target space model description file is missing or signature verification fails, the system will not perform mapping and will directly generate a mutual recognition failure record.

[0040] Example 3: Normalization and Constraint Graph Generation of Digital Contracts The contract parsing module parses the source digital contract into a unified constraint object. For structured policies, the system directly reads the subject, object, action, purpose, term, region, and output rules; for natural language clauses, the system first extracts constraint items through a terminology dictionary and rule templates, and then uses manually configurable validation rules to confirm field boundaries. Each unified constraint object includes a constraint identifier, constraint type, constraint value, whether it is mandatory, risk level, evidence field, and effective conditions.

[0041] The constraint graph generation module constructs a source contract constraint graph based on a unified constraint object. Constraint nodes include subject constraints, object constraints, action constraints, usage constraints, time constraints, geographical constraints, environmental constraints, output constraints, audit constraints, and obligation constraints. Constraint edges include inclusion, exclusion, dependency, sequence, and co-effectiveness relationships. For example, there is an exclusion relationship between "for research modeling only" and "not for commercial marketing," and a co-effectiveness relationship between "not allowing detailed output" and "output results must be aggregated into at least 50 records."

[0042] Example 4: Spatial Model Acquisition and Execution Capability Identification The spatial model acquisition module reads the identity model, data directory model, usage classification model, permission action model, runtime environment model, audit log model, and execution capability list of the source and target spaces. The identity model is used to determine whether subjects can recognize each other and whether roles are equivalent; the data directory model is used to determine whether fields, datasets, spatial ranges, and quality levels are consistent; the usage classification model is used to determine whether there are synonyms, hierarchical relationships, or superordinate relationships between usage codes; and the permission action model is used to determine whether actions such as reading, calculating, training, exporting, and forwarding have the same control granularity.

[0043] The execution capability checklist is used to determine whether the target space can actually execute the restrictions in the source contract. Execution capability items include API gateway usage limits, data sandbox isolation, trusted execution environment, privacy computation tasks, export approval, output aggregation threshold, result watermarking, log signing, log retention, timestamp service, and auditing interface. If the target space cannot natively execute a constraint, the system further determines whether it can be achieved through compensatory controls.

[0044] Example 5: Target Constraint Mapping Candidate Generation The mapping candidate generation module reads the source constraint nodes in the source contract constraint graph one by one and generates target constraint mapping candidates in the target space model. The system prioritizes precise field matching, followed by synonym matching, hierarchical classification matching, unit conversion, rule expression conversion, and historical mapping reuse. For example, the validity period of the source space until 2027-12-31 can be directly converted into a time constraint expression for the target space; the prohibition of downloading original details in the source space can be mapped to the two control items download_raw=false and export_detail=false in the target space.

[0045] For usage constraints, the system compares not only the text but also the positional relationships within the usage category tree. A target usage that is a subcategory of the source usage and does not expand the scope of the source contract can be considered a candidate; when the target usage is a supercategory of the source usage, the system marks it as a potential permission expansion. For environment constraints, the system compares the runtime environment required by the source contract with the available environment in the target space, such as a data sandbox, trusted execution environment, federated learning environment, or ordinary computing environment.

[0046] Example 6: Three-dimensional verification and threshold determination The three-dimensional verification module calculates semantic coverage, execution reachability, and risk difference, respectively. Semantic coverage measures whether the target constraints fully cover the semantic content of the source constraints; execution reachability measures whether the target space can control the mandatory constraints of the source contract through native capabilities or compensation; risk difference measures whether the control strength of the target space after mapping is lower than that of the source space.

[0047] In one example, the system sets the semantic threshold to 0.85, the execution threshold to 0.90, and the risk threshold to 0.10. If a mapping candidate has an SC of 0.93, an ER of 1.00, and a RD of 0.02, it proceeds to policy package generation; if the SC is 0.79, it proceeds to semantic ambiguity or constraint missing judgment; if the ER is 0.70, it indicates that the target space lacks necessary execution capabilities, requiring the generation of compensatory controls; if the RD is 0.35, it indicates a significant increase in risk after mapping, requiring tightening or rejection. These thresholds can be configured according to data security levels and industry standards.

[0048] Example 7: Collision Identification The conflict identification module identifies specific conflicts based on the 3D verification results and constraint graph relationships. If the source constraint node has no semantically equivalent node in the target space and cannot be compensated for, it is identified as a constraint missing conflict. If the allowed data range, subject range, action range, usage range, time range, or output range of the target mapping candidate is larger than the source digital contract, it is identified as a permission expansion conflict. If a source constraint has multiple similar target constraints and the confidence difference is less than a threshold, it is identified as a semantic ambiguity conflict.

[0049] For conflicts related to insufficient execution capabilities, the system checks whether the target space possesses the necessary capabilities. For example, if the source contract requires that the model can only be trained in a data sandbox and that sample-level results cannot be exported, and the target space can only provide regular API access without providing sandboxing and output review, then this is identified as a conflict related to insufficient execution capabilities. For conflicts related to inconsistent audit evidence, the system checks whether the target space logs contain the fields, signatures, timestamps, and retention periods required by the source contract.

[0050] Example 8: Generation of Conflict Resolution and Compensation Control Strategies The conflict resolution module selects the resolution action based on the conflict type. For permission expansion conflicts, the system performs a tightening mapping, restricting the subject, object, action, purpose, time, region, environment, and output scope in the target space policy package to no more than the source digital contract. For example, if the source contract only allows scientific research modeling, and the target space is mapped to scientific research and business analysis, the system automatically tightens it to scientific research modeling or its subcategories.

[0051] For conflicts arising from insufficient execution capabilities, the system generates compensation control policies. These policies may include forcing entry into a data sandbox, read-only access, computation-only access without export, additional output review, additional digital watermarking, invoking privacy-preserving computation tasks, extending log retention, increasing manual approval, or lowering the service level. If the target space cannot execute compensation controls, the system refuses mutual recognition and generates a reason for refusal.

[0052] For semantic ambiguity conflicts, the system generates a task to be reviewed, retaining source constraints, target candidates, matching confidence, difference explanations, and recommended actions. The results of manual review do not directly overwrite historical records; instead, they are written to the mapping version repository as a new mapping version for reuse and traceability in subsequent similar contracts.

[0053] Example 9: Generation and Distribution of Target Strategy Packages The policy package generation module generates a target policy package based on the resolved mapping relationships. The target policy package includes a policy identifier, policy version, subject mapping table, data directory mapping table, purpose mapping table, action control rules, environment constraint expressions, output control rules, audit log fields, compensation control instructions, validity period, approval records, and signature digest.

[0054] The target policy package can be distributed to the target space connector, API gateway, data sandbox, privacy computing engine, model service, or audit service. Before distribution, the system signs the target policy package and binds the source contract hash, target policy package hash, and mapping version number. After receiving the policy package, the target space connector verifies the signature. If the verification is successful, it is loaded into the local policy engine. If the verification fails or the policy version has been revoked, the target space must not execute data requests.

[0055] Example 10: Execution Simulation The executability simulation module constructs test requests before the strategy package takes effect, including compliance requests, unauthorized entity requests, unauthorized usage requests, expiration requests, export details requests, missing log requests, and output out-of-scope requests. The system submits the test requests to the target space strategy engine or simulation strategy engine to verify whether the returned results match the expectations of the source digital contract.

[0056] For example, if the source contract requires that detailed data not be exported, the simulation module constructs a request to export detailed data, and the target policy engine should return a rejection or proceed to output review. If the source contract requires that logs be retained for three years and contain a policy version field, the simulation module checks whether the target log fields contain the policy version, request body, data directory, action, output summary, timestamp, and signature summary. If the simulation fails, the system reverts to the conflict resolution step to regenerate the compensation control policy; if consecutive failures exceed a preset number, mutual recognition is terminated.

[0057] Example 11: Audit Evidence Preservation and Version Update The audit and evidence storage module records the source contract hash, source space model version, target space model version, mapping version, conflict type, resolution action, target strategy package hash, simulation test results, approval records, signature digest, and timestamp. These records can be written to the trusted data space audit log, consortium blockchain, or regulatory platform's evidence storage interface.

[0058] When the target space model description file undergoes version changes, such as adjustments to the usage classification tree, upgrades to execution capabilities, changes to log fields, or connector version updates, the system recalculates the semantic coverage, execution reachability, and risk differences of the already effective mappings. If the recalculation results do not meet the thresholds, the system automatically suspends the relevant strategy packages or downgrades them to manual review status to prevent historical contract constraints from becoming invalid after the space upgrade.

[0059] Example 12: Application Case In the scenario of cross-space circulation of public transportation data, the source space digital contract stipulates that: the target user can only train the traffic congestion prediction model within the industry application trusted data space; vehicle trajectory details must not be exported; the output results must be aggregated by road segment and 15-minute granularity; the logs must be kept for three years and include the requesting subject, purpose, data directory, model task number and output summary.

[0060] After system parsing, a constraint graph is generated. The target space can natively perform identity verification, usage restrictions, and task logs, but does not support raw detail export control. The system identifies this as a conflict due to insufficient execution capability and generates a compensation strategy: forcing the training task to run in a data sandbox, disabling the detail download interface, allowing export only after the output results have undergone an aggregation threshold check, and attaching a batch watermark to the results. After the executability simulation passes, the system issues the strategy package and writes it to the audit log.

[0061] Therefore, cross-space data circulation no longer relies on manual interpretation of contract text, but ensures that digital contracts are executed equivalently or more strictly in the target space through computable semantic mapping, execution capability verification, and conflict resolution mechanisms.

Claims

1. A method for semantic mapping and policy conflict resolution of digital contracts across trusted data spaces, characterized in that, include: Receive data flow requests initiated by the source trusted data space to the target trusted data space, and obtain the source digital contract, the source space model description file, and the target space model description file; The source digital contract is normalized and parsed into a unified set of atomic constraint objects, including subject, object, action, purpose, spatiotemporal, environment, output, audit, and obligation constraints. A heterogeneous constraint graph Gs of the source contract is constructed based on the unified atomic constraint object set, and a target space capability semantic graph Gt is constructed based on the target space model description file. Constraint semantic vectors, structural context vectors, execution capability vectors, and evidence requirement vectors are generated for the source constraint nodes in Gs and the target nodes in Gt, respectively. Generate a candidate set of target constraint mappings, and calculate the semantic coverage, graph structure consistency, execution reachability, audit completeness, and risk increment of the candidate mappings; The conflict cost function is solved under the constraints of no expansion of permissions, no loss of mandatory constraints, generation of audit evidence, and risk increment not exceeding a threshold, to obtain the optimal mapping combination. Based on the optimal mapping combination, at least one of the following is identified: constraint missing, granularity mismatch, permission expansion, semantic ambiguity, insufficient execution capability, inconsistent audit evidence, and constraint propagation conflict. Tightening mapping, constraint splitting, equivalent substitution, compensation control, manual review, or rejection of mutual recognition are executed to generate a target strategy package that can be executed in the target trusted data space. The target strategy package is subjected to strategy simulation verification using positive compliance samples and negative default samples. The target strategy package, mapping matrix, conflict resolution record, simulation verification results, and chain signature summary are written into the cross-space audit record.

2. The method according to claim 1, characterized in that, The unified atomic constraint object includes at least constraint identifier, constraint category, constraint value range, comparison operator, granularity level, mandatory identifier, risk level, evidence field, triggering condition, effective window, failure condition, and obligation action; the source contract heterogeneous constraint graph Gs includes source constraint nodes, containing edges, dependent edges, exclusive edges, sequential edges, jointly effective edges, condition triggering edges, obligation bearing edges, evidence supporting edges, node attribute vectors, and edge relationship types. The target space capability semantic graph Gt includes target policy nodes, target capability nodes, target audit nodes, semantic hierarchy edges, capability carrying edges, policy execution edges, and evidence generation edges.

3. The method according to claim 1, characterized in that, Both the source spatial model description file and the target spatial model description file include spatial identifier, connector version, identity mode, subject role hierarchy, data directory mode, field definition, usage classification tree, permission action enumeration, environmental constraint type, output control capability, log field mode, evidence retention period, signature algorithm, encryption algorithm, timestamp source, and policy execution capability list. The target constraint mapping candidate set is generated through at least three of the following methods: precise field matching, synonym matching, hierarchical concept matching, classification path edit distance matching, numerical interval inclusion relationship matching, unit conversion matching, rule expression conversion, historical mapping reuse, and graph neighborhood expansion.

4. The method according to claim 1, characterized in that, The semantic coverage SC is according to Calculate; the graph structure consistency GC is calculated according to Calculate; where Ei and Ej are the semantic vectors of source constraint node i and target candidate node j, PathSim represents the classification path similarity, RangeCover represents the coverage relationship between the target constraint domain and the source constraint domain, GranMatch represents the granularity matching function, Aip and Bjq are the edge weights in Gs and Gt respectively, and eta is the edge relationship type consistency function.

5. The method according to claim 1, characterized in that, The execution reachability ER is based on The audit completeness AC is calculated according to... The risk increment RD is calculated according to... Calculate; where Nij represents the native policy capability coverage value, Cij represents the compensation control coverage value, RBij represents the rollback risk value, Ei_req represents the set of evidence fields required by the source constraints, and Lj represents the set of logs or evidence fields that the target candidate node can generate.

6. The method according to claim 1, characterized in that, The conflict cost function J is according to Calculation, where , xij is a binary variable representing whether source constraint node i selects target candidate node j, Pexpand is the permission expansion penalty, Pmiss is the penalty for missing mandatory constraints, and Pcycle is the constraint propagation closed-loop conflict penalty; when solving, the following conditions must be met: each mandatory source constraint node must select at least one target candidate node or compensation control node; the authorization scope of the selected target candidate node must not be wider than the authorization scope of the source constraint; the audit completeness must not be lower than the audit threshold; the risk increment must not be higher than the risk threshold; and two source constraint nodes with exclusion edges must not be mapped to the same target allowed action.

7. The method according to claim 1, characterized in that, The conflict identification includes: when the source constraint node cannot find a target candidate node or compensation control node in Gt with semantic coverage not lower than the semantic threshold and execution reachability not lower than the execution threshold, it is identified as a constraint missing conflict; when the target candidate constraint allows at least one of the following: subject set, data set, action set, usage set, time window, geographical range, output granularity, or retention period to be wider than the source constraint, it is identified as a permission expansion conflict; when the target space lacks environmental isolation, number of times limit, real-time blocking, export control, result aggregation, watermark embedding, privacy computation, log signature, trusted timestamp, or evidence retention capability, it is identified as an execution capability insufficient conflict; when the log field, signature algorithm, timestamp source, retention period, evidence hash field, or signature verification interface does not meet the source digital contract audit requirements, it is identified as an audit evidence inconsistency conflict.

8. The method according to claim 1, characterized in that, The conflict resolution includes: performing tightening mapping on permission expansion conflicts; performing constraint splitting or result aggregation on granularity mismatch conflicts; generating a minimum compensation control set for conflicts with insufficient execution capabilities; adding evidence fields, signature summaries, and retention requirements for conflicts with inconsistent audit evidence; generating tasks to be reviewed for semantic ambiguity conflicts; and generating a mutual recognition rejection record for conflicts with uncompensated missing constraints. The minimum compensation control set is selected from at least one compensation control from mandatory data sandboxing, read-only access, computation-only without export, additional output review, additional digital watermarking, invoking privacy computation tasks, reducing output granularity, increasing manual approval, and extending log retention, with the selection objectives being the maximum number of uncovered mandatory constraints, the minimum compensation risk, the minimum operational overhead, and the minimum increase in audit fields.

9. The method according to claim 1, characterized in that, The strategy simulation verification includes automatically generating compliance samples, unauthorized entity samples, unauthorized usage samples, expired access samples, geographical boundary out-of-bounds samples, excessive call samples, detailed export samples, and missing log samples based on the heterogeneous constraint graph of the source contract. These samples are then input into the strategy engine corresponding to the target strategy package, and the results returned by the strategy engine are compared with the expected results of the source contract. When the simulation verification fails, the failed constraint node and target strategy field are located, and the process reverts to the conflict resolution step to regenerate the target strategy package. When the number of consecutive reverts exceeds a threshold or the same mandatory constraint fails repeatedly, cross-space mutual recognition is terminated, and a mutual recognition rejection record is generated. After the target space model description file is updated, the strategy drift value is calculated. When the policy drift value exceeds the drift threshold, the effective target policy package will be paused, downgraded, remapped, or manually reviewed.

10. A system for semantic mapping and policy conflict resolution of digital contracts across trusted data spaces, characterized in that, The system includes a request receiving module, a contract normalization parsing module, a source contract heterogeneous constraint graph generation module, a target space capability semantic graph generation module, a constraint vectorization module, a candidate mapping generation module, a comprehensive scoring module, a conflict cost solving module, a conflict identification module, a conflict resolution module, a target policy package generation module, a policy simulation verification module, a policy drift detection module, and an audit and evidence storage module. These modules are configured to perform the method described in any one of claims 1 to 9; or, an electronic device or computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 9.

Images