Data write control method, device, system and equipment based on version consistency and atomic commit, and medium

Abstract

The embodiment of the specification provides a data write control method, device, system, equipment and medium based on version consistency and atomic submission, which comprises the following steps: in response to receiving a data write proposal, putting the data write proposal in a memory pending state and reading a first active rule version identifier; calculating a risk assessment result based on the first rule version identifier; in response to the risk assessment result meeting a write condition, reading a second rule version identifier twice before physical writing; in response to the first rule version identifier being consistent with the second rule version identifier, locking a proposal unique identifier and atomically writing the proposal to an immutable storage medium, and updating to a persistent final state after success; and in response to the version identifiers being inconsistent or the assessment failing, rejecting the write. Through two-stage version consistency verification and atomic transaction submission, the write of unauthorized or expired rule data is effectively blocked.

Description

Technical Field

[0001] This specification relates to the fields of data security and access control technology, and in particular to a data write control method, apparatus, system, device and medium based on version consistency and atomic commit. Background Technology

[0002] In data-driven business scenarios, it is often necessary to perform security assessments and controls on data write requests from multiple sources to ensure the compliance and consistency of stored data. With the widespread deployment of automated systems and intelligent agent applications, the initiators of write requests are becoming increasingly diverse, and the frequency and concurrency of write requests are continuously growing, placing higher demands on the real-time performance, accuracy, and reliability of write control mechanisms.

[0003] In this scenario, the evaluation rules may dynamically switch during the processing of write requests, causing inconsistencies between the rules used in the evaluation phase and the rules in effect at the actual write time. This poses a risk of writing unqualified data to the storage medium based on expired rules. Furthermore, in high-concurrency write scenarios, multiple write requests may simultaneously compete for shared storage resources. Without atomicity guarantees, this could lead to an inconsistent state where some writes succeed while others fail.

[0004] Therefore, in the above scenario, there is a need for a technical solution that can ensure the consistency of evaluation and writing rules under dynamic rule switching and high-concurrency writing conditions, and achieve atomic submission of write operations. Summary of the Invention

[0005] This specification provides a data write control method based on version consistency and atomic commit, executed by a computing device, and may include: in response to receiving a data write proposal, placing the data write proposal in a pending state in memory and reading a first rule version identifier currently active in the system; calculating a risk assessment result for the data write proposal based on the first rule version identifier; in response to the risk assessment result meeting the write conditions, reading a second rule version identifier currently active in the system a second time before performing a physical write; in response to the first rule version identifier and the second rule version identifier being consistent, performing an indivisible transaction operation, the indivisible transaction operation including locking a unique identifier for the proposal, atomically writing the data write proposal to an immutable storage medium, and updating the data write proposal to a persistent final state after successful write; and in response to the first rule version identifier and the second rule version identifier being inconsistent, or the risk assessment result not meeting the write conditions, rejecting the write of the data write proposal. By reading the first rule version identifier before risk assessment and then reading the second rule version identifier twice before physical writing for consistency verification, this method can ensure that the rule version on which the assessment and writing are based are consistent in the scenario of dynamic rule switching, thereby avoiding writing unqualified data to the storage medium based on expired rules; at the same time, by binding the identifier locking, atomic writing and state update to execution through indivisible transaction operations, it can avoid the inconsistent state of partial write success and partial write failure in high-concurrency scenarios.

[0006] Optionally, calculating the risk assessment result of writing the data into the proposal may include: calling a static rule engine to calculate a first risk score, calling a dynamic semantic model to calculate a second risk score, and then weighting and combining the first risk score and the second risk score based on the weight coefficient corresponding to the first rule version identifier. This hybrid assessment mechanism of static rules and dynamic models can balance the reliability of deterministic matching with the flexibility of semantic recognition, and the weight coefficients are dynamically adjusted according to the rule version, enabling the risk assessment to adapt to the needs of different security levels.

[0007] Optionally, the static rule engine can perform deterministic matching based on regular expressions and a sensitive word database; the dynamic semantic model can make probabilistic judgments on the operational intent of writing the data into the proposal based on a classification model. The static rule engine provides fast and interpretable matching results, while the dynamic semantic model can identify risky intents not explicitly covered by the rules. The two complement each other to enhance the comprehensiveness of the assessment.

[0008] Optionally, the indivisible transaction operation may include: exclusively locking the unique identifier of the proposal in memory; calculating a tamper-proof hash value containing the payload of the data write proposal; initiating a write request carrying the tamper-proof hash value to the immutable storage medium; and releasing the lock on the unique identifier of the proposal only after receiving a physical write success confirmation signal. Exclusive locking prevents duplicate submissions of the same proposal, the tamper-proof hash value ensures the integrity of the written data, and releasing the lock only after successful confirmation ensures the atomicity of the transaction.

[0009] Optionally, in response to a discrepancy between the first rule version identifier and the second rule version identifier, the physical write operation can be blocked, and the risk assessment process can be re-initiated based on the second rule version identifier. This provides an opportunity for reassessment based on the new version, rather than simply rejecting the write operation due to version inconsistencies, reducing the likelihood of legitimate writes being mistakenly rejected due to rule updates.

[0010] Optionally, the memory pending state can be set with a time-to-live (TTL) threshold; in response to the data write proposal not being completed within the TTL threshold, the data write proposal can be converted to a blocked final state. The TTL threshold prevents overdue pending proposals from being delayed in writing after rule version changes, ensuring the system's timeliness and security.

[0011] Optionally, the method may further include: in response to receiving a highest-priority circuit breaker instruction, cutting off write permissions within a preset time window, and converting the data write proposal in the memory pending state to a blocked final state. The global circuit breaker mechanism can quickly block all write operations in emergency situations, preventing uncontrollable data writes during system anomalies or security threats.

[0012] Optionally, in response to the risk assessment result falling within a preset fuzzy range, the atomic write operation can be disabled, and the data write proposal can be routed to a manual review queue. This fuzzy range handling mechanism avoids erroneous writes when the assessment is uncertain, while providing a supplementary judgment channel through manual review.

[0013] Optionally, the data write proposal may include a source signature; calculating the risk assessment result of the data write proposal may further include verifying whether the source signature possesses the permission level required by the current rule version. Source signature verification checks the permissions of the write request during the risk assessment phase, further enhancing the security of write control.

[0014] Optionally, the immutable storage medium may, in response to receiving a write request, have the underlying driver perform a third version consistency check. This third check forms the final line of defense at the storage layer, preventing expired rule data from being written even if there is a communication delay or cache synchronization delay between the control gateway and the storage medium.

[0015] This specification also provides a proposal processing method in conjunction with atomic data writing. This method is executed by an intelligent agent client and may include: constructing a data writing proposal containing operational intent, and attaching a rule version declaration currently perceived by the client to the data writing proposal; sending the data writing proposal to a control gateway and listening for the status code returned by the control gateway; in response to receiving a retry status code due to version inconsistency, fetching the latest rule version and reconstructing the data writing proposal; and in response to receiving a persistent final state confirmation of successful locking and writing completion, rendering a successful operation feedback to the user interface. By attaching a rule version declaration on the client side, the server can detect version inconsistency issues during the proposal construction phase; by listening for status codes and automatically retrying, the client can quickly adapt after rule updates, reducing the impact of write failures on business processes.

[0016] Optionally, in response to receiving a pending status code in the manual review queue, the review progress can be displayed, and duplicate submissions of the same operation can be blocked. Blocking duplicate submissions avoids resource waste and potential conflicts caused by users repeatedly initiating the same operation during the review period.

[0017] Optionally, the data written to the proposal may include a client-generated anti-replay random number, which is used in conjunction with the server's unique proposal identifier locking mechanism. The anti-replay random number ensures that each proposal has a unique identifier, effectively preventing duplicate submissions in network latency scenarios when combined with the server's locking mechanism.

[0018] This specification also provides a data write control device based on version consistency and atomic commit. The device may include: a memory state control module, configured to, in response to receiving a data write proposal, place the data write proposal in a memory pending state and read the first rule version identifier currently active in the system; a risk assessment module, configured to, based on the first rule version identifier, calculate a risk assessment result for the data write proposal; a version consistency verification module, configured to, in response to the risk assessment result meeting the write conditions, read the second rule version identifier currently active in the system a second time before performing physical write; an atomic transaction execution module, configured to, in response to the first rule version identifier and the second rule version identifier being consistent, lock the unique identifier of the proposal, atomically write the data write proposal to immutable storage medium, and update the data write proposal to a persistent final state after successful write; and a rejection control module, configured to, in response to the first rule version identifier and the second rule version identifier being inconsistent, or the risk assessment result not meeting the write conditions, reject writing the data write proposal. The collaborative working mechanism of each module of this device corresponds to the method embodiment and can achieve the same technical effect.

[0019] Optionally, the device may also include a global circuit breaker module, which, in response to receiving a highest priority circuit breaker command, cuts off write access within a preset time window and converts a data write proposal in the memory pending state into a blocked final state.

[0020] This specification also provides a data write control system located between a nondeterministic generation environment and a deterministic storage environment. The system may include: an agent client for generating data write proposals containing operational intentions; a control gateway for receiving the data write proposals, placing them in a pending state in memory, and reading a first rule version identifier; a policy storage node for providing active rule version identifiers and their corresponding rule data; a hybrid risk assessor for calculating risk assessment results based on the first rule version identifier; a version consistency checker for reading a second rule version identifier before physical writing and verifying whether the first and second rule version identifiers are consistent; an atomic transaction executor for performing transaction operations such as locking the proposal's unique identifier, hash calculation, physical writing, and releasing the lock when the version is consistent and the risk assessment result meets the write conditions; and an immutable storage medium for receiving data write proposals submitted by the atomic transaction executor. By decoupling the functional components and clearly defining the data flow, this system can achieve rule version consistency assurance and atomic write control in complex deployment environments.

[0021] Optionally, the hybrid risk evaluator and the policy storage node can synchronize rule version identifiers via caching; and / or, the atomic transaction executor and the immutable storage medium can maintain the transaction context using a long-lived connection. Caching improves the timeliness of rule version reading, while long-lived connections reduce connection establishment overhead during transactions and maintain context consistency.

[0022] Based on the same technical concept, embodiments of this specification also provide a computing device, which may include a processor and a memory, wherein the memory stores computer-executable instructions, and when the computer-executable instructions are executed by the processor, the aforementioned data writing control method is implemented.

[0023] Accordingly, embodiments of this specification also provide a terminal device, which may include a processor and a memory, wherein the memory stores computer-executable instructions, and the computer-executable instructions, when executed by the processor, implement the aforementioned proposal processing method.

[0024] Accordingly, embodiments of this specification also provide a computer-readable storage medium storing computer-executable instructions thereon, which, when executed by a processor, implement the aforementioned data writing control method or the aforementioned proposal processing method.

[0025] Through the above technical solutions, the embodiments of this specification can ensure the consistency of the rule version on which the evaluation and writing are based through two-stage version consistency verification in scenarios of dynamic rule switching and high-concurrency writes, thereby effectively blocking unauthorized data writing based on expired rules. Since the indivisible transaction operation binds the identification locking, atomic writing, and state update for execution, it helps to avoid inconsistent states where some writes succeed while others fail in high-concurrency scenarios, thus meeting the requirements for write security and consistency in data-driven business scenarios. Furthermore, the hybrid evaluation mechanism of static rules and dynamic models can balance matching reliability and semantic recognition flexibility; the time-to-live threshold prevents overdue proposals from being delayed in writing; the global circuit breaker mechanism quickly blocks writes in emergency situations; fuzzy interval processing and manual review provide supplementary judgment channels when evaluation is uncertain; the third version consistency verification forms the final line of defense at the storage layer; and the client rule version declaration and automatic retry mechanism reduce the impact of rule updates on business processes. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating a data write control method based on version consistency and atomic commit, provided for some embodiments of this specification.

[0027] Figure 2 This is a flowchart illustrating a proposal processing method that accompanies data atomication writing, provided for some embodiments of this specification.

[0028] Figure 3 This is a schematic diagram of a data writing control system provided for some embodiments of this specification.

[0029] Figure 4 This is a timing diagram illustrating an atomic submission process provided for some embodiments of this specification.

[0030] Figure 5 This is a schematic diagram of a data writing control device based on version consistency and atomic commit, provided for some embodiments of this specification.

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

[0032] In data-driven business scenarios, data write requests from multiple sources need to undergo security assessments before being written to storage media. The rules used for the assessment may be dynamically updated as business needs and security policies change. For example, during security level adjustments, policy configuration changes, or emergency responses, the active rule version may switch. In this scenario, there is a time window between a data write request entering the assessment phase and completing the physical write. If the rule version switches within this window, the rules used in the assessment phase may be inconsistent with the rules in effect at the time of writing. One possible approach is to perform the physical write directly after the assessment is completed, without re-verifying the rule version before writing. This approach may not cause problems in scenarios with low rule update frequency, but in scenarios with frequent dynamic rule switching or high-concurrency writes, write requests that pass the assessment based on expired rules may be written to storage media even after the rules have been updated, resulting in unqualified data entering the system. Another possible approach is to rely solely on external synchronization mechanisms to ensure that the assessment and writing use the same rule version, such as pausing the write channel when rules are updated. While this approach avoids version inconsistencies, pausing the write channel affects business continuity, and there is a race condition window between pausing and resuming. Furthermore, in concurrent write scenarios, if multiple write requests compete for storage resources simultaneously and atomicity guarantees are lacking, an inconsistent state may occur where some writes succeed while others fail. This specification provides a data write control method based on version consistency and atomic commit. By reading the first rule version identifier before risk assessment and reading the second rule version identifier twice before physical write and performing consistency verification, it ensures that the rule version on which the assessment and write are based is consistent. Simultaneously, by binding identifier locking, atomic write, and state update through indivisible transaction operations, it guarantees the atomicity of the write operation.

[0033] Figure 1 This document provides a flowchart illustrating a data write control method based on version consistency and atomic commit, which is used to illustrate some embodiments of this specification. Figure 1 The method shown may include the following steps:

[0034] Step S101: In response to receiving a data write proposal, the data write proposal is placed in a pending state in memory, and the first rule version identifier that the system is currently active is read.

[0035] In step S101, the control gateway can receive data write proposals from intelligent agent clients or other requesting clients. Upon receipt, the control gateway can create an in-memory state object for the data write proposal. The in-memory state object can include information such as a unique proposal identifier, current state, reception time, current processing node, first rule version identifier, intermediate risk assessment results, lock status, and timeout period. The control gateway can perform basic format validation on the data write proposal, such as checking whether the proposal contains operational intent, payload, source signature, or anti-replay random number. After the format validation passes, the control gateway can place the proposal in a memory pending state. At this time, the proposal has not yet entered the immutable storage medium and will not trigger state changes in the external real business system. The control gateway can read the first rule version identifier currently active in the system from the policy storage node, policy database, cache, or configuration center. Reading the first rule version identifier occurs before risk assessment, thus binding subsequent risk assessments to a specific rule version. By placing the proposal in a memory pending state and reading the first rule version identifier before assessment, the system establishes a baseline version for subsequent version consistency checks, creating a traceable association between the risk assessment results and a specific rule version.

[0036] In some embodiments, if the data write proposal carries a rule version declaration currently perceived by the client, the control gateway can first perform a comparison between the client's declared version and the first rule version identifier. If they are inconsistent, the control gateway can return a version inconsistency retry status code, causing the agent client to pull the latest rule version and reconstruct the proposal. This process can serve as the first version comparison before evaluation, preventing data write proposals clearly constructed based on expired rules from entering subsequent processes. In other embodiments, to accommodate client rule synchronization delays, the control gateway may not directly reject proposals with inconsistent client declared versions, but instead write the first rule version identifier read by the server into the memory state object and force subsequent risk assessments to be performed only based on the rule data corresponding to the first rule version identifier. Regardless of the method used, a consistency check between the first rule version identifier and the second rule version identifier must still be performed before the final physical write.

[0037] Step S102: Calculate the risk assessment result of the data writing proposal based on the first rule version identifier.

[0038] In step S102, the system can calculate the risk assessment result based on the rule data corresponding to the first rule version identifier. The risk assessment result can be a risk score, risk level, pass / reject identifier, fuzzy range identifier, permission verification result, or a combination thereof. Since the risk assessment is performed based on the rule data corresponding to the first rule version identifier, the assessment result is bound to the version identifier, and subsequent version consistency verification can ensure that the active rule version at the time of physical write is consistent with the version at the time of assessment.

[0039] In some embodiments, the system can invoke a static rule engine to calculate a first risk score. The static rule engine can perform deterministic matching on data write proposals based on regular expressions, sensitive word lists, anomaly lists, permission lists, permission rules, operation type rules, or field constraint rules. For example, the static rule engine can check whether the payload contains sensitive fields, whether the operation intent is of a high-risk type, and whether the authorization subject corresponding to the source signature has the permission to execute the operation. The advantage of the static rule engine is that the matching results are deterministic and interpretable, and it can quickly identify risk patterns explicitly defined by the rules.

[0040] In some embodiments, the system can invoke a dynamic semantic model to calculate a second risk score. The dynamic semantic model can be a lightweight classifier, an intent recognition model, a text classification model, a sequence classification model, or other machine learning models. The dynamic semantic model can receive operational intents, context summaries, payload fragments, or structured features written into the proposal, and output intent risk probabilities, unauthorized access probabilities, anomaly probabilities, or other semantic risk indicators. The dynamic semantic model can identify risky intents not explicitly covered by rules, compensating for the coverage blind spots of static rules.

[0041] In some embodiments, the system can weight and combine the first risk score and the second risk score based on the weight coefficient corresponding to the first rule version identifier. For example, the risk assessment result can be expressed as Risk = α × StaticScore + β × DynamicScore, where StaticScore represents the first risk score output by the static rule engine, DynamicScore represents the second risk score output by the dynamic semantic model, and α and β can be specified by the rule data corresponding to the first rule version identifier. Different rule versions can have different weights. For example, during high-security-level operation, the weight of the static rule hit result can be increased; in scenarios requiring enhanced semantic recognition capabilities, the weight of the dynamic semantic model output can be increased. By dynamically adjusting the weight coefficients according to the rule version, the risk assessment can adapt to the needs of different security levels.

[0042] In some embodiments, a data write proposal may include a source signature. Calculating the risk assessment result of a data write proposal may further include verifying whether the source signature possesses the permission level required by the current rule version. The source signature may identify the initiating entity, initiation channel, or initiation credential of the proposal. The system can match the permission information corresponding to the source signature with the permission requirements corresponding to the first rule version identifier; if the permission level is insufficient, it can be rejected during the risk assessment phase. By verifying permissions during the risk assessment phase, the system can block write requests with insufficient permissions at an early stage, reducing unnecessary subsequent processing overhead.

[0043] The risk assessment result can be categorized into several ranges: a pass range (risk value below the pass threshold and permission verification successful), a rejection range (risk value above the rejection threshold or permission verification failed), and a fuzzy range (risk value between the pass and rejection thresholds, or insufficient confidence in the model output). In response to a risk assessment result falling within the fuzzy range, the system can disable atomic writes and route the data write proposal to a manual review queue. This queue can be handled by a review service, a ticket system, a higher-level agent, or an administrator terminal. Proposals in the manual review queue can enter an upgrade pending review state instead of being stored on immutable storage. In some embodiments, even if a proposal in the manual review queue receives manual approval, it does not directly bypass version consistency verification. After receiving the approval result, the system can reread the current active rule version identifier and re-enter the risk assessment or pre-write verification process based on the approval instruction, the current rule version, and the original proposal payload. This avoids writing expired rules due to rule version changes during the manual review process.

[0044] Step S103: In response to the risk assessment result meeting the write conditions, before performing the physical write, the second rule version identifier of the system currently in an active state is read a second time.

[0045] In step S103, if the risk assessment result meets the write conditions, the system does not immediately perform a physical write. Instead, it reads the second rule version identifier, which is currently active, again before performing the physical write. The second rule version identifier can be read from the same policy storage node, policy database, cache, or configuration center as the first rule version identifier. The purpose of this second read is to detect whether the active rule version has changed between the start of the risk assessment and the upcoming physical write. Without this second read, the data write proposal may be evaluated based on the old rule version, but then written to immutable storage media after the new rule version takes effect, creating a risk of inconsistency between the evaluation and the write rule. In some embodiments, the reading of the second rule version identifier can occur before generating the write request or before the atomic transaction executor prepares to commit the write transaction. The system can perform a consistency comparison between the first rule version identifier and the second rule version identifier. If they match, the atomic commit is allowed to continue; if they do not match, the write is rejected or the risk assessment process is re-initiated. Combined with the optional comparison between the client-declared version and the server-side first rule version identifier in step S101, the system can detect rule version inconsistencies at both the proposal construction stage and the physical write stage, thus forming a two-stage protection.

[0046] Step S104: In response to the first rule version identifier being consistent with the second rule version identifier, perform an indivisible transaction operation.

[0047] In step S104, if the first rule version identifier and the second rule version identifier are the same, the system can execute an indivisible transaction operation. This indivisible transaction operation may include locking the unique identifier of the proposal, atomically writing the data to the proposal to the immutable storage medium, and updating the data to the persistent final state after successful writing. Figure 4 This diagram illustrates the timing of the atomic commit process provided in some embodiments of this specification. In some embodiments, the atomic transaction executor may first exclusively lock the unique identifier of the proposal in memory. The exclusive lock may be implemented using a local memory lock, a distributed lock, a database unique constraint, a cached atomic operation, or other mutual exclusion mechanisms. By locking the unique identifier of the proposal, the system can prevent the same proposal from being committed repeatedly in high-concurrency scenarios. After locking the unique identifier of the proposal, the system can calculate a tamper-proof hash value containing the payload to be written to the proposal. The tamper-proof hash value may be calculated based on at least a portion of the payload, the unique identifier of the proposal, the first rule version identifier, the second rule version identifier, the timestamp, the source signature, and the hash value of the preceding record. The hash algorithm may employ SHA-256, SHA-3, or other cryptographic hash algorithms. The tamper-proof hash value may be committed to the immutable storage medium along with the write request for subsequent integrity verification. Subsequently, the system may initiate a write request carrying the tamper-proof hash value to the immutable storage medium. Immutable storage media can append records, which may include fields such as a unique proposal identifier, payload, rule version identifier, risk assessment result, tamper-proof hash value, source signature, and write time. The system only updates the proposal to a persistent final state and releases the lock on the proposal's unique identifier after receiving a physical write success confirmation signal. The physical write success confirmation signal can be returned by the immutable storage media, storage service, or underlying driver. If the write fails, the connection is interrupted, or the confirmation times out, the system can either maintain the proposal in an uncommitted state or convert it to a blocking final state and record the reason for the failure. By binding identifier locking, hash calculation, physical writing, and state updating together through indivisible transaction operations, the system guarantees the atomicity of write operations: either the proposal is fully written and enters a persistent final state, or the write fails without producing a partially committed inconsistent state.

[0048] In some embodiments, the atomic transaction executor may perform transaction actions in the following order: First, change the proposal state from "evaluating" to "committing" in the in-memory state store and set a lock flag; second, perform an exclusive lock on the proposal's unique identifier; third, calculate a tamper-proof hash value containing the payload; fourth, generate a write request carrying the commit rule version identifier and the tamper-proof hash value; fifth, initiate an append write to the immutable storage medium; sixth, update the proposal state to the persistent final state and release the lock only after receiving a physical write success confirmation signal. If any of the above actions fails, a persistence success confirmation must not be returned to the client.

[0049] In some embodiments, in response to a write request, the immutable storage medium can perform a third version consistency check by the underlying driver. Specifically, the write request may carry a first rule version identifier, a second rule version identifier, or a committed rule version identifier if both match. The underlying driver reads the currently active rule version identifier again and compares it with the committed rule version identifier carried in the write request. If they do not match, the underlying driver rejects the write; if they match, the underlying driver continues to perform the append write. Thus, even if there is network latency or cache synchronization latency between the control gateway and the immutable storage medium, a final line of defense can still be formed at the storage layer.

[0050] Step S105: In response to the inconsistency between the first rule version identifier and the second rule version identifier, or the risk assessment result not meeting the writing conditions, the data writing proposal is rejected.

[0051] In step S105, if the first rule version identifier and the second rule version identifier are inconsistent, or if the risk assessment result does not meet the write conditions, the system may reject the data write proposal. In response to the inconsistency between the first and second rule version identifiers, the system may intercept the physical write and re-initiate the risk assessment process based on the second rule version identifier. During the reassessment, the system can use the second rule version identifier as the new assessment version and recalculate the risk assessment result. If the reassessment passes, the system can still perform version consistency verification again before writing. In response to the risk assessment result not meeting the write conditions, the system may convert the data write proposal into a blocked final state. The blocked final state can be persistently recorded in the rejection log, audit log, or monitoring system. The rejection log may include information such as the proposal's unique identifier, rejection reason, risk assessment result, rule version identifier, and timestamp for subsequent diagnosis and auditing. In some embodiments, the status codes returned by the system to the client may include: persistence confirmation, indicating successful locking and completion of the write operation; version retry, indicating version inconsistency and requesting the client to fetch the latest rule version; review suspension, indicating that the proposal has entered the manual review queue; evaluation rejection, indicating that the evaluation failed; circuit breaker blocking, indicating that write operations are refused during the circuit breaker period; and timeout blocking, indicating that the memory pending state has timed out. The client can perform operations such as retrying, suspending display, providing success feedback, or blocking duplicate submissions based on the status codes.

[0052] Steps S101 to S105 above constitute the main flow of the data write control method based on version consistency and atomic commit. By reading the first rule version identifier before evaluation and reading the second rule version identifier twice before writing and verifying consistency, this method ensures that the rule versions on which evaluation and writing are based are consistent; the atomicity of writing is guaranteed through indivisible transaction operations; and the write rejection and blocking final state mechanisms prevent the writing of unqualified data. This process forms a technical closed loop from version binding, risk assessment, version verification, atomic writing to rejection control, meeting the requirements for write security and consistency in dynamic rule switching and high-concurrency scenarios.

[0053] In some embodiments, a time-to-live (TTL) threshold can be set for the memory pending state. The TTL threshold can be configured by the rule version or by a system default, such as 500 milliseconds, 1 second, or other time windows adapted to business latency. If a data write proposal is not written within the TTL threshold, does not enter the manual review queue, and does not reach the persistent final state, the memory state controller can convert it to a blocked final state and record the timeout reason. This prevents overdue TTL proposals from being delayed in writing after rule version changes.

[0054] In some embodiments, the system may include a global circuit breaker. The global circuit breaker can receive the highest priority circuit breaker command, which may be issued by an administrator, monitoring system, anomaly detection service, or a higher-level governance system. In response to receiving the highest priority circuit breaker command, the system may sever write permissions within a preset time window and convert data write proposals in a pending memory state to a blocked final state. The preset time window may be a millisecond-level time window, such as within 100 milliseconds, within 200 milliseconds, or a millisecond-level window determined by the system deployment environment. Severing write permissions may include closing the write channel from the control gateway to the immutable storage medium, updating the active rule version to the circuit breaker version, forcing all risk assessment results to be rejected, stopping the atomic transaction executor from committing new transactions, or causing the underlying driver to reject all write requests. The global circuit breaker has a higher priority than ordinary risk assessment processes and manual review processes. Even if a data write proposal has passed a risk assessment, as long as a circuit breaker command is received before the physical write success confirmation signal is returned, the system can reject the write and convert the proposal to a blocked final state. For proposals that have received a physical write success confirmation signal, the system does not roll back the records in the immutable storage medium. Instead, it can append circuit breaker audit records to explain the time and scope of the circuit breaker.

[0055] Figure 2 This is a flowchart illustrating a proposal processing method that accompanies data atomication writing, provided for some embodiments of this specification. Figure 2 The method shown can be executed by an agent client, which can be a client program running on a terminal device, edge device, robot, application server, or cloud agent node.

[0056] Step S201: Construct a data write proposal containing the operation intent, and attach a rule version declaration currently perceived by the client to the data write proposal.

[0057] The agent client can construct a data writing proposal based on user instructions, model output, tool call results, or environmental states. The data writing proposal can include operational intents, such as writing a record, initiating authorization, submitting a commitment, updating state, or other operations requiring entry into immutable storage. The agent client can attach a currently perceived rule version declaration to the data writing proposal. This declaration can come from the client's local cache, the previous server response, the rule synchronization interface, or the configuration update channel. This declaration helps the server identify whether the client is using an expired rule environment to construct the proposal. In some embodiments, the data writing proposal can include a client-generated anti-replay random number, which can be a random string, a random integer, a one-time token, or a time-based random value. The anti-replay random number can be used together with the client identifier, operational intent, and timestamp to generate a unique identifier for the proposal, thereby cooperating with the server's unique identifier locking mechanism.

[0058] Step S202: Write the data into the proposal and send it to the control gateway, and listen for the status code returned by the control gateway.

[0059] The agent client can send data write proposals to the control gateway via network interfaces, remote procedure calls, message queues, or other communication methods. After sending, the client can listen for the status codes returned by the control gateway. These status codes can include persistent final state confirmation, version inconsistency retry, manual review suspension, rejection, circuit breaker, and timeout. The client can execute different processing logic based on different status codes. For example, for persistent final state confirmation, it can render a success message to the user interface; for version inconsistency retry, it can re-fetch the rule version; for manual review suspension, it can display the review progress; and for rejection or circuit breaker, it can indicate that the operation has not been written.

[0060] Step S203: In response to receiving a retry status code due to version inconsistency, the latest rule version is retrieved and the data is reconstructed and written to the proposal.

[0061] If the server detects a discrepancy between the first rule version identifier and the second rule version identifier, or detects a discrepancy between the rule version declaration currently perceived by the client and the active rule version on the server, the server can return a retry status code indicating version inconsistency to the client. In response to receiving this retry status code, the agent client can proactively retrieve the latest rule version. Retrieving the latest rule version identifier, latest permission requirements, latest threshold configuration, or latest proposal format requirements may be included. The client can reconstruct the data and write it to the proposal based on the latest rule version and resend it to the control gateway. In some embodiments, when the agent client reconstructs the proposal, it can generate a new anti-replay random number and mark the old proposal's unique identifier as invalid to prevent the old proposal from being resubmitted due to network latency. If the business requires maintaining the traceability of the same user's operation, the client can carry the original operation association identifier in the new proposal, but the server still recalculates the proposal's unique identifier based on the new anti-replay random number and payload.

[0062] In step S204, in response to receiving a persistent final state confirmation that the lock was successfully locked and the write was completed, a successful operation feedback is rendered to the user interface.

[0063] If the server completes the unique identifier locking, version consistency verification, atomic writing, and persistent final state update of the proposal, it can return a persistent final state confirmation to the agent client indicating successful locking and completion of the write operation. Upon receiving this confirmation, the agent client can render a successful operation feedback to the user interface. This feedback may include a success message, record identifier, write time, rule version identifier, or other necessary information. Since this confirmation is only returned after the server receives the physical write success confirmation signal, the data proposal has already been written to immutable storage when the client displays the success feedback. In some embodiments, if the client receives a pending status code in the manual review queue, the client can display the review progress and block duplicate submissions of the same operation. Blocking duplicate submissions can be achieved by disabling the submit button, locking the local proposal status, displaying the queue status, or rejecting resubmissions using the same anti-replay random number.

[0064] Figure 5This specification provides a schematic diagram of a data write control device based on version consistency and atomic commit, as illustrated in some embodiments. The device can be deployed in a control gateway, server, cloud computing node, or edge computing node. The device may include a memory state control module, a risk assessment module, a version consistency verification module, an atomic transaction execution module, and a rejection control module. In some embodiments, the device may also include a global circuit breaker module. The memory state control module can be used to place the data write proposal in a memory pending state in response to receiving it, and read the first rule version identifier currently active in the system. The memory state control module can maintain the proposal lifecycle state, recording information such as the proposal's unique identifier, reception time, current state, timeout period, and current processing node. The risk assessment module can be used to calculate the risk assessment result of the data write proposal based on the first rule version identifier. The risk assessment module may include a static rule engine invocation unit, a dynamic semantic model invocation unit, a signature verification unit, and a weighted combination unit. The static rule engine invocation unit can invoke regular expressions, sensitive word libraries, or permission rules for deterministic matching; the dynamic semantic model invocation unit can invoke classification models for probability judgment of operation intent; the signature verification unit can verify whether the source signature meets the permission level of the current rule version; the weighted combination unit can generate a comprehensive risk assessment result based on the weight coefficients corresponding to the rule version. The version consistency verification module can, in response to the risk assessment result meeting the write conditions, read the second rule version identifier currently active in the system before performing a physical write. The version consistency verification module can compare the first rule version identifier with the second rule version identifier and output a verification result indicating whether the versions are consistent or inconsistent. The atomic transaction execution module can, in response to the first rule version identifier and the second rule version identifier being consistent, lock the unique identifier of the proposal, atomically write the data to the immutable storage medium, and update the data to the persistent final state after successful writing. The atomic transaction execution module can include a lock management unit, a hash calculation unit, a write request unit, an acknowledgment unit, and a lock release unit. The rejection control module can, in response to the first rule version identifier and the second rule version identifier being inconsistent, or the risk assessment result not meeting the write conditions, reject the writing of data to the proposal. The rejection control module can convert a proposal to a blocked final state, record the reason for rejection, and return the corresponding status code to the client. The global circuit breaker module can respond to the highest priority circuit breaker command, cut off write permissions within a preset time window, and convert the write proposal containing data in a pending memory state to a blocked final state. The global circuit breaker module can work in conjunction with the version consistency verification module, risk assessment module, and atomic transaction execution module to prevent new transactions from committing in emergency situations.In some embodiments, each module in the above-described apparatus can be implemented by a software program executed by one or more processors, or by a dedicated hardware circuit, a programmable logic device, or a combination of hardware and software. Modules can communicate with each other through in-process calls, remote procedure calls, message queues, or shared memory. The collaborative working mechanism of the modules in this apparatus corresponds to the method embodiments, and through modular design, a complete processing flow for version binding, risk assessment, version verification, atomic writing, and rejection control in data write control is achieved.

[0065] Figure 3This diagram illustrates the structure of a data writing control system provided in some embodiments of this specification. The system can be located between a nondeterministic generation environment and a deterministic storage environment. The nondeterministic generation environment may include an agent client, a model inference node, an automated planning node, or other generative systems. The deterministic storage environment may include immutable storage media, an audit database, or a ledger system. In some embodiments, the system may include a memory state controller, a hybrid risk evaluator, a version consistency checker, an atomic transaction executor, and a global circuit breaker. The system may also include a policy database, a cache, a control gateway, immutable storage media, and a manual review queue. The memory state controller maintains the lifecycle of proposals in isolated memory, marking proposals as pending, under evaluation, awaiting upgrade, blocked, or submitted, and determining the proposal routing direction based on the status label. The hybrid risk evaluator combines static rules and dynamic models to calculate risk values, invoking a static rule engine and a dynamic semantic model, and generating a comprehensive risk assessment result based on the weight coefficients corresponding to the current rule version. The version consistency checker performs rule version comparisons. Before evaluation, it compares the client-declared version with the server's first rule version identifier, and before writing, it compares the first rule version identifier with the second rule version identifier. This allows for the detection of version inconsistencies during the proposal construction and physical write phases. The atomic transaction executor performs a coherent operation of locking, hash calculation, physical writing, and lock release when versions are consistent. It can establish a long-lived connection with immutable storage media to maintain contextual information such as the proposal's unique identifier, rule version identifier, transaction number, and lock state during the transaction. The global circuit breaker receives urgent instructions and cuts off the physical write channel. It can set the write channel state to prohibit writing and notify the memory state controller to batch-transform the states of pending proposals. In some embodiments, the memory state controller can adopt a stateless design to support horizontal scaling. Each controller instance does not rely on local persistent state to maintain the proposal lifecycle; instead, it writes the proposal state, lock flags, time-to-live thresholds, and processing progress to a shared distributed memory state store or distributed cache. Each controller instance can restore its processing context from the shared state store based on the proposal's unique identifier. When the system faces high-concurrency proposal requests, horizontal scaling can be achieved by increasing the number of controller instances without compromising the consistency of proposal unique identifier locking and state transitions. In some embodiments, the hybrid risk assessor and the policy database synchronize rule version identifiers via a cache. The cache can store active rule version identifiers, weight coefficients, sensitive word summaries, permission thresholds, and fuzzy interval boundaries. Rule data in the cache can have version stamps and expiration times, and can be synchronously updated through a publish-subscribe mechanism, a long polling mechanism, or a configuration center notification mechanism.When the policy database releases a new rule version, the cache updates the active version pointer, and the control gateway reads the corresponding version identifier in steps S101 and S103 respectively. In some embodiments, a long-lived connection is used between the atomic transaction executor and the underlying immutable storage medium to maintain the transaction context. Long-lived connections can reduce the overhead of frequently establishing connections and ensure that the proposal unique identifier, commit rule version identifier, tamper-proof hash value, and transaction number remain consistent during the transaction. If the long-lived connection is abnormally disconnected, the atomic transaction executor should not assume that the write was successful by default, but should wait for an explicit acknowledgment signal from the immutable storage medium or confirm whether the proposal unique identifier has been written through an idempotent query interface.

[0066] In an exemplary scenario, an agent client generates a data write proposal containing an operational intent. This intent indicates that a certain decision result will be written to an immutable record. The client appends its currently perceived rule version declaration and a replay-protected random number to the proposal and sends it to the control gateway. Upon receiving the proposal, the control gateway generates or confirms a unique identifier for the proposal, places the proposal in a pending state in memory, and reads the first rule version identifier V1. If the client's declared version is also V1, the first version comparison passes. Subsequently, a hybrid risk assessor calls the static rule engine and the dynamic semantic model based on V1. The static rule engine finds no prohibited items based on a sensitive word library and regular expressions, and the dynamic semantic model outputs a low risk probability. The combined risk assessment result satisfies the write condition. Before performing the physical write, the version consistency checker reads the currently active rule version again to obtain the second rule version identifier V1. Since the first rule version identifier and the second rule version identifier are consistent, the atomic transaction executor exclusively locks the unique identifier of the proposal, calculates the tamper-proof hash value corresponding to the payload, and initiates a write request to the immutable storage medium carrying the hash value and the commit rule version identifier V1. After the underlying driver of the immutable storage medium performs the third version consistency check, the append write is completed, and a physical write success confirmation signal is returned. Upon receiving the confirmation, the atomic transaction executor updates the proposal state to the persistent final state and releases the lock. The control gateway returns a persistent final state confirmation to the client, and the client displays a success message on the user interface.

[0067] In another exemplary scenario, after the control gateway reads the first rule version identifier V1 and completes the risk assessment, the administrator updates the rule version, making the active rule version V2. The system reads the second rule version identifier V2 a second time before the physical write operation. Because V1 and V2 are inconsistent, the control gateway rejects the current write operation and can re-initiate the risk assessment process based on V2. The client can receive the retry status code due to the version inconsistency and pull the latest rule version to rebuild the proposal.

[0068] In another exemplary scenario, the risk assessment result falls within a preset fuzzy range. The system prohibits atomic writes and routes the proposal to a manual review queue. Upon receiving a pending status code, the client displays the review progress on the user interface and blocks duplicate submissions of the same operation. The proposal can only enter the write process after it has passed review and subsequent version consistency checks have been successful.

[0069] In another exemplary scenario, the global circuit breaker receives a highest-priority circuit breaker command from the administrator. Within a millisecond time window, the global circuit breaker sets the write channel status to write-prohibited, instructs the atomic transaction executor to stop committing new transactions, and instructs the memory state controller to batch-convert proposals in the pending and evaluation states to the blocked final state. For proposals that have not yet received confirmation of successful physical write to the immutable storage medium, the control gateway returns a circuit breaker blocking status code to the client.

[0070] The above describes a data writing control method and proposal processing method based on version consistency and atomic submission, as provided in the embodiments of this specification. Based on the same technical concept, the embodiments of this specification also provide corresponding computing devices, terminal devices, and storage media embodiments.

[0071] Figure 6This specification provides a schematic diagram of the structure of a computing device according to some embodiments. The computing device may include a processor, memory, a communication interface, a bus, and input / output interfaces. The processor may be a central processing unit, a graphics processing unit, a neural network processor, a microprocessor, an application-specific integrated circuit (ASIC), a programmable logic device, or a combination thereof. The memory may include volatile memory and non-volatile memory. The communication interface can be used to communicate with an agent client, a policy storage node, an immutable storage medium, a manual review queue, or other service nodes. The memory may store computer-executable instructions, which, when executed by the processor, enable the computing device to implement the aforementioned data write control method. For example, the processor may execute instructions to receive a data write proposal, place it in a pending state in memory, read a first rule version identifier, calculate a risk assessment result, read a second rule version identifier, perform version consistency verification, and perform atomic write or reject write. The terminal device may include a processor, memory, a display component, an input component, and a communication interface. The terminal device can run an agent client program. When the computer-executable instructions stored in the memory are executed by the processor, the terminal device can implement the aforementioned proposal processing method. For example, a terminal device can construct a data writing proposal containing operational intent, attach a rule version declaration currently perceived by the client, send the proposal to the control gateway, listen for status codes, and perform retry, suspension display, or success feedback based on the status codes. The computer-readable storage medium can be a non-transitory storage medium, such as a read-only memory, random access memory, disk, optical disk, flash memory, solid-state drive, or other medium capable of storing computer-executable instructions. When the computer-executable instructions stored in the computer-readable storage medium are executed by a processor, any of the aforementioned method embodiments can be implemented.

[0072] The above descriptions are merely some embodiments of this specification and are not intended to limit this specification. Those skilled in the art can make various changes, combinations, or substitutions to the above embodiments without departing from the technical concept of this specification, and all such changes, combinations, or substitutions should fall within the protection scope of this specification.

Claims

1. A data write control method based on version consistency and atomic commit, characterized in that, Performed by a computing device, including: In response to receiving a data write proposal, the data write proposal is placed in a pending state in memory, and the first rule version identifier currently active in the system is read. Based on the first rule version identifier, calculate the risk assessment result of the data writing proposal; In response to the risk assessment result meeting the write conditions, before performing the physical write, the second rule version identifier of the system currently in an active state is read a second time; In response to the first rule version identifier being consistent with the second rule version identifier, an indivisible transaction operation is performed. The indivisible transaction operation includes locking the unique identifier of the proposal, atomically writing the data into the proposal to an immutable storage medium, and updating the data into the persistent final state after successful writing. If the first rule version identifier and the second rule version identifier are inconsistent, or if the risk assessment result does not meet the writing conditions, the data writing proposal is rejected.

2. The method according to claim 1, characterized in that, The calculation of the risk assessment result of writing the data into the proposal includes: calling the static rule engine to calculate the first risk score, calling the dynamic semantic model to calculate the second risk score, and weighting the first risk score and the second risk score based on the weight coefficient corresponding to the first rule version identifier.

3. The method according to claim 2, characterized in that, The static rule engine performs deterministic matching based on regular expressions and a sensitive word library; the dynamic semantic model performs probabilistic judgment on the operational intent of writing the data into the proposal based on a classification model.

4. The method according to claim 1, characterized in that, The indivisible transaction operations include: The unique identifier of the proposal is exclusively locked in memory; Calculate the tamper-proof hash value of the payload containing the data to be written to the proposal; Initiate a write request carrying the tamper-proof hash value to the immutable storage medium; The lock on the unique identifier of the proposal is released only after a physical write success confirmation signal is received.

5. The method according to claim 1, characterized in that, In response to the inconsistency between the first rule version identifier and the second rule version identifier, the physical write is intercepted, and the risk assessment process is re-initiated based on the second rule version identifier.

6. The method according to claim 1, characterized in that, The memory pending state is set with a time-to-live threshold; in response to the data write proposal not being completed within the time-to-live threshold, the data write proposal is converted to a blocked final state.

7. The method according to claim 1, characterized in that, Also includes: In response to receiving the highest priority circuit breaker instruction, write permissions are cut off within a preset time window, and data write proposals in the memory pending state are converted to the blocked final state.

8. The method according to claim 1, characterized in that, If the risk assessment result falls within a preset fuzzy range, atomic writing is prohibited, and the data writing proposal is routed to the manual review queue.

9. The method according to claim 1, characterized in that, The data write proposal includes a source signature; the calculation of the risk assessment result of the data write proposal also includes verifying whether the source signature has the permission level required by the current rule version.

10. The method according to claim 1, characterized in that, In response to receiving a write request, the immutable storage medium performs a third version consistency check by the underlying driver.

11. A proposal processing method in conjunction with atomic data writing, characterized in that, Executed by the agent client, including: Construct a data write proposal containing the operational intent, and attach a rule version declaration currently perceived by the client to the data write proposal; Write the data into the proposal and send it to the control gateway, and listen for the status code returned by the control gateway; In response to receiving a retry status code due to version inconsistency, the latest rule version is retrieved and the data is reconstructed and written to the proposal; Upon receiving a persistent final state confirmation that the lock was successfully locked and the write was complete, a successful operation feedback is rendered to the user interface.

12. The method according to claim 11, characterized in that, In response to receiving a pending status code in the manual review queue, display the review progress and block duplicate submissions of the same operation.

13. The method according to claim 11, characterized in that, The data written to the proposal includes a client-generated anti-replay random number, which is used in conjunction with the server's unique proposal identifier locking mechanism.

14. A data write control device based on version consistency and atomic commit, characterized in that, include: The memory state control module is used to, in response to receiving a data write proposal, place the data write proposal in a memory pending state and read the first rule version identifier that the system is currently in an active state. The risk assessment module is used to calculate the risk assessment result of the data writing proposal based on the first rule version identifier; The version consistency verification module is used to read the second rule version identifier that the system is currently in an active state for the second time before performing physical writing, in response to the risk assessment result meeting the writing conditions. The atomic transaction execution module is used to lock the unique identifier of the proposal in response to the first rule version identifier being consistent with the second rule version identifier, atomically write the data to the proposal to the immutable storage medium, and update the data to the persistent final state after successful writing. The rejection control module is used to reject the data write proposal in response to the inconsistency between the first rule version identifier and the second rule version identifier, or the risk assessment result not meeting the write conditions.

15. The apparatus according to claim 14, characterized in that, It also includes a global circuit breaker module, which, in response to receiving the highest priority circuit breaker instruction, cuts off write permissions within a preset time window and converts the data write proposal in the memory pending state into a blocked final state.

16. A data writing control system, located between a nondeterministic generation environment and a deterministic storage environment, characterized in that, include: The intelligent agent client is used to generate data writing proposals containing operational intentions. A control gateway is configured to receive the data write proposal, place the data write proposal in a pending state in memory, and read the first rule version identifier. Policy storage nodes are used to provide the version identifiers of active rules and their corresponding rule data; A hybrid risk assessor is used to calculate risk assessment results based on the first rule version identifier; A version consistency checker is used to read the second rule version identifier before physical writing and to verify whether the first rule version identifier and the second rule version identifier are consistent. The atomic transaction executor is used to perform transaction operations such as locking the proposal unique identifier, hash calculation, physical writing, and releasing the lock when the version is consistent and the risk assessment result meets the write conditions. An immutable storage medium for receiving data write proposals submitted by the atomic transaction executor.

17. The system according to claim 16, characterized in that, The hybrid risk assessor and the policy storage node synchronize rule version identifiers via a cache; and / or, the atomic transaction executor and the immutable storage medium maintain the transaction context via a long connection.

18. A computing device, characterized in that, It includes a processor and a memory, the memory storing computer-executable instructions that, when executed by the processor, implement the method as claimed in any one of claims 1 to 10.

19. A terminal device, characterized in that, It includes a processor and a memory, the memory storing computer-executable instructions that, when executed by the processor, implement the method as claimed in any one of claims 11 to 13.

20. A computer-readable storage medium, characterized in that, The device stores computer-executable instructions that, when executed by a processor, implement the method as claimed in any one of claims 1 to 10, or implement the method as claimed in any one of claims 11 to 13.

Images