Food safety sampling inspection data verification method and system and computer storage medium thereof

Abstract

The invention discloses a food safety sampling inspection data verification method and system and a computer storage medium thereof, particularly relates to the technical field of food safety supervision informatization, and is used for solving the problem of false consistency caused by silent failure when an external data source fails in an existing verification system. Field-level binding is realized by establishing a dependency mapping table of a sampling inspection system and an external data source; constructing a service response causal graph model, and dynamically marking a failure data source based on the deviation between the anti-fact response and the actual response; analyzing the verification field set and positioning a key verification field; degrading the weight of the key field to be below a threshold value and activating a manual auditing flag bit; scanning a preset coupling relationship between fields, freezing associated fields which do not trigger rules, verifying and constructing a conflict topology; when the check engine is executed, dynamically skipping the weight reduction field, suspending the freezing field, and generating a to-be-rechecked report in combination with the artificial flag bit and the topological graph; error data transmission is blocked from the source, and the food safety risk missed judgment rate is remarkably reduced.

Description

Technical Field

[0001] The present invention relates to the field of food safety supervision information technology, and more specifically, to a food safety sampling data verification method, system and computer storage medium thereof. Background Art

[0002] In the field of food safety supervision, random inspection data verification relies on the coordinated operation of multiple heterogeneous systems. Existing technologies typically interact with production license databases, corporate credit databases, and standard and regulatory databases. These systems implement logical verification of key fields such as test results and corporate qualifications using pre-set rules. These systems employ a modular design, with each database operating independently and accessing data through interface protocols. When external dependent systems (such as the production license database) fail, default value padding is commonly used to ensure data integrity and prevent global verification interruptions due to single points of failure.

[0003] The existing verification method has the following defects: when the key dependent system fails, the verification process is unable to perceive the health status of the external data source, and still outputs the conclusion that the logical verification has passed based on the default value, resulting in silent failure. This causes the cross-system data verification results to show false consistency, the erroneous data is not effectively intercepted, and there is no alarm mechanism. In the food safety sampling scenario, it will directly lead to the omission of major risks such as unlicensed production enterprises and substandard food. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, the present invention provides a food safety sampling data verification method, system and computer storage medium thereof to solve the problems raised in the above-mentioned background technology.

[0005] To achieve the above object, the present invention provides the following technical solutions: Food safety sampling data verification methods include: S1. Establish a dependency mapping table between the sampling inspection system and the external data source. The dependency mapping table records the binding relationship between each check field and the corresponding external data source; S2. Build a service response causal graph model, inject virtual intervention parameters into the external data source and generate a counterfactual ideal response. When the KL divergence value between the actual response and the counterfactual ideal response exceeds the preset causal deviation threshold, mark the external data source as invalid. S3. Parse the check field set of the current sampling data and identify the key check fields bound to the external data source in the failed state based on the dependency mapping table; S4. Downgrade the check weight of the key check field to below the preset threshold, and activate the manual review flag; S5. Scan the preset coupling relationship set between the key check fields and the non-degraded check fields. If there is an untriggered coupling rule, freeze the logical verification of the associated check fields corresponding to the coupling rule and mark the conflicting topology. S6. When executing the verification rule engine, skip the logic verification for the key verification fields that have been demoted, suspend the logic verification for the frozen related fields, and generate a verification report to be reviewed based on the manual review flag and conflict topology.

[0006] Furthermore, S1 includes: Obtain the unique identifiers of all verification fields in the sampling inspection system and their corresponding external data source network access addresses; According to the food safety data verification rules, determine the field type attributes of each verification field. The field type attributes include enterprise qualification, testing standard, and product identification. Generate a structured storage dependency mapping table, in which each mapping record contains the unique identifier of the verification field, the bound external data source network access address and the field type attribute, and the dependency mapping table establishes an index association with the sampling data field through the unique identifier of the verification field.

[0007] Furthermore, S2 includes: Construct a Bayesian network structure as a service response causal graph model based on historical service log data; Using the service response causal graph model, a test request carrying virtual intervention parameters is sent to the target external data source. The virtual intervention parameters include a simulated request volume multiplier and a forced timeout threshold. Receive actual response data returned by the target external data source in response to the test request; Calculate counterfactual ideal response data under virtual intervention parameters through the service response causal graph model; Calculate the KL divergence value between the probability distribution of the actual response data and the counterfactual ideal response data; When the KL divergence value between probability distributions exceeds the preset causal deviation threshold, an external data source failure status marking signal is generated.

[0008] Furthermore, the Bayesian network structure includes a request amount node, a response delay node, and an error code node of the external data source.

[0009] Furthermore, S3 includes: Parse the validation field set of the current sampling data and identify the key validation fields bound to the external data source in the invalid state based on the dependency mapping table, including: Extract the unique identifier of the verification field to be verified in the current sampling data record; Query the external data source network access address corresponding to the unique identifier of the check field in the dependency mapping table; receiving an external data source failure status marking signal, wherein the external data source failure status marking signal includes a failed external data source network access address; Matching the queried external data source network access address with the invalid external data source network access address; When the external data source network access address is matched successfully, the corresponding check field unique identifier is marked as a key check field.

[0010] Furthermore, S4 includes: Get the initial check weight value configured in the check rule engine corresponding to the key check field; Determine differentiated degradation strategies based on the field type attributes bound to key verification fields. Field type attributes include enterprise qualification, testing standard, and product identification. Applying a differentiated degradation strategy to adjust the initial verification weight value to below the preset weight threshold, and generating a degraded verification weight value; Create a manual review flag in the metadata of the random inspection data verification task and set the manual review flag status to active.

[0011] Furthermore, S5 includes: Load the predefined coupling relationship configuration library, which stores the logical dependency rules between key check fields and non-degraded check fields; Traverse the combination instances of key check fields and non-degraded check fields in the current sampling data; Check whether the logical dependency rules corresponding to the combination instance meet the trigger conditions; When there are untriggered logical dependency rules, the logical verification status of the associated verification fields corresponding to the corresponding logical dependency rules is frozen in the metadata of the spot check data verification task; A conflict topology graph is constructed based on untriggered logical dependency rules, and the conflict topology graph records the failure dependency paths of associated check fields and key check fields.

[0012] Furthermore, S6 includes: Start the verification rule engine to verify the current sampling data; During the verification process, the logic verification operation is skipped for the key verification fields that have been downgraded; Suspend the logic verification operation for the frozen associated check fields during the check process; Read the activation status of the manual review flag and the failure dependency path recorded in the conflict topology map; A verification report to be reviewed is generated by combining the activation status of the manual review flag, the conflict topology diagram, and the list of unverified fields.

[0013] In another aspect, the present invention provides a food safety sampling data verification system, comprising: The dependency mapping module is used to establish a dependency mapping table between the sampling inspection system and the external data source. The dependency mapping table records the binding relationship between each check field and the corresponding external data source; The causal analysis module is used to build a service response causal graph model, inject virtual intervention parameters into the external data source and generate counterfactual ideal responses. When the KL divergence value between the actual response and the counterfactual ideal response exceeds the preset causal deviation threshold, the external data source is marked as invalid. The failure transmission module is used to parse the check field set of the current sampling data and identify the key check fields bound to the external data source with failure status based on the dependency mapping table; The weight control module is used to reduce the verification weight of key verification fields to below the preset threshold and activate the manual review flag at the same time; The coupling and decoupling module is used to scan the preset coupling relationship set between key check fields and non-degraded check fields. If there are any untriggered coupling rules, the logical verification of the associated check fields corresponding to the coupling rules is frozen and the conflicting topology is marked. The collaborative execution module is used to skip the logic verification of the key verification fields after the demotion when executing the verification rule engine, suspend the logic verification of the frozen related fields, and generate a verification report to be reviewed based on the manual review flag and conflict topology.

[0014] On the other hand, the present invention provides a computer storage medium, which stores a program or instruction. When the program or instruction is executed by a processor, a food safety sampling data verification method is implemented.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. The dependency mapping table and causal analysis model work together to proactively diagnose failures in external data sources. Unlike traditional passive default value filling, this system marks failure states in real time based on counterfactual response differences and accurately locates affected key validation fields through dependency mapping. This allows the system to immediately initiate weight downgrades and activate manual review flags when external anomalies occur, preventing erroneous data from entering subsequent validation processes and intercepting false consistency risks at the source.

[0016] 2. The coupling rule library and conflict topology construction solve the secondary logical conflict problem caused by weight degradation. By scanning for untriggered coupling rules, freezing associated fields to verify and mark dependent paths, and blocking the failure transmission chain, the collaborative execution engine dynamically skips the downgraded fields, suspends the freezing of fields, and automatically integrates the topology map to generate a report to be reviewed, forming a closed-loop control of failure perception - precise degradation - conflict isolation - targeted review. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flow chart of the food safety sampling data verification method of the present invention; Figure 2 It is a structural diagram of the food safety sampling data verification system of the present invention. DETAILED DESCRIPTION

[0018] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0019] Example 1: Figure 1 The present invention provides a food safety sampling data verification method, comprising: S1. Establish a dependency mapping table between the sampling inspection system and the external data source. The dependency mapping table records the binding relationship between each check field and the corresponding external data source; S2. Build a service response causal graph model, inject virtual intervention parameters into the external data source and generate a counterfactual ideal response. When the KL divergence value between the actual response and the counterfactual ideal response exceeds the preset causal deviation threshold, mark the external data source as invalid. S3. Parse the check field set of the current sampling data and identify the key check fields bound to the external data source in the failed state based on the dependency mapping table; S4. Downgrade the check weight of the key check field to below the preset threshold, and activate the manual review flag; S5. Scan the preset coupling relationship set between the key check fields and the non-degraded check fields. If there is an untriggered coupling rule, freeze the logical verification of the associated check fields corresponding to the coupling rule and mark the conflicting topology. S6. When executing the verification rule engine, skip the logic verification for the key verification fields that have been demoted, suspend the logic verification for the frozen related fields, and generate a verification report to be reviewed based on the manual review flag and conflict topology.

[0020] S1. Establish a dependency mapping table between the sampling inspection system and the external data source. The dependency mapping table records the binding relationship between each check field and the corresponding external data source. The specific implementation is as follows: When establishing a dependency mapping table between the sampling inspection system and external data sources, the generation of a unique identifier for the checkpoint field is achieved through a preset field identification algorithm. This algorithm's input parameters are a string representing the name of the database table to which the field belongs, a string representing the field name, and the date and time value of the field's creation timestamp. These three input parameters are concatenated in a fixed order: the database table name first, the field name in the middle, and the timestamp last, to form a combined string. This combined string is then input into a SHA-512 hash function that complies with the RFC 6234 standard for a one-way encryption operation. The resulting output is a 128-bit hexadecimal-formatted string that serves as the unique identifier. The hash operation is implemented by calling the operating system's built-in cryptographic service module. For example, in a Linux environment, the SHA512_Update function of the OpenSSL library is used to ensure that a specific and unique identification string is generated for each field globally within the sampling inspection system. The network access address of the external data source is obtained by parsing the address configuration template preset by the system. The template is stored in a JSON format text file and contains the standard application programming interface access path and identity authentication parameters corresponding to each verification field. The access path is generated according to the interface specification document published by the external data source service provider. For example, the path template for the enterprise qualification field contains the complete uniform resource locator of the "unified social credit code" path parameter placeholder.

[0021] The determination of field type attributes is based on the field function definition declared in the food safety data verification rules. The rule parser loads the built-in rule configuration file of the sampling inspection system and identifies the characteristic description statements about field classification in the configuration file through text pattern matching technology. The specific processing flow includes: when characteristic keywords such as "enterprise license" or "registration information" appear in the configuration text, the associated field is classified as the enterprise qualification category; when characteristic keywords such as "limit index" or "safety threshold" appear, it is classified as the testing standard category; when characteristic keywords such as "product traceability" or "batch identification" appear, it is classified as the product identification category. The classification results are written into the field metadata attribute table, and the attribute values are stored as integer values. 0 is set to correspond to the enterprise qualification category, 1 to the testing standard category, and 2 to the product identification category. This integer value is used as the fixed field value of the dependency mapping table.

[0022] The generation of dependency mapping tables is implemented using a relational database table structure. A database table named Data Dependency Mapping Table is created, which contains three core fields: the field used to store the unique identifier of the check field is defined as a fixed-length character type with a fixed length of 128 characters; the field used to store the network access address of the external data source is defined as a variable-length string type with a maximum of 255 characters allowed; the field used to store field type attributes is defined as a single-byte integer type. The index association mechanism is implemented by creating a balanced tree structure index in the field that stores the unique identifier of the check field. The index key is the binary encoding sequence of the field value. When the sampling inspection system accesses the data table field, the field name and table name combination parameters are submitted through the database connection interface. After the 128-bit string is generated by the same hash algorithm, an exact match query is performed in the index to locate the corresponding mapping record.

[0023] The mapping table maintenance mechanism includes a dynamic update process. When processing new fields, an identifier generation algorithm is called to create a field value for the unique identifier of the checksum field. At the same time, the address configuration template is read to generate the field value of the external data source network access address. The rule parsing process is initiated to determine the field type attribute value, and finally a new record is inserted into the data dependency mapping table. When processing address updates, the administrator updates the uniform resource locator in the configuration template. The system scans the field storing the external data source network access address for records containing the old address and batch updates it to the new address in the template through database transactions. For capacity management, the initial tablespace is allocated to 100 megabytes. When the number of records reaches, for example, 500,000, a shard table is automatically created. The shard table is named using the original table name plus an underscore and a partition number. The partitioning strategy uses the remainder of the ASCII code value of the first character of the field storing the unique identifier of the checksum field divided by 10 as the partitioning basis. Data consistency is ensured using a two-phase commit protocol to achieve multi-replica synchronization. The master database generates a pre-commit log before executing the update operation. The slave database returns a ready signal after confirming the log integrity. The master database sends a formal commit instruction after receiving confirmation from all slave databases.

[0024] Version control of field type attributes is achieved by adding an effective timestamp field. Two date and time type fields, the start effective time and the end effective time, are added to the data dependency mapping table. When the food safety rules are updated: a new version record is generated for the affected field, all field values of the original record are copied, the field type attribute field is updated to a new integer value, the start effective time is set to the rule effective date, and the end effective time is set to the maximum date value; the end effective time of the original record is modified to the rule effective date minus 1 day. When querying, the records whose current date is within the start effective time and end effective time range are used by default to achieve multi-version coexistence and smooth switching.

[0025] The availability of the external data source's network access address is verified using an active probing mechanism, with a frequency set to perform a full probe every 24 hours. The probing method involves sending a Hypertext Transfer Protocol (HTTP) HEAD request to the field storing the external data source's network access address. Timeout settings include, for example, a 3-second connection timeout and a 5-second response timeout. The result determination logic sets a 200 HTTP status code for three consecutive probes as normal; otherwise, it is marked as abnormal. Abnormal records are marked with a status flag in the mapping table. Abnormal address records are preferentially skipped during random system queries, triggering the alarm process.

[0026] The data persistence architecture comprises three levels of storage. Hot storage uses a MySQL cluster to store currently valid records, with millisecond response times. Warm storage utilizes a full-text search engine to store, for example, six-month historical version records, supporting multi-condition retrieval. Cold storage utilizes a distributed file system to store archived records, partitioned by year and compressed. The data access layer encapsulates a unified query interface. The input parameters are two strings: the name of the validation field and the name of the table to which it belongs. The output is the network access address of the external data source corresponding to the field and the field type attribute value. Multi-level storage routing and caching are automatically handled internally.

[0027] S2. Build a service response causal graph model, inject virtual intervention parameters into the external data source and generate counterfactual ideal responses. When the KL divergence value between the actual response and the counterfactual ideal response exceeds the preset causal deviation threshold, mark the external data source as invalid. The specific implementation is as follows: When constructing a service response causal graph model, a Bayesian network structure is generated based on historical service log data. Historical service log data comes from the access record database of the sampling inspection system connected to an external data source. Each record contains a request timestamp accurate to the millisecond, a standardized request parameter string, a three-digit response status code, a response delay value in milliseconds, and a data feature summary value. The data preprocessing process performs the following operations: delete invalid records with missing or zero response delays; discretize the response delay values into bins at intervals of 100 milliseconds, for example, dividing 0 to 100 milliseconds into the first interval and 100 to 200 milliseconds into the second interval; map HTTP error codes to predefined categorical variables, for example, status codes 500 to 599 are mapped to server error types, and 400 to 499 are mapped to client error types. The Bayesian network structure is constructed using the PC algorithm. This algorithm determines inter-node dependencies by calculating the conditional independence of the request volume node, the response delay node, and the error code node. Directed edges are established when the mutual information between two nodes, given the conditions of other nodes, is greater than 0.3 bits, ultimately forming a directed acyclic graph (DAG) containing three nodes. Network parameter learning utilizes Bayesian estimation, calculating a conditional probability table for each node based on historical data frequency statistics. For example, the conditional probability of a response delay exceeding 500 milliseconds when the request volume node is under high load is determined.

[0028] When executing virtual interventions using the service response causal graph model, the virtual intervention parameters include two core parameters: a simulated request volume multiplier and a mandatory timeout threshold. The simulated request volume multiplier is generated by multiplying the current actual request volume by a specified factor. This factor is a floating-point number, for example, between 1.5 and 3.0, and is set by the system administrator based on the target external data source's service level agreement. The mandatory timeout threshold is set to the time point of response interruption, ranging from 100 milliseconds to 1000 milliseconds, and is determined based on the 90th percentile of historical normal response latency. Test requests are constructed according to the interface specifications published by the target external data source. A custom intervention marker field is inserted into the standard HTTP request header, and the virtual intervention parameter key-value pairs are loaded into the JSON-formatted request body. For example, the "intervention_factor" key corresponds to the multiplier, and the "timeout_threshold" key corresponds to the timeout threshold. Requests are sent synchronously, with the complete request message written after establishing a Transmission Control Protocol connection. The socket read timeout parameter is set to twice the mandatory timeout threshold.

[0029] The process of receiving the actual response data includes data parsing and feature extraction. The raw response data is read from the Transmission Control Protocol connection as a byte stream, and the status line, message header, and message body are parsed according to the Hypertext Transfer Protocol 1.1 specification. The feature vector construction of the actual response data includes three dimensions: the response delay feature value is the time difference from the completion of the request to the receipt of the last byte, accurate to milliseconds; the error code feature value is the parsed three-digit integer status code; and the data integrity feature value is the ratio of the actual byte length of the message body to the expected length. For example, a value of 0.85 indicates that 85% of the data volume is returned. The feature vector normalization process uses the minimum-maximum scaling method to linearly transform each feature value to the range of 0 to 1. The transformation formula is (current value - historical minimum value) / (historical maximum value - historical minimum value).

[0030] The calculation of counterfactual ideal response data is achieved by performing intervention reasoning on the service response causal graph model. In the Bayesian network, the request volume node is fixed to a discrete interval value corresponding to the simulated request volume multiplier value. The mandatory timeout threshold is input as conditional evidence into the response delay node. The posterior probability distribution of the error code node is calculated using a variable elimination algorithm. The feature vector of the counterfactual ideal response data is generated by performing the following steps: the response delay feature is the mathematical expectation value of the network output; the error code feature is the status code category corresponding to the maximum probability value in the probability mass function; and the data integrity feature is the arithmetic mean of historical normal response samples, which is maintained in the range of, for example, 0.95 to 1.05. The probability distribution is represented as a probability mass function of a discrete random variable, with each possible status code associated with a probability value. For example, the probability value of status code 200 is P1, and the probability value of status code 500 is P2.

[0031] The KL divergence between probability distributions is calculated using the Kullback-Leibler divergence formula for discrete probability distributions. The input parameters are the probability distribution P of the actual response feature vector transformation and the probability distribution Q of the counterfactual ideal response feature vector transformation. The P distribution is statistically derived from the actual response data, while the Q distribution is generated by Bayesian network inference. The calculation process performs the following steps: first, the union of the event spaces of the two distributions is determined. For each event i in the union, a conditional check is performed: if the probability of event i in the Q distribution is greater than 1 in a million, the probability of event i in the P distribution is multiplied by the base-2 logarithm of the ratio of the probability of event i in the P distribution to the probability of event i in the Q distribution. If the probability of event i in the Q distribution is less than or equal to 1 in a million, the event is skipped. The KL divergence value, expressed in bits, is obtained by summing the calculated results for all valid events. The calculation includes a smoothing mechanism that adds a small amount of 1 in a million to the probability of all events in the Q distribution to prevent division by zero errors.

[0032] The preset causal deviation threshold is set based on benchmark test data under historical normal service conditions. During the period when the external data source is confirmed to be working normally, intervention testing is carried out continuously for 30 days. Every day during the low-peak business period, 100 sets of KL divergence value samples of actual responses and counterfactual responses are collected. The 95% quantile of all sample values is taken as the initial threshold value, for example, 0.5 bits. The threshold dynamic adjustment mechanism includes recalculating the quantile when new test data is added each week; and performing a new round of 30-day benchmark testing when the external data source service version is upgraded. The logical judgment process for generating the external data source failure status marking signal is as follows: when the KL divergence value of a single test exceeds the current threshold, the anomaly counter is triggered to increase by 1; when three consecutive tests exceed the threshold, a failure marking signal is generated. The signal format is in the form of a binary flag bit, setting 1 to indicate failure status and 0 to indicate normal status. The flag bit is written to the external data source status registration database table and associated with the network access address field.

[0033] The update cycle of the service response causal graph model is set to a full rebuild every week. The reconstruction trigger conditions include two situations: when the average daily prediction error rate exceeds 10%; or when a change in the version number of the external data source interface is detected. The model verification adopts the holdout method, using 30% of the historical data as the test set, and calculating the root mean square error between the predicted response delay and the actual delay. When the error value exceeds the historical benchmark value by 20%, the model anomaly alarm is triggered. The model is persistently stored as a graph structure data file, the node attributes are serialized and stored in JSON format, and the edge relationships are stored in a compressed sparse row format matrix. The model version management adopts the timestamp naming rule, retaining the most recent ten versions to support historical backtracking.

[0034] S3. Parse the check field set of the current sampling data and identify the key check fields bound to the external data source in the failed state based on the dependency mapping table. The specific implementation is as follows: When parsing the check field set of the current sampling data, the unique identifier of the check field to be verified is extracted from the sampling data record. The sampling data record is stored in a structured data format, and the check fields are distributed in a fixed hierarchical position of the data object and are accessed through a predefined field location path. The extraction of the unique identifier of the check field performs the following operations: read the dedicated field in the data record that stores the metadata of the check field. This field contains a 128-character hexadecimal format string generated by a hash algorithm when the field is created; when the data record contains a nested structure, traverse all child objects in depth-first order and collect the identifiers of all fields marked as requiring verification; finally, form an ordered list of unique identifiers of the fields to be verified, and each element in the list is a complete 128-bit string.

[0035] When querying the external data source network access address corresponding to the unique identifier of the check field in the dependency mapping table, a batch query optimization strategy is adopted. After establishing a connection to the dependency mapping database, a parameterized query statement is constructed. The query statement template contains the list of unique identifiers of the check field as input parameters. Performance optimization is implemented during the query execution process: when the number of identifiers exceeds 50, it is automatically split into multiple sub-queries; duplicate identifiers are deduplicated; and the query response timeout threshold is set to 2000 milliseconds. The query results are returned in the form of key-value pairs, where the key is the unique identifier string of the check field and the value is the corresponding complete external data source network access address string. For example, the identifier string is mapped to a standard uniform resource locator containing the protocol, domain name, and path.

[0036] When receiving an invalid status marking signal from an external data source, reliable transmission is achieved through a distributed messaging system. The invalid status marking signal is encoded in a structured data format, and the message content includes a list of network access addresses of invalid external data sources and the timestamp of signal generation. Subscribe to the specified topic channel of the messaging system, configure the consumer instance to process the message stream, and trigger the parsing function when a new message arrives. The parsing function performs the following operations: decode the binary content of the message; extract the invalid address list field, which is a string array type; verify the validity of the timestamp, and ignore signals generated more than 30 minutes earlier than the current time. The parsed invalid address list is stored in a cache and set to a 60-second expiration time to ensure data timeliness.

[0037] When matching the queried external data source network access address with the invalid external data source network access address, a standardized string comparison is performed. The matching process performs the following steps: traverse each network access address in the list of addresses to be matched; perform normalization processing on each address, including converting to all lowercase, removing query parameters, and standardizing path separators; and perform an exact string comparison between the processed address and the elements in the invalid address list. The matching algorithm includes special case handling: when the address strings are exactly the same, the match is considered successful; when there is a difference in uppercase and lowercase letters in the addresses, they are considered different addresses; when the addresses contain a difference in the default port number, they are considered unmatched. The matching result generates a record set, each record contains a unique identifier for the check field and a match status indicator. The match status indicator is a Boolean value indicating whether the match is successful.

[0038] When the network access address of the external data source is successfully matched, the corresponding check field unique identifier is marked as a key check field. The marking operation creates a key field registry in the sampling task execution context. The registry uses a hash table data structure, with the check field unique identifier as the key, to store the marking timestamp and invalidation type code. The marking process implements concurrency control: a version number mechanism is used to detect concurrency conflicts; when duplicate marking is detected, the invalidation type code is merged. The key field registry is persisted to the task metadata storage area, and an operation audit log is added. After marking is completed, a status change notification event is published. The event content contains a list of check field unique identifiers and a key status identifier.

[0039] The verification mechanism for key check field tags performs a consistency check before initiating subsequent processing. It reads all tagged records from the key field registry and initiates a batch query to the dependency mapping database to verify the status of external data sources. The verification query has a 200-millisecond response timeout. When the matching result consistency rate exceeds 80%, the tag is considered valid; otherwise, the tag is revoked, the inconsistent records are cleared, and the exception event is logged. The final confirmed list of key check field tags is written to the spot check task status file. Each line in the file contains the unique identifier of the check field, the tag timestamp, and the associated invalidation address.

[0040] The lifecycle management of key field tags is tied to the execution of spot check tasks. An empty registry is created during task initialization; tag records are dynamically added during task execution; the final state is persisted upon task completion; and memory resources are released upon task termination. For tasks that take longer than 60 minutes to execute, periodic status refreshes are implemented, with invalidation status revalidated and the registry updated every hour. The tag data retention policy is set to 30 days, and historical tag records can be queried using the unique identifier of the validation field.

[0041] The extraction path for the unique identifier of the validation field is predefined in the system configuration, and the path format uses dot-separated notation, for example, "metadata.validation_fields.uid". The dependency mapping database query interface provides batch access capabilities, supporting up to 100 identifier queries at a time. The transmission of failure status marking signals is guaranteed by a message confirmation mechanism. The producer waits for confirmation from all consumers before deleting the message. The standardized processing of address matching follows the Uniform Resource Identifier specification, and percent encoding is uniformly decoded to uppercase letters. The version number of the key field registry is initialized to 0 and incremented with each update. The consistency check threshold parameter is configurable, with a default value of 80%, which is determined based on historical false alarm rate statistics. The task status file uses append-write mode, and a file locking mechanism prevents concurrent write conflicts.

[0042] S4. Degrade the check weight of the key check field to below the preset threshold and activate the manual review flag. The specific implementation is as follows: When obtaining the initial verification weight value configured in the verification rule engine corresponding to the key verification field, the weight parameter storage area is queried through the application programming interface provided by the rule engine configuration service. This storage area is implemented using a distributed key-value database, where the key is a 128-bit hexadecimal string of the verification field unique identifier, and the value is a weight value in single-precision floating-point format, with the weight value range being between 0.0 and 1.0. The query process performs the following operations: constructing a batch query request containing a list of key verification field unique identifiers; sending a query instruction to the rule engine service through the remote procedure call protocol; receiving a returned set of weight values, each element of which contains a complete verification field unique identifier and the corresponding initial verification weight value. The initial verification weight value is set based on a grading model of the importance of the field in food safety verification. This model analyzes the frequency and severity of field verification failures in historical sampling data. For example, fields that frequently trigger verification failures are assigned higher weight values. The specific weight values are set by the system administrator in the configuration interface.

[0043] When determining a differentiated downgrade strategy based on the field type attribute bound to the key verification field, the field type attribute is divided into three categories: enterprise qualification, testing standard, and product identification. This classification information is synchronously obtained from the dependency mapping database. The formulation of the differentiated downgrade strategy executes the following logic: When the field type attribute is the enterprise qualification category, a multiplication downgrade strategy is adopted, multiplying the initial verification weight value by a preset proportional coefficient, the value range of which is, for example, a floating point number between 0.1 and 0.3; when the field type attribute is the testing standard category, a subtraction downgrade strategy is adopted, subtracting a fixed offset from the initial verification weight value, the value range of which is, for example, 0.2 to 0.4; when the field type attribute is the product identification category, a conditional downgrade strategy is adopted, applying different downgrade ranges based on the range of the initial verification weight value. The strategy selection is based on the integer enumeration value of the field type attribute, with the enumeration value 0 corresponding to the enterprise qualification category, 1 corresponding to the testing standard category, and 2 corresponding to the product identification category.

[0044] When a differentiated downgrade strategy is applied to adjust the initial verification weight value to below the preset weight threshold, the preset weight threshold is defined through the system configuration file. The adjustment process implements the following steps: read the integer enumeration value of the current field type attribute; select the corresponding downgrade strategy based on the enumeration value; apply the selected strategy to calculate the new verification weight value; verify whether the new weight value is lower than the preset weight threshold. The setting of the preset weight threshold is based on the sampling task tolerance analysis model. The model analyzes the field misjudgment rate in the historical manual review records and calculates the minimum acceptable weight value for each type of field. For example, the enterprise qualification threshold is set to 0.15, the inspection standard threshold is set to 0.2, and the product identification threshold is set to 0.25. The downgraded verification weight value is written to the weight parameter storage area through the rule engine configuration interface, and a weight change audit log is generated to record the operation details. The log contains the verification field unique identifier, initial weight value, downgraded weight value and operation timestamp.

[0045] When creating a manual review flag in the metadata of the spot check data verification task, the task metadata is stored in a structured database table. The flag creation process includes: adding a manual review flag field to the task metadata table; setting the field data type to Boolean type; initializing the field value to a logical false state. When the manual review flag state is set to the activated state, a state transition operation is performed: the manual review flag field value is updated to a logical true state; and the activation timestamp and trigger reason code are recorded in the task event log table. The activation state setting includes a concurrency control mechanism, which uses database transactions to ensure the atomicity of state changes and prevent multi-task concurrency conflicts. The activation state is associated with a list of key verification fields to form an audit task work order data structure, which contains an array of verification field unique identifiers, an array of downgraded verification weight values, and an original spot check data reference identifier.

[0046] The task routing mechanism after the manual review flag is activated includes queue allocation logic. Audit task work order data is pushed to the distributed message queue, which is partitioned and stored according to field type attributes. Enterprise qualification, testing standard, and product identification categories correspond to independent queue channels. The task allocation strategy configures routing rules based on the auditor's professional field. For example, enterprise qualification tasks are routed to the industrial and commercial qualification review group queue. The work order data structure includes a list of unique identifiers for key verification fields, downgraded verification weight values, and reference pointers to the original sampling data. The audit result feedback mechanism sets a 48-hour timeout control. Tasks that are not processed after the timeout are automatically escalated to the supervisor review queue, and a system alarm notification is sent at the same time.

[0047] The rollback mechanism for weight degradation is activated after the external data source is restored. The status change events of the external data source status registry are monitored. When the invalid status mark signal is revoked, the weight recovery process is triggered: query the weight change audit log to obtain the original weight value; submit a weight recovery request through the rule engine configuration interface; and verify whether the weight value is restored to the initial value. The recovery process includes version control, retaining the records of the three most recent weight changes to support backtracking operations. The manual review flag remains active after the weight is restored until the review is completed. After the review is completed, the status reset operation is performed, the flag is updated to a logical false state, and the completion timestamp is recorded.

[0048] Dynamic adjustment of downgrade policy parameters is based on the audit effectiveness evaluation system. Manual audit results are collected and the misjudgment rate of downgraded fields is calculated. The misjudgment rate is calculated by dividing the number of manual audit corrections by the total number of verifications. When the misjudgment rate exceeds 5%, the policy optimization process is triggered: the proportional coefficient or offset parameter range in the downgrade policy is adjusted; the preset weight threshold value is modified; and the differentiated downgrade policy selection logic is updated. Parameter adjustments use a grayscale release mechanism, first testing the new parameters in 10% of spot checks. Once the test passes, the new parameters take full effect. All parameter changes are recorded in the version control system, which supports parameter rollback and historical version comparison.

[0049] After the spot check task is completed, the impact assessment of weight degradation for key validation fields is analyzed. The results of automated validation and manual review for degraded fields are compared to generate a field reliability analysis report. This report includes metrics such as the percentage of degraded fields, the manual review correction rate, and the weight adjustment impact factor. The impact factor is calculated by taking the absolute difference between the manual review result and the automated validation result and dividing it by the data tolerance. The assessment results are used to optimize the initial weight allocation strategy, forming a closed-loop feedback mechanism. A weekly strategy optimization recommendation report is generated for administrators to make decisions.

[0050] The data processing process with the manual review flag activated includes a security isolation mechanism. The original data of downgraded fields is copied to a secure review storage area with read-only access to prevent accidental modifications. The review interface highlights key validation fields, and displays the downgraded validation weight and the reason for the external data source failure. A two-person review mechanism is implemented when the review results are entered into the system to ensure the accuracy of the review conclusions. Upon completion of the review, a validation results report is generated, noting the fields involved in the manual review and the final judgment.

[0051] S5. Scan the preset coupling relationship set between the key check fields and the non-degraded check fields. If there is an untriggered coupling rule, freeze the logical verification of the associated check fields corresponding to the coupling rule and mark the conflicting topology. The specific implementation is as follows: When loading the predefined coupling relationship configuration library, the configuration library uses a graph database to store the logical dependency rules between the key check fields and the non-demoted check fields. The construction process of the coupling relationship configuration library includes: defining the four core fields of the rule unique identifier, the subject field identifier, the object field identifier, and the trigger condition expression; entering the business constraint relationship between the fields through the rule management interface. For example, when the field corresponding to the key check field unique identifier is invalid, the field corresponding to the non-demoted check field unique identifier needs to be frozen; the configuration library uses a version control mechanism to generate a new configuration version number for each update. When the configuration library is initialized, the full amount of rule data is loaded into the memory graph structure. The graph node is the check field unique identifier string, and the edge attribute stores the trigger condition expression string and the rule status Boolean value.

[0052] When traversing the combination instances of key check fields and non-demoted check fields in the current sampling data, the key check field list and the non-demoted check field list are first identified. The key check field list is obtained from the task metadata and contains the unique identifiers of all check fields marked as key. The non-demoted check field list is configured by scanning the verification rule engine to filter field identifiers with weight values greater than the preset weight threshold. The combination instance generation algorithm performs the following steps: performing a Cartesian product operation on the key check field list and the non-demoted check field list; filtering out field combinations that do not exist in the coupling relationship configuration library; and creating a combination instance object for each valid combination. The object contains a subject field identifier string, an object field identifier string, and an association rule unique identifier string. The traversal process uses a paging optimization mechanism, processing, for example, 100 combination instances per page to avoid exhausting memory resources.

[0053] When checking whether the logical dependency rules corresponding to a combination instance meet the trigger conditions, the trigger condition expression is written in a logical expression language. The detection process performs the following operations: parse the condition expression string into a syntax tree structure; bind the actual value of the current sampled data record to the expression variable; and recursively perform logical operations to return a Boolean result. Trigger conditions include multiple types: when the expression is a numerical comparison operation, such as "the value of field A is greater than the value of field B", data type conversion is required before comparison; when the expression is a logical combination, such as "field C exists and field D is empty", the sub-expression results must be calculated separately and then combined. Boundary condition processing includes: returning an undefined status when the field value is empty; returning an exception flag when the value exceeds the valid range. The detection results generate a rule trigger status table, which records the rule's unique identifier and the Boolean flag of whether it was triggered.

[0054] When an untriggered logical dependency rule exists, the logical validation status of the associated validation field corresponding to the corresponding logical dependency rule is frozen in the metadata of the spot check data validation task. The freeze operation performs the following steps: creating a frozen rule registry data structure in the task metadata; inserting the unique rule identifier of the untriggered rule and its associated object field identifier into the frozen rule registry; marking the validation status of the associated validation field as the "frozen" string constant; and sending a status update request to the rule engine service. The frozen status implements a time limit control mechanism, setting a default freeze duration of, for example, 24 hours, which automatically releases the frozen status after the expiration date. During the freeze period, the rule engine skips the validation logic for the frozen field and directly returns a predefined freeze status code.

[0055] When constructing a conflict topology graph based on untriggered logical dependency rules, the conflict topology graph is stored using a directed graph data structure. The construction process includes: using the key check field as the starting node; using the untriggered logical dependency rule as the directed edge; and using the frozen associated check field as the end node. The graph structure is stored in an adjacency list format. Each node records the field unique identifier string and the field type attribute string, and each edge records the rule unique identifier string and the trigger condition expression string. The generation of the failure dependency path executes a depth-first traversal algorithm, starting from the key check field node, traversing along the edge of the untriggered rule to the associated check field node, and recording all node sequences on the path. The path data is encoded in JSON array format, and the array elements are the field unique identifier string sequences of the path nodes.

[0056] The conflict topology map is persistently stored using a dual backup mechanism, a graph database and a file system. The graph database stores the complete topology structure, supporting real-time queries. File storage uses a graph description language format, with full snapshots generated weekly. The topology map analysis service provides a path retrieval interface. Entering a key checkpoint identifier string returns a list of all affected associated checkpoint paths. An interactive relationship diagram can be generated, highlighting key checkpoint nodes and frozen field nodes, and marking failed dependency paths with lines in a specific color.

[0057] The frozen status monitoring mechanism includes an automated thawing process. The frozen rule registry is periodically scanned. When the weights of key validation fields are detected to have returned to their initial values and the external data source status registry indicates normal status, a thawing operation is triggered: the rule record in the frozen rule registry is cleared; the associated validation field status is updated to the "active" string constant; and the rule engine service is notified to restore the validation logic. The thawing process is recorded in an audit log, including the thawing timestamp and a list of associated rule unique identifiers. For complex topologies, a hierarchical thawing strategy is implemented, thawing the rules layer by layer, from the bottom to the top, following the dependency path hierarchy.

[0058] The validation mechanism within the coupled relationship configuration repository performs rule validity checks before initiating spot checks. This check includes verifying the existence of field identifiers referenced by the rule in the current dataset; checking the syntax of the trigger condition expression; and simulating the rule triggering logic using a test dataset. Invalid rules are automatically marked as inactive, and a system alert is issued. The configuration repository supports version rollback to the three most recent valid versions, automatically reloading historical configuration data into the in-memory graph structure.

[0059] The impact analysis of the conflict topology graph is performed immediately after the freeze operation. The analysis algorithm calculates the proportion of affected fields, calculated by dividing the number of frozen fields by the total number of fields to be validated. When this proportion exceeds, for example, 30%, global validation policy adjustments are triggered: lowering the automatic validation strictness level, increasing the manual review ratio, and extending the task timeout period. The analysis report generates a list of affected fields and a business impact assessment, such as the reliability index of product traceability when product identification fields are frozen.

[0060] Dynamic updates to the coupling relationship configuration library support a rule subscription mechanism. When a key validation field is added, the system automatically scans for potentially affected rules and sends a confirmation notification to the rule owner. Rule subscription lists are categorized by field type, with separate subscription groups corresponding to enterprise qualifications, testing standards, and product identification. Rule change history is retained for 90 days, and change records can be queried by time range.

[0061] Data validation exception handling in a frozen state includes a downgrade strategy. When the coupling rules for key validation fields and non-downgraded validation fields are frozen, a simplified rule set from the backup validation rule base is activated. This simplified rule set uses relaxed conditional expressions, such as changing from an exact match to a range match. The downgrade policy's validity period is tied to the frozen state, and standard validation rules are automatically restored upon unfreezing. The downgrade process records policy switching logs, including the switch timestamp and a rule replacement comparison table.

[0062] S6. When executing the verification rule engine, skip the logic verification for the key verification fields after the demotion, suspend the logic verification for the frozen related fields, and generate a verification report to be reviewed based on the manual review flag and conflict topology. The specific implementation is as follows: When starting the verification rule engine to verify the current sampling data, the verification environment initialization operation is first performed. The initialization process includes: loading the sampling data records into the memory buffer; parsing the task metadata to obtain the verification rule set version identifier; and establishing a network connection session to the rule engine service. The verification rule engine adopts an event-driven execution model. The engine core consists of three parts: the rule parsing component, the condition evaluation component, and the action execution component. The rule parsing component converts the rule configuration data in the storage area into an executable instruction sequence; the condition evaluation component binds the current sampling data value to the rule condition variable; and the action execution component executes the verification logic in order of priority. The engine startup parameters are dynamically configured according to the data record scale, including the task timeout threshold, such as 300 seconds, the maximum memory allocation, such as 512MB, and the number of exception retries, such as 3 times. These parameters are automatically calculated by the task complexity evaluation algorithm.

[0063] A fine-grained validation control mechanism is implemented when skipping logical validation for downgraded key validation fields during validation processing. To identify downgraded fields, the following steps are performed: querying the key validation field registry data structure in the task metadata; obtaining a list of downgraded validation weight values; and filtering the set of field unique identifiers whose weights fall below a preset weight threshold. The skip operation is implemented as follows: during the rule matching phase, if the current field unique identifier is detected as belonging to the downgraded field set, a predefined skip status code is returned; no condition evaluation or action triggering logic is executed; and the "weight downgrade skipped" status description text is recorded in the validation result set. The skip operation includes a full audit trail, recording the skipped field unique identifier string, the skip operation timestamp, and the downgraded weight value.

[0064] When pausing logical validation operations for frozen associated validation fields during validation processing, a state-aware validation scheduling strategy is implemented. To identify frozen fields, the following steps are performed: access the freeze rule registry data structure in the task metadata; extract a list of unique identifiers for all associated object fields. The pause operation is implemented by creating a placeholder task object for each frozen field in the rule scheduling queue; the placeholder task object does not execute the actual validation logic and immediately returns a "validation frozen" status code; and prevents the actual validation task from entering the execution queue. A timeout control mechanism is implemented for the pause state, automatically triggering the task requeue when the freeze duration exceeds a preset value, such as 24 hours. A snapshot copy of the original field value is retained during the pause period for reference in subsequent manual review.

[0065] When reading the activation status of the manual review flag and the invalid dependency path recorded in the conflict topology map, a multi-source metadata collection operation is performed. The collection process includes: reading the Boolean type status value of the manual review flag from the task metadata database; querying the adjacency list structure data of the conflict topology map from the graph database service; and parsing the JSON format array data of the invalid dependency path. The activation status reading includes a version verification step to ensure that the latest status flag value is obtained. The conflict topology map data acquisition implements an incremental loading strategy, only obtaining the subgraph structure data related to the current task. The invalid dependency path is parsed into a sequence of field unique identifiers, each sequence representing the complete impact chain data from the key verification field to the frozen field. The path data implements integrity verification to check whether all node fields exist in the current dataset.

[0066] When combining the activation status of the manual review flag, the conflict topology map, and the list of unverified fields to generate a verification report to be reviewed, a structured report assembly process is implemented. The list of unverified fields is generated by merging the list of demoted fields and the list of frozen fields. The list elements contain the field unique identifier string, the unverified reason code, and the original data value text. Report generation performs the following steps: creating a report template framework structure; inserting text describing the activation status of the manual review flag; visually rendering the conflict topology map image; listing the tabular data of the unverified field list; and adding summary statistics of the verification results. The report format uses both HTML and JSON formats for output. The HTML format is used for manual viewing, and the JSON format is used for system integration processing. The report is stored in the task report storage area, and an access link is generated and written to the task event log record.

[0067] The content enhancement of the report to be reviewed and verified includes impact analysis. Calculation of key indicators: the ratio of downgraded fields is the percentage value of the number of downgraded fields divided by the total number of key fields; the frozen impact range is the number of business function points affected by the frozen fields; the manual review urgency score is derived by weighted summation of the importance of the unverified fields. Indicator values are displayed visually using color coding. For example, values exceeding 30% are marked with a red warning icon. Data lineage annotation information is added to the report, marking the data source table and processing link path for each unverified field. Report version management uses a naming convention of task identifier plus timestamp, retaining historical versions to support audit tracing operations.

[0068] The validation rule engine's execution monitoring implements real-time metric collection. Collected metrics include the number of fields processed, the number of fields skipped, the number of fields paused, and the rule match duration percentile. The monitoring dashboard displays current execution status information, using a progress bar to indicate the task completion percentage. An exception handling mechanism captures error events during engine execution. When consecutive errors exceed a threshold, such as five, the task is paused and a system alert is sent. After the task completes, the resource recovery process frees memory buffer space, closes database connection sessions, and cleans up temporary file resources.

[0069] The report distribution mechanism is implemented based on subscription rule configuration. When the manual review flag is activated, reports are automatically sent to the manual review queue; otherwise, they are sent to the automatic archiving storage area. Distribution channels support email, message queue delivery, and file transfer protocol, automatically selecting the optimal transmission channel based on the report data size. The report read receipt tracking system records the recipient identifier, opening timestamp, and review duration. Timed-out unread reports trigger a reminder notification message. Feedback is collected through the evaluation button element embedded in the report page, allowing reviewers to submit a report quality score and textual suggestions for improvement.

[0070] Incremental updates to pending verification reports support dynamic changes during task execution. New frozen fields or weight adjustments trigger a report version update: obtaining the latest unverified field list data; regenerating the conflict topology subset data; and appending change log text. A version diff function highlights changes, distinguishing them with a special identifier. The final report is locked upon task submission to prevent subsequent modification. This lock is verified using a digital signature algorithm to protect integrity.

[0071] After report generation, quality verification is automated. This includes: field coverage verification to ensure all unverified fields are recorded; dependency path integrity verification to ensure the topology map includes all invalid paths; and state consistency verification to ensure the activation state in the report is consistent with the metadata. Verification results generate a quality score report. A score below a threshold, such as 80, triggers a report regeneration process. The quality score is calculated as a weighted average of the pass rates for each check item, with weights dynamically assigned based on business importance.

[0072] The storage security of pending verification reports is protected by encryption. Report files are encrypted using a symmetric encryption algorithm for persistent storage, with encryption keys distributed by task through a key management system. Access control implements role-based permission management, with auditors limited to accessing reports for their assigned tasks. An audit log records all report access operations, including the accessor identifier, access timestamp, and operation type code. The report retention period is set to 90 days after the task is completed, with the archive cleanup process automatically initiated upon expiration.

[0073] The implementation of steps S1 to S6 addresses the chained validation issues caused by external data source failures through a layered processing mechanism. Specifically, dynamic weight adjustment (S4) downgrades key fields rather than directly deactivates them, preserving basic validation capabilities and avoiding the waste of resources required for full manual review. For example, enterprise qualification fields are subject to a step-by-step downgrade, reducing the risk of misjudgment while maintaining minimum validation logic. Conflict topology modeling (S5) transforms field coupling relationships into visual dependency paths, precisely locating the frozen scope. Compared to traditional full-table scans, the graph structure stored in the adjacency table reduces invalid detections, and the hierarchical unfreezing mechanism prevents over-freezing. The collaborative control mechanism (S6) dynamically skips downgraded and suspended frozen fields during engine execution, automatically integrating manual review flags with the topology map to generate reports. Dual-format (HTML / JSON) reports address both human and machine processing needs, improving efficiency compared to single-output output. Through the coordinated integration of weight threshold control, topology dependency tracking, and state collaboration, the impact radius of external data anomalies on the system is reduced (based on measured data) while ensuring verification reliability, while also reducing the workload of manual review.

[0074] Example 2: Figure 2 A structural diagram of a food safety sampling data verification system of the present invention is provided. The food safety sampling data verification system comprises: The dependency mapping module is used to establish a dependency mapping table between the sampling inspection system and the external data source. The dependency mapping table records the binding relationship between each check field and the corresponding external data source; The causal analysis module is used to build a service response causal graph model, inject virtual intervention parameters into the external data source and generate counterfactual ideal responses. When the KL divergence value between the actual response and the counterfactual ideal response exceeds the preset causal deviation threshold, the external data source is marked as invalid. The failure transmission module is used to parse the check field set of the current sampling data and identify the key check fields bound to the external data source with failure status based on the dependency mapping table; The weight control module is used to reduce the verification weight of key verification fields to below the preset threshold and activate the manual review flag at the same time; The coupling and decoupling module is used to scan the preset coupling relationship set between key check fields and non-degraded check fields. If there are any untriggered coupling rules, the logical verification of the associated check fields corresponding to the coupling rules is frozen and the conflicting topology is marked. The collaborative execution module is used to skip the logic verification of the key verification fields after the demotion when executing the verification rule engine, suspend the logic verification of the frozen related fields, and generate a verification report to be reviewed based on the manual review flag and conflict topology.

[0075] Example 3: A computer storage medium stores a program or instruction, and when the program or instruction is executed by a processor, a food safety sampling data verification method is implemented.

[0076] The calculations involved in the embodiments are all dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to actual conditions.

[0077] It should be noted that the present invention can be deployed on the device itself to implement embedded applications, and can also be run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0078] The above embodiments can be implemented in whole or in part via software, hardware, firmware, or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product comprises one or more computer instructions or computer programs. When loaded or executed on a computer, the processes or functions described in the embodiments of this application are fully or partially performed. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired transmission. Wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission methods include infrared, microwave, etc. The computer-readable storage medium can be any available medium accessible by a computer, or a data storage device such as a server or data center that contains a collection of one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, tapes), optical media (e.g., DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0079] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and modules described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

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

[0081] The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, and may be located in one place or distributed across multiple network modules. Some or all of the modules may be selected to achieve the purpose of this embodiment according to actual needs.

[0082] In addition, each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0083] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0084] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

[0085] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A food safety sampling data verification method, characterized in that: include: S1. Establish a dependency mapping table between the sampling inspection system and the external data source. The dependency mapping table records the binding relationship between each check field and the corresponding external data source; S2. Build a service response causal graph model, inject virtual intervention parameters into the external data source and generate a counterfactual ideal response. When the KL divergence value between the actual response and the counterfactual ideal response exceeds the preset causal deviation threshold, mark the external data source as invalid. S3. Parse the check field set of the current sampling data and identify the key check fields bound to the external data source in the failed state based on the dependency mapping table; S4. Downgrade the check weight of the key check field to below the preset threshold, and activate the manual review flag; S5. Scan the preset coupling relationship set between the key check fields and the non-degraded check fields. If there is an untriggered coupling rule, freeze the logical verification of the associated check fields corresponding to the coupling rule and mark the conflicting topology. S6. When executing the verification rule engine, skip the logic verification for the key verification fields that have been demoted, suspend the logic verification for the frozen related fields, and generate a verification report to be reviewed based on the manual review flag and conflict topology.

2. The food safety sampling data verification method according to claim 1, characterized in that: S1 includes: Obtain the unique identifiers of all verification fields in the sampling inspection system and their corresponding external data source network access addresses; According to the food safety data verification rules, determine the field type attributes of each verification field. The field type attributes include enterprise qualification, testing standard, and product identification. Generate a structured storage dependency mapping table, in which each mapping record contains the unique identifier of the verification field, the bound external data source network access address and the field type attribute, and the dependency mapping table establishes an index association with the sampling data field through the unique identifier of the verification field.

3. The food safety sampling data verification method according to claim 2, characterized in that S2 include: Construct a Bayesian network structure as a service response causal graph model based on historical service log data; Using the service response causal graph model, a test request carrying virtual intervention parameters is sent to the target external data source. The virtual intervention parameters include a simulated request volume multiplier and a forced timeout threshold. Receive actual response data returned by the target external data source in response to the test request; Calculate counterfactual ideal response data under virtual intervention parameters through the service response causal graph model; Calculate the KL divergence value between the probability distribution of the actual response data and the counterfactual ideal response data; When the KL divergence value between probability distributions exceeds the preset causal deviation threshold, an external data source failure status marking signal is generated.

4. The food safety sampling data verification method according to claim 3, characterized in that: The Bayesian network structure includes request quantity nodes, response delay nodes and error code nodes of external data sources.

5. The food safety sampling data verification method according to claim 3, characterized in that: S3 includes: Parse the validation field set of the current sampling data and identify the key validation fields bound to the external data source in the invalid state based on the dependency mapping table, including: Extract the unique identifier of the verification field to be verified in the current sampling data record; Query the external data source network access address corresponding to the unique identifier of the check field in the dependency mapping table; receiving an external data source failure status marking signal, wherein the external data source failure status marking signal includes a failed external data source network access address; Matching the queried external data source network access address with the invalid external data source network access address; When the external data source network access address is matched successfully, the corresponding check field unique identifier is marked as a key check field.

6. The food safety sampling data verification method according to claim 5, characterized in that: S4 includes: Get the initial check weight value configured in the check rule engine corresponding to the key check field; Determine differentiated degradation strategies based on the field type attributes bound to key verification fields. Field type attributes include enterprise qualification, testing standard, and product identification. Applying a differentiated degradation strategy to adjust the initial verification weight value to below the preset weight threshold, and generating a degraded verification weight value; Create a manual review flag in the metadata of the random inspection data verification task and set the manual review flag status to active.

7. The food safety sampling data verification method according to claim 6, characterized in that S5 include: Load the predefined coupling relationship configuration library, which stores the logical dependency rules between key check fields and non-degraded check fields; Traverse the combination instances of key check fields and non-degraded check fields in the current sampling data; Check whether the logical dependency rules corresponding to the combination instance meet the trigger conditions; When there are untriggered logical dependency rules, the logical verification status of the associated verification fields corresponding to the corresponding logical dependency rules is frozen in the metadata of the spot check data verification task; A conflict topology graph is constructed based on untriggered logical dependency rules, and the conflict topology graph records the failure dependency paths of associated check fields and key check fields.

8. The food safety sampling data verification method according to claim 7, characterized in that S6 include: Start the verification rule engine to verify the current sampling data; During the verification process, the logic verification operation is skipped for the key verification fields that have been downgraded; Suspend the logic verification operation for the frozen associated check fields during the check process; Read the activation status of the manual review flag and the failure dependency path recorded in the conflict topology map; A verification report to be reviewed is generated by combining the activation status of the manual review flag, the conflict topology diagram, and the list of unverified fields.

9. A food safety sampling data verification system, used to implement the food safety sampling data verification method according to any one of claims 1 to 8, characterized in that: include: The dependency mapping module is used to establish a dependency mapping table between the sampling inspection system and the external data source. The dependency mapping table records the binding relationship between each check field and the corresponding external data source; The causal analysis module is used to build a service response causal graph model, inject virtual intervention parameters into the external data source and generate counterfactual ideal responses. When the KL divergence value between the actual response and the counterfactual ideal response exceeds the preset causal deviation threshold, the external data source is marked as invalid. The failure transmission module is used to parse the check field set of the current sampling data and identify the key check fields bound to the external data source with failure status based on the dependency mapping table; The weight control module is used to reduce the verification weight of key verification fields to below the preset threshold and activate the manual review flag at the same time; The coupling and decoupling module is used to scan the preset coupling relationship set between key check fields and non-degraded check fields. If there are any untriggered coupling rules, the logical verification of the associated check fields corresponding to the coupling rules is frozen and the conflicting topology is marked. The collaborative execution module is used to skip the logic verification of the key verification fields after the demotion when executing the verification rule engine, suspend the logic verification of the frozen related fields, and generate a verification report to be reviewed based on the manual review flag and conflict topology.

10. A computer storage medium, characterized in that A program or instruction is stored on a computer storage medium, and when the program or instruction is executed by a processor, the food safety sampling data verification method as described in any one of claims 1 to 8 is implemented.

Images