Government affair data exchange automatic checking method based on GS1 coding rule engine

Abstract

The application discloses a government affair data exchange automatic checking method based on a GS1 coding rule engine, which comprises the following steps: receiving government affair data in a data provider exchange request, and preprocessing the government affair data; performing GS1 coding structure analysis on the government affair data, constructing a coding analysis tree, performing dynamic rule reflection loading and matching according to the coding analysis tree, and obtaining a node level rule execution chain; constructing a time blood relationship link, and constructing a government affair data exchange automatic checking model according to the time blood relationship link; performing multi-level automatic checking and confidence score on the government affair data by using the GS1 coding rule engine in combination with the government affair data exchange automatic checking model, obtaining exchangeable data, to-be-reviewed data and problem government affair data; performing rule audit log reverse analysis and cross-checking on the to-be-reviewed data, obtaining misjudgment data, and feeding back and optimizing the node level rule execution chain and the government affair data exchange automatic checking model according to the misjudgment data.

Description

Technical Field

[0001] This invention relates to the field of automatic verification technology for data exchange, and in particular to an automatic verification method for government data exchange based on the GS1 coding rule engine. Background Technology

[0002] With the deepening of digital government construction, cross-departmental and cross-level government data exchange has become a key infrastructure for improving governance efficiency. However, existing government data exchange verification technologies generally suffer from the following defects: First, verification rules mostly adopt static configuration methods, which are difficult to adapt to the dynamic parsing requirements of mixed standard application identifiers and government extended identifiers in the GS1 coding system, resulting in rigid rule matching and poor scalability; Second, existing automatic verification mostly relies on a single rule engine, lacks a heterogeneous cross-verification mechanism, has a high risk of misjudgment and omission, and lacks sufficient confidence level processing, resulting in high manual review costs; Third, data lineage management is weak, lacking the ability to structurally trace exchange batches, content versions, and lifecycle events, making it difficult to locate the introduction point of data quality problems and unable to make adaptive predictions based on historical verification patterns; Fourth, rule correction and updates lack a gray-scale release mechanism, and full implementation can easily lead to systemic misjudgments, and lacks reverse analysis and self-optimization capabilities based on audit logs.

[0003] Therefore, there is an urgent need for an automatic verification method for government data exchange that can deeply integrate the GS1 coding standard and has dynamic rule reflection, dual-engine cross-validation, lineage tracing and adaptive learning capabilities. Summary of the Invention

[0004] The purpose of this invention is to provide an automatic verification method for government data exchange based on the GS1 coding rule engine.

[0005] To achieve the above objectives, the present invention is implemented according to the following technical solution: This invention includes the following steps: The system receives government data from a data provider's exchange request and preprocesses the government data. The exchange data includes an exchange header, a global location code, a data resource global trade item code, an exchange batch series shipping box code, and an exchange body. The government data is parsed using the GS1 encoding structure to construct an encoding parsing tree. Dynamic rule reflection loading and matching are then performed based on the encoding parsing tree to obtain a node-level rule execution chain. A timeline is constructed, and an automatic verification model for government data exchange is built based on the timeline. The GS1 coding rule engine is used in conjunction with the automatic verification model for government data exchange to perform multi-level automatic verification and confidence scoring on the government data, thereby obtaining exchangeable data, data to be reviewed, and problematic government data. The data to be reviewed is subjected to reverse analysis and cross-validation of the rule audit logs to obtain misjudged data, and the node-level rule execution chain and the automatic verification model for government data exchange are optimized based on the feedback of the misjudged data.

[0006] Furthermore, the method for constructing the encoded parse tree includes: The received exchange request header contains global location code, data resource global trade item code, and exchange batch series shipping box code; the header is parsed using the GS1 standard decoding algorithm to extract the sender location identifier, data resource type identifier, and batch serial number identifier, which are used as attribute metadata of the root node of the encoding parsing tree; The exchange adopts a hybrid coding structure that combines the standard application identifier AI with the government extended application identifier AI; the standard AI follows the application identifier in the GS1 general specification; First, identify the AI ​​prefix identifier in the exchange data stream, and determine whether the AI ​​belongs to standard AI or government extended AI by the prefix value range; if it is government extended AI, call the preset government AI mapping dictionary to perform semantic conversion. The encoding parse tree consists of a root node, first-level child nodes, second-level and lower-level child nodes, and leaf nodes. The root node uses the exchange batch SSCC as its root node and carries batch-level metadata, including the exchange timestamp, exchange protocol version, and batch global identifier. GLN and GTIN are used as first-level child nodes. GLN corresponds to the location information of the participants in the data exchange, and GTIN corresponds to the data resource type information of the data exchange. The GLN node is connected to the sender child node and the receiver child node. The GTIN node is connected to the data resource metadata child node. The second-level and lower-level child nodes recursively parse the standard AI and government extended AI in the exchange. Each AI corresponds to an independent node in the encoding parse tree, and the node attributes include AI identifier, AI data content, AI data length, AI verification status, and node level depth. The encoding parse tree is constructed using a top-down, layer-by-layer parsing method. During the construction process, AI format validity checks are performed simultaneously. If a node fails to pass the check, the current node is marked as abnormal.

[0007] Furthermore, the method for obtaining the node-level rule execution chain includes: The system traverses each node in the tree and queries the government AI mapping dictionary based on the AI ​​identifier corresponding to the node. The government AI mapping dictionary pre-defines the mapping relationship between standard AI and government extended AI to the verification rule set. The structure of the mapping dictionary is: the key is the AI ​​identifier, and the value is the rule set index corresponding to the AI. The rule set index points to the specific rule definition in the rule base. The rule definition includes rule ID, rule type, rule parameters and rule priority. Based on the query results of the mapping dictionary, each node of the encoded parse tree is dynamically assembled with a node-level rule execution chain. The construction of the rule execution chain adopts a reflection loading mechanism, which dynamically instantiates the corresponding rule processor according to the node AI type. The data field nodes are located using reflection to obtain the rule set: if the AI ​​type in the node attribute is marked as standard AI, the standard rule base is searched; if it is government-extended AI, the government-specific rule base is searched; the AI ​​code value and data type mark are combined as a composite search key to locate the verification rule set in the corresponding rule base; the associated code table version number in the node attribute is read, and the rule loader extracts standard code data from the code table cache based on the version number, using the standard code data as the comparison benchmark for value domain layer verification; if the version number is not in the cache, a hot update of the code table is triggered, and the latest version is pulled from the authoritative release source; The rule set is expanded into a node-level rule execution chain for each node: each rule is defined in the form of an abstract condition, and the actual data value, data length, and data format marker in the node attribute are bound to the placeholders of the abstract condition to generate an instantiated condition for the specific data value of the node; the actions in the rule set are instantiated into actions containing the specific context information of the node; the instantiated condition-action pairs are chained together in the original logical order of the rules to form the node-level rule execution chain for that node. The node-level rule execution chain comprises four layers of rules: format rules, value range rules, association rules, and semantic rules. These four layers are executed sequentially within the node-level rule execution chain, with each layer supporting parallel sub-rule execution. The format rules layer verifies the data type, length, encoding format, and required fields of data items. The value range rules layer verifies the value range, enumeration validity, and regular expression matching of data items. The association rules layer verifies the consistency of references between data items and other data items in the same batch, the validity of foreign keys, and logical dependencies. The semantic rules layer verifies the business semantic rationality of data items. If two rules within the same execution group have no direct dependency but are logically mutually exclusive, the conflict will be resolved according to the rule priority weights preset in the rule set; if the priorities are the same, the rules will be applied in order of newest to oldest according to their entry timestamps and written to the conflict resolution log. Assemble the data field nodes with sorted, instantiated, and pre-resolved cross-field references into node-level rule execution chains, and output them to the rule engine execution queue.

[0008] Furthermore, the method for constructing the temporal lineage link includes: A three-dimensional anchor system is established to decouple the identity identifier, exchange transaction identifier, and content version identifier of data resources. The three-dimensional anchors are identity anchor, batch anchor, and version anchor. The identity anchor uses the global trade project code of the data resource as the identity anchor, the batch anchor uses the exchange batch series shipping box code as the batch anchor of the exchange transaction, and the version anchor uses the value corresponding to the predefined version control application identifier in the exchange body as the content version identifier. Using the shipping box code as the granularity, the lineage node attributes of each exchange batch are recorded. The lineage node attributes are bound and stored with the batch anchor point, forming atomic nodes in the time lineage link. The lineage node attributes include content hash, exchange pair, and verification result. Using the identity anchor as the aggregation key, all historical batches associated with the current data resource are arranged in time series. For adjacent versions, the system determines whether the content has changed based on the content hash of the two. If the content hashes are different, incremental difference calculation is triggered. Based on the incremental difference, the content changes between adjacent versions are identified, and Diff nodes are generated. Adjacent versions refer to two exchange batches of the same data resource that are adjacent in time series, and the version anchors are continuously incremented. The attributes recorded in the Diff node include the changed field path, the value before and after the change, the change type, and the association rule ID. Diff nodes are linked together chronologically to form an incremental Diff chain of data resources, identified by the Global Trade Item Code. By traversing the incremental Diff chain, all field-level changes between any historical version and the current version can be precisely traced back to pinpoint the time and operation that introduced data quality issues. Five types of government data lifecycle events are written into the time lineage link to form the EPCIS event chain. The five types of events are associated with the same data resource through identity anchors, with specific exchange transactions through batch anchors, and with specific content versions through version anchors, forming a standardized event sequence covering the entire lifecycle of data resources. The EPCIS event chain is written into the time lineage link and output. The five types of events are data generation events, data exchange events, data acceptance events, data update events, and data obsolescence events.

[0009] Furthermore, the method for constructing an automatic verification model for government data exchange based on the aforementioned timeline includes: From the time-based lineage link, multi-dimensional lineage features are extracted according to the identity anchor points of the batch to be verified, and a lineage feature vector is constructed. The lineage feature vector encodes the four-dimensional attributes of the data resources in a structured manner and serves as the multi-dimensional input features of the automatic verification model. The four-dimensional attributes are time, space, content, and behavior. Based on the verification results of each historical batch and the corresponding bloodline feature vectors, a historical verification pattern library is constructed; the historical verification pattern library is aggregated by GTIN to establish a correlation mapping between bloodline feature vectors and verification results; Construct a verification prediction sub-model and output the bloodline prediction result: extract the bloodline feature vector of the new batch data, search the historical batch set in the historical verification pattern library where the similarity of the bloodline feature vector of the current new batch is higher than a preset threshold, if a similar historical batch is found, then calculate the distribution ratio of each verification result in the set and output the bloodline prediction result; the bloodline prediction result includes the prediction conclusion, prediction confidence, and similar historical batch reference identifier; The automated verification model integrates the rule verification results with the pedigree prediction results to make a final automated verification result. The integration decision employs a hierarchical adjudication mechanism with three layers: Layer 1: If both engines pass and the pedigree prediction is consistent, it's a high-confidence pass; if the two engines diverge, it's a medium-confidence pass, and pedigree prediction is introduced to assist in the adjudication. If the pedigree prediction conclusion contradicts the rule engine conclusion, and the prediction confidence is higher than the extremely high threshold, the automated verification model marks the data as pedigree abnormal; if both engines fail, it's a low-confidence pass, and in principle, it's classified as problematic data, unless the pedigree prediction conclusion is pass and the prediction confidence is higher than the extremely high threshold, in which case a pedigree abnormality review is triggered instead of a direct rejection. The rule verification result includes the main verification result, the shadow verification result, and the confidence score. When misjudged data is confirmed, the lineage feature vector of the misjudged batch and the confirmed actual compliance are added to the historical verification pattern library. The association mapping between the lineage feature vector corresponding to the affected data resources and the verification results in the historical verification pattern library is updated according to the misjudged data, and the verification prediction sub-model is retrained. The pattern library update module included in the automatic verification model for government data exchange regularly performs automatic updates of the pattern library, eliminates outdated historical patterns that exceed the preset time window, and supplements newly generated lineage-verification associations.

[0010] Furthermore, the method for performing multi-level automatic verification and confidence scoring of the government data includes: A master rule is used to perform multi-level automatic verification of government data. The master rule engine receives the node-level rule execution chain and performs verification of four levels of rules—format, value range, association, and semantics—on each node in the order of the preorder traversal of the encoding parse tree. The format rule verifies the data type, length, and encoding standard; the value range rule verifies the range of values ​​and the legality of enumeration; the association rule verifies the consistency of cross-field references; and the semantic rule verifies the rationality of business logic. The master verification result is output, which can be either passed or failed. Parallel execution verification is performed using a shadow rule engine, which achieves cross-validation through heterogeneous rule execution paths. The construction of the shadow rule engine follows the principles of functional equivalence and heterogeneous paths. Functional equivalence: The rule chains loaded by the shadow engine are logically and semantically equivalent to those of the main engine, meaning that the verification targets of the two rule chains are consistent for the same encoded parsing tree node and the same government data item. Path heterogeneity: The rule chains of the shadow engine have structural differences in implementation paths compared to the main engine. The main engine uses a rule loading mechanism based on dynamic reflection, while the shadow engine uses pre-compiled static rule templates to implement equivalent rules. The main rule engine and the shadow rule engine perform verification synchronously and in parallel on the same batch of government data. The shadow rule engine outputs the shadow verification result, which can be either pass or fail. When the primary verification result is passed and the shadow verification result is passed, the two heterogeneous engines, the primary rule engine and the shadow rule engine, independently determine that the data item meets the exchange standard, assign a high confidence rating, and classify the current data into the exchangeable data queue. When the primary verification result and the shadow verification result differ, a medium confidence rating is assigned, the data is placed in the data queue to be reviewed, and an intervention review process is triggered. The intervention review is a targeted review only of the nodes and related rule items where the dual engines determine the discrepancy. The reviewers make a final decision based on the original data, the rule hit details of each of the dual engines, and the context of the encoding parsing tree: if the data is confirmed to be compliant, it is corrected to be exchangeable data; if the data is confirmed to be non-compliant, it is corrected to be problematic government data. When both the primary verification result and the shadow verification result fail, a low confidence rating is assigned to both, the data is classified into the problematic government data queue, and returned to the data provider for correction. For each verification process, a logging method is used to write the main verification result, shadow verification result, final confidence rating, node rule execution details, engine execution time, and rule chain version number into the audit log.

[0011] Furthermore, the method for performing rule-based audit log reverse analysis and cross-validation on the data to be reviewed includes: Reverse analysis includes rule false interception rate statistics and failure mode identification and abnormal rule identification within a specific value range; among them, the false interception rate of each rule is monitored over time, and if the increase in the false interception rate within an adjacent time window exceeds a preset threshold, the rule is marked as an abnormal rule; Audit logs are aggregated by rule ID, and the false interception rate of each rule within a preset time window is calculated. If the falsely judged data is confirmed to be compliant data through cross-validation, it is included in the false interception count of the rule triggered by the current data. The distribution analysis of the field values ​​of each data item in the false judgment dataset is performed. If it is found that the concentration of false judgments generated by a certain rule in a specific value range is higher than a preset multiple in other ranges, it is determined that the current rule has a value range sensitive defect. The value range includes a certain administrative division code segment, a certain time range, and a certain numerical range. Stratified sampling is used to select data samples to be reviewed according to a preset ratio and send them into the review process. When the data provider appeals the verification results, all data items corresponding to the appeal are sent into the review process. The appeal data includes returned data marked as problematic government data and data in which the data provider has objections to the classification of the data to be reviewed. Data that has been confirmed as compliant through the review process, or data that has been confirmed as compliant through cross-validation and is consistent with the review conclusion, will be included in the misjudged dataset. The cross-validation will send the data to be confirmed to a third independent verification channel that is different from both the main rule engine and the shadow rule engine. If the third channel determines that the current data is compliant and consistent with the review conclusion, it will be confirmed as misjudged data. Based on the rule ID associated with the misjudged dataset and the failure mode in a specific value range, the rule entries that need to be corrected are automatically located. The corrections include rule logic correction, code table correction, and API call correction. The revised rules enter the gray-scale release phase. During this phase, the revised rules run in parallel with the original rules, but the revised rules are implemented in a gray-scale manner according to the exchange batch or the granularity of the Global Trade Item Code for the data resource. All exchange requests within the same batch or the same data resource are subject to the same version of the rules. The false interception rate, normal interception rate, and consistency with the original rules are continuously monitored during the operation of the gray-scale rules. If the false interception rate of the gray-scale rules does not exceed the preset deviation within the preset observation period, and the false interception rate is significantly lower than that of the original rules, then the full implementation is triggered, and the revised rules are promoted to all exchange requests. If the gray-scale rules exhibit abnormal behavior or introduce new misjudgment patterns, the rules are automatically rolled back to the original rules, and the abnormal information is fed back to the rule optimization queue.

[0012] The beneficial effects of this invention are: This invention is an automatic verification method for government data exchange based on the GS1 coding rule engine. Compared with the prior art, this invention has the following technical advantages: This invention achieves hybrid coding adaptive verification of standard AI and government extended AI by constructing a GS1 coding parse tree and a dynamic rule reflection loading mechanism, significantly improving the flexibility and scalability of rule matching. It employs a master-shadow dual-engine heterogeneous cross-validation and confidence leveling mechanism to effectively reduce the risk of misjudgment and omission by a single engine, improving the reliability of verification results. Based on a three-dimensional anchor point system, it constructs a time lineage link, enabling version tracing and incremental difference location throughout the entire lifecycle of government data, enhancing the root cause analysis capability of data quality issues. Through the fusion decision-making of the lineage prediction sub-model and rule verification, the system possesses historical experience inference and adaptive learning capabilities. Combined with rule audit log reverse analysis, canary release, and automatic rollback mechanisms, it achieves continuous rule optimization and smooth evolution, effectively reducing manual review costs and system update risks. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating the steps of the automatic verification method for government data exchange based on the GS1 coding rule engine of this invention. Detailed Implementation

[0014] The present invention will be further described below through specific embodiments. The illustrative embodiments and descriptions herein are used to explain the present invention, but are not intended to limit the present invention.

[0015] The automatic verification method for government data exchange based on the GS1 coding rule engine of this invention includes the following steps: like Figure 1 As shown, this embodiment includes the following steps: The system receives government data from a data provider's exchange request and preprocesses the government data. The exchange data includes an exchange header, a received global location code, a data resource global trade item code GS1, an exchange batch series shipping box code, and an exchange body. In the actual assessment, the data provider initiates an exchange request to the provincial market supervision bureau. The exchange header includes: Sender GLN: 6951234500008, Data Resource GTIN: 09521101530001 (corresponding to enterprise registration information data resource type), Exchange Batch SSCC: 000123450000000001, The exchange body adopts a hybrid AI structure with GS1-128 barcode encoding, and the data stream is... <fnc1> 01 09521101530001 <fnc1>92 ZQ-2024-001 <fnc1> 93 110105 <fnc1> 94 20240815 <fnc1> 95 91350100M0001 <fnc1>10 AB-2024-001; where AI(01) is the standard GTIN identifier; AI(92)~AI(95) are government extension AIs, respectively mapped as: 92=administrative division code, 93=unified social credit code prefix, 94=registration date, 95=market entity type code; AI(10) is the standard batch number; The government data is parsed using the GS1 encoding structure to construct an encoding parsing tree. Dynamic rule reflection loading and matching are then performed based on the encoding parsing tree to obtain a node-level rule execution chain. A timeline is constructed, and an automatic verification model for government data exchange is built based on the timeline. The GS1 coding rule engine is used in conjunction with the automatic verification model for government data exchange to perform multi-level automatic verification and confidence scoring on the government data, thereby obtaining exchangeable data, data to be reviewed, and problematic government data. The data to be reviewed is subjected to reverse analysis and cross-validation of the rule audit logs to obtain misjudged data, and the node-level rule execution chain and the automatic verification model for government data exchange are optimized based on the feedback of the misjudged data.

[0016] In this embodiment, the method for constructing the encoded parse tree includes: The received exchange request header contains global location code, data resource global trade item code, and exchange batch series shipping box code; the header is parsed using the GS1 standard decoding algorithm to extract the sender location identifier, data resource type identifier, and batch serial number identifier, which are used as attribute metadata of the root node of the encoding parsing tree; The exchange adopts a hybrid coding structure that combines standard application identifiers (AI) and government extended application identifiers (AI). The standard AI follows the application identifiers in the GS1 general specification. The government extended AI is a private application identifier applied for in the GS1 standard private / custom identifier reserved field for government data exchange scenarios. Its structure follows the GS1 AI coding specification and is mapped to government semantics through the government AI mapping dictionary. First, identify the AI ​​prefix identifier in the exchange data stream, and determine whether the AI ​​belongs to standard AI or government extended AI by the prefix value range; if it is government extended AI, call the preset government AI mapping dictionary to perform semantic conversion. The encoding parse tree consists of a root node, first-level child nodes, second-level and lower-level child nodes, and leaf nodes. The root node uses the exchange batch SSCC as its root node and carries batch-level metadata, including the exchange timestamp, exchange protocol version, and batch global identifier. GLN and GTIN are used as first-level child nodes. GLN corresponds to the location information of the participants in the data exchange, and GTIN corresponds to the data resource type information of the data exchange. The GLN node is connected to the sender child node and the receiver child node. The GTIN node is connected to the data resource metadata child node. The second-level and lower-level child nodes recursively parse the standard AI and government extended AI in the exchange. Each AI corresponds to an independent node in the encoding parse tree, and the node attributes include AI identifier, AI data content, AI data length, AI verification status, and node level depth. The encoding parse tree is constructed using a top-down, layer-by-layer parsing method. During the construction process, AI format validity checks are performed synchronously. If a node fails to pass the check, the current node is marked as abnormal. In actual evaluation, the current node is marked as abnormal, but the construction process of the entire tree is not interrupted; the parse tree can be accessed by preorder traversal. The top-down, layer-by-layer parsing is adopted: Root node: SSCC=000123450000000001, the attribute metadata includes the exchange timestamp 2026-08-23T14:30:00Z, protocol version v2.1; First-level child nodes: GLN node (sender 6951234500008, receiver 6951234500015); GTIN node (09521101530001); Second-level and lower child nodes: recursively parsing the exchange body, AI(01) is mounted under GTIN; AI(92)~AI(95) are mounted under the "Government Extended Data" branch under GTIN; AI(10) is mounted under the standard attribute branch under GTIN, and each node attribute includes AI identifier, data content, data length, verification status, and layer depth; During the construction process, AI format validity checks are performed synchronously: AI(92) data length is 8 bits, which meets the N8 format requirements; AI(94) data length is 8 bits, which meets the YYMMDD date format. If a node fails the check (e.g., AI(93) length is 7 bits instead of the required 6 bits), the node is marked as abnormal, but the construction of the entire tree is not interrupted.

[0017] In this embodiment, the method for obtaining the node-level rule execution chain includes: The system traverses each node in the tree and queries the government AI mapping dictionary based on the AI ​​identifier corresponding to the node. The government AI mapping dictionary pre-defines the mapping relationship between standard AI and government extended AI to the verification rule set. The structure of the mapping dictionary is: the key is the AI ​​identifier, and the value is the rule set index corresponding to the AI. The rule set index points to the specific rule definition in the rule base. The rule definition includes rule ID, rule type, rule parameters and rule priority. Based on the query results of the mapping dictionary, each node of the encoded parse tree is dynamically assembled with a node-level rule execution chain. The construction of the rule execution chain adopts a reflection loading mechanism, which dynamically instantiates the corresponding rule processor according to the node AI type. The data field nodes are located using reflection to obtain the rule set: if the AI ​​type in the node attribute is marked as standard AI, the standard rule base is searched; if it is government-extended AI, the government-specific rule base is searched; the AI ​​code value and data type mark are combined as a composite search key to locate the verification rule set in the corresponding rule base; the associated code table version number in the node attribute is read, and the rule loader extracts standard code data from the code table cache based on the version number, using the standard code data as the comparison benchmark for value domain layer verification; if the version number is not in the cache, a hot update of the code table is triggered, and the latest version is pulled from the authoritative release source; The rule set is expanded into a node-level rule execution chain for each node: each rule is defined in the form of an abstract condition, and the actual data value, data length, and data format marker in the node attribute are bound to the placeholders of the abstract condition to generate an instantiated condition for the specific data value of the node; the actions in the rule set are instantiated into actions containing the specific context information of the node; the instantiated condition-action pairs are chained together in the original logical order of the rules to form the node-level rule execution chain for that node. The node-level rule execution chain comprises four layers of rules: format rules, value range rules, association rules, and semantic rules. These four layers are executed sequentially within the node-level rule execution chain, with each layer supporting parallel sub-rule execution. The format rules layer verifies the data type, length, encoding format, and required fields of data items. The value range rules layer verifies the value range, enumeration validity, and regular expression matching of data items. The association rules layer verifies the consistency of references between data items and other data items in the same batch, the validity of foreign keys, and logical dependencies. The semantic rules layer verifies the business semantic rationality of data items. If two rules within the same execution group have no direct dependency but are logically mutually exclusive, the conflict will be resolved according to the rule priority weights preset in the rule set; if the priorities are the same, the rules will be applied in order of newest to oldest according to their entry timestamps and written to the conflict resolution log. Assemble the data field nodes with sorted, instantiated, and pre-resolved cross-field references into node-level rule execution chains, and output them to the rule engine execution queue; In actual evaluation, the pre-parsing of cross-field consistency references in the association layer verification is as follows: After the rule loader reads the reference list of the node, it directly locates the referenced node in the tree and copies the current data value and verification status attribute of the referenced node to the rule execution chain context of the current node to form a local reference cache; it checks the verification status attribute of the referenced node. If the referenced node itself has not yet completed the basic verification, the cross-field consistency rule of the current node is suspended and waits until the basic verification of the referenced node is completed; if the basic verification of the referenced node has failed, the cross-field consistency rule of the current node is directly marked as a reference invalid; the referenced node data is copied, where cross-field references follow unidirectionality: only nodes that semantically depend on others are allowed to reference nodes that depend on them, and reverse references are not allowed; Traverse each node of the encoding parsing tree and query the government AI mapping dictionary: AI(92) is mapped to the rule set index RS-GOV-001, which contains: format rules (length=8, type=number), value range rules (value range [110000,820000], corresponding to the national administrative division code), and association rules (logically dependent on the market entity type code referenced by AI(95); AI(01) is mapped to the standard rule base index RS-STD-001, which contains GTIN check bit verification rules; The reflection loading mechanism dynamically instantiates rule processors based on the node AI type: AI (92) is a government-extension AI, which enters the government-specific rule library; AI (01) is a standard AI, which enters the standard rule library. The rule set is located by combining the AI ​​encoding value and the data type tag as a composite retrieval key. The code table version number v2024.3 in the node attributes is read, and the standard administrative division code table is extracted from the cache; if the cache is missing, a hot update is triggered to pull it from the authoritative source released by the Ministry of Civil Affairs; The rule set is expanded into a node-level rule execution chain: each rule is defined in the form of abstract conditions, and the actual data value of the node is bound to the placeholder. The four layers of rules are executed in a serial order: format → value domain → association → semantics, and the sub-rules within each layer are executed in parallel.

[0018] In this embodiment, the method for constructing the temporal lineage link includes: A three-dimensional anchor system is established to decouple the identity identifier, exchange transaction identifier, and content version identifier of data resources. The three-dimensional anchors are identity anchor, batch anchor, and version anchor. The identity anchor uses the global trade project code of the data resource as the identity anchor, the batch anchor uses the exchange batch series shipping box code as the batch anchor of the exchange transaction, and the version anchor uses the value corresponding to the predefined version control application identifier in the exchange body as the content version identifier. Using the shipping box code as the granularity, the lineage node attributes of each exchange batch are recorded. The lineage node attributes are bound and stored with the batch anchor point, forming atomic nodes in the time lineage link. The lineage node attributes include content hash, exchange pair, and verification result. Using the identity anchor as the aggregation key, all historical batches associated with the current data resource are arranged in time series. For adjacent versions, the system determines whether the content has changed based on the content hash of the two. If the content hashes are different, incremental difference calculation is triggered. Based on the incremental difference, the content changes between adjacent versions are identified, and Diff nodes are generated. Adjacent versions refer to two exchange batches of the same data resource that are adjacent in time series, and the version anchors are continuously incremented. The attributes recorded in the Diff node include the changed field path, the value before and after the change, the change type, and the association rule ID. Diff nodes are linked together chronologically to form an incremental Diff chain of data resources, identified by the Global Trade Item Code. By traversing the incremental Diff chain, all field-level changes between any historical version and the current version can be precisely traced back to pinpoint the time and operation that introduced data quality issues. Five types of government data lifecycle events are written into the time lineage link to form the EPCIS event chain. The five types of events are associated with the same data resource through identity anchors, with specific exchange transactions through batch anchors, and with specific content versions through version anchors, forming a standardized event sequence covering the entire lifecycle of data resources. The EPCIS event chain is written into the time lineage link and output. The five types of events are data generation events, data exchange events, data acceptance events, data update events, and data obsolescence events.

[0019] In actual evaluation, content hashing: using existing cryptographic hashing algorithms, the hash value is calculated for the complete data content of the current batch of exchanged data; exchange pair: the sender's global location code and the receiver's global location code of the batch are recorded to form a directed exchange edge, representing the flow direction of data resources; verification result: the final classification result obtained after the current batch of data has undergone multi-level automatic verification is recorded. The changed field path is the node path of the changed data field in the encoding parsing tree; the value before and after the change is the specific value of the field in two adjacent versions; the change type is the identifier that indicates whether the change is a field addition, field deletion, or field value modification; the association rule ID is the identifier of the rule if the change is triggered by the execution of a data cleaning rule, transformation rule, or verification rule, and establishes the association between content changes and rule operations in the lineage link; The three-dimensional anchor point system enables the bloodline link to have both horizontal and vertical tracking capabilities, while the freight packing box code provides precise location of exchange transactions at the intersection of the horizontal and vertical paths; the horizontal tracking capability is to associate the flow path of the same data resource between different systems through the Global Trade Item Code; the vertical tracking capability is to associate the version evolution path of the same data resource at different points in time through the GS1 application identifier AI. For the same data resource GTIN=09521101530001 (enterprise registration information), establish a three-dimensional anchor point: Identity Anchor: GTIN=09521101530001, globally uniquely identifying this data resource; Batch Anchor: Recording three historical exchange batches at the SSCC granularity: Batch B1: SSCC=000123450000000001, time 2026-06-15T10:00:00Z; Batch B2: SSCC=000123450000000002, time 2026-07-20T10:00:00Z; Batch B3: SSCC=000123450000000003, time 2026-08-23T14:30:00Z (current batch to be verified); Version Anchor: Predefined version control AI (97) in the exchange body, B1 version=v1.0, B2 version=v1.1, B3 version=v1.2; Using SSCC as the atomic node, record the attributes of the lineage nodes: B1: Content hash SHA256_a1b2..., swap pair (6951234500008→6951234500015), verification result = high confidence passed; B2: Content hash SHA256_c3d4..., swap pair same as above, verification result = high confidence passed; B3: Content hash SHA256_e5f6..., swap pair same as above, pending verification; Compare the hashes of B1 and B2. If the hash values ​​are different, the incremental difference calculation is triggered, and a Diff node is generated: Change field path: / GTIN / Government Extended Data / AI(92); Previous value: 110105 (Chaoyang District); Change value: 110108 (Haidian District); Change type: Field value modification; Association rule ID: RULE-ADDR-001 (Address change rule); The Diff nodes are linked together in chronological order to form the incremental Diff chain of this GTIN. By traversing this chain, the details of the administrative division code change from 110105 to 110108 during the period from B1 to B3 can be traced back, and the change time point can be located as 2026-07-20T10:00:00Z; At the same time, five types of EPCIS events will be written into the time lineage: data generation event (when B1 is generated), data exchange event (when B1 / B2 / B3 are exchanged), data acceptance event (when the provincial bureau receives the data), data update event (when the B2 address changes), and data obsolescence event (none).

[0020] In this embodiment, the method for constructing an automatic verification model for government data exchange based on the time kinship link includes: From the time-based lineage link, multi-dimensional lineage features are extracted according to the identity anchor points of the batch to be verified, and a lineage feature vector is constructed. The lineage feature vector encodes the four-dimensional attributes of the data resources in a structured manner and serves as the multi-dimensional input features of the automatic verification model. The four-dimensional attributes are time, space, content, and behavior. Based on the verification results of each historical batch and the corresponding bloodline feature vectors, a historical verification pattern library is constructed; the historical verification pattern library is aggregated by GTIN to establish a correlation mapping between bloodline feature vectors and verification results; Construct a verification prediction sub-model and output the bloodline prediction result: extract the bloodline feature vector of the new batch data, search the historical batch set in the historical verification pattern library where the similarity of the bloodline feature vector of the current new batch is higher than a preset threshold, if a similar historical batch is found, then calculate the distribution ratio of each verification result in the set and output the bloodline prediction result; the bloodline prediction result includes the prediction conclusion, prediction confidence, and similar historical batch reference identifier; The automated verification model integrates the rule verification results with the pedigree prediction results to make a final automated verification result. The integration decision employs a hierarchical adjudication mechanism with three layers: Layer 1: If both engines pass and the pedigree prediction is consistent, it's a high-confidence pass; if the two engines diverge, it's a medium-confidence pass, and pedigree prediction is introduced to assist in the adjudication. If the pedigree prediction conclusion contradicts the rule engine conclusion, and the prediction confidence is higher than the extremely high threshold, the automated verification model marks the data as pedigree abnormal; if both engines fail, it's a low-confidence pass, and in principle, it's classified as problematic data, unless the pedigree prediction conclusion is pass and the prediction confidence is higher than the extremely high threshold, in which case a pedigree abnormality review is triggered instead of a direct rejection. The rule verification result includes the main verification result, the shadow verification result, and the confidence score. When misjudged data is confirmed, the lineage feature vector of the misjudged batch and the confirmed actual compliance are added to the historical verification pattern library. The association mapping between the lineage feature vector corresponding to the affected data resources and the verification results in the historical verification pattern library is updated according to the misjudged data. The verification prediction sub-model is retrained. The pattern library update module included in the automatic verification model for government data exchange regularly performs automatic updates of the pattern library, eliminates outdated historical patterns that exceed the preset time window, and supplements newly generated lineage-verification associations. In practical evaluation, the time dimension features include the time interval between the first generation event of the data resource and the current exchange event, the mean and variance of the time interval between two consecutive historical exchange events, and the version update frequency per unit time; the spatial dimension features include the number of participating GLNs involved in the historical exchange of the data resource, the topology features of the exchange path, and the distribution of historical verification results of each receiving GLN; the behavioral dimension features include the temporal pattern of various events in the EPCIS event chain associated with the GTIN, the time interval between the most recent data update event and the current exchange event, and whether there are any unclosed exchange events. The historical verification pattern library supports hierarchical indexing by data resource type, participant type, exchange period, and other dimensions; the verification prediction sub-model outputs the lineage prediction result based on the matching of the lineage feature vector of the new batch of data to be verified with the historical verification pattern library. The predicted conclusion is the tending conclusion, and the prediction confidence level is calculated based on the historical consistency rate; The verification prediction sub-model enables the automatic verification model to have the ability to infer from historical experience: for data resources with historical gray-scale rule false interception rate fluctuations not exceeding the preset deviation, clear exchange paths, and regular version change patterns, even if the current batch triggers certain boundary rules, the model can improve the verification confidence based on its good historical lineage characteristics; conversely, for exchange scenarios with frequent historical changes, inconsistent cross-system versions, and low historical verification pass rates of the recipient, the model can issue early warnings and suggest strengthening the verification strategy. The main rule engine executes the node-level rule execution chain in the order of preorder traversal: AI(92) node: format passed (8-digit number), value passed (110105 exists in the code table, corresponding to Chaoyang District, Beijing), association rule passed (matches the enterprise type with the prefix 91 of AI(95) 91350100M0001), semantic rule passed; AI(94) node: format passed (8-digit date), value passed (20240815 is within a reasonable time range); The shadow rule engine uses pre-compiled static rule templates to implement equivalence verification: For AI(92), the shadow engine loads the pre-compiled regular expression ^\d{6}$ and the static administrative division code hash set, and the execution path has structural differences from the dynamic reflection mechanism of the main engine.

[0021] The main engine and the shadow engine execute synchronously and in parallel for the same batch: If both engines pass for all nodes AI(92)~AI(95) and AI(01) and AI(10), a high confidence rating is given and the data is included in the exchangeable data queue; if the main engine of node AI(93) fails (length abnormality) and the shadow engine passes (the shadow engine adopts a compatibility mode that allows 7 bits), the two engines diverge, a medium confidence rating is given, the data is included in the data queue to be reviewed, and a targeted review is triggered; if both engines of node AI(95) fail (code prefix is ​​not within the valid enumeration range), a low confidence rating is given, the data is included in the problematic government affairs data queue, and the data is returned for correction. Verification log records: Main result = Pass / Fail, Shadow result = Pass / Fail, Final confidence level = High / Medium / Low, Node rule execution details, Engine time consumption, Rule chain version number v2.1.3; For batch B3 to be verified, a four-dimensional lineage feature vector was extracted: Time dimension: 69 days since the first generation, average historical adjacent exchange interval of 32.5 days, variance of 2.25, and version update frequency of 0.5 times / month; Spatial dimension: 2 GLNs involved in history, the exchange path topology is unidirectional city → province, and the historical verification pass rate of the recipient is 100%; Content dimension: the difference between the current content hash and B2 is 0.03 (only administrative division change); Behavioral dimension: the EPCIS event chain time sequence pattern is generation → exchange → acceptance → update → exchange, the most recent update is 34 days from the current time, and there are no unclosed loop exchange events; The historical verification pattern library is aggregated by GTIN and has stored the bloodline feature vectors of B1 and B2 and their corresponding verification results: B1: Feature vector [45,30,0,0.01,2,1,1,0,0,0] → Result = Pass; B2: Feature vector [58,32,0,0.02,2,1,1,0,0,0] → Result = Pass; Verification prediction and fusion decision: The verification prediction sub-model calculates the similarity between the B3 feature vector and historical patterns (using cosine similarity): the similarity with B1 is 0.92 and the similarity with B2 is 0.98, both of which are higher than the preset threshold of 0.85; The set of similar historical batches {B1, B2} was retrieved, and the verification results were distributed as: Pass: 100%; the bloodline prediction result was output as: prediction conclusion = Pass, prediction confidence = 0.97, and similar batches referenced {B1, B2}. The automatic verification model performs hierarchical decision-making: if the main engine = pass, the shadow engine = pass, and the lineage prediction = pass: if both engines are consistent and the lineage prediction is consistent, output a high-confidence pass; If the main engine = pass, the shadow engine = fail, and the bloodline prediction = pass: the two engines diverge, but the bloodline prediction conclusion is consistent with the main engine and the prediction confidence is 0.97, which is higher than the extremely high threshold of 0.95. The confidence in the output is passed, marked "bloodline auxiliary decision", and included in the waiting review queue but given priority for release. If the main engine fails, the shadow engine fails, and the lineage prediction passes: both engines fail, but the lineage prediction confidence is 0.97 > 0.95, triggering a lineage anomaly review instead of a direct rejection. The reviewer will determine whether it is a rule-based erroneous interception by combining the historical Diff chain. If the review confirms that B3 is a misjudgment (actually compliant), the B3 feature vector and the true result are added to the historical verification pattern library, and the verification prediction sub-model is retrained. The pattern library update module periodically eliminates outdated patterns that are more than 180 days old.

[0022] In this embodiment, the method for performing multi-level automatic verification and confidence scoring of the government data includes: A master rule is used to perform multi-level automatic verification of government data. The master rule engine receives the node-level rule execution chain and performs verification of four levels of rules—format, value range, association, and semantics—on each node in the order of the preorder traversal of the encoding parse tree. The format rule verifies the data type, length, and encoding standard; the value range rule verifies the range of values ​​and the legality of enumeration; the association rule verifies the consistency of cross-field references; and the semantic rule verifies the rationality of business logic. The master verification result is output, which can be either passed or failed. Parallel execution verification is performed using a shadow rule engine, which achieves cross-validation through heterogeneous rule execution paths. The construction of the shadow rule engine follows the principles of functional equivalence and heterogeneous paths. Functional equivalence: The rule chains loaded by the shadow engine are logically and semantically equivalent to those of the main engine, meaning that the verification targets of the two rule chains are consistent for the same encoded parsing tree node and the same government data item. Path heterogeneity: The rule chains of the shadow engine have structural differences in implementation paths compared to the main engine. The main engine uses a rule loading mechanism based on dynamic reflection, while the shadow engine uses pre-compiled static rule templates to implement equivalent rules. The main rule engine and the shadow rule engine perform verification synchronously and in parallel on the same batch of government data. The shadow rule engine outputs the shadow verification result, which can be either pass or fail. When the primary verification result is passed and the shadow verification result is passed, the two heterogeneous engines, the primary rule engine and the shadow rule engine, independently determine that the data item meets the exchange standard, assign a high confidence rating, and classify the current data into the exchangeable data queue. When the primary verification result and the shadow verification result differ, a medium confidence rating is assigned, the data is placed in the data queue to be reviewed, and an intervention review process is triggered. The intervention review is a targeted review only of the nodes and related rule items where the dual engines determine the discrepancy. The reviewers make a final decision based on the original data, the rule hit details of each of the dual engines, and the context of the encoding parsing tree: if the data is confirmed to be compliant, it is corrected to be exchangeable data; if the data is confirmed to be non-compliant, it is corrected to be problematic government data. When both the primary verification result and the shadow verification result fail, a low confidence rating is assigned to both, the data is classified into the problematic government data queue, and returned to the data provider for correction. For each verification process, a logging method is used to write the main verification result, shadow verification result, final confidence rating, node rule execution details, engine execution time, and rule chain version number into the audit log.

[0023] In actual evaluation, the shadow rule chain is logically independent from the main rule chain: the shadow rules are implemented using heterogeneous logic, the version of the shadow rule set can lag behind the main rule set by one version cycle, and its external API calls point to the backup data source; In this embodiment, the method for performing rule-based audit log reverse analysis and cross-validation on the data to be reviewed includes: Reverse analysis includes rule false interception rate statistics and failure mode identification and abnormal rule identification within a specific value range; among them, the false interception rate of each rule is monitored over time, and if the increase in the false interception rate within an adjacent time window exceeds a preset threshold, the rule is marked as an abnormal rule; Audit logs are aggregated by rule ID, and the false interception rate of each rule within a preset time window is calculated. If the falsely judged data is confirmed to be compliant data through cross-validation, it is included in the false interception count of the rule triggered by the current data. The distribution analysis of the field values ​​of each data item in the false judgment dataset is performed. If it is found that the concentration of false judgments generated by a certain rule in a specific value range is higher than a preset multiple in other ranges, it is determined that the current rule has a value range sensitive defect. The value range includes a certain administrative division code segment, a certain time range, and a certain numerical range. Stratified sampling is used to select data samples to be reviewed according to a preset ratio and send them into the review process. When the data provider appeals the verification results, all data items corresponding to the appeal are sent into the review process. The appeal data includes returned data marked as problematic government data and data in which the data provider has objections to the classification of the data to be reviewed. Data that has been confirmed as compliant through the review process, or data that has been confirmed as compliant through cross-validation and is consistent with the review conclusion, will be included in the misjudged dataset. The cross-validation will send the data to be confirmed to a third independent verification channel that is different from both the main rule engine and the shadow rule engine. If the third channel determines that the current data is compliant and consistent with the review conclusion, it will be confirmed as misjudged data. Based on the rule ID associated with the misjudged dataset and the failure mode in a specific value range, the rule entries that need to be corrected are automatically located. The corrections include rule logic correction, code table correction, and API call correction. The revised rules enter the gray-scale release phase. During this phase, the revised rules run in parallel with the original rules, but the revised rules are implemented in a gray-scale manner according to the exchange batch or the granularity of the Global Trade Item Code for the data resource. All exchange requests within the same batch or the same data resource are subject to the same version of the rules. The false interception rate, normal interception rate, and consistency with the original rules are continuously monitored during the operation of the gray-scale rules. If the false interception rate of the gray-scale rules does not exceed the preset deviation within the preset observation period, and the false interception rate is significantly lower than that of the original rules, then the full implementation is triggered, and the revised rules are promoted to all exchange requests. If the gray-scale rules exhibit abnormal behavior or introduce new misjudgment patterns, the rules are automatically rolled back to the original rules, and the abnormal information is fed back to the rule optimization queue.

[0024] In actual evaluation, rule logic correction is used to adjust the thresholds, operators, or logical combinations in the rule condition expressions; code table correction is used to update the enumerated code table referenced by the rule; and API call correction is used to adjust the parameters or versions of the external verification interfaces called during rule execution. The system aggregates audit logs from the past 30 days by rule ID and calculates the false interception rate for each rule: Rule RULE-ADDR-001 (administrative division code value range verification): The false interception rate increased from 0.5% (T-1 window) to 3.2% (T window), with an increase of 2.7% in adjacent time windows, exceeding the preset threshold of 2%, and was marked as an abnormal rule; Field value distribution analysis of the misjudged dataset revealed that the concentration of misjudgments for RULE-ADDR-001 within the administrative division code range of 130000~139999 (Hebei Province) was 68%, significantly higher than the average misjudgment concentration of 8% in other ranges (multiple = 8.5, higher than the preset multiple of 3). This indicates that the rule has a value range-sensitive defect (the newly established district 130181 is missing in the administrative division code table v2024.3 of a certain province). For the 50 data entries involving 130181 in the data to be reviewed, stratified sampling was used to select 10 entries at a rate of 20% and send them into the review process; at the same time, the data provider filed an appeal against the other 30 returned data entries, and all of them were sent into the review process. The third independent verification channel (a full-scale matching engine based on regular expressions and offline code tables) cross-validated 40 data entries: the third channel determined that 38 entries were compliant, consistent with the conclusion of manual review; these 38 entries were included in the misjudged dataset, with association rule ID=RULE-ADDR-001 and specific value range=130181; Automatic location requires correction of the following entry: RULE-ADDR-001 references code table v2024.3 which is missing 130181; the correction type is code table correction: update the administrative division code table to v2024.4 and add 130181=Xinji City; Gray-scale granularity: Effective according to data resource GTIN=09521101530001. All exchange requests under this GTIN are uniformly subject to the modified rule v2.1.4-beta, while other GTINs still use the original rule v2.1.3; Parallel operation: The modified rule and the original rule are calculated in parallel, but only the modified rule actually affects the judgment result, while the result of the original rule is used for comparison and monitoring. Continuous monitoring over a 7-day observation period: the false interception rate of the gray-scale rule was 0.3%, and the normal interception rate was 4.1%; the consistency with the original rule was 98.5%; the false interception rate fluctuated within ±0.1%, not exceeding the preset deviation ±0.5%; the false interception rate of 0.3% was significantly lower than the original rule's 3.2%; Trigger full implementation: Extend v2.1.4-beta to all exchange requests, and archive the original rules v2.1.3; Suppose that after another rule, RULE-SEM-002, is released in a gray-scale deployment, the following are observed: the gray-scale rule introduces a new misjudgment pattern (misjudging the valid date 20260229 as invalid due to a leap year logic error); the false interception rate of the gray-scale rule fluctuates by ±1.2%, exceeding the preset deviation of ±0.5%; The system automatically rolls back to the original rule v2.1.3, feeds back the abnormal information (leap year logic defect) to the rule optimization queue, and waits for the developers to correct it before re-entering the gray-scale process.

[0025] 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 within the protection scope of the present invention. < / fnc1> < / fnc1> < / fnc1> < / fnc1>

Claims

1. An automatic verification method for government data exchange based on the GS1 coding rule engine, characterized in that, Includes the following steps: The system receives government data from a data provider's exchange request and preprocesses the government data. The exchange data includes an exchange header, a global location code, a data resource global trade item code, an exchange batch series shipping box code, and an exchange body. The government data is parsed using the GS1 encoding structure to construct an encoding parsing tree. Dynamic rule reflection loading and matching are then performed based on the encoding parsing tree to obtain a node-level rule execution chain. A timeline is constructed, and an automatic verification model for government data exchange is built based on the timeline. The GS1 coding rule engine is used in conjunction with the automatic verification model for government data exchange to perform multi-level automatic verification and confidence scoring on the government data, thereby obtaining exchangeable data, data to be reviewed, and problematic government data. The data to be reviewed is subjected to reverse analysis and cross-validation of the rule audit logs to obtain misjudged data, and the node-level rule execution chain and the automatic verification model for government data exchange are optimized based on the feedback of the misjudged data.

2. The automatic verification method for government data exchange based on the GS1 coding rule engine according to claim 1, characterized in that, The method for constructing the encoded parse tree includes: The received exchange request header contains global location code, data resource global trade item code, and exchange batch series shipping box code; the header is parsed using the GS1 standard decoding algorithm to extract the sender location identifier, data resource type identifier, and batch serial number identifier, which are used as attribute metadata of the root node of the encoding parsing tree; The exchange adopts a hybrid coding structure that combines the standard application identifier AI with the government extended application identifier AI; the standard AI follows the application identifier in the GS1 general specification; First, identify the AI ​​prefix identifier in the exchange data stream, and determine whether the AI ​​belongs to standard AI or government extended AI by the prefix value range; if it is government extended AI, call the preset government AI mapping dictionary to perform semantic conversion. The encoding parse tree consists of a root node, first-level child nodes, second-level and lower-level child nodes, and leaf nodes. The root node uses the exchange batch SSCC as its root node and carries batch-level metadata, including the exchange timestamp, exchange protocol version, and batch global identifier. GLN and GTIN are used as first-level child nodes. GLN corresponds to the location information of the participants in the data exchange, and GTIN corresponds to the data resource type information of the data exchange. The GLN node is connected to the sender child node and the receiver child node. The GTIN node is connected to the data resource metadata child node. The second-level and lower-level child nodes recursively parse the standard AI and government extended AI in the exchange. Each AI corresponds to an independent node in the encoding parse tree, and the node attributes include AI identifier, AI data content, AI data length, AI verification status, and node level depth. The encoding parse tree is constructed using a top-down, layer-by-layer parsing method. During the construction process, AI format validity checks are performed simultaneously. If a node fails to pass the check, the current node is marked as abnormal.

3. The automatic verification method for government data exchange based on the GS1 coding rule engine according to claim 1, characterized in that, The method for obtaining the node-level rule execution chain includes: The system traverses each node in the tree and queries the government AI mapping dictionary based on the AI ​​identifier corresponding to the node. The government AI mapping dictionary pre-defines the mapping relationship between standard AI and government extended AI to the verification rule set. The structure of the mapping dictionary is: the key is the AI ​​identifier, and the value is the rule set index corresponding to the AI. The rule set index points to the specific rule definition in the rule base. The rule definition includes rule ID, rule type, rule parameters and rule priority. Based on the query results of the mapping dictionary, each node of the encoded parse tree is dynamically assembled with a node-level rule execution chain. The construction of the rule execution chain adopts a reflection loading mechanism, which dynamically instantiates the corresponding rule processor according to the node AI type. The data field nodes are located using reflection to obtain the rule set: if the AI ​​type in the node attribute is marked as standard AI, the standard rule base is searched; if it is government-extended AI, the government-specific rule base is searched; the AI ​​code value and data type mark are combined as a composite search key to locate the verification rule set in the corresponding rule base; the associated code table version number in the node attribute is read, and the rule loader extracts standard code data from the code table cache based on the version number, using the standard code data as the comparison benchmark for value domain layer verification; if the version number is not in the cache, a hot update of the code table is triggered, and the latest version is pulled from the authoritative release source; The rule set is expanded into a node-level rule execution chain for each node: each rule is defined in the form of an abstract condition, and the actual data value, data length, and data format marker in the node attribute are bound to the placeholders of the abstract condition to generate an instantiated condition for the specific data value of the node; the actions in the rule set are instantiated into actions containing the specific context information of the node; the instantiated condition-action pairs are chained together in the original logical order of the rules to form the node-level rule execution chain for that node. The node-level rule execution chain comprises four layers of rules: format rules, value range rules, association rules, and semantic rules. These four layers are executed sequentially within the node-level rule execution chain, with each layer supporting parallel sub-rule execution. The format rules layer verifies the data type, length, encoding format, and required fields of data items. The value range rules layer verifies the value range, enumeration validity, and regular expression matching of data items. The association rules layer verifies the consistency of references between data items and other data items in the same batch, the validity of foreign keys, and logical dependencies. The semantic rules layer verifies the business semantic rationality of data items. If two rules within the same execution group have no direct dependency but are logically mutually exclusive, the conflict will be resolved according to the rule priority weights preset in the rule set; if the priorities are the same, the rules will be applied in order of newest to oldest according to their entry timestamps and written to the conflict resolution log. Assemble the data field nodes with sorted, instantiated, and pre-resolved cross-field references into node-level rule execution chains, and output them to the rule engine execution queue.

4. The automatic verification method for government data exchange based on the GS1 coding rule engine according to claim 1, characterized in that, The method for constructing the aforementioned temporal lineage includes: A three-dimensional anchor system is established to decouple the identity identifier, exchange transaction identifier, and content version identifier of data resources. The three-dimensional anchors are identity anchor, batch anchor, and version anchor. The identity anchor uses the global trade project code of the data resource as the identity anchor, the batch anchor uses the exchange batch series shipping box code as the batch anchor of the exchange transaction, and the version anchor uses the value corresponding to the predefined version control application identifier in the exchange body as the content version identifier. Using the shipping box code as the granularity, the lineage node attributes of each exchange batch are recorded. The lineage node attributes are bound and stored with the batch anchor point, forming atomic nodes in the time lineage link. The lineage node attributes include content hash, exchange pair, and verification result. Using the identity anchor as the aggregation key, all historical batches associated with the current data resource are arranged in time series. For adjacent versions, the system determines whether the content has changed based on the content hash of the two. If the content hashes are different, incremental difference calculation is triggered. Based on the incremental difference, the content changes between adjacent versions are identified, and Diff nodes are generated. Adjacent versions refer to two exchange batches of the same data resource that are adjacent in time series, and the version anchors are continuously incremented. The attributes recorded in the Diff node include the changed field path, the value before and after the change, the change type, and the association rule ID. Diff nodes are linked together chronologically to form an incremental Diff chain of data resources, identified by the Global Trade Item Code. By traversing the incremental Diff chain, all field-level changes between any historical version and the current version can be precisely traced back to pinpoint the time and operation that introduced data quality issues. Five types of government data lifecycle events are written into the time lineage link to form the EPCIS event chain. The five types of events are associated with the same data resource through identity anchors, with specific exchange transactions through batch anchors, and with specific content versions through version anchors, forming a standardized event sequence covering the entire lifecycle of data resources. The EPCIS event chain is written into the time lineage link and output. The five types of events are data generation events, data exchange events, data acceptance events, data update events, and data obsolescence events.

5. The automatic verification method for government data exchange based on the GS1 coding rule engine according to claim 4, characterized in that, The method for constructing an automatic verification model for government data exchange based on the aforementioned time-series data includes: From the time-based lineage link, multi-dimensional lineage features are extracted according to the identity anchor points of the batch to be verified, and a lineage feature vector is constructed. The lineage feature vector encodes the four-dimensional attributes of the data resources in a structured manner and serves as the multi-dimensional input features of the automatic verification model. The four-dimensional attributes are time, space, content, and behavior. Based on the verification results of each historical batch and the corresponding bloodline feature vectors, a historical verification pattern library is constructed; the historical verification pattern library is aggregated by GTIN to establish a correlation mapping between bloodline feature vectors and verification results; Construct a verification prediction sub-model and output the bloodline prediction result: extract the bloodline feature vector of the new batch data, search the historical batch set in the historical verification pattern library where the similarity of the bloodline feature vector of the current new batch is higher than a preset threshold, if a similar historical batch is found, then calculate the distribution ratio of each verification result in the set and output the bloodline prediction result; the bloodline prediction result includes the prediction conclusion, prediction confidence, and similar historical batch reference identifier; The automated verification model integrates the rule verification results with the pedigree prediction results to make a final automated verification result. The integration decision employs a hierarchical adjudication mechanism with three layers: Layer 1: If both engines pass and the pedigree prediction is consistent, it's a high-confidence pass; if the two engines diverge, it's a medium-confidence pass, and pedigree prediction is introduced to assist in the adjudication. If the pedigree prediction conclusion contradicts the rule engine conclusion, and the prediction confidence is higher than the extremely high threshold, the automated verification model marks the data as pedigree abnormal; if both engines fail, it's a low-confidence pass, and in principle, it's classified as problematic data, unless the pedigree prediction conclusion is pass and the prediction confidence is higher than the extremely high threshold, in which case a pedigree abnormality review is triggered instead of a direct rejection. The rule verification result includes the main verification result, the shadow verification result, and the confidence score. When misjudged data is confirmed, the lineage feature vector of the misjudged batch and the confirmed actual compliance are added to the historical verification pattern library. The association mapping between the lineage feature vector corresponding to the affected data resources and the verification results in the historical verification pattern library is updated according to the misjudged data, and the verification prediction sub-model is retrained. The pattern library update module included in the automatic verification model for government data exchange regularly performs automatic updates of the pattern library, eliminates outdated historical patterns that exceed the preset time window, and supplements newly generated lineage-verification associations.

6. The automatic verification method for government data exchange based on the GS1 coding rule engine according to claim 1, characterized in that, A method for performing multi-level automatic verification and confidence scoring of the aforementioned government data includes: A master rule is used to perform multi-level automatic verification of government data. The master rule engine receives the node-level rule execution chain and performs verification of four levels of rules—format, value range, association, and semantics—on each node in the order of the preorder traversal of the encoding parse tree. The format rule verifies the data type, length, and encoding standard; the value range rule verifies the range of values ​​and the legality of enumeration; the association rule verifies the consistency of cross-field references; and the semantic rule verifies the rationality of business logic. The master verification result is output, which can be either passed or failed. Parallel execution verification is performed using a shadow rule engine, which achieves cross-validation through heterogeneous rule execution paths. The construction of the shadow rule engine follows the principles of functional equivalence and heterogeneous paths. Functional equivalence: The rule chains loaded by the shadow engine are logically and semantically equivalent to those of the main engine, meaning that the verification targets of the two rule chains are consistent for the same encoded parsing tree node and the same government data item. Path heterogeneity: The rule chains of the shadow engine have structural differences in implementation paths compared to the main engine. The main engine uses a rule loading mechanism based on dynamic reflection, while the shadow engine uses pre-compiled static rule templates to implement equivalent rules. The main rule engine and the shadow rule engine perform verification synchronously and in parallel on the same batch of government data. The shadow rule engine outputs the shadow verification result, which can be either pass or fail. When the primary verification result is passed and the shadow verification result is passed, the two heterogeneous engines, the primary rule engine and the shadow rule engine, independently determine that the data item meets the exchange standard, assign a high confidence rating, and classify the current data into the exchangeable data queue. When the primary verification result and the shadow verification result differ, a medium confidence rating is assigned, the data is placed in the data queue to be reviewed, and an intervention review process is triggered. The intervention review is a targeted review only of the nodes and related rule items where the dual engines determine the discrepancy. The reviewers make a final decision based on the original data, the rule hit details of each of the dual engines, and the context of the encoding parsing tree: if the data is confirmed to be compliant, it is corrected to be exchangeable data; if the data is confirmed to be non-compliant, it is corrected to be problematic government data. When both the primary verification result and the shadow verification result fail, a low confidence rating is assigned to both, the data is classified into the problematic government data queue, and returned to the data provider for correction. For each verification process, a logging method is used to write the main verification result, shadow verification result, final confidence rating, node rule execution details, engine execution time, and rule chain version number into the audit log.

7. The automatic verification method for government data exchange based on the GS1 coding rule engine according to claim 1, characterized in that, The method for performing rule-based audit log reverse analysis and cross-validation on the data to be reviewed includes: Reverse analysis includes rule false interception rate statistics and failure mode identification and abnormal rule identification within a specific value range; among them, the false interception rate of each rule is monitored over time, and if the increase in the false interception rate within an adjacent time window exceeds a preset threshold, the rule is marked as an abnormal rule; Audit logs are aggregated by rule ID, and the false interception rate of each rule within a preset time window is calculated. If the falsely judged data is confirmed to be compliant data through cross-validation, it is included in the false interception count of the rule triggered by the current data. The distribution analysis of the field values ​​of each data item in the false judgment dataset is performed. If it is found that the concentration of false judgments generated by a certain rule in a specific value range is higher than a preset multiple in other ranges, it is determined that the current rule has a value range sensitive defect. The value range includes a certain administrative division code segment, a certain time range, and a certain numerical range. Stratified sampling is used to select data samples to be reviewed according to a preset ratio and send them into the review process. When the data provider appeals the verification results, all data items corresponding to the appeal are sent into the review process. The appeal data includes returned data marked as problematic government data and data in which the data provider has objections to the classification of the data to be reviewed. Data that has been confirmed as compliant through the review process, or data that has been confirmed as compliant through cross-validation and is consistent with the review conclusion, will be included in the misjudged dataset. The cross-validation will send the data to be confirmed to a third independent verification channel that is different from both the main rule engine and the shadow rule engine. If the third channel determines that the current data is compliant and consistent with the review conclusion, it will be confirmed as misjudged data. Based on the rule ID associated with the misjudged dataset and the failure mode in a specific value range, the rule entries that need to be corrected are automatically located. The corrections include rule logic correction, code table correction, and API call correction. The revised rules enter the gray-scale release phase. During this phase, the revised rules run in parallel with the original rules, but the revised rules are implemented in a gray-scale manner according to the exchange batch or the granularity of the Global Trade Item Code for the data resource. All exchange requests within the same batch or the same data resource are subject to the same version of the rules. The false interception rate, normal interception rate, and consistency with the original rules are continuously monitored during the operation of the gray-scale rules. If the false interception rate of the gray-scale rules does not exceed the preset deviation within the preset observation period, and the false interception rate is significantly lower than that of the original rules, then the full implementation is triggered, and the revised rules are promoted to all exchange requests. If the gray-scale rules exhibit abnormal behavior or introduce new misjudgment patterns, the rules are automatically rolled back to the original rules, and the abnormal information is fed back to the rule optimization queue.

Images