Method and apparatus for arbitrating disputes in data flow transactions

Abstract

The application provides a data flow transaction dispute arbitration method and device, which comprises the following steps: receiving an arbitration request and applicant evidence, generating an arbitration semantic intermediate model according to the arbitration request and the applicant evidence, generating an evidence hypothesis set according to the arbitration semantic intermediate model, splitting each hypothesis in the evidence hypothesis set into a to-be-verified fact and a fact verification description object, inputting the fact verification description object and a current hypothesis state into an evidence retrieval controller to obtain an arbitration result, and maintaining an evidence state diagram by the evidence retrieval controller. The evidence retrieval controller comprises a task planner, a retrieval executor, an evidence evaluator, a hypothesis state manager, a query rewriter, a retrieval state recorder, a stop controller and a result generator. The application can realize cross-platform original data out-of-domain verifiable forensics.

Description

Technical Field

[0001] This invention relates to the fields of data element circulation, intelligent information retrieval, and cross-institutional trusted evidence collection, and in particular to a method and apparatus for arbitrating disputes related to data circulation transactions. Background Technology

[0002] In the arbitration process of cross-platform data transaction disputes, the disputed matters may involve multiple business aspects such as data ownership, contract performance, data delivery, authorized use, revenue distribution, and data quality. The relevant electronic data used to prove the above matters are usually stored in different platforms such as data registration systems, contract management systems, transaction systems, payment systems, data delivery systems, interface calling systems, and auditing systems. The data structure, identification methods, access interfaces, and evidence storage rules of each platform may differ.

[0003] Existing technologies typically assist in handling data transaction disputes through methods such as log querying, electronic evidence storage, rule verification, data comparison, or audit report generation. When using these methods, personnel usually need to pre-determine the orders, data products, users, interfaces, or log records to be queried based on the arbitration request, and manually set the query conditions. Since arbitration requests are usually described in natural language, and the same dispute may involve multiple parties, multiple transaction stages, and multiple time points, existing systems struggle to automatically identify interrelated facts to be verified from the arbitration request, and accordingly determine the type of evidence, source of evidence, and scope of query for each fact. Therefore, related records from different systems are difficult to effectively correlate, and there may be a lack of clear correspondence between the evidence obtained and the disputed matter.

[0004] Furthermore, cross-platform forensics is limited by data security, access permissions, and the protection of sensitive information. Platforms storing relevant electronic data typically cannot directly provide external parties with complete original records containing other customers, other orders, or sensitive business fields. Instead, they can only return relevant records, anonymized data, summary information, or verification results within authorized scopes. Existing cross-platform query requests are usually represented in the form of order numbers, product numbers, or log conditions, lacking a unified description of the facts to be verified, the target data source, the query time range, the query fields, and the allowed output content. Consequently, after the collaborative platform returns the query results, the initiating party often finds it difficult to confirm the facts to be verified, the actual data source and time range accessed, and the verification rules, algorithms, and parameter versions used to generate the results, affecting the traceability and reproducibility of the forensics process and results.

[0005] When cross-platform queries fail to retrieve the target record, or when records returned by different data sources are inconsistent, existing systems often struggle to distinguish between different scenarios, such as the target record not existing, inaccurate query identifiers or conditions, insufficient access permissions, abnormal API calls, data synchronization delays, and logs exceeding their retention period. If a fact to be verified has not yet met the predetermined criteria for sufficient evidence, personnel typically need to reassess the evidence gaps and determine the direction for supplementary evidence gathering based on existing materials. The system struggles to automatically adjust subsequent query targets, query conditions, or evidence acquisition paths based on the current verification status of the fact, the reasons for query failures, and the relationship between existing evidence.

[0006] Therefore, existing technologies still have problems when dealing with cross-platform data transaction disputes, such as difficulty in automatically linking arbitration requests with facts to be verified, lack of a unified scope and output constraints for evidence collection requests, insufficient traceability of query processes and verification results, and inability to dynamically adjust subsequent evidence collection processes based on evidence status and query results. It is difficult to form a closed-loop processing process from arbitration request parsing, fact verification, cross-platform evidence collection, evidence evaluation to query adjustment and result generation. Summary of the Invention

[0007] This invention provides a data circulation transaction dispute arbitration method and apparatus to solve the problem that existing technologies are difficult to form a closed-loop processing process from arbitration request parsing, fact verification, cross-platform evidence collection, evidence evaluation to query adjustment and result generation when handling cross-platform data transaction disputes.

[0008] This invention provides a method for arbitrating disputes related to data circulation and transactions, comprising the following steps: Receive the arbitration request and the applicant's evidence, and generate an intermediate semantic model of arbitration based on the arbitration request and the applicant's evidence; An evidence hypothesis set is generated based on the arbitration semantic intermediate model. Each hypothesis in the evidence hypothesis set is split into facts to be verified and fact verification description objects. The fact verification description objects and the current hypothesis state are input into the evidence retrieval controller to obtain the arbitration result. The evidence retrieval controller includes a task planner, a retrieval executor, an evidence evaluator, a hypothesis state manager, a query rewriter, a retrieval state recorder, a stop controller, and a result generator; the hypothesis state manager maintains an evidence state graph; the following operations are performed in the evidence retrieval controller: The task planner generates a dynamic task queue based on the current hypothesis state and evidence gaps. The retrieval executor selects a retrieval strategy from the dynamic task queue and generates a restricted query. It executes the restricted query through a unified retrieval interface and returns the local query results and the reasons for the miss. If the fact to be verified is indicated by the fact verification description object as requiring cross-platform evidence collection, then a cross-platform restricted task is generated and sent to an external platform, and the privacy evidence certificate returned by the external platform is received. The evidence evaluator evaluates the candidate results in the local query results, creates evidence nodes for candidate results that meet the evaluation criteria, and verifies the privacy evidence credentials, creating restricted evidence nodes for privacy evidence credentials that pass the verification. In the evidence state graph, the evidence nodes and the restricted evidence nodes are respectively associated with the corresponding factual propositions in the facts to be verified, and the unmet conditions are output. The hypothesis state manager updates the fact state according to the relationship between the evidence node and the fact proposition, and feeds back the fact state to the retrieval executor to output the conflict result; The query rewriter generates the next round of query based on the cause of the miss, the unmet condition, or the conflict result, and returns it to the retrieval executor. The stop controller determines whether the stop condition is met based on the fact status and the retrieval round information output by the retrieval status recorder. If the condition is met, it commands the retrieval executor to stop the retrieval and outputs a stop command, the reason for the stop, and the unfinished facts. The result generator responds to the stop command output by the stop controller, generates a fact verification result based on the evidence state diagram, and generates an arbitration result based on the fact verification result, the fact state of each fact proposition in the evidence state diagram, and the logical relationship between each fact proposition and the evidence hypothesis.

[0009] In one embodiment, the arbitration semantic intermediate model includes arbitration elements and claim units; The step of generating an intermediate arbitration semantic model based on the arbitration request and the applicant's evidence includes: Arbitration elements are extracted from any form of the arbitration request and the applicant's evidence, including the claim, the requesting party, the opposing party, the subject matter of the dispute, the assertion, the time constraint, the contract rules, and the requested outcome; If the arbitration request includes multiple claims, each claim shall be treated as a claim unit, and the multiple claim units shall share at least one of the claiming subject, the opposing party, the subject of the dispute, and the time constraint. For information that was not extracted from the arbitration elements, a vacancy or candidate entity is generated.

[0010] In one embodiment, the set of evidence hypotheses includes supporting hypotheses, negative hypotheses, and alternative interpretations; The generation of the evidence hypothesis set based on the arbitration semantic intermediate model includes: For each claim unit, the supporting hypothesis, the negative hypothesis, and the alternative explanation are generated simultaneously. Each of the aforementioned assumptions is broken down into machine-verifiable facts to be verified; Configure establishment conditions, denial conditions, evidence requirements, supporting evidence coverage conditions, and rebuttal evidence coverage conditions for each of the facts to be verified, and write the establishment conditions, denial conditions, evidence requirements, supporting evidence coverage conditions, and rebuttal evidence coverage conditions into the fact verification description object.

[0011] In one embodiment, the task planner generates a dynamic task queue based on hypothesis discrimination, dependencies, query costs, and permission levels; the task planner generates the dynamic task queue based on the current hypothesis state and evidence gaps, including: Based on the current state of the hypothesis and the evidence gap, determine the hypothesis discrimination of the hypothesis to be verified; Determine the dependencies between factual propositions; The facts in the set of facts to be processed are sorted according to the assumed discrimination, and the first sorting result is obtained. Based on the dependencies, the execution order is adjusted according to the fact that there are prerequisite relationships in the first sorting result to obtain the second sorting result; Based on query cost and permission level, the priorities of the tasks corresponding to each fact in the second sorting result are fine-tuned to generate a dynamic task queue.

[0012] In one embodiment, the retrieval strategy includes deterministic identifier precise retrieval and enhanced retrieval; the dynamic task queue contains at least one task to be executed, and each task to be executed corresponds to a retrieval strategy; The retrieval executor selects a retrieval strategy from the dynamic task queue, including: Prioritize the precise retrieval of the corresponding task to be executed based on the deterministic identifier, and use the results of the precise retrieval as candidate evidence; If the precise retrieval fails or key information is missing, the corresponding task to be executed for enhanced retrieval is selected from the dynamic task queue according to the reason for the miss returned by the unified retrieval interface. The enhanced retrieval includes entity alias fuzzy retrieval, misspelling fuzzy retrieval, semantic vector retrieval, time window progressive expansion, entity association expansion, evidence state graph adjacency expansion, and cross-source cross retrieval. Among them, the results of fuzzy search are used as candidate evidence after being verified for entity consistency, time consistency, and source consistency.

[0013] In one embodiment, after the evidence evaluator creates evidence nodes corresponding to supporting hypotheses, the query rewriter also generates queries for verifying negative hypotheses or alternative interpretations. The supporting evidence and the counter-evidence are evaluated using the same criteria; the evaluation criteria include relevance criteria, source reliability criteria, and coverage adequacy criteria. If the search for counter-evidence directions for the negative hypothesis and the alternative interpretations has not yet reached the preset search coverage requirement, the hypothesis state manager shall not update the fact state to verified; when the supporting evidence meets the support sufficient condition, the search for counter-evidence directions meets the preset search coverage requirement and there is no valid counter-evidence that meets the negation sufficient condition, the hypothesis state manager shall update the fact state to verified.

[0014] In one embodiment, the query rewriter rewrites the query expression in at least one of the following ways: Query standardization; Alias ​​extension; Time window expansion; Data source switching; Add constraints to confirmed entities; Add business phase constraints; Redirecting can provide the associated data source for key fields; Generate queries that verify the time, status, and subject mappings of each source; The query rewriter generates the next round of queries based on the cause of the miss, the condition not met, or the conflict result, including: If no match is found, query normalization, alias expansion, time window expansion, or data source switching will be triggered. If there are too many candidate results, add constraints on confirmed entities or business stages; If a candidate result lacks a key field, the search will turn to a related data source that can provide the key field. If results from different sources conflict, queries are generated to verify the time, status, and subject mapping of each source separately. After each rewrite, the previous query expression, the rewritten query expression, the reason for the rewrite, and the range change are written into the retrieval status recorder.

[0015] In one embodiment, the stopping condition includes at least one of the following: The key facts meet the criteria for sufficient evidence; Both supporting and counter-evidence meet the preset retrieval coverage requirements; No new valid evidence was obtained after several consecutive preset rounds; The maximum number of query rounds, time limit, or resource limit has been reached. Further actions require additional authorization; There are contractual ambiguities or conflicting evidence that require human interpretation; The stop controller determines whether the stop condition is met based on the fact status output by the hypothetical state manager and the retrieval round information output by the retrieval state recorder. If the condition is met, the stop controller commands the retrieval executor to stop the retrieval, and the stop controller outputs the stop reason and the unfinished facts.

[0016] In one embodiment, the cross-platform restricted task carries multiple items from the following: fact-checking description object, case-limited task identifier, range of allowed search strategies, maximum time extension range, maximum association depth, and allowed output fields; The privacy evidence credential includes multiple items from the following: case-limited task identifier, factual status, query execution status, actual coverage, evidence type summary, query condition commitment, source record set commitment, calculation algorithm and parameter version, generation time, and platform signature. After the evidence retrieval controller verifies the privacy evidence credential, it writes the privacy evidence credential as an evidence node into the evidence state graph. In the evidence state graph, the privacy evidence credential is associated with the fact proposition node corresponding to the fact identifier and is not used for other fact propositions.

[0017] The present invention also provides a data circulation transaction dispute arbitration device, comprising the following modules: The receiving module is used to receive arbitration requests and applicant evidence, and generate an arbitration semantic intermediate model based on the arbitration requests and applicant evidence. The arbitration module is used to generate an evidence hypothesis set based on the arbitration semantic intermediate model, split each hypothesis in the evidence hypothesis set into facts to be verified and fact verification description objects, input the fact verification description objects and the current hypothesis state into the evidence retrieval controller, and the result generator responds to the stop command output by the stop controller to obtain the arbitration result; The evidence retrieval controller includes a task planner, a retrieval executor, an evidence evaluator, a hypothesis state manager, a query rewriter, a retrieval state recorder, a stop controller, and a result generator; the hypothesis state manager maintains an evidence state graph; the following operations are performed in the evidence retrieval controller: The task planner generates a dynamic task queue based on the current hypothesis state and evidence gaps. The retrieval executor selects a retrieval strategy from the dynamic task queue and generates a restricted query. It executes the restricted query through a unified retrieval interface and returns the local query results and the reasons for the miss. If the fact to be verified is indicated by the fact verification description object as requiring cross-platform evidence collection, then a cross-platform restricted task is generated and sent to an external platform, and the privacy evidence certificate returned by the external platform is received. The evidence evaluator evaluates the candidate results in the local query results, creates evidence nodes for candidate results that meet the evaluation criteria, and verifies the privacy evidence credentials, creating restricted evidence nodes for privacy evidence credentials that pass the verification. In the evidence state graph, the evidence nodes and the restricted evidence nodes are respectively associated with the corresponding factual propositions in the facts to be verified, and the unmet conditions are output. The hypothesis state manager updates the fact state according to the relationship between the evidence node and the fact proposition, and feeds back the fact state to the retrieval executor to output the conflict result; The query rewriter generates the next round of query based on the cause of the miss, the unmet condition, or the conflict result, and returns it to the retrieval executor. The stop controller determines whether the stop condition is met based on the fact status and the retrieval round information output by the retrieval status recorder. If the condition is met, it commands the retrieval executor to stop the retrieval and outputs a stop command, the reason for the stop, and the unfinished facts. In response to the stop command, the result generator generates a fact verification result based on the evidence state diagram, and generates an arbitration result based on the fact verification result, the fact state of each fact proposition in the evidence state diagram, and the logical relationship between each fact proposition and the evidence hypothesis.

[0018] The data circulation transaction dispute arbitration method and apparatus provided by the present invention generate an arbitration semantic intermediate model and transform it into a set of evidence assumptions and a fact verification description object. The fact verification description object is then input into an evidence retrieval controller, thereby transforming the arbitration request into a machine-executable object with fact-level constraints. This transforms the arbitration claim, which originally relied on human understanding and processing, into a fact verification task that is machine-identifiable, executable, and traceable.

[0019] When the retrieval executor generates a restricted query, the query is constrained by the fact-verification description object, limiting the scope of the facts to be verified. For facts to be verified that require cross-platform evidence collection, fact-level constraints and output constraints for cross-platform requests are implemented. The cross-platform restricted task carries the fact-verification description object and sends it to the external platform. The external platform returns privacy evidence credentials, enabling the initiator to verify the query execution status and coverage, thus achieving verifiability of cross-domain evidence collection results.

[0020] The unified retrieval interface returns a reason for a missed query after executing a restricted query, distinguishing the specific circumstances of the missed query. The query rewriter performs subsequent processing based on the reason for the missed query. For example, if the state manager updates the fact state to unknown, it indicates that the query failed or was unverified due to insufficient coverage, thus clearly distinguishing the semantics of no record and enhancing the traceability of the query process and verification results.

[0021] The evidence evaluator outputs a condition not met, while the assumption state manager outputs a conflicting result. The unmet condition and the conflicting result constitute an evidence gap, meaning the current evidence cannot sufficiently support or refute a hypothesis. The query rewriter generates the next round of queries based on the cause of the miss, the unmet condition, or the conflicting result and returns it to the retrieval executor. The stop controller determines whether the stop condition is met based on the factual state and retrieval round information. If it is met, it commands the retrieval executor to stop the retrieval and outputs the stop command, the stop reason, and the unfinished facts.

[0022] The result generator responds to the stop command output by the stop controller, generates fact verification results based on the evidence state diagram, and then generates the arbitration result based on the fact verification results, the factual state of each factual proposition, and the logical relationship between each factual proposition and the evidence assumption. This ensures that the generation of the arbitration result is based on the fact verification results of the evidence state diagram and the logical relationship between each factual proposition and the evidence assumption, achieving full traceability of the arbitration result from facts to evidence to conclusion. It forms a complete closed-loop processing procedure from arbitration request parsing, fact verification, cross-platform evidence collection, evidence evaluation, query adjustment to result generation. This method allows the arbitration result to be traced back to the corresponding facts, evidence, and retrieval process. Dynamic query adjustment avoids duplicate and invalid searches, improving dispute resolution efficiency while enhancing the standardization, consistency, and verifiability of the arbitration process. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0024] Figure 1 This is a schematic diagram of the data circulation and transaction dispute arbitration system provided by the present invention.

[0025] Figure 2 This is a flowchart illustrating the data circulation and transaction dispute arbitration method provided by the present invention.

[0026] Figure 3 This is a flowchart illustrating the cross-platform privacy joint forensics protocol process provided by the present invention.

[0027] Figure 4 This is a schematic diagram of the data circulation and transaction dispute arbitration device provided by the present invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0029] The following is combined with Figures 1 to 4 This invention describes a data circulation transaction dispute arbitration method and apparatus.

[0030] This invention provides a data circulation transaction dispute arbitration method for handling disputes arising during the data element circulation process when data providers, data buyers, data users, or other relevant parties have disagreements regarding data transactions, delivery, authorization, use control, revenue distribution, data quality, or unauthorized use. The method takes the arbitration request and the applicant's evidence as input and the arbitration result as output. This method does not require the applicant to pre-select a fixed dispute type; instead, it converts the arbitration request into a unified data structure, driving a cyclical process of retrieval, evaluation, verification, and termination. While ensuring that the original data from each platform remains within its domain, it achieves cross-platform verifiable evidence collection and outputs the arbitration result.

[0031] This method can be deployed in the dispute resolution system of a data exchange or data circulation platform. The system connects to various business systems (including registration and rights confirmation system, transaction matching system, contract system, payment and settlement system, data delivery system, API gateway, data sandbox, privacy protection computing platform, usage control system, and auditing system, etc.) through read-only interfaces or adapters, without directly modifying the original data of each business system.

[0032] Figure 1 This is a schematic diagram of the data circulation and transaction dispute arbitration system of the present invention. Figure 1 As shown, the system includes a user access layer, an evidence arrangement layer, a data processing layer, a calculation and judgment layer, and a trust support layer.

[0033] The user access layer provides different access points for applicants, compliance personnel, and reviewers, including arbitration application submission, evidence upload, identity authentication, authorization confirmation, and result viewing. Applicants submit arbitration requests and their evidence through the user access layer; compliance personnel approve sensitive evidence collection tasks and view anonymized evidence through the user access layer; and reviewers view the evidence chain, scoring process, and matters pending review within their authorized scope.

[0034] The evidence arrangement layer comprises a request parsing module and a hypothesis generation unit. The request parsing module extracts arbitration elements from the arbitration request text and the applicant's evidence, generates candidate entities for missing information, and generates an intermediate arbitration semantic model independent of the specific arbitration type based on the extracted arbitration elements and candidate entities. The hypothesis generation unit generates a set of evidence hypotheses based on the intermediate arbitration semantic model, breaking down each hypothesis into facts to be verified and fact-verification description objects. The evidence arrangement layer is responsible for converting the arbitration request into the intermediate arbitration semantic model, generating the set of evidence hypotheses, and the fact-verification description objects.

[0035] The data processing layer is responsible for log adaptation, event vectorization, time calibration, subject object parsing, and evidence chain construction. It receives raw logs from various business systems, normalizes the logs into event vectors, constructs an evidence state graph, and maintains the association between evidence nodes and factual propositions.

[0036] The computational decision layer comprises an evidence retrieval controller, a unified retrieval interface, a cross-platform forensics module, and a report generation module. The unified retrieval interface registers and invokes precise query tools, fuzzy matching tools, semantic retrieval tools, graph query tools, log query tools, and cross-platform restricted query tools, executing restricted queries generated by the retrieval executor and returning query results and reasons for misses. When the fact to be verified is indicated by the fact-checking description object as requiring cross-platform forensics, the cross-platform forensics module generates a cross-platform restricted task and sends it to the external platform, receiving privacy-preserving evidence credentials returned by the external platform. The computational decision layer performs enhanced retrieval, evaluates candidate evidence, updates the fact state, rewrites queries, determines stopping conditions, generates fact-checking results, generates arbitration results, and generates an arbitration report. During cross-platform privacy forensics, the computational decision layer initiates joint computation, combining local evidence and privacy-preserving evidence credentials returned by the external platform for comprehensive judgment.

[0037] The Trusted Support Layer is responsible for hash commitments, trusted timestamps, access control, de-identification policies, and audit trails. It stores records of the retrieval process, generates hash commitment chains, verifies privacy evidence credentials, manages case authorization, and records audit logs for key operations. Viewing, exporting, and cross-domain operations of evidence are executed according to case authorization, and the commitment values ​​at key stages are linked to third-party trusted timestamps or consortium blockchains. Key actions such as case creation, querying, cross-domain interaction, report publication, and review all generate audit logs and hash commitments.

[0038] Figure 2 This is a flowchart illustrating the data circulation and transaction dispute arbitration method provided by the present invention, as shown below. Figure 2 As shown, the arbitration methods for data circulation and transaction disputes include the following: S110. Receive the arbitration request and the applicant's evidence, and generate an intermediate semantic model for arbitration based on the arbitration request and the applicant's evidence.

[0039] First, we will receive the arbitration request submitted by the applicant. The form of the arbitration request is not limited; the applicant may submit a dispute resolution request in natural language, through forms, contracts, orders, screenshots, anomaly samples, or log fragments, etc. The applicant must also submit supporting evidence related to the arbitration request, including contract numbers, data product numbers, order numbers, delivery receipts, API call receipts, anomaly result samples, communication record summaries, and other information that points to the facts of the dispute.

[0040] The applicant's identity is verified to confirm their authority to submit an arbitration request. The case identifier in the applicant's arbitration request is compared with the case identifier in the applicant's evidence to confirm that the arbitration request and the applicant's evidence belong to the same case. After completing the identity and case association verification, a case number is generated and all original materials, including the applicant's arbitration request and evidence, are archived. The case number serves as the primary key for the entire index; subsequent evidence collection tasks, event vectors, evidence status diagrams, calculation reports, and cross-departmental collaboration records are all associated with the same primary key, achieving one case, one archive, and full traceability.

[0041] Arbitration elements are extracted from the arbitration request and the applicant's evidence. These elements include the claim, the requesting party, the opposing party, the subject matter of the dispute, the assertion of actions, time constraints, contractual rules, and the requested outcome. Elements not explicitly given are recorded as missing. When an arbitration request contains multiple claims, each claim is treated as a separate claim unit. After extraction, all extracted arbitration elements and claim units are organized into an intermediate arbitration semantic model and output. This intermediate model represents information such as the arbitration claim, the requesting party, the opposing party, the subject matter of the dispute, the assertion of actions, time constraints, contractual rules, and the requested outcome, for use in subsequent hypothesis generation, evidence retrieval, and fact verification processes.

[0042] S120. Generate an evidence hypothesis set based on the arbitration semantic intermediate model, split each hypothesis in the evidence hypothesis set into facts to be verified and fact verification description objects, input the fact verification description objects and the current hypothesis state into the evidence retrieval controller, and obtain the arbitration result.

[0043] An evidence hypothesis set is generated based on the intermediate semantic model of arbitration, and a set of evidence hypotheses is generated for each claim unit. The evidence hypothesis set includes three categories of hypotheses. The first category is supporting hypotheses, which support the applicant's claim. The second category is negative hypotheses, which negate the applicant's claim. The third category is alternative interpretations, which are other possible interpretations that cannot be excluded by the current evidence.

[0044] After generating hypotheses, each hypothesis is broken down into facts to be verified, and verification conditions are configured for each fact. These verification conditions are then written into a fact verification description object. The fact verification description object and the current hypothesis state are then input into the evidence retrieval controller.

[0045] The evidence retrieval controller includes a task planner, a retrieval executor, an evidence evaluator, a hypothesis state manager, a query rewriter, a retrieval state recorder, a stop controller, and a result generator. The current hypothesis state is continuously maintained and updated by the hypothesis state manager and fed back to the task planner after each round of retrieval. The result generator is used to generate fact-checking results and arbitration results after the retrieval stops. The evidence retrieval controller maintains an evidence state graph. The evidence state graph is a directed heterogeneous graph with attributes, used to record all evidence nodes, factual proposition nodes, hypothesis nodes, and their relationships throughout the entire case lifecycle.

[0046] The following operations are performed in the evidence retrieval controller: S210, The task planner generates a dynamic task queue based on the current hypothesis state and evidence gaps. The retrieval executor selects a retrieval strategy from the dynamic task queue and generates a restricted query. The restricted query is executed through a unified retrieval interface and the local query results and reasons for misses are returned.

[0047] The current hypothesis state refers to the current proof status of each hypothesis, including being supported, refuted, unknown, or conflicting. An evidence gap refers to a state where current evidence is insufficient to fully support or refute a hypothesis, including unmet conditions and conflicting results. The task planner determines the query tasks to be executed and generates a dynamic task queue based on the facts corresponding to the unknown hypotheses in the current hypothesis state and the facts requiring supplementary evidence indicated by the evidence gap. After each round of retrieval, the task planner reorders the task queue according to the updated current hypothesis state and evidence gap.

[0048] The retrieval executor sequentially retrieves tasks from the dynamic task queue, selects a retrieval strategy, and generates a restricted query. A restricted query is one that is constrained by the fact-checking description object and the scope of case authorization in terms of subject, object, time, fields, and data source. After receiving a restricted query, the unified retrieval interface calls the corresponding retrieval tool to execute the query and returns the query results and reasons for misses. The unified retrieval interface outputs the query execution status and reasons for misses; the query execution status indicates whether the query was successful, failed, had insufficient permissions, or the data source is unavailable; the reasons for misses are used to distinguish between situations such as no record found, mismatched identifiers, inappropriate query time range, or logs exceeding their retention period when the query succeeds but no records are retrieved.

[0049] S220. If the fact to be verified is indicated by the fact verification description object as requiring cross-platform evidence collection, then a cross-platform restricted task is generated and sent to an external platform, and the privacy evidence credential returned by the external platform is received.

[0050] Cross-platform restricted tasks carry a fact-verification description and a case-restricted task identifier. The case-restricted task identifier does not expose the complete case number to the collaboration platform. After the cross-platform restricted task is sent to an external platform, the external platform converts the restricted task into a local query, executes the query according to the disclosure policy, and generates privacy evidence credentials. Upon receiving the privacy evidence credentials, the initiating platform performs verification. If the verification passes, the privacy evidence credentials are written as a restricted evidence node into the evidence status graph.

[0051] S230. The evidence evaluator evaluates the candidate results in the local query results, creates the candidate results that meet the evaluation criteria as evidence nodes, verifies the privacy evidence credential, and creates the verified privacy evidence credential as a restricted evidence node; in the evidence state diagram, the evidence nodes and the restricted evidence nodes are respectively associated with the corresponding factual propositions in the facts to be verified, and outputs the unmet conditions.

[0052] The evidence evaluator evaluates each candidate result in the local query results. Candidate results that meet the evaluation criteria are created as evidence nodes and associated with the corresponding factual propositions in the evidence state graph. Candidate results that do not meet the evaluation criteria are not created as formal evidence nodes but are retained in the candidate pool as candidate evidence nodes, and their failure to meet the criteria is recorded to trigger subject verification, object verification, or supplementary evidence tasks. The evidence evaluator also verifies the source, completeness, task consistency, and scope of the claims of privacy evidence credentials. If the verification passes, the privacy evidence credentials are created as restricted evidence nodes.

[0053] S240. The hypothesis state manager updates the fact state according to the relationship between the evidence node and the fact proposition, feeds back the fact state to the retrieval executor, and outputs the conflict result.

[0054] Assume that after receiving evidence nodes, the state manager maintains the fact states in the evidence state graph. The state manager updates the fact states based on the relationship type between the evidence nodes and the fact propositions. Fact states include four values: verified, refuted, unknown, and conflicting. Unknown and conflicting states are not equivalent to the fact not existing. When a conflicting state occurs, both sides' evidence and source commitments are retained, and no simple majority vote is performed. The updated fact states are fed back to the retrieval executor to drive the next round of retrieval. A conflicting result refers to an inconsistent state identifier generated when the same fact proposition has both supporting and rebuttal evidence, and neither can be simultaneously true. After obtaining evidence corresponding to the supporting hypothesis, a query is still generated to verify the rebuttal hypothesis or alternative interpretations. Supporting and rebuttal evidence are evaluated using the same criteria.

[0055] S250, the query rewriter generates the next round of query based on the cause of the miss, the condition not met, or the conflict result, and returns it to the retrieval executor.

[0056] The query rewriter receives the reasons for a miss, the conditions not met, and the conflict results. Based on these three types of input, it generates the next round of query expressions and returns them to the retrieval executor. After each rewrite, the query rewriter records the previous query expression, the rewritten query expression, the reason for the rewrite, and the range change.

[0057] S260. The stop controller determines whether the stop condition is met based on the fact status and the retrieval round information output by the retrieval status recorder. If the condition is met, the controller commands the retrieval executor to stop the retrieval and outputs the stop command, the reason for the stop, and the unfinished facts. The stop controller determines whether the stop conditions are met based on the factual status and retrieval round information. If the stop conditions are met, the stop controller commands the retrieval executor to stop the retrieval, outputting the stop reason and incomplete facts. Stop reasons include: key facts meeting the evidentiary sufficiency requirement; both supporting and counter-evidence meeting the preset retrieval coverage requirement; no new valid evidence obtained for consecutive preset rounds; reaching the maximum query round or time limit; subsequent actions requiring additional authorization; and the existence of contractual ambiguities or evidentiary conflicts requiring manual interpretation. Incomplete facts refer to facts that could not be verified due to the retrieval stoppage.

[0058] S270. In response to the stop command, the result generator generates a fact verification result based on the evidence state diagram, and generates an arbitration result based on the fact verification result, the fact state of each fact proposition in the evidence state diagram, and the logical relationship between each fact proposition and the evidence hypothesis.

[0059] The state manager continuously maintains the evidence state graph throughout all operations. The evidence state graph is a directed heterogeneous graph G=(V,E,A,S) with attributes. The node set V includes at least case nodes, claim unit nodes, evidence hypothesis nodes, factual proposition nodes, evidence nodes, candidate evidence nodes, evidence gap nodes, privacy evidence credential nodes, retrieval task nodes, and data source nodes. Evidence gap nodes are created by the evidence evaluator based on unmet conditions or by the hypothesis state manager based on conflict results, marking locations where the current evidence cannot sufficiently support or refute a hypothesis. The relation edge set E includes at least edges originating from, split into, supporting, refuting, explaining, dependent, preceding, mutually exclusive, conflicting, task-generated, credential-provided, and requiring supplementary evidence relationships. A is the attribute set of nodes and edges; S is the factual state set, with values ​​of verified, refuted, unknown, and conflicting.

[0060] The evidence status diagram maintains a two-way index from facts to evidence, from evidence to facts, from facts to assumptions, and from assumptions to claims. Reviewers can locate all supporting, disproving, and conflicting evidence from a specific fact, and can also trace back which facts a piece of evidence supports and which claims it affects from a single piece of evidence.

[0061] Upon cessation of the search, the result generator, responding to the stop command output by the stop controller, reads the factual state of each factual proposition from the evidence state diagram, the relationships between each evidence node and the factual proposition, and the logical relationships between each factual proposition and the evidence assumptions, generating fact verification results. These fact verification results include multiple items from each factual proposition, such as factual identifier, factual state, supporting evidence, rebuttal evidence, conflicting evidence, evidence gaps, and incomplete facts. Based on the fact verification results and the logical relationships between each factual proposition and the evidence assumptions, the result generator generates and outputs the arbitration result.

[0062] Specifically, the result generator reads the factual state (verified, refuted, unknown, or conflicting) of each factual proposition from the evidence state diagram, as well as the evidence nodes attached to each factual proposition and the relationships between each evidence node and the factual proposition (supporting edges, refutating edges, and conflicting edges). Based on the supporting edges, refutating edges, and conflicting edges, it determines the supporting evidence, refutating evidence, and conflicting evidence for each factual proposition. The result generator then organizes the read factual state, supporting evidence, refutating evidence, conflicting evidence, and evidence gap nodes of each factual proposition into a fact-checking result.

[0063] The result generator assesses each evidentiary hypothesis based on its factual state and the logical relationship between the hypothesis and the supporting evidence. If all the facts upon which a hypothesis relies have been verified and there is no sufficient counter-evidence, the hypothesis is deemed to be in favor of the other hypothesis. If the facts upon which the hypothesis relies are refuted or the contrary has been verified, the hypothesis is deemed to be in favor of the other hypothesis. If some of the facts upon which the hypothesis relies are true but lack crucial elements, the hypothesis is deemed to be partially in favor of the other hypothesis. If the facts upon which the hypothesis relies are still unknown or the conflict cannot be resolved, the hypothesis is deemed to be insufficient evidence. Based on the assessment of each evidentiary hypothesis, the result generator generates an arbitration result, which includes a tendency to favor the other hypothesis, a tendency to disfavor the other hypothesis, a partial support hypothesis, or insufficient evidence, and includes the corresponding evidentiary basis and incomplete facts.

[0064] The arbitration result may also include the request for understanding, assumptions and state of fact, a list of supporting evidence, a list of counter-evidence, unknowns, search history, and gaps in evidence. The request for understanding explains the interpretation of the arbitration request, while the assumptions and state of fact explain the supporting status of each assumption and the probative status of each factual proposition. The arbitration result referred to in this invention is the arbitration award generated by the system based on the factual verification results. When the actual arbitration proceedings require review by arbitrators, the arbitration result serves as the basis for the arbitrators to make a final arbitration award. The reviewers can confirm, return for supplementary evidence, or make corrections, and the reasons for corrections and the previous and current versions are continued to be archived.

[0065] This invention generates an intermediate semantic model for arbitration and transforms it into a fact-verification description object. This allows the restricted queries generated by the retrieval executor to be constrained by the fact-verification description object. A cross-platform restricted task carries this object to an external platform, enabling cross-platform requests with fact-level constraints. The cross-platform restricted task obtains privacy-preserving evidence credentials returned by the external platform. These credentials include query execution status, actual coverage, and factual status, allowing the initiator to verify the source and integrity of the credentials and to verify the query execution status, coverage, and correspondence between the external platform and the facts of the case. Specifically, the initiator can confirm whether the query was actually executed through the query execution status, confirm whether the log coverage is sufficient through the actual coverage, and confirm whether the conclusion corresponds to the facts of the case through the case-limited task identifier and factual status, thus achieving verifiable cross-domain evidence collection results.

[0066] By returning the reason for a no-match through a unified retrieval interface, the system can distinguish the specific circumstances of no record, avoiding confusion between query failure and genuine no record, and achieving a clear distinction of the semantics of no record. The evidence evaluator outputs unmet conditions, and the hypothesis state manager outputs conflict results, driving the query rewriter to generate the next round of queries. The stop controller determines the stop conditions based on the factual state and retrieval round information, achieving dynamic adjustment and automatic stopping of the retrieval cycle. The result generator generates fact verification results based on the evidence state diagram, and generates arbitration results based on the fact verification results, the factual state of each factual proposition, and the logical relationship between each factual proposition and the evidence hypothesis. This achieves full traceability of the arbitration result from facts to evidence to conclusion, forming a complete closed-loop processing process from arbitration request parsing, fact verification, cross-platform evidence collection, evidence evaluation, query adjustment to result generation.

[0067] In one embodiment, the arbitration semantic intermediate model is a unified structure that does not depend on a specific arbitration type, and the arbitration semantic intermediate model includes arbitration elements and claim units; The step of generating an intermediate arbitration semantic model based on the arbitration request and the applicant's evidence includes: Arbitration elements are extracted from any form of the arbitration request and the applicant's evidence, including the claim, the requesting party, the opposing party, the subject matter of the dispute, the assertion, the time constraint, the contract rules, and the requested outcome; If the arbitration request includes multiple claims, each claim shall be treated as a claim unit, and the multiple claim units shall share at least one of the claiming subject, the opposing party, the subject of the dispute, and the time constraint. For information that was not extracted from the arbitration elements, a vacancy or candidate entity is generated.

[0068] Specifically, explicit information is extracted from the arbitration request text and the applicant's evidence. Explicit information refers to information that can be directly identified or obtained through formatted parsing from the arbitration request text and the applicant's evidence, distinguishing it from candidate information inferred later. Explicit information includes the claim, the requesting party, the opposing party, the assertion, time constraints, contract rules, the request result, data product name, order number, contract number, interface name, amount, authorized purpose, anomalies, and order details, payment time, delivery batch, API call time, account identifier, screenshot text, and anomaly sample number directly obtained from the applicant's evidence through OCR, table parsing, metadata reading, or log field mapping. Explicit information is directly written into the arbitration semantic intermediate model. For missing or ambiguous information, such as only having a product abbreviation without a product number, or only having a payment screenshot without an order number, candidate entities are generated, and their source and confidence level are recorded for subsequent retrieval and verification. Speculated values ​​must not be treated as confirmed facts.

[0069] The intermediate arbitration semantic model is a unified structure independent of specific arbitration types, containing arbitration elements and claim units. Arbitration elements include claims, claiming parties, counterparties, disputed objects, assertive actions, time constraints, contractual rules, and request outcomes. In the explicit information, the claims, claiming parties, counterparties, assertive actions, time constraints, contractual rules, and request outcomes each correspond to the arbitration elements with the same name. The data product name in the explicit information corresponds to the disputed object; the interface name in the explicit information corresponds to the specific action in the assertive action; the amount in the explicit information corresponds to the specific amount in the request outcome; the authorized use in the explicit information corresponds to the use restriction clause in the contractual rules; and the abnormal phenomena in the explicit information correspond to abnormal situations in the assertive action. Candidate entities are filled in as candidate values ​​for the corresponding arbitration elements. When an arbitration request contains multiple claims, each claim is treated as a separate claim unit, and multiple claim units share the same claiming parties, counterparties, disputed objects, and time constraints. Information in the arbitration elements that is neither explicitly identified nor has a candidate entity generated is recorded as missing, and the intermediate arbitration semantic model is output.

[0070] This invention extracts explicit information from arbitration requests and applicant evidence, generating candidate entities for missing information instead of direct speculation. This allows information not explicitly stated in the arbitration request to be retained in a traceable candidate form, avoiding the misinterpretation of speculative values ​​as confirmed facts. It unifies different disputes into a structure of claims, factual propositions, and evidentiary requirements, enabling subsequent evidence retrieval and fact verification to process any type of arbitration request using a unified data structure, independent of predefined arbitration types, thus achieving universal dispute resolution.

[0071] In one embodiment, the set of evidence hypotheses includes supporting hypotheses, negative hypotheses, and alternative interpretations; The generation of the evidence hypothesis set based on the arbitration semantic intermediate model includes: For each claim unit, the supporting hypothesis, the negative hypothesis, and the alternative explanation are generated simultaneously. Each of the aforementioned assumptions is broken down into machine-verifiable facts to be verified; Configure establishment conditions, denial conditions, evidence requirements, supporting evidence coverage conditions, and rebuttal evidence coverage conditions for each of the facts to be verified, and write the establishment conditions, denial conditions, evidence requirements, supporting evidence coverage conditions, and rebuttal evidence coverage conditions into the fact verification description object.

[0072] Specifically, for each claim unit, three types of hypotheses are generated simultaneously: supporting hypotheses, negative hypotheses, and alternative interpretations. Supporting hypotheses are those that support the applicant's claim, negative hypotheses are those that deny the applicant's claim, and alternative interpretations are other possible explanations besides supporting and negative hypotheses. For example, for a claim of not receiving data after payment, the supporting hypothesis is that payment was made but the supplier failed to deliver as agreed, the negative hypothesis is that payment was unsuccessful or that delivery was made through other channels or that the contract allowed for an extension, and the alternative interpretation is that a delivery system malfunction caused the missing records.

[0073] Each hypothesis is broken down into machine-verifiable facts to be verified. The granularity of this breakdown is based on the fact that each fact to be verified can be completed through a single type of business record or a single restricted query. For example, the hypothesis of non-delivery can be broken down into facts such as successful payment, contract effectiveness, delivery deadline, no valid delivery package generated, no other delivery channels, and no valid extension clauses. Precedence, support, mutual exclusion, and explanatory relationships are established between these facts. Precedence relationships include, for example, payment before delivery is triggered; support relationships include, for example, delivery logs supporting delivery; mutual exclusion relationships include, for example, the same order cannot be both fully delivered and completely non-delivered at the same time; and explanatory relationships include, for example, system failures explaining missing logs.

[0074] For each fact to be verified, configure its establishment conditions, negation conditions, evidentiary requirements, supporting evidence coverage conditions, and rebuttal evidence coverage conditions, and then write these conditions into the fact verification description object. Establishment conditions refer to the conditions that must be met for the fact to be verified to be proven true. Negation conditions refer to the conditions that must be met for the fact to be verified to be disproven. Evidence requirements refer to the type and source of evidence required to prove or disprove the fact. Supporting evidence coverage conditions refer to the standards that the evidence supporting the fact must meet in terms of quantity, source, and type. Rebuttal evidence coverage conditions refer to the standards that the evidence refuting the fact must meet in terms of quantity, source, and type. The fact verification description object records the establishment conditions, negation conditions, required evidence, allowed search scope, and evidentiary sufficiency conditions for the fact to be verified, and is the core constraint file for cross-platform evidence collection.

[0075] This invention generates supporting hypotheses, negative hypotheses, and alternative interpretations for each claim unit, decomposing each hypothesis into machine-verifiable facts to be verified. This eliminates reliance on predefined arbitration types for evidence retrieval, transforming any arbitration claim into factual propositions and evidentiary requirements, thus achieving universal dispute resolution. Each fact to be verified is configured with conditions for establishment, conditions for denial, evidentiary requirements, conditions for coverage of supporting evidence, and conditions for coverage of rebuttal evidence, and written into a fact verification description object. This allows subsequent searches to simultaneously find supporting and rebuttal evidence, avoiding one-way confirmation bias. Furthermore, the fact verification description object serves as the core constraint file for subsequent searches and cross-platform evidence collection, ensuring that fact-level constraints persist throughout the entire search process.

[0076] In one embodiment, the task planner generates a dynamic task queue based on hypothesis discrimination, dependencies, query costs, and permission levels; the task planner generates the dynamic task queue based on the current hypothesis state and evidence gaps, including: Based on the current state of the hypothesis and the evidence gap, determine the hypothesis discrimination of the hypothesis to be verified; Determine the dependencies between factual propositions; The facts in the set of facts to be processed are sorted according to the assumed discrimination, and the first sorting result is obtained. Based on the dependencies, the execution order is adjusted according to the fact that there are prerequisite relationships in the first sorting result to obtain the second sorting result; Based on query cost and permission level, the priorities of the tasks corresponding to each fact in the second sorting result are fine-tuned to generate a dynamic task queue.

[0077] Specifically, the current hypothesis state refers to the current proof status of each hypothesis, including being supported, refuted, unknown, or conflicting. An evidence gap refers to a state where current evidence is insufficient to fully support or refute a hypothesis, including unmet conditions and conflicting results. The task planner extracts unknown and conflicting hypotheses from the current hypothesis state and facts requiring supplementary evidence from the evidence gap, merging both into a set of facts to be processed. For each fact in the set of facts to be processed, the task planner determines its hypothesis discrimination, which indicates the degree to which the fact can distinguish between multiple competing hypotheses. Hypothesis discrimination is determined by reading the fact verification description object corresponding to the fact and obtaining which verification conditions of supporting hypotheses, refutating hypotheses, and alternative interpretations reference the fact. If the fact is referenced by verification conditions of both supporting and refutating hypotheses, it is determined to be a fact that can distinguish between competing hypotheses; if the fact is referenced only by verification conditions of a single hypothesis, it is determined to be a fact that only supports that single hypothesis.

[0078] The task planner also determines the dependencies between factual propositions. Dependencies include prerequisites, supporting relationships, mutual exclusions, and explanatory relationships. The task planner determines the dependencies between factual propositions by traversing the business logic between the facts to be verified. That is, if the occurrence of fact A is a prerequisite for the occurrence of fact B, then A and B have a prerequisite relationship; if the validity of fact A supports the validity of fact B, then A and B have a supporting relationship; if fact A and fact B cannot be valid simultaneously, then A and B have a mutual exclusion relationship; if the occurrence of fact A can explain the absence or anomaly of fact B, then A and B have an explanatory relationship.

[0079] The task planner sorts the facts in the set of facts to be processed based on the hypothesis of discrimination, resulting in a first sort. Then, based on dependencies, the task planner adjusts the execution order of facts with prerequisite relationships in the first sort, resulting in a second sort.

[0080] The task planner calculates a fine-tuning factor for each task in the second ranking result. The fine-tuning factor includes query cost and permission level. Query cost is calculated as follows: For data sensitivity level, a corresponding cost coefficient is assigned based on the data source the task needs to access, which may contain data of varying sensitivity, such as customer information, order information, or trade secrets; for the expected number of records to be queried, a corresponding cost coefficient is assigned based on the expected number of records in the data tables to be scanned; for computational complexity, a corresponding cost coefficient is assigned based on whether the task requires cross-table joins, aggregation calculations, or complex condition matching; for cross-platform collaboration, an additional cost coefficient is added if the task involves external platform calls; for manual approval, an additional cost coefficient is added if manual intervention is required; and for retry costs after failure, a corresponding cost coefficient is assigned based on the time cost and resource consumption of retrying after a failure. The weighted sum of these six cost coefficients yields the query cost of the task.

[0081] The permission level indicates the data sources and operation scope that are authorized for access in the current case. The task planner checks whether the data sources and operations required by each task in the second sorting result are within the current permission level. If the data sources or operations required by a task exceed the current authorization scope, the task must not enter the executable task queue, but instead enter the pending authorization task queue and trigger the new authorization process. For authorized tasks with high data sensitivity, the permission cost coefficient is increased. The task planner adds the query cost coefficient and the permission cost coefficient to obtain a comprehensive cost coefficient, and uses this to fine-tune the priority of executable tasks, generating a dynamic task queue.

[0082] Each dynamic task undergoes scope control before execution; the subject, object, time, fields, and data source must not exceed the scope of the fact-checking description and the case authorization. The task planner generates at least one supporting query and one rebuttal query for each key hypothesis, and supporting and rebuttal evidence adopts the same source reliability and sufficiency standards.

[0083] After each round of retrieval, the task planner reorders the dynamic task queue based on the facts that have been identified, the facts that are still unknown, the conflict locations, and the evidence gaps, prioritizing tasks that can resolve key facts, distinguish multiple hypotheses, fill key gaps, have low costs, low permission risks, and high timeliness risks.

[0084] The task planner of this invention determines the hypothetical discrimination and dependency based on the current hypothesis state and evidence gaps. It generates a dynamic task queue by combining query cost and permission level, enabling retrieval tasks to prioritize those with high discrimination ability, low query cost, and the ability to verify multiple facts simultaneously. This avoids redundant and ineffective queries and resource waste, improving retrieval efficiency. For each key hypothesis, at least one supporting query and one rebuttal query are generated. Supporting and rebuttal evidence are evaluated using the same criteria, avoiding searching only for materials supporting the applicant's claims and reducing one-way confirmation bias. After each round of retrieval, the dynamic task queue is reordered based on ascertained facts, unknown facts, conflict locations, and evidence gaps. This allows evidence gaps to drive subsequent evidence gathering, forming a closed loop from evidence gaps to the next round of queries.

[0085] In one embodiment, the retrieval executor sequentially retrieves tasks to be executed from a dynamic task queue. The retrieval strategy includes deterministic identifier precise retrieval and enhanced retrieval; the dynamic task queue contains at least one task to be executed, and each task to be executed corresponds to one retrieval strategy. The retrieval executor selects a retrieval strategy from the dynamic task queue, including: S2101. Prioritize the precise retrieval of the task to be executed corresponding to the deterministic identifier, and use the results of the precise retrieval as candidate evidence; Deterministic identifiers include order numbers, contract numbers, product numbers, and retrieval credentials. The retrieval executor uses these deterministic identifiers for precise retrieval, searching for records matching the deterministic identifiers in the limited data source through a unified retrieval interface that invokes database read-only queries, business interfaces, and message queue archiving. Results from precise retrieval are directly used as candidate evidence.

[0086] S2102. If the precise retrieval fails or key information is missing, then according to the reason for the miss returned by the unified retrieval interface, the task to be executed corresponding to the enhanced retrieval is selected from the dynamic task queue. The enhanced retrieval includes entity alias fuzzy retrieval, misspelling fuzzy retrieval, semantic vector retrieval, time window progressive expansion, entity association expansion, evidence state graph adjacency expansion and cross-source cross retrieval. Among them, the results of fuzzy search are used as candidate evidence after being verified for entity consistency, time consistency, and source consistency.

[0087] Specifically, the cause of failure is used to distinguish between different situations such as no record, query failure, insufficient permissions, and expired logs. The retrieval executor determines which enhanced retrieval strategy to use based on the type of cause of failure. If the cause of failure indicates that the definitive identifier does not exist in the data source, the retrieval executor uses entity alias fuzzy search or misspelling fuzzy search; if the cause of failure indicates that the disputed time may be inaccurate, the retrieval executor uses progressive time window expansion; if the cause of failure indicates that the log has exceeded its retention period, the retrieval executor switches to the archive, backup system, audit summary, third-party evidence, or related business records. If the cause of failure indicates that key information is missing, the retrieval executor uses entity association expansion or cross-source cross-search. If the cause of failure indicates that the query scope exceeds the authorized boundary, the interface times out, or the data source is unavailable, the retrieval executor does not use enhanced retrieval and triggers permission request or retry. If the cause of failure indicates that the definitive identifier does not exist in the data source, the retrieval executor uses entity alias fuzzy search and misspelling fuzzy search. If the record corresponding to the cause of failure identifier has expired or the log retention period has expired, the retrieval executor uses progressive time window expansion. If the reason for the miss indicates that key information is missing, the retrieval executor enables entity association expansion and cross-source cross-search. If the reason for the miss indicates that the query scope exceeds the authorized boundaries, the retrieval executor does not enable enhanced retrieval and triggers a permission request. If the reason for the miss indicates that the interface timed out or the data source is unavailable, the retrieval executor does not enable enhanced retrieval and triggers a retry.

[0088] The retrieval executor progressively enables enhanced retrieval according to the strategy allowed by the task, rather than directly assuming that relevant records do not exist. Entity alias fuzzy retrieval handles input errors, name changes, or missing numbers by matching edit distance, pinyin or homophones, abbreviations and full names, historical names, field aliases, and local identifiers. Misspelling fuzzy retrieval matches spelling discrepancies caused by input errors. Semantic vector retrieval converts arbitration descriptions, contract terms, log summaries, and communication records into vectors, retrieving semantically similar content within a defined data source and time range. Progressive time window expansion starts from the disputed time window and expands forward or backward at preset steps when no match is found and authorization allows, recording the scope of each expansion. Entity association expansion uses confirmed subjects, objects, or events as seeds to search for associated accounts, certificates, API keys, contracts, orders, delivery batches, interface tasks, and policy alerts within a limited depth. Evidence state graph adjacency expansion utilizes edge relationships in the evidence state graph to find adjacent nodes in the graph starting from existing evidence nodes. Cross-source cross-retrieval uses an identifier obtained from one data source to query other data sources within the same platform; when external platforms are involved, the cross-retrieval requirement is converted into a cross-platform restricted task, which is executed locally by the external platform.

[0089] Results from entity alias fuzzy searches and misspelling fuzzy searches are considered candidate evidence after passing entity consistency, time consistency, and source consistency checks. Entity consistency checks compare the subject information in the results with the subject constraints in the fact-checking description object to determine if they refer to the same entity. Time consistency checks compare the time information in the results with the time window in the fact-checking description object to determine if it falls within the allowed time range. Source consistency checks compare the data source information in the results with the allowed data source range in the fact-checking description object to determine if it comes from an acceptable data source. Only when all three checks pass can the results from a fuzzy search be considered candidate evidence. Results from semantic vector searches also need to pass entity consistency, time consistency, and source consistency checks before being considered candidate evidence. Each search saves the original query, normalized query, strategy type, data source, query time, and result set commitment.

[0090] The query rewriter receives the reasons for a miss, the conditions not met, and conflicting results, and then generates the next round of query expressions. If there is no match, it expands the alias, synonymous action, or time window; if there are too many candidates, it adds constraints on confirmed entities and business stages; if a matched record lacks a key field, it switches to a related data source that can provide that field; if the results conflict, it generates queries that verify the time, status, and subject mapping of each source separately. Each step of the enhanced retrieval retains the basis for rewriting and the relationship between the preceding and following queries, thus explaining how the relevant information was discovered.

[0091] The retrieval executor of this invention prioritizes the precise retrieval of tasks corresponding to deterministic identifiers. Results from precise retrieval are directly used as candidate evidence. If precise retrieval fails or key information is missing, tasks corresponding to enhanced retrieval are selected from the dynamic task queue based on the reason for the miss, rather than directly assuming no relevant records exist. This avoids missing relevant evidence due to missing numbers, aliases, field errors, time discrepancies, or inconsistencies in cross-system identifiers. Enhanced retrieval includes fuzzy retrieval using entity aliases, fuzzy retrieval using misspellings, semantic vector retrieval, progressive expansion of the time window, expansion of entity associations, adjacency expansion of the evidence state graph, and cross-source cross-retrieval. This multi-strategy combination improves evidence recall. Results from fuzzy retrieval are used as candidate evidence after undergoing entity consistency verification, time consistency verification, and source consistency verification, avoiding erroneous associations and controlling erroneous associations while improving recall. The query rewriter generates the next round of query expressions based on the reasons for misses, unmet conditions, and conflicting results. Each rewrite retains the basis for the rewrite and the relationship between previous and subsequent queries, making the retrieval trajectory traceable.

[0092] In one embodiment, after the evidence evaluator creates the evidence node corresponding to the supporting hypothesis, the query rewriter further generates a query for verifying the negative hypothesis or alternative interpretation. After the evidence node corresponding to the supporting hypothesis is created, the hypothesis state manager stores the evidence node in the supporting evidence set according to the support relationship between the evidence node and the factual proposition. The evidence retrieval controller reads the hypothesis identifier corresponding to the confirmed supporting evidence in the supporting evidence set, searches for the negative hypothesis and alternative interpretation corresponding to the supporting hypothesis based on the hypothesis identifier, generates a new query task for the found negative hypothesis and alternative interpretation, and adds the query task to the dynamic task queue.

[0093] The supporting evidence and the rebuttal evidence are evaluated using the same criteria; these criteria include relevance, source reliability, and coverage adequacy. Relevance refers to the degree of relevance of the candidate results to the disputed facts of the case. Source reliability refers to the credibility of the source of the candidate results. Coverage adequacy refers to whether the number, type, and time frame of the candidate results are sufficient to support or refute a factual proposition. The evaluation of supporting evidence and rebuttal evidence follows the same three criteria.

[0094] If the search for counter-evidence directions for the negation hypothesis and the alternative interpretations has not yet reached the preset search coverage requirement, the hypothesis state manager shall not update the fact state to "verified." When supporting evidence meets the sufficient support condition, the search for counter-evidence directions meets the preset search coverage requirement, and there is no valid counter-evidence meeting the sufficient negation condition, the hypothesis state manager shall update the fact state to "verified." The preset search coverage requirement refers to the minimum standard that counter-evidence must meet in terms of quantity, type, and source. This standard is pre-configured in the fact verification description object. Before updating the fact state, the hypothesis state manager checks whether the set of counter-evidence meets the preset search coverage requirement. If the quantity, type, and source of evidence in the set of counter-evidence do not meet the minimum standard pre-configured in the fact verification description object, the hypothesis state manager shall not update the fact state to "verified" and shall keep the fact state in an unknown or conflicting state.

[0095] This invention, after the evidence evaluator creates evidence nodes corresponding to supporting hypotheses, generates queries by the query rewriter to verify negative hypotheses or alternative interpretations. This ensures that evidence retrieval does not stop searching for counter-evidence simply because supporting evidence has been found first, avoiding one-way confirmation bias caused by only searching materials supporting the applicant's claims. Supporting and counter-evidence are evaluated using the same criteria, ensuring that both sides are measured on the same scale and avoiding judgment bias caused by inconsistent standards. If counter-evidence does not meet the preset retrieval coverage requirements, the hypothesis state manager must not update the fact status to "verified," ensuring that fact status updates are based on sufficient two-way verification of supporting and counter-evidence, preventing premature confirmation of facts before sufficient counter-evidence has been retrieved.

[0096] In one embodiment, the query rewriter rewrites the query expression in at least one of the following ways: Query standardization; Alias ​​extension; Time window expansion; Data source switching; Add constraints to confirmed entities; Add business phase constraints; Redirecting can provide the associated data source for key fields; Generate queries that verify the time, status, and subject mappings of each source; The query rewriter generates the next round of queries based on the cause of the miss, the condition not met, or the conflict result, including: If no match is found, query normalization, alias expansion, time window expansion, or data source switching will be triggered. If there are too many candidate results, add constraints on confirmed entities or business stages; If a candidate result lacks a key field, the search will turn to a related data source that can provide the key field. If results from different sources conflict, queries are generated to verify the time, status, and subject mapping of each source separately. After each rewrite, the previous query expression, the rewritten query expression, the reason for the rewrite, and the range change are written into the retrieval status recorder.

[0097] Specifically, the query rewriter receives the reasons for misses from the unified retrieval interface, the unmet conditions from the evidence evaluator, and the conflict results from the hypothesis state manager. Based on these three types of inputs, it generates the next round of query expressions and returns them to the retrieval executor. After each rewrite, the query rewriter records the previous query expression, the rewritten query expression, the reason for the rewrite, and the range change.

[0098] If no match is found, the query rewriter triggers query normalization, alias expansion, time window expansion, or data source switching. Query normalization converts field names and values ​​in the query expression to a uniform format to ensure compatibility with query syntax across different data sources. Alias ​​expansion replaces entity names in the query conditions with the entity's abbreviation, full name, historical name, or association identifier to cover different names for the same entity in different systems. Time window expansion expands the query time range forward or backward by a preset step. Data source switching changes the query target from the current data source to another data source that can provide similar information.

[0099] If there are too many candidate results, the query rewriter adds confirmed entity constraints or business stage constraints. Confirmed entity constraints limit the query scope to entities or objects that have been confirmed through other evidence, reducing irrelevant results. Business stage constraints limit the query scope to a specific business stage, such as the delivery or settlement stage.

[0100] If a candidate result lacks a key field, the query rewriter redirects to a related data source that can provide that key field. The query rewriter identifies the missing field name in the candidate results, searches for other data sources that can provide that field based on the field name, and switches the query target to that related data source.

[0101] If results from different sources conflict, the query rewriter generates separate queries to verify the time, status, and subject mappings for each source. The query rewriter extracts the data source identifier, timestamp, status value, and subject identifier corresponding to each conflicting result, and generates an independent verification query for each source of conflicting results to confirm whether the time accuracy, status validity, and subject correspondence of the records from each source are consistent.

[0102] After the evidence evaluator creates evidence nodes corresponding to supporting hypotheses, the query rewriter generates queries to verify negative hypotheses or alternative interpretations. Based on the hypothesis identifiers corresponding to the confirmed supporting evidence in the supporting evidence set, the query rewriter searches for the corresponding negative hypotheses and alternative interpretations, and generates new query expressions for the found negative hypotheses and alternative interpretations.

[0103] The query rewriter of this invention generates the next round of queries based on the reasons for missing results, unmet conditions, and conflicting results. This allows the retrieval to automatically adjust the query direction and scope based on feedback from the previous round, avoiding repeated and invalid queries. If no match is found, query normalization, alias expansion, time window expansion, or data source switching are triggered to expand or adjust the query scope while maintaining the query intent, avoiding missing evidence due to inconsistent fields, naming differences, or time deviations. If there are too many candidate results, confirmed entity constraints or business stage constraints are added to narrow the query scope and improve retrieval accuracy. If a candidate result lacks a key field, the system switches to a related data source that can provide that key field, ensuring that the retrieval results contain the key information required for verification and avoiding the inability to complete fact verification due to missing fields. If results from different sources conflict, queries are generated to verify the time, status, and subject mapping of each source separately. By verifying each source, the authenticity and accuracy of the conflicting source are confirmed, avoiding erroneous inferences. After each rewrite, the previous query expression, the rewritten query expression, the reason for rewriting, and the changes in scope are saved, making the retrieval trajectory traceable.

[0104] The evidence evaluator assesses each candidate result in the query results. The assessment considers six aspects: relevance to the case, entity consistency, temporal consistency, source reliability, record completeness, and direction of proof. Relevance to the case refers to whether the candidate result is related to the disputed facts of the current case. Entity consistency refers to whether the subject information in the candidate result points to the same entity as the subject constraints in the fact-checking description object. Temporal consistency refers to whether the time information in the candidate result falls within the allowed time window in the fact-checking description object. Source reliability refers to whether the candidate result comes from original records in the business system, a third-party platform, manually uploaded materials, or screenshots; different source types have different levels of reliability. Record completeness refers to whether the candidate result is missing pages, fields, logs, signatures, or verification traces. Direction of proof refers to whether the candidate result supports a hypothesis, refutes a hypothesis, supports alternative interpretations, or is irrelevant to the current proposition.

[0105] The evidence evaluator assigns scores to six aspects, and the scores are weighted and summed to obtain a comprehensive score. The allocation of different weights is pre-configured according to the needs of the case. If the comprehensive score reaches a preset threshold and the source is traceable, the candidate result is determined to meet the evaluation criteria. Candidate results that meet the evaluation criteria are created as evidence nodes, and a relationship is established between the evidence node and the corresponding factual proposition in the facts to be verified in the evidence state diagram. If the evidence supports a factual proposition, a support relationship edge is established; if the evidence negates a factual proposition, a negation relationship edge is established; if the evidence explains an anomaly, an explanation relationship edge is established; if the evidence contradicts existing evidence, a conflict relationship edge is established. Candidate results that do not meet the evaluation criteria are retained in the candidate pool and trigger subject verification tasks, object verification tasks, or supplementary evidence tasks.

[0106] When an evidence node is created, its source, time, involved parties, object of investigation, direction of proof, and degree of credibility are recorded, and then it is linked to the corresponding fact to be verified. If the evidence supports the fact, a supporting relationship is formed; if the evidence refutes the fact, a refutation relationship is formed; if the interpretation of the evidence is unusual, an interpretive relationship is formed; if the evidence contradicts existing evidence, a conflict relationship is formed.

[0107] Assuming the state manager receives evidence nodes, it stores supporting evidence nodes in the supporting evidence set, refutating evidence nodes in the rebuttal evidence set, and records conflicting relationships as conflict states. The state manager checks if the supporting evidence set meets a preset sufficient condition and if the rebuttal evidence set is empty; if so, it updates the fact state to "verified." The state manager also checks if the rebuttal evidence set meets a preset sufficient condition; if so, it updates the fact state to "rejected." If neither the supporting nor rebuttal evidence set meets the preset sufficient condition, it updates the fact state to "unknown." Finally, the state manager checks for conflict states; if present, it updates the fact state to "conflicted." In conflict states, both sides' evidence and source commitments are retained, and no simple majority vote is performed.

[0108] When supporting evidence is found, the state manager assumes it does not immediately terminate, but checks the set of counter-evidence to see if there is evidence that could refute the interpretation. When counter-evidence is found, the state manager assumes it is caused by incorrect subject mapping, time skew, or missing logs. If a hypothesis is sufficiently supported but key counter-evidence has not yet been retrieved, the query rewriter generates queries to verify negative hypotheses or alternative interpretations. If multiple hypotheses cannot be ruled out, the task planner selects the facts that best distinguish these hypotheses as the next target. If a query fails, has insufficient coverage, or the subject mapping is uncertain, a corresponding evidence gap is generated.

[0109] The evidence status diagram simultaneously stores lists of facts to evidence and lists of evidence to facts, enabling bidirectional indexing. From a given fact, one can view all supporting, refutating, and conflicting evidence; from a given piece of evidence, one can trace back to which facts it supports and which claims it influences.

[0110] The evidence evaluator assesses candidate results based on six criteria: relevance to the case, entity consistency, temporal consistency, source reliability, record integrity, and direction of proof. Only candidate results that meet the evaluation criteria are created as evidence nodes. Candidate results that do not meet the criteria are retained in the candidate pool and trigger verification tasks, ensuring that the evidence entering the evidence state graph has sufficient credibility and relevance, and preventing low-quality evidence from affecting factual judgment. The evidence state graph simultaneously maintains lists of facts to evidence and evidence to facts. From a given fact, one can view all supporting, disproving, and conflicting evidence; from a given piece of evidence, one can trace back to which facts it supports, enabling bidirectional traceability between evidence and facts. The state manager updates the fact status to verified, disproving, unknown, or conflicting based on support, disproving, and conflicting relationships. When supporting evidence appears, it checks for counter-evidence; when counter-evidence appears, it checks the validity of the counter-evidence, avoiding one-way confirmation bias and ensuring that the fact status is based on bidirectional verification of supporting and disproving evidence.

[0111] In one embodiment, the stop controller determines whether the stop condition is met based on the fact status output by the hypothesis state manager and the retrieval round information output by the retrieval state recorder. If met, the stop controller commands the retrieval executor to stop the retrieval, and outputs the stop reason and incomplete facts. The fact status includes four values: confirmed, denied, unknown, and conflicting. The retrieval round information includes the number of query rounds executed, the identifier of each query round, the execution time of each query round, and the number of hit results for each query round. The stop condition includes at least one of the following: The key facts meet the criteria for sufficient evidence; that is, all facts to be verified have been confirmed or refuted, and the chain of evidence is complete.

[0112] Both supporting and counter-evidence meet the preset retrieval coverage requirements; that is, the retrieval in both the supporting and counter-evidence directions has been completed, and the supporting and counter-evidence meet the minimum standards pre-configured in the fact-checking description object in terms of quantity, type, and source.

[0113] No new valid evidence was obtained in consecutive preset rounds; that is, no new evidence nodes were created in multiple consecutive rounds of retrieval. The preset rounds are configured during system initialization.

[0114] The maximum number of query rounds, time limit, or resource limit has been reached; that is, the number of query rounds executed has reached the preset maximum value, the total retrieval time has reached the preset time limit, or the system resource consumption has reached the preset threshold.

[0115] Subsequent actions require additional authorization; that is, the data source or operation required for the task to be performed exceeds the current case's permission scope.

[0116] There are contractual ambiguities or evidentiary conflicts that require human interpretation; that is, there are multiple reasonable interpretations of the contract terms, or there are inconsistencies between evidence from multiple sources that cannot be automatically resolved.

[0117] Specifically, the stop controller checks whether all facts to be verified in the fact status have reached the verified or refuted state; whether the supporting evidence set and the rebuttal evidence set both meet the preset retrieval coverage requirements; whether the number of consecutive rounds without new evidence in the retrieval status recorder has reached a preset value; whether the total number of query rounds in the retrieval status recorder has reached a preset maximum value, whether the total retrieval time has reached a preset time limit, and whether the system resource consumption has reached a preset threshold; whether the permissions required for the currently pending task exceed the scope of case authorization; and whether there are any contractual ambiguities or evidence conflicts marked as requiring manual interpretation in the evidence status diagram. If any of the above checks is true, the stop controller determines that the stop condition has been met.

[0118] If the stopping conditions are met, the stop controller commands the retrieval executor to stop the retrieval and outputs the stop reason and incomplete facts. The stop reason refers to the specific stop condition that triggers the stop, i.e., one or more of the above checks that result in "yes". Incomplete facts refer to the facts to be verified that could not be verified due to the stop retrieval. The stop controller extracts facts with unknown or conflicting states from the fact states as incomplete facts and outputs the identifiers and current states of these facts.

[0119] The stop controller of this invention determines whether stop conditions are met based on the factual status and retrieval round information, providing a clear stop mechanism for the retrieval loop and avoiding infinite loops. Stop conditions include: key facts meeting the criteria for sufficient evidence; both supporting and counter-evidence meeting preset retrieval coverage requirements; no new valid evidence obtained for consecutive preset rounds; reaching the maximum query round, time limit, or resource limit; subsequent actions requiring additional authorization; and the existence of contractual ambiguities or evidentiary conflicts requiring manual interpretation. These conditions cover various stop scenarios such as sufficient evidence, resource exhaustion, insufficient permissions, and the need for manual intervention, ensuring the retrieval process terminates under reasonable conditions. The stop controller outputs the stop reason and incomplete facts, making the stop decision traceable and providing reviewers with clear directions for supplementary evidence and the basis for stoppage.

[0120] In one embodiment, when the fact to be verified is indicated by the fact verification description object as requiring cross-platform evidence collection, a cross-platform restricted task is generated. The cross-platform restricted task carries multiple items from the following: the fact verification description object, the case-limited task identifier, the allowed retrieval strategy range, the maximum time extension range, the maximum association depth, and the allowed output fields. The case-restricted task identifier is generated based on the case identifier, fact identifier, collaboration platform identifier, task sequence number, and random factor. This identifier can only be used within the specified case, specified facts, and specified validity period. This allows cross-platform restricted tasks to be sent to external platforms.

[0121] After receiving a cross-platform restricted task, the external platform reads the allowed retrieval strategy range, maximum time extension range, and maximum association depth from the task, and converts the restricted task into a local query. The external platform executes the query according to the read allowed retrieval strategy range, which is limited to the allowed retrieval strategy types. The external platform executes the query according to the read maximum time extension range, which is limited to the allowed time window extension range. The external platform executes the query according to the read maximum association depth, which is limited to the allowed number of association hops. The external platform outputs the results according to the read allowed output fields, which are limited to the allowed output data types. The external platform records the query execution status and actual coverage. The query execution status includes whether the query was successfully executed, the query start time, and the end time. The actual coverage includes the actual data source of the query, the actual time range of the query, and the actual number of records scanned. The external platform generates privacy evidence credentials after performing digest extraction, anonymized feature calculation, or protected joint calculation according to the disclosure policy. The privacy evidence credential includes multiple items from the following: case-limited task identifier, factual status, query execution status, actual coverage, evidence type summary, query condition commitment, source record set commitment, calculation algorithm and parameter version, generation time, and platform signature. After the evidence retrieval controller verifies the privacy evidence credential, it writes the privacy evidence credential as an evidence node into the evidence state graph. In the evidence state graph, the privacy evidence credential is associated with the fact proposition node corresponding to the fact identifier and is not used for other fact propositions.

[0122] Specifically, after receiving the privacy evidence credential returned by the external platform, the evidence retrieval controller verifies the privacy evidence credential. Verification includes checking whether the case-limited task identifier is consistent with the one sent and has not expired, whether the platform signature is valid, whether the query conditions are consistent with the original task, whether the actual coverage meets the sufficient evidence conditions in the fact-checking description object, and whether the calculation algorithm and parameter version are within the allowed range. If the verification passes, the privacy evidence credential is written as an evidence node into the evidence state diagram. In the evidence state diagram, the privacy evidence credential is associated with the fact proposition node corresponding to the fact identifier in the case-limited task identifier and is not used for other fact propositions. If the verification fails, the privacy evidence credential is discarded and the reason for the failure is recorded.

[0123] This invention's cross-platform restricted task includes a fact-verification description object, a case-limited task identifier, a range of permitted retrieval strategies, a maximum time extension range, a maximum association depth, and permitted output fields. It limits the verification conditions, permitted retrieval methods, and permitted output range of the facts to be verified to the scope specified by the fact-verification description object. External platforms can only execute queries and output results within this scope, achieving cross-platform evidence collection under minimal necessary constraints, avoiding boundless searches by external platforms, and ensuring that original data does not leave the domain. The privacy evidence credential includes a case-limited task identifier, factual status, query execution status, actual coverage, evidence type summary, query condition commitment, source record set commitment, calculation algorithm and parameter version, generation time, and platform signature. This enables the initiator to verify the source and integrity of the credential and, based on the query execution status, actual coverage, and case-limited task identifier, verify the query execution status and coverage declared by the external platform and their correspondence with the facts of the case. After the evidence retrieval controller verifies the privacy evidence credential, it writes the privacy evidence credential as an evidence node into the evidence status graph. It is only associated with the fact proposition node corresponding to the fact identifier and is not used for other fact propositions. This ensures that the cross-platform evidence collection results are only used for their corresponding fact propositions and avoids the cross-platform returned results being reused in other cases or other facts.

[0124] When the fact to be verified is indicated by the fact-checking description object as requiring cross-platform forensics, a cross-platform privacy-based joint forensics process is executed. For example... Figure 3 As shown: Step 1: The applicant submits the arbitration application and the applicant's evidence through the arbitration portal of Exchange A.

[0125] Step 2: After receiving the arbitration application and the applicant's evidence, Exchange A generates an intermediate arbitration semantic model based on the arbitration request and the applicant's evidence. Based on the intermediate arbitration semantic model, it generates a set of evidence hypotheses, breaks down each hypothesis into facts to be verified and fact verification description objects, and inputs the fact verification description objects and the current hypothesis status into the evidence retrieval controller to generate an evidence collection strategy.

[0126] Step 3: The retrieval executor in the evidence retrieval controller of Exchange A executes the query on the local data source, and the evidence evaluator evaluates the query results.

[0127] Step 4: When the task planner determines that local data is insufficient to verify a hypothesis, it generates a cross-platform restricted task through the arbitration portal of Exchange A and sends it to the collaborative evidence collection module of Exchange B. The cross-platform restricted task carries the fact-verification description object, the case-limited task identifier, the proof direction required by the current search process, the scope of allowed search strategies, the maximum time extension range, the maximum association depth, and the allowed output fields.

[0128] Step 5: After receiving the cross-platform restricted task, the local verification agent in Exchange B's collaborative evidence collection module verifies the task, converts it into a local query, records the query execution status and actual coverage, and generates privacy evidence credentials after executing the query according to the disclosure strategy. The privacy evidence credentials include the case-limited task identifier, factual status, query execution status, actual coverage, evidence type summary, query condition commitment, source record set commitment, calculation algorithm and parameter version, generation time, and platform signature. Original logs and unauthorized fields are always retained on Exchange B.

[0129] Step 6: Exchange B's collaborative evidence collection module submits the privacy evidence credentials to Exchange A.

[0130] Step 7: The credential verification unit in the evidence retrieval controller of Exchange A receives and verifies the privacy evidence credential. Verification includes checking whether the case-limited task identifier is consistent with the one sent and has not expired, whether the platform signature is valid, whether the query conditions are consistent with the original task, whether the actual coverage meets the sufficient evidence conditions, and whether the algorithm and parameter versions are within the allowed range. After successful verification, the facts are updated to verified, denied, unknown, or conflicting based on the factual status in the privacy evidence credential, and the credential is written as a restricted evidence node into the evidence status graph. In the evidence status graph, the privacy evidence credential is only associated with the propositional node corresponding to its factual identifier.

[0131] Step 8: When fact verification requires joint calculation using local evidence from Exchange A and privacy-related evidence credentials returned by Exchange B, the evidence retrieval controller of Exchange A generates a joint calculation task based on the fact verification description object and sends the joint calculation task to the joint calculation module. The joint calculation task defines the fact identifier to be verified, the scope of evidence allowed to participate in the calculation, the calculation algorithm and parameter version, and the allowed output result types.

[0132] Step 9: The joint calculation module performs joint calculations without outputting the original local data from Exchange A and the original data from Exchange B, generates a joint calculation result, and returns the joint calculation result to the evidence retrieval controller of Exchange A. The evidence evaluator evaluates the joint calculation result. If the evaluation is successful, it is created as an evidence node and written into the evidence state graph. It is assumed that the state manager updates the fact state of the corresponding fact accordingly.

[0133] Step 10: The stop controller determines whether the stop condition is met based on the fact state output by the hypothesis state manager and the retrieval round information output by the retrieval state recorder. If the stop condition is met, the stop controller outputs a stop command to the retrieval executor and submits the stop reason, incomplete facts, evidence state diagram and fact state of each fact proposition to the result generator.

[0134] Step 11: The result generator generates a fact verification result based on the evidence state diagram, and generates an arbitration result based on the fact verification result, the fact state of each factual proposition in the evidence state diagram, and the logical relationship between each factual proposition and the evidence assumption. The arbitration result includes a tendency to support, a tendency not to support, partial support, or insufficient evidence. The report generation module organizes the fact verification result, the arbitration result, and their evidentiary basis into an arbitration report, which is displayed and archived by Exchange A.

[0135] The arbitration report is generated through the report generation module, and the process is as follows: After the evidence retrieval controller stops the retrieval, the result generator generates the fact verification result and arbitration result based on the evidence state diagram. The evidence retrieval controller inputs the structured results—including the arbitration semantic intermediate model, the evidence hypothesis set, the fact verification result, the arbitration result, the retrieval process work record from the retrieval state recorder, the evidence state diagram, and privacy evidence vouchers—into the report generation module. The report generation module organizes these structured results into an arbitration report. The arbitration report includes the arbitration result and its evidentiary basis.

[0136] The arbitration report comprises four layers: Understanding the Claim, Assumptions and Facts, Retrieval Trajectory, Evidence and Counter-evidence, and Cross-Domain Evidence. The Understanding the Claim layer explains how the arbitration claim was understood and what key information was extracted. The Assumptions and Facts layer lists the generated assumptions and their corresponding facts, indicating whether they have been verified, refuted, are unknown, or conflicting. The Retrieval Trajectory layer demonstrates the query rewriting and strategy switching process, with sensitive fields hidden. The Evidence and Counter-evidence layer lists the evidence for supporting and opposing arguments, respectively. The Cross-Domain Evidence layer lists the privacy-preserving evidence returned from external platforms and their verification results.

[0137] The logic for generating the arbitration result is as follows: The result generator reads the verified, denied, unknown, or conflicting states of each factual proposition from the evidence status diagram, as well as the logical relationships established between the facts through the facts to be verified. If all the key facts required for a certain hypothesis have been verified and there is no sufficient counter-evidence to refute it, the result generator outputs a tendency to support it. If a key fact is denied or the opposite fact has been verified, the result generator outputs a tendency to not support it. If the core facts are partially true but still lack key elements, the result generator outputs partial support. If the key facts are still unknown or the conflict cannot be resolved, the result generator outputs insufficient evidence. The report distinguishes between ascertained facts and facts that still need to be supplemented, explaining what evidence is missing for the facts to be supplemented, suggesting where to supplement them, and what conclusions they might affect. The report generation module organizes and displays the arbitration result and its evidentiary basis, but does not replace the arbitrator's final legal judgment. After the reviewer confirms, returns for supplementary evidence, or makes corrections, the reasons for the corrections and the versions before and after are still included in the archive.

[0138] The archive is organized into a four-layer structure: case, facts, evidence, and calculation. The case layer stores the request and subject information; the facts layer stores the facts to be verified and their status changes; the evidence layer stores the original record index, event vectors, evidence status diagrams, and evidence gap nodes; and the calculation layer stores rule versions, weight templates, cross-domain results, and reports. A bidirectional index is established between each layer, allowing users to view the entire processing process from a case and to see which facts and conclusions a piece of evidence supports. Supplementary materials, re-examination of evidence, or manual corrections all generate new versions without overwriting old content. Ordinary applicants can view the conclusions and legally disclosable summaries, reviewers can view complete evidence within their authorized scope, and cross-exchange participants can only view their own requests and outputs. Key actions such as case creation, querying, cross-domain interaction, report publication, and review all generate audit records and hash commitments. The commitment values ​​at key stages are linked to a third-party trusted timestamp or consortium blockchain. Viewing, exporting, and cross-domain operations of evidence are performed according to case authorization. When manually confirming, correcting, or returning evidence for supplementation, the operator, time, and reason are recorded, without deleting existing versions or operation traces.

[0139] This invention also provides an anomaly handling and security control mechanism. Specifically, interface timeouts, network interruptions, or temporary permission failures are considered evidence-gathering anomalies. The task enters a retry queue and retains the reason for failure, without concluding that the relevant record does not exist. When a query is successful but no record is found, the log retention period and query coverage are checked. Only when the conditions are met is the absence of a record used as input for factual judgment. Missing key evidence creates an evidence gap and suspends definitive conclusions; missing auxiliary evidence only reduces the credibility of the path. When inconsistent record hashes, time inversions, or subject mapping conflicts are found, the affected evidence is placed in an isolation area, the original version is retained, and the relevant facts are marked as conflicting or pending review in the evidence status diagram, and the review personnel are notified. Time inversion refers to the time order shown by the evidence not conforming to business common sense or contract procedures, such as the delivery time being earlier than the payment time. Subject mapping conflicts refer to the same evidence corresponding to inconsistent subjects, such as the same account being mapped to the applicant and the counterparty. When manually confirming, correcting, or returning evidence for supplementation, existing versions and operation traces are not deleted.

[0140] The following seven examples illustrate how a single evidence retrieval controller handles different types and complex arbitration requests. An arbitration request is a formal application filed by one party in a dispute resolution process, and the dispute type is the category of content disputed in the arbitration request. Dispute types include multi-entity data ownership confirmation, failure to deliver as agreed, use beyond scope, secondary circulation of data across exchanges, distribution of data revenue, unauthorized access to government data, and substandard data quality. The dispute type is optional supplementary information; when the arbitration request includes a dispute type, the evidence retrieval controller loads an initial evidence template based on the dispute type; when the arbitration request does not include a dispute type, it generates an initial evidence template based on the arbitration semantic intermediate model. Ultimately, the retrieval process is driven by the arbitration semantic intermediate model transformed from the arbitration request, factual propositions, and the current factual state; the dispute type is not a necessary condition for executing the retrieval process. The evidence retrieval controller does not execute a fixed process for each type of dispute, but rather uniformly converts the arbitration request into an arbitration semantic intermediate model and a set of evidence assumptions, and then dynamically selects retrieval tools, rewrites queries, and updates the factual state based on actual hit results.

[0141] Example 1: Disputes over ownership of the same data among multiple entities: The arbitration request involves two parties, A and B, each claiming corresponding data rights to the same disputed data. Party A submitted data registration records, original collection records, and data fingerprints, asserting that it collected and registered the data first. Party B submitted data registration records, authorization documents, and data processing records from another platform, claiming that it acquired corresponding rights through independent collection, legal authorization, or substantial processing. The core of the dispute lies in whether the data claimed by the two parties is the same data, and whether the data source, formation time, authorization chain, and processing contribution on which their respective claims are based are valid.

[0142] The request parsing module extracts the requesting party, the opposing party, the disputed data identifier, data content characteristics, collection time, registration time, source entity, scope of authorization, and processing method from the materials submitted by both parties, generating an intermediate semantic model for arbitration. The hypothesis generation unit generates a set of evidence hypotheses: the hypothesis supporting subject A's claim is that the disputed data was legally obtained by subject A first, and subject B's data originated from subject A; the negative hypothesis is that subject B obtained the same or substantially the same data through independent collection or legal authorization; alternative interpretations are that both parties' data originated from the same public source, or that subject B only processed the basic data to form independent rights. Each hypothesis is broken down into facts of data identity, facts of the first formation time, facts of the original source, facts of collection behavior, facts of registration time, facts of the authorization chain, facts of processing contribution, and facts of limitations on rights, and fact verification descriptions are generated for each.

[0143] The evidence retrieval controller first performs precise and similarity searches based on data identifiers, data fingerprints, field structures, sample characteristics, and formation time, and correlates these searches with collection logs, registration records, authorization documents, data flow records, and processing task records. When registration records or source records from external platforms are involved, a cross-platform restricted task is generated, and the external platform returns privacy-protected evidence credentials. The evidence evaluator assesses data identity, record source, temporal continuity, authorization chain integrity, and processing contribution, assuming the state manager updates the factual status accordingly. If only the data content is identical or highly similar, an exclusive right is not directly established for a particular entity; only when data identity, source dependency, and corresponding rights basis all meet the conditions for sufficient evidence will an arbitration result that tends to support the entity's claim be output. If both parties have legitimate sources, or if the processing contribution and rights boundaries are still unclear, the output indicates that rights may coexist, partial support, or insufficient evidence, and lists the source proof, authorization documents, or processing records that need to be supplemented.

[0144] Example 2: Dispute over non-delivery in a single transaction: The arbitration claim rests on the buyer's assertion that no data was obtained after payment. The applicant's evidence consists of payment screenshots and product abbreviations submitted by the buyer, but no accurate order number was provided.

[0145] The request parsing module identifies the claim, payment time, amount, buyer, and product abbreviation from the payment screenshots and product abbreviations submitted by the buyer, and outputs an arbitration semantic intermediate model. The hypothesis generation unit generates a set of evidence hypotheses based on the arbitration semantic intermediate model. Supporting hypotheses include successful payment and triggered delivery obligation, and the supplier failing to complete effective delivery. Negative hypotheses include payment not being credited, delivery already made offline or through other interfaces, and the contract allowing for an extension. Alternative explanations include a delivery system malfunction causing missing records. Each hypothesis is broken down into facts to be verified, and fact verification description objects are generated, including facts of successful payment, contract effectiveness, delivery deadline expiration, effective delivery package generation, offline delivery voucher, extension clause, and system malfunction work order. The fact verification description objects and the current hypothesis status are input into the evidence retrieval controller.

[0146] The retrieval executor in the evidence retrieval controller first uses fuzzy matching of payment time, amount, and requesting entity to obtain settlement transaction records and candidate order numbers. The task planner determines subsequent query tasks based on the candidate order numbers. The retrieval executor associates the candidate order numbers with the contract system and delivery system. The initial query by product abbreviation yields no match. The query rewriter performs semantic and relational searches using the product's historical name and delivery batch based on the reason for the match. The evidence evaluator evaluates the search results and finds no valid delivery package records. The retrieval executor continues to query offline delivery vouchers, interface token issuance records, delay clauses, and system fault work orders. The evidence evaluator evaluates the above query results and finds no valid delivery-related records. The assumption state manager updates the fact status based on the evaluation results. Only when log coverage is sufficient and negative queries find no valid deliveries will the assumption state manager update the non-delivery fact to confirmed. The result generator outputs the arbitration result.

[0147] Example 3: Dispute over exceeding the scope of use in a single exchange: The arbitration request stems from the data provider's claim that the purchaser used data intended solely for statistical analysis for model training. The applicant's evidence includes usage restriction clauses in the contract, the authorization period, the claimant's identity, and product identification.

[0148] The request parsing module extracts usage restrictions, authorization periods, requesting parties, and product identifiers from the contract, outputting an intermediate arbitration semantic model. The hypothesis generation unit generates a set of evidence hypotheses based on this intermediate model. Supporting hypotheses include actual training execution using disputed data. Negative hypotheses include misclassification of the task, failure to actually execute training, and the existence of supplementary authorization. Alternative interpretations include the use of other datasets in the training task. Each hypothesis is broken down into facts to be verified, generating fact-verification description objects, including facts of actual execution of the training task, use of disputed data in training, correct task classification, and the existence of supplementary authorization. The fact-verification description objects and the current hypothesis state are input into the evidence retrieval controller.

[0149] The retrieval executor in the evidence retrieval controller first performs a precise query by task type, then performs a semantic search on the task name, script description, and log summary, and expands the association through API keys, sandbox accounts, and dataset mounting records. The evidence evaluator evaluates the retrieval results and matches training tasks. After the assumption state manager updates the actual execution fact of the training task to verified, the task planner generates a query task to verify the negative hypothesis. The retrieval executor continues to query the task execution status, input data fingerprint, whether the blocking alarm is effective, and the supplementary agreement. The evidence evaluator evaluates the above query results. The assumption state manager updates the fact state based on the evaluation results. Only when the training is actually executed, the input data fingerprint is related to the disputed data, and there is no valid supplementary authorization, will the assumption state manager update the out-of-scope use fact to verified. The result generator outputs the arbitration result.

[0150] Example 4: Disputes over the secondary circulation of data across exchanges: The arbitration request stems from Exchange A's claim that Exchange B possesses data products that appear to be identical to the data provided by Exchange A. The applicant's evidence consists of Exchange A's data registration records and information regarding the allegedly identical data products from Exchange B.

[0151] The request parsing module breaks down the claim into three facts to be verified: whether Exchange B has a listing that meets the specified characteristics, whether the listing time is later than the registration time of Exchange A, and whether the listing entity has re-authorization. Assume the generation unit generates fact verification description objects for each of the three facts to be verified.

[0152] When the task planner determines that local data is insufficient to verify the existence and timing of a listing on Exchange B, it generates three cross-platform restricted tasks and sends them to Exchange B. These cross-platform restricted tasks carry a fact-verification description and a case-limited task identifier. The local verification agent in Exchange B's collaborative evidence collection module converts the restricted tasks into local queries, executes the queries, generates three privacy-preserving evidence credentials, and returns them to Exchange A. For data similarity verification, joint computation is initiated only when the digest is insufficient for verification. The privacy-preserving evidence credentials record the feature algorithm, parameters, input commitment, and similarity output. The credential verification unit in Exchange A receives and verifies the three privacy-preserving evidence credentials. Upon successful verification, each credential is written as a restricted evidence node into the evidence state graph.

[0153] Assume the state manager updates facts based on the fact status in the privacy evidence credential. If a similarity fact is updated to be verified but the re-authorization log coverage is insufficient, the re-authorization fact remains unknown and triggers supplementary verification. Assume the state manager cannot directly determine illegal resale based solely on high similarity. The result generator outputs the arbitration result.

[0154] Example 5: Disputes over the distribution of data revenue: The arbitration request stems from the data provider's claim that the platform failed to pay revenue sharing as stipulated in the contract. The applicant's evidence is the contract.

[0155] The request parsing module extracts the revenue sharing ratio, settlement cycle, and deductions from the contract, outputting an intermediate arbitration semantic model. The hypothesis generation unit generates a set of evidence hypotheses based on this intermediate model. Supporting hypotheses include that the contractually agreed revenue sharing ratio and settlement cycle have been met, and that the platform has failed to pay as agreed. Negative hypotheses include that a settlement system malfunction caused payment delays, that the platform has paid all or part of the revenue sharing, and that deductions resulted in a reduction in the amount payable. Each hypothesis is broken down into facts to be verified, generating fact verification description objects, including facts regarding contract validity, revenue sharing ratio, settlement cycle, transaction amount, refund, taxes, fund transfer, payable amount calculation, actual payment, and system malfunction work order. The fact verification description objects and the current hypothesis status are input into the evidence retrieval controller.

[0156] The retrieval executor in the evidence retrieval controller is linked to order transaction amounts, refunds, taxes, and fund transfer logs. The evidence evaluator evaluates the query results. The task planner generates query tasks based on the evaluation results, calculating the payable amount and due date for each transaction. After the retrieval executor executes the query, the evidence evaluator evaluates the calculation results. The state manager updates the fact status. If the transaction fact is confirmed, the settlement period has expired, and there is no corresponding transfer record, an evidence gap forms between the payable amount and the actual payment amount in the evidence status diagram, and the result generator outputs a biased support. If there are abnormal work orders or partial payments in the settlement system, the state manager updates the relevant facts to confirmed, and the result generator outputs partial support and lists the difference. The result generator outputs the arbitration result.

[0157] Example 6: Disputes over unauthorized access to government data: The arbitration request stems from Department A's claim that Department B accessed sensitive government data beyond its authorized scope. The applicant's evidence is its authorization strategy.

[0158] The request parsing module reads the interface scope, field scope, access period, and purpose from the authorization policy and outputs an arbitration semantic intermediate model. The hypothesis generation unit generates a set of evidence hypotheses based on the arbitration semantic intermediate model. Supporting hypotheses include: Department B accessed sensitive government data beyond its authorized scope; negative hypotheses include: Department B accessed within its authorized scope; key sharing caused incorrect subject mapping; and access occurred within the authorized period. Each hypothesis is broken down into facts to be verified, and fact verification description objects are generated, including authorization policy facts, access log facts, facts exceeding interface scope, facts exceeding field scope, facts exceeding the authorization period, key sharing facts, and subject correspondence facts. The fact verification description objects and the current hypothesis state are input into the evidence retrieval controller.

[0159] The retrieval executor in the evidence retrieval controller uniformly maps institution certificates, accounts, and interface keys, reads the interface scope, field scope, access period, and purpose from the authorization policy, and then compares them sequentially with the API gateway logs. The evidence evaluator evaluates the query results. For calls exceeding the field scope or authorization period, the evidence evaluator generates a violation event edge and binds it to the specific time, interface, and response result. For calls where the subject is uncertain due to key sharing, the evidence evaluator lowers the subject association score and creates a supplementary evidence task. Assuming the state manager updates the factual state based on the evaluation results, the result generator outputs a tendency to support the claim only when both the requesting subject and the unauthorized conditions are updated to be verified. The report generation module then organizes the arbitration result and its evidentiary basis into an arbitration report.

[0160] Example 7: Disputes over substandard data quality: The arbitration request is based on the buyer's claim that the delivered data is missing fields or contains distorted values. The applicant's evidence is the contract.

[0161] The request parsing module extracts quality indicators such as completeness, accuracy, and update frequency, as well as acceptance methods, from the contract, and outputs an intermediate arbitration semantic model. The hypothesis generation unit generates a set of evidence hypotheses based on the intermediate arbitration semantic model. Supporting hypotheses include substandard delivered data quality. Negative hypotheses include acceptable data quality, quality issues caused by the buyer's parsing error, and quality issues occurring during transmission. Alternative explanations include discrepancies in test results due to inconsistent quality inspection program versions. Each hypothesis is broken down into facts to be verified, and fact-checking description objects are generated, including contract quality indicator facts, delivery batch facts, quality inspection task facts, source data quality issue facts, transmission damage facts, buyer's parsing error facts, and testing program version facts. The fact-checking description objects and the current hypothesis status are input into the evidence retrieval controller.

[0162] The retrieval executor in the evidence retrieval controller retrieves delivery batches, quality inspection tasks, parsing logs, and buyer-related anomaly samples. The task planner generates query tasks to re-execute agreed-upon inspections on the same batch. After the retrieval executor executes the query, the evidence evaluator evaluates the re-test results. The evidence evaluator distinguishes between source data quality issues, transmission corruption, and buyer parsing errors. The evidence evaluator writes the inspection program version, sample range, and result hash into the evidence chain. The assumption state manager updates the fact state based on the evaluation results. If the re-test results are below the contract threshold and the problem occurred before delivery, the result generator outputs a supportive view. If only some indicators are non-compliant or the causes of liability are mixed, the result generator outputs a partially supportive view and lists each indicator and the path of liability. The result generator outputs the arbitration result.

[0163] The data circulation and transaction dispute arbitration device provided by the present invention is described below. The data circulation and transaction dispute arbitration device described below can be referred to in correspondence with the data circulation and transaction dispute arbitration method described above.

[0164] This invention also provides a data circulation transaction dispute arbitration device, referring to... Figure 4 As shown, it includes the following modules: The receiving module 310 is used to receive arbitration requests and applicant evidence, and generate an arbitration semantic intermediate model based on the arbitration requests and applicant evidence; Arbitration module 320 is used to generate a set of evidence hypotheses based on the arbitration semantic intermediate model, split each hypothesis in the set of evidence hypotheses into facts to be verified and fact verification description objects, input the fact verification description objects and the current hypothesis state into the evidence retrieval controller, and obtain the arbitration result; The evidence retrieval controller includes a task planner, a retrieval executor, an evidence evaluator, a hypothesis state manager, a query rewriter, a retrieval state recorder, a stop controller, and a result generator; the hypothesis state manager maintains an evidence state graph; the following operations are performed in the evidence retrieval controller: The task planner generates a dynamic task queue based on the current hypothesis state and evidence gaps. The retrieval executor selects a retrieval strategy from the dynamic task queue and generates a restricted query. It executes the restricted query through a unified retrieval interface and returns the local query results and the reasons for the miss. If the fact to be verified is indicated by the fact verification description object as requiring cross-platform evidence collection, then a cross-platform restricted task is generated and sent to an external platform, and the privacy evidence certificate returned by the external platform is received. The evidence evaluator evaluates the candidate results in the local query results, creates evidence nodes for candidate results that meet the evaluation criteria, and verifies the privacy evidence credentials, creating restricted evidence nodes for privacy evidence credentials that pass the verification. In the evidence state graph, the evidence nodes and the restricted evidence nodes are respectively associated with the corresponding factual propositions in the facts to be verified, and the unmet conditions are output. The hypothesis state manager updates the fact state according to the relationship between the evidence node and the fact proposition, and feeds back the fact state to the retrieval executor to output the conflict result; The query rewriter generates the next round of query based on the cause of the miss, the unmet condition, or the conflict result, and returns it to the retrieval executor. The stop controller determines whether the stop condition is met based on the fact status and the retrieval round information output by the retrieval status recorder. If the condition is met, it commands the retrieval executor to stop the retrieval and outputs a stop command, the reason for the stop, and the unfinished facts. The result generator responds to the stop command output by the stop controller, generates a fact verification result based on the evidence state diagram, and generates an arbitration result based on the fact verification result, the fact state of each fact proposition in the evidence state diagram, and the logical relationship between each fact proposition and the evidence hypothesis.

[0165] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0166] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0167] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for arbitrating disputes related to data circulation and transactions, characterized in that, include: Receive the arbitration request and the applicant's evidence, and generate an intermediate semantic model of arbitration based on the arbitration request and the applicant's evidence; An evidence hypothesis set is generated based on the arbitration semantic intermediate model. Each hypothesis in the evidence hypothesis set is split into facts to be verified and fact verification description objects. The fact verification description objects and the current hypothesis state are input into the evidence retrieval controller to obtain the arbitration result. The evidence retrieval controller includes a task planner, a retrieval executor, an evidence evaluator, a hypothesis state manager, a query rewriter, a retrieval state recorder, a stop controller, and a result generator; the hypothesis state manager maintains an evidence state graph; the following operations are performed in the evidence retrieval controller: The task planner generates a dynamic task queue based on the current hypothesis state and evidence gaps. The retrieval executor selects a retrieval strategy from the dynamic task queue and generates a restricted query. It executes the restricted query through a unified retrieval interface and returns the local query results and the reasons for the miss. If the fact to be verified is indicated by the fact verification description object as requiring cross-platform evidence collection, then a cross-platform restricted task is generated and sent to an external platform, and the privacy evidence certificate returned by the external platform is received. The evidence evaluator evaluates the candidate results in the local query results, creates the candidate results that meet the evaluation criteria as evidence nodes, and verifies the privacy evidence credentials, creating the verified privacy evidence credentials as restricted evidence nodes. In the evidence state diagram, the evidence nodes and the restricted evidence nodes are respectively associated with the corresponding factual propositions in the facts to be verified, and the unmet conditions are output. The hypothesis state manager updates the fact state according to the relationship between the evidence node and the fact proposition, and feeds back the fact state to the retrieval executor to output the conflict result; The query rewriter generates the next round of query based on the cause of the miss, the unmet condition, or the conflict result, and returns it to the retrieval executor. The stop controller determines whether the stop condition is met based on the fact status and the retrieval round information output by the retrieval status recorder. If the condition is met, it commands the retrieval executor to stop the retrieval and outputs a stop command, the reason for the stop, and the unfinished facts. The result generator responds to the stop command output by the stop controller, generates a fact verification result based on the evidence state diagram, and generates an arbitration result based on the fact verification result, the fact state of each fact proposition in the evidence state diagram, and the logical relationship between each fact proposition and the evidence hypothesis.

2. The data circulation and transaction dispute arbitration method according to claim 1, characterized in that, The arbitration semantic intermediate model includes arbitration elements and claim units; The step of generating an intermediate arbitration semantic model based on the arbitration request and the applicant's evidence includes: Arbitration elements are extracted from any form of the arbitration request and the applicant's evidence, including the claim, the requesting party, the opposing party, the subject matter of the dispute, the assertion, the time constraint, the contract rules, and the requested outcome; If the arbitration request includes multiple claims, each claim shall be treated as a claim unit, and the multiple claim units shall share at least one of the claiming subject, the opposing party, the subject of the dispute, and the time constraint. For information that was not extracted from the arbitration elements, a vacancy or candidate entity is generated.

3. The data circulation and transaction dispute arbitration method according to claim 2, characterized in that, The set of evidence hypotheses includes supporting hypotheses, negative hypotheses, and alternative interpretations; The generation of the evidence hypothesis set based on the arbitration semantic intermediate model includes: For each claim unit, the supporting hypothesis, the negative hypothesis, and the alternative explanation are generated simultaneously. Each of the aforementioned assumptions is broken down into machine-verifiable facts to be verified; Configure establishment conditions, denial conditions, evidence requirements, supporting evidence coverage conditions, and rebuttal evidence coverage conditions for each of the facts to be verified, and write the establishment conditions, denial conditions, evidence requirements, supporting evidence coverage conditions, and rebuttal evidence coverage conditions into the fact verification description object.

4. The data circulation and transaction dispute arbitration method according to claim 1, characterized in that, The task planner generates a dynamic task queue based on hypothesis discrimination, dependencies, query costs, and permission levels. The task planner generates a dynamic task queue based on the current hypothesis state and evidence gaps, including: Based on the current state of the hypothesis and the evidence gap, determine the hypothesis discrimination of the hypothesis to be verified; Determine the dependencies between factual propositions; The facts in the set of facts to be processed are sorted according to the assumed discrimination, and the first sorting result is obtained. Based on the dependencies, the execution order is adjusted according to the fact that there are prerequisite relationships in the first sorting result to obtain the second sorting result; Based on query cost and permission level, the priorities of the tasks corresponding to each fact in the second sorting result are fine-tuned to generate a dynamic task queue.

5. The data circulation and transaction dispute arbitration method according to claim 1, characterized in that, The retrieval strategy includes deterministic identifier precise retrieval and enhanced retrieval; the dynamic task queue contains at least one task to be executed, and each task to be executed corresponds to a retrieval strategy. The retrieval executor selects a retrieval strategy from the dynamic task queue, including: Prioritize the precise retrieval of the corresponding task to be executed based on the deterministic identifier, and use the results of the precise retrieval as candidate evidence; If the precise retrieval fails or key information is missing, the corresponding task to be executed for enhanced retrieval is selected from the dynamic task queue according to the reason for the miss returned by the unified retrieval interface. The enhanced retrieval includes entity alias fuzzy retrieval, misspelling fuzzy retrieval, semantic vector retrieval, time window progressive expansion, entity association expansion, evidence state graph adjacency expansion, and cross-source cross retrieval. Among them, the results of fuzzy search are used as candidate evidence after being verified for entity consistency, time consistency, and source consistency.

6. The data circulation and transaction dispute arbitration method according to claim 3, characterized in that, After the evidence evaluator creates evidence nodes corresponding to supporting hypotheses, the query rewriter also generates queries for verifying negative hypotheses or alternative interpretations. The supporting evidence and the counter-evidence are evaluated using the same criteria; the evaluation criteria include relevance criteria, source reliability criteria, and coverage adequacy criteria. If the search for counter-evidence directions for the negative hypothesis and the alternative interpretations has not yet reached the preset search coverage requirement, the hypothesis state manager shall not update the fact state to verified; when the supporting evidence meets the support sufficient condition, the search for counter-evidence directions meets the preset search coverage requirement, and there is no valid counter-evidence that meets the negation sufficient condition, the hypothesis state manager shall update the fact state to verified.

7. The data circulation and transaction dispute arbitration method according to claim 1, characterized in that, The query rewriter modifies the query expression in at least one of the following ways: Query standardization; Alias ​​extension; Time window expansion; Data source switching; Add constraints to confirmed entities; Add business phase constraints; Redirecting can provide the associated data source for key fields; Generate queries that verify the time, status, and subject mappings of each source; The query rewriter generates the next round of queries based on the cause of the miss, the condition not met, or the conflict result, including: If no match is found, query normalization, alias expansion, time window expansion, or data source switching will be triggered. If there are too many candidate results, add constraints on confirmed entities or business stages; If a candidate result lacks a key field, the search will turn to a related data source that can provide the key field. If results from different sources conflict, queries are generated to verify the time, status, and subject mapping of each source respectively. After each rewrite, the previous query expression, the rewritten query expression, the reason for the rewrite, and the range change are written into the retrieval status recorder.

8. The data circulation and transaction dispute arbitration method according to claim 1, characterized in that, The stopping condition includes at least one of the following: The key facts meet the criteria for sufficient evidence; Both supporting and counter-evidence meet the preset search coverage requirements; No new valid evidence was obtained after several consecutive preset rounds; The maximum number of query rounds, time limit, or resource limit has been reached. Further actions require additional authorization; There are contractual ambiguities or conflicting evidence that require human interpretation; The stop controller determines whether the stop condition is met based on the fact status output by the hypothetical state manager and the retrieval round information output by the retrieval state recorder. If the condition is met, the stop controller commands the retrieval executor to stop the retrieval, and the stop controller outputs the stop reason and the unfinished facts.

9. The data circulation and transaction dispute arbitration method according to claim 1, characterized in that, The cross-platform restricted task carries multiple items from the following: fact verification description object, case-limited task identifier, scope of allowed search strategies, maximum time extension range, maximum association depth, and allowed output fields. The privacy evidence credential includes multiple items from the following: case-limited task identifier, factual status, query execution status, actual coverage, evidence type summary, query condition commitment, source record set commitment, calculation algorithm and parameter version, generation time, and platform signature. After the evidence retrieval controller verifies the privacy evidence credential, it writes the privacy evidence credential as an evidence node into the evidence state graph. In the evidence state graph, the privacy evidence credential is associated with the fact proposition node corresponding to the fact identifier and is not used for other fact propositions.

10. A data circulation and transaction dispute arbitration device, characterized in that, include: The receiving module is used to receive arbitration requests and applicant evidence, and generate an arbitration semantic intermediate model based on the arbitration requests and applicant evidence. The arbitration module is used to generate a set of evidence hypotheses based on the arbitration semantic intermediate model, split each hypothesis in the set of evidence hypotheses into facts to be verified and fact verification description objects, input the fact verification description objects and the current hypothesis state into the evidence retrieval controller, and obtain the arbitration result. The evidence retrieval controller includes a task planner, a retrieval executor, an evidence evaluator, a hypothesis state manager, a query rewriter, a retrieval state recorder, a stop controller, and a result generator; the hypothesis state manager maintains an evidence state graph; the following operations are performed in the evidence retrieval controller: The task planner generates a dynamic task queue based on the current hypothesis state and evidence gaps. The retrieval executor selects a retrieval strategy from the dynamic task queue and generates a restricted query. It executes the restricted query through a unified retrieval interface and returns the local query results and the reasons for the miss. If the fact to be verified is indicated by the fact verification description object as requiring cross-platform evidence collection, then a cross-platform restricted task is generated and sent to an external platform, and the privacy evidence certificate returned by the external platform is received. The evidence evaluator evaluates the candidate results in the local query results, creates the candidate results that meet the evaluation criteria as evidence nodes, and verifies the privacy evidence credentials, creating the verified privacy evidence credentials as restricted evidence nodes. In the evidence state diagram, the evidence nodes and the restricted evidence nodes are respectively associated with the corresponding factual propositions in the facts to be verified, and the unmet conditions are output. The hypothesis state manager updates the fact state according to the relationship between the evidence node and the fact proposition, and feeds back the fact state to the retrieval executor to output the conflict result; The query rewriter generates the next round of query based on the cause of the miss, the unmet condition, or the conflict result, and returns it to the retrieval executor. The stop controller determines whether the stop condition is met based on the fact status and the retrieval round information output by the retrieval status recorder. If the condition is met, it commands the retrieval executor to stop the retrieval and outputs a stop command, the reason for the stop, and the unfinished facts. The result generator responds to the stop command output by the stop controller, generates a fact verification result based on the evidence state diagram, and generates an arbitration result based on the fact verification result, the fact state of each fact proposition in the evidence state diagram, and the logical relationship between each fact proposition and the evidence hypothesis.

Images