Report verification batch parallel execution optimization method based on pluggable rule engine framework

Abstract

The invention discloses a report verification batch parallel execution optimization method based on a pluggable rule engine framework, and relates to the technical field of report verification, and the method comprises the following steps: receiving compliance rules, converting the compliance rules into a uniform data structure model, analyzing to generate metadata indexes, and supporting business rule set configuration; loading the matched business rule set based on the meta-information of the to-be-verified report, and registering the matched business rule set to an execution container; s3, receiving a to-be-verified report, analyzing a report structure, and generating a report field index table; performing field dependency analysis based on the report field index and the loaded business rule set, and constructing a rule field dependency graph; graph partition optimization and topological sorting are executed according to the dependency graph, and rule batches capable of being executed in parallel are generated; and uniformly collecting and outputting all rule execution results, hit states, abnormal records and performance indexes, and generating a structured verification report and an audit chain log. The financial statement compliance check execution efficiency can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of report verification, and in particular to a report verification batch parallel execution optimization method based on a pluggable rule engine framework. Background Art

[0002] In modern corporate financial management and auditing, report compliance verification is a crucial step in ensuring the authenticity, completeness, and compliance of financial information with regulatory requirements. Traditional report verification methods, which rely heavily on static rule templates and manual review processes, are inefficient and error-prone. They also struggle to adapt to diverse report formats, dynamic regulatory requirements, and frequent data updates.

[0003] In recent years, with the widespread adoption of intelligent financial systems, some platforms have introduced rule engine technology to automate report verification. However, existing rule execution frameworks commonly suffer from the following issues: First, the rigid organizational structure of rules makes them difficult to flexibly configure and expand, especially in multi-industry, multi-caliber, and multi-cycle scenarios. Second, rule execution efficiency is low, especially when large reports or large batches of rules are applied simultaneously to multiple reports, where serial execution leads to significant system performance bottlenecks. Third, there is a lack of mechanisms for managing inter-rule dependencies and optimizing grouping, resulting in redundant computation and wasted resources.

[0004] Furthermore, many systems fail to support dynamic rule loading and pluggable management, and lack parallel execution optimization strategies at the task scheduling layer. This makes it difficult to meet the practical needs of large enterprises or financial institutions for "high-performance, high-flexibility, and high-interpretability" report compliance verification systems in high-density financial data environments. Therefore, a rule engine optimization mechanism with flexible rule management capabilities and support for high-concurrency execution is urgently needed to improve the efficiency and intelligence of report auditing. Summary of the Invention

[0005] The present invention aims to solve the problems of low rule execution efficiency, rigid rule structure, poor system scalability, etc. in financial statements, and provides a report verification batch parallel execution optimization method based on a pluggable rule engine framework.

[0006] The present invention provides a report verification batch parallel execution optimization method based on a pluggable rule engine framework, which solves the above technical problems using the following technical solutions:

[0007] A report verification batch parallel execution optimization method based on a pluggable rule engine framework comprises the following steps:

[0008] S1. Receive compliance rules, convert them into a unified data structure model, parse and generate metadata indexes, and archive them to a rule repository that supports classification, version management, and template inheritance and combination mechanisms. It also supports business rule set configuration and static analysis to optimize scheduling.

[0009] S2: Based on the metadata of the report to be verified, the rule selector determines the loading of matching business rule sets. Rules are extracted from the rule repository and registered in the execution container. This supports on-demand rule loading, delayed initialization, and isolated execution mechanisms to improve stability and flexibility.

[0010] S3. Receive financial report data submitted by users or automatically generated, call the semantic parsing engine to analyze the report structure, extract field paths, data types, period information, and unit attributes, and generate a report field index table;

[0011] S4. Perform field dependency analysis based on the report field index and the loaded business rule set, and construct a rule field dependency graph. The rule field dependency graph is a directed graph structure, where nodes are rule entities and edges are field sharing relationships or calculation sequence dependencies.

[0012] S5. Execute graph partition optimization and topological sorting based on the rule field dependency graph to generate batches of rules that can be executed in parallel. Dynamically adjust parallel parameters based on host resource status, distribute tasks through thread pools or distributed message queues, and use field access locality analysis, memory hot pool caching, intermediate result sharing, and computation plan precompilation to improve efficiency. Independent exception handlers ensure execution stability.

[0013] S6. Collect and output all rule execution results, hit status, exception records and performance indicators in a unified manner, and generate structured verification reports and audit chain logs.

[0014] Optionally, step S1 specifically includes:

[0015] S1.1. Receive compliance rules provided by financial business personnel, audit experts, or domain configuration systems, and support defining rule content based on templates, DSL languages, expression templates, or tree-based logic configurations;

[0016] S1.2. Convert the received rules into a unified data structure model and use the built-in syntax parser to automatically parse and convert them into a rule intermediate representation structure to ensure that the rules can be recognized by the subsequent execution engine;

[0017] S1.3. Extract core elements from the parsed rules, including logical expressions, field dependencies, applicable report types, verification cycles, verification levels, and responsibility tags, to form standardized rule entities.

[0018] S1.4. Generate a rule metadata index while parsing the rules, forming a rule metadata table to provide a basis for subsequent scheduling optimization and retrieval;

[0019] S1.4. The rules processed above are filed uniformly in the rule warehouse and categorized and stored according to rule type, applicable form, and industry template.

[0020] S1.5. Combine the rules in the rule warehouse into business rule sets based on business scenarios, and configure the trigger conditions and applicable business domains of the business rule sets.

[0021] Optionally, the rule repository supports version management, recording the content, time, and operator of each rule change, allowing for tracing back historical versions to ensure auditability and compliance of rule changes.

[0022] The method supports the template inheritance mechanism. When users quickly define their own variant rules based on the industry general rule template, the method automatically expands the rule reference relationship and verifies the logical integrity to avoid conflicts or redundancies.

[0023] When defining rule content, the method scans the field usage frequency and dependency depth in the compliance rules, generates scheduling optimization suggestions based on the scanning results, and provides a basis for performance optimization of subsequent batch verification.

[0024] Further optionally, the step S2 specifically includes:

[0025] S2.1. Extract the metadata of the report to be verified and generate a rule matching condition combination;

[0026] S2.2, the rule selector filters the business rule set from the rule repository based on the matching conditions;

[0027] S2.3. Extract matching rules from the rule repository based on the screening results:

[0028] (a) Using an on-demand loading mechanism, only the rules triggered by the current report are loaded into the execution container;

[0029] (b) Enable lazy initialization, where the rule logic component is loaded into the execution container only when it is first triggered or matched to the target field;

[0030] (c) The extracted matching rules are registered in the execution container in the form of modular components, each of which contains independent rule logic, configuration parameters and execution context.

[0031] Further optionally, step S3 specifically includes:

[0032] S3.1. Receive financial statement data manually submitted by users or automatically generated by the business system through interfaces or file import, and complete data format verification and integrity checks;

[0033] S3.2. Call the built-in semantic parsing engine to deeply analyze the report structure, implement table recognition, field location, and cross-period joint table processing, and establish a mapping relationship between period labels and fields;

[0034] S3.3. Extract four types of meta-information from the parsing results: field path, data type, period information, and unit attributes. Then, construct a field merge index and multi-table fusion model for nested tables, supplementary tables, or cross-period joint tables in table recognition, and integrate the meta-information and structured report fields into a report field index table.

[0035] Further optionally, step S4 specifically includes:

[0036] S4.1. Obtain the generated report field index table and load the currently active business rule set;

[0037] S4.2. Parse each rule in the business rule set to identify its input field set and output impact field set;

[0038] S4.3. Match the rule's input fields and output impact fields with the report field index table to determine the fields' physical paths and logical meanings, analyze the field sharing relationships between rules, and calculate the order of dependencies.

[0039] S4.4. Using rule entities as nodes and field sharing relationships or sequential dependency relationships as edges, a rule field dependency graph with a directed graph structure is constructed.

[0040] Further optionally, step S5 specifically includes:

[0041] S5.1. Use the minimum cut set algorithm to divide the rule field dependency graph into multiple execution domains, perform topological sorting on the rules within each execution domain, and generate the dependency chain execution order.

[0042] S5.2. Generate rule batches without field conflicts based on the topological sorting results and the partitioning results of the rule field dependency graph. Dynamically adjust the batch size and the number of parallel threads based on the current host resource status.

[0043] S5.3: In standalone scenarios, rule batches are submitted to the local thread pool for parallel execution. In high-concurrency scenarios, tasks are distributed to remote execution agents on multiple nodes through distributed message queues.

[0044] S5.4. During the above execution process, each rule is bound to an independent exception handler, which automatically captures calculation errors and field missing exceptions, executes skip, retry or interrupt operations according to the configured strategy, and marks the exception log.

[0045] Preferably, steps S5.2-S5.3 are performed, and the following operations are performed simultaneously before, during, or after the rule batch is generated:

[0046] Analyze field access frequency and cache fields that exceed the set frequency as high-frequency fields in a hot memory pool. When multiple rules reference the same field, they share intermediate calculation results to avoid repeated reading and calculation.

[0047] For rules involving aggregate calculations or cross-period comparisons, pre-compilation is performed to generate reusable intermediate result execution graphs, shortening runtime calculation time.

[0048] Further optionally, step S6 specifically includes:

[0049] S6.1. After rule execution is complete, the status of hit rules, failed rules, and warning rules will be centrally aggregated. Each record will include key information such as the rule number, execution time, specific fields hit, specific failure type, error level assessment, targeted recommendations, and the rule dependency chain path.

[0050] S6.2. Based on the above collected content, the execution result data, field-level error details, performance indicators, and dependency chain path information are integrated. Then, based on user-preconfigured or system-preset templates, a field-level verification report, report-level audit summary, audit chain log, visual heat map, and abnormal indicator time series chart are automatically generated;

[0051] S6.3. Export the verification report to JSON, Excel, or PDF format and push it to downstream systems through the interface. Support data structure mapping and automatic synchronization of the regulatory interface.

[0052] S6.4. Write the execution process metadata into the audit chain log for later archiving, performance evaluation, and troubleshooting, to build a full-chain explainable system.

[0053] The present invention provides a report verification batch parallel execution optimization method based on a pluggable rule engine framework, which has the following beneficial effects compared with the prior art:

[0054] 1. This invention supports execution path optimization based on rule dimensions, report dimensions, or industry scenarios, effectively improving the execution efficiency and response speed of financial statement compliance checks. It is suitable for high-density business scenarios such as multi-version reports, cross-period comparisons, and cross-table consistency checks. It has significant advantages such as flexible rule management, superior execution performance, strong adaptability, and support for multi-business collaboration.

[0055] 2. The present invention introduces a rule dependency graph and a parallel batch processing mechanism to achieve high-concurrency operation of multiple rules and multiple reports, which can significantly improve the rule execution efficiency and system responsiveness. It supports dynamic loading of rules, on-demand calling of business modules, and hot-swap operations to decouple rules from the system, facilitate subsequent maintenance, updates, and sharing in multiple scenarios, and reduce system coupling and operation and maintenance costs. It supports cross-report, cross-cycle, and multi-dimensional rule expression and execution, improves the system's adaptability to complex regulatory calibers and industry rules, and expands the scope of rule support for automatic auditing. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Attachment Figure 1 This is a flow chart of the method of embodiment 1 of the present invention. DETAILED DESCRIPTION

[0057] In order to make the technical solution, the technical problems solved and the technical effects of the present invention more clear, the technical solution of the present invention is clearly and completely described below in conjunction with specific embodiments.

[0058] Example 1:

[0059] Combined with attachment Figure 1 This embodiment proposes a report verification batch parallel execution optimization method based on a pluggable rule engine framework, which includes the following steps:

[0060] S1. Receive compliance rules, convert them into a unified data structure model, parse and generate metadata indexes, and archive them to a rule repository that supports classification, version management, and template inheritance and combination mechanisms. It also supports business rule set configuration and static analysis to optimize scheduling. Specifically, it includes:

[0061] S1.1. Receive compliance rules provided by financial business personnel, audit experts, or domain configuration systems, and support defining rule content based on templates, DSL languages, expression templates, or tree-based logic configurations;

[0062] S1.2. Convert the received rules into a unified data structure model and use the built-in syntax parser to automatically parse and convert them into a rule intermediate representation structure to ensure that the rules can be recognized by the subsequent execution engine;

[0063] S1.3. Extract core elements from the parsed rules, including logical expressions, field dependencies, applicable report types, verification cycles, verification levels (prompt / block), and responsibility tags, to form standardized rule entities.

[0064] S1.4. Generate a rule metadata index while parsing the rules to form a rule metadata table (RuleMetaTable), which provides a basis for subsequent scheduling optimization and retrieval;

[0065] S1.4. The rules processed above are filed uniformly in the rule warehouse and categorized and stored according to rule type, applicable form, and industry template.

[0066] S1.5. Combine the rules in the rule repository into business rule sets based on business scenarios, and configure the triggering conditions and applicable business domains of the business rule sets (RuleBundles).

[0067] The rule repository involved in this step supports version management, recording the content, time, and operator of each rule change. This allows for tracing back historical versions and ensures the auditability and compliance of rule changes.

[0068] It should be noted that the method involved in this embodiment supports the template inheritance mechanism. When users quickly define their own variation rules based on the industry-wide rule template, the rule reference relationship is automatically expanded and the logical integrity is verified to avoid conflicts or redundancies.

[0069] When defining the rule content, the method involved in this embodiment scans the field usage frequency and dependency depth in the compliance rules, generates scheduling optimization suggestions based on the scanning results, and provides a basis for performance optimization of subsequent batch verification.

[0070] S2. Based on the metadata of the report to be verified, the rule selector decides to load and match the configured business rule set, extracts rules from the rule repository and registers them in the execution container. It supports on-demand loading, delayed initialization, and isolated execution mechanisms for rules to improve stability and flexibility.

[0071] This step specifically includes:

[0072] S2.1. Extract the metadata of the report to be verified (such as the report template number, business module, organization, reporting period, etc.) and generate a rule matching condition combination;

[0073] S2.2, the rule selector filters the business rule set from the rule repository based on the matching conditions;

[0074] S2.3. Extract matching rules from the rule repository based on the screening results:

[0075] (a) Using an on-demand loading mechanism, only the rules triggered by the current report are loaded into the execution container;

[0076] (b) Enable lazy initialization, where the rule logic component is loaded into the execution container only when it is first triggered or matched to the target field;

[0077] (c) The extracted matching rules are registered in the execution container in the form of modular components. Each component contains independent rule logic, configuration parameters and execution context (including execution thread, cache space, error recovery strategy, etc.).

[0078] S3. Receive user-submitted or automatically generated financial report data, call the semantic parsing engine to analyze the report structure, extract field paths, data types, period information (such as "this period," "previous period," "beginning of the year"), and unit attributes, and generate a report field index table, specifically including:

[0079] S3.1. Receive financial statement data manually submitted by users or automatically generated by the business system through interfaces or file import, and complete data format verification and integrity checks;

[0080] S3.2. Invoke the built-in semantic parsing engine to deeply analyze the report structure, implement table recognition (including the identification of main tables, nested tables, and supplementary tables), field location (covering the analysis of physical paths and logical meanings), and cross-period table processing, establishing a mapping relationship between period labels and fields.

[0081] S3.3. Extract four types of meta-information from the parsing results: field path, data type, period information, and unit attributes. Then, construct a field merge index and multi-table fusion model for the nested tables, supplementary tables, or cross-period joint tables in table recognition. Integrate the meta-information and the structured report fields (specifically, the specific carrier objects of the field merge index and multi-table fusion model, which is a general term for the field merge index and multi-table fusion model) into a report field index table.

[0082] S4. Perform field dependency analysis based on the report field index and the loaded business rule set, and construct a rule field dependency graph. The rule field dependency graph is a directed graph structure, in which nodes are rule entities and edges are field sharing relationships or calculation sequence dependencies.

[0083] This step specifically includes:

[0084] S4.1. Obtain the generated report field index table and load the currently active business rule set;

[0085] S4.2. Parse each rule in the business rule set to identify its input field set and output impact field set;

[0086] S4.3. Match the rule's input fields and output impact fields with the report field index table to determine the fields' physical paths and logical meanings, analyze the field sharing relationships between rules, and calculate the order of dependencies.

[0087] S4.4. Using rule entities as nodes and field sharing relationships or sequential dependency relationships as edges, a rule field dependency graph with a directed graph structure is constructed.

[0088] S5. Perform graph partition optimization and topological sorting based on the rule field dependency graph to generate batches of rules that can be executed in parallel. Dynamically adjust parallel parameters based on the host resource status, distribute tasks through thread pools or distributed message queues, and use field access locality analysis, memory hot pool caching, intermediate result sharing, and calculation plan pre-compilation during execution to improve efficiency. At the same time, an independent exception handler is used to ensure execution stability.

[0089] This step specifically includes:

[0090] S5.1. Use the minimum cut set algorithm to divide the rule field dependency graph into multiple execution domains, perform topological sorting on the rules within each execution domain, and generate the dependency chain execution order.

[0091] S5.2. Generate rule batches without field conflicts based on the topological sorting results and the partitioning results of the rule field dependency graph. Dynamically adjust the batch size and the number of parallel threads based on the current host resource status.

[0092] S5.3: In standalone scenarios, rule batches are submitted to the local thread pool for parallel execution. In high-concurrency scenarios, tasks are distributed to remote execution agents on multiple nodes through distributed message queues.

[0093] S5.4. During the above execution process, each rule is bound to an independent exception handler, which automatically captures calculation errors and field missing exceptions, executes skip, retry or interrupt operations according to the configured strategy, and marks the exception log.

[0094] It should be noted that when executing steps S5.2-S5.3, before or after the rule batch is generated or during the execution, the following operations are performed simultaneously:

[0095] Analyze field access frequency and cache fields that exceed the set frequency into a hot field buffer. When multiple rules reference the same field, they share intermediate calculation results to avoid repeated reading and calculation.

[0096] For rules involving aggregate calculations or cross-period comparisons, pre-compilation is performed to generate reusable intermediate result execution graphs, shortening runtime calculation time.

[0097] S6. Collect and output all rule execution results, hit status, exception records, and performance indicators in a unified manner, generating a structured verification report and audit chain log, specifically including:

[0098] S6.1. After rule execution is complete, the status of hit rules, failed rules, and warning rules are aggregated. Each record includes key information such as the rule number, execution time, specific fields hit, specific failure type, error level assessment, targeted recommendations, and the rule dependency chain path.

[0099] S6.2. Based on the above collection, the execution result data, field-level error details, performance indicators, and dependency chain path information are integrated. Then, based on user-preconfigured or system-preset templates, a report is automatically generated, including a field-level verification report (indicating failed fields, causes, and suggestions), a report-level audit summary (statistical hit rate, anomaly distribution, and error level), an audit chain log (tracing rule input → execution logic → output → responsible field), a visual heat map (showing the distribution of issues in the report structure), and an anomaly indicator time series chart (supporting cross-period trend tracking);

[0100] S6.3. Export the verification report to JSON, Excel, or PDF format and push it to downstream systems (such as audit systems, risk control engines, or report review platforms) through interfaces. Support data structure mapping and automatic synchronization of regulatory interfaces.

[0101] S6.4. Write the execution process metadata (execution path, version number, resource usage, task error rate, etc.) into the audit chain log for later archiving, performance evaluation and problem troubleshooting, and build a full-chain explainable system.

[0102] In summary, the report verification batch parallel execution optimization method based on the pluggable rule engine framework of the present invention can significantly improve the rule execution efficiency and system responsiveness, enhance the flexibility and modular reuse capabilities of rule management, improve the intelligence and coverage of compliance verification, enhance the transparency and explainability of anomaly identification, and solve the technical bottlenecks of existing financial statement compliance inspection systems in terms of rule execution efficiency, flexibility and scalability.

[0103] The above specific examples are used to illustrate the principles and implementation methods of the present invention in detail. These examples are only used to help understand the core technical content of the present invention. Based on the above specific embodiments of the present invention, any improvements and modifications made by those skilled in the art without departing from the principles of the present invention should fall within the scope of patent protection of the present invention.

Claims

1. A report verification batch parallel execution optimization method based on a pluggable rule engine framework, characterized in that: The steps include: S1. Receive compliance rules, convert them into a unified data structure model, parse and generate metadata indexes, and archive them to a rule repository that supports classification, version management, and template inheritance and combination mechanisms. It also supports business rule set configuration and static analysis to optimize scheduling. S2: Based on the metadata of the report to be verified, the rule selector determines the loading of matching business rule sets. Rules are extracted from the rule repository and registered in the execution container. This supports on-demand rule loading, delayed initialization, and isolated execution mechanisms to improve stability and flexibility. S3. Receive financial report data submitted by users or automatically generated, call the semantic parsing engine to analyze the report structure, extract field paths, data types, period information, and unit attributes, and generate a report field index table; S4. Perform field dependency analysis based on the report field index and the loaded business rule set, and construct a rule field dependency graph. The rule field dependency graph is a directed graph structure, where nodes are rule entities and edges are field sharing relationships or calculation sequence dependencies. S5. Execute graph partition optimization and topological sorting based on the rule field dependency graph to generate batches of rules that can be executed in parallel. Dynamically adjust parallel parameters based on host resource status, distribute tasks through thread pools or distributed message queues, and use field access locality analysis, memory hot pool caching, intermediate result sharing, and computation plan precompilation to improve efficiency. Independent exception handlers ensure execution stability. S6. Collect and output all rule execution results, hit status, exception records and performance indicators in a unified manner, and generate structured verification reports and audit chain logs.

2. The report verification batch parallel execution optimization method based on the pluggable rule engine framework according to claim 1 is characterized in that: The step S1 specifically includes: S1.

1. Receive compliance rules provided by financial business personnel, audit experts, or domain configuration systems, and support defining rule content based on templates, DSL languages, expression templates, or tree-based logic configurations; S1.

2. Convert the received rules into a unified data structure model and use the built-in syntax parser to automatically parse and convert them into a rule intermediate representation structure to ensure that the rules can be recognized by the subsequent execution engine; S1.

3. Extract core elements from the parsed rules, including logical expressions, field dependencies, applicable report types, verification cycles, verification levels, and responsibility tags, to form standardized rule entities. S1.

4. Generate a rule metadata index while parsing the rules, forming a rule metadata table to provide a basis for subsequent scheduling optimization and retrieval; S1.

4. The rules processed above are filed uniformly in the rule warehouse and categorized and stored according to rule type, applicable form, and industry template. S1.

5. Combine the rules in the rule warehouse into business rule sets based on business scenarios, and configure the trigger conditions and applicable business domains of the business rule sets.

3. The report verification batch parallel execution optimization method based on the pluggable rule engine framework according to claim 2 is characterized in that: The rule repository supports version management, recording the content, time, and operator of each rule change, allowing historical versions to be traced to ensure the auditability and compliance of rule changes; The method supports the template inheritance mechanism. When users quickly define their own variant rules based on the industry general rule template, the method automatically expands the rule reference relationship and verifies the logical integrity to avoid conflicts or redundancies. When defining rule content, the method scans the field usage frequency and dependency depth in the compliance rules, generates scheduling optimization suggestions based on the scanning results, and provides a basis for performance optimization of subsequent batch verification.

4. The report verification batch parallel execution optimization method based on the pluggable rule engine framework according to claim 2 is characterized in that: The step S2 specifically includes: S2.

1. Extract the metadata of the report to be verified and generate a rule matching condition combination; S2.2, the rule selector filters the business rule set from the rule repository based on the matching conditions; S2.

3. Extract matching rules from the rule repository based on the screening results: (a) Using an on-demand loading mechanism, only the rules triggered by the current report are loaded into the execution container; (b) Enable lazy initialization, where the rule logic component is loaded into the execution container only when it is first triggered or matched to the target field; (c) The extracted matching rules are registered in the execution container in the form of modular components, each of which contains independent rule logic, configuration parameters and execution context.

5. The report verification batch parallel execution optimization method based on the pluggable rule engine framework according to claim 2 is characterized in that: The step S3 specifically includes: S3.

1. Receive financial statement data manually submitted by users or automatically generated by the business system through interfaces or file import, and complete data format verification and integrity checks; S3.

2. Call the built-in semantic parsing engine to deeply analyze the report structure, implement table recognition, field location, and cross-period joint table processing, and establish a mapping relationship between period labels and fields; S3.

3. Extract four types of meta-information from the parsing results: field path, data type, period information, and unit attributes. Then, construct a field merge index and multi-table fusion model for nested tables, supplementary tables, or cross-period joint tables in table recognition, and integrate the meta-information and structured report fields into a report field index table.

6. The report verification batch parallel execution optimization method based on the pluggable rule engine framework according to claim 5 is characterized in that: The step S4 specifically includes: S4.

1. Obtain the generated report field index table and load the currently active business rule set; S4.

2. Parse each rule in the business rule set to identify its input field set and output impact field set; S4.

3. Match the rule's input fields and output impact fields with the report field index table to determine the fields' physical paths and logical meanings, analyze the field sharing relationships between rules, and calculate the order of dependencies. S4.

4. Using rule entities as nodes and field sharing relationships or sequential dependency relationships as edges, a rule field dependency graph with a directed graph structure is constructed.

7. The report verification batch parallel execution optimization method based on the pluggable rule engine framework according to claim 6 is characterized in that: The step S5 specifically includes: S5.

1. Use the minimum cut set algorithm to divide the rule field dependency graph into multiple execution domains, perform topological sorting on the rules within each execution domain, and generate the dependency chain execution order. S5.

2. Generate rule batches without field conflicts based on the topological sorting results and the partitioning results of the rule field dependency graph. Dynamically adjust the batch size and the number of parallel threads based on the current host resource status. S5.3: In standalone scenarios, rule batches are submitted to the local thread pool for parallel execution. In high-concurrency scenarios, tasks are distributed to remote execution agents on multiple nodes through distributed message queues. S5.

4. During the above execution process, each rule is bound to an independent exception handler, which automatically captures calculation errors and field missing exceptions, executes skip, retry or interrupt operations according to the configured strategy, and marks the exception log.

8. The report verification batch parallel execution optimization method based on the pluggable rule engine framework according to claim 7 is characterized in that: Execute steps S5.2-S5.

3. Before, during, or after the rule batch is generated, perform the following operations simultaneously: Analyze field access frequency and cache fields that exceed the set frequency as high-frequency fields in a hot memory pool. When multiple rules reference the same field, they share intermediate calculation results to avoid repeated reading and calculation. For rules involving aggregate calculations or cross-period comparisons, pre-compilation is performed to generate reusable intermediate result execution graphs, shortening runtime calculation time.

9. The report verification batch parallel execution optimization method based on the pluggable rule engine framework according to claim 7 is characterized in that: The step S6 specifically includes: S6.

1. After rule execution is complete, the status of hit rules, failed rules, and warning rules will be centrally aggregated. Each record will include key information such as the rule number, execution time, specific fields hit, specific failure type, error level assessment, targeted recommendations, and the rule dependency chain path. S6.

2. Based on the above collected content, the execution result data, field-level error details, performance indicators, and dependency chain path information are integrated. Then, based on user-preconfigured or system-preset templates, a field-level verification report, report-level audit summary, audit chain log, visual heat map, and abnormal indicator time series chart are automatically generated; S6.

3. Export the verification report to JSON, Excel, or PDF format and push it to downstream systems through the interface. Support data structure mapping and automatic synchronization of the regulatory interface. S6.

4. Write the execution process metadata into the audit chain log for later archiving, performance evaluation, and troubleshooting, to build a full-chain explainable system.

Images