Long-period performance examination consistency control method and system

Abstract

The application provides a long-period performance evaluation consistency control method and system, and relates to the technical field of performance evaluation management. The application divides the performance evaluation scheme configuration into a draft state and an instance state two-state model, performs consistency binding on the draft configuration and external dependence through two-stage verification, generates an instance snapshot after the verification passes, and only depends on the instance snapshot during the instance running period and isolates the influence of organizational changes, and ensures that the process is not interrupted and the whole link is left with traces through event-driven exception handling; meanwhile, a verifiable audit playback function is provided to support provable playback of dispute scenarios, thereby significantly improving the stability, consistency and auditability of long-period evaluation.

Description

Technical Field

[0001] This invention relates to the field of performance appraisal management technology, and in particular to a method and system for controlling the consistency of long-term performance appraisal. Background Technology

[0002] In existing enterprise performance management systems, inconsistencies commonly exist between configuration, execution, and dynamic organizational changes when handling long-cycle performance appraisal processes. This directly impacts the fairness, auditability, and stability of the appraisal. Currently, mainstream performance management systems typically employ a combination of "configuration-referenced execution + single-stage verification + coarse-grained version numbering + manual fallback for anomalies," lacking verifiable auditing capabilities. Specifically, configuration-referenced execution means that the appraisal task continuously reads real-time updated configuration, template, and organizational structure information during execution to automatically adapt to changes; single-stage verification means performing only a form-level / rule-level verification before initiating the appraisal task; coarse-grained version numbering means maintaining only template or process versions, lacking consistent binding for dependencies on organization, permissions, and rules; manual fallback for anomalies means handling issues like reviewer departures or job transfers through manual assignment or temporary modifications, lacking a unified strategy and audit evidence chain; and the lack of verifiable auditing means that while logs can be recorded, it's difficult to prove "what the basis was at the time of initiation and whether it was tampered with during execution."

[0003] Research has revealed the following significant shortcomings in existing technologies: 1. Configuration drift and organizational change contamination during execution: After an assessment instance is initiated, if the backend assessment scheme configuration (such as scoring rules and process nodes) or the company's real-time organizational structure (such as reporting relationships) changes, the running instance will change its behavioral basis accordingly. This leads to inconsistent assessment rules for different participants or at different times within the same assessment cycle, resulting in confusion about "who should be assessed" and "what rules should be used for assessment," which can seriously lead to task misassignment and result disputes.

[0004] 2. Accidents and consistency issues caused by concurrent operations: Multiple administrators may simultaneously edit different parts of the same assessment plan. Due to the lack of effective concurrency control and eventual consistency guarantee mechanisms, at the moment an administrator clicks "Initiate," the configuration version actually used by the system may not be the version they finally confirmed, but rather an unknown version that has been concurrently modified by others, i.e., "configuration drift," which can easily lead to accidental initiation or rule errors.

[0005] 3. Lack of standardized mechanisms and audit traceability in anomaly handling: During assessment periods that can last for several months, situations such as reviewers leaving or being reassigned are inevitable. Existing systems often rely on temporary manual handling, such as manually reassigning tasks. This approach is inefficient and lacks a unified handling strategy and complete operational logs. If disputes arise later, it is impossible to effectively reconstruct and prove the basis and process of the handling at the time.

[0006] 4. Weak Verifiability and Auditability: While the existing system can record operation logs, it is difficult to form a complete and verifiable "chain of evidence." When employees appeal their performance evaluation results, it is difficult to efficiently and reliably review and prove: What was the exact basis for the appeal? Was the data tampered with during execution due to system or human error? Did the handling of the anomaly comply with established rules? This "black box" state increases management costs and legal risks.

[0007] Therefore, there is an urgent need for a technical solution that can ensure the consistency and auditability of long-term performance evaluation from configuration, initiation to execution and archiving, in order to solve the problems of configuration drift, concurrent incidents, chaotic anomaly handling and difficulty in audit traceability. Summary of the Invention

[0008] The purpose of this invention is to provide a long-term performance evaluation consistency control method and system, so as to at least solve one of the problems existing in the prior art, such as configuration drift, concurrent accidents, chaotic anomaly handling and difficulty in audit traceability.

[0009] In a first aspect, the present invention provides a method for controlling the consistency of long-term performance appraisals, comprising: In response to users' performance appraisal scheme configuration operations, create and maintain draft configurations in draft state, and record change audit logs; among them, draft configurations support versioned editing and concurrent change management; During the process of initiating an assessment transaction, a two-stage verification is performed: the first stage verification includes pre-verification of the draft configuration before editing the draft configuration or initiating the assessment transaction; the second stage verification includes final verification of the draft configuration based on the bound external dependency consistency view after initiating the assessment transaction. The external dependency consistency view includes at least the organizational structure snapshot version, the assessment template version, and the policy version. After the second phase of verification is passed, the draft configuration and its associated external dependency consistency view are frozen together to generate an instance snapshot in the instance state, and the integrity verification value of the instance snapshot is calculated; the instance snapshot includes an immutable copy of the cycle, participation scope, review relationship, process rules, scoring template and its dependency version identifier; Based on instance snapshots, assessment tasks are generated idempotently and state machine execution is driven; during the execution of assessment tasks, the processing logic of assessment tasks is based solely on instance snapshots, and the impact of real-time organizational structure and configuration changes is isolated. Monitor personnel movement events that occur during the execution of assessment tasks, perform event-driven exception handling for the affected assessment tasks according to predefined strategies, and record the event content, handling actions, and strategies in the event action log. After the assessment task is completed, a verifiable audit playback function is provided based on the instance snapshot and its integrity verification value, change audit log and event action log.

[0010] In an optional implementation, maintaining the draft configuration in draft mode includes: Receive editing operations on the draft configuration; the editing operations are represented in the form of an operation list. Concurrency conflict detection is performed based on the current latest draft version number configured in the draft configuration and the target draft version number corresponding to the editing operation; If a conflict is detected, conflict information will be output for the user to handle. If no conflict is detected, the edit operations are automatically merged to generate a draft configuration with a new draft version number, and the change audit log is updated.

[0011] In an optional implementation, the integrity check value of the instance snapshot is calculated, including: Perform hash calculations on each component of the instance snapshot separately; The hash values ​​of each component are concatenated and hashed, and the resulting overall snapshot hash value is used as the integrity verification value. When the number of participants exceeds a preset threshold, the Merkle root is calculated using a Merkle tree structure for the participant snapshot portion of the instance snapshot, and the Merkle root is used to calculate the overall snapshot hash value.

[0012] In an optional implementation, event-driven exception handling includes a padding strategy, which at least includes: When an unavailable reviewer event is detected, the nearest valid supervisor is searched up the reporting chain as a replacement reviewer based on the frozen organizational relationships in the instance snapshot. If no suitable supervisor is found, a substitute reviewer will be assigned from a predefined pool of backup reviewers. When performing the fill-in, record the strategy version used, the changes in task status before and after processing, and the reasons in the event action log.

[0013] In optional implementations, the long-term performance appraisal consistency control method further includes: Receive change requests for snapshots of running instances and analyze the scope of impact of the change requests for user approval; After the change request is approved, a change compatibility assessment is performed based on the scope of the change request, and differential reconstruction or new instance creation is performed on the assessment instance based on the compatibility assessment results. Among them, differential reconstruction only applies changes to incomplete assessment tasks, while the new instance derivation operation will create a new instance snapshot and archive the original instance snapshot, while recording the complete change approval and execution chain.

[0014] In optional implementations, the long-term performance appraisal consistency control method further includes: By employing two-phase verification, instance snapshot freezing, and audit chain construction, the following objective function is implemented. The value is constrained to within a predetermined threshold: ; Among them, Drift( t (time) t The configuration drift risk metric is used to characterize the degree of deviation between the instance execution relationship chain and the real-time organizational relationship; To validate violation indication functions, used to characterize the draft version. v Draft configuration D (v) The number of items blocked during the audit; AuditGap( I ) is an audit gap indicator function used to characterize instance snapshots. I The situation regarding the lack of audit evidence; l 1. l 2. l 3 are all preset weighting coefficients.

[0015] In an optional implementation, after the first-stage verification and / or the second-stage verification are completed, the long-term performance evaluation consistency control method further includes generating a verification fingerprint in the following manner: The verification details in the verification results generated by the two-stage verification are subjected to deterministic serialization. Deterministic serialization includes at least sorting all keys, sorting the array, and normalizing null values. The serialized result is hashed to obtain a verification fingerprint. The verification fingerprint is used to compare the verification results within the initiating transaction and / or to verify the consistency of the verification basis during audit playback.

[0016] Secondly, this invention provides a long-cycle performance appraisal consistency control system, comprising: The configuration and maintenance module is used to respond to users' performance appraisal scheme configuration operations, create and maintain draft configurations in draft state, and record change audit logs; among them, draft configurations support versioned editing and concurrent change management; The two-stage verification module is used to perform two-stage verification during the initiation of an assessment transaction: the first stage verification includes pre-verification of the draft configuration before editing the draft configuration or initiating the assessment transaction; the second stage verification includes final verification of the draft configuration based on the bound external dependency consistency view after initiating the assessment transaction. The external dependency consistency view includes at least the organizational structure snapshot version, the assessment template version, and the policy version. The snapshot freeze module is used to freeze the draft configuration and its associated external dependency consistency view together to generate an instance snapshot in the instance state after the second phase of verification passes, and to calculate the integrity verification value of the instance snapshot; wherein, the instance snapshot includes an immutable copy of the cycle, participation scope, review relationship, process rules, scoring template and its dependent version identifier; The task execution module is used to generate assessment tasks idempotently based on instance snapshots and drive the state machine to execute. During the execution of the assessment task, the processing logic of the assessment task is based only on the instance snapshot and is isolated from the impact of real-time organizational structure and configuration changes. The exception handling module is used to monitor personnel movement events that occur during the execution of assessment tasks, perform event-driven exception handling on the affected assessment tasks according to predefined strategies, and record the event content, handling actions, and the strategies used to the event action log. The audit replay module is used to provide verifiable audit replay functionality based on instance snapshots and their integrity verification values, change audit logs, and event action logs after the assessment task is completed.

[0017] Thirdly, the present invention provides an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the long-cycle performance evaluation consistency control method of any of the foregoing embodiments.

[0018] Fourthly, the present invention provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, performs the long-cycle performance evaluation consistency control method of any of the foregoing embodiments.

[0019] The long-cycle performance appraisal consistency control method and system provided by this invention can respond to users' performance appraisal scheme configuration operations, create and maintain a draft configuration in a draft state, and record change audit logs. The draft configuration supports versioned editing and concurrent change management. During the initiation of an appraisal transaction, a two-stage verification is performed: the first stage verification includes pre-verification of the draft configuration before editing or initiating the appraisal transaction; the second stage verification includes final verification of the draft configuration based on the bound external dependency consistency view after initiating the appraisal transaction. The external dependency consistency view includes at least the organizational structure snapshot version, the appraisal template version, and the policy / strategy version. After the second stage verification passes, the draft configuration and its associated external dependency consistency view are frozen together to generate an instance. The system generates instance snapshots and calculates their integrity verification values. Each instance snapshot includes an immutable copy of the cycle, scope of participation, review relationships, process rules, and scoring template, along with their dependent version identifiers. Based on these instance snapshots, assessment tasks are generated idempotently, driving the state machine execution. During the execution of the assessment tasks, the processing logic relies solely on the instance snapshots, isolating the impact of real-time organizational structure and configuration changes. The system monitors personnel movement events occurring during the execution of assessment tasks, performs event-driven exception handling on affected assessment tasks according to predefined strategies, and records the event content, processing actions, and applicable strategies in the event action log. After the assessment tasks conclude, a verifiable audit replay function is provided based on the instance snapshots and their integrity verification values, change audit logs, and event action logs. This approach divides the performance appraisal scheme configuration into a dual-state model of draft and instance states. Through two-stage verification, the draft configuration is consistently bound to external dependencies. After the verification passes, an instance snapshot is generated. During the instance runtime, only the instance snapshot is used, and the impact of organizational changes is isolated. Event-driven exception handling ensures that the process is uninterrupted and that the entire chain is traceable. At the same time, a verifiable audit playback function is provided to support the provable playback of disputed scenarios, thereby significantly improving the stability, consistency, and auditability of long-term performance appraisals. 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 long-cycle performance appraisal consistency control method provided in an embodiment of the present invention; Figure 2A schematic diagram illustrating the process of converting from draft state to instance state and freezing a snapshot, provided in an embodiment of the present invention; Figure 3 A timing diagram for a two-stage verification provided in an embodiment of the present invention; Figure 4 A schematic diagram of an execution-time event-driven exception handling process provided in an embodiment of the present invention; Figure 5 A schematic diagram of a long-cycle performance appraisal consistency control system provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0022] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and 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] Current performance management systems suffer from the following core pain points: 1. Organizational changes pollute the assessment chain: After the initiation, the change of supervisor causes the "who evaluates whom" relationship to drift in real time, resulting in misassignment of tasks and disputes over results.

[0024] 2. Inconsistent configuration and execution, difficult to explain, and difficult to audit: Changes in configuration / template / rules during execution lead to inconsistencies in rules before and after the same instance, making it impossible to restore the basis for initiation during auditing.

[0025] 3. Concurrent editing leads to configuration drift and incidents: When multiple administrators concurrently edit the scope / process / weight, the final configuration at the moment of initiation may not be the version seen by anyone else.

[0026] 4. There is no unified mechanism for handling anomalies and they are not traceable: There is a lack of audit basis for interrupting tasks or filling in gaps caused by resignation, unavailable reviewers, job transfers, etc.

[0027] Based on this, this invention provides a consistency control solution for long-cycle performance appraisals based on a dual-state model and a verifiable audit chain: The appraisal configuration is divided into a draft (variable) and an instance (immutable) dual-state model. During transaction initiation, a two-stage verification gate ensures consistency binding between the draft version and external dependencies (organization / template / policy, etc.). After successful verification, an instance snapshot containing the cycle, participation scope parsing results, review relationship chain, process state machine, scoring rules, and dependency version identifiers is generated and frozen. During instance runtime, a "snapshot priority" approach is maintained to isolate organizational changes, and event-driven exception handling (filling in gaps / freezing / approval) ensures uninterrupted process flow and full-chain traceability. Simultaneously, deterministic serialization and hash notarization / Merkel root authentication are introduced to construct a verifiable audit chain, supporting provable replay of disputed scenarios, thereby significantly improving the stability, consistency, and auditability of long-cycle performance appraisals. Here, "long-cycle" can be a quarter, half a year, or a year or more.

[0028] This invention relates to the fields of enterprise-level workflow engines, configuration governance, and data consistency control technology, specifically involving: 1. Workflow instantiation control and long-term consistency assurance for performance appraisal configuration and execution; 2. Draft configuration management, versioned editing, concurrent collaboration, and change auditing; 3. Instance-level immutability and snapshot freezing isolate organizational changes; 4. Two-stage verification (Pre-Launch + In-Launch) achieves concurrent consistency, dependency version binding, and drift access control; 5. Audit and record-keeping of event-driven anomaly handling (resignation / job transfer / supervisor change) and replacement strategies during the execution period; 6. Optional controlled change and audit replay verification mechanisms.

[0029] To facilitate understanding of this embodiment, a detailed description of a long-cycle performance evaluation consistency control method disclosed in this embodiment of the invention will be provided first.

[0030] This invention provides a method for controlling consistency in long-term performance appraisals, which can be executed by an electronic device with data processing capabilities. See also... Figure 1 The diagram shows a flowchart of a long-term performance appraisal consistency control method, which mainly includes the following steps S110 to S160: Step S110: In response to the user's performance appraisal scheme configuration operation, create and maintain a draft configuration in draft state, and record change audit logs; wherein, the draft configuration supports versioned editing and concurrent change management.

[0031] In this embodiment of the invention, during the initial configuration phase of the performance appraisal process, an independent and variable "draft" configuration space is created and maintained, allowing users to edit the performance appraisal plan (including cycle, scope, process, template, rules, etc.) multiple times in a collaborative manner. Versioning management tracks every change to the draft configuration, and a change audit log records the operator, content, time, and reason for each modification. Simultaneously, the system incorporates concurrent change management capabilities. When multiple people are editing simultaneously, mechanisms such as path conflict detection and automatic merging coordinate concurrent modifications, preventing data overwriting and loss, thereby ensuring the consistency and traceability of the configuration during collaborative editing.

[0032] In some possible embodiments, maintaining the draft configuration in draft state may include: receiving editing operations on the draft configuration, the editing operations being represented in the form of an operation list; performing concurrent conflict detection based on the latest draft version number of the draft configuration and the target draft version number corresponding to the editing operation; if a conflict is detected, outputting conflict information for the user to handle; if no conflict is detected, automatically merging the editing operations to generate a draft configuration with a new draft version number, and updating the change audit log.

[0033] When handling concurrent editing of performance plan drafts, optimistic concurrency control is achieved through versioned operation lists and version comparisons. The specific process is as follows: User-submitted editing operations must include the target draft version number on which the editing is based. The system compares this target draft version number with the latest draft version number currently stored on the server. If the version numbers are inconsistent, it indicates that the draft has been modified by someone else during the user's editing period. In this case, the system does not directly reject the edit but instead proceeds to the "concurrency conflict detection" stage. This stage analyzes whether there are conflicts in the data path between the user's submitted operation list and other people's modifications during the same period. If a conflict exists (e.g., multiple people modifying the same field), explicit conflict information is output, requiring user intervention. If no conflict is detected, the system automatically merges the modifications from both parties, generating a new draft configuration containing all changes, and updating the draft version number accordingly. The editing intent, version changes, operation content, and processing results throughout the entire process are recorded in the change audit log, ensuring the traceability and consistency of all collaborative editing activities.

[0034] In one possible implementation, the aforementioned concurrent conflict detection may include path conflict determination, which, when two version numbers are different, determines whether two patch operations conflict using the following logic: When the field paths of the first patch operation and the second patch operation are the same, and both operations are write operations, it is considered a conflict. A conflict is identified when the field path of the first patch operation is a prefix of the field path of the second patch operation, and the modification type of either patch operation is a delete operation. When two patch operations modify the same index position of the same array, it is considered a conflict; If none of the above conflict conditions are met, it is determined that there is no conflict.

[0035] The system can determine whether two concurrent modifications will cause semantic conflicts—that is, whether they will overwrite each other or produce inconsistent results—based on the "field path" and "operation type" of the data structure affected by the patch operation. Specifically, this embodiment defines three typical conflict scenarios: when two operations modify the exact same field (write conflict); when one operation attempts to delete a parent path while another operation modifies its child path (structural destruction conflict); and when two operations simultaneously modify the same position in an array (array index conflict). Only when a pair of concurrent modifications does not meet any of the above conflict conditions will the system determine that they are non-conflicting operations, thus allowing for safe automatic merging. This achieves versioned collaborative editing, avoiding data loss and inconsistency.

[0036] Step S120: During the process of initiating an assessment transaction, a two-stage verification is performed: The first stage verification includes pre-verification of the draft configuration before editing the draft configuration or initiating the assessment transaction; the second stage verification includes final verification of the draft configuration based on the bound external dependency consistency view after initiating the assessment transaction. The external dependency consistency view includes at least the organizational structure snapshot version, the assessment template version, and the policy version.

[0037] In this embodiment of the invention, to ensure the consistency of the final result during the assessment transaction initiation stage, two security gates, namely a two-stage verification, are set up. The first-stage verification is a "pre-rehearsal" or "draft" verification performed in the draft state, helping administrators to promptly identify and correct logical, rule, or scope errors in the plan before the actual initiation. The second-stage verification, within the formal initiation transaction, is a final and most authoritative legality review of the draft configuration based on a set of external data (snapshots of organizational structure, assessment templates, and policy strategies) that is "locked" at the start of the transaction. This two-stage verification design separates the pre-inspection stage of "identifying problems and allowing corrections" from the final confirmation stage of "based on a consistent view and irreversible," thereby both mitigating risks in advance and completely eliminating the risk of inconsistencies between the verification basis and the final execution basis due to real-time changes in external data at the moment of initiation, thus ensuring the certainty and auditability of the assessment instance.

[0038] To ensure the authority and verifiability of the verification process, this embodiment of the invention introduces a "verification fingerprint" mechanism. After the first-stage verification and / or the second-stage verification are completed, the long-cycle performance evaluation consistency control method further includes generating a verification fingerprint in the following ways: performing deterministic serialization on the verification details in the verification results generated by the two-stage verification. Deterministic serialization includes at least sorting all keys, sorting the array, and normalizing null values; performing hash calculation on the serialized results to obtain the verification fingerprint. The verification fingerprint is used for comparing verification results within the initiating transaction and / or for verifying the consistency of the verification basis during audit playback.

[0039] Whether it's the first stage (pre-checking of drafts) or the second stage (final verification), the system will perform deterministic serialization on all verification entries (e.g., "weight and verification passed," "process closure check passed"). This processing generates an absolutely unique string representation using fixed rules (such as sorting keys and arrays, and standardizing null value formats). This string is then hashed to obtain a unique and irreversible verification fingerprint. This verification fingerprint has two key uses: first, within the initiating transaction, it allows for rapid comparison of verification results to prevent data tampering; second, in subsequent audits or dispute replays, it provides irrefutable mathematical evidence proving the basis for the verification at the time, thus ensuring the integrity and credibility of the entire verification chain.

[0040] Step S130: After the second-stage verification is passed, the draft configuration and its associated external dependency consistency view are frozen together to generate an instance snapshot in the instance state, and the integrity verification value of the instance snapshot is calculated; wherein, the instance snapshot includes an immutable copy of the cycle, participation scope, review relationship, process rules, scoring template and its dependent version identifier.

[0041] In this embodiment of the invention, after the second-stage verification ensures that all evidence is legal and consistent, the system performs an atomic operation to transform the currently "draft" variable configuration, along with the version-locked external data (such as organizational structure snapshots) relied upon during verification, into an independent, immutable instance snapshot. This instance snapshot fully encapsulates all key information at the time the assessment was initiated, including the assessment cycle definition, the specific list of participants, the established "who evaluates whom" relationship chain, fixed process steps, the scoring calculation template, and the version numbers of the external data relied upon. The system then calculates a unique integrity check value (such as a hash value) for this complete snapshot data package. From then on, this instance snapshot and its integrity check value constitute the unique, authoritative, and tamper-proof original evidence of the entire long-cycle assessment process. All subsequent task generation, status progression, and exception handling are strictly based on this instance snapshot, thus completely isolating it from subsequent organizational changes and configuration modifications, ensuring the determinism of execution and the auditability of results.

[0042] In some possible embodiments, the above-mentioned calculation of the integrity verification value of the instance snapshot may include: performing hash calculation on each component of the instance snapshot separately; concatenating and hashing the hash values ​​of each component, and using the resulting overall snapshot hash value as the integrity verification value; wherein, when the number of participants exceeds a preset threshold, the Merkle root is calculated using a Merkle tree structure for the participant snapshot portion of the instance snapshot, and the Merkle root is used to calculate the overall snapshot hash value.

[0043] To ensure the immutability and efficient verifiability of instance snapshots, this embodiment employs a combination of hierarchical hashing and structural optimization. First, each core component of the snapshot (i.e., its constituent parts, such as period, range, and relationship chains) is hashed independently. Then, these component hash values ​​are concatenated in a fixed order, and the concatenated result is recalculated to obtain the final total hash value, i.e., the overall snapshot hash value, which serves as the integrity verification value for the entire instance snapshot. This design ensures that any minor change to a component will result in a significant change in the final integrity verification value. Simultaneously, for components like "participant snapshots," which can potentially have a massive data volume, performance optimizations have been implemented to avoid processing huge amounts of data for each calculation and verification. When the number of participants exceeds a preset threshold, a Merkle tree is constructed for this portion of data, and the "root" of this tree (the Merkle root) is used as its hash representative in the final calculation. This ensures both data integrity and verifiability while maintaining system efficiency when handling large-scale participant scenarios through data structure optimization. The preset threshold can be set according to actual needs and is not limited here.

[0044] Step S140: Based on the instance snapshot, generate the assessment task idempotently and drive the state machine to execute; wherein, during the execution of the assessment task, the processing logic of the assessment task is based only on the instance snapshot and the impact of real-time organizational structure and configuration changes is isolated.

[0045] In this embodiment of the invention, when generating assessment tasks, a uniquely identified task is generated for each pair of "assessed person-reviewer" at each process node based on the "review relationship snapshot" and "process snapshot" in the frozen instance snapshot. This generation process is "idempotent," meaning that even if triggered multiple times due to retries or other reasons, no duplicate tasks will be generated, ensuring the stability of the system. Furthermore, throughout the entire long execution period, the status progression, permission judgment, and notification logic of all assessment tasks are strictly and uniquely based on the instance snapshot frozen at the time of initiation, and are not subject to any changes in the company's organizational structure, job information, or backend configuration during execution. This fundamentally isolates the ongoing assessment process from contamination, drift, and logical chaos caused by the dynamic adjustment of "people, positions, and departments" in reality, thereby ensuring the consistency and predictability of the entire long-cycle process.

[0046] Step S150: Monitor personnel movement events that occur during the execution of the assessment task, perform event-driven exception handling on the affected assessment task according to the predefined strategy, and record the event content, handling actions, and the strategy to the event action log.

[0047] In long-term performance evaluations, to address dynamic organizational changes, continuous monitoring of personnel changes related to evaluation participants (such as resignations, job transfers, and supervisor changes) is possible. Once such an event is detected, the system will not be interrupted or disrupted; instead, it will immediately trigger an "event-driven exception handling" process. Based on predefined, versioned policies associated with the instance snapshot, the system automatically performs actions such as filling gaps or freezing the affected specific evaluation tasks, and can grant reasonable deadline grace periods to ensure the process can continue uninterrupted. Furthermore, the entire process—from the received event itself, the policy version upon which the system bases its decision, the final actions executed, to the state snapshots before and after processing—is completely and structurally recorded in the event action log. This constructs a complete and auditable chain of evidence, allowing any subsequent disputes regarding "why this person evaluated me" or "why the task was adjusted" to be clearly and credibly explained by replaying this log.

[0048] In some possible embodiments, the event-driven exception handling described above may include a padding strategy, which at least includes: When an unavailable reviewer event is detected, the nearest valid supervisor is searched up the reporting chain as a replacement reviewer based on the frozen organizational relationships in the instance snapshot. If no suitable supervisor is found, a substitute reviewer will be assigned from a predefined pool of backup reviewers. When performing the fill-in, record the strategy version used, the changes in task status before and after processing, and the reasons in the event action log.

[0049] This invention addresses situations where reviewers are unavailable during performance evaluations due to resignation, job transfer, or other reasons. It employs an automated, tiered replacement mechanism: when the system receives a "reviewer unavailable" event, it doesn't simply interrupt the process or rely on manual intervention. Instead, it first searches upwards along the employee's reporting line using the frozen organizational chart (i.e., instance snapshot) to find the first currently employed and active manager (e.g., the next-level supervisor) as the first-priority replacement. This maximizes the rationality and authority of the review process. If tracing up the reporting chain fails (e.g., the entire management chain fails), the system uses a pre-defined, more general "backup reviewer pool" (e.g., HR or a specific committee) to assign tasks, ensuring uninterrupted workflow. The entire process is fully automated. Simultaneously, the system records the event, the applicable strategy version, the task status change before and after replacement (e.g., from "to be done" to "assigned to new reviewer S"), and the reason in the event action log. This automatically resolves the issue while simultaneously building a clear and verifiable chain of audit evidence.

[0050] Step S160: After the assessment task is completed, a verifiable audit playback function is provided based on the instance snapshot and its integrity verification value, change audit log and event action log.

[0051] After the long-term assessment process concludes, a verifiable audit replay function is provided to resolve potential disputes and provide final credible evidence. Specifically, when archiving the assessment, the system systematically archives all definitive evidence and operation records throughout the entire lifecycle—including instance snapshots and their hash values, all modification traces during the drafting period (change audit logs), and the complete trajectory of handling all abnormal events during the execution period (event action logs). When appeals regarding the results or compliance reviews are required, the audit replay function can start from the frozen instance snapshot and, strictly in chronological order, replay each key action and decision from initiation to completion based on immutable hash values ​​and detailed logs. This not only clearly demonstrates the basis and results of each step at the time, but more importantly, by verifying the integrity check value, it can mathematically prove that the "original evidence" upon which the entire replay process relies has not been tampered with from the moment it was initiated. This transforms dispute resolution into a technical verification process based on an objective and verifiable chain of evidence, greatly enhancing the transparency and credibility of the entire assessment system.

[0052] The long-term performance appraisal consistency control method provided in this invention divides the performance appraisal scheme configuration into a dual-state model of draft and instance states. Through two-stage verification, the draft configuration and external dependencies are bound to consistency. After the verification is passed, an instance snapshot is generated. During the instance runtime, only the instance snapshot is used and the impact of organizational changes is isolated. Event-driven exception handling ensures that the process is not interrupted and that the entire chain is traceable. At the same time, a verifiable audit playback function is provided to support the provable playback of disputed scenarios, thereby significantly improving the stability, consistency and auditability of long-term performance appraisal.

[0053] Furthermore, to address potential significant rule adjustments during long-term performance evaluations, this embodiment of the invention proposes a controlled change mechanism. Based on this, the aforementioned long-term performance evaluation consistency control method may further include: receiving change requests for snapshots of running instances and analyzing the scope of impact of the change requests for user approval; after the change request is approved, performing a change compatibility judgment based on the scope of impact of the change request, and performing differential reconstruction or new instance creation operations on the evaluation instance based on the compatibility judgment results; wherein, differential reconstruction applies changes only to incomplete evaluation tasks, and the new instance creation operation creates a new instance snapshot and archives the original instance snapshot, while simultaneously recording the complete change approval and execution chain.

[0054] Specifically, when the assessment is already in effect but the rules need to be adjusted, the system provides a strict and auditable change path: users can submit a change request, and the system first analyzes its scope of impact (who will be affected and which incomplete tasks will be affected), and uses this analysis report for approval decisions. After approval, the system makes a key judgment based on the "compatibility" of the change: if the change is "compatible" (e.g., only adjusting non-core parameters), then the affected, incomplete tasks are updated using a "differential rebuild" approach; if the change is "incompatible" (e.g., modifying core scoring rules or process structure), then a more thorough "derive new instance" strategy is adopted, that is, a new instance applying the new rules is created based on the original instance data, and the original instance is completely archived. Regardless of the strategy used, the entire chain from request, approval, analysis, judgment to execution is recorded, thus allowing necessary flexibility while strictly ensuring the controllability, explainability, and full auditability of the change process.

[0055] Furthermore, the aforementioned methods for controlling consistency in long-term performance appraisals may also include: By employing two-phase verification, instance snapshot freezing, and audit chain construction, the following objective function is implemented. The value is constrained to within a predetermined threshold: ; Among them, Drift( t (time) tThe configuration drift risk metric is used to characterize the degree of deviation between the instance execution relationship chain and the real-time organizational relationship; To validate violation indication functions, used to characterize the draft version. v Draft configuration D (v) The number of items blocked during the audit; AuditGap( I ) is an audit gap indicator function used to characterize instance snapshots. I The situation regarding the lack of audit evidence; l 1. l 2. l 3 are all preset weighting coefficients.

[0056] l 1. Configure the drift item (Drift) t The weighting coefficient of ) ranges from 0.20 to 0.50, with a default value of 0.30; l 2 is for verifying violations. The weighting coefficient ranges from 0.30 to 0.60, with a default value of 0.45. l 3 is the Audit Gap item. I The weighting coefficient of ) ranges from 0.15 to 0.40, with a default value of 0.25.

[0057] Optionally, the dynamic adjustment rules for the above three weighting coefficients can be: (1) Classified by life cycle: Initiation phase: Focuses on the rigor of configuration verification. l 2. Increased to 0.50–0.60; Implementation phase: Focus on isolating the drift risk caused by organizational changes. l 1. Increased to 0.40–0.50; Archiving and playback phase: Focuses on the completeness of audit evidence. l 3 was increased to 0.40.

[0058] The longer the assessment period, l The higher 1 is, l The upper limit for 1 is 0.50.

[0059] (2) Exponential smoothing based on the proportion of disputed attributions: Based on the actual attribution ratio of historical disputes (such as the proportion of disputes caused by drift, verification omissions, and audit deficiencies), the corresponding weight coefficients are exponentially smoothed.

[0060] Smoothing coefficient β The value ranges from 0.1 to 0.3. The smaller the value, the more gradual the smoothing effect of historical data on the current weight.

[0061] (3) Set a lower limit based on the evidence requirements of the jurisdiction: For regions or business units with strict evidentiary requirements l 3. A mandatory lower limit of 0.30 is set to ensure the completeness of the audit evidence chain.

[0062] Blocking rule: When If the value is >0, then if there is a verification item that is determined to be in a blocked state, the initiation of the assessment instance will be blocked and the execution phase will not be allowed.

[0063] The aforementioned predetermined thresholds can be set according to actual needs and are not limited here. In this embodiment, a measurable and unified consistency control objective can be achieved through a technical solution. Specifically, multiple risks that the entire system needs to guard against (execution-time relationship chain drift, non-compliant configuration verification, and lack of audit evidence) are integrated into a quantitative comprehensive objective function. This objective function is a weighted sum of three risk indicators, where the weight coefficients of each indicator can be preset according to business importance. Each weight coefficient and predetermined threshold are versioned and written into the instance snapshot and audit chain. The dual-stage verification mechanism (reducing verification violations), instance snapshot freezing mechanism (isolating real-time changes to reduce drift), and audit chain construction mechanism (ensuring complete evidence) proposed in this embodiment of the invention share a common design and engineering goal: to ensure that the value of this objective function is controlled within a predetermined threshold close to zero at the critical nodes of assessment initiation and execution. This provides a clear and assessable mathematical basis for the effectiveness of the entire technical solution, elevating it from a qualitative goal of ensuring consistency to a precise control level that quantifies and constrains consistency risks.

[0064] For ease of understanding, please refer to the following: Figure 2 to Figure 4 This paper provides a detailed introduction to some of the processes involved in the above-mentioned long-term performance appraisal consistency control method.

[0065] See Figure 2The diagram illustrates a process for transitioning from draft state to instance state and freezing a snapshot. The process begins with creating or editing a draft; then, version control is implemented for modifications to the draft configuration, including versioning using Patch(ops[]) and change log (i.e., change audit log); followed by the first stage of validation, Pre-LaunchValidation, which outputs pass / warn / blocked, as well as validation_items and fp_val ("validation failure point"); it determines whether the first stage validation passes; if the validation result is blocked, the blocking is initiated and a repair suggestion is returned; if the validation result is pass / warn, the Launch Transaction Begin is initiated and an idempotency key idempotency_key is generated, followed by the second stage of validation, In-Launch Final. Validation includes checking the draft_version (i.e., consistency of the draft version) and the dependency consistency view (org / template / policy); then determining whether the final validation (i.e., the second-stage validation) passes; if not, a transaction rollback is performed, indicating version drift / dependency change; if yes, an instance + frozen snapshot is generated, the snapshot includes cycle, participants, relations, process, template, and dependency_versions; then, a snapshot_hash is calculated on the generated instance snapshot, optionally generating a MerkleRoot; then, an idempotent task + state machine is generated, the task ID is generated using hashing, i.e., task_id = H(instance_id + step + employee + rater); finally, the execution phase begins, and the instance runs only depending on the snapshot.

[0066] See Figure 3 The sequence diagram shown is a two-stage verification process involving "User / HR", "Draft Service", "Verification Service", "Organizational Snapshot Library (Org)", "Template Library (Template)", "Policy Library (Policy)", and "Instance Service". The complete process of a user initiating an assessment instance through the Draft Service is as follows: The "User / HR" sends the following operation to the "Draft Service": Edit Draft(ops[], reason); The Draft service returns a version number: draft_version=v; The "User / HR" initiates a pre-validation request to the "Validation Service": S2 pre-validate(draft_id, v); The "Verification Service" requests the "Draft Service" to read the draft: Read Draft(v); The "Draft service" returns the pre-validation result to the "user / HR": pre-validation result (pass / warn / blocked) + fp_val; The "User / HR" initiates a transaction to the "Instance Service": S3 initiates launch(draft_id, expected_v); The "Instance service" requests the "Draft service" to read the current draft version: read Draft (current version); Perform version matching verification; If the versions are inconsistent, the "Instance Service" returns a rejection message to the "User / HR": Rejection of initiation (DRAFT_VERSION_MISMATCH); the process then terminates. If the versions are consistent, the "Instance Service" obtains the organization snapshot version from the "Organization Snapshot Library (Org)": obtains org_snapshot_version (organization snapshot version) and read_at_version (i.e., reads data by version number); obtains the template version from the "Template Library (Template)": obtains template_version (template version) and read_at_version; obtains the policy version from the "Policy / Policy Library (Policy)": obtains policy_version (policy version) and read_at_version; The "Instance service" requests the "Validation service" to perform final validation: S4 in-transaction final validation validate(draft, org_view, tpl_view, policy_view); If the final verification is blocked (i.e., the final verification is blocked), the "Instance service" returns a rollback prompt to the "user / HR": rollback with prompt (FINAL_VALIDATION_BLOCKED); then the process terminates; If the final verification passes, the "Instance Service" executes: S5 Freeze the instance snapshot + calculate the snapshot_hash; the "Instance Service" continues to execute: S6 Idempotent generation task and state machine; The "Instance service" returns a success response to "User / HR": Successful initiation (instance_id).

[0067] See Figure 4 The diagram illustrates a process for runtime event-driven exception handling. The runtime event-driven exception handling process includes: 1. Execution phase startup: Receive event.

[0068] 2. Event deduplication: Calculate the deduplication key of the event, i.e., deduplication_key = H(event_id + instance_id).

[0069] 3. Determine if the event is a duplicate: Determine if the event is a duplicate event based on the dededupe_key; If it is a (repeating event): ignore the event or return an idempotent response; the process terminates. If no (new event): Proceed to the next step.

[0070] 4. Read the instance snapshot, which includes policy_version and snapshot_hash (optional verification used to verify snapshot integrity).

[0071] 5. Policy decision: The decide_action(policy, instance, event) method is called based on the policy, instance, and event to decide the action to be taken for the event.

[0072] 6. Determine the event type and proceed to different branches based on the event type: Branch 1 - Reviewer has left / is unavailable: a. Replacement strategy: Select the nearest_active_manager / agent pool as the replacement person; b. (Optional) SLA (Service Level Agreement, referring to predefined service level objectives or grace rules for handling exceptional events) Grace period: Calculate the new deadline. new due_at = min( old due_at +Δ grace , final deadline ), where Δ grace To allow for grace period, final deadline This is the final deadline; Grace period Δ grace Retrieve from the SLA parameters of the frozen snapshot C: Read C.sla.grace_by_event_type[event_type] (a dictionary of grace times configured for each event type); if the event type is not configured separately, use the default grace time C.sla.default_grace; if configured as a percentage, the calculation formula is Δ. grace =C.sla.grace_ratio × C.sla.duration(step_key), where C.sla.grace_ratio represents the grace ratio coefficient, and C.sla.duration(step_key) represents the standard duration of the corresponding step; and the upper limit constraint is accumulated, i.e., Δ grace = min(read value, C.sla.max_total_grace - accumulated grace time), ensuring that the grace time will not accumulate indefinitely under multiple abnormal events, and that the total grace time does not exceed the maximum limit C.sla.max_total_grace set in the snapshot; Final deadline final deadline Obtain the due point parameter from the frozen snapshot C: prioritize C.due_points[step_key], which is the exclusive due point of the current step; if not configured separately, fall back to the due point of the stage to which this step belongs; if still not configured, take the final due time C.end of the assessment period as the final due date. Original deadline old due_at Similarly, it is derived from the frozen snapshot C, taking C.due_points[step_key], or calculated according to the formula C.start + C.sla.duration(step_key), where C.start is the start time of the assessment period; Results: Since all parameters are taken from the frozen snapshot C, even if the configuration is modified in the background during execution, it will not affect the grace period calculation results, ensuring that the results are deterministic and replayable; through the min(·) constraint, it is guaranteed that the final deadline recorded in the snapshot will not be exceeded after each grace period. final deadline Each grace period operation is recorded in the event action log with fields such as before / after (the deadline before or after the grace period), reason (the reason), policy_version (the policy version), and ts (timestamp) for easy traceability and auditing. c. Update task assignment / notification: Reassign the task to the replacement person and send a notification.

[0073] Branch 2 - The person being reviewed leaves the company: a. Freeze their tasks / file or remove them according to policy: Suspend or process the reviewer's related tasks (e.g., freeze tasks, file or delete them); b. Update State Machine and Notifications: Update the instance's state machine and send departure-related notifications.

[0074] Branch 3 - Job Transfer / Supervisor Change: a. Default no recalculation (snapshot priority): Prefers existing snapshot data and does not recalculate the instance; b. Determine if "the strategy requires recalculation?": If not, leave it unchanged and record the event; the process continues. If so, proceed to the controlled change process (S8), which involves initiating a change request, approval, delta rebuild, or derive v2.

[0075] 7. Record event action log: Write the event action log (event_action_log), and record the following content: before / after (state before and after the operation), reason (reason), approver? (approver, optional), policy_version (policy version), and ts (time stamp).

[0076] 8. Continue to advance the execution phase process: After completing the handling of the current event, continue to advance the subsequent processes of the execution phase (such as waiting for the next event, executing periodic tasks, etc.).

[0077] Corresponding to the above-described long-term performance appraisal consistency control method, this invention also provides a long-term performance appraisal consistency control system. See [link to related document]. Figure 5 The diagram shows a structural schematic of a long-cycle performance appraisal consistency control system. The system includes: The configuration maintenance module 501 is used to respond to users' performance appraisal scheme configuration operations, create and maintain draft configurations in draft state, and record change audit logs; among them, draft configurations support versioned editing and concurrent change management; The two-stage verification module 502 is used to perform two-stage verification during the initiation of an assessment transaction: the first stage verification includes pre-verification of the draft configuration before editing the draft configuration or initiating the assessment transaction; the second stage verification includes final verification of the draft configuration based on the bound external dependency consistency view after initiating the assessment transaction. The external dependency consistency view includes at least the organizational structure snapshot version, the assessment template version, and the policy version. The snapshot freeze module 503 is used to freeze the draft configuration and its associated external dependency consistency view together to generate an instance snapshot in the instance state after the second phase verification is passed, and to calculate the integrity verification value of the instance snapshot; wherein, the instance snapshot includes an immutable copy of the cycle, participation scope, review relationship, process rules, scoring template and its dependent version identifier. The task execution module 504 is used to generate assessment tasks idempotently based on instance snapshots and drive the state machine to execute; during the execution of the assessment task, the processing logic of the assessment task is based only on the instance snapshot and is isolated from the impact of real-time organizational structure and configuration changes. The exception handling module 505 is used to monitor personnel movement events that occur during the execution of assessment tasks, perform event-driven exception handling on the affected assessment tasks according to predefined strategies, and record the event content, handling actions, and the strategies used to the event action log. The audit replay module 506 is used to provide verifiable audit replay functionality based on instance snapshots and their integrity verification values, change audit logs, and event action logs after the assessment task is completed.

[0078] The long-cycle performance appraisal consistency control system provided in this invention divides the performance appraisal scheme configuration into a dual-state model of draft and instance states. Through two-stage verification, the draft configuration and external dependencies are consistently bound. After the verification is passed, an instance snapshot is generated. During the instance runtime, only the instance snapshot is used and the impact of organizational changes is isolated. Event-driven exception handling ensures that the process is not interrupted and that the entire chain is traceable. At the same time, a verifiable audit playback function is provided to support the provable playback of disputed scenarios, thereby significantly improving the stability, consistency and auditability of long-cycle performance appraisal.

[0079] Furthermore, the configuration maintenance module 501 is specifically used for: receiving editing operations on the draft configuration, the editing operations being represented in the form of an operation list; performing concurrent conflict detection based on the latest draft version number of the current draft configuration and the target draft version number corresponding to the editing operation; if a conflict is detected, outputting conflict information for the user to handle; if no conflict is detected, automatically merging the editing operations to generate a draft configuration with a new draft version number, and updating the change audit log.

[0080] Furthermore, the aforementioned snapshot freezing module 503 is specifically used for: performing hash calculations on each component of the instance snapshot; concatenating and hashing the hash values ​​of each component, and using the resulting overall snapshot hash value as an integrity verification value; wherein, when the number of participants exceeds a preset threshold, the Merkle root is calculated using a Merkle tree structure for the participant snapshot portion of the instance snapshot, and the Merkle root is used to calculate the overall snapshot hash value.

[0081] Furthermore, the aforementioned event-driven exception handling includes a fill-in strategy, which at least includes: When an unavailable reviewer event is detected, the nearest valid supervisor is searched up the reporting chain as a replacement reviewer based on the frozen organizational relationships in the instance snapshot. If no suitable supervisor is found, a substitute reviewer will be assigned from a predefined pool of backup reviewers. When performing the fill-in, record the strategy version used, the changes in task status before and after processing, and the reasons in the event action log.

[0082] Furthermore, the aforementioned long-cycle performance appraisal consistency control system also includes a controlled change module. The controlled change module is used to: receive change requests for snapshots of running instances and analyze the scope of impact of the change requests for user approval; after the change request is approved, perform a change compatibility judgment based on the scope of impact of the change request, and perform differential reconstruction or new instance creation operations on the assessment instances based on the compatibility judgment results; wherein, differential reconstruction only applies changes to incomplete assessment tasks, and the new instance creation operation will create a new instance snapshot and archive the original instance snapshot, while recording the complete change approval and execution chain.

[0083] Furthermore, the aforementioned long-cycle performance evaluation consistency control system is also used to: through two-stage verification, instance snapshot freezing, and audit chain construction, to achieve the following objective function The value is constrained to within a predetermined threshold: ; Among them, Drift( t (time) t The configuration drift risk metric is used to characterize the degree of deviation between the instance execution relationship chain and the real-time organizational relationship; To validate violation indication functions, used to characterize the draft version. v Draft configuration D (v) The number of items blocked during the audit; AuditGap( I ) is an audit gap indicator function used to characterize instance snapshots. I The situation regarding the lack of audit evidence; l 1. l 2. l 3 are all preset weighting coefficients.

[0084] Furthermore, the aforementioned two-stage verification module 502 is also used to generate a verification fingerprint after the first-stage verification and / or the second-stage verification is completed, in the following manner: performing deterministic serialization processing on the verification details in the verification result generated by the two-stage verification, wherein the deterministic serialization includes at least sorting all keys, sorting the array, and normalizing null values; performing hash calculation on the serialized result to obtain the verification fingerprint, which is used to compare the verification results within the initiating transaction and / or to verify the consistency of the verification basis during audit playback.

[0085] The long-cycle performance appraisal consistency control system provided in this embodiment has the same implementation principle and technical effects as the aforementioned long-cycle performance appraisal consistency control method embodiment. For the sake of brevity, any parts not mentioned in the long-cycle performance appraisal consistency control system embodiment can be referred to the corresponding content in the aforementioned long-cycle performance appraisal consistency control method embodiment.

[0086] For ease of understanding, the long-term performance evaluation consistency control method and system provided in the embodiments of the present invention will be described in detail below.

[0087] I. Model Architecture Design.

[0088] 1. Overall architecture.

[0089] The system provided in this embodiment of the invention can be composed of the following core sub-modules: • Draft Management and Concurrent Collaboration Module: Used for versioned patching, conflict detection and automatic merging, and change auditing; • Dual-stage verification module: used for Pre-Launch verification and In-Launch final access control; • Initiate transaction and dependency consistency view module: used for in-transaction binding, including org_snapshot_version / template_version / policy_version; • Instance snapshot freeze module: used to freeze period / range / relationship / process / template / dependency version and generate snapshot_hash; •Task generation and state machine module: used for constructing idempotent tasks and freezing state transition rules; • Event-driven exception handling module: used for idempotent event deduplication, strategy decision-making, fill / freeze / approval, and record keeping; • Controlled Changes Module (Optional): Used for impact surface analysis, differential reconstruction, and deriving new instances; • Audit playback and verifiable module: Used for hash verification and action chain replay during playback.

[0090] 2. Mathematical modeling of data and objects involved in the embodiments of the present invention.

[0091] 1) Organizational structure diagram: Abstracting organizational / reporting relationships into a directed graph.

[0092] •Employee group V Report side gathering E The organizational chart is as follows G =( V , E ).

[0093] •( u , v )∈ E express u The direct supervisor is v .

[0094] • Versions of the organizational chart exist: G (k) Indicates the first k Each organization's snapshot version (corresponding to org_snapshot_version= k ).

[0095] 2) Draft objects and instance objects.

[0096] •draft: D (v) Indicates draft version v Configuration (cycle / scope / process / template / rules, etc.).

[0097] •Example: I From draft D (v) Snapshots of multiple components were captured at the time of initiation. ; in, C This is a periodic snapshot (cycle_snapshot). P This is a snapshot of participants (participants_snapshot of participants + groups_snapshot of participants' groups). R This is a snapshot of the review relationships (relations_snapshot). F This is a process / state machine snapshot (process_snapshot). T This is a snapshot of the template and scoring rules (template_snapshot / model_rules_snapshot). This is a set of dependency version identifiers (org / template / policy, etc.).

[0098] 3) Consistent goals (deterministic execution).

[0099] Define the execution function Φ: Generate task and state progression results based on the instance snapshot. ; in, E 1:t Indicates the time from initiation to the moment t The event sequence. This invention requires that, for the same instance... I With the same event sequence E 1:t Output Certainty means that it is not directly affected by real-time organizational changes.

[0100] II. Core Algorithm Formulas and Derivation.

[0101] Performance consistency control is not traditional supervised learning, but the system's access control and policy selection can be expressed in the form of an "optimization objective / cost function".

[0102] 1. Configure drift risk measurement and access control objective (Consistency Objective).

[0103] Define a drift metric (e.g., relationship chain drift): •Review relationships generated in real-time organizational relationships are (If real-time organization calculation is used); • The organizational relationships frozen in the instance snapshot are R .

[0104] The drift distance can be defined as the symmetry difference: ; in, The first preset value, >0 is used to prevent division by zero (i.e., to prevent the denominator from being 0); △ is the symmetric difference operator for sets, such as A△B=(A∪B)-(A∩B), which represents the set of elements that belong only to A or only to B (not both at the same time). The larger the drift distance, the greater the deviation between the real-time organizational relationship and the frozen instance snapshot.

[0105] Define a consistency violation indicator function (from the validation item): ; Viol(D (v) In ), D (v)This is the configuration for draft version v; Viol(·) indicates the number of verification items judged as blocked; Viol=0 indicates that all verifications passed and there were no blocked items. In this embodiment of the invention, this value is constrained to 0 at the initiating node through two-stage verification. The formula aims to incorporate the number of blocked items into the comprehensive optimization objective, driving the system to eliminate all verification violations before initiation.

[0106] And define the audit gap: ; This is an indicator function; if the condition within the parentheses is true, the value of this symbol is 1. In this embodiment... This is used for counting; each missing item is incremented by 1. `snapshot_hash missing` indicates a missing instance snapshot hash value, and `event_action_log missing` indicates a missing event action log. An AuditGap value of 0 indicates no audit gaps; a larger value indicates more incomplete audit records.

[0107] Overall goal (expected value approaching 0): ; This invention's embodiments employ a two-stage verification process, snapshot freezing, and an audit chain to ensure engineering compliance. The critical nodes of initiation and execution are constrained to 0 or a controllable range.

[0108] 2. Concurrent Patch Conflict Detection Function.

[0109] Abstract each patch operation as op =( type , path , value Define path prefix relationships. :like path a yes path b The prefix, then .

[0110] Conflict indication function: ; Among them, Conf( op a , op b ) is used to indicate operations op a and op b Is there a conflict? path a For operation op a field path, type a For operation op a Operation type; path b For operation op b field path, type b For operation op b Operation type; W For a set of operation types, W ={add (add), remove (remove), replace (replace)}; ∧ is logical AND, ∨ is logical OR; array-index conflict on same index is a specific conflict determination condition, which means that when two or more concurrently submitted edit operations (ops[]) attempt to modify the same index position of the same array, the system will determine that there is an array index conflict between these operations.

[0111] 3. Deterministic Validation Fingerprint.

[0112] Verification details items [] Perform deterministic serialization using canon( (Key sorting, array sorting, null value specification): ; Used for: proving "what the verification result was at the time"; intra-transaction verification and comparison; and verifying consistency during audit playback.

[0113] 4. Instance snapshot verifiable hash (Snapshot Hash / Merkle Root).

[0114] Calculate the hash of each snapshot component: , , , , , .

[0115] The total snapshot hash is: ; Here, || is the byte sequence concatenation operator, which concatenates the hash values ​​of each component end to end into a byte sequence, and then performs a hash calculation on the whole to generate the total snapshot_hash.

[0116] when P When the number of participants is large, introduce the Merkle root (optional implementation): •The leaves are: ; • Merkelgen is: ; The total snapshot hash is then: .

[0117] 5. Confidence-Weighted Compensation for Absence / Resignation.

[0118] In this embodiment of the invention, in event-driven exception handling, when a reviewer is absent from the review process, a confidence-weighted compensation mechanism is used to calculate the score of the person being evaluated. This includes: calculating the average score for that dimension as a compensation score based on the scores of available reviewers in the review group to which the absent reviewer belongs; when calculating the final score for each dimension of the person being evaluated, the compensation score and the normal score are weighted together for average calculation, wherein the compensation score is assigned a confidence weight lower than the normal score; and clearly marking this score as a compensation score in the audit record, and recording the compensation method, confidence weight, and calculation basis used. Specific details are as follows: staff e In dimensions d The score is: ; Total score: ; in, As reviewer r For employees e In dimensions d The rating; For example e In dimensions d The collection of all relevant raters; α r The source confidence level (e.g., direct supervisor can be set to 1.0, collaboration to 0.7, compensation to 0.4, etc.). The second preset value, >0 is used to prevent division by zero (i.e., to prevent the denominator from being 0). W d For dimension weights, satisfying .

[0119] Example of compensated scoring (group mean method): ; in, For example e In dimensionsd Above, by the raters r The adjusted score is given; mean({…}) is the mean function, which calculates the arithmetic mean of all elements in the set within the curly braces; A set of ratings containing all available ratings. r 'For example e In dimensions d Original ratings ; α comp For predefined component weights.

[0120] And record the audit fields: is_compensated (whether the score is compensated), compensation_method (compensation method), alpha_used (weight used), and evidence_ref (evidence reference).

[0121] 6. Weight Renormalization when nodes are missing.

[0122] In this embodiment of the invention, in event-driven exception handling, when certain steps in the process cannot be performed due to rule non-compliance or participant unavailability, the weights of subsequent executable steps can be re-normalized. This includes: removing the weights of all unusable steps from a preset set of original step weights; redistributing the weights of the remaining usable steps according to their proportion in the total remaining weights to obtain the actual effective weights; and simultaneously saving the original weights and the actual effective weights in the audit log. The specific formula is as follows: If some steps are unavailable (set) The available steps are as follows: A The weight of the original step is { w i}, then the actual effective weight is: ; in, The third preset value, >0 is used to prevent division by zero (i.e., to prevent the denominator from being 0). It should be noted that... , , The values ​​can be set according to actual needs. The three can be the same, not exactly the same, or different from each other.

[0123] It also records original_weights and effective_weights to support replay interpretation.

[0124] III. Related Algorithm Pseudocode / Processing Flow (Coverage) Figure 2 (S1–S9 in the text).

[0125] 1. S1: Draft creation and versioning patch.

[0126] The data structure is as follows: •draft={draft_id (unique identifier for draft), version (version number), cycle (assessment cycle configuration), scope_config (assessment scope configuration), process_config (process configuration), template_config (template configuration), model_rules (scoring rules), evidence_map (evidence mapping, optional), validation_status (validation status), created_by (creator), updated_at (last update time)}; •change_log={draft_id,from_version,to_version,ops[] (operation list),reason (reason for change),operator (operator),timestamp,pre_hash (pre-change hash, optional),post_hash (post-change hash, optional)}.

[0127] One possible pseudocode is as follows: .

[0128] 2. S2: First-stage validation Pre-Launch Validation.

[0129] One possible pseudocode is as follows: .

[0130] 3. S3: Launch Transaction Begin.

[0131] An idempotent key can be: ; Here, idempo is the idempotency key that initiates the transaction. H (·) represents a hash function (such as SHA-256); || represents a byte sequence concatenation operator; draft_id This serves as a unique identifier for the draft. launcher_id Used as a unique identifier for the initiator; draft _ version Draft version number confirmed by the initiator expected_version ; cycle This is for the assessment period. This information is concatenated and hashed to generate a unique idempotent key, preventing duplicate instance creation in scenarios such as network retries.

[0132] One possible pseudocode is as follows: .

[0133] 4. S4: Second-stage In-Launch Final Validation.

[0134] One possible pseudocode is as follows: .

[0135] 5. S5: Instance Snapshot Freezing (including snapshot_hash).

[0136] The frozen content may include: • Periodic snapshot C (start / end, cutoff point, SLA); • Participation Scope Resolution Snapshot P (participants + groups); • Review Relationship Snapshot R (relations + rule_version); • Process Snapshot F (steps / transitions / permissions / sla / remind_policy); • Template and scoring rules snapshot T (template_id + template_version + model_rules_snapshot); • Dependency version (org / template / policy).

[0137] One possible pseudocode is as follows: .

[0138] 6. S6: Task generation and state machine instantiation.

[0139] The formula for calculating the task deterministic key can be: task_id =base62( H ( instance _ id ∥ steps _ key ∥ employee _ id ∥ rater _ id )); in, task_id This serves as a deterministic and unique identifier for the task; base62(...) is the Base62 encoding function; H (·) represents a hash function; || represents the concatenation operator; instance_id This serves as a unique identifier for the assessment example; step_key For process step keys (such as self_review, manager_review, etc.); employee_id This serves as a unique identifier for the employee being evaluated. rater_id This serves as a unique identifier for the reviewer. A quaternion defines a unique review task relationship, and upsert writes guarantee idempotent generation.

[0140] One possible pseudocode is as follows: .

[0141] 7. S7: Execution-phase organizational change isolation + event-driven exception handling.

[0142] The formula for calculating event deduplication can be: dedupe _ key = H ( event _ id ∥ instance _ id ) ; in, dedupe_key Deduplicating keys for idempotent events; H (·) represents a hash function; || represents the concatenation operator; event_ id It serves as a globally unique identifier for external events; instance_id This serves as a unique identifier for the current assessment instance. The two are concatenated, hashed, and then the deduplication key is obtained and stored in the event_log. This key is checked each time an event is received. dedupe_key Does it already exist? If it already exists, it is considered a duplicate delivery and returned directly; if it does not exist, it is written to the log and processing actions such as filling in or freezing are performed.

[0143] One possible pseudocode is as follows: .

[0144] The following is an example pseudocode for a fill-in strategy (nearest_active_manager): .

[0145] 8. S8: Controlled Change.

[0146] One possible pseudocode is as follows: .

[0147] 9. S9: Audit Replay.

[0148] One possible pseudocode is as follows: .

[0149] IV. Specific Implementation Plan.

[0150] 1. Key data structures.

[0151] 1) Draft: draft_id, version, cycle, scope_config, process_config, template_config, model_rules, evidence_map, validation_status; change_log(ops[], reason, operator, timestamp, pre_hash, post_hash).

[0152] 2) Validation: validation_result(status, items[], fingerprint).

[0153] 3) Instance: instance_id, draft_id, frozen_at, org_snapshot_version, template_version, rule_version, policy_version, snapshot_hash, final_validation_fingerprint; cycle_snapshot, participants_snapshot, groups_snapshot, relations_snapshot, process_snapshot, template_snapshot.

[0154] 4) Tasks / State: task(task_id, instance_id, step_key, assignee_id, target_employee_id, due_at, status, task_hash); state(instance_id, step_key, status, started_at, ended_at).

[0155] 5) Event / Change: event(event_id, event_type, user_id, payload, occurred_at); event_action_log(instance_id, event_id, action_type, before, after,approver, reason, policy_version, timestamp); change_request(instance_id, requested_ops, impact_summary, approvals[], status).

[0156] 2. Example 1: Change of supervisor after initiation does not affect the instance.

[0157] Freeze relations_snapshot when initiated: Employee A → Supervisor M.

[0158] Organizational restructuring during the execution period: A's supervisor was changed to M2.

[0159] The system prioritizes snapshots: tasks are still assigned to M; if M leaves, a replacement strategy is triggered and a record is left.

[0160] Audit playback: The basis and filling process at the time of initiation can be restored, and the snapshot_hash verification is passed.

[0161] 3. Example 2: Concurrent editing drift is intercepted by two-stage verification.

[0162] HR1 in version v 3. Edit the scope and save; HR2 is based on v 3. Editing process formation v 4.

[0163] HR1 initiates by carrying expected_version= v 3.

[0164] The draft version of the initiation of in-transaction checks is v 4. Trigger DRAFT_VERSION_MISMATCH, reject and prompt for reconfirmation; or enter merge_ops for automatic merging (merge if there are no conflicts, output the conflicting block if there are conflicts). Avoid the "Initial configuration is not the version you see" error.

[0165] 4. Example 3: Replacement and auditing of reviewers who leave their positions.

[0166] The resignation of reviewer M triggers the rater_inactive event.

[0167] The system assigns tasks to the parent manager (S) according to the policy "nearest_active_manager" and can grant SLA grace periods for "due_at". new due_at =min( old due_at +Δ grace , final deadline ).

[0168] Write the following to the event_action_log: before / after, reason, approver (if needed), policy_version, and timestamp.

[0169] 5. Example 4: Missing comments compensation and interpretable archiving.

[0170] A certain employee's collaborative review was missing, and the system generated compensation based on confidence level weighting. And record is_compensated and alpha_used.

[0171] The archived report clearly lists the "sources and scope of impact of the compensation scores" to reduce disputes.

[0172] V. Alternative solutions.

[0173] The following implementations are all equivalent replacements: 1. Replacement with concurrent editing mechanism: Replace "version number + merge" with CRDT (Conflict-free Replicated Data Type), OT (Operational Transform), field segment locks, or pessimistic locks; the core remains "controllable and auditable concurrent modifications".

[0174] 2. Consistent view alternative: Replace MVCC (Multi-Version Concurrency Control) / at_version reads with TSO (Timestamp Oracle), snapshot read replicas, and read-write arbitration; the core is "initiating intra-transaction dependency version consistency".

[0175] 3. Snapshot-verifiable alternative: The approach replaces single hashes with Merkle trees, WORM (Write Once, Read Many) storage, event sourcing, and immutable log ledgers; the core principle is "provable immutability."

[0176] 4. Event handling alternatives: The core of the approach is "event-driven + idempotent + traceability". It is based on message queue at least once delivery + deduplication and replacement with exactly once semantics, idempotent consumption framework, Saga (used to break a long transaction into a series of local transactions, each corresponding to a participating service) / TCC (Try-Confirm-Cancel).

[0177] 5. Replacement / compensation strategies: Replace rule-based strategies with statistical models, graph search, and learning strategies; however, "strategy versioning + audit explanation field" must be retained.

[0178] VI. Summary of Key Technical Points

[0179] Key Point 1: The draft state-instance dual-state model isolates execution from the instance state.

[0180] • Divide the performance plan configuration into Draft (variable and versionable) and Instance (immutable and only depends on snapshot execution); • Reading real-time configuration / real-time organization overwrite is prohibited during instance runtime; tasks and state machines are driven solely based on instance snapshots.

[0181] Key Point 2: Two-stage verification access control.

[0182] • Perform the first stage of validation before editing / initiating the draft, and output the graded results (pass / warn / blocked) and validation details; • Perform the second-phase final verification within the initiating transaction, which should include at least: a. Draft version consistency check (expected draft_version); b. Key consistency verification (weight / process / scope / relationship chain); c. Verification of consistent views of external dependencies (see key point 3).

[0183] Key point 3: Initiate a consistent view that binds external dependencies within a transaction.

[0184] • Determine and bind the following within the initiating transaction: org_snapshot_version, template_version, policy_version (extensible permission policy version, etc.); • The second phase of verification and instance freezing is completed by reading at version (read_at_version / consistent read), avoiding the drift of dependent data within the transaction.

[0185] Key Point 4: Freeze Scope and Immutability Rules for Instance Snapshot Freezing.

[0186] • When converting a draft into an instance, freeze at least the following snapshots: cycle, scope resolution participants, review relationship chain, process state machine, template and scoring rules, and dependency version identifiers; • Instance snapshots cannot be modified by default; if changes are required, a controlled change mechanism must be followed.

[0187] Key Point 5: Snapshot-based idempotent task generation and state machine instantiation.

[0188] • Use the deterministic task_id determined by instance_id + step_key + employee_id + rater_id; • Supports retrying tasks without recreating them (idempotent upsert / unique constraints), and advances execution using state transition rules based on process snapshots.

[0189] Key Point 6: Versioned editing of draft patches + change audit chain.

[0190] • Draft editing is expressed using ops[] (add / remove / replace), incrementing draft_version; • Record change_log (operator, time, field path, previous and next values, reason, evidence reference / association).

[0191] Key Point 7: Concurrent Editing Conflict Detection and Automatic Merging.

[0192] • Perform conflict determination on the field paths of the patch (write on the same path / overwrite by parent and child paths / array index conflict). • Non-conflicting ops are automatically merged, while conflicting ops are output as conflict blocks and require confirmation, thereby reducing the regularity of "rejecting based solely on version".

[0193] Key Point 8: Verification result fingerprint / deterministic verification output.

[0194] • Perform deterministic serialization on validation_items[] and calculate the validation fingerprint; • The second-stage verification can compare fingerprints or record fingerprints for audit playback, enhancing "provable consistency".

[0195] Key Point 9: Verifiable immutability of instance snapshots.

[0196] • Perform deterministic serialization on each component of the snapshot and calculate the component hash and the total hash snapshot_hash; • In scenarios with a large number of participants, MerkleRoot is used as a snapshot record for participants; • Verify the hash during audit playback to prove that the instance basis has not been tampered with.

[0197] Key Point 10: Isolation of organizational changes during execution + closed loop of event-driven exception handling.

[0198] • Clearly define the "snapshot priority isolation principle": changes in supervisors / job transfers will not alter the instance relationship chain by default; • Monitor personnel events (resignation / unavailability / job transfer / supervisor change, etc.) and execute replacement / freeze / archive according to the strategy; • The event handling process is written to the event_action_log (before / after, policy version, approver, timestamp, etc.).

[0199] Key point 11: Deduplication and idempotency of events.

[0200] • Introduce a deduplication key for event handling (e.g., dedupe_key=H(event_id+instance_id)); • Repeated deliveries will not trigger the fill / freeze action repeatedly, ensuring stability during the execution period.

[0201] Key Point 12: Filling Strategy Algorithm and Last-Comeback Pool.

[0202] • When a reviewer is unavailable: trace back up the organizational chart to the nearest available supervisor as a substitute reviewer; • When no suitable supervisor can be found, activate the fallback pool (HR / committee / proxy pool) and record the strategy version and reason.

[0203] Key Point 13: SLA / Deadline Controlled Adjustment.

[0204] • When padding or an exception occurs, a controlled grace period is applied to due_at: it does not exceed the global final_deadline; • Synchronously record changes and reasons before and after due_at to enhance auditability.

[0205] Key Point 14: Controlled Change and Approval Chain.

[0206] • Change requests include requested_ops, reason, approval chain, and status; • Change execution support: a. Patch updates that only apply to incomplete nodes / tasks; or b. Derive a new instance instance_v2 and freeze the archived old instance.

[0207] Key Point 15: Impact Surface Analysis and Differential Reconstruction of Changes.

[0208] • Calculate the set of participants / relationships / nodes / tasks that are affected for requested_ops; • Only perform differential reconstruction on tasks that have not started / completed; completed tasks remain immutable.

[0209] Key Point 16: Audit Replay + Hash Verification.

[0210] • Archive instance snapshots, task results, change chains, and event action chains; • During playback, first verify the snapshot_hash, then replay the event_action_log in chronological order, and output a verifiable report.

[0211] In summary, the embodiments of the present invention bring the following beneficial effects: 1. Significantly improved consistency: Instance execution relies only on frozen snapshots, organizational changes no longer pollute the relationship chain, and the drift incident rate is significantly reduced; Drift (…) is available. t The indicator monitoring is approaching 0.

[0212] 2. Significantly reduced concurrency incidents: Dual-stage verification + concurrency conflict detection / merging ensures that the configuration is consistent with expectations at the moment of initiation, reducing "configuration drift" and false initiation.

[0213] 3. Enhanced auditability and provability: validation_fingerprint + snapshot_hash + event_action_log constitute a verifiable audit chain, allowing dispute resolution to be replayed and proven to be tamper-proof.

[0214] 4. Uninterrupted execution and improved completion rate: Event-driven fill-in and SLA grace, missing evaluation compensation / weight normalization enable long-cycle processes to still be closed on schedule in scenarios of resignation / missed evaluation.

[0215] 5. Controllable changes and explainable impacts: Controlled changes introduce impact analysis and differential reconstruction to avoid uncontrollable side effects caused by full recalculation, while preserving the complete approval and change process.

[0216] like Figure 6 As shown, an electronic device 600 provided in this embodiment of the invention includes: a processor 601, a memory 602 and a bus. The memory 602 stores a computer program that can run on the processor 601. When the electronic device 600 is running, the processor 601 and the memory 602 communicate through the bus, and the processor 601 executes the computer program to realize the above-mentioned long-cycle performance evaluation consistency control method.

[0217] Specifically, the memory 602 and processor 601 mentioned above can be general-purpose memory and processor, without any specific limitations here.

[0218] This invention also provides a computer-readable storage medium storing a computer program. When executed by a processor, this computer program performs the long-cycle performance evaluation consistency control method described in the preceding method embodiments. The computer-readable storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), RAM, magnetic disks, or optical disks.

[0219] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0220] In all examples shown and described herein, any specific values ​​should be interpreted as merely exemplary and not as limitations; therefore, other examples of exemplary embodiments may have different values.

[0221] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0222] In the several embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some communication interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0223] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0224] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

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

Claims

1. A method for controlling consistency in long-term performance appraisals, characterized in that, include: In response to user performance appraisal scheme configuration operations, create and maintain draft configurations in draft state, and record change audit logs; wherein, the draft configurations support versioned editing and concurrent change management; During the process of initiating an assessment transaction, a two-stage verification is performed: the first stage verification includes pre-verifying the draft configuration before editing the draft configuration or initiating the assessment transaction; the second stage verification includes performing a final verification of the draft configuration based on the bound external dependency consistency view after initiating the assessment transaction, wherein the external dependency consistency view includes at least the organizational structure snapshot version, the assessment template version, and the policy version. After the second stage verification is passed, the draft configuration and its associated external dependency consistency view are frozen together to generate an instance snapshot in the instance state, and the integrity verification value of the instance snapshot is calculated; wherein, the instance snapshot includes an immutable copy of the cycle, participation scope, review relationship, process rules, scoring template and its dependent version identifier; Based on the instance snapshot, assessment tasks are generated idempotently and state machine execution is driven; wherein, during the execution of the assessment task, the processing logic of the assessment task is based solely on the instance snapshot, and the impact of real-time organizational structure and configuration changes is isolated. Monitor personnel movement events that occur during the execution of the assessment task, perform event-driven exception handling on the affected assessment task according to a predefined strategy, and record the event content, handling actions, and strategy-based actions in the event action log. After the assessment task is completed, a verifiable audit playback function is provided based on the instance snapshot and its integrity verification value, the change audit log, and the event action log.

2. The long-cycle performance appraisal consistency control method according to claim 1, characterized in that, The maintenance of draft configurations in draft mode includes: Receive editing operations on the draft configuration, the editing operations being represented in the form of an operation list; Based on the current latest draft version number configured in the draft configuration and the target draft version number corresponding to the editing operation, perform concurrent conflict detection; If a conflict is detected, conflict information will be output for the user to handle. If no conflict is detected, the editing operations are automatically merged to generate a draft configuration with a new draft version number, and the change audit log is updated.

3. The long-cycle performance appraisal consistency control method according to claim 1, characterized in that, The calculation of the integrity verification value of the instance snapshot includes: Perform hash calculations on each component of the instance snapshot; The hash values ​​of each component are concatenated and hashed, and the resulting overall snapshot hash value is used as the integrity verification value. When the number of participants exceeds a preset threshold, a Merkle root is calculated for the participant snapshot portion of the instance snapshot using a Merkle tree structure, and the Merkle root is used to calculate the overall snapshot hash value.

4. The long-cycle performance appraisal consistency control method according to claim 1, characterized in that, The event-driven exception handling includes a padding strategy, which includes at least the following: When an unavailable reviewer event is detected, the nearest valid supervisor is searched up the reporting chain as a replacement reviewer based on the frozen organizational relationships in the instance snapshot. If no suitable supervisor is found, a substitute reviewer will be assigned from a predefined pool of backup reviewers. When performing the fill-in, record the strategy version used, the changes in task status before and after processing, and the reasons in the event action log.

5. The long-cycle performance appraisal consistency control method according to claim 1, characterized in that, The long-term performance appraisal consistency control method also includes: Receive change requests for snapshots of running instances and analyze the scope of impact of the change requests for user approval; After the change request is approved, a change compatibility assessment is performed based on the scope of the change request, and differential reconstruction or new instance creation is performed on the assessment instance based on the compatibility assessment results. The differential reconstruction applies changes only to incomplete assessment tasks, while the new instance creation operation creates a new instance snapshot and archives the original instance snapshot, while recording the complete change approval and execution chain.

6. The long-cycle performance appraisal consistency control method according to claim 1, characterized in that, The long-term performance appraisal consistency control method also includes: Through the aforementioned two-stage verification, instance snapshot freezing, and audit chain construction, the following objective function will be implemented. The value is constrained to within a predetermined threshold: ； Among them, Drift( t (time) t The configuration drift risk metric is used to characterize the degree of deviation between the instance execution relationship chain and the real-time organizational relationship; To validate the violation indicator function, used to characterize the draft version. v The following draft configuration D (v) The number of items blocked during the audit; AuditGap( I ) is an audit gap indicator function used to characterize instance snapshots. I The situation regarding the lack of audit evidence; λ 1. λ 2. λ 3 are all preset weighting coefficients.

7. The long-cycle performance appraisal consistency control method according to claim 1, characterized in that, After the first stage verification and / or the second stage verification is completed, the long-term performance appraisal consistency control method further includes generating a verification fingerprint in the following manner: The verification details in the verification result generated by the two-stage verification are subjected to deterministic serialization processing, which includes at least sorting all keys, sorting the array, and normalizing null values. The serialized result is hashed to obtain the verification fingerprint. The verification fingerprint is used to compare the verification results within the initiating transaction and / or to verify the consistency of the verification basis during audit playback.

8. A long-cycle performance appraisal consistency control system, characterized in that, include: The configuration and maintenance module is used to respond to users' performance appraisal scheme configuration operations, create and maintain draft configurations in draft state, and record change audit logs; wherein, the draft configurations support versioned editing and concurrent change management; The two-stage verification module is used to perform two-stage verification during the initiation of an assessment transaction: the first-stage verification includes pre-verification of the draft configuration before editing the draft configuration or initiating the assessment transaction; the second-stage verification includes final verification of the draft configuration based on the bound external dependency consistency view after initiating the assessment transaction, wherein the external dependency consistency view includes at least the organizational structure snapshot version, the assessment template version, and the policy version. The snapshot freezing module is used to freeze the draft configuration and its associated external dependency consistency view together to generate an instance snapshot in the instance state after the second stage verification is passed, and to calculate the integrity verification value of the instance snapshot; wherein, the instance snapshot includes an immutable copy of the cycle, participation scope, review relationship, process rules, scoring template and its dependent version identifier; The task execution module is used to generate assessment tasks idempotently based on the instance snapshot and drive the state machine to execute; wherein, during the execution of the assessment task, the processing logic of the assessment task is based only on the instance snapshot and is isolated from the impact of real-time organizational structure and configuration changes; The exception handling module is used to monitor personnel movement events that occur during the execution of the assessment task, perform event-driven exception handling on the affected assessment task according to a predefined strategy, and record the event content, handling actions and the strategy to the event action log. The audit replay module is used to provide verifiable audit replay functionality based on the instance snapshot and its integrity verification value, the change audit log, and the event action log after the assessment task is completed.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the long-cycle performance evaluation consistency control method as described in any one of claims 1-7.

10. A computer-readable storage medium storing a computer program thereon, characterized in that, The computer program, when executed by the processor, performs the long-cycle performance evaluation consistency control method as described in any one of claims 1-7.

Images