Dual-track consistency enforcement instruction compilation method and system

Abstract

The application discloses a double-track consistency execution instruction compiling method and system of rule summary, and relates to the field of artificial intelligence. In order to solve the defects of low efficiency, lack of verification and non-backtracking of the existing rule summary compiling method, the application obtains rule summary and domain knowledge base of business experts and carries out structured analysis to obtain standardized rule objects; applicable formats and trigger conditions are extracted; the intention is mapped to a predefined review mode set, and an instance of a review operator chain is instantiated as an abstract execution sequence; the operator chain is traversed, and a variable metadata set corresponding to each user is generated one by one; two types of products are generated in parallel: one is track A readable review text, which is used for driving a large model to expand interpretation reasoning according to fixed logic in the running period; and the other is track B machine-readable specification, which is used for performing deterministic comparison and post-stored strong constraint checking in the background. The application is mainly used for compiling the rule summary into double-track consistency execution instructions.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence, and in particular to a dual-track consistent execution instruction compilation method and system based on an outline of drawing review rules. Background Technology

[0002] With the increasing capabilities of large language models (LLMs) in semantic understanding and logical reasoning, and their integration with multimodal processing technologies such as image processing, OCR, and tables, the automated review of engineering documents and drawings has ushered in a new technological path. In the field of power distribution network engineering, especially in the review of drawings for power receiving projects, engineering practices have begun to explore intelligent review platforms that combine multimodal review models with rule bases, demonstrating significant potential in terms of interpretability, automation, and efficiency.

[0003] However, a core bottleneck in putting this technology into practice lies in the fact that engineering rules are often presented in highly generalized natural language in actual work, such as "the incoming line cabinet CT ratio should match the transformer capacity" or "the transformer selection should meet energy efficiency standards." Experienced business experts can understand the rules and complete the implicit steps, thresholds, units, and prohibitions, but if such rule summaries are directly input into large language models as prompts, the lack of clear execution steps and necessary domain constraints often leads to problems such as vague definitions, unclear thresholds and units, and difficulty in reproducing the results. This gap between "summary" and "executable" implementation is a key bottleneck in engineering applications.

[0004] There are three main existing technological approaches to address this problem, but all of them have significant drawbacks:

[0005] (1) Manual rule rewriting: This method relies on AI engineers or domain experts to manually rewrite each rule summary into detailed, structured prompts. This method is costly and time-consuming, and it is difficult to ensure logical consistency between rules written by different people, making version maintenance extremely difficult.

[0006] (2) Pure large model approach: Directly rely on large models for end-to-end auditing. Although this approach is flexible, it is difficult to meet the requirements of engineering auditing for strong consistency, replayability, and auditability due to the lack of verifiable deterministic constraints and explicit parameter, unit, and threshold specifications.

[0007] (3) Business rule engine: This type of engine has advantages in deterministic execution, but there is a semantic gap between its rule language and expert natural language, and professional IT personnel are still needed to intervene in the long term; at the same time, it lacks native processing capabilities for multimodal information such as images, layouts, and tables, and is difficult to be directly applied to complex scenarios of drawing review.

[0008] Therefore, there is an urgent need for a dual-track consistent execution instruction compilation method and system that can automate, verify, and trace back the review rules. Summary of the Invention

[0009] To address the shortcomings of existing drawing review rule compilation methods, such as low efficiency, lack of verifiability, and lack of backtracking, this invention provides a dual-track consistent execution instruction compilation method and system for drawing review rule overview that is automated, verifiable, and backtrackable.

[0010] The dual-track consistency execution instruction compilation method outlined in the drawing review rules of this invention includes the following steps:

[0011] S1. Obtain the rule overview and domain knowledge base from business experts, and perform structured parsing on the original rule overview to obtain standardized rule objects;

[0012] S2. Extract the applicable layout and triggering conditions from the rule object and the corresponding domain knowledge base;

[0013] S3. Based on the intent of the rule object, map the intent to a predefined set of review patterns, and instantiate a chain of review operators as an abstract execution sequence;

[0014] S4. Traverse the operator chain, collect the variables involved, and generate a set of variable metadata for each user.

[0015] S5. Using the operator chain and the variable metadata set as the sole source of facts, generate two types of products in parallel: one is track A readable audit text, which is used to drive the large model to unfold explanation and reasoning according to fixed logic during runtime; the other is track B machine readable specification, which is used for deterministic comparison and post-processing strong constraint verification in the background.

[0016] Furthermore, following S5, the following steps are also included:

[0017] S6. Extract and normalize the key elements involving structure and constraints in track A and track B, and perform hash consistency verification.

[0018] S7. During compilation, check whether track A and track B explicitly contain the prohibition constraints declared by the rule. After track B obtains the running result, perform the corresponding post-strong verification. If a result that violates the prohibition constraints is found, the compilation is deemed to have failed and the standard error code and evidence location are returned.

[0019] S8. Determine the input and output structure of the current rule during compilation to ensure that the compilation and execution interfaces remain consistent.

[0020] Further: In S6, the specific steps of the hash consistency verification include:

[0021] Extract structural elements from track A and track B that are only related to execution semantics;

[0022] It is sorted by key, deduplicated and whitespace-folded according to normalization rules, and regular expression is standardized before being serialized into standard JSON.

[0023] Calculate the hash values ​​for track A and track B respectively;

[0024] If the hash values ​​of the two hashes match, the release is allowed; if they do not match, it is determined to be a caliber drift, the system blocks the compilation and release and outputs a list of differences.

[0025] Furthermore, in S8, the output adopts a unified set of variable metadata, which includes status, extracted and calculated fields, evidence anchor array, error code list and brief reason description.

[0026] Further: In S1, the pre-configuration of the domain knowledge base includes: establishing a review operator library, registering domain entities and synonyms and registering external data sources, and cleaning, identifying entities and normalizing units in the natural language summary text of the rule summary to form standardized rule objects.

[0027] Furthermore: In S5, the readable audit text of Track A adopts a fixed Chinese step format; the machine-readable specification of Track B adopts JSON serialization, including gating, operator chain, variable metadata set, comparison strategy, post-validation and I / O convention.

[0028] The compilation system for implementing the dual-track consistency execution instruction compilation method outlined in the drawing review rules of the present invention includes a structured parsing module, a pre-verification module, an operator chain generation module, a traversal module, and a dual-track consistency generation module.

[0029] The structured parsing module is used to obtain the rule overview and domain knowledge base of business experts, and to perform structured parsing on the original rule overview to obtain standardized rule objects;

[0030] The pre-validation module is used to extract applicable layouts and triggering conditions from the rule object and the corresponding domain knowledge base;

[0031] The operator chain generation module is used to map the intent of the rule object to a predefined set of review patterns, and instantiate a review operator chain as an abstract execution sequence.

[0032] The traversal module is used to traverse the operator chain, collect the variables involved, and generate a set of variable metadata for each user.

[0033] The dual-track consistency generation module is used to take the operator chain and the variable metadata set as a unique source of facts and generate two types of products in parallel: one is track A readable audit text, which is used to drive the large model to unfold interpretation and reasoning according to fixed logic during runtime; the other is track B machine readable specification, which is used for deterministic comparison and post-strong constraint verification in the background.

[0034] The beneficial effects of this invention are:

[0035] This invention addresses the intelligent review requirements of power distribution network engineering design drawings (preferred embodiment: power receiving engineering design drawings for business expansion projects). It proposes a method to automatically transcribe the review rules outlined by business experts into two types of consistency products during the compilation phase. These products are: a readable review text (Track A) for driving the reasoning of a multimodal review model, providing clear and readable review text for the multimodal review model and ensuring the interpretability and controllability of the reasoning process; and a machine-readable specification (Track B) for platform-side deterministic comparison, post-validation, and replay evaluation, providing a rigid machine-readable specification for the platform side and supporting deterministic comparison, post-validation of prohibition constraints, and replay and regression evaluation.

[0036] It should be noted that intelligent drawing review platforms in engineering practice typically include runtime modules such as page classifiers, layout structuring, and evidence location. The method of this invention is independent of the platform implementation and focuses on the compilation problem of "rule overview → dual-track product".

[0037] The beneficial effects of this invention include the following aspects:

[0038] 1. Combining interpretability and verifiability: Track A ensures the interpretability of the review process for both humans and AI, while Track B ensures the determinism and verifiability of the execution logic.

[0039] 2. Prevent logical drift: Through dual-track same-source generation and structure hash verification, it is ensured that the logic displayed to the user is completely consistent with the logic actually executed in the backend.

[0040] 3. Strong system robustness: The two-stage prohibition constraint verification mechanism effectively prevents rules in key areas from being executed incorrectly, significantly reducing the risk of false positives and false negatives.

[0041] 4. Easy to maintain and migrate: Decoupling business logic from parameters and strategies makes rule base updates and cross-regional and cross-industry migrations efficient and low-cost.

[0042] 5. Supports auditing and regression: Machine-readable specifications can be directly used to drive model-free automated regression testing, facilitating version control, quality assurance, and post-auditing.

[0043] 6. The preferred implementation is based on the power receiving engineering drawings for business expansion, and can be extended to the relevant rule compilation scenarios for distribution network construction / renovation and main network engineering. Attached Figure Description

[0044] Figure 1 It is a diagram showing the overall system architecture and process overview;

[0045] Figure 2 This is the core flowchart for generating the basic review operator chain;

[0046] Figure 3 This is a schematic diagram of the dual-track consistency output and hash verification mechanism;

[0047] Figure 4 This is a timing diagram for verifying two-stage prohibition constraints;

[0048] Figure 5 This is a diagram showing the execution sequence and interface interactions of the system within the drawing review platform. Detailed Implementation

[0049] The following are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. The embodiments described below are only for explaining the present invention and should not be construed as limiting the present invention. The scope of protection of the present invention should be determined by the scope of the claims. The embodiments of the present invention are described in detail below. In order to facilitate the description of the present invention and simplify the description, the technical terms used in the specification of the present invention should be interpreted broadly, including but not limited to conventional alternatives not mentioned in this application, and including both direct and indirect implementation methods.

[0050] Example 1

[0051] Combination Figure 1 and Figure 2 This embodiment describes a complete method for converting a "rule overview" into two products during compilation. This process is completed only at the compilation end and does not involve runtime evaluation or review of specific drawings. The goal of the method is to deterministically compile the business expert's overview rules into: a highly readable review text for Track A, used to drive large model inference, and a machine-readable specification (JSON) for Track B, used for deterministic execution and strong post-validation by the drawing review platform. The entire process includes the following steps.

[0052] S1. Structured parsing of the original rules:

[0053] The system receives rule overview text, related parameter tables and knowledge bases, as well as terminology and unit specifications from business experts, and performs cleaning, entity identification, and terminology normalization. It then parses these into a standardized rule object, clarifying the rule's entities, intent categories, and external resource references, providing a unified input for subsequent steps.

[0054] S2. Definition of pre-validation for page applicability of rules:

[0055] Applicable layouts and triggering conditions are extracted from rule objects and domain knowledge, and gating is defined in the form of preconditions. The conditions for activating rules at runtime are agreed upon using the structure "page_type_in page type set + must_contain mandatory element". Whether a page is matched is determined by the runtime page classifier.

[0056] S3. Overview of Basic Review Operator Chain Generation:

[0057] Based on the intent of the rule object, it is mapped to a predefined set of review patterns, and a basic review operator chain is instantiated as an abstract execution sequence. The atomic operator library of this invention includes, but is not limited to: extract, lookup, compose, compare, anchor, normalize, regex_match, threshold, range_check, exists, format_check, sequence_check, aggregate, cross_page_consistency, unit_convert, route_if, branch, etc. Specific embodiments may select from these as needed. The following are merely illustrative examples; the operator library can be expanded according to project needs; specific embodiments only use necessary subsets. The atomic operator library, its Chinese names, and operation instructions are as follows:

[0058] extract: Extracts structured values ​​from text areas, table cells, or annotations in drawings; can carry source priority, regular expressions, and format constraints, and outputs evidence location information.

[0059] Lookup: Queries standard values ​​in a registered parameter table / knowledge base using one or more keys; supports metadata declarations with nearest value retrieval, range matching, and missing value fallback strategies.

[0060] compose (composition / expression): Combines intermediate variables into strings or derived values ​​according to an expression template, for example, generating "<I1_A> Standard CT ratio in the form of / 5”; can be bound to prohibition constraints (such as forbid_simplify) and unit locking policies.

[0061] compare: performs comparisons on both sides of the value by equality, threshold, interval or set matching; equality rules (e.g. "x / 5" and "x / 5A" are considered equal) and tolerances can be configured.

[0062] Anchor (evidence location): Bind the conclusion to evidence anchors such as "location of capacity source" and "location marked on CT", which facilitates interpretable presentation and auditing.

[0063] normalize: unifies units, numerical formats, capitalization, etc. (e.g., kV) kV and blank folding only change the representation without changing the semantics.

[0064] regex_match: Uses regular expressions to determine whether text matches a given pattern. It is used as a pre-filter for parameter extraction or format validation.

[0065] Threshold (threshold comparison): Compares the extracted value with a threshold using ≥, ≤, =, etc., and is used for items such as energy efficiency level and minimum cross-section.

[0066] range_check (range check): Determines whether a value is within a closed / open interval, and supports multiple intervals and unit conversions.

[0067] EXISTS (existence check): Checks if an object or annotation exists; it will directly fail if "required equipment / parameters are missing".

[0068] format_check (format check): Strictly constrains the format of the parameter (e.g., "must be a string of 'x / 5'").

[0069] sequence_check (number continuity): Performs sequence integrity and number skipping checks on switch cabinets, circuit numbers, etc.

[0070] aggregate (aggregation / counting): sums, counts, removes duplicates, etc. across objects, used for rules such as "at least N items satisfy" and "total power is not less than".

[0071] cross_page_consistency: Constrains parameters to be consistent across different pages, such as the correspondence between a system diagram and a device table.

[0072] unit_convert (unit conversion): Performs unit normalization and conversion (e.g., kVA) before comparison. MVA, mm² cm²).

[0073] route_if (conditional routing) / branch (branch decision): Draw different branches in the operator chain according to the conditions (e.g., "metering CT / protection CT" follow different rule branches).

[0074] S4. Parameter instantiation and intermediate variable definition based on information source:

[0075] The operator chain is traversed, collecting the variables involved. A schema of variable metadata for each user is generated, specifying the type and unit, source priority, regular expressions and format constraints, table lookup and expression, fallback strategy, standard error codes, and mandatory prohibitions. This step is strictly limited to structure definition and does not perform any numerical calculations or expression evaluations at compile time.

[0076] The information sources include direct extraction, external data table queries, and expression calculations, etc.

[0077] The direct extraction refers to extracting variables directly from specific areas (such as tables, annotations, and paragraphs) in the drawings of the power receiving project. The extraction methods include extraction through regular expressions or pattern matching.

[0078] The external data table query is obtained by searching externally registered data tables (such as the "Transformer Capacity and Current Transformer Configuration Comparison Table") to obtain standard values ​​and comparing them to obtain variables;

[0079] The calculation expression is derived from other variables through formulas or expressions to obtain parameter values;

[0080] For example, for high-voltage incoming switchgear, the physical formula for calculating current is based on the three-phase power formula:

[0081] ;

[0082] Where: S is apparent power / transformer capacity (unit: kVA); U is line voltage (unit: kV, high voltage side is usually 10kV); I is current (unit: A); .

[0083] Table 1. Comparison of Transformer Capacity and Current Transformer Configuration;

[0084]

[0085] S5, Dual-track Consistency Output Generation:

[0086] Using the operator chain of S3 and the variable metadata set schema of S4 as the sole source of facts, two types of products are generated in parallel: one is the readable audit text of Track A, which adopts the Chinese step-by-step style and includes precautions and evidence anchor points, used to drive the large model to unfold interpretable reasoning according to fixed logic during runtime; the other is the machine-readable specification of Track B, which adopts JSON document and fully provides page gating, operator chain, variable schema, comparison strategy, post-validation and I / O interface conventions.

[0087] S6. Structure hash consistency check:

[0088] Key structural and constraint elements (such as variable names, computed expressions, outer table IDs, forbidden constraint sets, comparison strategies, and I / O conventions) in tracks A and B are extracted and normalized (using key sorting, set deduplication sorting, whitespace folding, and unified escaping of regular expressions). These are then serialized into Canonical JSON and their SHA-256 hashes are calculated. If the hashes of the two tracks are inconsistent, it is considered a caliber drift, compilation is halted, and a list of differences is output.

[0089] S7. Verification of Prohibition Constraints:

[0090] During compilation, check whether both Track A and Track B explicitly include the prohibition constraints declared in the rule (e.g., "CT ratio must not be reduced"). Simultaneously, define the `post_checks` field in Track B for runtime, requiring the executor to perform corresponding strong post-checks after obtaining the runtime result; if a result violating the prohibition constraints is found, immediately determine failure and return a standard error code and the location of the evidence.

[0091] S8. Execution-time Interface Conventions:

[0092] The schema of the input and output variable metadata set for this rule is determined during compilation to ensure interface consistency between compilation and runtime. Inputs include page assets, track A text and track B specifications, and references to external parameter tables; outputs include status, extracted and calculated fields, evidence anchors, error codes, and brief explanations. The method of this invention is not limited to a specific runtime engine; it can employ a collaborative approach of "large model inference by track A + executor deterministic comparison by track B," or be tailored as needed.

[0093] Example 2

[0094] This embodiment is described in conjunction with Example 1. To more clearly present the method of the present invention, this embodiment uses several typical rules as examples to give a complete compilation process from the rule overview text to the dual-track output. Only the structure and template are generated throughout the process; no numerical values ​​are solved during compilation.

[0095] S1. Structured parsing of the original rules:

[0096] Before this step begins, the system has already completed the necessary pre-configurations in the domain knowledge base:

[0097] S11. Establish a basic audit operator library consisting of extraction operators, table lookup operators, combination operators, comparison operators, anchor point operators, etc.

[0098] S12. Register domain entities and synonyms, such as device names, parameter names and their aliases;

[0099] S13. Register an external data source, such as a device parameter configuration lookup table. This table uses device parameters as keys and outputs corresponding standard configuration values.

[0100] S14. Record engineering strategies and declare prohibitions, such as prohibiting mathematical simplification of parameters in a specific format.

[0101] The system then receives the natural language summary text, performs cleaning, entity recognition, and unit normalization to form a standardized rule object. This rule object includes the rule name, intent category, the set of entities involved, and a list of referenced external resources. The intent category identifies the core validation pattern of the rule, such as table lookup matching validation, threshold comparison validation, cross-page consistency validation, or aggregate statistics validation.

[0102] S2. Definition of pre-validation for page applicability of rules:

[0103] Based on rule objects and layout knowledge, the system provides the set of pages to which this rule applies and the triggering conditions, expressed in a precondition structure. The precondition structure contains two core elements: a set of page types and required elements. The set of page types defines the page categories required for rule activation (e.g., "Primary System Diagram," "Bill of Materials"); the required elements define the key objects or identifiers that must appear on the page (e.g., the "Incoming Line Cabinet" element must be included). Whether a page is matched during runtime is determined by the page classifier.

[0104] Taking review-type rules as an example, when a rule needs to verify the parameter configuration of a certain type of device, the precondition can be set as follows: the page type belongs to a system configuration diagram or parameter table, and the page must contain the identifier of that type of device. For cross-page consistency rules, the precondition can be set as follows: multiple related page types exist simultaneously, and each page contains the target object to be compared.

[0105] S3. Overview of Basic Review Operator Chain Generation:

[0106] The system first maps the intent category of the rule object to a predefined review pattern, and then instantiates an operator chain based on this pattern template. The operator chain has strictly defined order and function, and only the execution skeleton is generated at compile time without performing numerical calculations.

[0107] Depending on the different intent categories, typical structures of operator chains include the following patterns:

[0108] The lookup and matching mode is as follows: First, the extraction operator is executed to extract key parameter values ​​from the drawing. Then, the lookup operator is executed to query the standard configuration in the external data table with the parameter value. Next, the combination operator is executed to generate standard verification values ​​according to the expression template. Then, the extraction operator is executed again to extract the actual annotation values ​​from the drawing. Finally, the comparison operator is executed to perform matching and verification according to the predetermined rules, and the anchor point operator outputs evidence positioning information.

[0109] Threshold comparison mode: First, the extraction operator is executed to extract the parameter values ​​to be verified from the drawing. Then, the classification operator or conditional routing operator is executed to determine the category of the parameter and the corresponding threshold standard. Next, the threshold operator is executed to perform numerical comparison and judgment. Finally, the anchor point operator outputs the evidence location information.

[0110] Cross-page consistency mode: First, extract operators are executed on multiple pages to extract parameter values ​​or description information of the same object on different pages. Then, aggregation operators are executed to convert the extraction results of each page into a comparable structured form. Next, normalization operators are executed to unify the format. Then, comparison operators are executed to perform cross-page consistency verification. Finally, anchor operators are used to mark the source of evidence on each page.

[0111] Aggregation statistics mode: First, the extraction operator is executed to extract a set of target objects from the drawing. Then, the aggregation operator is executed to perform statistical operations such as counting, summing or deduplication. Next, the threshold operator or interval verification operator is executed to determine whether the statistical results meet the requirements. Finally, the anchor point operator outputs evidence location information.

[0112] S4. Parameter instantiation and intermediate variable definition based on information source:

[0113] The system traverses the above operator chain, generating a variable metadata set schema for each variable, specifying the type and unit, source priority and regular expression, table lookup and expression with fallback strategy, as well as the prohibitions and standard error codes that must be followed. This step only defines the structure and does not render expressions or calculate any values. Taking this embodiment as an example, the variable definitions are as follows.

[0114] Each variable definition in the variable metadata collection contains the following elements: The data type field indicates whether the variable is numeric, string, list, or character; the unit field indicates the unit of measurement; the required flag indicates whether the variable is a necessary input for rule execution; the source priority field lists the sources from which the variable was extracted in order of priority, e.g., tables take precedence over annotations, and annotations take precedence over paragraph text; the matching pattern field provides a characteristic description used to identify the variable; the derivation field indicates whether the variable is obtained through a table lookup or an expression calculation; the fallback strategy field indicates the alternative calculation method when the primary source is missing; the constraint list field lists the format constraints or prohibitions that the variable must adhere to; and the error code field lists the standard error codes that should be returned when the variable is missing or non-compliant.

[0115] For derived variables, the system supports three information sources: direct extraction, which means extracting the variable directly from a specific area in the drawing; external data table query, which means obtaining the standard value by searching the registered data table; and calculation expression, which means deriving the parameter value from other variables through formulas.

[0116] S5, Dual-track Consistency Output Generation:

[0117] The system uses the operator chain and the variable metadata set as the sole source of facts, and generates two types of products, track A and track B, while maintaining consistency between fields and expressions.

[0118] Track A is a readable review text, using a fixed Chinese step format, used to drive the large model to generate interpretable reasoning processes during runtime; Track A is only a template and does not contain any runtime values; the structure of Track A includes: an applicable page declaration, specifying the page conditions for this rule to be activated; a step sequence, describing the operations such as extraction, table lookup, combination, and comparison step by step in the operator chain, with each step marked with the operation type, target variable, source range, and precautions; and an output description, specifying the type of conclusion to be given and the requirements for evidence anchors.

[0119] Track B is a machine-readable specification using a structured data format, fully outlining page gating conditions, operator chain definitions, variable metadata sets, comparison strategies, post-validation rules, and input / output interface conventions. The structure of Track B includes: rule name, preconditions, operator chain, variable definitions, comparison strategy configuration, post-validation list, and output mode conventions. The comparison strategy configuration specifies the working mode of the comparison operator, such as exact string matching, tolerance-based numerical comparison, dictionary equality comparison, or set inclusion comparison. The post-validation list specifies the mandatory validation items that must be performed at runtime. The output mode conventions specify the fields that the output results must include, including status, extracted fields, calculated fields, evidence anchors, error codes, and brief explanations.

[0120] S6. Structure hash consistency check:

[0121] This step is used to eliminate the caliber drift between readable text and machine specifications at the compiler level. The specific verification process is as follows:

[0122] First, extract only the structural elements related to execution semantics from track A and track B, including key elements such as preconditions, operator chains, variable definitions, comparison strategies, post-validation rules, and input / output conventions, while excluding non-semantic content such as comments and formatting specifications.

[0123] Secondly, the extracted structural elements are standardized according to the standardization rules, including: sorting the key names in a dictionary to ensure that different writing orders of the same content produce the same results; deduplicating and sorting the set data to eliminate order differences; folding whitespace to unify consecutive whitespace characters into a single space; and standardizing the expression of special characters.

[0124] Then, the normalized structural elements are serialized into a normalized format to ensure that the same semantic content produces the same serialization result.

[0125] Finally, the digest values ​​are calculated for the normalized sequences of track A and track B respectively. If the digest values ​​are the same, publication is allowed; if they are different, it is determined to be a caliber drift, the system blocks compilation and publication and outputs a discrepancy list, indicating the specific elements of the disagreement between the two tracks.

[0126] S7. Verification of Prohibition Constraints:

[0127] This step creates a closed loop between compilation and runtime, ensuring that key constraints are strictly adhered to.

[0128] During compilation, the system verification track A text must contain explicit hints of prohibited constraints in the rule declarations. For example, for constraints prohibiting reduction, track A should contain "Strictly Prohibited from Reduction" or an equivalent expression. At the same time, the constraint list of the relevant operators in verification track B should contain the corresponding prohibition flags. If any product is missing a declaration of a prohibited constraint, compilation will fail and the product will not be released.

[0129] During runtime, the system enforces post-verification of results according to the post-verification requirements in Track B. The execution logic of post-verification is as follows: obtain the result value generated during runtime, check whether the result violates the constraint list item by item; if a result that violates the constraint is found, it is immediately judged as a failure with a standard error code and the evidence position is returned; if the result is missing the necessary evidence information, it is also judged as a failure and the corresponding error code is returned.

[0130] S8. Dateline Interface Conventions:

[0131] This step determines the runtime input and output structure during compilation, ensuring that the rules can be reliably received by the platform.

[0132] The input structure includes: a readable audit text template for Track A, a machine-readable specification for Track B, page text recognition results, table structured results, image data, and references to external parameter tables.

[0133] The output structure uses a unified set of variable metadata, which must include the following fields: Target object identifier, used to specify the specific object currently being reviewed; Status field, with values ​​of Pass, Fail, Pending, or Inapplicable; Extracted field set, containing parameter values ​​directly extracted from the drawings; Calculated field set, containing parameter values ​​obtained through table lookup or formula calculations and their calculation basis; Evidence anchor array, containing the type, location information, and description of each piece of evidence; Error code list, containing the standard error codes for all errors found in this review; Brief explanation of the reasons, describing the main basis for the review conclusion in natural language.

[0134] Example of compiling multi-type rules:

[0135] To illustrate the universality of the method of this invention, the following describes the key points of compiling several typical rules:

[0136] Category 1: Lookup-based matching rules. A typical summary of this type of rule is "A certain parameter of a certain device should match a certain standard configuration." During compilation, the operator chain sequentially includes: extracting the key parameters of the device from the drawings; looking up the standard value in the configuration lookup table using that parameter; combining standard verification values ​​according to the rule template; extracting the actual labeled values ​​from the drawings; comparing them according to equivalence rules or tolerance rules; and outputting evidence anchors. The variable metadata set should define the extraction mode and source priority of key parameters, the lookup relationship and fallback strategy of standard values, the matching mode of actual labeled values, and the equivalence rules or tolerance range of the comparison strategy. The compilation focus is on establishing the mapping between "extracted values" and "standard values." The variable metadata needs to define the "lookup key" and "fallback calculation formula" of the standard values, and the comparison strategy needs to define whether unit conversion or string equivalence is allowed (e.g., "x / 5" is equivalent to "x / 5A").

[0137] The second type: Threshold comparison rules. A typical summary of this type of rule is "a certain indicator of a certain device should meet a certain standard." During compilation, the operator chain sequentially includes: extracting the device model or specification information from the drawings; determining the device category and corresponding threshold standard according to classification rules; extracting the value to be compared from the model or specification; performing the threshold comparison judgment; and outputting the evidence anchor point. The variable metadata set should define the model extraction mode, the correspondence between classification rules and thresholds, and the method for extracting the value to be compared. The compilation focus is on "conditional routing." The operator chain must contain routing nodes that dynamically point to different threshold variables based on the extracted device model prefix (e.g., dry / oil-immersed). The threshold constants under different branches must be clearly defined in the variable definition.

[0138] The third category: Cross-page consistency rules. A typical summary of this type of rule is "the information of an object should remain consistent across multiple pages." During compilation, the operator chain sequentially includes: extracting the information set of the target object from the first type of pages, extracting the same target object's information set from the second type of pages, performing aggregation and normalization on the two sets respectively, comparing them according to dictionary equivalence or set equivalence rules, and outputting the evidence anchor points for each page. The variable metadata set should define the extraction mode, aggregation method, normalization rules (including synonym mapping, format uniformity, etc.), and comparison strategy for each page. The compilation focus is on "aggregation and normalization." The operator chain needs to include separate extraction and aggregation for the two pages (e.g., generating a "model-quantity" dictionary), define normalization rules to eliminate writing differences (e.g., capitalization, full / half-width characters), and finally use a dictionary comparison strategy for full verification.

[0139] Category 4: Tolerance-based comparison rules. These rules are typically summarized as "a calculated value should match a standard value." At compile time, the operator chain structure is similar to that of a lookup-based matching rule, but the comparison operator uses a tolerance mode instead of an exact match mode. The variable metadata set should additionally define the values ​​for relative or absolute tolerance, as well as the reporting format when differences exceed limits.

[0140] Through the above method, the present invention can systematically compile various review rules into a dual-track consistent product, which ensures both the interpretability of the review process and the determinism and verifiability of the execution logic.

Claims

1. A dual-track consistency execution instruction compilation method based on the drawing review rules, characterized in that, Includes the following steps: S1. Obtain the rule overview and domain knowledge base from business experts, and perform structured parsing on the original rule overview to obtain standardized rule objects; S2. Extract the applicable layout and triggering conditions from the rule object and the corresponding domain knowledge base; S3. Based on the intent of the rule object, map the intent to a predefined set of review patterns, and instantiate a chain of review operators as an abstract execution sequence; S4. Traverse the operator chain, collect the variables involved, and generate a set of variable metadata for each user. S5. Using the operator chain and the variable metadata set as the sole source of facts, generate two types of products in parallel: one is track A readable audit text, which is used to drive the large model to unfold explanation and reasoning according to fixed logic during runtime; the other is track B machine readable specification, which is used for deterministic comparison and post-processing strong constraint verification in the background. Following S5, the following steps are also included: S6. Extract and normalize the key elements involving structure and constraints in track A and track B, and perform hash consistency verification. S7. During compilation, check whether track A and track B explicitly contain the prohibition constraints declared by the rule. At the same time, perform the corresponding strong post-validation after the running result is obtained from track B. If a result that violates the prohibition constraint is found, the compilation is deemed to have failed and a standard error code and evidence location are returned; S8. Determine the input and output structure of the current rule during compilation to ensure that the compilation and execution interfaces remain consistent. In S5, the readable audit text of Track A adopts a fixed Chinese step format; the machine-readable specification of Track B adopts JSON serialization, including gating, operator chain, variable metadata set, comparison strategy, post-validation and I / O convention.

2. The dual-track consistency execution instruction compilation method according to the drawing review rules outlined in claim 1, characterized in that, In S6, the specific steps of the hash consistency verification include: Extract structural elements from track A and track B that are only related to execution semantics; It is sorted by key, deduplicated and whitespace-folded according to normalization rules, and regular expression is standardized before being serialized into standard JSON. Calculate the hash values ​​for track A and track B respectively; If the hash values ​​of the two hashes match, the release is allowed; if they do not match, it is determined to be a caliber drift, the system blocks the compilation and release and outputs a list of differences.

3. The dual-track consistency execution instruction compilation method according to the drawing review rules outlined in claim 1, characterized in that, In S8, the output uses a unified set of variable metadata, which includes status, extracted and calculated fields, evidence anchor array, error code list and brief reason description.

4. The dual-track consistency execution instruction compilation method according to the drawing review rules outlined in claim 1, characterized in that, In S1, the pre-configuration of the domain knowledge base includes: establishing a review operator library, registering domain entities and synonyms and registering external data sources, and cleaning, identifying entities and normalizing units in the natural language summary text of the rule summary to form standardized rule objects.

5. A compilation system for implementing the dual-track consistency execution instruction compilation method outlined in the drawing review rules as described in any one of claims 1-4, characterized in that, It includes a structured parsing module, a pre-verification module, an operator chain generation module, a traversal module, and a dual-track consistency generation module; The structured parsing module is used to obtain the rule overview and domain knowledge base of business experts, and to perform structured parsing on the original rule overview to obtain standardized rule objects; The pre-validation module is used to extract applicable layouts and triggering conditions from the rule object and the corresponding domain knowledge base; The operator chain generation module is used to map the intent of the rule object to a predefined set of review patterns, and instantiate a review operator chain as an abstract execution sequence. The traversal module is used to traverse the operator chain, collect the variables involved, and generate a set of variable metadata for each user. The dual-track consistency generation module is used to take the operator chain and the variable metadata set as a unique source of facts and generate two types of products in parallel: one is track A readable audit text, which is used to drive the large model to unfold interpretation and reasoning according to fixed logic during runtime; the other is track B machine readable specification, which is used for deterministic comparison and post-strong constraint verification in the background.

Images