Data compliance amendment method, system, and electronic device

Abstract

The application provides a data compliance correction method and system and electronic equipment, and relates to the technical field of data governance. The method comprises the following steps: in response to a correction request of a client for to-be-corrected business data in a locked state, sending a compliance challenge information to the client; receiving an unlocking credential submitted by the client according to the compliance challenge information, and issuing an unlocking token to the client after verifying that the unlocking credential is valid; receiving correction data submitted by the client and carrying the unlocking token, and writing the correction data into a pre-created new version branch after verifying that the unlocking token is passed. The application can realize automatic consistency alignment of compliance correction and associated data on the premise of ensuring data integrity and traceability.

Description

Technical Field

[0001] This invention relates to the field of data governance technology, and in particular to a data compliance correction method, system, and electronic device. Background Technology

[0002] In various automated business systems (such as workflow approval systems, order management systems, and resource allocation systems), once critical business data becomes effective, it often needs to meet strict audit compliance requirements, namely, ensuring the data is authentic, complete, and tamper-proof. To this end, existing systems typically employ a combination of state machines and access control to lock and protect effective data.

[0003] However, existing data governance mechanisms have the following technical shortcomings: First, most systems, upon receiving a correction request, directly perform an UPDATE operation on the original record in the database, recording only a simple operation log. Once data correction or subsequent auditing occurs, the system cannot restore a complete snapshot of the data before the modification, making the data evolution process untraceable and failing to meet high-standard auditing requirements.

[0004] Second, when business personnel modify an existing data item (e.g., change order quantity or modify resource configuration parameters), the system often only updates the current table item, ignoring the synchronous adjustment of other records related to that data (such as summary statistics or downstream dependent data). This approach leads to inconsistencies in the system's internal data, which in turn causes business logic errors.

[0005] Third, existing systems generally adopt a role-based access control (RBAC) model, which determines whether modification is allowed solely based on user roles, lacking a fine-grained verification mechanism based on specific business credentials (such as approval documents and supporting evidence). This deficiency allows internal personnel to exploit access vulnerabilities to arbitrarily tamper with critical data, increasing the risk of fraud.

[0006] In summary, there is an urgent need for a technical solution that can both ensure that historical data is absolutely unwriteable and support controlled correction and automatic linkage processing of related data. Summary of the Invention

[0007] In view of this, the purpose of the present invention is to provide a data compliance correction method, system and electronic device, which solves the technical problem that the prior art cannot simultaneously take into account the immutability and traceability of historical data, the automatic linkage adjustment of related data and the differentiated permission control based on risk level when correcting data.

[0008] In a first aspect, embodiments of the present invention provide a data compliance correction method, the method comprising: In response to a client's request to correct business data that is locked, a compliance challenge message is sent to the client; the compliance challenge message is used to instruct the client to provide unlocking credentials that match the risk level of the modified content. Receive the unlocking credentials submitted by the client based on the compliance challenge information, and after verifying the validity of the unlocking credentials, issue an unlocking token to the client; The system receives correction data submitted by the client, carrying the unlock token, and writes the correction data into a pre-created new version branch after verifying the unlock token. The correction data is the data submitted by the user to modify the business data to be corrected, and the new version branch is associated with the original version of the business data to be corrected through a parent-child reference relationship.

[0009] In one implementation, the current business data is pre-locked in the following way: when the business flows to a preset target node, the hash value of the current business data is calculated; the hash value of the current business data is linked with the hash value of the previous business data version to form a hash chain; wherein, the previous business data version refers to the locked data version generated by the previous target node; the hash value of the current business data is stored in the WORM storage area, and the current business data is marked as locked.

[0010] In one implementation, after responding to a client's request to correct business data that is in a locked state, the method further includes: performing a whitelist check on the correction request to determine whether the semantic type of the correction request belongs to a preset correction compliance whitelist; if it does not belong, the correction request is directly rejected.

[0011] In one implementation, before sending a compliance challenge message to the client, the method further includes performing a status check on the correction request through the following steps: checking whether the business data to be corrected is currently in a locked state, and checking whether the field targeted by the correction request belongs to the range of fields that can be modified; if the business data to be corrected is not in a locked state or the field targeted by the correction request does not belong to the range of fields that can be modified, then the correction request is rejected; if the status check passes, then a compliance challenge message is returned to the client.

[0012] In one implementation, writing the corrected data into a pre-created new version branch includes: using a data model representing the correspondence between the main table and the version table, taking the original version as the parent version, generating a child version snapshot with a new version identifier, and writing the corrected data into the child version snapshot; wherein the main table only stores the latest version pointer, the version table stores all historical data snapshots, and each historical data snapshot records its parent version identifier.

[0013] In one implementation, after writing the corrected data into the new version branch, the method further includes: comparing the data differences between the original version and the new version branch; and generating a compensatory correction record based on the data differences to cancel the original data record and record the new data record.

[0014] In one implementation, after writing the corrected data into the new version branch, the method further includes: calculating the hash value of the new version branch, marking the state of the new version branch as locked, and prohibiting in-situ overwrite operations on the new version branch.

[0015] Secondly, embodiments of the present invention also provide a data compliance correction system, the system comprising: The request receiving and challenge sending module is configured to send a compliance challenge message to the client in response to a client's request to correct business data that is in a locked state; the compliance challenge message is used to instruct the client to provide unlocking credentials that match the risk level of the modified content; The credential verification and token issuance module is configured to receive the unlocking credential submitted by the client based on the compliance challenge information, and after verifying the validity of the unlocking credential, issue an unlocking token to the client. The data correction and version management module is configured to receive correction data submitted by the client carrying the unlock token, and after verifying the unlock token, write the correction data into a pre-created new version branch; wherein, the correction data is the data submitted by the user after modifying the business data to be corrected, and the new version branch is associated with the original version of the business data to be corrected through a parent-child reference relationship.

[0016] Thirdly, embodiments of the present invention also provide an electronic device, including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method described in any one of the first aspects.

[0017] This invention provides a data compliance correction method, system, and electronic device. In response to a client's correction request for locked business data, the system sends a compliance challenge to the client; receives an unlocking credential submitted by the client based on the compliance challenge; and, after verifying the validity of the unlocking credential, issues an unlocking token to the client. It also receives the correction data submitted by the client carrying the unlocking token, and, after verifying the unlocking token, writes the correction data into a pre-created new version branch. By sending compliance challenge information based on risk level to the client and issuing time-sensitive unlocking tokens, fine-grained dynamic verification of correction requests and temporary least privilege control are achieved. Simultaneously, by leveraging independent new version branches and their parent-child reference relationships, historical data is fully preserved, and automatic difference comparison and compensation record generation are supported. This ensures high-standard compliance audit requirements are met while avoiding data inconsistency errors, while maintaining business efficiency and security.

[0018] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0019] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

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

[0021] Figure 1 A flowchart illustrating a data compliance correction method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a business data pre-locking process provided in an embodiment of the present invention; Figure 3 A data version fork and hash chain structure diagram provided in an embodiment of the present invention; Figure 4 A schematic diagram illustrating an irreversible node locking and compliant unlocking correction process provided in an embodiment of the present invention; Figure 5 A structural block diagram of a data compliance correction system provided in an embodiment of the present invention; Figure 6This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] In various automated business systems (such as workflow approval systems, order management systems, and resource allocation systems), once critical business data becomes effective, it often needs to meet strict audit compliance requirements, namely, ensuring the data is authentic, complete, and tamper-proof. To this end, existing systems typically employ a combination of state machines and access control to lock and protect effective data.

[0024] However, existing data governance mechanisms have the following technical flaws: First, most systems adopt a direct in-situ data update approach, recording only simple logs, resulting in the loss of data snapshots before modification and making the data evolution process untraceable, which is difficult to meet high-standard audit requirements; second, correction operations only update the current table entries while ignoring the synchronous adjustment of related records (such as summary statistics and downstream dependent data), which can easily lead to data inconsistencies and business logic errors within the system; finally, role-based access control lacks fine-grained verification of specific business credentials, allowing internal personnel to exploit permission vulnerabilities to arbitrarily tamper with critical data, increasing the risk of fraud.

[0025] Based on this, the present invention provides a data compliance correction method, system, and electronic device. By sending compliance challenge information based on risk level to the client and issuing time-sensitive unlock tokens, it achieves fine-grained dynamic verification of correction requests and temporary least privilege control. At the same time, by leveraging independent new version branches and their parent-child reference relationships, it fully preserves historical data and supports automatic difference comparison and compensation record generation. Thus, while ensuring business efficiency and security, it meets high-standard compliance audit requirements and avoids data inconsistency errors.

[0026] To facilitate understanding of this embodiment, a data compliance correction method disclosed in this invention will first be described in detail, see [link to relevant documentation]. Figure 1 The diagram illustrates a data compliance correction method, which may include the following steps: S102, in response to the client's request to correct business data that is in a locked state, a compliance challenge message is sent to the client.

[0027] The compliance challenge information is used to instruct the client to provide unlocking credentials that match the risk level of the modified content. The server dynamically determines the risk level based on the field content and data importance involved in the modification request, and then decides what level of verification credentials the client is required to provide (e.g., low risk only requires confirmation of the operation, medium risk requires approval and authorization, and high risk requires uploading supporting documents such as red-letter invoices).

[0028] Client-side: Refers to the terminal device or application that interacts with the server, such as the front end of an expense reimbursement app used by company employees or the web interface used by finance personnel. The client is responsible for initiating business requests, submitting supporting documentation, and receiving the processing results returned by the server.

[0029] Business data in a locked state that is not yet corrected refers to business data that has reached an irreversible node in the business process sequence (such as "payment completed" or "voucher archived") and has been fixed by the system in the form of a hash chain or other means, and is prohibited from being modified in place.

[0030] A correction request is an instruction sent by the client to the server to request modification of a locked piece of data. This request typically includes a unique identifier for the data to be modified (such as a document number or version ID), the name of the field to be modified, a description of the reason for the modification, and the identity information of the requester. A correction request is a prerequisite for triggering subsequent compliance challenge processes.

[0031] For example, on the server side, when a correction request is received from a client for a piece of business data that has been marked as locked and is awaiting correction, the server first performs basic legality checks on the correction request (such as checking the request format and the existence of data identifiers). If the checks pass, the server immediately returns a compliance challenge message to the client. This compliance challenge message is typically encapsulated in JSON or XML format and includes a unique identifier for the challenge, the type of evidence required (such as a red-ink invoice code, approval number, etc.), the deadline for evidence submission, and the risk level assessed for the correction request. After receiving the compliance challenge message, the client must collect and upload the corresponding verification credentials as required in the message before proceeding to the next stage of the token application process.

[0032] In one example, the risk level of the verification credentials required in the compliance challenge information is dynamically determined based on the modifications involved in the remediation request; specifically: when the modifications are at a low risk level, no external verification credentials are required, only confirmation is needed from the party initiating the remediation request; when the modifications are at a medium risk level, authorization information from a management role with preset approval authority is required; and when the modifications are at a high risk level, supplementary supporting documents proving the legality of the remediation are required.

[0033] S104: Receive the unlock credentials submitted by the client based on the compliance challenge information, and after verifying the validity of the unlock credentials, issue an unlock token to the client.

[0034] Unlock credentials are evidence submitted by the client to the server to prove the compliance of its modification request. The specific form of the unlock credentials depends on the risk level of the modification request: in low-risk scenarios, it may only be an operation confirmation instruction (without attachments); in medium-risk scenarios, it may be a screenshot of approval or a work order number; and in high-risk scenarios, it may be a verifiable legal document such as a red-ink invoice notification number or a bank refund electronic receipt. Unlock credentials are the key basis for the server to determine whether to authorize modification.

[0035] Verifying the validity of the unlocking credential: This refers to the server performing a series of verification operations on the unlocking credential submitted by the client, including but not limited to: format integrity checks, consistency comparison with external authoritative data sources (such as tax bureau systems, bank interfaces, OA approval workflows), whether the credential is valid, and whether the business entity pointed to by the credential matches the data to be corrected.

[0036] Issuance: The process by which a server generates and sends a digital token. Issuance signifies that, after verification, the server formally grants the client a temporary, controlled permission to operate. The issuance process typically involves a cryptographic signature to ensure the token's unforgeability and integrity.

[0037] Unlock Token: A temporary digital credential issued by the server, which the client must include when submitting corrected data. Technically, the unlock token can be implemented using JSON Web Token (JWT) or a variant thereof. It contains the server-granted scope of permissions (e.g., only allowing modification of "tax amount" or "invoice number" fields), a validity period window (e.g., valid for 5 minutes after self-signing), and the associated correction request ID. When processing corrected data, the server first verifies the token's authenticity and permission boundaries to prevent unauthorized modification. The unlock token design combines the security features of "short validity" and "least privileges," making it the core security carrier of the controlled correction mechanism. For example, the token structure might use a JWT (JSON Web Token) variant, with the payload containing: { target_id, allowed_fields: ["tax_no", "title"], expire_at:171889900, proof_ref: "Red_Invoice_001"}, and signed with the system private key.

[0038] For example, after returning compliance challenge information to the client, the server remains in a waiting state, continuously listening for the client's response. When it receives unlocking credentials (such as red-letter invoice codes, screenshots of superior approvers' signatures, bank refund transaction numbers, etc.) submitted by the client according to the compliance challenge information requirements, the server immediately initiates a verification process: First, it parses the data format of the unlocking credentials and extracts key evidence items; then, it compares them with pre-stored business ledgers, third-party systems (such as the tax bureau's red-letter invoice database, OA approval system), or local rule engines to confirm the authenticity, validity period, and relevance to the business data to be corrected. If the verification passes (e.g., the red-letter invoice code actually exists in the tax bureau system and the amount is consistent), the server generates an unlocking token. This unlocking token is typically in JWT format, signed with the server's private key, and its payload specifies the allowed modified field names, token validity period (e.g., 5 minutes), and associated correction request ID. Finally, the server returns the unlocking token to the client via an encrypted channel (such as HTTPS), and the client must carry this token to continue performing subsequent data modification operations.

[0039] S106 receives the correction data submitted by the client, which carries the unlock token, and writes the correction data to a pre-created new version branch after verifying the unlock token.

[0040] Among them, the corrected data is the data submitted by the user after modifying the business data to be corrected. The new version branch is related to the original version of the business data to be corrected through a parent-child reference relationship.

[0041] Unlock token verification successful: This means the server successfully performs a series of verification actions on the unlock token submitted by the client. Specifically, this includes: ① Signature verification: Verifying that the unlock token's signature was issued by a valid private key using the system's public key; ② Validity verification: Checking if the validity period in the unlock token is greater than the current server time; ③ Permission verification: Confirming that the set of fields the client requested to modify is a subset of the "allowed modification field list" in the unlock token; ④ Consistency verification: Verifying that the request ID or data ID bound to the unlock token matches the ID of the data to be modified. Only after all verification items pass will the server continue with the write operation.

[0042] A pre-created new version branch refers to an independent data carrier pre-allocated by the server in the version store before the correction process begins (or upon receiving the unlock token), used to hold the corrected data. This branch is associated with the original business data version through a "parent-child reference relationship" (e.g., storing the Parent_Version_ID field in the version table). The new version branch can be created immediately upon token issuance as a placeholder record, or it can be generated in real-time after token verification. However, the term "pre-created" emphasizes that the version branch is not an in-situ modification of the original version, but a new version object independent of the original storage. Using a new version branch ensures that the original version data remains completely unchanged; any corrections are presented as append versions, thus meeting the requirements for audit traceability and data tamper-proofing.

[0043] For example, after issuing an unlock token to the client, the server enters a phase of waiting for corrected data. The client must send the corrected data along with the unlock token to the server's designated interface within the token's validity period (e.g., 5 minutes). Upon receiving the request, the server first extracts the unlock token from the request header or body, and verifies the token using the public key held by the system to confirm that the token has not been tampered with. Secondly, it checks whether the token's validity period has expired, whether the allowed modification fields declared on the token cover the fields involved in the corrected data submitted by the client, and whether the token matches the previously issued request ID.

[0044] If all verifications pass, the server immediately locates the original storage location of the business data to be corrected and activates a pre-created new version branch storage area (e.g., a record with a parent-child relationship identifier already reserved in the version table). The server then writes the client's corrected data into the new version branch after format validation and field mapping. After writing, the server records metadata such as the operator, operation time, original version ID, and new version ID, and marks the new version branch's status as "committed and awaiting locking" or directly proceeds to the subsequent hash calculation and locking process. The entire writing process follows the "append-only, no overwrite" principle, keeping the original version data unchanged, thus ensuring the integrity and traceability of historical data.

[0045] This invention provides a data compliance correction method that achieves fine-grained dynamic verification of correction requests by sending compliance challenge information to the client and providing unlocking credentials based on risk level requirements. This allows for rapid confirmation of low-risk modifications and requires authoritative proof for high-risk modifications, effectively curbing unauthorized operations and internal fraud while ensuring business efficiency. By issuing time-limited unlocking tokens after verifying the validity of the unlocking credentials, the method achieves temporary authorization and minimum permission control for corrections. Even if the token is intercepted during transmission, it cannot be used after expiration or for unauthorized fields, significantly improving the security of the correction process. By writing the corrected data into an independent new version branch and establishing a parent-child reference relationship with the original version, the method achieves complete retention of historical data and traceability of each correction. The original version is never overwritten, and any audit can trace the complete evolution process along the version chain, meeting high-standard compliance requirements. The parent-child association between the new version branch and the original version provides a structured version basis for subsequent automatic difference comparison and compensation record generation, achieving automatic linkage between the corrected and original data and avoiding data inconsistency errors caused by manual processing.

[0046] In one possible implementation, the current business data is pre-locked in the following way: S202, when the business flow reaches the preset target node, calculate the hash value of the current business data.

[0047] Among them, the preset target node refers to a node that is pre-marked in the business process state machine, and whose data cannot be overwritten or modified after it is reached. These nodes usually correspond to completion states with legal effect or financial settlement significance, and the system will list them in the form of enumeration or whitelist in the code or configuration file. Current business data refers to a snapshot of the business object at the moment of transition to the target node, containing all attribute values ​​of the business instance. Hash value: A fixed-length digital fingerprint calculated from data of arbitrary length using a hash function.

[0048] For example, the system predefines a set of business status nodes as "target nodes" to trigger locking, such as "payment completed," "electronic voucher generated," and "contract archived." When the business processing engine detects that the current business object has flowed to the target node, it immediately triggers the hash calculation process. The server extracts all key fields of the current business data (such as order number, amount, timestamp, related party ID, etc.), organizes them into a key-value pair sequence according to the agreed sorting rules (such as ascending field name), and then serializes them into a standard JSON string or byte stream. Subsequently, a cryptographic hash function (such as SHA-256 or the national cryptographic standard SM3) is called to calculate the byte stream, outputting a fixed-length (such as 256 bits) hash value. This calculation process is completed synchronously before the transaction is committed, ensuring that the hash value and the business status are solidified simultaneously. For example, node fingerprint calculation: $Hash_{current} =SHA256(Data_{payload} + Timestamp + Hash_{previous} + Salt)$. Introducing the hash value corresponding to the previous node is to build a causal chain; any tampering with historical nodes will cause the hash verification of all subsequent nodes to fail.

[0049] This step, by synchronously calculating hash values ​​at preset target nodes, solidifies the state of business data and atomically binds it to the generation of digital fingerprints. This ensures that any subsequent tampering with the data can be detected by changes in the hash fingerprint, thereby achieving non-repudiation and integrity verification capabilities for the data content.

[0050] S204 links the hash value of the current business data with the hash value of the previous business data version to form a hash chain.

[0051] The "previous business data version" refers to the locked data version generated by the previous target node. It can also be understood as the previous locked data version of the same business object in terms of time sequence. For example, if the first commit generates V1 and the second compliance correction generates V2, then V1 is the "previous business data version" of V2. This version has already undergone the locking process and has its own hash value and locking status.

[0052] Hash chains are data structures in which the hash value of each data block (version) is linked to the hash value of the previous block. Any modification to the content of a historical block changes its hash value, thus breaking the link with subsequent blocks and causing the verification of the entire chain to fail. Hash chains provide cryptographic-level guarantees for the temporal integrity of data.

[0053] Link: refers to the operation of establishing an association between the current hash value and the previous hash value. Specifically, it can be done by concatenating and then hashing again, or by explicitly storing the previous hash value in a linked list.

[0054] For example, after calculating the hash value of the current business data, the system queries the previous locked data version of the same business object (e.g., finding the record with the largest parent version identifier in the version table) and obtains the hash value of that version. If no previous version exists (i.e., the current version is the first version), a system-preset "genesis hash value" (e.g., all zeros or a fixed constant) is used. The server concatenates the current hash value with the previous hash value in sequence (e.g., previous hash value + current hash value or current hash value + previous hash value, depending on the design), and recalculates the hash value of the concatenated string to obtain the "link hash value". Alternatively, a simpler approach is to directly store the combination of "current hash value + previous hash value" as a chained record. In practice, a `parent_hash` field is often added to the version table to directly record the hash value of the previous version, and the link relationship is recalculated during verification. The chaining operation of the hash chain is usually completed together with the hash calculation within the same database transaction to ensure atomicity.

[0055] This step creates a hash chain, ensuring that any tampering with historical data versions will cause all subsequent versions to fail verification, thus achieving "one-time modification, global awareness" tamper-proof capability. This technique does not rely on centralized notarization; it can prove historical integrity solely through cryptographic links, meeting the requirements for auditing, tracing, and judicial evidence collection.

[0056] S206, store the hash value of the current business data into the WORM storage area, and mark the current business data as locked.

[0057] WORM storage area: short for Write Once Read Many, refers to a storage medium or logical area that can only be read, not modified or deleted, after a single write. WORM characteristics can be implemented through various methods such as physical read-only media, software access control policies, and blockchain-based storage, all of which ensure the immutability of written data.

[0058] Locked Status: A logical flag assigned to a data version (e.g., field state = 'LOCKED') indicating that the version has been hashed and protected against tampering. The system checks this flag before performing any modification operations; only unlocked data is allowed to be updated directly, while locked data must go through the version branch process.

[0059] Tag: Refers to updating a status field in the database or writing metadata to the status management service.

[0060] For example, after hash calculation and linking are completed, the system writes the hash value of the current business data (and optionally the link record of the previous hash value) to the WORM storage area. The WORM storage area can be a dedicated hardware device that supports write-once-read-many (such as a tape library or optical disc library), an object-locked bucket in a cloud storage service (such as AWS S3 ObjectLock), or a table with tamper-proof constraints implemented using a database (e.g., disabling UPDATE and DELETE through database triggers). After the write operation is completed, the system updates the status field of the data version to "LOCKED" in the business master table or version status table. Thereafter, when any application or user attempts to perform modification operations such as UPDATE or DELETE on this version, the database interceptor or application layer interceptor will refuse to execute based on the "LOCKED" flag, and only allow the creation of new versions through the version branching mechanism.

[0061] This step, by storing the hash value in the WORM storage area and combining it with logical locking tags, prevents in-situ modification of the solidified data at both the physical and logical levels. Even operators with database administrator privileges find it difficult to bypass WORM's write protection, while the logical tags provide the application layer with a quick basis for judgment. This method ensures the permanent preservation and non-repudiation of historical data versions, providing solid technical support for compliance auditing.

[0062] In one possible implementation, after responding to a client's request to correct business data that is in a locked state, the method further includes: performing a whitelist check on the correction request to determine whether the semantic type of the correction request belongs to a preset correction compliance whitelist; if it does not belong, the correction request is directly rejected.

[0063] Whitelist verification is an access control method based on a permission list. The system predefines a set of allowed modification operation types (i.e., a whitelist), and only allows operations requested by clients that belong to types within this list; otherwise, it directly rejects them. Semantic type refers to the category identifier obtained after classifying the business meaning of the modification request. Unlike underlying SQL operations (such as UPDATE), semantic types are closer to business language, such as "invoice information change," "account adjustment," and "remark supplement." The system can identify the semantic type of the request through natural language processing or a predefined field-operation mapping table. The modification compliance whitelist is a set of allowed modification operation rules pre-configured by the system administrator or compliance department. Each rule can include the following elements: the name of the business field that can be modified, the preconditions for modification (e.g., the amount remains unchanged, the associated approval form has been approved), and the applicable business role or department scope. The whitelist can be dynamically adjusted according to regulatory requirements or internal management standards.

[0064] For example, after receiving a correction request from a client, the server first extracts key semantic features from the request message, including the name of the business field to be modified (such as "tax amount", "invoice number", "payment account"), the type of modification operation (such as "replace", "delete", "add"), and the associated business scenario identifier (such as "expense reimbursement" or "purchase order"). The server matches these features with a correction compliance whitelist maintained by the system. The whitelist is usually stored in a database or configuration center in the form of a rule table. Each rule defines a semantic type of correction that is allowed, such as allowing modification of the invoice tax number, provided that the tax number before and after the change conforms to the national standard format, or allowing adjustment of the reimbursement subject, but the subject code must be within the range of a preset subject tree. If the semantic type of the correction request matches a rule in the whitelist, the verification passes and the process continues to the subsequent status check or compliance challenge steps; if no rule is matched (for example, a request to modify the "Payment Amount" field, while the whitelist only allows modification of "Remarks" and "Attachments"), the server immediately terminates the correction request and returns a rejection response to the client, which may include the reason for rejection (such as the field not being in the whitelist or the current operation not being allowed).

[0065] This step, by adding whitelist verification at the outset of remediation requests, enables rapid semantic filtering of these requests. Requests that clearly violate compliance policies (such as attempts to modify core financial amounts or delete critical vouchers) are rejected early on, avoiding unnecessary subsequent status checks, compliance challenges, and token issuance processes, thus saving server computing resources and business processing time. Simultaneously, the whitelist mechanism provides clear business boundaries for remediation operations, preventing misoperations or unauthorized actions due to overly broad permissions. Therefore, without affecting normal remediation efficiency, it further enhances the system's security and compliance.

[0066] In one possible implementation, before sending a compliance challenge message to the client, the method further includes performing a status check on the correction request by the following steps: checking whether the business data to be corrected is currently locked, and checking whether the field targeted by the correction request is within the range of fields that can be modified; if the business data to be corrected is not locked or the field targeted by the correction request is not within the range of fields that can be modified, then the correction request is rejected; if the status check passes, then a compliance challenge message is returned to the client.

[0067] For example, after receiving a correction request from a client and completing whitelist verification (if applicable), the server proceeds to the status check stage. First, the server queries the status field in the business database based on the business object identifier (such as document ID or version number) carried in the correction request to determine if the current status of the business data to be corrected is LOCKED. If the status is UNLOCKED or DRAFT, it means the data has not been hash-locked and should not proceed with the correction process; the server directly rejects the request. Second, the server parses the fields to be modified specified in the correction request (e.g., extracting "modified_fields": ["tax_no", "amount"] from the JSON request body) and compares these fields with the system-configured "list of fields allowed to be modified". This list can be globally fixed (e.g., only allowing modification of "remarks", "attachments", and "invoice numbers"), or dynamically obtained based on business type or data status. If any of the requested fields is not within the allowed range (e.g., attempting to modify the "amount" field when it is not in the list), the check fails, the server rejects the request, and may return an error code and the specific reason. The status check only passes when the data is indeed locked and all fields requested for modification are within the allowed range. Only then will the server proceed to send compliance challenge information to the client.

[0068] This step, by adding a status check before sending compliance challenge information, enables rapid pre-filtering of remediation requests. Requests that do not yet have locked data (i.e., should not enter the remediation process) or request modifications to illegal fields (i.e., outside the scope of permissions) are rejected early on, avoiding subsequent meaningless compliance challenge interactions and token generation operations. This step significantly reduces unnecessary server load and improves the overall system response efficiency. Simultaneously, it ensures that only requests meeting the two fundamental conditions of data being indeed locked and field modifications being compliant can enter the risk verification process, enhancing the logical rigor and security of the remediation process.

[0069] In one possible implementation, writing corrected data to a pre-created new version branch includes: employing a data model representing the correspondence between the master table and the version table, using the original version as the parent version, generating a child version snapshot with a new version identifier, and writing the corrected data to the child version snapshot; wherein, the master table only stores pointers to the latest version, the version table stores all historical data snapshots, and each historical data snapshot records its parent version identifier. The data model representing the correspondence between the master table and the version table is a database design pattern that separates the current state of a business object from its historical evolution. The master table focuses on the latest state and is used for daily business queries and display; the version table focuses on historical snapshots and is used for auditing, tracing, and version comparison. The two are linked through a business primary key (such as a document ID), and each record in the version table forms a chain structure through its parent version identifier.

[0070] For example, after the server verifies the unlock token, the system enters the version branch writing phase. The system maintains two core data tables: a main table (e.g., Transaction_Head) and a version table (e.g., Transaction_Ver). Each record in the main table corresponds to a business object, storing only a pointer to the current latest version (e.g., Current_Ver_ID), not complete historical data. The version table stores all historical version snapshots of the business object. Each version record includes: version number (Ver), complete data payload (Data, usually stored in JSON or serialized format), parent version identifier (Parent_Version_ID), state flag (State), hash value, and other fields. When corrective data needs to be written, the system uses the original version (i.e., the version record corresponding to the business data to be corrected) as the parent version, adds a new record to the version table: assigns a new version identifier (e.g., Ver = original version.Ver+1), serializes the corrective data and fills it into the Data field, and sets Parent_Version_ID to the ID of the original version. At the same time, the system updates the latest version pointer in the main table to this new version ID. If a pre-creation strategy is adopted, the system can create a placeholder record in the version table when issuing tokens, and then fill in the full content after receiving the corrected data. After the write is complete, the system calculates the hash value of the new version snapshot and marks it as locked, thereby completing the generation and data writing of the entire version branch.

[0071] In one possible implementation, after writing the corrected data to the new version branch, the method further includes: comparing the data differences between the original version and the new version branch; and generating a compensatory correction record based on the data differences to cancel the original data record and record the new data record.

[0072] Compensatory correction records are a set of structured log entries used to offset the impact of original data and confirm the impact of new data, similar to red-to-blue reversal in finance. Each change corresponds to two sub-records: one reversal record (indicating that the original value should be canceled or reversed) and one addition record (indicating that the new value should take effect). Compensatory correction records ensure data consistency and traceability within the system, achieving equivalent results through compensation logic even if the original data is not overwriteable.

[0073] Reversing original data records: This refers to generating an operation record that offsets the changes in the original version. For example, if a field value is X in the original version and is changed to Y after correction, the reversal record indicates -X or undoes X, so that the original value is no longer included in subsequent summaries in the business logic.

[0074] Recording new data: This refers to generating an operation record corresponding to the corrected new value, indicating +Y or applying Y. Through the combination of reversal and addition, the system updates the data facts without modifying the original version.

[0075] For example, after the server successfully writes the corrected data to the new version branch, the system automatically triggers the difference comparison and compensation record generation process. First, it reads data snapshots from the version table for both the original version (parent version) and the new version branch (child version). Both snapshots are stored in a structured format (such as JSON or database rows). The system uses a recursive comparison algorithm to traverse the two snapshots field by field, identifying changed fields (e.g., tax amount changes from 100 to 120, receiving account changes from A to B), newly added fields, and deleted fields. The comparison results generate a difference set, containing the values ​​before and after the change, as well as the change path.

[0076] Subsequently, the system generates compensatory correction records based on this difference set. Compensatory correction records are typically represented as a set of positive and negative operations: for each change, a reversal record is generated to undo or offset the impact of that data item in the original version; simultaneously, a new record is generated to record the changed data item and its impact in the new version branch. In practice, compensatory correction records can be stored in a dedicated compensatory record table or audit log table. Each record must contain at least: original version identifier, new version identifier, changed field name, reversal value, new value, generation timestamp, and operation type (e.g., reversal / new). The generated compensatory correction records are associated with the corresponding new version branch via version ID, facilitating subsequent auditing, rollback, or accounting alignment operations.

[0077] This step automatically compares the data differences between the original and new versions of the branch, and generates compensatory correction records that reverse the original data records and record the new data records. This achieves the following technical effects: the compensatory correction records clearly document every detail of the change from the original value to the new value. Combined with a snapshot of the new version branch, auditors can clearly understand the reasons, content, and impact of the corrections without relying on additional logs or guesswork. In areas such as finance, inventory, and billing, compensatory correction records can be directly consumed by accounting engines and inventory management systems to automatically generate red-ink reversal vouchers or inventory adjustment orders, significantly reducing manual intervention and error rates.

[0078] In one possible implementation, generating a compensatory correction record for reversing the original data record and recording the new data record includes: generating a first type of compensatory record for reversing the data items that have changed in the original version, and generating a second type of compensatory record for recording the changed data items in the new version branch; and associating the identifiers of the first type of compensatory record and the second type of compensatory record with the metadata of the new version branch.

[0079] The first type of compensation record is a record generated for each data item that has been changed in the original version, used to undo or offset the original impact of that data item. A first-type compensation record typically includes: compensation record ID, associated original version ID, changed field path, original value, generation time, and operation type (reversal).

[0080] The second type of compensation record: A record generated for each data item changed in the new version branch to confirm or apply the impact of the new data. The second type of compensation record includes: compensation record ID, associated new version ID, changed field path, new value, generation time, and operation type (record).

[0081] Identifier-based storage: This refers to storing the unique identifiers (such as database auto-incrementing IDs or UUIDs) of the first and second type compensation records in a structured manner (such as arrays or string lists) into the metadata fields of the new version branch. This establishes an explicit and directly queryable association between the new version branch and the compensation records, allowing all compensation operations to be retrieved without complex data difference recalculation.

[0082] For example, after comparing the data differences between the original version and the new version branch, the system obtains a set of differences, where each change contains three elements: change path (e.g., / amount), original value (e.g., 100), and new value (e.g., 120). For each change in the set of differences, the system generates two independent compensation records. The first record is a first-type compensation record, which cancels the original value, i.e., records the amount in the original version as 100, which should be revoked. Specifically, it can be stored as operation type REVERSE, field path amount, original value 100, and target version ID (original version ID). The second record is a second-type compensation record, which records the new value, i.e., records the amount in the new version branch as 120, which should be applied. The operation type is APPLY, field path amount, new value 120, and target version ID (new version branch ID).

[0083] Next, after all changes have been processed, the system stores the unique identifiers (such as record IDs or UUIDs) of the generated first-type and second-type compensation records in a list format in the metadata of the new version branch. The metadata can be appended to the snapshot records of the new version branch (for example, storing JSON-formatted {"compensation_records": ["rec_001", "rec_002", ...]} in the metadata field of the version table). This way, when subsequent auditing or compensation logic is required, all relevant compensation records can be quickly located through the metadata of the new version branch without needing to re-compare the differences.

[0084] For example, such as Figure 3 The diagram illustrates a data version fork and hash chain structure, maintaining an immutable version chain and corresponding audit logs. Initially, version V1 is in a locked state (State: LOCKED), with its metadata recording the account as travel expenses, the amount as 1000, the hash value as a1b2…, and associated with voucher #001. When a correction operation is initiated due to an incorrect account, the system generates an unlock token Token_xyz and records the operation and reason in the audit log. Subsequently, a new version V2 is created, with its parent hash pointing to the hash value a1b2… of V1, and its own hash value as c3d4…, also marked as LOCKED. In V2's metadata, the account is corrected to entertainment expenses, while the amount remains unchanged at 1000. In accounting processing, the system generates a red-ink voucher #002 to offset the corresponding voucher #001 of V1, and a blue-ink voucher #003 to record the new accounting entry for V2. Both vouchers are associated with V2's metadata. V2 is the current active version, while V1, although obsolete, is still fully retained, thus achieving traceable version management and automatic accounting alignment.

[0085] In one possible implementation, after writing the corrected data to the new version branch, the method further includes: calculating the hash value of the new version branch, marking the state of the new version branch as locked, and prohibiting in-place overwrite operations on the new version branch.

[0086] In one possible implementation, for example: Transaction_Head: { ID: 1001, Current_Ver: 2}; Transaction_Ver: [{ ID: 1001, Ver: 1, Data: {...}, State: LOCKED},{ ID: 1001, Ver: 2, Data: {...}, State: LOCKED, Parent: 1}]; Automatic reconciliation algorithm: Load data objects V1 and V2, and calculate $Diff = V2 - V1$.

[0087] If $Diff.Amount \neq 0$ or $Diff.Subject \neq 0$: Generate voucher A (in red): Debit: V1. Account (-amount), Credit: Bank (-amount).

[0088] Generate voucher B (blue text): Debit: V2.Account (+Amount), Credit: Bank (+Amount).

[0089] Associate the credential A / B ID with the V2 version metadata.

[0090] For example, once the server completes writing the corrected data to the new version branch and persists the new version snapshot to the version table, the system immediately triggers a locking process for that new version branch. First, the system reads the complete data snapshot of the new version branch stored in the version table (including all business fields, timestamps, parent version identifiers, etc.), generates a byte stream according to the same serialization rules as the original version (e.g., converting fields to JSON strings after sorting), and calls a cryptographic hash function (SHA-256 or SM3) to calculate the hash value of the byte stream. The calculated hash value is written to the hash field of the version table, and a timestamp and salt value can be appended.

[0091] Subsequently, the system updates the status field of the new version branch from "Pending" or "Draft" to "LOCKED". At the database level, row-level locks, triggers, or application-level interceptors can ensure that any UPDATE or DELETE operations targeting records in this version branch are rejected. For example, an interception rule can be deployed at the database ORM layer: when the target record's status is detected as LOCKED and the executed SQL is UPDATE or DELETE, an exception or error code is thrown directly. Simultaneously, the database's WORM storage area (or a bucket configured with object locks) can further provide physical write protection. At this point, the new version branch, like the original version, enters a fixed, unwriteable state.

[0092] For example, such as Figure 4 The diagram illustrates a process for irreversible node locking and compliant unlocking correction. The user / finance (client) sends a correction request to the locking controller, requesting modification of already recorded data. This request includes the identifier of the business data to be corrected and the field information to be modified. Upon receiving the request, the locking controller checks the whitelist and status. Determine whether the semantic type of the correction request belongs to the preset correction compliance whitelist; Check if the business data to be corrected is currently locked (e.g., Ver1 status is LOCKED). Check whether the field requested for modification falls within the range of fields that are allowed to be modified.

[0093] If any check fails, the request is rejected; if it passes, proceed to the next step.

[0094] The lock controller returns a compliance challenge to the user / finance department, requiring the client to provide verification credentials (e.g., red-ink invoice number, approval certificate, etc.) matching the risk level of the modified content. The user / finance department collects and submits the credentials (e.g., red-ink invoice number) to the lock controller according to the challenge requirements. The lock controller forwards the submitted credentials to the token center for verification. After verifying the validity of the credentials, the token center issues an Unlock_Token (e.g., valid for 5 minutes) and returns the token to the lock controller. The lock controller forwards the Unlock_Token to the user / finance department. The user / finance department, carrying the Unlock_Token and the corrected data, submits a correction request to the lock controller again. The lock controller verifies the token's signature and permissions (checking the validity period, allowed field modification range, etc.). After successful verification, it requests to read the Ver1 snapshot (original version) from the business database.

[0095] The business database returns the Ver1 snapshot data to the lock controller. Based on the Ver1 snapshot, the lock controller writes the new version branch Ver2 into the business database, setting Parent=Ver1, and writes the corrected data to the Ver2 snapshot. The lock controller triggers a difference analysis: comparing the data differences between Ver1 and Ver2. The lock controller sends the difference results to the accounting engine, requesting the generation of compensatory correction records. The accounting engine generates red-ink vouchers (reversing V1) and blue-ink vouchers (recording V2) based on the differences and returns the generated voucher identifiers to the lock controller. The lock controller associates the red / blue-ink voucher identifiers into the metadata of Ver2 and stores them in the business database. The lock controller calculates the hash value of Ver2, marks the status of Ver2 as LOCKED, and prohibits in-situ overwrite operations on Ver2. The lock controller returns a confirmation message indicating that the correction is complete to the user / finance department.

[0096] Based on the same concept, embodiments of the present invention provide a data compliance correction system, such as... Figure 5 The diagram shown represents a structural block diagram of a data compliance correction system, which may include: The request receiving and challenge sending module 510 is configured to send a compliance challenge message to the client in response to the client's request to correct business data that is in a locked state; the compliance challenge message is used to instruct the client to provide unlocking credentials that match the risk level of the modified content; The credential verification and token issuance module 520 is configured to receive the unlock credentials submitted by the client based on the compliance challenge information, and issue an unlock token to the client after verifying the validity of the unlock credentials. The data correction and version management module 530 is configured to receive correction data submitted by the client carrying an unlock token, and write the correction data to a pre-created new version branch after verifying the unlock token. The correction data is the data submitted by the user after modifying the business data to be corrected, and the new version branch is associated with the original version of the business data to be corrected through a parent-child reference relationship.

[0097] The system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0098] This invention also provides an electronic device, such as... Figure 6 The diagram shows the structure of the electronic device, which includes a processor 61 and a memory 60. The memory 60 stores computer-executable instructions that can be executed by the processor 61. The processor 61 executes the computer-executable instructions to implement the aforementioned data compliance repair method.

[0099] exist Figure 6 In the illustrated embodiment, the electronic device further includes a bus 62 and a communication interface 63, wherein the processor 61, the communication interface 63, and the memory 60 are connected via the bus 62.

[0100] The memory 60 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 63 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 62 may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus 62 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0101] Processor 61 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 61 or by instructions in software form. Processor 61 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this invention can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the memory, and the processor 61 reads the information in the memory and, in conjunction with its hardware, completes the steps of the data compliance repair method of the aforementioned embodiment.

[0102] This invention also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are called and executed by a processor, they cause the processor to implement the aforementioned data compliance modification method. For specific implementation details, please refer to the foregoing method embodiments, which will not be repeated here.

[0103] The computer program products of the data compliance repair method, apparatus and electronic device provided in the embodiments of the present invention include a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0104] Unless otherwise specifically stated, the relative steps, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of the invention.

[0105] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0106] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0107] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A data compliance correction method, characterized in that, Applied to a server, the method includes: In response to a client's request to correct business data that is locked, a compliance challenge message is sent to the client; the compliance challenge message is used to instruct the client to provide unlocking credentials that match the risk level of the modified content. Receive the unlocking credentials submitted by the client based on the compliance challenge information, and after verifying the validity of the unlocking credentials, issue an unlocking token to the client; The system receives correction data submitted by the client, carrying the unlock token, and writes the correction data into a pre-created new version branch after verifying the unlock token. The correction data is the data submitted by the user to modify the business data to be corrected, and the new version branch is associated with the original version of the business data to be corrected through a parent-child reference relationship.

2. The method according to claim 1, characterized in that, Pre-lock current business data using the following methods: When the business flow reaches the preset target node, calculate the hash value of the current business data; The hash value of the current business data is linked with the hash value of the previous business data version to form a hash chain; wherein, the previous business data version refers to the locked data version generated corresponding to the previous target node; The hash value of the current business data is stored in the WORM storage area, and the current business data is marked as locked.

3. The method according to claim 1, characterized in that, After responding to a client's request to correct business data that is in a locked state, the method further includes: performing a whitelist check on the correction request to determine whether the semantic type of the correction request belongs to a preset correction compliance whitelist; if it does not belong, the correction request is directly rejected.

4. The method according to claim 1, characterized in that, Before sending a compliance challenge message to the client, the method further includes performing a status check on the remediation request through the following steps: Check whether the business data to be corrected is currently locked, and check whether the field targeted by the correction request is within the range of fields that can be modified; If the business data to be corrected is not in a locked state or the field targeted by the correction request is not within the range of fields that can be modified, then the correction request is rejected. If the status check passes, a compliance challenge message is returned to the client.

5. The method according to claim 1, characterized in that, The step of writing the corrected data into a pre-created new version branch includes: A data model representing the correspondence between the main table and the version table is adopted. The original version is used as the parent version to generate a child version snapshot with a new version identifier, and the corrected data is written into the child version snapshot. The main table only stores the latest version pointer, the version table stores all historical data snapshots, and each historical data snapshot records its parent version identifier.

6. The method according to claim 1, characterized in that, After writing the corrected data into the new version branch, the method further includes: Compare the data differences between the original version and the new version branch; Based on the data differences, a compensatory correction record is generated to cancel the original data record and record the new data record.

7. The method according to claim 6, characterized in that, The generation of compensatory correction records for reversing original data records and recording new data records includes: Generate a first type of compensation record for offsetting the changed data items in the original version, and generate a second type of compensation record for recording the changed data items in the new version branch; The identifiers of the first type of compensation record and the second type of compensation record are associated and stored in the metadata of the new version branch.

8. The method according to claim 1, characterized in that, After writing the corrected data into the new version branch, the method further includes: calculating the hash value of the new version branch, marking the state of the new version branch as locked, and prohibiting in-place overwrite operations on the new version branch.

9. A data compliance correction system, characterized in that, The system includes: The request receiving and challenge sending module is configured to send a compliance challenge message to the client in response to a client's request to correct business data that is in a locked state; the compliance challenge message is used to instruct the client to provide unlocking credentials that match the risk level of the modified content; The credential verification and token issuance module is configured to receive the unlocking credential submitted by the client based on the compliance challenge information, and after verifying the validity of the unlocking credential, issue an unlocking token to the client. The data correction and version management module is configured to receive correction data submitted by the client carrying the unlock token, and after verifying the unlock token, write the correction data into a pre-created new version branch; wherein, the correction data is the data submitted by the user after modifying the business data to be corrected, and the new version branch is associated with the original version of the business data to be corrected through a parent-child reference relationship.

10. An electronic device, characterized in that, The method includes a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method of any one of claims 1 to 8.

Images