A natural resource data consistency checking system based on a rule engine

Abstract

The application discloses a natural resource data consistency checking system based on a rule engine and belongs to the technical field of data processing, which comprises a data sensing module, a rule responding module, a dynamic decision module, a collaborative evolution module, a conclusion generating module, an adversarial verification module and a report generating module. Through multi-agent collaborative calculation and dynamic optimization decision, the application can realize natural resource data consistency checking and credible level grading report generation.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a natural resource data consistency check system based on a rule engine. Background Technology

[0002] In the field of natural resource data management, data consistency checks are a crucial step in ensuring data quality and supporting business decisions. This process involves verifying the compliance of massive amounts of spatial and non-spatial data based on predefined data quality constraints and business logic specifications. This invention relates to an automated checking system based on a rule engine.

[0003] Currently, a common automated inspection solution involves building a centralized rule base and encoding the specific inspection logic into fixed scripts or programs. During system runtime, these inspection programs are invoked according to a predefined order or simple trigger conditions to perform batch, independent rule matching and validation operations on the data blocks to be inspected. Another approach is to encapsulate different inspection rules as independent services and then linearly orchestrate and invoke them through a workflow engine.

[0004] However, the matching relationship between rules and inspection execution resources is usually statically preset, making it difficult to dynamically adjust and optimize according to the complexity of specific data blocks and the real-time needs of inspection dimensions. Secondly, the various inspection units are isolated from each other during operation, lacking an effective mid-process information exchange and collaboration mechanism, which prevents the inspection process from dynamically evolving based on discovered clues. Finally, the inspection conclusions output by the system are usually unidirectional and final, lacking a built-in, systematic procedure to proactively and multi-dimensionally verify and challenge the preliminary conclusions. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides a natural resource data consistency check system based on a rule engine. Through multi-agent collaborative computation and dynamic optimization decision-making, it can achieve consistency checks and generate credibility grading reports for natural resource data.

[0006] The above objectives can be achieved through the following approach: A natural resource data consistency check system based on a rule engine includes: The data perception module is used to acquire the natural resource target data block to be inspected, and to perform multi-dimensional feature analysis on the natural resource target data block to generate diagnostic demand signals. The rule response module is used to broadcast the diagnostic requirement signal to a preset intelligent agent resource pool containing multiple intelligent agents. Each intelligent agent in the intelligent agent resource pool generates and submits a performance application report containing expected performance indicators and resource requirement estimates based on the diagnostic requirement signal. The dynamic decision-making module is used to make multi-objective optimization decisions based on all the received performance application reports, dynamically filter and form a collaborative diagnostic team for the natural resource target data block; The collaborative evolution module is used to drive each agent in the collaborative diagnostic team to inspect the natural resource target data block. During the execution process, a real-time problem data sharing channel is established, allowing any agent to publish the problem data it discovers to the real-time problem data sharing channel, and enabling other agents in the collaborative diagnostic team to subscribe to and use the problem data to adjust their inspection behavior. The conclusion generation module is used to aggregate the inspection results of all agents in the collaborative diagnostic team to form a preliminary diagnostic conclusion for the natural resource target data block; The adversarial verification module is used to generate a reverse verification proposition that is logically opposite to the preliminary diagnostic conclusion based on the preliminary diagnostic conclusion, and to call or combine agents in the agent resource pool to perform reverse evidence search on the target data block to obtain the reverse verification result. The report generation module is used to perform conflict resolution and evidence weight assessment using the preliminary diagnostic conclusions and the reverse verification results, and generate a structured quality diagnostic report containing a credibility level.

[0007] Compared with the prior art, the present invention has the following advantages: This invention uses a dynamic decision-making module to make multi-objective optimization decisions based on the performance application reports submitted by each intelligent agent to form a collaborative diagnostic team. This enables the system to dynamically configure inspection resources according to the characteristics of different data blocks, thereby improving the matching degree between resource utilization and task requirements.

[0008] This invention establishes a real-time problem data sharing channel through a collaborative evolution module, allowing intelligent agents to dynamically interact based on structured problem data units and adjust their respective inspection behaviors, thereby enhancing the detection and adaptation capabilities for complex correlation errors.

[0009] This invention introduces a procedural verification step into automated inspection by logically inverting the preliminary diagnostic conclusions and organizing reverse verification through an adversarial verification module, thereby improving the reliability of the final conclusions. Fourth, the report generation module arbitrates conflicts and assigns credibility levels based on evidence weights and rule priorities, enabling the output diagnostic report to quantitatively reflect the uncertainty of the problem assertion and providing a more detailed basis for subsequent decision-making. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of the structure of a natural resource data consistency check system based on a rule engine according to an embodiment of the present invention.

[0011] Figure 2This is a flowchart illustrating a natural resource data consistency check method based on a rule engine according to an embodiment of the present invention. Detailed Implementation

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

[0013] Reference Figure 1 One embodiment of the present invention proposes a natural resource data consistency check system based on a rule engine. Through multi-agent collaborative computing and dynamic optimization decision-making, it can realize the consistency check of natural resource data and the generation of a credibility classification report.

[0014] The system described in this embodiment specifically includes: Reference Figure 2 The data perception module is used to acquire the natural resource target data block to be inspected, and to perform multi-dimensional feature analysis on the natural resource target data block to generate diagnostic demand signals. Specifically, the data perception module reads the natural resource target data block to be inspected from a pre-configured data interface, such as a database connection address or file system directory. This data block may be stored in a specific format, such as the Shapefile vector data format commonly used in Geographic Information Systems (GIS), a database table containing attribute information, or an image file with geographic tags. The system extracts features representing the data content by parsing the metadata information of the data block or reading partial sample data within it. These features are input into a pre-built knowledge base storing natural resource data classification relationships for matching and mapping. The knowledge base defines feature templates for different data content types, such as parcel boundaries, mineral resource reserves, and land use patches. Through feature matching, the system determines the content type that best matches the data block. Subsequently, the system uses a business domain mapping table, which specifies the standard business domain to which different content types belong, such as mapping "parcel boundaries" to the "real estate registration" domain. Finally, the system generates a string with a unique identifier as a domain classification label, and the encoding rules of this label follow the industry standards for natural resource information classification and coding.

[0015] The data awareness module uses the domain classification tags obtained in the previous step as the primary search key to initiate a query to the rule and standard resource library maintained internally by the system. This resource library is a relational database or knowledge graph, and its structure is designed so that each data quality constraint rule and business logic specification is associated with one or more domain classification tags through metadata. Data quality constraint rules include mandatory requirements for data format, precision, completeness, and uniqueness, such as "the number of decimal places for coordinate points must not exceed 6" and "the parcel identifier field cannot be empty." Business logic specifications define the semantic relationships that must be satisfied between data items, such as "the sum of the forest areas under the same zone must not exceed the total land area of ​​the zone." The system executes the query operation, retrieving all rule and specification entries directly associated with the input domain classification tags, as well as those indirectly associated through hierarchical inheritance relationships. The system deduplicates and sorts these retrieved entries, organizing them into a structured set according to rule type and inspection priority. This set is the constraint rule set for the current target data block. The resource database is constructed based on digital modeling of the clauses of a series of published technical regulations, such as the land use database standard and the method for assessing and identifying mineral resource reserves.

[0016] The data perception module first performs structural parsing on the natural resource target data blocks. If the data block is a database table, it reads its table name, the names of all fields, data types, and constraint information. If the data block is spatial vector data, it reads its layer names, geometric types, attribute table structure, and spatial reference system. Next, the system compares this data structure information with the constraint rule set item by item. During the comparison, the system identifies fields in the data structure that are explicitly pointed to or constrained by a rule in the constraint rule set, marking these fields as key fields. Simultaneously, the system analyzes whether there are dependency, computation, or mutual exclusion relationships between key fields defined by business logic specifications; for example, field A is the basis for the computation of field B, or the combination of values ​​for field C and field D must conform to a certain enumeration relationship. Based on the identified set of key fields and their logical relationships, the system generates a diagnostic dimension list, where each item corresponds to a specific inspection task to be performed, with the task objective derived from the constraint rule set. For each diagnostic dimension in the list, the system automatically generates an initial problem hypothesis based on a library of common data error patterns. For example, under the "coordinate precision check" dimension, the hypothesis "there may be coordinate values ​​exceeding the effective number of digits limit" is generated. Finally, the system encapsulates the domain classification label, constraint rule set, diagnostic dimension list, and initial problem hypothesis into a data structure object conforming to a predetermined interface specification. This object is the final generated diagnostic requirement signal used to drive subsequent modules.

[0017] For example, for a farmland protection data block to be inspected, the data awareness module obtains a Shapefile format file package from a specified file server path. By parsing its ".dbf" attribute header and ".shp" file header information, features such as "land type name," "area," and "geometric polygon" are extracted. These features are matched with templates in the knowledge base to determine the content type as "farmland patch vector data." The business domain mapping table is queried to obtain the domain classification label "TDGY_01." Using this label, the rules and standard resource library are queried to retrieve data quality constraint rules including "the patch area field value must be greater than 0" and "the land type code must exist in the latest annual change survey code table," as well as business logic specifications such as "the geometric range of farmland patches must not intersect with the construction land planning range in the overall land use plan of the same period," forming a constraint rule set. The structure of the Shapefile is parsed to extract key fields such as "area," "land type code," and "geometric shape," and the relationship between the "geometric shape" field and the external "planning range layer" needs to be spatially validated is identified. Based on this, a list of diagnostic dimensions is generated, including "positive area verification," "land category code validity verification," and "spatial conflict verification with planned construction land." The system associates the initial problem assumption for the "positive area verification" dimension with "the possibility of invalid map cell records with zero or negative areas." The final synthesized diagnostic requirement signal is a JSON object containing labels, rule sets, lists, and assumptions.

[0018] The rule response module is used to broadcast the diagnostic requirement signal to a preset intelligent agent resource pool containing multiple intelligent agents. Each intelligent agent in the intelligent agent resource pool generates and submits a performance application report containing expected performance indicators and resource requirement estimates based on the diagnostic requirement signal. Specifically, after constructing the diagnostic request signal, the rule response module immediately performs a broadcast operation through a central message scheduler. This central message scheduler maintains the network addresses or queue identifiers of all registered agents. The diagnostic request signal is converted into a standard serialized message based on JSON or Protocol Buffers format. Subsequently, the scheduler simultaneously pushes a copy of this message to the independent message queue or topic channel listened to by each agent in the agent resource pool. The agent resource pool is initialized before system operation, and each registered agent is abstracted as a service instance with a unique ID, specific functional description, and active state. The broadcast process ensures that all agents in the pool with a "ready" state receive the exact same copy of the diagnostic request signal in near real-time, establishing the communication foundation for subsequent parallelized and distributed responses.

[0019] Each agent residing in the agent resource pool has a continuously running message listening loop within its process. This loop is triggered when a new broadcast message is received in the agent's dedicated message queue. The agent first deserializes the received raw message, restoring it from its transmission format to a structured data object in memory. Next, the agent accesses this data object and extracts the field content named "Diagnostic Dimension List" according to predefined signal structure specifications. The Diagnostic Dimension List itself is an array or list structure that sequentially stores multiple strings or codes, each element representing a dimension to be checked, such as "DIM_001: Coordinate Precision Compliance" and "DIM_002: Attribute Field Integrity." After parsing, the agent obtains all target dimension items for this inspection task in memory.

[0020] Each agent loads a proprietary, structured knowledge base during initialization. This knowledge base exists in the form of key-value pairs, rule trees, or feature vectors, explicitly recording all diagnostic dimension types that the agent can handle and their matching conditions. The agent sequentially calculates the similarity or performs exact matching between each dimension item in the diagnostic dimension list obtained in the previous step and the dimension type recorded in its own knowledge base. The matching process may involve string comparison, semantic encoding mapping, or logical judgment of rule preconditions. For a dimension item in the diagnostic dimension list, if it meets the matching threshold condition with a record in the knowledge base, the dimension item is marked as "processable." After traversing the entire diagnostic dimension list, all dimension items marked as "processable" are collected to form a new set, which is the subset of diagnostic dimensions determined by the agent for the current task. If no dimension item matches successfully, an empty subset of diagnostic dimensions is generated.

[0021] The agent first calculates the coverage metric. Coverage is defined as the ratio of the number of dimension items contained in the agent's diagnostic dimension subset to the total number of dimension items contained in the original diagnostic dimension list in the diagnostic requirement signal. For coverage, we have: , in, The coverage rate is a dimensionless value between 0 and 1. Represents a subset of diagnostic dimensions; This represents the number of dimension items contained in the subset; Represents the original list of diagnostic dimensions; This represents the total number of dimension items in the original list. Next, the agent predicts the estimated execution time. The agent uses its internally pre-set performance benchmark model, trained on historical execution data, to diagnose the subset of dimensions. Each item in Estimate a processing time Then, sum the estimated times for all items to obtain the estimated time. : , Among them, the estimated time The unit is usually milliseconds. The expected performance index P is a comprehensive measure, which can be defined, for example, as: ,in and These are preset weighting coefficients used to balance coverage and efficiency. Their sum is 1, and the setting is based on the trade-off between the overall system throughput and the requirements for inspection integrity. The estimated time is the maximum value. The resource requirement estimate R is obtained by querying the agent's built-in resource configuration file, which lists the typical computing resources required to execute various inspection dimensions, such as memory usage (MB) and the number of CPU cores. The final estimate is the union or sum of the resource requirements of each inspection within the subset. Finally, the agent encapsulates its own ID, diagnostic dimension subset S, coverage C, estimated time T, expected performance index P, and resource requirement estimate R into a new structured data object according to a unified interface specification. This object is the performance request report, which is sent back to the system's dynamic decision-making module via the network.

[0022] For example, the diagnostic request signal broadcast by the system contains a list L of raw diagnostic dimensions with 5 codes: [“GEO_ACC”, “ATTR_FULL”, “VAL_RANGE”, “LOGIC_CONS”, “TOPOLOGY”]. Agent X in the agent resource pool declares in its knowledge base that it can process two dimensions: [“ATTR_FULL”, “LOGIC_CONS”]. After receiving and parsing the signal, agent X compares each item in list L with its own knowledge base to determine the diagnostic dimension subset S as [“ATTR_FULL”, “LOGIC_CONS”]. Based on this, the coverage is calculated as C = 2 / 5 = 0.4. Its performance model estimates that processing “ATTR_FULL” will take 50 milliseconds and “LOGIC_CONS” will take 80 milliseconds, so the total estimated processing time is T = 130 milliseconds. Assuming α = 0.7 and β = 0.3, the expected performance index is calculated as P ≈ 0.282. Its resource configuration file shows that processing these two types of checks requires a total of 1 CPU core and 256MB of memory; this is the estimated resource requirement. Finally, agent X encapsulates {ID:“AgentX”,Subset:S,Coverage:C,EstTime:T,PerfIndex:P,ResourceEst:R} into a performance request report and submits it.

[0023] The dynamic decision-making module is used to make multi-objective optimization decisions based on all the received performance application reports, dynamically filter and form a collaborative diagnostic team for the natural resource target data block; Specifically, within a preset deadline window, the dynamic decision-making module collects performance request reports asynchronously submitted by each agent in the agent resource pool. The module parses each report, extracting and structuredly storing the agent identifier, diagnostic dimension subset, coverage, estimated execution time, expected performance metrics, and resource requirement estimate. The resource requirement estimate is typically a multi-dimensional vector, including quantitative requirements for resources such as the number of CPU cores, memory size, and expected execution time. Subsequently, the module constructs a multi-objective optimization model based on this data. This model treats each agent as a decision variable, with its value indicating whether the agent is selected. The model presets two core optimization objectives: the first is to maximize the overall diagnostic coverage of the selected agent set, defined by calculating the completeness of the union of the diagnostic dimension subsets committed by these agents relative to the original diagnostic dimension list; the second objective is to minimize the overall resource consumption of the selected agent set, i.e., summing the resource requirement estimates of all selected agents across the multi-dimensional resources. The model includes a key constraint that requires the union of the diagnostic dimension subsets of the selected agents to completely cover the original list of diagnostic dimensions in the diagnostic requirement signal, or at least reach a preset minimum coverage threshold, such as 95%. This threshold is set based on the minimum tolerance standard for data integrity in business operations.

[0024] After transforming the multi-objective optimization problem into a computable format, the dynamic decision-making module calls the built-in optimization solver for processing. Due to the large number of agents and the complexity of selection and combination, heuristic algorithms such as non-dominated sorting genetic algorithms are often used for approximate solutions, or integer linear programming solvers are used to obtain exact solutions when the problem size is small. A practical approach is to transform the multi-objective problem into a single-objective optimization by constructing a comprehensive scoring function. This function merges the overall diagnostic coverage and overall resource consumption objectives. Considering the different dimensions of the two objectives—coverage is a dimensionless ratio between 0 and 1, while resource consumption is a physical quantity with tangible units (such as kernel-second or megabyte)—they must be normalized to eliminate the influence of dimensions. Comprehensive Scoring Function It can be represented as: , in, This represents the overall score, aiming for the highest possible value. This represents the overall diagnostic coverage that a certain combination of agents to be evaluated can achieve; This is the theoretical maximum coverage, typically 1; The total resource consumption value representing this combination can be transformed from a multidimensional resource demand vector into a single scalar resource cost through weighted summation or other methods. It is a reference benchmark value for resource consumption, such as the sum of the resource requirements of all agents or the total available resources of the system converted into a single scalar resource cost, used to assess... Perform normalization; This is a preset tradeoff coefficient, ranging from 0 to 1, used to adjust the preference for coverage versus resource consumption. Its specific value is set by the system administrator based on task urgency and resource sufficiency. The solver traverses or searches the space of possible agent combinations, calculating a comprehensive score for each combination. Final selection The combination of agents with the highest value is taken as the optimal solution. The list of agent identifiers corresponding to this optimal solution is the obtained agent combination scheme.

[0025] After obtaining the agent composition scheme, the dynamic decision-making module generates a scheduling instruction containing the identifiers of all agents in the scheme. This instruction is sent to the service manager of the agent resource pool. The service manager maintains a registry and state machine for all agent instances. Based on the identifier list in the instruction, the manager queries the registry for the corresponding agent instance and checks whether its current state is "idle" or "schedulable". For all agents whose states meet the conditions, the manager sends a unified "task binding" command to them. The command contains the task identifier of this collaborative diagnostic task, the target data block access path, and the address information of the dedicated group communication channel created for this task. At the same time, the manager updates the state of these agent instances to "bound to task [task identifier]". This series of operations logically links these originally independent agent instances together, forming a task execution group with a common task goal and a shared communication context, namely the collaborative diagnostic group. After the group is formed, its ready signal is sent to the system's collaborative evolution module to drive subsequent inspection work.

[0026] For example, the dynamic decision-making module receives three performance request reports from agents Alpha, Beta, and Gamma. The original diagnostic dimension list L includes three items: {localization accuracy, attribute completeness, and logical consistency}. The diagnostic dimension subset for agent Alpha is {localization accuracy}, with resource requirements of {CPU: 1 core, memory: 200MB}; for Beta, the subset is {attribute completeness, logical consistency}, with resource requirements of {CPU: 2 cores, memory: 300MB}; and for Gamma, the subset is {attribute completeness}, with resource requirements of {CPU: 1 core, memory: 150MB}. The preset minimum coverage threshold is 100%. The module builds a model and determines the decision variables. These represent whether the corresponding agent is selected. The goal is... and The constraints are: Covering "positioning accuracy", Covering "attribute completeness", This covers "logical consistency". (Settings) , Take the sum of resources from all agents. The solver calculates the coverage when the {Alpha, Beta} combination is selected. ,resource nuclear, Normalized composite score The highest. Therefore, the agent composition scheme is: Based on this scheme, the module schedules the intelligent agents Alpha and Beta, sends them task binding instructions, and updates their status to "bound," thereby forming a collaborative diagnostic team.

[0027] The collaborative evolution module is used to drive each agent in the collaborative diagnostic team to inspect the natural resource target data block. During the execution process, a real-time problem data sharing channel is established, allowing any agent to publish the problem data it discovers to the real-time problem data sharing channel, and enabling other agents in the collaborative diagnostic team to subscribe to and use the problem data to adjust their inspection behavior. Specifically, after receiving the collaborative diagnostic team formation instruction from the dynamic decision-making module, the collaborative evolution module sends a start instruction to all agent members within the team. This instruction contains the storage path of the target data block. Each agent, as an independent software service instance, begins to access the target data block in parallel and performs analysis according to its internally loaded check procedures for specific data quality constraints or business logic specifications.

[0028] The co-evolution module also instantiates a communication component for the group: a real-time problem data sharing channel. This channel is technically implemented as a publish-subscribe message queue, built using middleware such as RabbitMQ or Apache Kafka. The channel's topic identifier is synchronously distributed to all agents within the group. To ensure unambiguous information exchange, the channel mandates that all transmitted data adhere to a predefined, JSON Schema-based structured data format. This format includes fields such as a unique problem identifier (UUID), problem type code, source agent identifier, problem data location, trigger rule reference, problem description text, and discovery timestamp. The problem type code's value range comes from a predefined and system-embedded problem classification dictionary, including categories such as "numerical range violation," "format mismatch," "logical contradiction," and "spatial relationship conflict." The design of this structured data format is based on the summarization and abstraction of key information elements from over two hundred historical natural resource data quality problem cases.

[0029] When executing its inspection procedure, the agent identifies inconsistent data or rule conflicts by comparing actual data values ​​with expected rule values ​​or reasoning about the constraint relationships between multiple rules. Once identified, the agent immediately initiates the encapsulation process. It generates a globally unique UUID, retrieves the corresponding problem type code from an internal mapping table, fills in its own identifier, precisely records the position of the problem data in the target data block, references the specific rule number that was triggered, writes a brief description of the problem phenomenon, and records the current system time. These fields are strictly organized into a JSON object according to the above structured data format, thus forming a standardized problem data unit. After encapsulation, the agent calls the application programming interface provided by the message middleware to publish this problem data unit as a message to the corresponding real-time problem data sharing channel topic of its group. The publishing action is asynchronous and non-blocking.

[0030] During the initialization phase of the collaborative diagnostic team, each agent declares its subscription conditions to the real-time problem data sharing channel based on its functional scope and knowledge base definition. The subscription is based on the problem type code or the rule set to which the triggering rule reference belongs. When an agent publishes a problem data unit, the message middleware automatically pushes it to all other eligible agents based on the subscription relationship. These other agents within the collaborative diagnostic team who have subscribed to the relevant type receive the unit through their message listening service.

[0031] After receiving the content of the problematic data unit from the intelligent agent, it adjusts its behavior according to the preset response strategy. This adjustment is mainly reflected in two aspects. First, it triggers internal rule updates, such as adding the new error pattern revealed by the problematic data unit as a temporary rule or empirical threshold to its rule base for subsequent judgments in similar situations. Second, it adjusts subsequent inspection logic and data scanning paths. For example, upon receiving a problematic data unit indicating a specific contradiction in data from a certain region, the agent may immediately pause the full table scan and instead prioritize and concentrate computing resources on a deep review of the data in that region, or modify its analysis algorithm to improve detection sensitivity. Through this mechanism, agents within the group can share intermediate findings during inspections, achieving collaborative evolution and dynamic optimization of inspection strategies.

[0032] For example, for a land use planning patch data block, the collaborative diagnostic team includes agent A and agent B. The collaborative evolution module drives both to start checking and establishes a real-time problem data sharing channel identified as "Task_Plan_Land_Check", which adopts the aforementioned structured data format. During the check, agent A discovers that the "planned use code" and "current land type code" of a certain patch are contradictory under the same business rule, constituting a rule conflict. Agent A then encapsulates a problem data unit, which includes the UUID "ERR-20231027-001", the problem type code "logical contradiction", the source agent identifier "Agent_A", the problem data location "FeatureID: PL-00567", the triggering rule reference "Rule_LandUse_Compat_01", the problem description "the planned use and current land type of the patch conflict under the compatibility rule", and the discovery timestamp "2023-10-27T10:30:00Z". This unit was published to the "Task_Plan_Land_Check" channel. Agent B subscribed to all problem types related to "logical contradictions," so it received this unit in real time. After parsing, although Agent B was primarily responsible for area balance checks, its internal strategy was triggered. It marked the problem patch's "FeatureID: PL-00567" as a key object requiring verification and prioritized the verification of all area summary data related to this patch in subsequent checks, thereby adjusting its original data scanning path and verification priority.

[0033] Specifically, under the coordination of the co-evolution module, after an agent within the co-diagnostic team updates its internal rules or inspection logic based on the problem data unit, a resource reassessment process is triggered. This process is executed by the resource estimator within the agent. The resource estimator accesses a resource configuration template bound to the agent's functionality. This template defines, in key-value pairs or tables, the typical amount of computational resources required to perform various inspection operations, such as attribute verification, spatial analysis, and logical reasoning. Based on the agent's currently effective and adjusted new behavior configuration, the resource estimator queries the corresponding resource entries from the template. These entries typically include values ​​for dimensions such as CPU core usage, memory usage, and expected processing time. The resource estimator uses an additive method to calculate the overall resource requirements under the new configuration; that is, for each resource dimension, it adds the resource values ​​required by all operations involved in the new behavior to generate a new resource requirement estimate. This estimate is a multi-dimensional vector, for example, represented as a demand vector: .

[0034] The agent will reassess the estimated resource requirements. Compared with the original resource requirement estimate submitted at the initial stage of the task. For quantitative comparison, the system defines a scalarized resource cost function Cb(R). This function maps the multidimensional resource demand vector R to a single comprehensive cost value. One feasible mapping method is weighted summation, i.e.: , Among them, the weighting coefficient , These are real numbers greater than zero, and their setting is based on the quantitative assessment of the cost per unit of different resources in system operation and maintenance, such as determining them based on cloud service pricing models or local hardware power consumption models. These coefficients are usually preset during system deployment and can be adjusted according to strategies.

[0035] Calculate the original cost With new costs Then calculate the relative difference ratio. : , in, It is a dimensionless numerical value representing the magnitude of changes in resource costs. Preset demand threshold. It is a constant pre-configured in the system's global parameters. Threshold The value is set between 0.1 and 0.5, and this range is based on the results of a balancing test of the stability and agility of system resource scheduling, for example, by determining the value through historical task simulation. This can achieve a better balance between avoiding frequent reconfiguration and preventing resource overload. The specific value is flexibly set by the system administrator based on the actual hardware resources.

[0036] The agent will calculate and Compare. If If the resource demand changes significantly, the agent will generate a resource demand update signal. This signal is a structured message and must include the identifier of the agent that generated the signal, the task identifier of the collaborative diagnostic team to which it belongs, and a detailed reassessed estimate of the resource demand. Calculated difference ratio And the relevant data unit references that triggered this revaluation. If If not, no signal will be generated.

[0037] The collaborative evolution module's team coordinator continuously listens for and captures resource requirement update signals from any agent. Upon receiving a signal, the team coordinator immediately initiates a round of dynamic adjustment decisions. These decisions are based on two real-time pieces of information: first, a snapshot of the current state of all agents within the collaborative diagnostic team, collected through a heartbeat mechanism or status reporting interface, containing each agent's identifier, health status, current actual resource usage, and a list of assigned subtasks; and second, the newly received resource requirement update signal.

[0038] Dynamic adjustments follow a pre-defined decision-making logic within the team coordinator. The goal of this logic is to maintain the overall resource consumption of the team within a preset quota while ensuring the integrity of the inspection tasks. Adjustment operations fall into two categories. First, dynamically adjusting the composition of the collaborative diagnostic team. The coordinator assesses whether the team's total resource estimate exceeds the limit if new resource requests are approved. If so, it may remove an agent with the lowest current resource utilization or whose inspection dimension can be partially taken over by other members, and request the dynamic decision-making module to schedule a new agent with a more suitable resource requirement to join. Second, dynamically adjusting task allocation. Without changing the team composition, the coordinator reallocates tasks within the team. For example, it may migrate some non-core or low-energy-consumption inspection subtasks of the signaling agent to other agents with lighter current loads within the team, thereby balancing the overall load and meeting the new resource requirements of the signaling agent.

[0039] After making a decision, the coordinator generates specific control instructions, such as task migration instructions, agent removal notifications, or new member addition guidelines, and distributes these instructions to the relevant agents and agent resource pool managers. Once the stakeholders execute the instructions, the collaborative diagnostic team's resource configuration or task layout is updated, and a new collaborative inspection phase begins.

[0040] For example, in a collaborative diagnostic team inspecting forest resource survey data blocks, agent A is responsible for verifying timber volume calculations, while agent B is responsible for checking the logical consistency of tree species composition. Upon receiving a problematic data unit indicating a complex conflict between tree species coding and the growth model in a specific area, agent B adjusts its behavior and loads a more complex model fitting algorithm for in-depth verification. Agent B reassesses the resource demand, and its original resource demand estimate... Calculated using the cost function Unit. Under the new behavior Calculated Unit. Difference ratio The system has preset demand thresholds. Since 0.5 is greater than 0.3, Agent B generates a resource requirement update signal. The group coordinator receives the signal and checks the status snapshot: Agent A's load is moderate, and its accumulation calculation has multiple simplified verification modes. The coordinator decides to adopt a dynamic task allocation strategy. It instructs Agent A to switch its accumulation calculation from "exact full model" mode to "fast sampling verification" mode to free up some computing resources. Simultaneously, it transfers the "basic tree species coding compliance batch check" subtask originally handled by Agent B to Agent A. After the adjustment, Agent B obtains sufficient resources for deep model verification, the group's total resource consumption does not exceed the quota, and the task can continue.

[0041] The conclusion generation module is used to aggregate the inspection results of all agents in the collaborative diagnostic team to form a preliminary diagnostic conclusion for the natural resource target data block; Specifically, after the collaborative diagnostic team begins its checks, the conclusion generation module immediately initiates a subscription connection to the real-time problem data sharing channel established for the team. This real-time problem data sharing channel is a message middleware system based on a publish-subscribe pattern, such as Apache Kafka or RabbitMQ. The module's subscription goal is to obtain all messages published by any agent within the current collaborative diagnostic team in this channel. These messages are problem data units, and their format follows a predefined structured data format defined by the system. This format specifies essential fields such as the problem's unique identifier (UUID), problem type code, source agent identifier, problem data location, trigger rule reference, problem description text, and discovery timestamp. The module continuously listens to the channel, and whenever it receives a new problem data unit, it parses it and stores it in a cache set. To avoid duplicate counting caused by different agents reporting the same problem from different perspectives, the module performs deduplication on the received units based on the two core fields of the problem's unique identifier and the problem data location, retaining only the first reported unit instance. All the received, parsed, and deduplicated problem data units together constitute the real-time problem dataset for subsequent analysis.

[0042] The conclusion generation module receives the final inspection results submitted by each agent in the collaborative diagnostic team in parallel. Each agent's inspection result is a structured list, with each item corresponding to the output of a specific inspection action. The record includes the diagnostic dimension identifier being inspected, the inspection conclusion status, and, when the inspection fails, the specific data record identifier or data fragment in the associated target data block. The module performs an association matching operation, the core task of which is to establish logical connections between problem data units in the real-time problem dataset and the inspection result items of each agent. The matching process mainly relies on whether the data entities they point to are the same, i.e., comparing the "problem data location" field in the problem data unit with the "data record identifier" field in the inspection result item. If both point to the same data entity in the target data block, an association edge is established between the problem data unit and this inspection result. Association edges have a type attribute: if the inspection result confirms the inconsistency described by the problem data unit, the edge type is marked as "support"; if the inspection result shows that the data entity conforms to the rules and contradicts the problem report, the edge type is marked as "conflict". By traversing the complete real-time problem dataset and all inspection results, the module constructs a graph structure called the Problem Evidence Association Graph. In this graph, nodes are divided into two categories: problem nodes, representing each independent problem in the real-time problem dataset; and evidence nodes, representing each specific inspection result submitted by each agent. The edges connecting the nodes represent logical relationships such as "support" or "conflict".

[0043] After the problem evidence association graph is constructed, the conclusion generation module calls its embedded graph reasoning algorithm to comprehensively analyze the information in the graph. This algorithm first assigns an initial weight value to each evidence node. This initial weight value is directly derived from the expected performance index value recorded in the performance application report submitted by the agent that generated the evidence node during the task allocation phase. The expected performance index is a dimensionless value between 0 and 1, reflecting the system's pre-assessment of the agent's reliability in handling the corresponding diagnostic dimension.

[0044] Subsequently, the algorithm performs evidence weight aggregation. For each problem node in the problem evidence association graph, the algorithm aggregates all connected evidence nodes. For edges of type "support," the weights of their connected evidence nodes are accumulated; for edges of type "conflict," the weights of their connected evidence nodes are canceled out. To eliminate the influence of the number of evidence nodes on the accumulated value and to unify the units of measurement, the following normalization formula is used to calculate the overall confidence score for each problem node p: , in, It is the sum of the initial weights of all evidence nodes connected to the problem node via "support" edges; It is the number of "supporting" edges; It is the sum of the initial weights of all evidence nodes connected to the problem node through "conflict" edges; This represents the number of conflicting edges; K is a preset conflict reduction coefficient, a real number greater than 0. In the formula, the numerator is the sum of weights, and the denominator is the number of edges. Dividing the two yields the average weight, achieving dimensional normalization. It is a dimensionless numerical value. The conflict reduction factor K is set based on the business's tolerance for false alarms and is calibrated using historical mission data; for example, it can be set to 0.5.

[0045] When logical conflicts arise in the evidence association graph, the algorithm makes a ruling based on a pre-defined list of rule priorities. This list is determined during the construction of the system rules and standard resource library, specifying the priority levels of business rules from different sources. The algorithm prioritizes problem nodes supported by evidence chains triggered or associated with higher-priority rules. For evidence conflicts caused by rules of the same priority, the algorithm directly compares the comprehensive confidence scores of the problem nodes. Those with higher scores will be adopted.

[0046] The algorithm filters problem nodes based on a preset conclusion acceptance threshold. This threshold is an empirical value between 0 and 1, for example, set to 0.6. For the overall confidence score... Problem nodes that are greater than or equal to this threshold and are not rejected after conflict resolution will have their corresponding quality issues adopted as definitive diagnostic conclusions. All adopted conclusions will be organized according to their problem type and severity to form a structured preliminary diagnostic conclusion.

[0047] For example, in a land use data inspection, the collaborative diagnostic team includes agents M and N. The conclusion generation module subscribes to problem data units Qa (reporting "Area anomaly in Patch T-01") and Qb (reporting "Land category conflict in Patch T-02") from the real-time problem data sharing channel. The module simultaneously receives the inspection result Ra from agent M (confirming "Area verification of Patch T-01 failed") and the inspection results Rb (confirming "Logical verification of Patch T-02 failed") and Rc (displaying "Correct encoding format for Patch T-01") from agent N. The module constructs a problem evidence association graph, where nodes Qa are connected to Ra via "support" edges and to Rc via "conflict" edges; nodes Qb are connected to Rb via "support" edges. Assuming the expected performance index of agent M is 0.85 and that of agent N is 0.9, Ra has a weight of 0.85, Rb has a weight of 0.9, and Rc has a weight of 0.9. Taking K=0.5, the calculation of Qa... ;Qb Setting the conclusion adoption threshold at 0.6, after conflict resolution and without intervention from higher-priority rules, the module generates a preliminary diagnostic conclusion. The issues reported by Qb are adopted as definitive conclusions, while the issues reported by Qa are not included in the final conclusion due to their confidence scores being below the threshold. This fully replicates the technical process from subscribing to data, constructing a relational graph, to inference and conclusion generation.

[0048] The adversarial verification module is used to generate a reverse verification proposition that is logically opposite to the preliminary diagnostic conclusion based on the preliminary diagnostic conclusion, and to call or combine agents in the agent resource pool to perform reverse evidence search on the target data block to obtain the reverse verification result. Specifically, the adversarial verification module receives a preliminary diagnostic conclusion output by the conclusion generation module. This preliminary diagnostic conclusion is a structured list containing several data quality issue assertions. For example, one assertion might state, "The measured value V of field F of data entity E exceeds the standard range." Maintain a logical inversion rule base, which defines mapping rules that transform different types of assertions into their opposites or competing hypotheses. The mapping rules are established based on the analysis of the logical form of data quality rules in the natural resources domain. For example, for assertions of the "out of range" type, the inversion rule is to generate "value V is within the compliance range". The module iterates through each assertion in the preliminary diagnostic conclusion, first parsing its assertion structure to identify the assertion type, the data entities involved, attributes, and constraints. Based on the identified assertion type, the module retrieves the corresponding mapping rule from the logical inversion rule base. Applying this mapping rule, the module negates or replaces the core logical relationship in the original assertion, generating a new statement that logically directly opposes the original assertion—a reverse verification proposition. All reverse verification propositions generated from the above processing of assertions in the preliminary diagnostic conclusion are collected to form a reverse verification proposition set.

[0049] The adversarial verification module parses each proposition in the set of reverse verification propositions, extracting the core capability tags required to verify the proposition. These capability tags correspond to specific diagnostic dimensions, data formats, or rule types that the agent can handle, such as "spatial topology analysis," "attribute value range verification," and "business rule chain reasoning." The module then initiates a collaborative query to the management component of the agent resource pool. The query request includes the set of capability tags extracted from all propositions. In the agent resource pool, each agent declares its list of capability tags during registration. The management component calculates the matching degree between each agent's capability tag list and the capability tag set in the query request. One method for calculating the matching degree is to consider the proportion of the agent's capability tags that cover the query requirement tags. For a specific reverse verification proposition J, its required set of capability tags is... The set of capability tags for an agent A is: Then the matching degree of agent A to proposition J is... The Jaccard similarity coefficient between the two can be calculated: , in, The number of capability labels required for proposition J and also possessed by agent A. This represents the union of all capability labels required for proposition J and possessed by agent A. This formula calculates... It is a dimensionless numerical value between 0 and 1, with a higher value indicating a higher match rate. A match rate threshold is set. For example, 0.6 is an empirical value set based on statistical analysis of the success rate and efficiency of task allocation during the testing phase of the system, and is used to screen qualified candidate agents.

[0050] Based on the matching calculation results, the module allocates appropriate execution resources for each reverse verification proposition. For proposition P, if there is a matching degree for a single agent... Exceeding the threshold If a proposition is deemed suitable, the agent is directly assigned to it. If no single agent can fully meet the requirements, the module attempts to select a group of agents from the agent resource pool, ensuring that the union of their capability tags covers all the capability tags required for proposition P. A verification process for proposition P is then formed by combining the checking logic of these agents. After assigning execution agents or groups of agents to all reverse verification propositions, the module sends task activation instructions to these selected agents. These instructions include the specific reverse verification proposition assigned to the agent, access credentials for the natural resource target data block, and the session identifier for this verification task. All agents that receive and confirm the execution instructions logically constitute the reverse verification team for this reverse verification task.

[0051] After the reverse verification team is established, the adversarial verification module sends a start signal to all agents within the team. Each agent, based on its assigned reverse verification proposition, focuses on finding evidence supporting the proposition and conducts targeted analysis of the natural resource target data block. This analysis, contrary to the inspection purpose of the previous collaborative diagnostic team, aims to proactively find clues or conditions that can refute the corresponding assertions in the preliminary diagnostic conclusion. For example, if the reverse verification proposition is "value V is within the compliance range," the agent will attempt to apply all possible, compliant data transformation rules or tolerance interpretations to demonstrate the compliance of V; if the proposition is "there is a rule exemption condition," the agent will deeply scan the associated attributes or metadata of the data block to find identifiers or contextual information that may trigger exemption clauses. Agents run verification programs on their specialized inspection dimensions, programs configured to reason and calculate based on verifying the reverse proposition. The verification process may involve operations such as data retrieval, rule matching, numerical simulation, and spatial relationship re-judgment.

[0052] After verification, each agent generates a structured verification feedback. The feedback must include the reverse verification proposition it verified, the final "verification conclusion," and the "chain of evidence" supporting that conclusion. The verification conclusion is a binary judgment, typically "confirmed" or "falsified," indicating that sufficient evidence has been found to support the truth of the reverse proposition, or that no supporting evidence has been found, making the original preliminary diagnostic assertion more likely to be true. The chain of evidence details the reasoning steps, referenced data fragments, and rule clauses. The adversarial verification module collects all verification feedback submitted by agents and categorizes them according to the original reverse verification proposition. For each reverse verification proposition, the module marks its final state as "challenge successful" or "challenge failed" based on its corresponding verification feedback. The final state markings of all propositions and their associated chains of evidence together constitute a complete and systematic reverse verification result, which is then passed to the report generation module for subsequent comprehensive adjudication.

[0053] For example, the preliminary diagnostic conclusion includes an assertion that "the 'planned land use code' of land use patch L-101 is 203, which, along with the 'current land use code' of the same patch (105), violates the mandatory rule R1 that two types of codes cannot exist in the same patch." The adversarial verification module applies a logic inversion rule base to generate a reverse verification proposition for this type of "violation relationship" assertion: "The combination of the planned land use code and the current land use code of patch L-101 does not violate rule R1, or there is an applicable exception." The module parses this proposition and extracts the required capability tags, such as "coding rule interpretation" and "rule exception clause retrieval." After querying the agent resource pool, the module calculates that agent Ω's capability tag set contains these two tags, and its matching degree is calculated to be 1.0, higher than the threshold of 0.6. Therefore, the module calls agent Ω and adds it to the reverse verification group. After receiving the task, agent Ω checks the attributes and associated metadata of patch L-101 with the goal of proving the proposition true. It discovered a "historical legacy issue" identifier recorded in the properties of the map patch, and further retrieved a supplementary explanation for rule R1 in the rule base, stating that "map patches marked with a historical legacy issue identifier, where planning and current status codes coexist, are not treated as rule violations." Based on this, agent Ω generates verification feedback, concluding with "confirmed," and attaches the "historical legacy issue identifier" and the supplementary rule explanation as a chain of evidence. The adversarial verification module summarizes the results, marking this reverse verification proposition as "challenge successful." This successfully challenged proposition and its chain of evidence become the key part of the output reverse verification result.

[0054] The report generation module is used to perform conflict resolution and evidence weight assessment using the preliminary diagnostic conclusions and the reverse verification results, and generate a structured quality diagnostic report containing a credibility level.

[0055] Specifically, the report generation module receives preliminary diagnostic conclusions from the conclusion generation module and reverse verification results from the adversarial verification module. The report generation module first parses these two inputs, extracting the data quality assertions they contain. For each assertion in the preliminary diagnostic conclusion, the module extracts its assertion identifier, the relevant data record identifier, the problem field, and the violated rule identifier. For each record in the reverse verification result, the module extracts its challenged target assertion identifier and challenge conclusion status, which includes challenge success or challenge failure. Subsequently, the module uses the assertion identifier, or a combination of data record identifiers and rule identifiers, to match the assertions in the preliminary diagnostic conclusion with the records in the reverse verification result one by one. After matching, the module checks each item: if the reverse verification record associated with a preliminary diagnostic assertion has a challenge success status, then the assertion is determined to be a specific assertion point with logical conflict; if the status is challenge failure, then the assertion has not been effectively challenged and does not constitute a conflict point. All assertions determined to have logical conflicts are collected, forming a set of conflict points to be arbitrated.

[0056] For each specific assertion point in the set of conflict points, the report generation module evaluates the strength of evidence supporting both sides. The module obtains the necessary foundational data for the evaluation by accessing a globally shared agent performance knowledge base within the system. This knowledge base stores copies of performance request reports submitted by all agents in the agent resource pool during this inspection task, as well as task execution records from the collaborative diagnostic team and the reverse verification team.

[0057] When evaluating the weights of the preliminary evidence chain supporting the preliminary diagnostic conclusion, the module searches the agent performance knowledge base for all agents that provided supporting evidence during the generation of the preliminary diagnostic assertion. The identifiers of these agents can be obtained from the problem evidence association graph records constructed by the conclusion generation module. The module queries the expected performance index values ​​recorded by these agents in their performance application reports. This value is a pre-assessed reliability measure between 0 and 1. The module calculates the arithmetic mean of these expected performance index values ​​and uses this average as the initial weight value of the preliminary evidence chain for that assertion point. The calculation formula is as follows: ,in, The initial weight value representing the preliminary chain of evidence; This represents the expected performance index value of the i-th agent providing supporting evidence; It is the number of agents providing supporting evidence; This indicates a summation operation.

[0058] When evaluating the weights of the reverse evidence chain supporting the reverse verification result, the module searches the agent performance knowledge base for reverse verification agents that successfully challenged the assertion. The identifiers of these agents are included in the evidence chain description of the reverse verification result. The module queries the expected performance index values ​​recorded in the performance application reports of these agents and calculates the arithmetic mean of these values. This average is used as the initial weight value of the reverse evidence chain for that assertion point. The calculation formula is as follows: ,in, The initial weight value representing the reverse chain of evidence; This represents the expected performance metric value of the j-th agent performing reverse verification; It is the number of agents that provide reverse evidence.

[0059] The report generation module has a pre-defined set of credibility arbitration rules. This rule base defines a rule priority mapping table, which categorizes business rules into levels such as "mandatory," "binding," and "guiding," assigning a quantified priority coefficient to each level, for example, 1.0, 0.7, and 0.5 respectively. The arbitration process is conducted independently for each specific assertion point and outputs a final weight value for acceptance. And a final diagnostic result status.

[0060] Arbitration first determines the rule priority. The module retrieves the rule priority coefficient that was violated by the assertion point and triggered the initial diagnosis. Simultaneously, retrieve the priority coefficient of the rules or exceptions upon which the reverse verification challenge is based. .like Higher than For example, if the difference exceeds the preset rule priority threshold, the arbitration will directly adopt the preliminary diagnosis, determine the final diagnosis as "confirmed problem," and set the final weight value for acceptance. .

[0061] If the rule priorities are equal, an evidence weight comparison is performed for adjudication. The module calculates the initial weight values ​​for the preliminary chain of evidence. Initial weight values ​​of the reverse chain of evidence absolute difference D is compared to a preset confidence threshold Δ, which is an empirical value set based on historical arbitration case data analysis, for example, Δ = 0.2. If... If the arbitration adopts the preliminary evidence, determines the final diagnosis as "confirmed problem," and orders... .like If the arbitration adopts the reverse evidence, it determines the final diagnosis as "challenge valid, preliminary assertion unfounded," and orders... .

[0062] If the absolute difference D is not greater than the threshold Δ, that is If the assertion is not found, an additional review process is initiated. The module submits the assertion point to a pre-defined high-authority review interface, which may be a dedicated review agent with comprehensive judgment capabilities or a human review interface. The module determines the final diagnosis based on the ruling returned by the review interface and... Set the initial weight value corresponding to the side whose review opinion is accepted. For preliminary diagnostic assertions not identified as points of conflict, the final diagnostic result is directly confirmed as a "confirmed issue". Set as .

[0063] After arbitration of all assertion points, the report generation module assigns a confidence level to each assertion with a final diagnostic result of "Confirmed Problem". The levels are divided into three categories: "High", "Medium", and "Low". The assignment process is based on a confidence score calculation and mapping mechanism.

[0064] For each confirmed issue, the module has obtained its final weight value for acceptance. and the base priority coefficient of the rules violated. The module uses the following formula to calculate the credibility score for this question: ,in, The credibility score is a dimensionless numerical value. It is a pre-defined dimensionless harmonic coefficient used to balance the impact of evidence weight and the inherent importance of the rule on credibility. The value ranges from 0 to 1, and its specific value is determined based on statistical analysis of a large number of historical diagnostic reports. For example, setting... ; yes The complementarity coefficients of the two are equal to 1.

[0065] Module preset scoring interval mapping relationship: when When the credibility level is "high", when When the credibility level is "medium", when At that time, the credibility level was "low". (Based on each question) The module maps the value to the corresponding level.

[0066] Finally, the module integrates all information to generate a final structured quality diagnostic report. This report is output as an electronic document and includes at least: target data block identifiers, an overview of the inspection tasks, and a detailed issue list. For each issue in the detailed issue list, the report clearly lists its data location, issue description, rule violation, final diagnostic result, brief reasons for arbitration, assigned credibility level, and related evidence and challenge index. The report's structured format design follows industry-standard specifications for natural resource data quality assessment reports, ensuring its direct applicability to subsequent data governance processes.

[0067] For example, in response to a land use data inspection task, the report generation module receives a preliminary diagnostic assertion: "The 'Building Area' field value of map patch TP-1001 is empty, violating the mandatory rule R_NonNull that 'core attribute fields cannot be empty'." Its initial weight value for the preliminary chain of evidence. The calculated value is 0.90. One record in the reverse verification results challenges this assertion, with the proposition "This plot is an unfinished and unregistered land parcel, and its building area can be empty," and the status is "Challenge Successful." The initial weight value of the reverse evidence chain is... The value is 0.85. The module identifies it as a specific assertion point. Upon investigation, the priority coefficient of rule R_NonNull is... The priority coefficient P_rule_counter for the "Exemption Clause for Unfinished Construction" cited in the reverse challenge is 0.8 (binding), with a priority of 1.0 (mandatory). Due to the difference in rule priorities, arbitration proceeds to a weighted comparison. A threshold is set. Calculate the difference No greater than Therefore, an additional review was initiated. The review interface, involving manual examination, confirmed the land parcel's status and accepted the reverse challenge. The arbitration determined the final diagnosis to be "challenge valid, TP-1001's building area is empty, meeting the exemption conditions, and does not constitute a problem," and ordered... Since the final result is not a "confirmed issue," no confidence level is assigned. In the final structured quality diagnostic report, the "Final Diagnostic Result" field for this entry is recorded as "After review, no issue," and the "Arbitration Reason" field is recorded as "Rule exemption clause applies." This example fully reproduces the entire process from conflict identification, weight assessment and calculation, hierarchical arbitration based on rules and weights, to report generation.

[0068] It should be noted that the above description is merely an exemplary embodiment of the present invention and should not be construed as limiting the scope of the invention. All equivalent changes and modifications made in accordance with the teachings of this invention are still within the scope of this invention. Those skilled in the art will readily conceive of other embodiments of the invention upon considering the disclosure of the specification and practical truths. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or conventional techniques in the art not described herein.

Claims

1. A natural resource data consistency check system based on a rule engine, characterized in that, The system includes: The data perception module is used to acquire the natural resource target data block to be inspected, and to perform multi-dimensional feature analysis on the natural resource target data block to generate diagnostic demand signals. The rule response module is used to broadcast the diagnostic requirement signal to a preset intelligent agent resource pool containing multiple intelligent agents. Each intelligent agent in the intelligent agent resource pool generates and submits a performance application report containing expected performance indicators and resource requirement estimates based on the diagnostic requirement signal. The dynamic decision-making module is used to make multi-objective optimization decisions based on all the received performance application reports, dynamically filter and form a collaborative diagnostic team for the natural resource target data block; The collaborative evolution module is used to drive each agent in the collaborative diagnostic team to inspect the natural resource target data block. During the execution process, a real-time problem data sharing channel is established, allowing any agent to publish the problem data it discovers to the real-time problem data sharing channel, and enabling other agents in the collaborative diagnostic team to subscribe to and use the problem data to adjust their inspection behavior. The conclusion generation module is used to aggregate the inspection results of all agents in the collaborative diagnostic team to form a preliminary diagnostic conclusion for the natural resource target data block; The adversarial verification module is used to generate a reverse verification proposition that is logically opposite to the preliminary diagnostic conclusion based on the preliminary diagnostic conclusion, and to call or combine agents in the agent resource pool to perform reverse evidence search on the target data block to obtain the reverse verification result. The report generation module is used to perform conflict resolution and evidence weight assessment using the preliminary diagnostic conclusions and the reverse verification results, and generate a structured quality diagnostic report containing a credibility level.

2. The natural resource data consistency check system based on a rule engine according to claim 1, characterized in that, The data sensing module includes: Obtain the natural resource target data block to be inspected, identify the data content type and business domain of the natural resource target data block, and obtain the domain classification label; Based on the domain classification tags, corresponding data quality constraint rules and business logic specifications are called from the preset rules and standard resource library to form a constraint rule set; The data structure of the natural resource target data block is analyzed by combining the constraint rule set, key fields and business logic relationships between fields are extracted, a list of diagnostic dimensions and initial problem hypotheses are generated, and diagnostic demand signals are synthesized.

3. The natural resource data consistency check system based on a rule engine according to claim 2, characterized in that, The rule response module includes: The diagnostic request signal is broadcast to a preset intelligent agent resource pool containing multiple intelligent agents. Each agent in the agent resource pool receives the diagnostic request signal and parses the list of diagnostic dimensions in the diagnostic request signal. Based on the list of diagnostic dimensions, the knowledge bases within each agent in the agent resource pool are matched to determine the subset of diagnostic dimensions that each agent in the agent resource pool can process; Based on the diagnostic dimension subset, the coverage and estimated time of each agent in the agent resource pool to check the diagnostic dimension subset are predicted, the expected performance index and resource requirement estimate are calculated, and the performance application report is packaged.

4. The natural resource data consistency check system based on a rule engine according to claim 1, characterized in that, The dynamic decision-making module includes: Summarize all received performance request reports and establish an optimization model with preset overall diagnostic coverage and preset overall resource consumption as objectives; Solving the optimization model yields an agent combination scheme; According to the agent combination scheme, corresponding agents are scheduled from the agent resource pool to form a collaborative diagnostic team.

5. A natural resource data consistency check system based on a rule engine according to claim 4, characterized in that, The co-evolution module includes: The system drives each agent within the collaborative diagnostic team to inspect the natural resource target data block. Establish a real-time problem data sharing channel within the collaborative diagnostic team and define a structured data format for exchanging problem data; When any agent in the collaborative diagnostic team identifies inconsistent data or rule conflicts during the inspection process, it encapsulates the inconsistent data or rule conflicts into problem data units according to the structured data format and publishes them to the real-time problem data sharing channel. Other agents within the collaborative diagnostic team that have subscribed to relevant data types or rule types receive the problem data unit and trigger internal rule updates for other agents within the collaborative diagnostic team based on the content of the problem data unit, or adjust subsequent inspection logic and data scanning paths.

6. A natural resource data consistency check system based on a rule engine according to claim 5, characterized in that, The co-evolution module also includes: After the agents in the collaborative diagnostic team adjust their inspection behavior based on the problem data unit, the resource requirement estimate of the corresponding agents is reassessed. If the difference between the reassessed resource demand estimate and the original resource demand estimate exceeds a preset demand threshold, a resource demand update signal will be generated. Based on the current state of all agents and the resource demand update signal, the composition or task allocation of the collaborative diagnostic team is dynamically adjusted.

7. A natural resource data consistency check system based on a rule engine according to claim 5, characterized in that, The conclusion generation module includes: Subscribe to all published problem data units from the real-time problem data sharing channel to obtain a real-time problem dataset; The real-time problem dataset is correlated and matched with the inspection results of each agent in the collaborative diagnostic team to construct a problem evidence association graph; Based on the aforementioned evidence association graph, a graph reasoning algorithm is used to aggregate evidence weights and resolve conflicts, generating a preliminary diagnostic conclusion.

8. A natural resource data consistency check system based on a rule engine according to claim 7, characterized in that, The adversarial verification module includes: Based on the preliminary diagnostic conclusions, a logical inversion operation is performed to generate a reverse verification proposition that challenges the correctness of the preliminary diagnostic conclusions. According to the technical requirements of the reverse verification proposition, intelligent agents with corresponding verification capabilities are retrieved from the intelligent agent resource pool, or multiple intelligent agents are combined to form verification logic, and a reverse verification team is formed. The reverse verification team is driven to perform an evidence-finding process that contradicts the preliminary diagnostic conclusion on the natural resource target data block, and outputs the reverse verification result.

9. A natural resource data consistency check system based on a rule engine according to claim 8, characterized in that, The report generation module includes: By comparing the preliminary diagnostic conclusion with the reverse verification result, specific assertion points with logical conflicts are identified. For each specific assertion point, the weight of the preliminary chain of evidence supporting the preliminary diagnostic conclusion and the weight of the reverse chain of evidence supporting the reverse verification result are evaluated respectively. Based on preset credibility arbitration rules, and combined with the weight of the preliminary evidence chain, the weight of the reverse evidence chain, and the priority of preset business rules, the conflict points are arbitrated to determine the final diagnosis result. Assign a confidence level to the final diagnostic results and generate a structured quality diagnostic report.

Images