A cross-border trade dynamic performance security execution method, system and device based on a task graph state machine and rule constraints, and a storage medium

Abstract

This invention discloses a method for secure dynamic performance execution in cross-border trade based on task graph state machines and rule constraints. The system receives and structures business intentions, generating a performance task graph containing node dependencies, state fields, rules, and permission policies. Compliance, state transition, and permission rules are converted into executable constraints to form a baseline solution. Trusted off-chain data is collected to generate anti-replay state events. When replanning is triggered, candidate strategies from the intelligent agent are received and encoded as strategy change records. Feasible strategies are screened through signature, permission, authorization, state, rules, on-chain pre-processing, and replay verification, and a dynamic solution is solved. The system calculates the state root hash and compares it with the consortium blockchain. Settlement, credit adjustment, or state update is triggered only when the state is consistent, the documents are complete, the signature is valid, and there is no dispute.

Description

Technical Field

[0001] This invention relates to the fields of digital fulfillment of cross-border trade, supply chain finance, artificial intelligence candidate strategy control, workflow orchestration, rule engine, blockchain trusted storage and secure execution of smart contracts, and specifically to a method, system, device and storage medium for secure execution of dynamic fulfillment of cross-border trade based on task graph state machine and rule constraints. Background Technology

[0002] Cross-border trade fulfillment typically involves multiple entities, including exporters, importers, logistics companies, banks, customs, insurance institutions, and electronic documentation service providers. The business process encompasses several stages, such as contract generation, quality inspection, booking, shipment, customs declaration, customs clearance, transportation tracking, financing review, receipt confirmation, dispute resolution, and fund settlement. Inconsistencies in data standards, interface protocols, permission boundaries, and business status among these different entities can easily lead to problems such as duplicate data entry, high manual verification costs, delayed status synchronization, fragmented dispute evidence, and lengthy settlement cycles.

[0003] Existing centralized business platforms can integrate some processes, but they have limited credibility in recording evidence of cross-entity collaboration and in controlling the security of automated execution. Existing blockchain evidence storage systems can record document hashes and status events, but they are usually biased towards post-event traceability and it is difficult to control automatic settlement or credit adjustment based on the consistency between the off-chain task graph state and the on-chain event sequence. Pre-set scripts or robotic process automation can execute fixed actions, but it is difficult to handle dynamic events such as port congestion, severe weather, customs inspection, route adjustments, abnormal cargo status, exchange rate fluctuations, and changes in financing risks in a timely manner.

[0004] With the development of generative models, large language models, and business intelligence technologies, it has become possible to use artificial intelligence to analyze business intent, generate candidate performance strategies, and assist in multi-party negotiations. However, in highly compliant scenarios such as cross-border trade and supply chain finance, directly using natural language candidate strategies generated by AI models or business intelligence agents as the basis for execution can easily lead to risks such as field parsing errors, rule out-of-bounds violations, illegal state transitions, improper access permissions, inconsistencies between on-chain and off-chain states, duplicate execution, and a lack of auditable evidence. Summary of the Invention

[0005] Purpose of the Invention: To overcome the shortcomings of the prior art, the first objective of this invention is to provide a method for secure execution of dynamic contract fulfillment in cross-border trade based on task graph state machine and rule constraints. This method combines artificial intelligence candidate generation, task graph state machine, machine-verifiable strategy change record, deterministic rule constraint verification, off-chain trusted data collection, consortium chain anchoring, state root consistency verification, failure shutdown control, and smart contract execution gating. This ensures that the candidate strategies output by the artificial intelligence model or business intelligence agent can only drive automatic contract fulfillment when they are structured, verified, authorized, signed, and verified against replay and are consistent with the on-chain state. The second objective is to provide a cross-border trade dynamic performance security execution system based on task graph state machine and rule constraints, through which the above-mentioned cross-border trade dynamic performance security execution method based on task graph state machine and rule constraints can be implemented; The third objective is to provide a dynamic contract fulfillment security execution device for cross-border trade based on task graph state machine and rule constraints; The fourth objective is to provide a storage medium for secure execution of dynamic contract fulfillment in cross-border trade based on task graph state machines and rule constraints.

[0006] Technical Solution: The present invention provides a method for dynamic performance security in cross-border trade based on task graph state machine and rule constraints, comprising the following steps: S1. Receive cross-border trade business intents and structure them into standard intent parameters with transaction identifiers and version numbers; S2. Generate a performance task graph based on standard intent parameters. The performance task graph includes task nodes, node dependencies, state machine fields, on-chain state fields, compliance rule numbers, and permission policies. S3. Based on the performance task graph, call the preset rule library to convert the compliance rules, state transition rules and permission rules corresponding to the task nodes into executable constraint expressions, and pre-verify the performance task graph based on the executable constraint expressions to form a benchmark performance plan; S4. Collect environmental variables from an off-chain trusted data source that has been authenticated and authorized, generate state events, and generate a replanning event when the environmental variables meet preset triggering conditions; S5. In response to the replanning event, receive candidate fulfillment strategies proposed by an artificial intelligence model, business intelligence agent, or human participant, wherein the candidate fulfillment strategies are not used as the basis for direct automatic execution; parse the candidate fulfillment strategies into machine-verifiable strategy change records, and perform normalization processing on the strategy change records to generate strategy change record hashes. S6. Before the strategy change record enters the utility calculation, task state update or smart contract call, execute the strategy execution gate based on signature, permission, data authorization, state transition, rule constraint, on-chain preconditions and replay protection to block the strategy change record that has not passed the strategy execution gate and obtain a set of feasible strategies. S7. Perform utility calculation and negotiation on the set of feasible strategies to obtain a dynamic performance plan; S8. Calculate the state root hash based on the task graph version, task node state set, on-chain event sequence number, strategy change record hash, and necessary document hash, and perform a consistency comparison between the state root hash and the state root hash recorded in the consortium chain. S9. Settlement, credit adjustment, or status update shall be triggered through smart contract settlement gate only when the state root hash is consistent, the necessary events and necessary documents are complete, the signatures of the participants are valid, and there are no unresolved disputes; otherwise, the freeze shall be automatically executed and transferred to manual review.

[0007] Furthermore, the standard intent parameters, task nodes, or candidate fulfillment strategies are generated by a natural language processing model, generative model, large language model, or business intelligence agent as candidate generation sources. These candidate results are not used as the basis for automatic execution until they are structured and parsed into a preset field pattern and verified for field integrity, value range, field conflict, confidence threshold, rules, permissions, signature, replay, and on-chain state preconditions. The candidate generation source outputs candidate results based on business intent, task graph state, or replanning events, and is only used to generate candidate field values, candidate task nodes, or candidate strategy text. It does not have the authority to directly call smart contracts, directly modify task node states, or directly trigger settlement.

[0008] Furthermore, the performance task graph is a directed acyclic graph, and the task nodes include at least one of the following: order creation, quality inspection confirmation, document upload, booking, shipment, customs declaration, customs clearance status confirmation, transportation status reporting, financing review, goods receipt confirmation, and fund settlement. Each task node is only allowed to change its status according to a preset status migration table, and it cannot directly enter the completed, pending settlement, or settled status without prior evidence, necessary document hashes, on-chain status events, or authorization signatures.

[0009] Furthermore, the executable constraint expression includes rule number, field identifier, comparison operator, threshold parameter, state condition, authorization subject, data source identifier, signature requirement, failure handling action, and priority identifier; the gating includes strategy execution gating and smart contract settlement gating; the strategy execution gating is executed in the order of signature gating, permission gating, data authorization gating, state gating, rule gating, on-chain pre-processing gating, and replay gating, wherein the signature gating verifies the proposer's signature and the data source signature, the permission gating verifies the proposer's role and field modification permission, the data authorization gating verifies off-chain data access authorization, and the state gating verifies... The system verifies whether the target state conforms to the preset state transition table, verifies the executable constraint expression through rule gating, verifies the on-chain event sequence number and necessary events through on-chain pre-gating, and verifies the anti-replay random number, idempotent execution flag, and time window through replay gating. When any of the policy execution gating or smart contract settlement gating fails, the system blocks the corresponding policy change record from entering utility calculation, task state update, or smart contract call, sets the relevant task node to a paused, pending manual review, or dispute frozen state, and generates an audit log containing the failure gating number, failure field value, current state, target state, proposer, timestamp, and record hash.

[0010] Furthermore, the off-chain trusted data source includes at least one of the following: IoT devices, customs data interface, shipping company or logistics platform interface, meteorological interface, exchange rate interface, bank risk control interface, and electronic document system; the environmental variables include at least one of the following: estimated arrival time, transportation cost, customs clearance status, weather risk, exchange rate change, cargo location, cargo temperature and humidity, cargo abnormal status, and financing risk score; the preset triggering conditions include at least one of the following: time deviation, cost increase, exchange rate fluctuation, cargo abnormality, customs clearance delay, financing risk change, and task timeout; the status event includes at least one of the following: data hash, source signature, permission identifier, timestamp, on-chain event sequence number, data source certificate identifier, and anti-replay random number, and the on-chain event sequence number is allocated or confirmed by the consortium blockchain smart contract, consortium blockchain node consensus service, or trusted sequence service.

[0011] Furthermore, the strategy change record includes at least one of the following: transaction identifier, task graph version number, strategy change record identifier, task node identifier, operation type, state before change, target state, parameters before change, target parameters, effective conditions, proposer, timestamp, on-chain event sequence number, anti-replay random number, idempotent execution identifier, signature, reason code, and data authorization identifier, authorization scope identifier, or authorization credential hash. Before being written to the consortium blockchain, participating in utility calculation, task state update, or state root hash calculation, the strategy change record is standardized and serialized according to a fixed field order, encoding format, time format, null value handling rules, array sorting rules, and numerical precision rules, and a strategy change record hash is generated.

[0012] Furthermore, the utility calculation only processes the set of feasible strategies that are gated through all strategies, and normalizes at least two indicators among performance time, performance cost, financing cost, credit risk, default loss, compliance risk and state consistency risk and calculates the comprehensive utility. When the set of feasible strategies is empty, the negotiation fails to converge, the core participants reject the candidate strategy, there is an irresolvable compliance conflict, the on-chain and off-chain states are inconsistent, the event sequence number is discontinuous or the necessary document hash is missing, the freeze is automatically executed and the human-machine loopback module outputs the dispute point, conflict cause, candidate strategy record, failure gating number, state root comparison result and alternative scheme.

[0013] Correspondingly, the cross-border trade dynamic performance security execution system based on task graph state machine and rule constraints provided by this invention includes: The intent parsing module is used to output cross-border trade business intents as standard intent parameters; The task graph generation module is used to generate a performance task graph that includes state machine fields, on-chain state fields, compliance rule numbers, permission policies, and exception handling policies. The rules engine module is used to convert rules into executable constraint expressions and execute gating strategies in the order of signature, permissions, data authorization, state, rules, on-chain pre-processing and replay. The environment awareness module is used to collect data from off-chain trusted data sources that have been authenticated and authorized, generate state events, and determine whether to trigger replanning. The negotiation solution module encodes candidate performance strategies into strategy change records and performs utility calculations and generates dynamic performance solutions only for the set of feasible strategies that have passed all gating. The state consistency verification module is used to calculate the state root hash according to the normalized serialization rules and compare it with the state root hash and event sequence number recorded in the consortium blockchain. The on-chain anchoring module is used to write hashes, state events, timestamps, and participant signatures into the consortium blockchain; The smart contract execution module is used to execute settlement, credit adjustment or status update when the state root is consistent, the events and documents are complete, the signature is valid and there are no unresolved disputes, based on the settlement gate; otherwise, it will execute dispute freezing or manual review triggering. The human-machine loop module is used to freeze automatic execution and trigger manual review when gating fails, negotiation deadlocks or consistency verification fails. The access control and privacy protection module is used for access control, de-identification, or encryption. The intelligent agent skill optimization module is used to record failure samples such as candidate parsing failure, gating failure, and manual review results. After sandbox replay, rule regression testing, and manual review, the module updates the model prompt words or task arrangement template. The update does not directly change the smart contract execution rules. The above modules enable the implementation of the cross-border trade dynamic performance security execution method based on task graph state machine and rule constraints as described in claim 1.

[0014] Correspondingly, the cross-border trade dynamic performance security execution device based on task graph state machine and rule constraints provided by the present invention includes: one or more processors; Storage device for storing one or more program or resource data; When the one or more programs are executed by one or more processors, the one or more processors implement the above-described method for dynamic and secure execution of cross-border trade contracts based on task graph state machines and rule constraints.

[0015] Correspondingly, the cross-border trade dynamic performance security execution storage medium based on task graph state machine and rule constraints provided by the present invention stores a computer program, which, when executed by a processor, implements the above-mentioned cross-border trade dynamic performance security execution method based on task graph state machine and rule constraints.

[0016] Beneficial effects: Compared with the prior art, the significant advancements of this invention are as follows: 1. By limiting the output of generative models, large language models, or business intelligence agents to candidate results, and further limiting them to not having the authority to directly call smart contracts, directly modify task node states, or directly trigger settlement, candidate results must pass structured parsing, rule engine, state machine, permission policy, signature, replay protection, and on-chain state precondition verification before entering the subsequent process, thereby reducing the performance risks caused by artificial intelligence illusions, field parsing errors, or unauthorized execution; 2. By using the state machine field, on-chain state field, and preset state transition table of the performance task graph, the order, document, logistics, financing, customs clearance, receipt and settlement links in cross-border trade are uniformly expressed as verifiable node states, avoiding direct entry into the completed, pending settlement or settled state when there is a lack of prior evidence; 3. The changes to the dynamic performance plan are uniformly expressed through the policy change record, and the rules, states, on-chain preconditions, permissions, data authorization, signatures and replay gating are executed before the utility calculation to prevent candidate policies that violate compliance rules, illegal state transitions, unauthorized access or repeated execution from entering the automatic execution process. 4. By using state root hashing, the off-chain task graph version, task node state set, on-chain event sequence number, policy change record hash, and necessary document hash are bound into recalculated and comparable state evidence, reducing the risk of incorrect settlement, incorrect credit adjustment, or duplicate execution caused by inconsistency between on-chain and off-chain states. 5. Through the layered design of strategy execution gating and smart contract settlement gating, the former blocks non-compliant strategies from entering utility calculation and state update, while the latter blocks settlement, credit adjustment and state update when there is inconsistency in state root, missing necessary events, missing necessary documents or disputes, forming a failure-closed security control. 6. Through multi-agent negotiation and human-machine feedback mechanism, automatic execution is frozen in case of abnormal events, compliance conflicts, negotiation deadlocks, signature abnormalities, permission abnormalities, replay risks, or inconsistent states. The system also outputs the points of contention, reasons for rule conflicts, and alternative solutions, thereby improving the auditability and explainability of complex cross-border trade scenarios. Attached Figure Description

[0017] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a system architecture diagram of the present invention; Figure 3 This is a schematic diagram illustrating the generation of task node state transition and strategy change records in this invention; Figure 4 This is a flowchart illustrating the rule-based gating and failure-based shutdown process of this invention. Figure 5 This is a flowchart of the multi-agent negotiation and human-machine loopback process of the present invention; Figure 6 This is a flowchart of the on-chain and off-chain state consistency verification process of the present invention. Detailed Implementation

[0018] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0019] Example 1: As Figure 1 The method for dynamic performance security in cross-border trade, based on task graph state machines and rule constraints, includes the following steps: S1. Receive cross-border trade business intents and structure them into standard intent parameters with transaction identifiers and version numbers; S2. Generate a performance task graph based on standard intent parameters. The performance task graph includes task nodes, node dependencies, state machine fields, on-chain state fields, compliance rule numbers, and permission policies. S3. Based on the performance task graph, call the preset rule library to convert the compliance rules, state transition rules and permission rules corresponding to the task nodes into executable constraint expressions, and pre-verify the performance task graph based on the executable constraint expressions to form a benchmark performance plan; S4. Collect environmental variables from an off-chain trusted data source that has been authenticated and authorized, generate state events, and generate a replanning event when the environmental variables meet preset triggering conditions; S5. In response to the replanning event, receive candidate fulfillment strategies proposed by an artificial intelligence model, business intelligence agent, or human participant, wherein the candidate fulfillment strategies are not used as the basis for direct automatic execution; parse the candidate fulfillment strategies into machine-verifiable strategy change records, and perform normalization processing on the strategy change records to generate strategy change record hashes. S6. Before the strategy change record enters the utility calculation, task state update or smart contract call, execute the strategy execution gate based on signature, permission, data authorization, state transition, rule constraint, on-chain preconditions and replay protection to block the strategy change record that has not passed the strategy execution gate and obtain a set of feasible strategies. S7. Perform utility calculation and negotiation on the set of feasible strategies to obtain a dynamic performance plan; S8. Calculate the state root hash based on the task graph version, task node state set, on-chain event sequence number, strategy change record hash, and necessary document hash, and perform a consistency comparison between the state root hash and the state root hash recorded in the consortium chain. S9. Settlement, credit adjustment, or status update shall be triggered through smart contract settlement gate only when the state root hash is consistent, the necessary events and necessary documents are complete, the signatures of the participants are valid, and there are no unresolved disputes; otherwise, the freeze shall be automatically executed and transferred to manual review.

[0020] Specifically, the standard intent parameters, task nodes, or candidate fulfillment strategies are generated by a natural language processing model, generative model, large language model, or business intelligence agent as candidate generation sources. These candidate results are not used as the basis for automatic execution until they are structured and parsed into a preset field pattern and verified for field integrity, value range, field conflict, confidence threshold, rules, permissions, signature, replay, and on-chain state preconditions. The candidate generation source outputs candidate results based on business intent, task graph state, or replanning events. These results are only used to generate candidate field values, candidate task nodes, or candidate strategy text and do not have the authority to directly call smart contracts, directly modify task node states, or directly trigger settlement.

[0021] The performance task graph is a directed acyclic graph. The task nodes include at least one of the following: order creation, quality inspection confirmation, document upload, booking, shipment, customs declaration, customs clearance status confirmation, transportation status reporting, financing review, goods receipt confirmation, and fund settlement. Each task node is only allowed to change its status according to the preset status migration table, and it cannot directly enter the completed, pending settlement, or settled status without prior evidence, necessary document hash, on-chain status event, or permission signature.

[0022] Executable constraint expressions include rule number, field identifier, comparison operator, threshold parameter, state condition, authorization subject, data source identifier, signature requirements, failure handling action, and priority identifier; gating includes policy execution gating and smart contract settlement gating; policy execution gating is executed in the following order: signature gating, permission gating, data authorization gating, state gating, rule gating, on-chain pre-gating, and replay gating. Specifically, signature gating verifies the proposer's signature and the data source signature; permission gating verifies the proposer's role and field modification permissions; data authorization gating verifies off-chain data access authorization; and state gating verifies the target state. The system verifies whether the state conforms to the preset state transition table, verifies the executable constraint expression through rule gating, verifies the on-chain event sequence number and necessary events through on-chain pre-gating, and verifies the anti-replay random number, idempotent execution flag, and time window through replay gating. When any gating in the strategy execution gating or smart contract settlement gating fails, it blocks the corresponding strategy change record from entering utility calculation, task state update, or smart contract call, sets the relevant task node to a paused, pending manual review, or disputed freeze state, and generates an audit log containing the failure gating number, failure field value, current state, target state, proposer, timestamp, and record hash.

[0023] The off-chain trusted data sources include at least one of the following: IoT devices, customs data interfaces, shipping company or logistics platform interfaces, meteorological interfaces, exchange rate interfaces, bank risk control interfaces, and electronic document systems; environmental variables include at least one of the following: estimated arrival time, transportation costs, customs clearance status, weather risks, exchange rate changes, cargo location, cargo temperature and humidity, cargo abnormal status, and financing risk score; preset trigger conditions include at least one of the following: time deviation, cost increase, exchange rate fluctuation, cargo abnormality, customs clearance delay, changes in financing risk, and task timeout; status events include at least one of the following: data hash, source signature, permission identifier, timestamp, on-chain event sequence number, data source certificate identifier, and anti-replay random number, and the on-chain event sequence number is assigned or confirmed by the consortium blockchain smart contract, consortium blockchain node consensus service, or trusted sequence service.

[0024] The strategy change record includes at least one of the following: transaction identifier, task graph version number, strategy change record identifier, task node identifier, operation type, state before change, target state, parameters before change, target parameters, effective conditions, proposer, timestamp, on-chain event sequence number, anti-replay random number, idempotent execution identifier, signature, reason code, and data authorization identifier, authorization scope identifier, or authorization credential hash. Before being written to the consortium blockchain, participating in utility calculation, task state update, or state root hash calculation, the strategy change record is standardized and serialized according to a fixed field order, encoding format, time format, null value handling rules, array sorting rules, and numerical precision rules, and a strategy change record hash is generated.

[0025] The utility calculation only processes the set of feasible strategies that are gated through all strategies, and normalizes at least two indicators among performance time, performance cost, financing cost, credit risk, default loss, compliance risk and state consistency risk and calculates the comprehensive utility. When the set of feasible strategies is empty, the negotiation fails to converge, the core participants reject the candidate strategy, there is an irresolvable compliance conflict, the on-chain and off-chain states are inconsistent, the event sequence number is discontinuous or the necessary document hash is missing, the freeze is automatically executed and the human-machine loopback module outputs the dispute point, conflict cause, candidate strategy record, failure gating number, state root comparison result and alternative solution.

[0026] Example 2: A dynamic contract fulfillment security execution system for cross-border trade based on task graph state machine and rule constraints, comprising: The intent parsing module is used to output cross-border trade business intents as standard intent parameters; The task graph generation module is used to generate a performance task graph that includes state machine fields, on-chain state fields, compliance rule numbers, permission policies, and exception handling policies. The rules engine module is used to convert rules into executable constraint expressions and execute gating strategies in the order of signature, permissions, data authorization, state, rules, on-chain pre-processing and replay. The environment awareness module is used to collect data from off-chain trusted data sources that have been authenticated and authorized, generate state events, and determine whether to trigger replanning. The negotiation solution module encodes candidate performance strategies into strategy change records and performs utility calculations and generates dynamic performance solutions only for the set of feasible strategies that have passed all gating. The state consistency verification module is used to calculate the state root hash according to the normalized serialization rules and compare it with the state root hash and event sequence number recorded in the consortium blockchain. The on-chain anchoring module is used to write hashes, state events, timestamps, and participant signatures into the consortium blockchain; The smart contract execution module is used to execute settlement, credit adjustment or status update when the state root is consistent, the events and documents are complete, the signature is valid and there are no unresolved disputes, based on the settlement gate; otherwise, it will execute dispute freezing or manual review triggering. The human-machine loop module is used to freeze automatic execution and trigger manual review when gating fails, negotiation deadlocks or consistency verification fails. The access control and privacy protection module is used for access control, de-identification, or encryption. The intelligent agent skill optimization module is used to record failure samples such as candidate parsing failure, gating failure, and manual review results. After sandbox replay, rule regression testing, and manual review, the module updates the model prompt words or task arrangement template. The update does not directly change the smart contract execution rules. The above modules enable the implementation of the cross-border trade dynamic performance security execution method based on task graph state machine and rule constraints, as described in Example 1.

[0027] like Figure 2 As shown, the system of this invention includes an intent input layer, an intent parsing and task graph generation layer, a rule engine, an environment awareness layer, a multi-agent negotiation layer, an off-chain trusted data source layer, a consortium blockchain anchoring layer, a state consistency verification module, a smart contract execution layer, a human-machine loopback module, a permission management and privacy protection module, and an agent skill optimization module. The intent input layer receives business intents from natural language, forms, contract texts, or electronic documents. The intent parsing and task graph generation layer maps business intents to standard intent parameters and generates a performance task graph with state machine fields and on-chain state fields. The rule engine performs deterministic gating on task nodes and candidate strategies in the following order: signature verification, permission verification, data authorization verification, state transition legality verification, rule constraint verification, on-chain state precondition verification, and replay verification.

[0028] The multi-agent negotiation layer generates and solves dynamic performance plans when environmental variables are abnormal, but only performs utility calculations on the set of feasible strategies that pass deterministic gating. The consortium blockchain anchoring layer records key hashes, state events, timestamps, and participant signatures. The state consistency verification module calculates and compares the state root hash. The smart contract execution layer includes a strategy execution gating interface and a settlement gating interface. The strategy execution gating blocks strategy change records that fail verification, while the settlement gating blocks settlement, credit adjustments, and state updates when there is state root inconsistency, missing necessary on-chain events, missing necessary document hashes, or unresolved disputes.

[0029] Business users can input natural language intents, such as: "Transport 1000 tons of cold chain agricultural products from Shanghai to Rotterdam, requiring completion within 30 days and obtaining 80% prepayment financing." The intent parsing module calls a generative model or large language model to generate candidate parsing results, but these candidate parsing results do not directly enter the execution layer and do not have the authority to trigger settlement or modify the task status. The structured parser extracts the transaction entity, goods name, quantity, destination, performance period, financing ratio, document requirements, and risk constraints according to preset field templates, and verifies the completeness of fields, value range, field conflicts, source identifier, confidence threshold, and signature status. If the destination, financing ratio, or document requirements are missing, the system outputs a supplementary confirmation request; if the financing ratio exceeds the preset credit limit, the system switches to manual confirmation or rule rejection. As shown in Table 1, standard intent parameters can further include fields such as unique transaction identifier, participants and roles, goods category code, amount and currency, destination code, performance period, financing ratio, required documents, and risk constraints.

[0030] Table 1. Example Table of Standard Intent Parameter Fields

[0031] The task graph generation module generates a fulfillment task graph based on standard intent parameters. Nodes in the fulfillment task graph can include order creation, quality inspection confirmation, invoice upload, booking, shipment, customs declaration, customs clearance status confirmation, transportation status reporting, financing review, importer receipt confirmation, and fund settlement. Dependencies between task nodes are represented by directed edges; for example, quality inspection confirmation must precede shipment, and customs release and receipt confirmation must precede fund settlement. Each task node is configured with a state machine field, an on-chain state field, a compliance rule number, an access control policy, and an exception handling policy. Figure 3 As shown, task nodes change their status according to the preset status migration path. When an environment is abnormal or manual review is triggered, the system generates a policy change record and includes fields such as the status before the change, the target status, the operation type, and the reason code in subsequent rule verification.

[0032] The rules engine includes a hard rule base, a parameter rule base, a state transition rule base, a permission rule base, a signature verification component, a data authorization verification component, and a replay protection component. The hard rule base includes rules for letter of credit limits, sanctions lists, anti-money laundering, goods category restrictions, destination country or region restrictions, transportation time limits, and participant permission rules. The state transition rule base specifies the allowed state change paths for each type of task node. As shown in Table 2, each task node changes state according to a preset state transition table, and is only allowed to enter the next state when necessary conditions are met.

[0033] Table 2. Example of Task Node State Transition Rules

[0034] The rule engine converts rules into executable constraint expressions. A constraint expression can be represented as `Rule(rule_id, field, operator, threshold, state_condition, permission_subject, data_source, signature_requirement, fail_action, priority)`. When a business agent submits a candidate policy, the rule engine first matches the transaction entity, destination code, goods category code, amount field, credit ratio field, time window field, state machine field, on-chain event sequence number, and anti-replay random number in the policy against the constraint expression. If a candidate policy causes the transaction amount to exceed the letter of credit limit, the destination to fall into a restricted region, the entity to fall into a sanctions list, or the state to jump directly from execution to settlement without receiving confirmation and document verification, the policy is rejected, and a rule validation failure log containing the failure gate number and failure field value is generated. Figure 4 As shown, the rule engine performs deterministic gating before candidate policies enter utility calculation, task state update, or smart contract execution. If any gating fails, the system enters the failure shutdown process. As shown in Table 3, when rule verification, state transition, signature, permission, replay, or state root consistency verification fails, the system performs blocking, freezing, or manual review actions according to the failure shutdown principle.

[0035] In one implementation, the inputs to the policy execution gating are policy change records, current task node status, on-chain event sequence number, necessary document hash, proposer identity, and permission policy; the output is one of pass, failure, or failure gating number. Only policy change records with a pass output are written into the feasible policy set, while failure records are only written to the audit log and manual review queue and do not participate in utility calculation.

[0036] Table 3 Gating Failure Types and Failure Closure Actions

[0037] During the execution of the baseline performance plan, the environmental awareness module continuously receives status data from trusted off-chain data sources. For example, the logistics interface provides estimated arrival time, IoT devices provide cargo location, temperature, and humidity data, the meteorological interface provides typhoon path and port weather data, the customs interface provides inspection and release status, the bank risk control interface provides financing risk scoring, and the exchange rate interface provides real-time exchange rate changes.

[0038] When any environmental variable reaches a trigger threshold, the system generates a replanning event. For example, if the estimated arrival time is delayed by more than 72 hours from the baseline plan, the transportation cost increases by more than 10% compared to the original plan, the exchange rate fluctuates by more than 3%, the cargo temperature exceeds the threshold for 30 minutes, or the bank risk score rises above a preset level, the system will write the abnormal state, triggering reason, data hash, timestamp, on-chain event sequence number, data source certificate identifier, anti-replay random number, and data source signature into the consortium blockchain and notify the multi-agent negotiation module. As shown in Table 4, the environmental perception module determines whether to generate a replanning event based on variables such as estimated arrival time, transportation cost, exchange rate, temperature and humidity, customs clearance status, and financing risk score.

[0039] Table 4. Examples of Environment Variable Trigger Thresholds and Status Events

[0040] Upon triggering a replanning event, the logistics agent, bank agent, importer agent, and exporter agent each generate strategy change records based on their current task graph status. The logistics agent can propose strategies such as rerouting, delaying shipment, adding insurance, or changing carriers; the bank agent can propose strategies such as adjusting credit limits, financing interest rates, or margin ratios; the importer agent can propose strategies such as adjusting receiving windows, adjusting breach of contract compensation, or delaying acceptance; and the exporter agent can propose strategies such as supplementing documents, adding guarantees, or adjusting delivery commitments.

[0041] In this implementation, the strategy change record DeltaP describes the candidate strategies proposed by the business intelligence agent. Its fields include trade_id, task_graph_version, delta_id, node_id, operation_type, source_state, target_state, param_before, param_after, effective_condition, proposer, timestamp, event_seq, nonce, idempotency_key, signature, and reason_code. Through this structure, the system can transform natural language-based candidate solutions into structured data that can be jointly verified by the rule engine, state machine, and smart contracts. As shown in Table 5, the strategy change record can cover operation types such as state changes, time window changes, execution entity changes, route changes, funding parameter changes, and dispute freezes. As shown in Figure 5, after the replanning event is triggered, multiple business agents propose candidate strategies. The system encodes the candidate strategies as strategy change records and filters them through rule gating to form a set of feasible strategies. Then, utility calculation and negotiation are performed to solve the problem. When the negotiation is deadlocked, the core participants refuse, or the set of feasible strategies is empty, the human-machine loop processing is initiated.

[0042] Table 5. Example Table of Operation Types for Strategy Change Records

[0043] Let the current performance status be s. t The candidate action or candidate strategy is a t The set of compliance constraints is C = {C1, C2, ..., C}. m The system does not directly execute the output of the generative model, but instead uses it as a candidate set A. candidate Part of it. The rules engine generates a set of feasible policies A based on executable constraint expressions and state transition tables. feasible : ; Among them, C j (s t ,a) represents the j-th hard constraint, such as the transacting entity not being on a sanctions list, the transaction amount not exceeding the letter of credit limit, the financing ratio not exceeding the credit line ratio, the destination not being a restricted region, and the task node not undergoing an illegal state transition, etc. ta) indicates whether the state transition corresponding to the candidate strategy conforms to the preset state transition table; Permission(a) indicates whether the proposer and the executor have the permission to access or modify the relevant fields; Signature(a) indicates whether the strategy record signature is valid; ReplayCheck(a) indicates whether the candidate strategy passes the idempotent execution and on-chain event sequence number verification.

[0044] In this embodiment, the utility function U of the i-th business intelligence agent i Calculations are based on performance time, performance costs, financing costs, credit risk, default losses, compliance risk, and status consistency risk. Each indicator is first normalized, and the normalized values ​​are denoted as T. i C i F i R i Q i and S i Then it can be calculated in the following form: ; Here, w1 to w7 are weight parameters corresponding to the business roles. The negotiation solution module can calculate the comprehensive score using weighted summation, constraint optimization, Nash negotiation model, or negotiation game model, depending on the scenario. If the utility changes of each agent are less than a preset threshold in multiple consecutive rounds of negotiation, and the current optimal strategy combination remains unchanged, then the negotiation is considered converged. If the number of negotiation rounds reaches the maximum number of rounds K... max A feasible If the value is empty, any core participant rejects all candidate strategies, there is an irresolvable rule conflict, or the on-chain and off-chain state verifications are inconsistent, the human-machine loop module will be triggered.

[0045] This invention employs a method of storing complete off-chain data and key on-chain evidence for evidence preservation. Business contracts, invoices, bills of lading, raw IoT data, risk control details, and complete task graphs are stored in off-chain business systems or trusted storage environments; the consortium blockchain records corresponding data hashes, state root hashes, timestamps, participant signatures, permission identifiers, and state events. For data involving trade secrets or personal information, field-level access control, anonymized storage, encrypted storage, or authorized access mechanisms can be used.

[0046] like Figure 6As shown, regarding on-chain and off-chain state consistency verification, the system performs normalized serialization of the off-chain task graph version number, task node state set, on-chain event sequence number, policy change record hash, and necessary document hash according to a preset field order, calculates the state root hash, and then compares the calculated state root hash with the consortium blockchain record. In one implementation, the normalized serialization uses UTF-8 encoding, a fixed field order, a fixed time format, fixed numerical precision, preset null value handling rules, and array sorting rules; the state root hash can be calculated using SM3, SHA-256, or equivalent hash algorithms. Participant signatures can be verified based on the consortium blockchain identity system; state events or policy change records that fail signature verification cannot be used as the basis for automatic execution.

[0047] ; Here, `ordered(task_state_set)` represents the set of states sorted by task node identifier, state field, on-chain state field, and version number. `doc_hash` represents the hash set of necessary documents such as contracts, invoices, bills of lading, insurance policies, temperature control records, or receipt confirmations. The system compares the recalculated `stateRoot` with the `stateRoot` recorded on the consortium blockchain. If the comparison is inconsistent, the smart contract suspends automatic settlement, credit adjustment, and state updates, and triggers a manual review event.

[0048] In one implementation, the smart contract provides interfaces such as createTask, anchorHash, updateStatus, confirmDelivery, adjustCredit, freezeDispute, triggerSettlement, and triggerManualReview. When the smart contract detects that the customs clearance status is true, the goods receipt status is true, the document verification is passed, the state root hash is consistent, the on-chain event sequence number is continuous, the participant's signature is valid, and there are no unresolved disputes, the contract triggers a settlement instruction. If it detects a dispute freeze status, a rule conflict status, an inconsistent state root hash, a backtracking or discontinuous event sequence number, a missing necessary on-chain event, a missing necessary document hash, a replay verification failure, or a manual intervention status, the contract suspends automatic settlement and records audit events.

[0049] Taking the export of 1,000 tons of cold-chain agricultural products to Rotterdam as an example, the system first generates a baseline fulfillment task diagram based on business intent. Task nodes include order creation, cold chain quality inspection, booking, shipment, customs declaration, ocean freight tracking, import customs clearance, receipt confirmation, financing review, and settlement. During transportation, the logistics interface detects a typhoon causing a 90-hour delay in the estimated arrival time. Simultaneously, IoT devices report a short-term abnormality in cargo temperature, and the bank's risk control interface adjusts the risk score from B to C. Since the estimated arrival time delay, temperature anomaly, and risk score change all reach trigger thresholds, the system generates a replanning event.

[0050] The logistics agent proposed rerouting and additional insurance strategies; the bank agent proposed adjusting the prepayment financing ratio from 80% to 70% and increasing the margin; the importer agent proposed extending the receiving window and demanding compensation for breach of contract; and the exporter agent proposed supplementing temperature control records and providing additional guarantees. The rules engine eliminated strategies that would cause the financing ratio to exceed the credit limit, lack insurance documents, fail to sign, have insufficient permissions, cause event sequence number rollback, or result in illegal state transitions. The negotiation and solution module calculated the utility of the remaining strategies and ultimately selected a dynamic fulfillment plan: rerouting transportation, adding insurance, supplementing temperature control records, adjusting the financing ratio to 70%, and extending the receiving window by 48 hours. The system wrote the hash of this dynamic fulfillment plan, the hash of relevant documents, the hash of environment variables, the hash of strategy change records, and the signatures of the participating parties into the consortium blockchain and updated the task graph version.

[0051] If subsequent customs clearance, goods receipt, document verification, and status consistency verification all pass, the smart contract triggers fund settlement; if the temperature control record is inconsistent with the original IoT data hash, the on-chain event sequence number is rolled back, the necessary document hash is missing, or the importer raises a dispute, the smart contract triggers the freezeDispute interface to freeze the settlement and notifies the human-machine loopback module to conduct manual review.

[0052] The agent skill optimization module records samples such as parameter extraction errors, task dependency errors, rule matching errors, infeasible candidate strategies, unreasonable utility weight settings, incorrect tool call parameters, replay verification failures, and manual intervention results. Based on the failure reasons, the system generates suggested modifications such as prompts, task template modifications, or tool parameter modifications. To avoid new execution risks caused by model self-modification, any modification suggestions must undergo sandbox environment replay, test set verification, rule regression testing, and manual review before being updated to the production environment.

[0053] The access control and privacy protection module controls the scope of field access based on the participant's identity and task node permission policies. Sensitive fields such as bank risk control details, financing amounts, transaction prices, and personal identification information can be stored encrypted off-chain only, with hashes and permission identifiers recorded on-chain. When a participant requests access to off-chain data, the system performs authorization verification based on permission policies, data usage, and task node status.

[0054] This invention can be applied to cross-border trade digital fulfillment platforms, supply chain finance platforms, bank trade finance systems, port logistics collaboration systems, electronic document trusted storage systems, and cross-border settlement platforms. By combining task graph state machines, rule constraints, strategy change records, multi-agent negotiation, on-chain anchoring, state root consistency verification, and secure smart contract execution, this invention can adapt to cross-border trade scenarios involving multiple entities, multiple rules, and multiple abnormal events, and has good industrial applicability.

[0055] Example 3: A cross-border trade dynamic performance security execution device based on task graph state machine and rule constraints, comprising: one or more processors; Storage device for storing one or more program or resource data; When the one or more programs are executed by one or more processors, the one or more processors implement the cross-border trade dynamic performance security execution method based on task graph state machine and rule constraints in Embodiment 1.

[0056] Example 4: A storage medium for secure execution of dynamic cross-border trade performance based on task graph state machine and rule constraints, which stores a computer program that, when executed by a processor, implements the secure execution method for dynamic cross-border trade performance based on task graph state machine and rule constraints in Example 1.

Claims

1. A method for dynamic performance security in cross-border trade based on task graph state machine and rule constraints, characterized in that, Includes the following steps: S1. Receive cross-border trade business intents and structure them into standard intent parameters with transaction identifiers and version numbers; S2. Generate a performance task graph based on standard intent parameters. The performance task graph includes task nodes, node dependencies, state machine fields, on-chain state fields, compliance rule numbers, and permission policies. S3. Based on the performance task graph, call the preset rule library to convert the compliance rules, state transition rules and permission rules corresponding to the task nodes into executable constraint expressions, and pre-verify the performance task graph based on the executable constraint expressions to form a benchmark performance plan; S4. Collect environmental variables from an off-chain trusted data source that has been authenticated and authorized, generate state events, and generate a replanning event when the environmental variables meet preset triggering conditions; S5. In response to the replanning event, receive candidate fulfillment strategies proposed by an artificial intelligence model, business intelligence agent, or human participant, wherein the candidate fulfillment strategies are not used as the basis for direct automatic execution; parse the candidate fulfillment strategies into machine-verifiable strategy change records, and perform normalization processing on the strategy change records to generate strategy change record hashes. S6. Before the strategy change record enters the utility calculation, task state update or smart contract call, execute the strategy execution gate based on signature, permission, data authorization, state transition, rule constraint, on-chain preconditions and replay protection to block the strategy change record that has not passed the strategy execution gate and obtain a set of feasible strategies. S7. Perform utility calculation and negotiation on the set of feasible strategies to obtain a dynamic performance plan; S8. Calculate the state root hash based on the task graph version, task node state set, on-chain event sequence number, strategy change record hash, and necessary document hash, and perform a consistency comparison between the state root hash and the state root hash recorded in the consortium chain. S9. Settlement, credit adjustment, or status update shall be triggered through smart contract settlement gate only when the state root hash is consistent, the necessary events and necessary documents are complete, the signatures of the participants are valid, and there are no unresolved disputes; otherwise, the freeze shall be automatically executed and transferred to manual review.

2. The method for dynamic performance security execution in cross-border trade based on task graph state machine and rule constraints as described in claim 1, characterized in that, The standard intent parameters, task nodes, or candidate fulfillment strategies are generated by natural language processing models, generative models, large language models, or business intelligence agents as candidate generation sources, and the candidate results are not used as the basis for automatic execution before they are structured and parsed into preset field patterns and verified by field integrity, value range, field conflict, confidence threshold, rules, permissions, signature, replay, and on-chain state preconditions. The candidate generation source outputs candidate results based on business intent, task graph status, or replanning events. It is only used to generate candidate field values, candidate task nodes, or candidate strategy text, and does not have the authority to directly call smart contracts, directly modify task node status, or directly trigger settlement.

3. The method for dynamic performance security execution in cross-border trade based on task graph state machine and rule constraints according to claim 1, characterized in that, The performance task graph is a directed acyclic graph. The task nodes include at least one of the following: order creation, quality inspection confirmation, document upload, booking, shipment, customs declaration, customs clearance status confirmation, transportation status reporting, financing review, goods receipt confirmation, and fund settlement. Each task node is only allowed to change its status according to a preset status migration table, and it cannot directly enter the completed, pending settlement, or settled status without prior evidence, necessary document hash, on-chain status event, or authorization signature.

4. The method for dynamic performance security execution in cross-border trade based on task graph state machine and rule constraints as described in claim 1, characterized in that, The executable constraint expression includes rule number, field identifier, comparison operator, threshold parameter, state condition, authorization subject, data source identifier, signature requirement, failure handling action, and priority identifier; the gating includes strategy execution gating and smart contract settlement gating; the strategy execution gating is executed in the following order: signature gating, permission gating, data authorization gating, state gating, rule gating, on-chain pre-processing gating, and replay gating, wherein the signature gating verifies the proposer's signature and the data source signature, the permission gating verifies the proposer's role and field modification permissions, the data authorization gating verifies off-chain data access authorization, and the state gating verifies the target... The system checks whether the target state conforms to the preset state transition table, verifies the executable constraint expression using rule gating, verifies the on-chain event sequence number and necessary events using on-chain pre-gating, and verifies the anti-replay random number, idempotent execution flag, and time window using replay gating. When any of the policy execution gating or smart contract settlement gating fails, it blocks the corresponding policy change record from entering utility calculation, task state update, or smart contract call, sets the relevant task node to a paused, pending manual review, or disputed freeze state, and generates an audit log containing the failure gating number, failure field value, current state, target state, proposer, timestamp, and record hash.

5. The method for dynamic performance security execution in cross-border trade based on task graph state machine and rule constraints according to claim 1, characterized in that, The off-chain trusted data source includes at least one of the following: IoT devices, customs data interface, shipping company or logistics platform interface, meteorological interface, exchange rate interface, bank risk control interface, and electronic document system; the environmental variables include at least one of the following: estimated arrival time, transportation cost, customs clearance status, weather risk, exchange rate change, cargo location, cargo temperature and humidity, cargo abnormal status, and financing risk score; the preset trigger conditions include at least one of the following: time deviation, cost increase, exchange rate fluctuation, cargo abnormality, customs clearance delay, financing risk change, and task timeout; the status event includes at least one of the following: data hash, source signature, permission identifier, timestamp, on-chain event sequence number, data source certificate identifier, and anti-replay random number, and the on-chain event sequence number is allocated or confirmed by the consortium blockchain smart contract, consortium blockchain node consensus service, or trusted sequence service.

6. The method for dynamic performance security execution in cross-border trade based on task graph state machine and rule constraints according to claim 1, characterized in that, The strategy change record includes at least one of the following: transaction identifier, task graph version number, strategy change record identifier, task node identifier, operation type, state before change, target state, parameters before change, target parameters, effective conditions, proposer, timestamp, on-chain event sequence number, anti-replay random number, idempotent execution identifier, signature, reason code, and data authorization identifier, authorization scope identifier, or authorization credential hash. Before being written to the consortium blockchain, participating in utility calculation, task state update, or state root hash calculation, the strategy change record is standardized and serialized according to a fixed field order, encoding format, time format, null value handling rules, array sorting rules, and numerical precision rules, and a strategy change record hash is generated.

7. The method for dynamic performance security execution in cross-border trade based on task graph state machine and rule constraints according to claim 1, characterized in that, The utility calculation only processes the set of feasible strategies that are gated through all strategies, and normalizes at least two indicators among performance time, performance cost, financing cost, credit risk, default loss, compliance risk and state consistency risk and calculates the comprehensive utility. When the set of feasible strategies is empty, the negotiation fails to converge, the core participants reject the candidate strategy, there is an irresolvable compliance conflict, the on-chain and off-chain states are inconsistent, the event sequence number is discontinuous or the necessary document hash is missing, the freeze is automatically executed and the human-machine loopback module outputs the dispute point, conflict cause, candidate strategy record, failure gating number, state root comparison result and alternative solution.

8. A dynamic contract fulfillment security execution system for cross-border trade based on task graph state machine and rule constraints, characterized in that, include: The intent parsing module is used to output cross-border trade business intents as standard intent parameters; The task graph generation module is used to generate a performance task graph that includes state machine fields, on-chain state fields, compliance rule numbers, permission policies, and exception handling policies. The rules engine module is used to convert rules into executable constraint expressions and execute gating strategies in the order of signature, permissions, data authorization, state, rules, on-chain pre-processing and replay. The environment awareness module is used to collect data from off-chain trusted data sources that have been authenticated and authorized, generate state events, and determine whether to trigger replanning. The negotiation solution module encodes candidate performance strategies into strategy change records and performs utility calculations and generates dynamic performance solutions only for the set of feasible strategies that have passed all gating. The state consistency verification module is used to calculate the state root hash according to the normalized serialization rules and compare it with the state root hash and event sequence number recorded in the consortium blockchain. The on-chain anchoring module is used to write hashes, state events, timestamps, and participant signatures into the consortium blockchain; The smart contract execution module is used to execute settlement, credit adjustment or status update when the state root is consistent, the events and documents are complete, the signature is valid and there are no unresolved disputes, based on the settlement gate; otherwise, it will execute dispute freezing or manual review triggering. The human-machine loop module is used to freeze automatic execution and trigger manual review when gating fails, negotiation deadlocks or consistency verification fails. The access control and privacy protection module is used for access control, de-identification, or encryption. The intelligent agent skill optimization module is used to record failure samples such as candidate parsing failure, gating failure, and manual review results. After sandbox replay, rule regression testing, and manual review, the module updates the model prompt words or task arrangement template. The update does not directly change the smart contract execution rules. The above modules enable the implementation of the cross-border trade dynamic performance security execution method based on task graph state machine and rule constraints as described in claim 1.

9. A cross-border trade dynamic performance security execution device based on task graph state machine and rule constraints, characterized in that, include: One or more processors; Storage device for storing one or more program or resource data; When the one or more programs are executed by one or more processors, the one or more processors implement the cross-border trade dynamic performance security execution method based on task graph state machine and rule constraints as described in any one of claims 1 to 7.

10. A storage medium for secure execution of dynamic contract fulfillment in cross-border trade based on task graph state machine and rule constraints, characterized in that, It stores a computer program that, when executed by a processor, implements the cross-border trade dynamic performance security execution method based on task graph state machine and rule constraints as described in any one of claims 1 to 7.

Images