Chain store operation abnormality closed loop processing method and device based on evidence contract and dynamic effect verification, and medium

Abstract

The application provides a chain store operation abnormity closed-loop processing method and device based on evidence contract and dynamic effect verification, and a medium, which comprises the following steps: acquiring multi-source operation data to generate data snapshots with version information; creating an abnormal object bound with an abnormal fingerprint, an evidence contract and an effect contract; gating in combination with multi-dimensional evidence quality and action risk; performing pre-verification before writing back after approval, and making the approval invalid if the action envelope is not met; obtaining an execution receipt through idempotent writing back; calculating an effect score based on dynamic contrast indexes within the window limited by the effect contract and updating the closed-loop state; and writing the decision feedback and the verification result feedback into different channels respectively. The application is used for operation abnormity disposal in a multi-store scene, and can improve the accuracy, traceability and closed-loop verifiability of the abnormity disposal.

Description

Technical Field

[0001] This invention relates to the field of computer data processing and business process control technology, and in particular to a method, apparatus and medium for closed-loop processing of chain store operation anomalies based on evidence contracts and dynamic effect verification. Background Technology

[0002] In the daily operations of chain retail or catering enterprises, stores typically deploy multiple heterogeneous information systems, such as POS systems, ERP systems, inventory management systems, supply chain systems, membership management systems, promotion systems, and task management systems. Regional managers need to identify operational anomalies from a large number of stores, products, and time series data, determine the causes of the anomalies, issue rectification tasks to store or supply chain personnel, and subsequently confirm whether the rectification is effective.

[0003] Existing technologies offer various solutions for handling operational anomalies in chain stores. The first type of technology utilizes sales forecasting, inventory discrepancy calculations, time-series thresholds, or machine learning models to identify operational anomalies such as stockouts, overstocking, and sales fluctuations, and outputs warnings or replenishment suggestions. Examples include sales forecasting-based data processing methods for order reporting. The second type of technology performs permission checks, risk checks, or system status verification before automating actions to reduce the risk of unauthorized or unsuitable operations. Examples include permission level verification and pre-execution verification methods based on maintenance instruction parsing. The third type of technology records the processing process using alarm or work order statuses and checks whether technical indicators have recovered after processing. If the indicators recover, the processing is complete; otherwise, it re-enters the unprocessed state.

[0004] However, the aforementioned solutions lack a unified collaborative control mechanism across stages such as anomaly identification, action approval, pre-execution checks, and result verification. The data version, evidence source, cause confidence level, suggested actions, and expected indicators of anomalous data cannot be transmitted and traced along with the task status, resulting in the loss of the anomaly handling context during cross-system flow.

[0005] Therefore, there is an urgent need for a closed-loop processing method, device, and medium for abnormal chain store operations based on evidence contracts and dynamic effect verification, in order to solve the problems existing in the current technology. Summary of the Invention

[0006] This invention provides a closed-loop processing method, device, and medium for chain store operation anomalies based on evidence contracts and dynamic effect verification. It addresses the problems of existing technologies, such as the disconnect between anomaly identification, decision approval, action execution, and effect verification, inconsistencies between approval criteria and execution status, and attribution bias caused by the lack of dynamic comparison in action effect evaluation.

[0007] The core technology of this invention mainly uses an abnormal object containing evidence contracts and effect contracts as a carrier. By gating action levels based on evidence quality, dynamic re-verification based on data versions is introduced between approval and execution. Combined with dynamic comparison effect scoring and dual-channel feedback mechanism, machine-verifiable closed-loop handling of operational anomalies is achieved.

[0008] In a first aspect, the present invention provides a closed-loop processing method for abnormal operations of chain stores based on evidence contracts and dynamic effect verification, the method comprising the following steps: Acquire multi-source operational data and generate data snapshots with version information; Based on data snapshots, operational anomalies are identified, and anomaly objects are created that are bound with anomaly fingerprints, evidence contracts, and effect contracts. The output level of a candidate action is determined by combining the multidimensional evidence quality of the data snapshot with the risk of the candidate action, and the approval result is obtained after the approval is triggered. After a candidate action is approved but before it is written into the target business system, the current operating data is re-acquired for pre-execution re-verification. If the current operating data and the data on which the approval is based do not meet the preset action applicability envelope, the original approval is invalidated and the process is returned for re-diagnosis. In response to successful pre-execution re-verification, an action write-back request containing idempotent control information is sent to the target business system, and an execution receipt is obtained. In response to the execution receipt, target indicators and dynamic comparison indicators are collected within the verification window defined by the effect contract, the comprehensive effect score is calculated, and the closed-loop processing status of abnormal objects is updated based on the comprehensive effect score and the guardrail indicators. The approval decision records for candidate actions and the operational performance records after effect verification are written into different feedback channels to update the action suggestion ranking model and the action effect prediction model respectively.

[0009] Furthermore, an evidence contract refers to a set of machine-verifiable conditions bound to an abnormal object and its data version, used to determine whether an abnormal object can enter the subsequent action stage. It includes at least the necessary data source and fields, maximum refresh delay, cross-source consistency tolerance, minimum data granularity, data version and abnormal fingerprint generation rules, action gating thresholds, and downgrade actions when evidence is insufficient.

[0010] Furthermore, the multidimensional evidence quality includes at least two of the following: completeness, freshness, consistency, granularity adaptability, and traceability; a comprehensive evidence quality score is calculated based on the multidimensional evidence quality; when the comprehensive evidence quality score is lower than the preset action execution threshold, the candidate action is automatically downgraded to a data verification or supplementary collection task.

[0011] Furthermore, the action's applicable envelope includes allowable deviations for key fields and insurmountable business hard constraints. Business hard constraints include at least one of safety stock, store capacity, remaining shelf life, permission status, and conflicting tasks, and are not exempted due to allowable deviations. Pre-execution re-verification includes: collecting current operational data and generating the data version at execution time and the current abnormal fingerprint; when the deviation of key fields relative to the approval time exceeds the allowable deviation, the current abnormal fingerprint disappears or its intensity changes beyond the set range, or a business hard constraint is triggered, the original approval is deemed invalid.

[0012] Furthermore, the effect contract pre-fixes the target indicator, guardrail indicator, indicator direction, control generation method, verification window, minimum sample size, effective threshold, invalid threshold, and uncertainty handling rules before the candidate action is executed, and these cannot be changed afterward during the verification period of the same contract version; the dynamic control indicator is generated by at least one of the following: the predicted value of the same store's historical comparable period, the weighted indicator of similar stores or similar product groups that have not executed the candidate action, the value generated by the prediction model combined with external environmental factors, and the trend extrapolation value before the action.

[0013] Furthermore, updating the closed-loop processing status of abnormal objects based on the comprehensive effect score and guardrail indicators includes: When the overall effect score reaches the effective threshold and the guardrail index does not deteriorate, the closed-loop processing status of the abnormal object will be updated to "improved". When the overall effect score is lower than the invalid threshold, the closed-loop processing status of the abnormal object is updated to "not improved" and it is re-entered into the diagnosis. When the overall performance score is between the invalid and valid thresholds or when there are insufficient observation samples, the closed-loop processing status of the abnormal object is updated to uncertain, and the verification window is extended or manual review is triggered.

[0014] Furthermore, the approval decision records for candidate actions and the operational performance records after effect verification are written into different feedback channels, including: writing the approval decision records into the decision feedback dataset to optimize the front-end interface display and suggested ranking; and writing the operational performance records into the verification result dataset only when the preset minimum sample size, evidence quality and result certainty conditions are met, to update the action effect model or strategy selection model.

[0015] Secondly, the present invention provides a closed-loop processing device for chain store operation anomalies based on evidence contracts and dynamic effect verification, comprising: The data acquisition and quality assessment module is used to acquire multi-source operational data and generate data snapshots with version information to assess the quality of multi-dimensional evidence. The anomaly detection and diagnosis module is used to identify operational anomalies based on data snapshots and generate anomaly fingerprints, candidate causes, and supporting or refuting evidence. The Evidence Contract and Effect Contract modules are used to generate evidence contracts and effect contracts bound to the abnormal object. The evidence contract defines the machine-verifiable conditions that the abnormal object must meet to enter the subsequent action stage, and the effect contract fixes the effect verification rules before the candidate action is executed. An exception object library and state machine are used to store exception objects with globally unique identifiers and manage their state transitions. An exception object is associated with at least a store or product identifier, indicator time window, data version, exception fingerprint, evidence contract, candidate action, effect contract, and audit event. State transitions have machine-verifiable entry conditions. The action generation and risk gating module is used to determine the output level of candidate actions by combining the quality of multidimensional evidence and the risk of candidate actions, and to obtain the approval result after triggering the approval process. The pre-execution re-verification module is used to re-acquire the current operating data for pre-execution re-verification after the candidate action has been approved and before it is written into the target business system. If the current operating data and the data on which the approval is based do not meet the preset action applicable envelope, the original approval will be invalidated and the process will be returned for re-diagnosis. The idempotent write-back module is used to send an action write-back request containing idempotent control information to the target business system and obtain the execution receipt when the pre-execution re-verification passes. The dynamic effect verification module is used to respond to the execution receipt, collect target indicators and dynamic comparison indicators within the verification window defined by the effect contract, calculate the comprehensive effect score, and update the closed-loop processing status of abnormal objects based on the comprehensive effect score and guardrail indicators. The dual-channel feedback update module is used to write the approval decision records for candidate actions and the operational performance records after effect verification into different feedback channels, so as to update the action suggestion ranking model and the action effect prediction model respectively.

[0016] Thirdly, the present invention provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to execute the above-mentioned closed-loop processing method for chain store operation anomalies based on evidence contracts and dynamic effect verification.

[0017] Fourthly, the present invention provides a readable storage medium storing a computer program, which, when executed by a processor, implements the above-described closed-loop processing method for chain store operation anomalies based on evidence contracts and dynamic effect verification.

[0018] The main contributions and innovations of this invention are as follows: 1. This invention links the original data version, anomaly fingerprint, evidence, action, approval, receipt, and effect by unifying the anomaly object, avoiding context loss caused by storing warnings, analysis reports, approval forms, store tasks, and execution results in different systems, and ensuring that the anomaly maintains the same technical identifier from discovery to closure.

[0019] 2. This invention transforms data integrity, freshness, consistency, granularity, and lineage into computer-executable permission conditions through evidence contracts and quality gating mechanisms. When evidence is insufficient, high-risk actions are automatically downgraded to data verification tasks, avoiding the generation of unsuitable actions due to reasons such as inventory synchronization delays or missing batch data.

[0020] 3. This invention uses a pre-execution re-verification module to re-collect the current status after approval and before execution, compare the data version at the time of approval with the data version at the time of execution, and use the action application envelope for verification. When the business status changes, the original approval becomes invalid, thereby avoiding the continued execution of outdated actions after the anomaly disappears or the intensity changes.

[0021] 4. This invention uses effect contracts to fix verification rules before the action is executed, and uses dynamic historical data or similar stores to construct counterfactual comparisons to calculate standardized effect scores. This can effectively eliminate the influence of external factors such as holidays, weather, promotions or natural regression on indicator changes, and achieve objective attribution of the actual business effect of the action.

[0022] 5. This invention separates user decision feedback from verified effect feedback through a dual-channel feedback mechanism, avoiding the erroneous attribution of directly equating "user adoption" with "action effectiveness". This allows the action effect model to be updated based on real business results, improving the effectiveness of subsequent recommended actions.

[0023] 6. This invention integrates exceptions, approvals, executions, and verifications into a complete closed loop through machine-verifiable state transition rules. Each state transition is bound to the data version, the operating entity, the execution receipt, and the result, preventing exceptions without approval, receipt, or verification results from being mistakenly closed.

[0024] Details of one or more embodiments of the present invention are set forth in the following drawings and description, so that other features, objects and advantages of the invention will be more readily understood. Attached Figure Description

[0025] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings: Figure 1This is a system framework diagram of a closed-loop processing method for abnormal chain store operations based on evidence contracts and dynamic effect verification according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only for explaining the invention and are not intended to limit the invention. Technical terms not specifically described in this specification have meanings known to those skilled in the art. This invention belongs to the field of computer data processing and business process control technology. The module division in the following embodiments is a logical functional division, which can be implemented in electronic devices through software instructions, hardware circuits, or a combination thereof. The English abbreviations (such as POS, ERP, etc.) involved in the embodiments of this invention have clear meanings known to those skilled in the art.

[0027] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0028] Example 1 like Figure 1 As shown, this invention provides a closed-loop processing device for chain store operational anomalies based on evidence contracts and dynamic effect verification. The device is deployed on one or more servers, edge computing nodes, or cloud services, and connects to POS systems, ERP systems, inventory systems, supply chain systems, product master data systems, promotion systems, task management systems, and permission systems via interfaces. This system does not replace the legal or business accounting capabilities of the aforementioned systems; instead, it serves as an anomaly handling control layer, responsible for unified anomaly object management, action permission control, pre-execution status review, execution receipt collection, and effect verification.

[0029] The system comprises nine functional modules: data alignment and quality assessment, anomaly detection and diagnosis, evidence contract and effect contract, anomaly object library and state machine, action generation and risk gating, pre-execution re-verification, idempotent write-back, dynamic effect verification, and dual-channel feedback update. Each module can be implemented on the same computing device or deployed as multiple microservices. Modules communicate with each other via message queues, event buses, database change events, or synchronization interfaces. The anomaly object library preferably uses event sourcing to store each state transition; alternatively, a relational database can be used to record the current state and write historical events to an audit table.

[0030] The system can be deployed in various ways, including but not limited to: enterprise private cloud, public cloud, or edge nodes. Inventory and transaction events with high real-time requirements can be input via message queues, while master data and historical data can be synchronized via batch processing. The write-back interface preferably supports idempotent keys, version conditions, request signatures, permission tokens, and receipt queries. When the target business system supports optimistic locking, the idempotent write-back module can use the version at execution time as a conditional update field; if the target system does not support version conditions, this system will perform re-verification before the call and immediately query the receipt and current status after the call.

[0031] In this embodiment, the basic processing unit of the present invention is not an isolated warning message, but an anomaly object. Each anomaly object has a globally unique anomaly identifier and is associated with at least a store identifier, a product identifier or product group identifier, an indicator, a time window, a data version, an anomaly fingerprint, an evidence contract, candidate causes, candidate actions, an effect contract, a status, and an audit event. The anomaly object is updated as the handling process progresses, but its original data snapshot and version relationship remain traceable.

[0032] In a preferred embodiment, the data structure of the exception object includes at least the following fields: The object identification field includes anomaly identifier, enterprise identifier, region identifier, store identifier, product identifier or product group identifier, anomaly type, detection time, and effective time window.

[0033] The anomaly fingerprint field consists of comparable features generated by the anomaly type, object range, indicator time window, key feature summary, and data version according to preset encoding, hashing, or structured combination rules. Anomaly fingerprints are used to identify duplicate anomalies, merge similar anomalies, determine whether anomalies persist, and verify whether the approval basis still holds before execution. Anomaly fingerprints are not limited to cryptographic hash values; they can also use deterministic hashing, locality-sensitive hashing, or combinations of structured fields.

[0034] Evidence fields include data source identifier, data timestamp, collection batch, calculation caliber, data lineage, missing rate, refresh delay, cross-source consistency, minimum data granularity, and evidence quality score.

[0035] Diagnostic fields include the intensity of the anomaly, the scope of its impact, the expected loss or opportunity, a list of candidate causes, the confidence level of the cause, and supporting and rebuttal evidence.

[0036] The action field includes candidate action type, action parameters, applicable prerequisites, risk level, reversibility, scope of impact, required permissions, target business system, and expected execution receipt.

[0037] The effect contract fields include target metric, guardrail metric, metric direction, baseline generation method, validation start and end times, minimum observation sample size, effective threshold, invalid threshold, and rules for handling uncertain states. An effect contract is a set of effect validation rules and their version information determined before candidate actions are executed and bound to the exception object and candidate actions. The effect contract must at least fix the target and guardrail metric, metric direction, control generation method, validation window, minimum sample size, effective threshold, invalid threshold, and rules for handling uncertain states; during the validation of the same contract version, a more favorable metric or threshold cannot be selected retroactively.

[0038] The status and audit fields include the current status, previous status, status transition time, operator or service subject, data version at the time of approval, data version at the time of execution, execution receipt, verification result, and feedback destination.

[0039] In this embodiment, the data alignment and quality assessment module standardizes multi-source data according to enterprise, region, store, product, time, and business scope. This module unifies timestamps from different systems to a set time zone and granularity, maps product codes, store codes, and activity codes to unified master data, and records the collection batch and lineage of the original data. For each object to be detected, the module calculates scores for evidence dimensions such as completeness, freshness, consistency, granularity fit, and traceability. Completeness reflects the absence of required fields and records in the target window; freshness reflects the difference between the current time and the data update time; consistency reflects the degree of matching between relevant quantities such as POS sales, ERP outbound shipments, and inventory changes; granularity fit reflects whether the data reaches the granularity required for anomaly judgment (e.g., store-product-batch); and traceability reflects whether the data has records of source, batch, scope, and transformation chain. Data versions can be database snapshot numbers, event sequence numbers, key field hashes, or vectors composed of multiple source versions. In one specific embodiment, when the batch expiration date field used to determine near-expiration loss is missing, even if the total inventory and sales data are complete, the granularity fit score still decreases. At this time, the comprehensive evidence quality score does not reach the action execution threshold, and the system should not output direct price reduction or cross-store transfer instructions, but should output batch verification tasks instead.

[0040] In this embodiment, the anomaly detection and diagnosis module can identify operational anomalies using rules, statistical models, time series models, machine learning models, or a combination thereof. This module outputs the anomaly type, anomaly strength, impact estimate, and one or more candidate causes. Stockout risk detection can be based on a comprehensive assessment of current available inventory, in-transit volume, projected sales volume, delivery cycle, and safety stock; inventory backlog detection can be based on a comprehensive assessment of inventory days, sales trends, shelf life, and store capacity; near-expiry loss detection can be based on a comprehensive assessment of batch expiration date, expected consumption rate, and available store demand; and sales anomaly detection can be based on a comparison of same-store baseline, similar stores, weather, holidays, and promotional conditions. Candidate causes are not simply natural language descriptions but structured results that include cause identifiers, confidence levels, supporting evidence sets, and rebuttal evidence sets.

[0041] In this embodiment, the evidence contract and effect contract modules are used to generate evidence contracts and effect contracts bound to the anomalous object. An evidence contract is a set of machine-verifiable conditions that the anomalous object must satisfy before entering subsequent action stages, and it is bound to the anomalous object and its data version. Each evidence contract has a unique contract version and is stored together with the anomalous object's data version and anomalous fingerprint. The system verifies the contract conditions item by item; if any required condition is not met, no directly executable action is generated, but instead, the task is downgraded to data supplementation, inventory counting, batch verification, or manual review. An evidence contract includes at least: Required data source and fields; Maximum allowable refresh latency for each data source; The permissible range of cross-source consistency; Minimum granularity required for anomaly detection; Data version and abnormal fingerprint generation rules; The minimum quality threshold of evidence required to execute an action; And downgrade actions when there is insufficient evidence.

[0042] Multiple versions of the evidence contract are allowed for the same anomaly type. For example, handling overstocking of general packaged foods allows for store-product-day granular inventory, while short-shelf-life foods require store-product-batch granularity and an expiration date field. The effect contract is determined before candidate actions are executed and is bound to the anomaly object and candidate actions. The effect contract must at least fix the target metric and guardrail metric, metric direction, control generation method, validation window, minimum sample size, valid threshold, invalid threshold, and rules for handling uncertain states. The target metric can be out-of-stock rate, availability rate, inventory turnover days, loss rate, sales volume, or gross profit; guardrail metric is used to avoid local optimization causing other problems, such as replenishment reducing the out-of-stock rate but significantly increasing near-expiration losses.

[0043] In this embodiment, the exception object library stores the current snapshot, historical versions, and audit events of exception objects. The state machine includes at least the following eight states: pending confirmation, pending execution, executing, pending verification, improved, not improved, uncertain result, and false alarm. Each state transition has a clearly defined machine-verifiable entry condition: 1. To move from pending confirmation to pending execution, the evidence quality must reach the corresponding threshold, candidate actions must be generated, and the required manual or system approval must be completed.

[0044] 2. Before execution, the system must pass a re-verification process. The current data version must be consistent with or different from the approval criteria and be within the applicable envelope of the action. The target system must then accept the action.

[0045] 3. To move from execution to verification, an execution receipt from the target system or store must be obtained. The receipt must include at least the action identifier, actual parameters, completion time, and result status.

[0046] 4. From unverified to improved or unimproved, the minimum verification window and sample requirements must be met, and the effect score exceeding the uncertainty interval must be calculated.

[0047] 5. The result is uncertain after the period of pending validation, due to insufficient observation sample, conflicting external interventions, or the effect score falling into the uncertainty range.

[0048] 6. If a false alarm occurs from any open state, an inventory check, data repair, or subsequent verification is required to prove that the original anomaly did not exist, and the reason for the false alarm must be recorded.

[0049] Each state transition is written to an event, which includes at least an exception flag, the states before and after the transition, the time, the operator or service entity, the data version, the evidence summary, and the associated task or receipt flag. This prevents illegal transitions such as entering execution without approval, entering verification without a receipt, or entering closure without verification. The state machine can be implemented using a workflow engine, event-driven services, or database constraints.

[0050] In this embodiment, the action generation and risk gating module generates candidate actions based on the anomaly type, candidate reasons, current constraints, and historical verification results. Initial actions may include inventory counting, replenishment, inter-store transfer, display adjustment, near-expiry promotion, activity modification, or manual review. The risk gating module calculates a risk score based on the action amount, the scope of affected stores or products, reversibility, cross-regional extent, target system permissions, and cause confidence. Evidence quality and action risk jointly determine the output level: when evidence quality is below the verification threshold, only data replenishment, inventory counting, or manual verification tasks are output; when evidence quality reaches the suggested threshold but not the execution threshold, risk warnings, explanations of reasons, and action drafts can be output; when evidence quality reaches the execution threshold and action risk is low, executable tasks can be generated within the pre-authorized scope; medium- to high-risk actions must be approved by the regional manager, supply chain, or other authorized entities; high-risk, irreversible, or cross-regional actions, even with high evidence quality, must undergo multi-level approval or only output suggestions. The approval interface displays abnormal fingerprints, key evidence, data time, cause confidence level, action parameters, risk score, expected indicators, and a verification window to the approver. Approval results include acceptance, rejection, parameter modification, or request for supplementary evidence, and are recorded separately as decision feedback. The verification window represents the observation period after the action, preferably 3–14 days, configured according to product turnover and action type.

[0051] In this embodiment, the pre-execution re-verification module re-collects the current state related to the action after it is approved but before it is actually written back, including available inventory, in-transit quantity, recent sales volume, batch expiration date, promotion status, incomplete tasks, and permission status. This module generates the execution-time data version and the current anomaly fingerprint, and compares them with the record from the approval time. The action application envelope refers to the set of state constraints predetermined at the time of approval for a candidate action, which allows the action to remain valid during execution. It consists of allowable deviations for key fields and insurmountable hard constraints. Allowable deviations are configured according to action type, key fields, and business objects; hard constraints such as safety stock, store capacity, remaining shelf life, permission status, and conflicting tasks are not exempted due to allowable deviations. The original approval becomes invalid and cannot be executed directly if at least one of the following conditions occurs: the current data version indicates that key data has been updated, and the abnormal fingerprint has disappeared or its intensity has changed beyond the threshold; the current state exceeds the applicable envelope of the action, such as expected inventory exceeding store capacity after replenishment, the store itself becoming out of stock at risk, or near-expiry batches already sold; there are already conflicting tasks acting on the same store, product, and time window; the target system permissions, store operating status, or promotional status have changed; or the quality of evidence falls below the execution threshold due to data expiration, source interruption, or decreased consistency. After the original approval becomes invalid, the system will return the abnormal object to the pending confirmation or verification status, save the reason for the invalidation, and recalculate the candidate action based on the new data. If data differences exist but fall within the predefined applicable envelope of the action, the system can adjust the actual parameters and request confirmation again, or automatically execute according to the allowable deviation set at the time of approval.

[0052] In this embodiment, the idempotent write-back module converts approved and re-verified actions into interface requests acceptable to the target system. This request includes at least an anomaly identifier, action identifier, idempotent key, target object, action parameters, approval information, data version at execution time, and timeout conditions. The idempotent key prevents network retries from causing duplicate replenishment, duplicate allocation, or duplicate promotions. The target system returns an acceptance, rejection, partial execution, or completion receipt. For actions such as manual inventory checks and display adjustments that cannot be automatically confirmed by the business system, the store submits a task receipt with time and object identifiers, and if necessary, includes the inventory quantity, photo hash, or approver's review record. If the actual execution parameters differ from the approved parameters, the system saves both the approved and actual parameters, using the actual parameters for effect verification to prevent the verification model from using incorrect intervention strength. Action execution can be fully manual, semi-automatic, or automatic. Regardless of the degree of automation, the system saves the actual action parameters and execution receipts, and verifies the results according to the same effect contract.

[0053] In this embodiment, the dynamic effect verification module continuously collects target and guardrail indicators within the time window specified in the effect contract. This module generates counterfactual or control values ​​for each indicator. Dynamic controls can be generated using one or more of the following methods: historical comparable time-period predicted values ​​for the same store and the same product; weighted indicators for similar stores or similar product groups that did not perform the action; model predicted values ​​considering weather, holidays, promotions, and regional trends; pre-action trend extrapolation values; and combined control values ​​obtained by weighting multiple baselines according to reliability. For stores with insufficient data, controls can degenerate into regularized baselines. The system compares the actual indicators with the control values ​​and standardizes them according to indicator direction and uncertainty to obtain a comprehensive effect score. When subsequent inventory checks or data repair prove that the anomaly originated from data errors, the abnormal object is marked as a false alarm, and the corresponding action result is not used as a valid training sample.

[0054] In this embodiment, the dual-channel feedback update module divides feedback into two independent channels: decision feedback and verification result feedback. Decision feedback includes approver acceptance, rejection, parameter modification, supplementary evidence requirements, and explanatory text. It is used to optimize information presentation, approver preferences, suggested ranking, and required evidence, but does not directly prove that an action has operational effectiveness. Verification result feedback includes effectiveness scores, effective or invalid labels, changes in guardrail indicators, actual action parameters, store context, and counterfactual reliability. Only verification results that meet the minimum sample size, evidence quality, and result certainty conditions are entered into the action effectiveness model or strategy selection model. Through two independent dataset identifiers, feature spaces, and update entry points, the system prevents frequently accepted actions from being directly converted to frequently effective ones. When an action has a high acceptance rate but a low verification effectiveness rate, the system can lower the action's effectiveness priority while preserving its comprehensible ranking within the specific approver's interface.

[0055] Preferably, when the same store and product repeatedly trigger similar anomalies within adjacent time windows, the system compares the similarity between the current anomaly fingerprint and historical anomaly fingerprints. If the similarity reaches a preset threshold, the operational anomaly is merged into the original anomaly object and its strength is updated, rather than creating a new object. For anomalies caused by independent reasons, the system creates a new anomaly object. If multiple anomalies generate conflicting actions, such as one action requiring restocking while another requires inventory clearance, the conflict detection module prevents concurrent execution based on anomaly priority, data version, scope of impact, and action mutual exclusion rules, and requests joint approval or re-optimization. For consecutive anomalies, the system can aggregate multiple adjacent time windows into a single master anomaly object and treat each action as a sub-event.

[0056] Preferably, if subsequent inventory checks or data repair prove that the anomaly originated from data synchronization failure, encoding mapping errors, or inventory errors, the system will mark the anomaly as a false alarm, recording the error source and the affected data batch. Action results associated with false alarms must not be included in the action effect model as valid training samples. Corresponding data quality events can be fed back to the data alignment and quality assessment module, reducing the quality score of the same source in subsequent windows.

[0057] Preferably, sensitive operational data within abnormal objects can be isolated by enterprise, region, and role. Approver can only view stores and products within their authorized scope. Status transitions, rule versions, model versions, data versions, and API calls are all written into unmodifiable or traceable audit logs. For high-risk actions, dual approval, dynamic passwords, or electronic signatures can be required. For automated actions, limits can be set on single-action amount, daily frequency, scope of impact, and reversibility; exceeding these limits automatically downgrades to manual approval.

[0058] Example 2 Based on the same concept, the complete processing flow of the present invention includes the following steps.

[0059] Step S1: Multi-source data collection and caliber alignment. Collect transaction, inventory, in-transit, batch, product, promotion, task management, and permission data from multiple business systems such as POS, ERP, inventory, supply chain, product, promotion, task, and permission. Align execution time, coding, and indicator caliber to form a reproducible data snapshot with version and lineage information.

[0060] Step S2: Evidence Quality Calculation and Data Version Generation. Scores are calculated for each of the evidence quality dimensions stipulated in the evidence contract, including completeness, freshness, consistency, granularity suitability, and traceability. A comprehensive evidence quality score is then calculated based on the weights. Data lineage is recorded, and data versions are generated for key fields, time windows, and collection batches.

[0061] Step S3: Anomaly Detection, Diagnosis, and Object Creation. Anomalies are detected, anomaly fingerprints, impact estimates, candidate causes, and supporting or refuting evidence are generated, and globally unique anomaly objects are created.

[0062] Step S4: Bind the evidence contract and the effect contract. Generate evidence contracts and effect contracts for the anomalous objects. The effect contract determines the target indicator, guardrail indicator, indicator direction, baseline method, verification time window, minimum sample size, and effect threshold before the action is executed, so that subsequent verification is not a temporary selection of favorable indicators.

[0063] Step S5, Action Generation and Gating. Based on the overall evidence quality and action risk, determine the output verification task, risk warning, action draft, or executable action; for actions requiring manual approval, generate an approval request including an evidence summary and expected effects.

[0064] Step S6, Pre-execution Re-verification. After approval and before write-back, re-acquire the current data and compare the data version, abnormal fingerprint, and action applicable envelope between the approval and execution times. If re-verification fails, invalidate the approval and recalculate.

[0065] Step S7: Idempotently write back and obtain execution receipt. Write the action that passes re-verification into the target system or send it to the store terminal, using idempotent keys to prevent duplicate execution, and record the acceptance and completion receipts as well as the actual action parameters.

[0066] Step S8: Construct a dynamic control and calculate the effect score. Obtain the actual indicators and guardrail indicators within the preset window, construct dynamic control values, calculate the standardized effect score, and output "improved," "not improved," "uncertain," or "false alarm."

[0067] Step S9, dual-channel feedback. The approver's actions are written into the decision feedback dataset, and the effect results that meet the reliability conditions are written into the verification result dataset. The suggestion presentation or ranking model and the action effect or strategy selection model are updated respectively.

[0068] In this embodiment, for ease of explanation, the following symbols are defined: Index for exception objects; Indexed for the dimension of evidence quality. ; The number of evidence quality dimensions is preferably 5, and the configuration can include completeness, freshness, consistency, granularity, and traceability. Index for candidate actions; For action risk factor index, ; For performance metrics index, ; Exception object In the The scores for each dimension of evidence quality are configured by normalization of missing rate, latency, discrepancy rate, etc. For the first The weights of each dimension of evidence quality, and The value range is positive and the sum is 1. The configuration method is to configure according to the exception type and the product type. Exception object The comprehensive evidence quality score configuration method is calculated by equation (1); Exception object candidate actions In the The normalized value on each risk factor, i.e. the risk value of a single action, is configured by normalizing business parameters. For the first The action risk weights of each risk factor, and The configuration method is configured by the enterprise's risk strategy; Candidate actions The comprehensive risk score is calculated using equation (2); The minimum evidence quality threshold required to allow the generation of executable actions is preferably set to 0.80, and can be configured to increase or decrease based on the risk of the action. The maximum action risk threshold allowed for the corresponding approval level is preferably set to 0.50, and the configuration method is to configure it separately for pre-authorization, single-level or multi-level approval; Exception object The data version at the time of approval can be a hash, a serial number, or a composite version, and can be configured to be generated from key data, batches, and windows. Exception object The data version used during pre-verification can be a hash, a serial number, or a composite version, configured to be regenerated during reverification. Index the key status fields. ; , Exception object The The values ​​of key status fields during approval and pre-execution re-verification; For the first The standardized scale for each key status field can be configured by field dimension, historical fluctuation, or business scale. Candidate actions For the first The maximum normalization deviation allowed for each key status field is configured to be fixed by action type and key field during approval. The standardized deviation of the state before execution relative to the state at the time of approval; Exception object candidate actions The action applies to the envelope; The minimum observation sample threshold required for effect determination, i.e. the minimum number of transactions or days allowed for effect determination, is preferably 30 transactions or 30 days, and the configuration method is configured by the effect contract according to volatility and reliability requirements; To verify the first in the window The actual observed value of each indicator, i.e. the actual observed indicator, takes the original dimension of the indicator and is configured to be calculated within the verification window. For the first The dynamic counterfactual or comparative value of each indicator, i.e., the dynamic comparative indicator, has the same unit as the actual value and is configured as historical, similar store or model generated. For the first The desired direction of each indicator is to take the highest possible value. When the value is as low as possible, take For stockout rate and loss rate, take -1; for sales volume, etc., take 1. For the first The uncertainty or standardization scale for each indicator can be the historical standard deviation, prediction error or business scale. For the first The weight of each performance metric, and That is, the weighting of performance indicators and the configuration of the importance of targets and guardrails; To prevent stable terms with a denominator of zero, i.e., numerically stable terms, the preferred value is... To prevent the denominator from being zero; Exception object The overall effect score of the corresponding action is a real number and is calculated by formula (4); This is an invalid threshold; a value of 0.00 is preferred. As an effective threshold, a value of 0.80 is preferred, satisfying the following conditions. ; The number of action risk factors is preferably between 4 and 8, and the configuration can include amount, scope, reversibility, cross-regional, etc. The number of performance indicators is preferably between 1 and 6, and the configuration method is fixed in advance by the performance contract.

[0069] The overall evidence quality score is calculated according to formula (1):

[0070] The action risk score is calculated according to formula (2):

[0071] The permissible deviation of the state before execution is calculated according to formula (3):

[0072] When all key status fields are satisfied If the current state still meets all hard constraints such as safety stock, store capacity, remaining shelf life, permission status, and conflicting tasks, then a decision is made. If the original approval remains valid, then the original approval becomes invalid and the candidate actions are recalculated based on the latest status. Only if... , Candidate actions can only enter the write-back stage after the required approvals have been completed and the data version and action applicability envelope have been re-verified and confirmed to be valid before execution. Data version validity does not require identical binary hashes; the system can compare the changes in key fields with the allowable deviation of the action. Furthermore, if the critical changes exceed the permissible deviation, the approval will be invalid.

[0073] The overall performance score is calculated according to formula (4):

[0074] when And when the guardrail index does not exceed the deterioration threshold, the result is marked as improved; when When, the result is marked as no improvement; when If the minimum sample size is insufficient, the result is marked as uncertain. For critical cases, counterfactual confidence intervals, the number of conflicting interventions, or the quality of store data can be used as additional criteria. Invalid threshold. Effective threshold Minimum Sample Both the validation window and the validation window are configurable parameters, but they must be fixed by the effect contract before the action is executed. Their values ​​can be calibrated based on historical validation samples, volatility levels, confidence requirements, or business tolerance for the same action type and indicator combination; the same effect contract version remains unchanged during validation.

[0075] Example 3 Based on Examples 1 and 2, this example provides an implementation plan for stockout risk and replenishment: A certain region comprises 120 stores. Before the daily morning operations meeting, the system collects data on store A's product P, including its sales volume over the past 28 days, current available inventory, in-transit quantity, replenishment cycle, promotional plans, and data from other stores in the same region. The anomaly detection and diagnosis module, based on this data, determines if the probability of stockouts exceeding a preset threshold within the next two days, creates an anomaly object, and labels the anomaly as "stockout risk."

[0076] The data alignment and quality assessment module calculates the scores for the five dimensions of evidence quality as 0.95, 0.90, 0.85, 0.90, and 0.80, respectively, with corresponding weights of 0.25, 0.20, 0.20, 0.20, and 0.15. From equation (1), we obtain:

[0077] set up The anomaly meets the action evidence threshold. The system generates replenishment candidate actions. The risk values ​​for the action's amount, scope, reversibility, and cross-regional extent are 0.40, 0.20, 0.30, and 0.50, respectively, with risk weights of 0.35, 0.25, 0.20, and 0.20, respectively. From equation (2), we obtain:

[0078] Set up single-level approval ,because If so, the action will proceed to the regional manager's approval. During the approval process, the system records the data version at the time of approval. Recommended replenishment quantity, reasons and evidence, and three-day effect window.

[0079] After regional manager approval, the pre-execution re-verification module re-acquires the current inventory and in-transit quantity. If the store happens to receive a batch of in-transit goods, causing the projected inventory to exceed the action's applicable envelope (e.g., exceeding the store's capacity limit), the data version at execution will be changed. and If the critical difference exceeds the allowable range, the original approval becomes invalid, the system does not write the replenishment order and recalculates. If the status does not change substantially, the system generates an idempotent key with an exception identifier and an action identifier, writes the replenishment request to the ERP system, and saves the ERP acceptance number and the actual replenishment quantity.

[0080] After the action is completed, the dynamic effect verification module verifies the stockout rate, loss rate, and sales volume. The actual observed values, dynamic control values, standardized scale, expected direction, and weights of the three indicators are shown in Table 1 below: Table 1

[0081] From equation (4), we get:

[0082] Set invalid threshold , effective threshold Furthermore, indicators such as inventory backlog have not worsened. Because... Anomalies are moved from the pending verification state to the improved state. The verification result is added to the verification result feedback dataset to update the action effect model. The regional manager's approval behavior is added to the decision feedback dataset to optimize suggestion presentation and ranking; the two are not merged into the same label.

[0083] Example 4 Based on Embodiment 1 and Embodiment 2, this embodiment provides an example of near-expiration loss and allocation: The system identified a near-expiration risk for fresh food item Q in store B. Data alignment and quality assessment revealed that the ERP system only had total inventory data but lacked batch expiration date data. Due to a low score in the granularity fit dimension, the overall evidence quality score was lowered. The action execution threshold has not been reached. In this case, the system will not generate a transfer action that can be executed directly, but will only generate a store task to verify the batch and expiration date, which will be automatically downgraded to a data verification task.

[0084] After a store submits a batch inventory receipt, the system recalculates the evidence quality. At this point, the batch validity period field is complete, the granularity fit score improves, and the overall evidence quality score reaches the execution threshold. The system generates candidate actions for transferring goods from store B to store C. The applicable envelope for this transfer action must include at least the following: store B retains safety stock after the transfer, store C has anticipated demand within the validity period, the transportation time is less than a set percentage of the remaining shelf life, and the transfer cost is lower than expected to avoid losses.

[0085] After regional manager approval, the pre-execution re-verification module re-collects the current status. If store C's inventory has been replenished by other tasks, the pre-execution re-verification detects conflicting tasks and changes in target inventory, causing the current status to exceed the action's applicable envelope. The original approval becomes invalid, and the system returns to the pending confirmation state, saving the reason for the invalidation. If the re-verification passes, the system generates a transfer order in an idempotent manner and simultaneously verifies the decrease in store B's loss rate and the change in store C's sell-through rate upon completion. This avoids situations where only the loss rate of the transferring store is reduced, but new inventory buildup is created in the receiving store.

[0086] Example 5 Based on Examples 1 and 2, this example provides an implementation plan for abnormal sales and display adjustments: The system detected that the sales volume of product R in store D was significantly lower than that of similar stores, but inventory, pricing, and promotions were performed normally. The anomaly detection and diagnosis module generated candidate causes pointing to display location or missing price tags. Since display adjustments are reversible and have low risk, the system generated a store task after the evidence quality reached a certain threshold.

[0087] After a store uploads its display adjustment task confirmation, the dynamic effect verification module constructs a comparison group using similar stores that did not implement adjustments and the historical same-week trend of store D. The comparison value is generated by combining a weighted index of similar stores with extrapolated values ​​from the historical trend of the same store.

[0088] If store D's sales recover, but all stores in the same area see a simultaneous increase due to improved weather, the combined control value will also increase accordingly. In this case, the standardized difference between the actual and control indicators will not be overestimated solely by the increased sales after the adjustment, thus avoiding misinterpreting changes caused by external factors as the effect of the display adjustment. If the observation sample is insufficient (not reaching the minimum observation sample size)... Instead of immediately marking the action as valid, the system marks the result as uncertain and extends the verification window.

[0089] Example 6 This embodiment also provides an electronic device, see reference. Figure 2 It includes a memory 402 and a processor 401, wherein the memory 402 stores a computer program and the processor 401 is configured to run the computer program to perform the steps in any of the above method embodiments.

[0090] Specifically, the processor 401 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of the present invention.

[0091] The memory 402 may include a mass storage device for data or instructions. For example, and not limitingly, the memory 402 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 402 may include removable or non-removable (or fixed) media. Where appropriate, the memory 402 may be internal or external to a data processing device. In a particular embodiment, the memory 402 is non-volatile memory. In a particular embodiment, the memory 402 includes read-only memory (ROM) and random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable read-only memory (PROM), an erasable read-only memory (EPROM), an electrically erasable read-only memory (EEPROM), an electrically alterable read-only memory (EAROM), or flash memory, or a combination of two or more of these. Where appropriate, the RAM can be Static Random-Access Memory (SRAM) or Dynamic Random-Access Memory (DRAM). DRAM can be Fast Page Mode Dynamic Random Access Memory (FPMDRAM), Extended Data Out Dynamic Random Access Memory (EDODRAM), Synchronous Dynamic Random-Access Memory (SDRAM), etc.

[0092] The memory 402 can be used to store or cache various data files that need to be processed and / or communicated, as well as possible computer program instructions executed by the processor 401.

[0093] The processor 401 reads and executes computer program instructions stored in the memory 402 to implement any of the chain store operation anomaly closed-loop processing methods based on evidence contracts and dynamic effect verification in the above embodiments.

[0094] Optionally, the electronic device may further include a transmission device 403 and an input / output device 404, wherein the transmission device 403 is connected to the processor 401 and the input / output device 404 is connected to the processor 401.

[0095] The transmission device 403 can be used to receive or send data via a network. Specific examples of the network described above may include wired or wireless networks provided by the communication provider of the electronic device. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 403 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0096] Input / output device 404 is used for inputting or outputting information. It can be a speaker, microphone, monitor, or keyboard.

[0097] Example 7 This embodiment also provides a readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the chain store operation anomaly closed-loop processing method based on evidence contract and dynamic effect verification as described in Embodiment 1.

[0098] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0099] Generally, various embodiments can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects of the invention can be implemented in hardware, while others can be implemented by firmware or software executed by a controller, microprocessor, or other computing device, but the invention is not limited thereto. Although various aspects of the invention may be shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, by way of non-limiting example, these blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0100] Embodiments of the present invention can be implemented by computer software, which may be executable by a data processor of a mobile device, such as a processor entity, or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products) including software routines, applets, and / or macros can be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. The computer program product may include one or more computer-executable components configured to perform the embodiments when the program is run. The one or more computer-executable components may be at least one piece of software code or a portion thereof. Additionally, it should be noted in this respect that, as Figure 1 Any box in the logical flow can represent a program step, or interconnected logic circuits, boxes and functions, or a combination of program steps and logic circuits, boxes and functions. Software can be stored on physical media such as memory chips or blocks of storage implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as DVDs and their data variants, CDs, etc. The physical medium is a non-transient medium.

[0101] The present invention can also be implemented in the following optional ways, which can be used alone or in combination: 1. Data version can be a database snapshot number, event sequence number, key field hash, or a vector consisting of multiple source versions.

[0102] 2. Abnormal fingerprints can be generated using deterministic hashing, locality-sensitive hashing, or a combination of structured fields; similar fingerprints can be used to merge duplicate anomalies.

[0103] 3. Evidence quality scoring and action risk scoring can employ weighted summation, rule trees, probabilistic models, or learning models, but all should output definitive results and versions that can be used for gating.

[0104] 4. Dynamic comparisons can employ synthetic control, matched stores, causal forests, difference within difference, time series forecasting, or simple historical mean; for stores with insufficient data, they can be degraded to a regularized baseline.

[0105] 5. A state machine can be implemented using a workflow engine, event-driven services, or database constraints; the key is binding the state entry conditions to data version, permissions, receipts, and results.

[0106] 6. Actions can be performed fully manually, semi-automatically, or automatically. Regardless of the level of automation, the system saves the actual action parameters and execution receipts, and verifies the results according to the same effect contract.

[0107] 7. For consecutive anomalies, the system can aggregate multiple adjacent time windows into a single master anomaly object and treat each action as a sub-event; for anomalies caused by independent reasons, a new anomaly object is created.

[0108] This invention can be applied to food retail, catering, convenience stores, supermarkets, pharmacies, clothing, home furnishings, warehousing, and other multi-store operation scenarios. The technical essence of this invention lies in its unified, version-based, and verifiable control over data evidence, abnormal objects, action permissions, execution status, actual feedback, and results, without relying on specific enterprises, products, or business metrics.

[0109] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0110] The above embodiments are merely illustrative of several implementations of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of the present invention should be determined by the appended claims.

Claims

1. A closed-loop method for handling operational anomalies in chain stores based on evidence contracts and dynamic effect verification, characterized in that, Includes the following steps: Acquire multi-source operational data and generate data snapshots with version information; Based on the data snapshot, operational anomalies are identified, and anomaly objects are created that are bound with anomaly fingerprints, evidence contracts, and effect contracts. The output level of a candidate action is determined by combining the multidimensional evidence quality of the data snapshot with the risk of the candidate action, and the approval result is obtained after the approval is triggered. After the candidate action is approved and before it is written into the target business system, the current operating data is re-acquired for pre-execution re-verification. If the current operating data and the approval basis data do not meet the preset action applicability envelope, the original approval is invalidated and the process is returned for re-diagnosis. In response to the successful pre-execution re-verification, an action write-back request containing idempotent control information is sent to the target business system, and an execution receipt is obtained; In response to the execution receipt, target indicators and dynamic comparison indicators are collected within the verification window defined by the effect contract, a comprehensive effect score is calculated, and the closed-loop processing status of the abnormal object is updated based on the comprehensive effect score and the guardrail indicators. The approval decision records for the candidate actions and the operational performance records after effect verification are written into different feedback channels to update the action suggestion ranking model and the action effect prediction model respectively.

2. The method as described in claim 1, characterized in that, The evidence contract refers to a set of machine-verifiable conditions bound to the abnormal object and its data version, used to determine whether the abnormal object can enter the subsequent action stage. It includes at least the necessary data source and fields, maximum refresh delay, cross-source consistency tolerance, minimum data granularity, data version and abnormal fingerprint generation rules, action gating threshold, and downgrade actions when evidence is insufficient.

3. The method as described in claim 1, characterized in that, The multidimensional evidence quality includes at least two of the following: completeness, freshness, consistency, granularity adaptability, and traceability; a comprehensive evidence quality score is calculated based on the multidimensional evidence quality; when the comprehensive evidence quality score is lower than a preset action execution threshold, the candidate action is automatically downgraded to a data verification or supplementary collection task.

4. The method as described in claim 1, characterized in that, The action applies to the envelope including allowable deviations for key fields and insurmountable hard business constraints. The hard business constraints include at least one of safety stock, store capacity, remaining shelf life, permission status, and conflicting tasks, and are not exempted by the allowable deviations. The pre-execution re-verification includes: collecting current operating data and generating the data version at execution time and the current anomaly fingerprint; When the deviation of the key field from the approval exceeds the allowable deviation, the current abnormal fingerprint disappears or the intensity change exceeds the set range, or the business hard constraint is triggered, the original approval is deemed invalid.

5. The method as described in claim 1, characterized in that, The effect contract pre-fixes the target indicator, guardrail indicator, indicator direction, comparison generation method, verification window, minimum sample size, effective threshold, invalid threshold, and uncertainty handling rules before the candidate action is executed, and cannot be changed afterwards during the verification of the same contract version; the dynamic comparison indicator is generated by at least one of the following: the predicted value of the same store's historical comparable period, the weighted indicator of similar stores or similar product groups that have not executed the candidate action, the value generated by the prediction model combined with external environmental factors, and the trend extrapolation value before the action.

6. The method as described in claim 1, characterized in that, The closed-loop processing status of the abnormal object is updated based on the comprehensive effect score and the guardrail index, including: When the overall effect score reaches the effective threshold and the guardrail index does not deteriorate, the closed-loop processing status of the abnormal object is updated to "improved". When the overall effect score is lower than the invalid threshold, the closed-loop processing status of the abnormal object is updated to "not improved" and it re-enters the diagnosis process. When the overall effect score is between the invalid threshold and the valid threshold or when there are insufficient observation samples, the closed-loop processing status of the abnormal object is updated to uncertain, and the verification window is extended or manual review is triggered.

7. The method as described in claim 1, characterized in that, Writing the approval decision records for the candidate actions and the operational performance records after effect verification into different feedback channels includes: writing the approval decision records into the decision feedback dataset for optimizing the front-end interface display and suggested sorting; and writing the operational performance records into the verification result dataset only when the preset minimum sample size, evidence quality, and result certainty conditions are met, for updating the action effect model or strategy selection model.

8. A closed-loop processing device for chain store operation anomalies based on evidence contracts and dynamic effect verification, characterized in that, include: The data acquisition and quality assessment module is used to acquire multi-source operational data and generate data snapshots with version information to assess the quality of multi-dimensional evidence. The anomaly detection and diagnosis module is used to identify operational anomalies based on the data snapshot, and generate anomaly fingerprints, candidate causes, and supporting or refuting evidence. The Evidence Contract and Effect Contract module is used to generate an evidence contract and an effect contract bound to the abnormal object. The evidence contract defines the machine-verifiable conditions that the abnormal object must meet to enter the subsequent action stage, and the effect contract fixes the effect verification rules before the candidate action is executed. An exception object library and state machine are used to store exception objects with globally unique identifiers and manage their state transitions. The exception objects are associated with at least a store or product identifier, an indicator time window, a data version, an exception fingerprint, an evidence contract, a candidate action, an effect contract, and an audit event. The state transitions have machine-verifiable entry conditions. The action generation and risk gating module is used to determine the output level of the candidate action by combining the quality of the multidimensional evidence and the risk of the candidate action, and to obtain the approval result after the approval is triggered. The pre-execution re-verification module is used to re-acquire the current operating data for pre-execution re-verification after the candidate action is approved and before it is written into the target business system. If the current operating data and the approval basis data do not meet the preset action application envelope, the original approval is invalidated and the process is returned for re-diagnosis. The idempotent write-back module is used to send an action write-back request containing idempotent control information to the target business system when the pre-execution re-verification passes, and to obtain the execution receipt. The dynamic effect verification module is used to respond to the execution receipt, collect target indicators and dynamic comparison indicators within the verification window defined by the effect contract, calculate the comprehensive effect score, and update the closed-loop processing status of the abnormal object according to the comprehensive effect score and the guardrail indicators. The dual-channel feedback update module is used to write the approval decision records for the candidate actions and the operational performance records after effect verification into different feedback channels, so as to update the action suggestion ranking model and the action effect prediction model respectively.

9. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to execute the chain store operation anomaly closed-loop processing method based on evidence contract and dynamic effect verification as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the chain store operation anomaly closed-loop processing method based on evidence contracts and dynamic effect verification as described in any one of claims 1 to 7.

Images