Dual-mode data playback verification method, device, system and medium based on immutable snapshot

Abstract

The embodiment of the specification provides a kind of immutable snapshot-based dual-mode data playback verification method, device, system and medium. In response to the playback verification request for target historical event, only read original input data, historical rule snapshot and historical execution result snapshot from immutable storage medium;Response to instruction type routing to first playback mode or second playback mode;First playback mode excludes dynamic semantic generation logic, and only based on static check algorithm, compliance consistency is verified;Second playback mode recalculates historical input in isolated computing environment by calling current semantic generation engine and current rule set, generates simulated output result and calculates data difference index;Output verification result and prohibit modification original data in immutable storage medium.

Description

Technical Field

[0001] This specification relates to the fields of artificial intelligence, data governance and software engineering technology, and in particular to a dual-mode data playback verification method, apparatus, system and medium based on immutable snapshots. Background Technology

[0002] As AI systems evolve from dialogue generation systems to intelligent agent systems capable of performing complex tasks, these systems typically continuously receive external inputs, invoke tools, generate intermediate inference results, and output decision outcomes during operation. In scenarios such as finance, healthcare, education, and enterprise automation, the historical behavior of intelligent agent systems often needs to be audited, reviewed, or reassessed. In long-term operational scenarios, the model version, rule set, prompting strategy, external interfaces, and business constraints of intelligent agent systems may continuously change over time. Auditing a historical event requires not only confirming whether the event met the rule constraints at the time of its occurrence but also assessing whether the current model or rules produce different results after reprocessing the historical input. However, these two types of audit requirements correspond to different technical processing objectives—the former emphasizes the consistency verification of historical evidence and historical rules, while the latter emphasizes the analysis of differences brought about by model evolution or rule changes—failure to distinguish between them could allow compliance judgments to be interfered with by the uncertain output of the current model. Furthermore, if intermediate results or simulated outputs generated during playback are incorrectly written into historical data storage, the integrity and traceability of historical evidence may be compromised. Therefore, in the above scenario, there is a need for a technical solution that can distinguish between compliance verification and comparative simulation assessment based on immutable historical snapshots, and avoid modifying the original historical data by replaying the results. Summary of the Invention

[0003] This specification provides a dual-mode data replay verification method based on immutable snapshots. This method can be executed by a computing device and may include: in response to a replay verification request for a target historical event, reading-only acquiring the original input data, historical rule snapshots, and historical execution result snapshots corresponding to the target historical event from an immutable storage medium; in response to the instruction type in the replay verification request, routing the execution flow to a first replay mode or a second replay mode; in response to entering the first replay mode, verifying the compliance consistency between the original input data, historical rule snapshots, and historical execution result snapshots based on a static verification algorithm, excluding dynamic semantic generation logic; in response to entering the second replay mode, invoking the currently active semantic generation engine and the current rule set in an isolated computing environment to reprocess the original input data, generate simulated output results, and calculate the data difference index between the simulated output results and the historical execution result snapshots; outputting the verification result, and prohibiting modification of the original data in the immutable storage medium by the verification result at the physical layer.

[0004] Optionally, the static verification algorithm in the first replay mode may include cryptographically verifying the integrity of the hash chain in the underlying storage of historical execution result snapshots. Furthermore, the permission signature in the historical execution result snapshot can be extracted and verified using the public key in the historical rule snapshot to confirm whether the historical execution result corresponds to the permission environment in effect at that time.

[0005] Optionally, when obtaining a snapshot, the evidence anchor pointer in the historical execution result snapshot can be parsed, and the original interactive byte stream can be recursively pulled from the underlying ledger based on the evidence anchor pointer, so that the replay verification depends on the traceable underlying original data.

[0006] Optionally, before the second replay mode is executed, the network write permissions of the isolated computing environment to the external real business system can be cut off to prevent the simulation from producing real business side effects.

[0007] Optionally, calculating the data difference index may include semantic drift calculation. Specifically, historical execution result snapshots and simulation output results can be converted into old decision vectors and new decision vectors, respectively, and the distance between the old and new decision vectors in multidimensional space can be calculated to obtain the semantic drift index. Optionally, this distance can be the normalized cosine distance.

[0008] Optionally, the calculated data difference index may also include trade-off reversal detection. Trade-off dimension data can be extracted from historical execution result snapshots and simulation output results, and the trend of the two on preset key indicators can be compared; in response to the detection of a reversal of the trend, a trade-off reversal alarm can be marked in the verification results.

[0009] Optionally, the output verification results may include attaching a simulated derivative tag to the verification results and storing the verification results with the simulated derivative tag in an audit database. The audit database may be physically isolated from the immutable storage media of the production environment.

[0010] Optionally, the verification results may include at least one of the following: replay mode identifier, target historical event identifier, historical rule snapshot identifier, historical execution result snapshot identifier, compliance consistency verification result, semantic drift metric, trade-off reversal alarm, and evidence anchor point verification result.

[0011] Accordingly, embodiments of this specification provide an interactive method for historical decision auditing. This method can be executed by an audit client and may include: sending a replay request containing a timestamp range and a target event identifier to the server; specifying a replay mode in the replay request; in response to specifying a second replay mode, injecting hypothetical rule parameters for sandbox simulation or a specified version of the inference model into the replay request; receiving a structured discrepancy report returned by the server; and aligning and rendering historical decision primitives and simulated decision primitives in a visualization interface, highlighting the dimension nodes where trade-offs have occurred. Optionally, the audit client may support counterfactual parameter fine-tuning. In response to the audit user adjusting the threshold in the hypothetical rule parameters through the interactive interface, an updated replay request is generated to trigger the server to re-execute the second replay mode. Optionally, in response to receiving a hash chain break alarm returned by the first replay mode, the audit client may block subsequent business logic and generate an evidence report.

[0012] Based on the same technical concept, embodiments of this specification provide a dual-mode data replay verification device based on immutable snapshots. This device may include a read-only acquisition module, a mode routing module, a static verification module, a sandbox simulation module, a difference calculation module, and an output and write barrier module. The read-only acquisition module can be used to read-only acquire the original input data, historical rule snapshots, and historical execution result snapshots from the immutable storage medium in response to a replay verification request for a target historical event. The mode routing module can be used to route the execution flow to a first replay mode or a second replay mode in response to the instruction type in the replay verification request. The static verification module can be used to verify compliance consistency based on a static verification algorithm in response to entering the first replay mode, excluding dynamic semantic generation logic. The sandbox simulation module can be used to call the currently effective semantic generation engine and the current rule set in an isolated computing environment to reprocess the original input data and generate simulated output results in response to entering the second replay mode. The difference calculation module can be used to calculate the data difference index between the simulated output results and the historical execution result snapshots. The output and write barrier module can be used to output the verification results and prohibit the verification results from modifying the original data in the immutable storage medium at the physical level.

[0013] Based on the same technical concept, embodiments of this specification provide a historical decision auditing interactive device. This device may include a request sending module, a parameter injection module, a report receiving module, and a visualization rendering module. The request sending module can be used to send a playback request containing a timestamp range and a target event identifier to the server, and specify a playback mode in the playback request; the parameter injection module can be used to inject hypothetical rule parameters for sandbox inference or a specified version of the inference model into the playback request in response to the specified second playback mode; the report receiving module can be used to receive a structured difference report returned by the server; the visualization rendering module can be used to align and render historical decision primitives and simulated decision primitives in a visualization interface, and highlight the dimension nodes where trade-offs have occurred.

[0014] Based on the same technical concept, embodiments of this specification provide a dual-mode data playback verification system based on immutable snapshots. This system may include a read-only cascaded acquisition module, a mode routing gateway, a static verification engine, an isolation sandbox deduction engine, a difference calculation component, and a physical write barrier component. The read-only cascaded acquisition module can be used to synchronously extract historical inputs, historical rules, and historical results from the underlying storage; the mode routing gateway can be used to distribute execution flows according to instruction types; the static verification engine can be used to perform cryptographic verification and logical rule verification; the isolation sandbox deduction engine can be used to load the currently effective semantic generation engine and the current rule set to recalculate historical inputs and generate simulated output results; the difference calculation component can be used to compare the semantic drift and trade-offs between the simulated output results and the historical execution result snapshots; and the physical write barrier component can be used to intercept modification requests to the original historical data in the immutable storage medium.

[0015] Based on the same technical concept, embodiments of this specification provide an electronic device. This electronic device may include a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the aforementioned dual-mode data playback verification method or historical decision audit interaction method based on immutable snapshots.

[0016] Based on the same technical concept, embodiments of this specification provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the aforementioned dual-mode data playback verification method or historical decision audit interaction method based on immutable snapshots.

[0017] Through the above technical solutions, the embodiments of this specification divide the historical replay process into a first replay mode and a second replay mode. The first replay mode excludes dynamic semantic generation logic and performs verification solely based on historical rule snapshots, historical execution result snapshots, and static verification algorithms. Therefore, it helps avoid interference from current model changes on historical compliance verification and meets the requirement for consistency verification between historical evidence and historical rules. The second replay mode calls the current semantic generation engine and current rule set in an isolated computing environment to reprocess historical inputs and calculates the data difference index between the simulated output results and the historical execution result snapshots. Therefore, it helps quantify the impact of model or rule evolution on historical decision-making logic and meets the need for difference analysis of model evolution and rule changes. Simultaneously, since the data corresponding to the replay verification request is read-only obtained from an immutable storage medium, and the verification results are prohibited from modifying the original data in the immutable storage medium, it can maintain the stability and traceability of historical evidence while preventing the replay results from contaminating the original historical data, meeting the requirement of distinguishing between compliance verification and comparative simulation evaluation while protecting the integrity of historical evidence. Furthermore, by using semantic drift metrics and trade-off reversal alerts, auditors can not only observe whether the output results are different, but also identify whether the decision-making basis, trade-off bias, or key dimension direction has changed, thereby improving the audit interpretability and model governance capabilities of long-term intelligent agent systems. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a dual-mode data playback verification method based on immutable snapshots, provided for some embodiments of this specification.

[0019] Figure 2 This is a schematic diagram of the processing flow of a first playback mode provided for some embodiments of this specification.

[0020] Figure 3 This is a schematic diagram illustrating the processing flow of a second playback mode provided for some embodiments of this specification.

[0021] Figure 4 This is a schematic diagram illustrating a data difference index calculation process provided for some embodiments of this specification.

[0022] Figure 5 This is a flowchart illustrating an interactive method for historical decision auditing, provided for some embodiments of this specification.

[0023] Figure 6 This is a schematic diagram of the structure of a dual-mode data playback verification device based on an immutable snapshot, provided for some embodiments of this specification.

[0024] Figure 7 This is a schematic diagram of the structure of a dual-mode data playback verification system based on an immutable snapshot, provided for some embodiments of this specification.

[0025] Figure 8 This is a schematic diagram of the structure of a computing device provided for some embodiments of this specification. Detailed Implementation

[0026] In the embodiments of this specification, "immutable storage medium" can be a ledger database using an append-only write mode, a hash chain database, a storage system with write-once-read-many characteristics, a blockchain ledger, a log storage system with tamper-proof verification mechanisms, or other data storage media capable of restricting the updating and deletion of historical data. In some embodiments, the immutable storage medium can be configured to reject update and deletion instructions for historical records and maintain the integrity relationship between historical records through hash chains, signatures, timestamps, or evidence anchors.

[0027] In one specific implementation, the immutable storage medium may include a ledger record table, a rule snapshot table, and an execution result snapshot table. The ledger record table adopts an append-only write mode and includes at least the following fields: record identifier (ledger_id), previous hash (prev_hash), payload hash (payload_hash), current record hash (record_hash), physical timestamp (timestamp), rule version identifier (policy_version), permission signature (signature), and evidence anchor pointer (anchor_ptr). Database accounts can be divided into read-only audit accounts, append-only write accounts, and management accounts. The audit playback service only holds read-only audit account permissions and cannot perform UPDATE, DELETE, or overwrite write operations.

[0028] In the embodiments of this specification, "historical rule snapshot" can represent a set of rules, permission configurations, public key information, risk thresholds, policy version identifiers, model constraint parameters, or combinations thereof that were in effect when the target historical event occurred. Historical rule snapshots can be stored in the form of structured data, versioned configuration files, ledger records, or evidence anchors. For example, a historical rule snapshot may include the following fields: policy_version, effective_from, effective_to, public_key_set, risk_threshold, permission_matrix, static_rule_hash, model_constraint_hash, and signature_algorithm. Among these, public_key_set can be used to verify the permission signature in the historical execution results, and effective_from and effective_to can be used to determine whether the rule snapshot was valid when the target historical event occurred.

[0029] In the embodiments of this specification, "historical execution result snapshot" can represent the output results, decision primitives, operation records, permission signatures, evidence anchors, hash values, rule version identifiers, timestamps, or combinations thereof formed when a target historical event occurred. Historical execution result snapshots can be used to prove how the target historical event was processed at that time. In some embodiments, historical execution result snapshots may include decision goals, historical chosen execution paths (chosen_path), historical rejected alternative paths (rejected_paths), historical trade-offs, unknowns, input hash (input_hash), rule version identifier (policy_version), permission signature (auth_signature), and evidence anchor (evidence_anchor). These fields are not only used to reconstruct historical output content but also to support semantic drift calculation and trade-off detection in the second replay mode.

[0030] The "raw input data" in the embodiments of this specification may include user commands, environment states, tool invocation requests, context fragments, intermediate data generated internally by the agent, return values ​​from external systems, or combinations thereof. Raw input data may be stored as raw interactive byte streams, standardized event objects, or verifiable payloads.

[0031] The "semantic generation engine" in the embodiments of this specification may include a large language model, a neural network generation model, a rule-enhanced generation model, an agent reasoning engine, a prompt word arrangement engine, or other models or programs capable of generating output results based on the input context. The currently active semantic generation engine may be different from the semantic generation engine used when the target historical event occurred.

[0032] In the embodiments of this specification, "dynamic semantic generation logic" refers to the logic that regenerates natural language or decision paths based on a probabilistic model, the current prompt word template, the current model parameters, or the current inference strategy. The first replay mode explicitly excludes this type of logic and only performs deterministic cryptographic verification, signature verification, rule version comparison, and static rule consistency verification.

[0033] In some embodiments, the intelligent agent system can employ a multi-layered, isolated data governance architecture. During operation, the system can write raw interaction data to an immutable record layer and generate structured decision objects or decision primitives based on the established data. Structured decision objects may include fields such as objectives, selected execution paths, abandoned alternative paths, trade-off dimension data, unknown information items, and evidence anchors. The immutable record layer can store original inputs, rule snapshots, historical execution results, and the evidentiary relationships between them.

[0034] When regulators, system administrators, model governance personnel, or auditing procedures need to review a historical event, they can send a replay verification request to the replay verification service. This request can specify the target historical event, timestamp range, replay mode, audit purpose, hypothetical rule parameters, or a specific version of the inference model. The replay verification service can select different execution modes based on the type of instructions in the request.

[0035] In one approach, the system can directly call the current model to rerun historical inputs and compare the results. However, if this approach does not distinguish between audit purposes, the uncertainty of the current model or changes in current rules may affect historical compliance judgments. Furthermore, if the rerun results are incorrectly written back to the production ledger, it may contaminate the original historical evidence. Therefore, this specification provides a dual-mode replay mechanism, separating the first replay mode used for historical compliance verification from the second replay mode used for model governance analysis, and preventing the replay results from modifying the original historical data through read-only access and physical write barriers. Specifically, the first replay mode answers the question of "whether the historical event was compliant and whether the evidence was complete at the time"; the second replay mode answers the question of "how the results would change if the same historical input were processed using the current model, current rules, or hypothetical rule parameters." The inputs for both modes can be the same, but the calculation logic, output labels, storage locations, and legal meanings are different. The result of the first replay mode can be used as a compliance consistency verification result; the result of the second replay mode is only used as a simulated derivative result and does not change the historical facts.

[0036] Figure 1 This is a flowchart illustrating a dual-mode data playback verification method based on immutable snapshots, provided for some embodiments of this specification. Figure 1 The method shown may include the following steps:

[0037] Step S110: In response to the replay verification request for the target historical event, read-only acquire the original input data, historical rule snapshot, and historical execution result snapshot corresponding to the target historical event from the immutable storage medium.

[0038] In step S110, the computing device can receive a replay verification request. The replay verification request can originate from an audit client, a regulatory interface, a model governance platform, a scheduled audit scheduler, or other business systems. The replay verification request may include at least one of the following: target event identifier, timestamp range, tenant identifier, agent identifier, replay mode identifier, audit task identifier, authorization credentials, hypothetical rule parameters, and identifier of a specified version of the inference model. The target historical event can correspond to an event in which an agent receives input, executes rule judgments, generates decisions, invokes tools, or outputs results at a historical time point. The target historical event can be located using a globally unique event identifier, ledger record identifier, structured decision object identifier, evidence anchor pointer, or timestamp range.

[0039] Computing devices can access immutable storage media in read-only mode. Read-only access can be achieved through database read-only accounts, read-only mounts, access control lists, storage tier permission policies, file system read-only mounts, read-only query methods of the ledger interface, or combinations thereof. Read-only access prevents the replay verification process from updating, deleting, or overwriting historical raw data. In specific implementations, the replay verification service can mount the immutable storage media in read-only mode upon startup and set write request interception rules in the storage access agent. If the audit replay process sends INSERT, UPDATE, DELETE, MERGE, TRUNCATE, PUT, or overwrite write requests to the immutable storage media, the storage access agent can directly return a rejection status code and record it in the security audit log.

[0040] In some embodiments, the original input data, historical rule snapshots, and historical execution result snapshots can reside in different storage domains. For example, the original input data can reside in the underlying ledger or original event storage, the historical rule snapshots can reside in the policy version repository, and the historical execution result snapshots can reside in the immutable record layer or the structured cognitive layer. The computing device can perform cascading queries using target historical event identifiers to simultaneously extract the three types of data.

[0041] In some embodiments, historical execution result snapshots may include evidence anchor pointers. Evidence anchor pointers may point to underlying ledger records, original interaction byte streams, hash values, public key versions, rule versions, or other verifiable data. The computing device can parse the evidence anchor pointers and recursively retrieve the original interaction byte streams from the underlying ledger based on them. For example, historical execution result snapshots may contain fields such as `ledger_id`, `prev_hash`, `payload_hash`, `policy_version`, and `signature_id`. The computing device can query ledger records based on `ledger_id`, locate the original input data based on the `payload_hash` in the ledger record, and query historical rule snapshots based on `policy_version`. The recursive fetching process may include: first, reading the `evidence_anchor` from the historical execution result snapshot; second, parsing the `ledger_id` and `payload_hash` in the `evidence_anchor`; third, querying the corresponding ledger record based on the `ledger_id`; if the ledger record references a previous record or original event fragment, then continuing to read the previous record or fragment based on `prev_hash` or `segment_ptr`; finally, recalculating the hash value of the read original interaction byte stream and performing a consistency comparison with `payload_hash`. If the comparison fails, the evidence anchor verification failure is recorded in the verification result. Through the above method, the original input data, historical rule snapshots, and historical execution result snapshots output in step S110 have a traceable relationship, which is beneficial for compliance consistency verification in the subsequent first replay mode and also beneficial for comparative simulation evaluation in the second replay mode.

[0042] In step S120, in response to the instruction type in the playback verification request, the execution stream is routed to either the first playback mode or the second playback mode.

[0043] In step S120, the computing device can parse the instruction type in the replay verification request. The instruction type can be determined by the replay mode identifier, audit purpose field, request path, interface type, task template, or permission policy. The first replay mode can be used to verify the compliance consistency of historical events under historical rule snapshots. In this mode, the system can exclude dynamic semantic generation logic and not call the current large language model or current semantic generation engine for regeneration. The processing object of the first replay mode is the historical evidence itself, and the processing goal is to determine whether the relationship between historical inputs, historical rules, and historical execution results is consistent, complete, and verifiable. The second replay mode can be used to compare and evaluate the differences generated by the current semantic generation engine and the current rule set after reprocessing historical inputs. In this mode, the system can perform simulation in an isolated computing environment, generate simulation output results, and calculate the differences between them and the historical execution result snapshot. The processing goal of the second replay mode is not to change historical conclusions, but to evaluate the output differences that may be caused by model evolution, rule updates, or changes in assumed parameters.

[0044] In some embodiments, pattern routing can be performed through a pattern routing gateway. The pattern routing gateway can check requester permissions, target historical event status, request parameter integrity, and target storage availability. In response to a request specifying a first replay mode, the pattern routing gateway can forward the execution flow to the static verification engine. In response to a request specifying a second replay mode, the pattern routing gateway can forward the execution flow to the isolation sandbox simulation engine. The pattern routing gateway can also perform mutual exclusion checks: when the audit purpose field of the request is LEGAL_PROOF, REGULATORY_AUDIT, or CHAIN_INTEGRITY, only the first replay mode is allowed; when the audit purpose field of the request is MODEL_UPGRADE_EVALUATION, COUNTERFACTUAL_TEST, or POLICY_SANDBOX, the second replay mode is allowed. If a request declares both a first and a second replay mode, the pattern routing gateway can reject the request or split it into two independent audit tasks to avoid confusion between compliance verification results and simulation results. By using explicit pattern routing, the system can avoid conflating simulation results used for model governance with historical compliance proofs, and can also avoid introducing uncertain outputs of the current model when legal evidence verification is required.

[0045] Step S130: In response to entering the first replay mode, without excluding dynamic semantic generation logic, verify the compliance consistency between the original input data, historical rule snapshots and historical execution result snapshots based on the static verification algorithm.

[0046] Figure 2This is a schematic diagram illustrating the processing flow of a first playback mode, provided as an example of some embodiments of this specification. Figure 2 The illustrated embodiment may include the following processing steps: The first replay mode may include at least one of hash chain integrity verification, permission signature verification, rule version consistency verification, and result consistency verification.

[0047] The first replay mode excludes dynamic semantic generation logic. In other words, in this mode, the computing device may not invoke the currently active semantic generation engine, nor may it invoke the current version of the large language model to regenerate results from historical input. This avoids changes in current model parameters, current prompting strategies, or current rules affecting historical compliance judgments. In engineering implementation, the execution container corresponding to the first replay mode may not mount model invocation credentials or configure a model service address; its runtime dependencies only include a hash library, signature verification library, rule parser, and read-only data access components. Therefore, even if the current semantic generation engine has been upgraded, the first replay mode will not be affected by the randomness of the current model output.

[0048] In some embodiments, the computing device can verify the integrity of the hash chain of historical execution result snapshots in the underlying storage based on a cryptographic algorithm. Hash chain integrity verification may include: obtaining the current hash value of the ledger record corresponding to the historical execution result snapshot; obtaining the hash value of its predecessor record; concatenating the predecessor record hash value, the current record payload, timestamp, signature data, or other system fields byte-wise; performing a cryptographic hash operation on the concatenated data; and comparing the calculated hash value with the hash value stored in the ledger. If they match, it can be confirmed that the chain relationship between the record and its predecessor record has not been broken; if they do not match, a hash chain break alarm can be generated. The cryptographic hash algorithm can be SHA-256, SHA-3, SM3, or other hash algorithms with collision resistance. The hash chain structure can be a linear hash chain, a Merkle tree, a Merkle directed acyclic graph, or other tamper-proof data linking structures.

[0049] For example, let the i-th ledger record be L_i, its preceding record hash be H_{i-1}, its current payload be payload_i, its physical timestamp be ts_i, and its signature data be sig_i. Then, the static verification engine can calculate H_i' = Hash(H_{i-1}|| payload_i || ts_i || sig_i), where "||" represents byte concatenation, and Hash represents SHA-256, SM3, or other cryptographic hash functions. If H_i' matches the record_hash stored in the ledger, the chain integrity verification of this record passes; if they do not match, a HASH_CHAIN_BROKEN alarm is output.

[0050] In some embodiments, the computing device can also extract the permission signature from historical execution result snapshots and verify the signature using the public key in the historical rule snapshot. The permission signature can be generated by the authorizing subject, policy access control node, execution node, or trusted signature service at the time of historical execution. The historical rule snapshot can store the public key, certificate chain, signature algorithm identifier, permission level, or subject identity mapping relationship that was valid at that time. The computing device can verify the permission signature based on the public key in the historical rule snapshot to determine whether the historical execution result was generated by the authorized subject or system component at that time. Permission signature verification can specifically include: extracting auth_signature, signing_subject, and signature_algorithm from the historical execution result snapshot; reading the public_key corresponding to signing_subject from the historical rule snapshot; and performing signature verification on the data to be verified based on signature_algorithm. The data to be verified may include the target event identifier, input hash, output hash, rule version identifier, timestamp, and permission scope. If the signature verification fails, the verification result can be marked with SIGNATURE_INVALID; if the signing subject is not in the list of authorized subjects in the historical rule snapshot, it can be marked with UNAUTHORIZED_SUBJECT.

[0051] In some embodiments, compliance consistency verification may further include: verifying whether the rule version identifier recorded in the historical execution result snapshot is consistent with the historical rule snapshot identifier; verifying whether the hash value of the original input data is consistent with the input hash field in the historical execution result snapshot; verifying whether the timestamp in the historical execution result snapshot is within the validity period of the historical rule snapshot; and verifying whether the status of the target historical event is submitted, authorized, or other auditable status. Further, the static verification engine can perform logical consistency verification on the historical execution result snapshot based on the deterministic rules stored in the historical rule snapshot. For example, if the historical rule snapshot stipulates that an external payment operation must be rejected when the risk_score is greater than 0.8, the static verification engine reads the risk_score and operation_type from the historical execution result snapshot; if the operation_type is PAYMENT and the risk_score is greater than 0.8, but the historical execution result shows ALLOW, then a STATIC_RULE_MISMATCH alarm is output. This process does not require calling a large language model, but rather reviews the deterministic rules in the historical snapshot.

[0052] The verification results output in the first replay mode can include compliance consistency verification results, hash chain integrity results, permission signature verification results, rule version consistency results, evidence anchor verification results, and alarm information. These verification results can be used to prove whether a historical event met the static rules and evidence constraints at that historical point in time.

[0053] In step S140, in response to entering the second replay mode, the currently active semantic generation engine and the current rule set are invoked in the isolated computing environment to reprocess the original input data, generate simulated output results, and calculate the data difference index between the simulated output results and the historical execution result snapshot.

[0054] Figure 3 This is a schematic diagram illustrating the processing flow of a second playback mode, provided as an example of some embodiments of this specification. Figure 3 The illustrated embodiment may include the following processing steps: The second replay mode may include isolation environment preparation, loading of the current model and current rules, recalculation of historical inputs, generation of simulated outputs, and calculation of differences.

[0055] The second replay mode can be used to answer the following technical questions: What simulated output results would be obtained if the currently active semantic generation engine and the current rule set were used to process the original input data from the past, and what differences would exist between the simulated output results and the historical execution results? This mode is beneficial for evaluating changes in system behavior before and after model upgrades, rule adjustments, threshold changes, or policy iterations.

[0056] In some embodiments, before the second replay mode is executed, the system can sever the isolated computing environment's network write permissions to the external real business system. The isolated computing environment can be a containerized virtual environment, a virtual machine, a sandbox process, an isolated namespace, a restricted network environment, a simulation cluster, or other computing environments with isolation capabilities. Severing network write permissions can include prohibiting access to the real transaction system, the real notification system, the real database write interface, the real tool call interface, or other external systems that will produce real side effects. The isolated computing environment can only allow access to the simulation stub service, the read-only model repository, the read-only rule base, the audit database, or restricted test interfaces. Specifically, before starting the second replay mode task, the isolated sandbox inference engine can execute the following environmental constraints: First, set the container network policy to `egress-deny-by-default`; second, only allow access to the whitelisted model inference service, simulation stub service, and audit database; third, configure the production transaction interface, the production message queue, the production database write interface, and the real tool call interface as unreachable; fourth, redirect tool call requests generated within the sandbox to the simulation stub service. With the above constraints, even if the current semantic generation engine generates simulated operations such as "placing an order", "making a payment", or "sending a notification", it will not have any side effects on the real business system.

[0057] In some embodiments, the currently active semantic generation engine can be the currently deployed large language model, the current inference model, the current agent decision engine, or the current prompt word orchestration system. The current rule set can include the current policy version, the current threshold, the current permission rules, the current risk model parameters, the current static rules, or a combination thereof. If hypothetical rule parameters or a specified version of the inference model are injected into the replay verification request, the isolation sandbox inference engine can override the default current rule set or model version based on the parameters in the request, but this override only takes effect in sandbox inference.

[0058] Simulation output can include simulated decision primitives, simulated execution paths, simulated rejection paths, simulated trade-offs dimension data, simulated risk scores, simulated tool call plans, simulated response text, or other structured output. Simulation output can be labeled as simulated data and is not considered a modification of historical execution results. To facilitate variance calculation, the isolated sandbox inference engine can require the current semantic generation engine to output simulated decision primitives according to a preset structured pattern. This structured pattern includes at least the fields: goal, chosen_path, rejected_paths, trade_offs, unknowns, risk_score, tool_plan, and model_version. If the current semantic generation engine outputs unstructured text, the sandbox inference engine can call a structured parser to convert it into simulated decision primitives, or determine that the simulation output does not meet the variance calculation requirements and record a FORMAT_INVALID status.

[0059] Figure 4 This is a schematic diagram illustrating a data difference index calculation process, provided as an example of some embodiments of this specification. Figure 4 The illustrated embodiment may include the following processing steps: data difference indicators may include semantic drift indicators and trade-off reversal alarms.

[0060] In some embodiments, the semantic drift metric can be calculated by converting a snapshot of historical execution results into an old decision vector and converting the simulated output results into a new decision vector; then calculating the distance between the old and new decision vectors in a multidimensional space. The old and new decision vectors can be encoded based on decision objectives, selected execution paths, rejection paths, trade-offs, risk levels, or other structured fields. Vectorization can employ text embedding models, feature encoders, rule encoders, classification label encoding, or combinations thereof. In one specific implementation, the difference calculation module can concatenate the goal, chosen_path, and trade_offs from the historical execution result snapshot into historical decision text, and concatenate the goal, chosen_path, and trade_offs from the simulated output results into simulated decision text, and input these into the same embedding model to obtain the old decision vector V_old and the new decision vector V_new. To avoid model differences affecting the comparison results, the embedding model can be a fixed-version encoder specified for the audit task, and its version identifier is recorded in the verification results.

[0061] Optionally, cosine distance can be used to calculate the semantic drift metric. Let the old decision vector be V_old and the new decision vector be V_new. The drift alarm value D can be calculated using the following formula: D = 1 - (V_old · V_new) / (||V_old|| × ||V_new||), where V_old · V_new represents the inner product of the two vectors, and ||V_old|| and ||V_new|| represent the magnitudes of the two vectors, respectively. A larger D indicates a greater semantic difference between the simulated output and the snapshot of the historical execution results. In some embodiments, the system can compare D with a preset drift threshold, and generate a semantic drift alarm in response to D being greater than the threshold. For example, when D is greater than a first threshold T1, the verification result can be labeled DRIFT_NOTICE; when D is greater than a second threshold T2 and T2 is greater than T1, the verification result can be labeled DRIFT_HIGH_RISK. Thresholds T1 and T2 can come from hypothetical rule parameters in the current rule set, audit task configuration, or replay request.

[0062] In some embodiments, trade-off reversal detection can be achieved by comparing trade-off dimension data in historical execution result snapshots with those in simulated output results. Trade-off dimension data may include dimensions such as security, benefits, costs, timeliness, risk, user preferences, compliance levels, long-term goals, short-term goals, or other decision-making criteria. The system can set a bias direction for each key indicator, such as bias towards improving security, bias towards reducing risk, bias towards improving short-term benefits, or bias towards maintaining long-term stability. If historical execution results show a first bias direction for a certain key indicator, while simulated output results show an opposite bias direction for the same key indicator, a trade-off reversal can be determined. The bias direction can be represented by a direction value. For example, for each key indicator k, direction_old(k) and direction_new(k) can be set, where +1 indicates a bias towards strengthening the indicator, -1 indicates a bias towards weakening the indicator, and 0 indicates neutrality or indeterminacy. If direction_old(k) × direction_new(k) = -1, then a trade-off reversal is determined for key indicator k. If multiple key indicators reversal occurs, the system can calculate a reversal risk score based on the weights of each key indicator.

[0063] For example, if the trade-off dimension data in the historical execution result snapshot indicates "sacrificing short-term gains to reduce long-term risk," while the trade-off dimension data in the simulated output result indicates "accepting higher long-term risk to increase short-term gains," the system can mark a trade-off reversal alert on the "gain-risk" dimension. This alert helps auditors identify whether model upgrades or rule changes have altered the fundamental tendency of the decision-making logic. In batch audit scenarios, the difference calculation module can also statistically analyze the average semantic drift value, maximum semantic drift value, trade-off reversal ratio, and high-risk event list for multiple historical events before and after the same model version upgrade, to support regression audits before model deployment.

[0064] Step S150: Output the verification result and prevent the verification result from modifying the original data in the immutable storage medium at the physical level.

[0065] In step S150, the computing device can output the verification result. The verification result can be a structured report, a JSON object, an audit log, visualized data, an alarm message, a file, or a combination thereof. The verification result may include at least one of the following fields: replay mode identifier, target historical event identifier, historical rule snapshot identifier, historical execution result snapshot identifier, original input data hash, compliance consistency verification result, permission signature verification result, semantic drift index, trade-off alarm, evidence anchor verification result, simulation derivative tag, and audit task identifier. In a specific data structure, the verification result may include the following fields: replay_id, target_event_id, mode, historical_policy_version, historical_result_id, input_hash, hash_chain_result, signature_result, static_rule_result, semantic_drift_score, trade_off_flip_nodes, evidence_anchor_result, simulation_tag, created_at, auditor_id, and report_hash. In the first replay mode, semantic_drift_score and trade_off_flip_nodes can be empty; in the second replay mode, hash_chain_result and signature_result can be retained as input evidence verification results.

[0066] In some embodiments, when outputting verification results, a simulation-derived tag can be attached to the verification results. The simulation-derived tag can be used to indicate that the result was generated by replay verification or sandbox simulation and does not belong to the original historical data in the production environment. The simulation-derived tag can be SIMULATION, AUDIT_DERIVED, REPLAY_RESULT, or other identifiers. After attaching the simulation-derived tag, the system can store the verification results in a dedicated audit database. The audit database can be physically isolated from the immutable storage media of the production environment, for example, deployed under different database instances, different storage volumes, different access domains, different network zones, or different permission accounts.

[0067] Physical-level restrictions prevent verification results from modifying existing data in immutable storage media, which can be achieved through a physical write barrier component. This component can intercept write requests from the static verification engine, isolation sandbox simulation engine, differential computation component, or output component. If the write request points to historical raw data in the immutable storage media, the write request is rejected. The physical write barrier component can be implemented through database permissions, network access control, storage interface proxies, operating system permissions, container network policies, read-only mounts, or a combination thereof. For example, the physical write barrier component can maintain a set of resource identifiers for the production immutable storage media: `immutable_resource_set`. When the output component submits a write request, the physical write barrier component checks whether the target resource identifier `target_resource` belongs to `immutable_resource_set`. If it does, the write is rejected and `WRITE_FORBIDDEN_FOR_IMMUTABLE_HISTORY` is returned; if the target resource is an audit database and the verification result carries the `SIMULATION` or `AUDIT_DERIVED` tag, the write is allowed.

[0068] Through step S150, the system ensures that the results of the first playback mode and the second playback mode do not overwrite the original historical data, thereby maintaining the stability of historical evidence in the immutable storage medium. Through steps S110 to S150, the embodiments of this specification form a technical closed loop from read-only acquisition of historical data, mode routing, dual-mode verification, difference calculation to controlled output, achieving the technical goal of distinguishing between compliance verification and simulation evaluation without destroying historical evidence.

[0069] The above is an embodiment of a dual-mode data playback verification method based on immutable snapshots provided in this specification. Based on the same technical concept, this specification also provides a historical decision audit interaction method.

[0070] Figure 5 This is a flowchart illustrating an interactive method for historical decision auditing, provided as an example of some embodiments of this specification. Figure 5 The illustrated embodiment may include the following processing steps: This method can be executed by an audit client. The audit client can be a browser client, desktop client, mobile terminal, monitoring workbench, model governance platform front-end, or other user interaction device. The method may include steps S210 to S240.

[0071] Step S210: Send a replay request containing a timestamp range and a target event identifier to the server. The audit client can receive the timestamp range and target event identifier input by the audit user. The timestamp range can be used to limit the time interval of the event to be audited; the target event identifier can be an event ID, ledger record ID, decision primitive ID, agent task ID, or other identifiers that can locate historical events. The audit client can encapsulate the above information into a replay request and send it to the server. The replay request may also include information such as the audit user's identity, authorization credentials, tenant identifier, audit task description, and the type of report to be returned. In some embodiments, before sending the replay request, the audit client can perform local session verification of the audit user's identity and attach an access token, audit task number, and request signature to the request header. The server can determine whether the audit user has permission to read the target historical event based on the access token and request signature.

[0072] Step S220: Specify the replay mode in the replay request; in response to specifying the second replay mode, inject hypothetical rule parameters or a specified version of the inference model for sandbox simulation into the replay request. The audit client can provide a replay mode selection control in the interface. If the audit user selects the first replay mode, the replay request can carry the first replay mode identifier. If the audit user selects the second replay mode, the replay request can carry the second replay mode identifier, and can further carry hypothetical rule parameters or a specified version of the inference model. Hypothetical rule parameters may include risk thresholds, permission thresholds, policy switches, weight coefficients, time windows, model temperature parameters, number of candidate paths, or other parameters used for sandbox simulation. The specified version of the inference model can be the current model, candidate upgrade model, grayscale model, historical model, or other models that can be loaded in the sandbox environment. In some embodiments, the audit client can support counterfactual parameter fine-tuning. The audit user can dynamically change the threshold in the hypothetical rule parameters through sliders, input boxes, drop-down boxes, or configuration editors. In response to the threshold change, the audit client can generate an updated replay request and trigger the server to re-execute the second replay mode. Through this interactive method, auditors can observe the simulated impact of different rule parameters on historical inputs. For example, an auditor can adjust the risk threshold from 0.7 to 0.85 in the interface. The audit client automatically writes the updated risk_threshold into the hypothetical_params field of the replay request and resends the second replay mode request. After the server re-executes the sandbox simulation, it returns new semantic drift metrics and trade-off reversal alerts. The audit client displays the old and new results side by side.

[0073] Step S230: Receive the structured difference report returned by the server. After executing the first replay mode or the second replay mode, the server can return a structured difference report to the audit client. The structured difference report may include information such as historical decision primitives, simulated decision primitives, semantic drift indicators, trade-off reversal alarms, compliance consistency verification results, hash chain integrity results, permission signature verification results, and evidence anchor verification results. If the server returns a hash chain break alarm in the first replay mode, the audit client can block subsequent business logic and generate an evidence report. The evidence report may include fields such as target event identifier, break location, related hash value, timestamp, evidence anchor, requesting user, and report generation time. Blocking subsequent business logic may include suspending automatic processing of the historical event, prohibiting further external operations based on the historical event, prompting auditors for manual review, or sending an alarm to the regulatory system. In one implementation, upon receiving a HASH_CHAIN_BROKEN alarm, the audit client can set the interface status corresponding to the target historical event to LOCKED, preventing the audit user from initiating a second replay mode simulation. This avoids generating misleading comparison reports when the integrity of the evidence is questionable. Simultaneously, the audit client can call the evidence report generation module to generate a PDF, JSON, or electronically signed report containing the hash chain break location and verification parameters.

[0074] In step S240, the historical decision primitives and simulated decision primitives are aligned and rendered in the visualization interface, and the dimension nodes where trade-offs have reversed are highlighted. The audit client can display the historical and simulated decision primitives side-by-side, as a timeline, a graph structure, or a table. Decision primitives may include fields such as objectives, selected execution paths, abandoned alternative paths, trade-off basis, unknown information items, and evidence anchors. The audit client can render the historical and simulated decision primitives according to field alignment, allowing audit users to intuitively see the differences between them. For dimension nodes where trade-offs have reversed, the audit client can mark them using highlight colors, alarm icons, borders, line changes, node blinking, or other visualization methods. For example, in a graph structure, a dimension node may represent "risk priority," with historical decision primitives pointing to "reducing risk" and simulated decision primitives pointing to "increasing returns." The audit client can mark this node as a trade-off reversal node. The audit client can also display semantic drift indicators as numerical values, color levels, or trend charts. For example, low drift is displayed in green, medium drift in yellow, and high drift in red. For dimension nodes marked as trade-off flips, the client can display the historical trend direction, the simulated trend direction, and the specific field value that triggered the flip, making it easier for auditors to pinpoint the source of the impact of model or rule changes. Through the above interactive methods, the audit client can transform the complex data discrepancy analysis results from the server into a visual and interpretable audit interface.

[0075] The above is an example of a historical decision auditing interaction method provided by the embodiments of this specification. Based on the same technical concept, the embodiments of this specification also provide a dual-mode data playback verification device based on immutable snapshots.

[0076] Figure 6 This is a schematic diagram of a dual-mode data playback verification device based on an immutable snapshot, provided as an example of some embodiments of this specification. Figure 6 The structure shown may include the following units: This device can be deployed in a computing device or implemented collaboratively by multiple computing nodes. The device may include a read-only acquisition module 610, a pattern routing module 620, a static verification module 630, a sandbox simulation module 640, a difference calculation module 650, and an output and write barrier module 660.

[0077] The read-only acquisition module 610 can be used to respond to a replay verification request for a target historical event by reading-only acquiring the original input data, historical rule snapshots, and historical execution result snapshots from an immutable storage medium. The read-only acquisition module 610 can parse the evidence anchor pointers, recursively pull the original interactive byte stream from the underlying ledger, and obtain the corresponding historical rule snapshots and historical execution result snapshots. The read-only acquisition module 610 may also include an anchor parsing submodule, a cascading query submodule, and a hash comparison submodule. The anchor parsing submodule is used to parse the evidence anchor pointers in the historical execution result snapshots; the cascading query submodule is used to read ledger records, rule snapshots, and original inputs based on the evidence anchor pointers; and the hash comparison submodule is used to calculate the hash of the original input and compare it with the input hash in the historical execution result snapshots.

[0078] The pattern routing module 620 can be used to route the execution flow to a first replay mode or a second replay mode in response to the instruction type in the replay verification request. The pattern routing module 620 can determine the routing target based on the pattern identifier, audit purpose, or permission policy in the request. The pattern routing module 620 can also be used to perform request mutual exclusion checks and permission checks before routing, and reject the request if the request pattern does not match the audit purpose.

[0079] The static verification module 630 can be used to verify compliance consistency based on a static verification algorithm in response to entering the first replay mode, excluding dynamic semantic generation logic. The static verification module 630 can perform hash chain integrity verification, permission signature verification, rule version consistency verification, and evidence anchor verification. The static verification module 630 may include a hash chain verification submodule, a signature verification submodule, and a rule consistency submodule. The hash chain verification submodule is used to recalculate the record hash based on the previous hash, the current payload, and the signature data; the signature verification submodule is used to verify the permission signature using the public key in the historical rule snapshot; and the rule consistency submodule is used to determine whether the historical execution results conform to the deterministic rules defined in the historical rule snapshot.

[0080] The sandbox simulation module 640 can be used to reprocess the original input data and generate simulated output results in response to entering the second replay mode, by invoking the currently active semantic generation engine and the current rule set in an isolated computing environment. The sandbox simulation module 640 can run in a containerized virtual environment, and its access to real business systems can be restricted through network policies. The sandbox simulation module 640 may include an isolation environment management submodule, a model loading submodule, a rule loading submodule, and a simulation output generation submodule. The isolation environment management submodule is used to configure the container network egress and read-only mounting; the model loading submodule is used to load the current model or request a specified model; the rule loading submodule is used to load the current rule set or hypothetical rule parameters; and the simulation output generation submodule is used to output simulated decision primitives tagged with SIMULATION.

[0081] The difference calculation module 650 can be used to calculate data difference indicators between simulated output results and historical execution result snapshots. The difference calculation module 650 can convert historical execution result snapshots and simulated output results into old and new decision vectors, and calculate semantic drift indicators; it can also extract tradeoff dimension data and detect tradeoff flips. The difference calculation module 650 may include a vectorization submodule, a distance calculation submodule, and a tradeoff flip detection submodule. The vectorization submodule is used to convert historical and simulated decision primitives into vectors; the distance calculation submodule is used to calculate cosine distance; the tradeoff flip detection submodule is used to compare the tendency direction of key indicators and output the dimension nodes where flips have occurred.

[0082] The output and write barrier module 660 can be used to output verification results and prevent the verification results from modifying the original data in the immutable storage medium at the physical level. The output and write barrier module 660 can attach simulated derived tags to the verification results and write them to an audit database physically isolated from the production environment's immutable storage medium. The output and write barrier module 660 may also include a tag attaching submodule, an audit database writing submodule, and an immutable resource interception submodule. The tag attaching submodule is used to add SIMULATION or AUDIT_DERIVED tags to the second playback mode results; the audit database writing submodule is used to write the verification results to the audit database; and the immutable resource interception submodule is used to prevent any component from writing historical raw data to the production immutable storage medium.

[0083] The modules described above can be implemented through software programs, hardware circuits, dedicated chips, programmable logic devices, or a combination of hardware and software. The modules in the device embodiments correspond to the steps in the aforementioned method embodiments, and can produce corresponding technical effects.

[0084] Based on the same technical concept, embodiments of this specification also provide a historical decision auditing interactive device. This device can be deployed in an auditing client. The device may include a request sending module, a parameter injection module, a report receiving module, and a visualization rendering module. The request sending module can be used to send a replay request containing a timestamp range and a target event identifier to the server, and specify a replay mode in the replay request. The parameter injection module can be used to inject hypothetical rule parameters for sandbox inference or a specified version of the inference model into the replay request in response to specifying a second replay mode. The parameter injection module can also generate an updated replay request in response to the auditing user changing a threshold in the interactive interface. The report receiving module can be used to receive a structured difference report returned by the server. If the report contains a hash chain break alarm, the report receiving module can trigger a control instruction to block subsequent business logic and generate an evidence report. The visualization rendering module can be used to align and render historical decision primitives and simulated decision primitives in the visualization interface, and highlight the dimension nodes where trade-offs have occurred. The parameter injection module can encapsulate hypothetical rule parameters into the hypothetical_params field and encapsulate the specified version of the inference model into the model_version field; the visualization rendering module can determine the dimension nodes that need to be highlighted based on the trade_off_flip_nodes field in the structured difference report, and determine the difference level display method based on the semantic_drift_score field.

[0085] Based on the same technical concept, embodiments of this specification also provide a dual-mode data playback verification system based on immutable snapshots.

[0086] Figure 7 This is a schematic diagram illustrating the structure of a dual-mode data playback verification system based on an immutable snapshot, provided as an example of some embodiments of this specification. Figure 7 The structure shown may include the following units: The system may include a read-only cascade acquisition module 710, a mode routing gateway 720, a static verification engine 730, an isolation sandbox inference engine 740, a difference calculation component 750, and a physical write barrier component 760.

[0087] The read-only cascading acquisition module 710 can be used to synchronously extract historical inputs, historical rules, and historical results from the underlying storage. The underlying storage may include immutable storage media, rule snapshot storage, structured decision object storage, and audit metadata storage. The read-only cascading acquisition module 710 can connect to the above data via evidence anchor pointers.

[0088] The pattern routing gateway 720 can be used to distribute execution flows based on instruction type. The pattern routing gateway 720 can be located at the audit request entry point to check request pattern, request permissions, target event status, and parameter integrity.

[0089] The static verification engine 730 can be configured to perform cryptographic verification and logical rule verification. Cryptographic verification can include hash chain integrity verification and signature verification. Logical rule verification can include verification of rule version validity, time window consistency, permission level consistency, input hash consistency, etc.

[0090] The isolated sandbox simulation engine 740 can be configured to load the currently active semantic generation engine and the current rule set to recalculate historical inputs and generate simulated output results. In some embodiments, the isolated sandbox simulation engine 740 can run in a containerized virtual environment, whose network egress can be configured to allow access only to a simulation stub service. The simulation stub service can simulate the returns from external tools, external databases, or business interfaces without writing data to the real business system.

[0091] The difference calculation component 750 can be used to compare semantic drift and trade-offs between simulated output results and historical execution result snapshots. In some embodiments, the difference calculation component 750 may include a matrix operation acceleration module. The matrix operation acceleration module can perform distance calculations of high-dimensional decision vectors based on GPUs, NPUs, vector processing units, SIMD instruction sets, or other accelerated hardware, thereby improving computational efficiency in batch auditing scenarios.

[0092] The Physical Write Barrier 760 can be configured to block requests to modify historical raw data in immutable storage media. The Physical Write Barrier 760 can work in conjunction with storage access agents, database permission systems, container network policies, auditing database write interfaces, or operating system permission controls to ensure that replay verification results do not overwrite historical raw data.

[0093] In one deployment method, the read-only cascading acquisition module 710, the pattern routing gateway 720, and the static verification engine 730 are deployed in the audit service cluster; the isolated sandbox simulation engine 740 is deployed in a separate sandbox computing cluster; the differential computing component 750 is deployed in a computing node with matrix operation acceleration hardware; and the physical write barrier component 760 is deployed before the immutable storage medium access point. This deployment method can simultaneously isolate historical evidence from simulation results at the network layer, permission layer, and storage layer.

[0094] In some embodiments, the system may further include a scheduled audit scheduler. The scheduled audit scheduler can respond to model version upgrade events, triggering a second replay mode in batches and generating a global drift assessment report. Model version upgrade events may include major version model deployment, major rule set version switching, centralized adjustment of policy thresholds, or replacement of the inference engine. The global drift assessment report can statistically analyze the semantic drift distribution, trade-off reversal ratio, high-risk event list, and recommended review scope for multiple historical events. For example, before a candidate model is deployed, the scheduled audit scheduler can select high-risk historical event samples within a preset time window, batch-call the second replay mode, and obtain the semantic drift index and trade-off reversal alarms corresponding to each historical event; if the proportion of high-risk events exceeds a preset deployment threshold, a model upgrade blocking recommendation is generated.

[0095] Based on the same technical concept, embodiments of this specification also provide an electronic device.

[0096] Figure 8 This is a schematic diagram of the structure of a computing device provided as an example of some embodiments of this specification. Figure 8 The illustrated structure may include the following units: The computing device may include a processor 810, a memory 820, a communication interface 830, and a bus 840. The processor 810, memory 820, and communication interface 830 can be connected via the bus 840. The processor 810 may be a central processing unit, a graphics processing unit, a neural network processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or other processing unit that executes instructions. The memory 820 may include volatile and non-volatile memory, such as random access memory, read-only memory, solid-state drive, disk, or other storage media. The communication interface 830 can be used to communicate with immutable storage media, audit clients, model services, rule bases, audit databases, or other systems.

[0097] In some embodiments, memory 820 may store computer-executable instructions. When processor 810 executes these computer-executable instructions, it can implement the aforementioned dual-mode data replay verification method based on immutable snapshots. For example, in response to a replay verification request, processor 810 may read-only acquire the original input data, historical rule snapshots, and historical execution result snapshots; select a first replay mode or a second replay mode according to the instruction type; perform static verification in the first replay mode; perform isolation sandbox inference and difference calculation in the second replay mode; output the verification result and prohibit modification of the original data in the immutable storage medium. In some embodiments, the audit terminal device may also include a processor, memory, communication interface, and display components. When the processor of the audit terminal device executes the instructions in the memory, it can implement the aforementioned historical decision audit interaction method. For example, the audit terminal device may send a replay request, inject hypothetical rule parameters or a specified version of the inference model, receive a structured difference report, and align and render historical decision primitives and simulated decision primitives in a visualization interface.

[0098] Based on the same technical concept, embodiments of this specification also provide a computer-readable storage medium. The computer-readable storage medium can be a non-transitory computer-readable storage medium, such as a read-only memory, random access memory, disk, optical disk, solid-state drive, flash memory, memory card, or other medium capable of storing computer-executable instructions. The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, can implement any of the aforementioned method embodiments. Further, when the computer-executable instructions are executed by the processor 810, the computing device can also perform the following operations: parsing the evidence anchor pointer in the historical execution result snapshot; recursively reading the original interactive byte stream based on the evidence anchor pointer; verifying the hash chain integrity and authorization signature in the first replay mode; cutting off network write permissions from the isolated computing environment to the external real business system before execution in the second replay mode; converting the historical execution result snapshot and simulated output results into old and new decision vectors; generating a semantic drift index based on cosine distance; extracting trade-off dimension data and detecting whether the tendency direction has reversed; attaching simulated derivative tags to the verification results and writing them to an audit database physically isolated from the production immutable storage medium.

[0099] The above descriptions are merely some embodiments of this specification and are not intended to limit this specification. Any modifications, equivalent substitutions, or improvements made within the technical concept of this specification should be included within the scope of protection of this specification.

Claims

1. A dual-mode data playback verification method based on immutable snapshots, characterized in that, Performed by a computing device, including: In response to a replay verification request for a target historical event, the original input data, historical rule snapshots, and historical execution result snapshots corresponding to the target historical event are read-only retrieved from an immutable storage medium. In response to the instruction type in the playback verification request, the execution stream is routed to either the first playback mode or the second playback mode; In response to entering the first replay mode, without excluding dynamic semantic generation logic, the compliance consistency between the original input data, the historical rule snapshot and the historical execution result snapshot is verified based on a static verification algorithm. In response to entering the second replay mode, the currently active semantic generation engine and the current rule set are invoked in the isolated computing environment to reprocess the original input data, generate simulated output results, and calculate the data difference index between the simulated output results and the historical execution result snapshot; Output the verification result and prevent the verification result from modifying the original data in the immutable storage medium at the physical level.

2. The method according to claim 1, characterized in that, The verification of compliance consistency based on the static verification algorithm includes: The integrity of the hash chain of the historical execution result snapshot in the underlying storage is verified based on a cryptographic algorithm. Extract the permission signature from the historical execution result snapshot, and verify the permission signature using the public key in the historical rule snapshot.

3. The method according to claim 1, characterized in that, The step of reading-only from the immutable storage medium to obtain the original input data, historical rule snapshots, and historical execution result snapshots corresponding to the target historical event includes: Parse the evidence anchor pointer in the historical execution result snapshot, and recursively pull the original interactive byte stream from the underlying ledger based on the evidence anchor pointer; Before the second replay mode is executed, the network write permissions of the isolated computing environment to the external real business system are cut off to prevent the simulated output results from producing real business side effects.

4. The method according to claim 1, characterized in that, The calculation of the data difference index between the simulated output result and the historical execution result snapshot includes: The historical execution result snapshot and the simulation output result are respectively converted into old decision vector and new decision vector; Based on the inner product of the old decision vector and the new decision vector, and the product of the magnitudes of the two vectors, the normalized cosine distance is calculated, and a semantic drift index is generated based on the cosine distance. Extract the trade-off dimension data from the historical execution result snapshot and the simulation output result; compare the tendency of the two in terms of preset key indicators; in response to the detection of a reversal of the tendency, mark a trade-off reversal alarm in the verification result.

5. The method according to claim 1, characterized in that, The output verification results include: A simulated derivative label is attached to the verification result, and the verification result with the simulated derivative label attached is stored in the audit database; The audit database is physically isolated from the immutable storage medium in the production environment. The verification results include at least one of the following: replay mode identifier, target historical event identifier, historical rule snapshot identifier, historical execution result snapshot identifier, compliance consistency verification result, semantic drift index, trade-off reversal alarm, and evidence anchor point verification result.

6. A historical decision auditing interactive method, characterized in that, Performed by the audit client, including: Send a playback request containing the timestamp range and the target event identifier to the server; Specify a replay mode in the replay request; in response to specifying a second replay mode, inject hypothetical rule parameters for sandbox inference or a specified version of the inference model into the replay request; Receive the structured difference report returned by the server; In the visualization interface, the historical decision primitives and simulated decision primitives are aligned and rendered, and the dimension nodes where trade-offs are reversed are highlighted.

7. A dual-mode data playback verification device based on immutable snapshots, characterized in that, include: The read-only acquisition module is used to read-only acquire the original input data, historical rule snapshots, and historical execution result snapshots from the immutable storage medium in response to a replay verification request for a target historical event. The mode routing module is used to route the execution flow to the first playback mode or the second playback mode in response to the instruction type in the playback verification request; The static verification module is used to verify compliance and consistency based on a static verification algorithm in response to entering the first playback mode, excluding dynamic semantic generation logic. The sandbox simulation module is used to respond to entering the second replay mode by calling the currently active semantic generation engine and the current rule set in the isolated computing environment to reprocess the original input data and generate simulated output results. The difference calculation module is used to calculate the data difference index between the simulated output result and the historical execution result snapshot; The output and write barrier module is used to output the verification result and prevent the verification result from modifying the original data in the immutable storage medium at the physical layer.

8. A historical decision auditing interactive device, characterized in that, include: The request sending module is used to send a replay request containing a timestamp range and a target event identifier to the server, and to specify the replay mode in the replay request; The parameter injection module is used to inject hypothetical rule parameters or a specified version of the inference model for sandbox inference into the replay request in response to a specified second replay mode. The report receiving module is used to receive the structured difference report returned by the server; The visualization rendering module is used to align historical decision primitives and simulated decision primitives in the visualization interface, and to highlight the dimension nodes where trade-offs have occurred.

9. A dual-mode data playback verification system based on immutable snapshots, characterized in that, include: The read-only cascading retrieval module is used to synchronously extract historical inputs, historical rules, and historical results from the underlying storage. A pattern routing gateway is used to distribute execution flows based on instruction type; The static verification engine is configured to perform cryptographic verification and logical rule verification. The isolated sandbox simulation engine is configured to load the currently active semantic generation engine and the current rule set to recalculate historical inputs and generate simulated output results; A difference calculation component is used to compare the semantic drift and trade-offs between the simulated output results and historical execution result snapshots; The physical write barrier component is configured to intercept requests to modify historical raw data in immutable storage media.

10. A computer-readable storage medium, characterized in that, The system stores computer-executable instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 6.

Images