A low-code application automatic generation method and system for the engineering construction industry

Abstract

The application relates to the field of software engineering, and in particular to a low-code application automatic generation method and system for the engineering construction industry, wherein the method comprises the following steps: using a multi-modal large model to analyze engineering industry specification information, constructing a business constraint network and an engineering business blueprint, dividing a business constraint community through a community discovery algorithm, generating engineering specification bytecode through double-end isomorphic compilation, integrating an initial low-code program package by combining a business entity mapping business execution template, completing offline verification through a local virtual sandbox, carrying out online causal topology verification, driving business constraint network topology evolution according to double-line verification logs, optimizing the initial program package to obtain an engineering low-code program package, and finally solidifying the evolved constraint network and deploying a background auxiliary engine to generate an engineering low-code application. The application can realize automatic generation of low-code applications in the engineering industry, effectively fit engineering specification constraints, and improve the generation quality of low-code applications.

Description

Technical Field

[0001] This invention relates to the field of software engineering, and in particular to a method and system for automatically generating low-code applications for the engineering and construction industry. Background Technology

[0002] With the continuous advancement of digital transformation in fields such as construction engineering and municipal infrastructure, low-code development platforms are widely used to quickly build various engineering management business systems due to their advantages of short development cycles and flexible deployment. The construction industry involves diverse business scenarios such as construction control, quality acceptance, safety inspection, testing and inspection, equipment management, and final acceptance. The implementation of each business strictly relies on industry specifications, standard documents, internal management systems, and standardized business forms. Rapidly customizing low-code applications that meet business needs based on engineering specifications has become a core research direction for the implementation of digital transformation in engineering.

[0003] In existing low-code automatic generation solutions, engineering specification data needs to go through multiple processing steps such as text parsing, format conversion, logic compilation, program integration, and online deployment. Generally, there is a lack of a unified processing mechanism covering the entire application generation process. Each step is independent and loosely connected, which can easily lead to problems such as cross-step data misalignment, business logic conflicts, and program integration and adaptation anomalies. The resulting low-code applications often have defects such as business logic deviations, poor program integration compatibility, and non-compliance, which significantly reduces the quality and usability of the automatically generated low-code applications. Summary of the Invention

[0004] This invention provides a method and system for automatically generating low-code applications for the engineering and construction industry, which improves the quality of generated low-code applications.

[0005] The technical solution adopted by this invention to solve its technical problem is:

[0006] On the one hand, this invention provides a method for automatically generating low-code applications for the engineering and construction industry, including the following steps:

[0007] S101. Based on the pre-constructed multimodal large model, perform specification text parsing on the received engineering industry specification information, construct a business constraint network based on the specification text parsing results, and construct an engineering business blueprint based on the business constraint network. The engineering business blueprint includes engineering business rules and engineering business entities.

[0008] S102. Divide the business constraint network into business constraint communities according to the community discovery algorithm, and perform double-ended isomorphic compilation on the engineering business rules according to the division results of the business constraint communities to obtain the engineering specification bytecode;

[0009] S103. Construct a business execution template based on the engineering business entity mapping, and perform program integration based on the business execution template and engineering specification bytecode to generate an initial low-code program package;

[0010] S104. Perform offline verification on the initial low-code package based on the pre-built local virtual sandbox, and generate offline verification logs based on the offline verification results;

[0011] S105. Perform causal topology verification of the initial low-code package online based on the offline verification log, and generate online verification log based on the causal topology verification results;

[0012] S106. Perform topology evolution on the service constraint network based on the offline verification log and the online verification log, and optimize the initial low-code package based on the service constraint network after the topology evolution to obtain the engineering low-code package;

[0013] S107. Solidify the business constraint network that has completed topology evolution into the engineering low-code package, and deploy the background auxiliary engine in the solidified engineering low-code package to obtain the engineering low-code application.

[0014] Furthermore, in step S101, the received engineering industry standard information is parsed using a pre-constructed multimodal large model. A business constraint network is then constructed based on the parsing results, and an engineering business blueprint is built based on the business constraint network. This includes the following steps:

[0015] S201. Based on the multimodal large model, identify and extract engineering specification structure blocks of engineering industry standard information. Among them, the engineering specification structure blocks include engineering specification table blocks, engineering specification formula blocks, engineering specification text blocks and engineering specification vector blocks. The multimodal large model includes entity recognition engine, symbol calculation engine and syntactic analysis engine.

[0016] S202. Perform text semantic parsing on all engineering specification structural blocks using the entity recognition engine, and generate an engineering semantic entity set based on the text semantic parsing results;

[0017] S203. Retrieve the project form template from the pre-built project database, perform form template matching on all project semantic entities in the project semantic entity set according to the project form template, and complete the parameter filling of the project form template according to the form template matching result to obtain the project template instance;

[0018] S204. Extract the set of engineering constraints for the engineering specification structure blocks from the multimodal large model, and construct a business constraint network based on the set of engineering constraints. The set of engineering constraints includes the set of engineering calculation constraints, the range of engineering risk parameters, and the engineering temporal causal chain.

[0019] S205. Using engineering template instances as the backbone of engineering business, and encapsulating business constraint networks and engineering temporal causal chains as core components of engineering business, an engineering business blueprint is constructed. The engineering business blueprint includes engineering business rules, engineering business entities, business constraint networks, and business relationships.

[0020] Furthermore, in step S204, the engineering constraint set of the engineering specification structural block is extracted based on the multimodal large model, and the business constraint network is constructed based on the engineering constraint set, including the following steps:

[0021] S301. The mathematical expression is parsed from the engineering specification formula block and the engineering specification text block using the symbolic computation engine;

[0022] S302. Generate forward calculation logic and reverse verification logic based on mathematical expressions, and combine the forward calculation logic and reverse verification logic to generate a set of engineering calculation constraints;

[0023] S303. Perform flexible semantic recognition based on the engineering specification text block, query the corresponding historical deviation distribution parameters from the engineering database based on the flexible semantic recognition results, and generate the corresponding engineering risk parameter range based on the historical deviation parameters;

[0024] S304. Use a syntactic analysis engine to identify process relationships and corresponding process relationship confidence from engineering specification text blocks, and construct a directed causal graph of the engineering based on the process relationships;

[0025] S305. Perform directed cycle detection on the directed causal graph of the project using the graph search algorithm. Based on the directed cycle detection results and the process association confidence, optimize the causal graph of the directed causal graph of the project to obtain the temporal causal chain of the project.

[0026] S306. Map the set of engineering calculation constraints, the range of engineering risk parameters, and the engineering time-series causal chain to formal constraint nodes, and construct node association edges based on the process association relationships between formal constraint nodes;

[0027] S307. Retrieve historical engineering business records from the engineering database, and search for engineering event association parameters from the historical engineering business records based on the association rule mining algorithm;

[0028] S308. Generate candidate constraint nodes based on the engineering event association parameters, and associate the candidate constraint nodes with the corresponding formal constraint nodes or node association edges to obtain the business constraint network.

[0029] Furthermore, in step S102, the business constraint community of the business constraint network is divided according to the community detection algorithm, and the engineering business rules are compiled isomorphically by both ends according to the division results of the business constraint community to obtain the engineering specification bytecode, including the following steps:

[0030] S401. Map the global business constraint graph based on the formal constraint nodes, candidate constraint nodes, and node-associated edges;

[0031] S402. Retrieve historical engineering business records from the engineering database, calculate the historical operation attributes of all constraint nodes based on the historical engineering business records, and calculate the edge weights of the global business constraint graph based on the historical operation attributes of the nodes.

[0032] S403. Construct a modularity optimization function to complete the global business constraint graph based on the graph edge weights. Divide the global business constraint graph into communities based on the modularity optimization function and the community detection algorithm to obtain multiple business constraint communities.

[0033] S404. Traverse all node association edges between business constraint communities and extract all cross-community bridge edges between business constraint communities;

[0034] S405. Determine the cross-community data flow direction between all business constraint communities based on the cross-community bridging edge, and generate community interaction protocol interfaces based on the cross-community data flow direction;

[0035] S406. Traverse the business constraint community, extract the engineering business rules corresponding to all formal constraint nodes in the community, and perform double-ended isomorphic compilation on all engineering business rules according to the business constraint community to obtain the standard bytecode module;

[0036] S407. Establish cross-module call relationships between all standard bytecode modules according to the community interaction protocol interface, and complete the program integration of all standard bytecode modules according to the cross-module call relationships to obtain the engineering standard bytecode.

[0037] Furthermore, in step S103, a business execution template is constructed based on the engineering business entity mapping, and program integration is performed based on the business execution template and the engineering specification bytecode to generate an initial low-code program package, including the following steps:

[0038] S501. Extract the set of business attributes of the engineering business entities based on the engineering business blueprint, wherein the set of business attributes includes entity attribute parameters, entity association relationships and business constraint relationships;

[0039] S502. Map all engineering business entities to the corresponding business execution template body according to the entity attribute parameters;

[0040] S503. Based on the business constraint network, map the engineering business rules corresponding to the formal constraint nodes to the business execution template body to obtain the business execution template. Based on the mapping result of the engineering business rules, construct the rule calling relationship between the business execution template and the engineering specification bytecode.

[0041] S504. Determine the template reference relationships between business execution templates corresponding to engineering business entities based on entity association relationships;

[0042] S505. Establish program integration relationships based on rule call relationships, template reference relationships, and process association relationships. Based on the program integration relationships, complete the program integration of engineering specification bytecode and business execution templates to generate an initial low-code program package.

[0043] Furthermore, in step S104, the initial low-code package is offline verified based on the pre-built local virtual sandbox, and an offline verification log is generated based on the offline verification results, including the following steps:

[0044] S601. Deploy the initial low-code package to a pre-built local virtual sandbox;

[0045] S602. Calculate the node topology attributes of all constraint nodes in the business constraint network, and determine the attack priority of all constraint nodes based on the node topology attributes and the division results of the business constraint community. Among them, constraint nodes include formal constraint nodes and candidate constraint nodes.

[0046] S603. Retrieve historical engineering business records from the engineering database, and calculate the historical operation attributes of all constraint nodes based on the historical engineering business records. The historical operation attributes of nodes include historical operation activity, historical operation stability, and historical conflict contribution.

[0047] S604. Calculate the chaotic verification operation sequence based on the attack priority, node historical running attributes, and engineering constraint set;

[0048] S605. Run the initial low-code program package according to the chaotic verification operation sequence, synchronously collect the program running parameters of the initial low-code program, and generate offline verification logs based on the program running parameters.

[0049] Furthermore, in step S604, the chaotic verification operation sequence is calculated based on the attack priority, the node's historical running attributes, and the engineering constraint set, including the following steps:

[0050] S701. Based on the attack priority and the historical operation attributes of the nodes, the target constraint nodes and the corresponding target associated edges are selected from the business constraint network.

[0051] S702. Locate the preceding and subsequent processes in the engineering time-series causal chain based on the target associated edge, and search for the target process path along the engineering time-series causal chain based on the preceding and subsequent processes;

[0052] S703. Perturb the path sequence of the target process path to obtain the process attack sequence;

[0053] S704. Based on the set of engineering calculation constraints corresponding to the target constraint node, select all engineering variables and variable constraints, and dynamically perturb all engineering variables and variable constraints to generate a constraint conflict attack sequence.

[0054] S705. Based on the preset perturbation step size and perturbation direction, continuously perturb all engineering risk parameter intervals corresponding to the target constraint node to obtain the interval attack sequence;

[0055] S706. Based on the cross-combination of process attack sequence, constraint conflict attack sequence and interval attack sequence, a chaotic verification operation sequence is obtained.

[0056] Furthermore, in step S105, the causal topology verification of the initial low-code package is completed online based on the offline verification log, and an online verification log is generated based on the causal topology verification results, including the following steps:

[0057] S801. Deploy the initial low-code package to a pre-built shadow server;

[0058] S802. Extract the operation log sequence from the offline verification log and inject the operation log sequence concurrently into the shadow server;

[0059] S803. When the shadow server receives the operation log sequence, it uses the multimodal large model to parse out the metadata fields of all operation logs in the operation log sequence. The metadata fields include the hybrid logical clock value, causal hash pointer, business document, and business entity.

[0060] S804. Using the operation log as the operation node, and combining the hybrid logic clock value and the causal hash pointer, establish the operation causal edge between the operation nodes to obtain the operation causal topology graph;

[0061] S805. Based on the operation cause-effect topology graph, perform topological sorting of all operation logs to obtain the target replay sequence;

[0062] S806. Input all operation logs into the initial low-code package according to the target playback sequence, execute business playback through the initial low-code package, and obtain the business playback status;

[0063] S807. Based on the business playback status, call the engineering specification bytecode to execute the engineering business rules and obtain the rule execution results;

[0064] S808. Perform constraint consistency verification on all formal constraint nodes in the business constraint network based on the rule execution results, and generate online verification logs based on the constraint consistency verification results.

[0065] Furthermore, in step S106, the service constraint network is topologically evolved based on the offline verification logs and the online verification logs. The initial low-code package is then optimized based on the evolved service constraint network to obtain the engineering low-code package, including the following steps:

[0066] S901. Based on the offline verification logs and online verification logs, calculate the node verification parameters of all constraint nodes in the business constraint network. The node verification parameters include the number of node triggers, the node verification results, and the joint trigger parameters.

[0067] S902. Update the node operation attributes of all constrained nodes according to the node verification parameters, wherein the node operation attributes include node operation activity, node operation stability and node conflict contribution.

[0068] S903. Calculate the association weights between all constraint nodes based on the updated node running attributes, and perform topology evolution on the business constraint network based on the association weights;

[0069] S904. Update the engineering business blueprint based on the topology evolution results of the business constraint network, and compile and generate the target specification bytecode based on the updated engineering business blueprint;

[0070] S905. Optimize the initial low-code package according to the target specification bytecode to obtain the project low-code package.

[0071] On the other hand, the present invention also provides a low-code application automatic generation system for the engineering and construction industry, used to execute the above-described low-code application automatic generation method for the engineering and construction industry, the system comprising:

[0072] The memory is a machine-readable storage medium storing computer instructions that execute the above-described method for automatically generating low-code applications for the engineering and construction industry.

[0073] The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the aforementioned method for automatically generating low-code applications for the engineering and construction industry.

[0074] The beneficial effects of this invention are:

[0075] Upon receiving engineering industry specification information, this invention constructs a business constraint network and an engineering business blueprint. It automatically converts the natural language knowledge in the engineering industry specifications into structured knowledge that computers can understand and execute. This reduces omissions or misunderstandings caused by manual interpretation of specifications and manual modeling, enabling the generated low-code application to more accurately reflect the engineering specification requirements and improving application generation quality from the source. The engineering specification bytecode converts business rules into executable programs. To improve the efficiency of business rule execution, it utilizes the business constraint community to compile highly related business rules into the same logical module, thereby reducing cross-module data calls and rule switching during runtime. The initial low-code package is the data execution foundation for building the low-code application. It integrates the engineering specification bytecode with the business execution template to form the initial low-code package. The business execution template not only handles business data storage and recovery but also ensures data consistency under multi-terminal, multi-user offline editing conditions, providing a unified data foundation for subsequent offline verification and online playback. Therefore, it improves the data reliability and concurrent operation capability of the low-code application. Offline verification can expose defects in business rules, data consistency issues, and abnormal process handling problems in advance, improving the integrity and stability of the program before deployment and providing real operational samples for subsequent online verification. Online causal topology verification, through online replay, can verify whether the program still maintains consistent business logic in complex concurrent environments, improving the operational stability and business consistency of low-code applications after deployment. Business constraint network topology evolution and program optimization improve program execution efficiency and accuracy through actual operational data, rather than human experience, enabling low-code applications to have continuous optimization capabilities. In summary, since the final application uses a business constraint network optimized by offline verification, online verification, and knowledge evolution, it can more accurately express engineering specifications, more stably execute engineering business rules, and has stronger environmental adaptability and continuous evolution capabilities compared to traditional one-time generated low-code applications. This improves the overall generation quality, operational quality, and long-term maintenance quality of engineering low-code applications. Attached Figure Description

[0076] Figure 1 This is a flowchart illustrating an automatic low-code application generation method for the engineering and construction industry, as described in an embodiment of the present invention.

[0077] Figure 2 This is a schematic diagram of the process of constructing an engineering business blueprint according to an embodiment of the present invention.

[0078] Figure 3 This is a schematic diagram of the process for generating offline verification logs according to an embodiment of the present invention. Detailed Implementation

[0079] To make the objectives, technical solutions, and advantages of this embodiment clearer, the technical solutions in this embodiment will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation and are not intended to limit this embodiment. All other embodiments obtained by those skilled in the art based on the embodiments in this application without creative effort are within the scope of protection of this application.

[0080] It should be noted that if this embodiment involves directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a specific posture (as shown in the attached figure). If the specific posture changes, the directional indicators will also change accordingly.

[0081] Furthermore, if this embodiment involves descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0082] This embodiment provides a method for automatically generating low-code applications for the engineering and construction industry, such as... Figure 1 As shown, the specific steps include the following:

[0083] S101. Based on the pre-constructed multimodal large model, the received engineering industry standard information is parsed into standard text. Based on the parsing results, a business constraint network is constructed. Based on the business constraint network, an engineering business blueprint is constructed. The engineering business blueprint includes engineering business rules and engineering business entities.

[0084] In this embodiment, upon receiving engineering industry standard information, a pre-constructed multimodal large-scale model is used to parse the standard text of the information. During the parsing process, the multimodal large-scale model separates the document layout, identifying and extracting engineering standard table blocks, engineering standard formula blocks, engineering standard text blocks, and engineering standard vector blocks. Subsequently, the entity recognition engine, symbol computation engine, and syntactic analysis engine in the multimodal large-scale model perform semantic parsing on the above structural blocks, extracting the engineering semantic entity set, engineering calculation constraint set, engineering risk parameter range, and engineering temporal causal chain. Based on the above extraction results, a business constraint network and an engineering template instance are constructed. Then, using the engineering template instance as the skeleton, the business constraint network and the engineering temporal causal chain are encapsulated as core components to construct an engineering business blueprint containing engineering business rules and engineering business entities. After automatic verification by a formal verification sandbox, the engineering business blueprint is digitally signed and its version is locked.

[0085] Among them, the multimodal large model is a deep learning model specifically built and trained for parsing standard information in the engineering and construction industry. Its construction and training process includes five stages: training data preparation, model architecture design, pre-training, multi-task fine-tuning, and domain adaptation.

[0086] Training data preparation phase: This phase primarily involves collecting a large-scale professional corpus from the engineering and construction industry. Sources include national and industry engineering and construction standards, specifications, acceptance and testing procedures, construction process standards, and historical project business forms. After all documents undergo anonymization and copyright compliance review, a professional team conducts detailed annotation. The annotation content includes five core categories: table structure boundaries, formula areas and variable relationships, engineering named entities, process sequence relationships, and degree adverb strength levels. The annotated standardized corpus is then divided into training, validation, and test sets at a ratio of 80%, 10%, and 10%, respectively.

[0087] Model Architecture Design Phase: The model adopts a deep neural network architecture based on an attention mechanism, consisting of four core engine components. First, a visual and layout-aware encoder, relying on convolutional neural networks and deformable attention mechanisms, encodes document images and electronic document layout structures, identifying the spatial location and boundaries of various document regions. Second, a text encoder, based on a pre-trained language model backbone network, completes natural language text semantic encoding and extracts contextual word vector features. Third, a cross-modal alignment module, using a contrastive learning loss function as training basis, unifies visual and text features into the same semantic space, achieving accurate matching and alignment of tables, formulas, vector graphics, and corresponding text content. Fourth, a decoder set, including entity recognition, symbol computation, and syntactic analysis decoders, each adapted to different document parsing output tasks.

[0088] Pre-training phase: Based on large-scale unlabeled engineering documents, the model pre-trained through two self-supervised learning tasks: masking language modeling and visual region masking reconstruction. Masking language modeling optimizes text semantics by masking text words and predicting masked content based on context. Visual region masking reconstruction learns the document's visual layout features by masking document image regions and reconstructing the masked regions based on surrounding features. Through pre-training, the model can master general basic features such as the semantics of engineering terminology, document layout patterns, and chart structures.

[0089] Multi-task fine-tuning phase: Based on the labeled dataset, the pre-trained model is jointly fine-tuned across multiple tasks, simultaneously optimizing the loss functions for multiple tasks. The entity recognition task is optimized using the sequence labeling loss function to accurately extract semantic entities such as engineering parameters, process actions, and business objects; the formula parsing task is optimized using the symbol tree editing distance loss function to complete mathematical expression parsing and variable mapping; the elastic semantic recognition task is optimized using the classification loss function to achieve accurate mapping between degree adverbs and intensity levels; and the process relationship extraction task is optimized using the relation classification loss function to identify dependencies such as the order, conditions, and parallelism of processes.

[0090] Domain Adaptation Phase: A highly efficient parameter fine-tuning approach is employed, utilizing a small amount of high-quality labeled data from various sub-engineering disciplines to optimize the model and adapt it to the terminology and expression habits of different professions. After fine-tuning, performance evaluation is conducted using validation and test sets. Once the model meets the criteria of entity recognition accuracy ≥ 0.95, formula parsing accuracy ≥ 0.98, and process relationship extraction accuracy ≥ 0.90, it can be deployed to the production environment for use.

[0091] In this embodiment, a multimodal large model is used to uniformly parse the full content of the specification, covering four types of specification carriers: text, tables, formulas, and graphics. Natural language specifications are accurately converted into structured entities and constraint rules, minimizing business logic errors caused by subjective human interpretation, ensuring consistency between application logic and engineering specification requirements, and guaranteeing the reliability of low-code applications from the source.

[0092] In step S101, the received engineering industry standard information is parsed using a pre-constructed multimodal large model. A business constraint network is constructed based on the parsing results, and an engineering business blueprint is built based on this network. Figure 2 As shown, the specific steps include the following:

[0093] S201. Based on the multimodal large model, identify and extract engineering specification structure blocks of engineering industry standard information. Among them, the engineering specification structure blocks include engineering specification table blocks, engineering specification formula blocks, engineering specification text blocks and engineering specification vector blocks. The multimodal large model includes entity recognition engine, symbol calculation engine and syntactic analysis engine.

[0094] S202. Perform text semantic parsing on all engineering specification structural blocks using the entity recognition engine, and generate an engineering semantic entity set based on the text semantic parsing results;

[0095] S203. Retrieve the project form template from the pre-built project database, perform form template matching on all project semantic entities in the project semantic entity set according to the project form template, and complete the parameter filling of the project form template according to the form template matching result to obtain the project template instance;

[0096] S204. Extract the set of engineering constraints for the engineering specification structure blocks from the multimodal large model, and construct a business constraint network based on the set of engineering constraints. The set of engineering constraints includes the set of engineering calculation constraints, the range of engineering risk parameters, and the engineering temporal causal chain.

[0097] S205. Using engineering template instances as the backbone of engineering business, and encapsulating business constraint networks and engineering temporal causal chains as core components of engineering business, an engineering business blueprint is constructed. The engineering business blueprint includes engineering business rules, engineering business entities, business constraint networks, and business relationships.

[0098] In this embodiment, after receiving the input engineering industry specification information, the multimodal large model first performs full document layout parsing and content classification. Based on the content presentation form and semantic features, the complete specification document is divided into four independent engineering specification structural blocks. The engineering specification text block corresponds to textual content such as specification clauses, process requirements, and acceptance standards expressed in natural language; the engineering specification table block corresponds to structured content such as parameter comparison tables, quality evaluation tables, and inspection item tables presented in two-dimensional table format; the engineering specification formula block corresponds to mathematical content such as calculation formulas and conversion rules presented in mathematical expressions; and the engineering specification vector block corresponds to graphic content such as process flow diagrams, component construction diagrams, and process node diagrams presented in vector graphics. The multimodal large model has three built-in functional engines that collaboratively support subsequent parsing work: the entity recognition engine is responsible for domain entity semantic recognition and attribute extraction for all four structural blocks; the symbolic computation engine is responsible for the parsing and derivation of mathematical logic in the engineering specification formula block and the engineering specification text block; and the syntactic analysis engine is responsible for the syntactic-level recognition of logical relationships such as process dependencies and causal relationships in the engineering specification text block.

[0099] The entity recognition engine leverages pre-trained information extraction capabilities from the engineering domain to perform semantic parsing on each segmented engineering specification structure block. For engineering specification text blocks, it identifies core elements such as described business objects, testing parameters, and process actions, simultaneously extracting attribute information such as standard values, units of measurement, and permissible deviations for each element. For engineering specification tables, it extracts structured entity information such as field names defined in the table header, parameter limits in the table body, and grading standards. For engineering specification formula blocks, it identifies entities such as physical quantity names, calculation indicators, and constant coefficients contained in the expressions. For engineering specification vector blocks, it identifies graphic-related entities such as component names, process nodes, and testing points marked in the diagram. All identified entities undergo deduplication, attribute completion, and consistency verification before being integrated into a unified engineering semantic entity set. Each engineering semantic entity within the set carries a complete attribute description and association relationship markers.

[0100] The engineering database pre-stores engineering form templates covering various engineering business scenarios such as construction management, quality acceptance, safety inspection, and testing. Each template predefines standard field structures, data type constraints, and business logic frameworks. Based on the entity types and field attributes of the engineering semantic entity set, semantic similarity is calculated between the template and the field definitions of all engineering form templates in the engineering database. The template with the highest similarity is selected as the matching target. The similarity threshold for template matching is preset to 0.75, determined based on the minimum reliability requirement for matching engineering business form fields. A successful match is considered achieved when the highest similarity exceeds this threshold. After matching, the attribute values ​​of the corresponding entities in the engineering semantic entity set are automatically filled into the corresponding parameter slots of the target engineering form template. For fields present in the template but not covered by the engineering semantic entity set, these slots are left empty and marked as needing to be added. After all parameter filling operations are completed, an engineering template instance is generated that can be directly used for subsequent business operations and rule mapping.

[0101] The multimodal large model, through the collaborative operation of its built-in symbolic computation engine, syntactic analysis engine, and entity recognition engine, extracts three types of constraint rules from various engineering specification structural blocks: mathematical calculation, risk interval, and temporal logic, and summarizes them into an engineering constraint set. Based on this, the system maps various constraint rules to corresponding constraint nodes, constructs node association edges according to process associations and parameter dependencies, and supplements potential candidate constraint nodes by combining historical engineering data, ultimately constructing a complete business constraint network.

[0102] Engineering template instances serve as the framework for carrying business data, forming the engineering business skeleton of the engineering business blueprint, used to define the storage structure and interaction patterns of business data. Simultaneously, the business constraint network and engineering temporal causal chain serve as the core carriers of business logic, encapsulated and embedded within the blueprint framework, respectively undertaking the core functions of business rule verification and process control. The final encapsulated engineering business blueprint fully encompasses four core elements: engineering business rules, engineering business entities, business constraint network, and business relationships, forming a unified and structured business model that provides authoritative business basis for subsequent program compilation, verification, and deployment.

[0103] In step S204, the engineering constraint set of the engineering specification structural block is extracted based on the multimodal large model, and the business constraint network is constructed based on the engineering constraint set, specifically including the following steps:

[0104] S301. The mathematical expression is parsed from the engineering specification formula block and the engineering specification text block using the symbolic computation engine;

[0105] S302. Generate forward calculation logic and reverse verification logic based on mathematical expressions, and combine the forward calculation logic and reverse verification logic to generate a set of engineering calculation constraints;

[0106] S303. Perform flexible semantic recognition based on the engineering specification text block, query the corresponding historical deviation distribution parameters from the engineering database based on the flexible semantic recognition results, and generate the corresponding engineering risk parameter range based on the historical deviation distribution parameters.

[0107] S304. Use a syntactic analysis engine to identify process relationships and corresponding process relationship confidence from engineering specification text blocks, and construct a directed causal graph of the engineering based on the process relationships;

[0108] S305. Perform directed cycle detection on the directed causal graph of the project using a graph search algorithm. Based on the directed cycle detection results and the process association confidence, optimize the causal graph of the directed causal graph of the project to obtain the temporal causal chain of the project.

[0109] S306. Map the set of engineering calculation constraints, the range of engineering risk parameters, and the engineering time-series causal chain to formal constraint nodes, and construct node association edges based on the process association relationships between formal constraint nodes;

[0110] S307. Retrieve historical engineering business records from the engineering database, and search for engineering event association parameters from the historical engineering business records based on the association rule mining algorithm;

[0111] S308. Generate candidate constraint nodes based on the engineering event association parameters, and associate the candidate constraint nodes with the corresponding formal constraint nodes or node association edges to obtain the business constraint network.

[0112] In this embodiment, the symbolic computation engine processes two types of structural content in parallel: engineering specification formula blocks and engineering specification text blocks. For engineering specification formula blocks, the engine directly identifies the symbolic structure, operational relationships, and physical quantity identifiers of the formulas, converting the formatted formulas into standardized, parsable mathematical expressions. For engineering specification text blocks, the engine uses semantic matching to locate the calculation rules, conversion relationships, and quantitative requirements embedded in natural language statements, converting the textual description of the calculation logic into mathematical expressions consistent with the formula block format. Taking the calculation of the compressive strength of a concrete cube as an example, the parsed mathematical expression can be represented as: ,in, This indicates the maximum load the specimen can withstand before failure, derived from the measured load value during the testing process. The bearing area of ​​the cubic specimen is derived from the calculated area corresponding to the nominal size of the specimen. This represents the compressive strength of a concrete cube.

[0113] For each parsed mathematical expression, bidirectional execution logic is generated. The forward calculation logic calculates the target indicator value according to the mathematical expression's operational rules, given all input parameters, supporting automated calculation scenarios during business operations. The reverse verification logic, given the expected range of the target indicator, uses mathematical inverse calculation to determine the theoretically permissible value range of each input parameter, supporting boundary verification and anomaly detection scenarios. Together, the forward calculation logic and the reverse verification logic constitute a complete constraint capability for this mathematical rule. All bidirectional calculation logic corresponding to the mathematical expressions is aggregated and integrated to form an engineering calculation constraint set. This set fully covers all quantifiable and calculable rule requirements in the engineering specifications, providing a formal mathematical constraint basis for subsequent constraint networks.

[0114] Perform flexible semantic recognition on engineering specification text blocks. A pre-set flexible semantic dictionary is established, which includes common flexible adverbs and suggestive phrases in engineering construction industry standards, mapping them to corresponding flexible strength levels. For example, phrases like "must," "strictly prohibited," and "must not" are mapped to rigid constraints with a flexible strength level of 0; "suitable" and "not suitable" are mapped to weakly flexible constraints with a flexible strength level of 1; "can be appropriately relaxed" and "exceeds" are mapped to mediumly flexible constraints with a flexible strength level of 2; and "can be adjusted according to actual conditions" are mapped to strongly flexible constraints with a flexible strength level of 3. The statements associated with each engineering parameter in the engineering specification text block are traversed, identifying the flexible adverbs they contain, and labeling the allowable deviation range of each engineering parameter with a flexible strength level.

[0115] After the elastic strength grade is labeled, the system retrieves matching historical deviation distribution parameters from the engineering database. The engineering database uses engineering parameter type and elastic strength grade as dual indexes, storing the mean, standard deviation, and quantile distribution data of the deviations between measured and standard values ​​of parameters for similar projects. During retrieval, records with completely identical parameter types and elastic strength grades are prioritized. If no complete match is found, the record with the same parameter type and the smallest grade difference is selected as the calculation benchmark. Based on the historical deviation distribution parameters, three levels of engineering risk parameter intervals are defined: the first level, low-risk interval, has upper and lower bounds at the standard benchmark value ± 1 times the historical deviation standard deviation; the second level, controllable deviation interval, has a lower limit from the lower limit of the low-risk interval to the standard benchmark value minus 2 times the standard deviation, and an upper limit from the upper limit of the low-risk interval to the standard benchmark value plus 2 times the standard deviation; the third level, the over-limit risk interval, encompasses all values ​​exceeding the boundaries of the controllable deviation interval. The higher the elastic strength grade, the wider the controllable deviation interval becomes. The formula for calculating the interval expansion coefficient is: ,in, This represents the interval expansion coefficient, used to correct for the second-level controllable deviation from the interval boundary; The elastic strength level representing the current engineering parameter annotation is derived from the level value obtained by matching the elastic semantic dictionary during the elastic semantic recognition stage. Ultimately, all engineering parameters meeting quantitative judgment requirements are assigned a set of graded engineering risk parameter ranges, including low-risk, controllable deviation, and excessive risk ranges, which serve as the basis for generating formal constraint nodes of the spacing class in the subsequent constraint network.

[0116] The syntactic analysis engine performs deep dependency parsing on the process paragraphs of the engineering specification text, breaking down sentences into subject-verb-object and modifier components, extracting temporal, conditional, and causal clause structures, identifying process relationships and encapsulating them into triples. Each triple contains a preceding process node, a following process node, and a relationship type, categorized into sequential dependency, conditional dependency, and parallel relationship. The syntactic analysis engine simultaneously calculates the process relationship confidence for each relationship, with a value ranging from 0 to 1; higher values ​​indicate stronger relationship reliability. Calculation dimensions include sentence clarity, conjunction strength, and process text co-occurrence frequency. An initial directed causal graph is constructed using process actions as nodes and process relationships as directed edges. Directed edges point from preceding processes to following processes, with edge weights assigned to the corresponding process relationship confidence.

[0117] The structure is optimized by using a directed causal graph from the initial engineering process to ensure rigorous and complete causal logic. The first step employs a depth-first search directed cycle detection algorithm to traverse the entire graph and identify cyclic dependencies. If a directed cycle is detected, a cycle elimination procedure is executed, comparing the confidence scores of each edge within the cycle and cutting off the edge with the lowest confidence score. If multiple edges have the same confidence score, edges that conflict with the original text description order are prioritized for elimination. If the text order cannot be determined, edges deviating from the conventional construction process are cut off based on the prior knowledge of standard procedures in the engineering database, iterating until no directed cycles remain. The second step executes an implicit dependency completion procedure, traversing all process nodes with an in-degree of 0 in the graph and verifying the completeness of preceding processes against the standard construction process template in the engineering database. If a missing preceding dependency exists, a preceding process node and a directed edge pointing to the current node are automatically added. The default confidence score for the newly added edge is 0.60, a value set based on the reliability of the process inference. The acyclic graph after cycle elimination and implicit dependency completion is the engineering temporal causal chain.

[0118] The engineering calculation constraint set, engineering risk parameter range, and engineering temporal causal chain information are uniformly mapped to nodes and edges in a graph structure to construct a formal constraint network. First, node mapping is performed. Each engineering calculation constraint record in the engineering calculation constraint set is mapped to a formal constraint node of the calculation constraint type. The node attributes store the forward calculation logic reference, reverse verification logic reference, and variable mapping table for that record. The engineering risk parameter range corresponding to each engineering parameter is mapped to a formal constraint node of the range constraint type. The node attributes store the standard value, low-risk range, controllable deviation range, and excessive risk range for that parameter. Each process action in the engineering temporal causal chain is mapped to a formal constraint node of the causal constraint type. The node attributes store the action identifier of that process and the construction stage to which it belongs.

[0119] Secondly, the construction of node association edges is performed. The construction rules include the following three rules: Rule 1: If a variable mapping table contained in a formal constraint node of a computational constraint type references an engineering parameter corresponding to a formal constraint node of a range constraint type, then a node association edge is established between these two formal constraint nodes, and the edge type is marked as parameter reference. Rule 2: If the calculation result of an engineering indicator verified by a formal constraint node of a computational constraint type directly serves as a prerequisite or acceptance criterion for a process corresponding to a formal constraint node of a causal constraint type, then a node association edge is established between these two formal constraint nodes, and the edge type is marked as logical dependency. Rule 3: Based on the existing directed edges between process nodes in the engineering temporal causal chain, node association edges are established between the corresponding formal constraint nodes of the causal constraint type, and the edge type is marked as temporal dependency. The edge weight is initialized to the process association confidence of the corresponding process association relationship. All formal constraint nodes and their corresponding node association edges together constitute the formal constraint network.

[0120] Anonymized historical engineering business records were retrieved from the engineering database. These records included parameter values, risk zone trigger records, process timestamps, conflict logs, and environmental monitoring data. A frequent pattern growth association rule mining algorithm was used to analyze the historical records, with projects as the transaction unit and engineering events and parameter deviation markers as statistical items. Engineering events included process delays, equipment activation, and special environmental conditions; parameter deviation markers included parameters falling within controllable deviations and exceeding risk limits. The algorithm selected frequent itemsets with a support score higher than the minimum support threshold of 0.03, which was set based on the sparsity characteristics of engineering anomalies. The credibility of each rule from event set A to parameter deviation set B was then calculated. Credibility was calculated as the number of projects containing both A and B divided by the number of projects containing only A. Valid rules with a credibility score higher than the minimum credibility threshold of 0.60 were selected, which was determined based on the acceptable false alarm rate for risk warnings. The antecedent and consequent data of valid rules constitute the engineering event association parameters.

[0121] Candidate constraint nodes are generated based on engineering event association parameters and connected to the formal constraint network to form a complete business constraint network. Each valid association rule generates a candidate constraint node marked as a candidate. The node stores the trigger condition set, expected deviation set, association credibility, and source identifier. The initial value of node activity is 0, the node activity stability is the association credibility multiplied by a decay factor of 0.5, and the initial value of node conflict contribution is 0. Candidate node association is divided into two categories: if the engineering rule corresponding to the candidate constraint node only affects the engineering rule corresponding to the formal constraint node, the candidate constraint node is associated with the corresponding formal constraint node. For example, if a temperature range may affect the concrete strength range, then the candidate constraint node corresponding to the temperature range is associated with the formal constraint node corresponding to the concrete strength range. If the candidate constraint node will have a temporal impact on the engineering rules corresponding to two formal constraint nodes, then it is associated with the node association edge between these two formal constraint nodes. For example, if a delay in a certain pouring process often leads to abnormal verification results in the next curing process, then the candidate constraint node is associated with the node association edge between the two. All formal constraint nodes, candidate constraint nodes, and their corresponding edges together form the business constraint network. This business constraint network serves as a core component of the engineering business blueprint. Candidate constraint nodes will be dynamically processed into active, dormant, or eliminated based on their runtime attributes during subsequent verification and evolution phases.

[0122] S102. Divide the business constraint network into business constraint communities based on the community detection algorithm, and perform isomorphic compilation of the engineering business rules based on the division results of the business constraint communities to obtain the engineering specification bytecode:

[0123] Step S102 specifically includes the following steps:

[0124] S401. Map the global business constraint graph based on the formal constraint nodes, candidate constraint nodes, and node-associated edges;

[0125] S402. Retrieve historical engineering business records from the engineering database, calculate the historical operation attributes of all constraint nodes based on the historical engineering business records, and calculate the edge weights of the global business constraint graph based on the historical operation attributes of the nodes.

[0126] S403. Construct a modularity optimization function to complete the global business constraint graph based on the graph edge weights. Divide the global business constraint graph into communities based on the modularity optimization function and the community detection algorithm to obtain multiple business constraint communities.

[0127] S404. Traverse all node association edges between business constraint communities and extract all cross-community bridge edges between business constraint communities;

[0128] S405. Determine the cross-community data flow direction between all business constraint communities based on the cross-community bridging edge, and generate community interaction protocol interfaces based on the cross-community data flow direction;

[0129] S406. Traverse the business constraint community, extract the engineering business rules corresponding to all formal constraint nodes in the community, and perform double-ended isomorphic compilation on all engineering business rules according to the business constraint community to obtain the standard bytecode module;

[0130] S407. Establish cross-module call relationships between all standard bytecode modules according to the community interaction protocol interface, and complete the program integration of all standard bytecode modules according to the cross-module call relationships to obtain the engineering standard bytecode.

[0131] Specifically, the business constraint network is transformed into a global business constraint graph that can be processed by the graph computation engine, enabling the community discovery algorithm to perform modularity optimization calculations based on a unified numerical weight standard. All formal constraint nodes and candidate constraint nodes in the business constraint network are traversed. For each constraint node, a corresponding vertex is created in the global business constraint graph. The vertex identifier is consistent with the original constraint node identifier, and the vertex's attribute field stores the node type flag, the initial value of the node's runtime attributes, and the corresponding engineering constraint logical reference. All node-related edges in the business constraint network are traversed, and an undirected edge connecting the corresponding vertex is created for each related edge. The edge attributes store the type flag of the original node-related edge, including four categories: parameter reference type, logical dependency type, temporal dependency type, and candidate association type. All edges constitute a set.

[0132] Historical project records are retrieved from the project database. For each constraint node, three historical operational attributes are calculated and normalized to the range of 0 to 1: Historical operational activity is the total number of historical triggers of the constraint node divided by the total number of projects covered, then normalized; Historical operational stability is the ratio of successful verifications to the total number of triggers, with an initial value of 0.90 for formal constraint nodes without historical records, and the value of 0.50 (the confidence level during the association rule mining stage) multiplied by a decay factor; Historical conflict contribution is the ratio of the number of times the node participated in anomaly detection to the total number of historical anomalies, after normalization. After obtaining the historical operational attributes of all nodes, the graph edge weight is calculated for each edge. The calculation formula combines the basic weight of the edge type with the operational attributes of the nodes at both ends:

[0133] ;

[0134] In the above formula, As vertices and The edge weights of the graph; For the basic weights of edge types, preferably, in this embodiment, the parameter reference type is set to 0.80, the logical dependency type to 0.70, the temporal dependency type to 0.60, and the candidate association type to 0.40. The weight differences correspond to the coupling strength of different business relationships. , To constrain the historical operational stability of the nodes at both ends, , The historical activity level of the nodes at both ends is constrained. , The contribution of historical conflicts to the constrained nodes at both ends. The formula uses the mean stability as the base multiplier. This is a constant smoothing term, typically set to 0.01, to avoid extreme situations where the historical stability of the constrained nodes at both ends is 0, which would cause the graph edge weights to be reset to zero. The average activity level is a positive enhancement factor, and the average conflict contribution level is a penalty factor, with a penalty coefficient of 0.25 to ensure moderate intensity.

[0135] After calculating the edge weights of the global business constraint graph, the Leiden community detection algorithm is used to perform community partitioning on the global business constraint graph with the optimization objective of maximizing modularity. The formula for calculating modularity is:

[0136] ;

[0137] In the above formula, This represents the modularity, typically ranging from -0.50 to 1.00. A higher value indicates that the edge weights within the community exceed the random expectation by a greater margin, and the better the partitioning quality. This is the sum of the edge weights of all edges in the global business constraint graph. , Vertices , The weighted degree is the sum of the weights of all the edges associated with the corresponding vertex; and Vertices , The business constraint community number to which it belongs; As vertices , The graph edge weights between edges; For indicator functions, when and When they are equal, the value is 1; when they are equal, the value is 1. and The value is 0 when they are not equal, in the formula. This indicates that in a random graph where the weights of each vertex remain constant, the vertex... and The expected value of the edge weights between the two edges, and the difference between the actual edge weights and the expected value, measures the non-random significance of the connection.

[0138] The Leiden community discovery algorithm consists of three iterative phases. The first phase is the local movement phase, where each vertex is initialized as an independent community. All vertices are traversed, and the modularity gain after moving them to the community of an adjacent vertex is calculated. The algorithm executes the legal move with the largest positive gain, iterating until there is no gain. The second phase is the refinement phase, which further subdivides each community obtained in the first phase, ensuring that the subdivided sub-communities can function as independent units in the aggregation phase. The third phase is the aggregation phase, where the refined sub-communities are used as new vertices to construct the next level of the aggregate graph. The edge weights between the new vertices are equal to the sum of the original edge weights connecting the two sub-communities. These three phases are executed iteratively until the modularity no longer increases. The algorithm outputs a community affiliation label for each vertex, representing the community partitioning scheme of the global business constraint graph. This partitioning scheme is mapped back to the business constraint network, grouping constraint nodes with the same community affiliation label into the same business constraint community.

[0139] After obtaining the business constraint community partitioning results, all edges in the global business constraint graph are traversed. The community numbers of the two vertices at both ends of each edge are compared. If the numbers are different, they are marked as cross-community bridging edges, corresponding to the original node association edges in the business constraint network, representing the business logic dependency relationship between constraint nodes in different communities. All cross-community bridging edges are traversed, and the cross-community data flow direction is determined according to the original type of the edge: parameter reference type points from the community of the referenced constraint node to the referrer community, with the provider being the community of the referenced node and the consumer being the community of the referrer node; logical dependency type points from the community of the precondition constraint node to the community of the post-conclusion node; temporal dependency type points from the community of the preprocess constraint node to the community of the subsequent process node; candidate association types are tentatively set to bidirectional, and the main direction will be determined during runtime based on the actual call situation. After clarifying the flow direction, a community interaction protocol interface record is generated for each pair of business constraint communities with cross-community bridging edges. The record includes the source community identifier, the target community identifier, the interface data definition, and the constraint summary. The interface data definition includes the engineering parameter name, data type, and engineering physical unit. The constraint summary includes the data validity verification requirements on the target side. All interface records form a cross-community interface contract table, which serves as the authoritative basis for establishing subsequent cross-module call relationships.

[0140] Each business constraint community is traversed, extracting the engineering business rules corresponding to all formal constraint nodes within the community. This includes the forward calculation logic and reverse verification logic for computational constraints, the logic for determining the engineering risk parameter range for interval constraints, and the logic for verifying the preconditions of causal constraints. Mutual calls between constraint nodes within a community generate local function call instructions; references involving cross-community constraints are not inlined, only generating remote call stub functions with the same signature as the original function. The function body contains instructions to initiate cross-module calls to the microkernel host. After translation, the corresponding source code is compiled into independent canonical bytecode modules by a Web assembler. Each canonical bytecode module carries a metadata header containing a community identifier, version number, exported function entry points, and a list of dependent modules.

[0141] Dual-end isomorphic compilation is a compilation mechanism that connects the upper-layer business semantic model with the lower-layer program execution layer. The business model side includes a business constraint network, a business constraint community, and engineering business rules, while the bytecode execution side is an executable Web assembly bytecode module. Its core is to achieve dual-end isomorphism, that is, the topology, dependencies, and calling logic of the upper-layer business constraint community are transformed into the corresponding structure and logic of the lower-layer bytecode module without loss through standardized mapping rules, ensuring zero loss of business semantics. The specific compilation process is as follows: first, the business constraint network is divided into business constraint communities using a community discovery algorithm, and engineering business rules are compiled with communities as units; constraints within a community generate local bytecode functions, and cross-community dependencies generate standardized remote call stubs. The upper-layer community topology and the lower-layer bytecode module structure are completely aligned, ultimately producing modular engineering specification bytecode. The core function of this mechanism is to achieve a high degree of uniformity between business logic and executable code structure, reduce cross-module call overhead, improve execution efficiency, and facilitate the synchronous updating of the lower-layer code logic during subsequent business rule verification and topology evolution, reducing maintenance costs and ensuring consistency between business and code iteration.

[0142] After all the bytecode modules are compiled, the system establishes cross-module call relationships based on the cross-community interface contract table: functions matching the interface definition are registered as cross-module callable entry points in the corresponding module of the source community; the binding relationship between the remote call stub and the source module and interface entry point is confirmed to be correct in the corresponding module of the target community. All bytecode modules, the cross-community interface contract table, and the module dependency mapping table are packaged, and a microkernel host component is assembled, which contains three core units: a module registry maintaining the mapping between module identifiers, version numbers, and runtime load addresses; an interface routing bus forwarding cross-module call requests and return results according to the contract table; and a version coordinator responsible for module version compatibility verification during loading. The microkernel host is synchronously compiled into a lightweight runtime module. Finally, the microkernel host, all bytecode modules, and configuration files are merged and packaged to obtain the project-standard bytecode. This product transforms from the original monolithic massive bytecode into a modular collection organized by business-constrained communities, which can be loaded and updated independently at runtime through the microkernel host.

[0143] S103. Construct a business execution template based on the engineering business entity mapping, and integrate the program according to the business execution template and the engineering specification bytecode to generate an initial low-code program package:

[0144] In this embodiment, the set of business attributes of engineering business entities is extracted from the engineering business blueprint, including entity attribute parameters, entity association relationships and business constraint relationships. Based on this, a business execution template is constructed, and then the engineering specification bytecode and the business execution template are integrated into an initial low-code package.

[0145] Through the above steps, the final generated initial low-code package is a self-contained structure that integrates all data templates, calculation logic, process engine and security components. It can execute business operations completely without relying on the network and is suitable for network outage scenarios in engineering sites. At the same time, the package has a unified integrity verification mechanism to avoid application malfunctions caused by missing or tampered files during the deployment process.

[0146] In step S103, a business execution template is constructed based on the engineering business entity mapping. The program is then integrated based on the business execution template and the engineering specification bytecode to generate an initial low-code package. This process includes the following steps:

[0147] S501. Extract the set of business attributes of the engineering business entities based on the engineering business blueprint, wherein the set of business attributes includes entity attribute parameters, entity association relationships and business constraint relationships;

[0148] S502. Map all engineering business entities to the corresponding business execution template body according to the entity attribute parameters;

[0149] S503. Based on the business constraint network, map the engineering business rules corresponding to the formal constraint nodes to the business execution template body to obtain the business execution template. Based on the mapping result of the engineering business rules, construct the rule calling relationship between the business execution template and the engineering specification bytecode.

[0150] S504. Determine the template reference relationships between business execution templates corresponding to engineering business entities based on entity association relationships;

[0151] S505. Establish program integration relationships based on rule call relationships, template reference relationships, and process association relationships. Based on the program integration relationships, complete the program integration of engineering specification bytecode and business execution templates to generate an initial low-code program package.

[0152] In this embodiment, after the engineering business blueprint is constructed and locked, the compilation-time business execution template generation stage begins. The first step is to extract the set of business attributes corresponding to all engineering business entities within the engineering business blueprint. An engineering business entity is the data carrier unit corresponding to the actual engineering business object in the blueprint, including types such as concrete compressive strength test records, steel bar tensile test reports, and concealed works acceptance records. Each engineering business entity is associated with a set of business attributes, divided into three categories. The first category is entity attribute parameters, which are the field definitions of the entity's own data structure, covering field names, data types, engineering physical units, default values, and mandatory constraint markers. Taking the concrete compressive strength test record as an example, the parameters include specimen number, design strength grade, specimen bearing area, failure load, measured compressive strength value, and corresponding units and data types. The second category is entity relationships, representing the data references and dependencies between the current entity and other entities, clarifying the primary and foreign keys and data flow paths between entities. For example, the concrete compressive strength test record is associated with concrete pouring records and concrete mix design reports, characterizing the source of the test data. The third category is business constraint relationships, which record the formal constraint nodes of the business constraint network bound to each field of the current entity, providing an index basis for subsequent validation logic injection templates.

[0153] After extracting the complete set of business attributes, each engineering business entity is mapped individually to a business execution template body. The business execution template body is the core carrier for data storage and interaction during the low-code program's runtime, supporting offline independent self-describing data management. The mapping process sequentially traverses all entity attribute parameters, generating corresponding data fields within the template body, fully inheriting field data types, engineering physical units, and default values. Simultaneously, four types of common metadata fields—template identifier, template version number, creation timestamp, and last modification timestamp—are uniformly injected into the template body. Based on the mandatory markers of entity attribute parameters, non-empty validation rules are built into the template field validation layer to ensure offline data integrity. After mapping, the business execution template body serves only as a pure data container, without any engineering business rules attached.

[0154] After the data container for the main body of the business execution template is built, engineering business rules are injected to generate a complete business execution template. The system traverses all formal constraint nodes in the business constraint network and performs differentiated mapping according to node type: Calculation constraint type nodes extract variable mapping tables, locate the engineering business entities covered by the constraints and their corresponding fields, add calculation triggers and validation hooks to the corresponding template main body fields, and store forward calculation logic references and reverse validation logic references in the field metadata; interval constraint type nodes write the corresponding engineering risk parameter intervals into the field reactive validation rules, automatically completing the parameter interval classification judgment at runtime; causal constraint type nodes write the preconditions of the work process into the template submission pre-validation logic, forcing the process to follow the engineering temporal causal chain requirements. After the rule mapping is completed, the data container is upgraded to a business execution template with complete validation, calculation, and process control capabilities.

[0155] During the mapping process, the rule calling relationship between the business execution template and the engineering specification bytecode is established synchronously. The engineering business rules have been compiled into independent engineering specification bytecode modules according to the business constraint community partition. Each calculation and range constraint reference in the template is converted into a call pointer to the function inside the corresponding bytecode module. The pointer is bound to the field validation hook to generate a rule calling relationship mapping table. The runtime engine uses this mapping table to accurately call the corresponding bytecode validation function when the field value changes.

[0156] The system iterates through all entity relationships within the blueprint, converting hierarchical relationships into template reference relationships between business execution templates. For each entity relationship, it distinguishes between the source entity, target entity, and relationship type, including one-to-one, one-to-many, and many-to-many relationships. A reference field is added to the template corresponding to the source entity, storing the target template identifier and a unique identifier for each record. Based on the constraint strength of the engineering business specifications, cascading behavior rules are configured for the reference field, including three processing strategies: setting to null, preventing deletion, and cascading deletion. All template reference relationships are uniformly stored in the program integration relationship description file.

[0157] The system integrates three types of data: rule call relationship mapping table, template reference relationship set, and blueprint process association relationship. It constructs a unified program integration relationship and completes the integration and assembly of engineering specification bytecode and business execution templates. The system generates a program integration relationship description object, recording three layers of integration information at the engineering business entity level: internal rule binding records the bytecode module identifier and function entry point associated with template fields; external template dependencies record other business execution templates that need to be called during execution; and process flow constraints record the template's position, preceding state, and subsequent triggering conditions within the process engine.

[0158] The integration operation is performed in three layers based on the program integration relationship description object: The data layer serializes all business execution templates, generates a document set using a conflict-free data replication format, and forcibly writes a hybrid logical clock field and a causal hash pointer field into each document; the logic layer packages all engineering specification bytecode modules according to the business constraint community index, generates a module loading mapping table, and binds and configures cross-community call stub functions according to internal rules; the process layer converts template references and process associations into process definition files that the process engine can recognize, clarifying the submission order of each template, state switching rules, and the automatic adjudication service mounting point for controllable deviation intervals. After integration, the data layer document set, logic layer bytecode module set and loading mapping table, and process layer process definition files are compressed and packaged together with a front-end low-code rendering component, a terminal trusted proxy security module, and an offline resource package. The resulting compressed file is the initial low-code program. This program has a built-in complete data model, calculation and verification logic, process control rules, and security protection components, supporting completely offline independent operation. However, the program's logical completeness and anti-conflict capabilities still need to be optimized and improved through subsequent verification and evolution processes.

[0159] S104. Perform offline verification on the initial low-code package based on the pre-built local virtual sandbox, and generate offline verification logs based on the offline verification results:

[0160] In this embodiment, the initial low-code package is deployed to a local virtual sandbox completely isolated from the external network. The attack priority and historical operating attributes of all constraint nodes within the business constraint network are calculated. A chaotic verification operation sequence is then calculated by combining the attack priority, historical operating attributes, and the engineering constraint set. The initial low-code package is run according to the chaotic verification operation sequence, and program running parameters are collected synchronously to generate offline verification logs.

[0161] This step involves generating three types of attack sequences: time-series inversion, constraint conflicts, and interval boundaries. It simulates various violations, critical inputs, and abnormal processes that may occur in a real-world engineering environment. This allows for the discovery of deep-seated issues such as logical vulnerabilities, rule escapes, and computational deadlocks that are often overlooked in conventional testing. Defects can be fixed proactively in the offline phase, significantly reducing the probability of failure after deployment. The local virtual sandbox completely disconnects from the network, simulating a real-world operating environment with no or weak network connectivity. This fully verifies the application's rule validation, data storage, and workflow capabilities in a purely offline state, avoiding the problems of traditional online testing failing to cover offline scenarios and offline functionality malfunctioning after deployment. This ensures the application's operational quality in offline scenarios. The offline verification logs are not only used for this offline self-consistency assessment but also serve as core inputs for subsequent online causal topology verification and constraint network evolution, providing real and rich test data support for quality optimization in later stages.

[0162] In step S104, the initial low-code package is offline verified based on a pre-built local virtual sandbox, and an offline verification log is generated based on the offline verification results, such as... Figure 3 As shown, the specific steps include the following:

[0163] S601. Deploy the initial low-code package to a pre-built local virtual sandbox;

[0164] S602. Calculate the node topology attributes of all constraint nodes in the business constraint network, and determine the attack priority of all constraint nodes based on the node topology attributes and the division results of the business constraint community. Among them, constraint nodes include formal constraint nodes and candidate constraint nodes.

[0165] S603. Retrieve historical engineering business records from the engineering database, and calculate the historical operation attributes of all constraint nodes based on the historical engineering business records. The historical operation attributes of nodes include historical operation activity, historical operation stability, and historical conflict contribution.

[0166] S604. Calculate the chaotic verification operation sequence based on the attack priority, node historical running attributes, and engineering constraint set;

[0167] S605. Run the initial low-code program package according to the chaotic verification operation sequence, synchronously collect the program running parameters of the initial low-code program, and generate offline verification logs based on the program running parameters.

[0168] In this embodiment, the container orchestration engine is first invoked to automatically create one or more lightweight containerized instances as local virtual sandboxes. During creation, the system applies strict network isolation policies to these container instances, removing their virtual network interface cards and disconnecting all physical layer connections with external host networks, inter-container networks, and the external Internet, retaining only the local loopback interface within the container to simulate extreme network outage engineering environments such as tunnel construction and deep foundation pit operations. After the container instances are created, the unpacked files of the initial low-code package are transferred to the container's internal file system and deployed according to a preset directory structure. The deployment specifically includes: deploying the engineering specification bytecode module set compiled according to business constraints and community partitions to the Web assembly virtual machine runtime directory of the local virtual sandbox; initializing the business execution template set injected with mixed logical clock fields and causal hash pointer fields into the conflict-free document database; loading the business process engine with an embedded controllable deviation interval automatic adjudication service into the runtime memory; and registering the terminal trusted proxy security module as a signature interceptor for local operation logs. After deployment, each container instance is assigned an independent virtual terminal identifier and device fingerprint, and an independent system clock source is set up inside the container. This clock source is completely isolated from the external physical clock, providing operational space for subsequent clock tampering tests.

[0169] The node topology attributes of all constraint nodes within the business constraint network are calculated. These attributes include three core graph theory metrics: degree centrality, betweenness centrality, and eigenvector centrality. Degree centrality represents the number of directly connected neighboring nodes of a single constraint node, reflecting the node's extensive connectivity within the network. Betweenness centrality represents the frequency with which the node appears on the shortest path between any two nodes, reflecting the node's bridging role as a network hub. Eigenvector centrality comprehensively considers the importance of neighboring nodes, reflecting the node's core influence in the overall network. After calculating the node topology attributes, and combining this with the existing business constraint community partitioning results, the weights of constraint nodes located at the core of a community and undertaking cross-community bridging functions are increased. The attack priority score for each constraint node is then calculated using a weighted summation method. The weighted calculation of the attack priority score can be performed using the following formula:

[0170] ;

[0171] in, Represents constraint nodes A comprehensive score for attack priority; , , Constraint nodes Degree centrality, betweenness centrality, and eigenvector centrality; As a cross-community bridging factor, if the constrained nodes If any node has an edge that connects different business constraint communities, then The value is 1 if it is set to 1, otherwise the value is 0. , , , The weighting coefficients have default values ​​of 0.30, 0.35, 0.25, and 0.10. This weighting allocation emphasizes betweenness centrality and degree centrality, while also considering the special value of cross-community bridging. The attack priority scores of all constraint nodes are normalized and mapped to the range of 0 to 1 to obtain the final attack priority ranking. A higher attack priority indicates a more critical constraint node in the network topology, and attack testing on it is more effective in verifying the constraint enforcement capabilities of the initial low-code package.

[0172] After determining the attack priority, historical data is retrieved from the project database to supplement the statistical historical operation attributes of each constraint node. The node's historical operation attributes include three dimensions. The first dimension is historical operational activity. This involves calculating the total number of times the constraint node was triggered for verification in historical project business records. The statistical scope of the trigger count includes: the number of times the constraint node was executed by forward calculation logic as a calculation constraint type, the number of times it was triggered by project risk parameter range determination as an interval constraint type, and the number of times it was triggered by process precondition verification as a causal constraint type. The statistical results are normalized according to the number of projects; that is, historical operational activity equals the total number of triggers divided by the total number of projects covered, yielding the average number of triggers per project. This value is then divided by the maximum average number of triggers per project among all constraint nodes, mapping it to the interval between 0 and 1.

[0173] The second dimension is historical operational stability. This measures the consistency rate between the verification results and the final business judgment conclusion after the constraint node is triggered in historical engineering business records. For formal constraint nodes, if they have never caused verification anomalies or conflict events in historical records, a higher initial value for historical operational stability is used, such as 0.90. For candidate constraint nodes, their historical operational stability is equal to their credibility during the association rule mining phase multiplied by a decay factor, such as 0.5. If there are records in the historical record of the constraint node participating in conflict events, a deduction is made based on the proportion of conflict events to the total number of triggers.

[0174] The third dimension is historical conflict contribution. This involves calculating the frequency with which the constraint node appears as a basis for conflict determination in historical engineering business records. Specifically, the system retrieves all events marked as constraint violation, range exceeding limits, or process timing anomalies from historical engineering business records. It then counts the number of times each constraint node is marked as participating in the determination in these abnormal events, divides this number by the total number of historical abnormal events, and maps it to a range of 0 to 1; this is the historical conflict contribution. The calculation results of the above three dimensions are integrated into the historical operation attribute record of each constraint node and stored in association with the corresponding constraint node identifier.

[0175] Based on the attack priority and historical node attributes, a chaotic verification operation sequence is calculated using the engineering constraint set. This chaotic verification operation sequence serves as the standardized input to drive the initial low-code package. After the chaotic verification operation sequence is generated, the initial low-code package is driven to run line by line according to the sequence within a local virtual sandbox, while simultaneously collecting program execution parameters and generating offline verification logs. Specifically, a test orchestration process is first started within the local virtual sandbox. This process reads the chaotic verification operation sequence and, according to the chronological and logical order of the operation instructions in the sequence, sends operation requests line by line to the front-end interaction interface or data submission interface of the initial low-code package. Each operation request includes the operation type, target engineering business entity identifier, target field identifier, operation value, and optional operation execution timestamp tampering parameters.

[0176] Upon receiving the operation request, the initial low-code package's internal components respond sequentially. The Web Assembly Virtual Machine loads the corresponding engineering specification bytecode module, executes forward calculation logic and reverse verification logic, and returns the calculation and verification results. The reactive verification rules in the business execution template are triggered, completing the determination of the engineering risk parameter range. Based on the determination result, the data is marked as either the first-level low-risk range, the second-level controllable deviation range, or the third-level excessive risk range. If the data falls into the second-level controllable deviation range, the business process engine automatically calls the controllable deviation range automatic adjudication service for adjudication. The conflict-free document database records the data changes generated by this operation and generates an atomic operation log with a mixed logical clock field and a causal hash pointer field. The terminal trusted proxy module applies a digital signature to the atomic operation log.

[0177] During the initial low-code package execution, the test orchestration process synchronously mounts a program execution parameter collector to intercept and record the following program execution parameters in real time: the response latency of each operation request, the calculation output results of the Web Assembly Virtual Machine, the interval determination results triggered by the reactive validation rules, the adjudication conclusion of the controllable deviation interval automatic adjudication service, the state change records of the conflict-free document database, and the signature log generated by the terminal trusted proxy module. The program execution parameter collector also captures any abnormal information thrown during program execution, including calculation anomalies, data constraint violation alarms, and process blocking events.

[0178] The collected operational parameters are aligned according to the operation sequence and structurally assembled to generate offline verification logs. Each log entry includes the operation sequence number, operation type, entity and field identifiers, input values, response timestamps, interval judgment results, pass status of each constraint verification, automatic adjudication conclusion, hybrid logic clock value, causal hash pointer value, digital signature, and anomaly flag fields. All logs are uniformly stored in a designated output directory in the sandbox, serving as the core output of offline verification without network access.

[0179] In step S604, the chaotic verification operation sequence is calculated based on the attack priority, the node's historical running attributes, and the set of engineering constraints. Specifically, this includes the following steps:

[0180] S701. Based on the attack priority and the historical operation attributes of the nodes, the target constraint nodes and the corresponding target associated edges are selected from the business constraint network.

[0181] S702. Locate the preceding and subsequent processes in the engineering time-series causal chain based on the target associated edge, and search for the target process path along the engineering time-series causal chain based on the preceding and subsequent processes;

[0182] S703. Perturb the path sequence of the target process path to obtain the process attack sequence;

[0183] S704. Based on the set of engineering calculation constraints corresponding to the target constraint node, select all engineering variables and variable constraints, and dynamically perturb all engineering variables and variable constraints to generate a constraint conflict attack sequence.

[0184] S705. Based on the preset perturbation step size and perturbation direction, continuously perturb all engineering risk parameter intervals corresponding to the target constraint node to obtain the interval attack sequence;

[0185] S706. Based on the cross-combination of process attack sequence, constraint conflict attack sequence and interval attack sequence, a chaotic verification operation sequence is obtained.

[0186] In this embodiment, the first step in generating the chaotic verification operation sequence is to accurately select the target constraint nodes and their associated edges with the highest testing value from the business constraint network. This ensures that the subsequently generated attack sequence can effectively verify the logical robustness of the initial low-code package. First, two preliminary analysis results are extracted from all constraint nodes in the business constraint network. The first is the attack priority, calculated using graph theory during the chaotic injection strategy generation stage. This indicator integrates the degree centrality, betweenness centrality, and eigenvector centrality of the constraint node to quantify its importance in the business constraint network topology. A higher attack priority value indicates that the node is depended on by more other constraints or occupies a more critical cross-community bridging position. The second is the node's historical operational attributes, derived from statistical information about the constraint node based on historical engineering business records stored in the engineering database. Specifically, this includes three dimensions: historical operational activity, historical operational stability, and historical conflict contribution. Historical operational activity reflects how frequently the constraint node has been triggered in previous projects; historical operational stability reflects the reliability of the constraint node after verification in multiple projects; historical conflict contribution reflects the probability that the constraint node has been used as a basis for judgment in previous conflict events.

[0187] The results of the two analyses above are weighted and combined to calculate the target selection score for each constraint node. One formula for calculating the target selection score is as follows:

[0188] ;

[0189] in, Indicates the target selection score; This indicates the attack priority, with a value ranging from 0 to 1, derived from the normalized value of the graph theory analysis results; This represents the historical stability of the operation, with a value ranging from 0 to 1, and is derived from the historical operation attributes of the node. This represents the contribution to historical conflicts, with a value ranging from 0 to 1, and is also derived from the node's historical operational attributes. , , These are the corresponding weighting coefficients. The weighting coefficients are set according to the emphasis of the testing strategy on the importance, stability, and conflict tendency of the topology. The default values ​​are 0.40, 0.35, and 0.25, respectively, giving priority to key positions in the network topology.

[0190] Sort all constraint nodes according to their target screening scores from highest to lowest, and select constraint nodes whose scores exceed a preset screening threshold as target constraint nodes. The preset screening threshold is determined to ensure that the selected nodes are approximately the top 20% of nodes with the highest attack value in the network, with a reference value of 0.60. Simultaneously, mark all nodes in the business constraint network directly connected to the target constraint nodes as target-related edges, and output them along with the target constraint nodes to subsequent steps.

[0191] After identifying the target constraint nodes and their associated edges, the process nodes associated with them are located in the engineering time-series causal chain using these edges, and the complete process attack path is searched along the causal chain. All target associated edges are traversed, and only time-dependent and logically dependent edges are filtered out. The preceding and subsequent process identifiers corresponding to the causal constraint nodes at both ends are extracted. Using the two sets of processes as anchor points, the engineering time-series causal chain is traversed bidirectionally: tracing back to all upstream starting nodes of the preceding process and forward to all downstream ending nodes of the subsequent process, the upstream and downstream paths and causal dependencies are connected to obtain a single process path. All paths are deduplicated and merged to form a set of target process paths. Perturbing this set can verify the program's time-series constraint execution capability.

[0192] After obtaining the set of target process paths, a path order perturbation is performed on each target process path to generate an aggressive operation sequence that violates process timing constraints. For a path containing... The target process path for each process node is denoted as follows: ,in Indicates the first position on the path Each process node. Apply one or more of the following three perturbation strategies in combination to this path.

[0193] The first type is reverse perturbation. This completely reverses the node order of the target process path, generating... The first method involves reversing the order of operations to simulate an extreme scenario of reversed process steps. The second method involves local exchange perturbations. A pair of adjacent process nodes on the target process path are randomly selected. and The positions of the two nodes are swapped to generate a new operation sequence. This perturbation strategy is used to simulate a scenario where adjacent processes are out of order. Local swapping perturbations can be repeated multiple times, each time randomly selecting a different pair of adjacent process nodes. The third type is jump perturbation. A process node is randomly selected from the target process path. The process is extracted from the original path and inserted into another random position on the path. This perturbation strategy is used to simulate scenarios where a process is missed and then added back. The perturbation operation is performed on each target process path in the target process path set, and the set of all perturbed path sequences is the process attack sequence. Each record in the process attack sequence contains a set of process operation instructions arranged in a specific order, which intentionally violates the sequential dependencies stipulated by the engineering temporal causal chain.

[0194] While generating the process attack sequence, variable perturbation is performed in parallel on the nodes of the computational constraint type within the target constraint node to generate a constraint conflict attack sequence. The variable mapping table of the computational constraint node and the reverse verification logic are extracted to obtain all engineering variables, their corresponding valid domains, and variable constraint conditions. The perturbation strategies include the following three categories.

[0195] The first type is boundary value attacks. For each engineering variable, a value is generated that represents the upper and lower boundary values ​​of the variable's effective domain, as well as a value that exceeds the upper and lower boundaries by a preset small increment. These values ​​are then substituted into the forward calculation logic, and the results are observed to see if they trigger conflicts between related invariants. The preset increment reference value is 1% of the width of the effective domain, determined based on the general tolerance range of engineering measurement accuracy.

[0196] The second type is constraint violation attacks. These attacks extract the mathematical relationships between engineering variables from variable constraints, for example, those of the form... The value of remains unchanged, while the dependent variable... The value is replaced with a value that intentionally violates the constraint, for example, replaced with... The calculation result is multiplied by a deviation coefficient, with a reference value of 1.50 or 0.50, corresponding to the two deviation directions of exceeding and falling short, respectively, to generate a combination of constraint violation data.

[0197] The third type is combined cross-attack. This involves selecting two or more engineering variables from formal constraint nodes of the same computational constraint type, and simultaneously modifying their values ​​so that the individual variables are all valid values ​​within their respective domains, but the combination of variables violates the mathematical relationships specified by the variable constraints. For example, for the constraint on concrete compressive strength calculation... ,in, This indicates the maximum load the specimen can withstand before failure, derived from the measured load value during the testing process. The bearing area of ​​the cubic specimen is derived from the calculated area corresponding to the nominal size of the specimen. Given the compressive strength of the concrete cube, generate a set of failure loads. The value is too large and the bearing area of ​​the specimen is too large. The combination of data with smaller values ​​results in a lower calculated compressive strength. This far exceeds the theoretically possible range for concrete of this strength grade. All the data generated by the perturbations constitute a constraint conflict attack sequence. Each record in the constraint conflict attack sequence contains a set of field assignments for a specific engineering business entity. These assignments may meet the requirements of the engineering risk parameter range at the individual field level, but violate engineering calculation constraints at the level of correlation invariants.

[0198] For the boundary of the engineering risk parameter interval for the target constraint node of the interval constraint type, an interval attack sequence is generated. The three-level engineering risk interval boundary stored in the node is read, and the disturbance step size is set to 0.5% of the parameter standard baseline value. Two types of disturbance directions are distinguished: positive and negative. Positive disturbances shift towards the direction of increasing risk, and negative disturbances shift towards the direction of decreasing risk. Test points are continuously generated along these two directions at the upper and lower boundaries of the low-risk interval and the upper and lower boundaries of the controllable deviation interval. These test points are encapsulated as assignment instructions carrying entities, fields, and test values. All instructions constitute the interval attack sequence, used to verify the accuracy of the program's hierarchical judgment of interval critical values. After the three types of attack sequences are generated independently, they are cross-combined to output a comprehensive chaos verification operation sequence. The combination uses the process steps of the process attack sequence as the timeline, retrieves the engineering business entity corresponding to each process, and embeds the assignment instructions that match the entity in the constraint conflict and interval attack sequence as data payloads into the process entry stage. Attack instructions without a corresponding process are randomly interspersed between the time nodes of each process, simulating the real scenario of entering abnormal data at any time on site. After combination, an ordered instruction set with operation type, business entity, field, test value, and timestamp is generated, which is the chaotic verification operation sequence. This sequence is then sent to the isolated sandbox driver program to run, comprehensively verifying the program's logical consistency and operational robustness under scenarios of time sequence disorder, mathematical conflict, and overlapping critical inputs at interval boundaries.

[0199] S105. Perform causal topology verification of the initial low-code package online based on the offline verification log, and generate online verification log based on the causal topology verification results:

[0200] In this embodiment, the initial low-code package is deployed to a pre-built shadow server. Operation log sequences are extracted from offline verification logs and injected. Metadata fields for each operation log are parsed using a multimodal large model, including mixed logical clock values, causal hash pointers, business documents, and business entities. Using the operation logs as operation nodes, causal edges are established by combining the mixed logical clock values ​​and causal hash pointers to obtain an operation causal topology graph, which is then sorted to obtain the target replay sequence. Business replay is executed according to the target replay sequence, calling the engineering specification bytecode to execute engineering business rules, performing constraint consistency verification on all formal constraint nodes in the business constraint network, and generating online verification logs.

[0201] In this step, the construction and sorting of the causal topology graph transforms the timing ambiguities caused by clock skew and network latency in distributed offline operations into a deterministic global operation sequence. This provides a precise causal dependency basis for conflict resolution, avoiding the risk of misjudgment in engineering scenarios using traditional timestamp sorting methods. The isolated replay environment of the shadow server ensures that the verification process of high-concurrency conflict merging does not affect the production system at all, and can fully expose potential concurrency defects and logical inconsistencies under secure and controlled conditions. Constraint consistency verification verifies the replay results node by node at the granularity of formal constraint nodes to ensure that the application's data state is strictly self-consistent mathematically and business-wise after undergoing both offline conflict and online merging tests. Therefore, these steps effectively improve the quality and reliability of low-code application generation.

[0202] In step S105, the causal topology verification of the initial low-code package is completed online based on the offline verification log, and an online verification log is generated based on the causal topology verification results. Specifically, this includes the following steps:

[0203] S801. Deploy the initial low-code package to a pre-built shadow server;

[0204] S802. Extract the operation log sequence from the offline verification log and inject the operation log sequence concurrently into the shadow server;

[0205] S803. When the shadow server receives the operation log sequence, it uses the multimodal large model to parse out the metadata fields of all operation logs in the operation log sequence. The metadata fields include the hybrid logical clock value, causal hash pointer, business document, and business entity.

[0206] S804. Using the operation log as the operation node, and combining the hybrid logic clock value and the causal hash pointer, establish the operation causal edge between the operation nodes to obtain the operation causal topology graph;

[0207] S805. Based on the operation cause-effect topology graph, perform topological sorting of all operation logs to obtain the target replay sequence;

[0208] S806. Input all operation logs into the initial low-code package according to the target playback sequence, execute business playback through the initial low-code package, and obtain the business playback status;

[0209] S807. Based on the business playback status, call the engineering specification bytecode to execute the engineering business rules and obtain the rule execution results;

[0210] S808. Perform constraint consistency verification on all formal constraint nodes in the business constraint network based on the rule execution results, and generate online verification logs based on the constraint consistency verification results.

[0211] In this embodiment, the container orchestration engine is first automatically invoked to create an independent shadow server instance. This shadow server instance maintains the same hardware resource allocation and network configuration as the production server, but at the network level, it is configured to allow only unidirectional connections from the system's internal test bus, prohibiting direct access from any external clients and preventing the shadow server from actively connecting to the production environment. This ensures that any abnormal states generated during the verification process will not affect the running production services. After the shadow server instance is created, the engineering business blueprint version corresponding to the initial low-code package to be verified is loaded. A complete topology snapshot of the business constraint network and the initial dataset of the engineering template instance are extracted from this blueprint and restored to the conflict-free document database and business constraint network cache within the shadow server, ensuring that the initial data state of the shadow server is strictly consistent with the blueprint state used by the compiler. Subsequently, all engineering specification bytecode module sets, business execution template sets, the business process engine with embedded controllable deviation range automatic adjudication service, and the terminal trusted proxy module from the initial low-code package are completely installed into the shadow server according to production deployment standards, completing the runtime environment readiness initialization.

[0212] Once the shadow server is deployed, a high-concurrency log injector is started. This injector reads all operation logs from the operation log sequence and simulates an extreme network recovery transient scenario for concurrent injection. The injector concurrently and streams multiple operation logs from different virtual clients, containing out-of-sequence and logically conflicting data, into the shadow server within the same time window. The injection process strictly maintains the original data integrity and temporal characteristics of each operation log, without any pre-sorting, filtering, or correction, to ensure that the data injected into the shadow server is a complete copy of the real conflicting data generated during the offline verification phase.

[0213] After receiving the concurrently injected operation log sequence, the shadow server calls the multimodal large model to perform structured parsing on each operation log, extracting the metadata fields required for subsequent causal topology construction. The multimodal large model first identifies the log format version of each operation log, locating the offset position and encoding method of each data field according to the corresponding format definition file. Subsequently, the multimodal large model parses the following four metadata fields from the operation log. The first field is the hybrid logical clock value. The hybrid logical clock value is a composite timestamp, composed of a 64-bit physical timestamp component and a 32-bit logical counter component. The physical timestamp component records the system clock reading in milliseconds when the operation occurred in the local virtual sandbox; the logical counter component records the monotonically increasing sequence number of multiple operations occurring within the same physical timestamp. The multimodal large model parses and stores these two components separately.

[0214] The second item is the causal hash pointer. The causal hash pointer is a cryptographic hash value, the result of hashing the entire contents of the preceding operation logs. The multimodal large model parses and stores this hash value as a hexadecimal string, serving as the basis for constructing causal edges. The third item is the business document. The business document identifier specifies the specific business execution template instance in the conflict-free document database modified or created by this operation. The fourth item is the business entity. The business entity identifier specifies the type of engineering business entity targeted by this operation and its specific fields.

[0215] After parsing the metadata fields of all operation logs, an operation causal topology graph is constructed, with each operation log as an operation node. First, a unique operation node identifier is assigned to each operation log, and the metadata fields and all original content of that operation log are associated and stored as attributes of that operation node. All operation nodes constitute the vertex set of the operation causal topology graph. Then, causal edges between operation nodes are established. The construction of causal edges follows two rules. The first rule is causal hash chain edges. For any operation log, the system extracts the value of its causal hash pointer field and searches all operation logs for a preceding operation log whose content hash matches the causal hash pointer value. If a matching preceding operation log is found, the system establishes a directed causal edge between the operation nodes corresponding to these two operation logs, with the edge pointing from the preceding operation node to the current operation node. This causal edge indicates that the current operation is logically a continuation or modification of the preceding operation.

[0216] Rule 2 is the business entity dependency edge. For multiple operation logs operating on the same business entity identifier within the same business document identifier, the system sorts them according to their mixed logical clock values ​​and establishes directed causal edges between operation nodes with adjacent times. The direction of the edge is from the operation node with the smaller mixed logical clock value to the operation node with the larger mixed logical clock value. This causal edge represents the sequential relationship of operations on the same business entity. The set of all operation nodes and causal edges together constitutes the causal topology graph of operations.

[0217] After constructing the operational causal topology graph, a directed cycle detection process is performed. If a directed cycle is detected, it indicates a circular dependency in the causal relationships between operation logs. This typically means that clock tampering operations during chaotic injection in the offline verification phase have caused logical clock inversion. For such cases, the system initiates a cycle-breaking procedure: it traverses all operational causal edges on the directed cycle, identifies edges where there is a clear contradiction between the mixed logical clock value and the causal hash pointer value (i.e., edges where the partial order relationship between the physical timestamp component and the logical counter component is inconsistent with the direction of the causal hash chain), marks them as timing-abnormal edges, and temporarily removes them from the operational causal topology graph. The cycle-breaking procedure iterates until the operational causal topology graph becomes a directed acyclic graph.

[0218] After ensuring that there are no directed cycles in the causal topology graph, the system runs a topology sorting algorithm. The output of the topology sorting algorithm is a linear sequence of operation nodes that satisfies the following condition: for any causal edge in the causal topology graph pointing from operation node A to operation node B, operation node A always precedes operation node B in the sequence. When the topology sorting algorithm faces multiple operation nodes with an in-degree of 0 to choose from at a certain moment, it uses the following priority rules for arbitration: the first priority is to compare the physical timestamp component in the mixed logical clock value, and output the smaller value first; the second priority is to compare the logical counter component in the mixed logical clock value, and output the smaller value first; the third priority is to compare the lexicographical order of the operation node identifiers. The output sequence of the topology sorting algorithm is the target replay sequence. The target replay sequence determines the strict order in which all offline operation logs are replayed in the shadow server. This order integrates causal dependencies, physical time order, and logical counter order, ensuring the determinism and reproducibility of the replay process.

[0219] After obtaining the target replay sequence, a replay-driven process is started. This process reads the original operation instructions of each operation log in the order of the operation nodes in the target replay sequence, including the operation type, target project business entity identifier, target field identifier, and operation input value, and resubmits them to the data submission interface of the initial low-code package. The replay-driven process strictly follows the sorting result of the target replay sequence to ensure that the operation instructions corresponding to the operation nodes output first are submitted first, thereby eliminating potential timing ambiguities in the concurrent injection phase.

[0220] Upon receiving each replay operation instruction, the initial low-code package processes each internal component sequentially according to the standard production workflow. The conflict-free document database first receives the data change request and merges the change with the current database state based on the mixed logical clock value and conflict resolution rules. The reactive validation rules in the business execution template are then triggered, determining the engineering risk parameter range. If the determination result falls within the second-level controllable deviation range, the business process engine calls the controllable deviation range automatic adjudication service for automatic adjudication. After each step is completed, the initial low-code package returns the resulting business replay status to the replay driver process. The business replay status includes: data merging result, range determination result, automatic adjudication conclusion, and the resulting cascading data change records. The replay driver process collects the business replay status from the full operation log in the order of the operation nodes, forming a complete business replay status sequence.

[0221] After completing the full operation log replay, the system first iterates through each record in the business replay status sequence to identify the engineering business entity and specific fields involved in that record. Then, based on the rule call relationship mapping table established during the program integration phase, the system locates the engineering specification bytecode module and verification function entry point bound to that field. A call request is then sent to the Web assembly virtual machine on the shadow server, passing in the current value of the field and the context value of the associated field. The Web assembly virtual machine loads the corresponding engineering specification bytecode module and executes the forward calculation logic and reverse verification logic.

[0222] The forward calculation logic calculates the theoretical values ​​of engineering indicators based on the input business data; the reverse verification logic deduces the constraints that each input parameter should meet based on the target value or allowable range of the engineering indicators, and compares them with the actual input values. The execution results of the engineering specification bytecode module are returned in the form of structured data, including: calculated output values, boolean flags indicating whether constraint verification passed or failed, and descriptions of constraint violations generated when verification failed. The execution results of all engineering specification bytecode modules are aggregated into a rule execution result set. Each record in the rule execution result set contains an operation node identifier, the corresponding engineering specification bytecode module identifier, calculated output values, constraint verification flags, and descriptions of constraint violations.

[0223] The system iterates through all formal constraint nodes in the business constraint network. For each formal constraint node, the system executes the corresponding verification logic based on its node type. If the formal constraint node is a computational constraint type, the system retrieves the execution result of the engineering specification bytecode module bound to the computational constraint node from the rule execution result set. If the retrieved constraint verification mark is passed, the consistency verification result of the computational constraint node is consistent. If the constraint verification mark is failed, the system marks the consistency verification result of the computational constraint node as violated, and attaches a description of the violated constraint and the identifier of the operation node that triggered the violation to the record.

[0224] If the formal constraint node belongs to the interval constraint type, the system retrieves all interval judgment results of the engineering parameters under the jurisdiction of the interval constraint node during the playback process from the business playback status sequence. If all judgment results do not enter the third-level over-limit risk interval, and the adjudication conclusions of the controllable deviation interval automatic adjudication service are all releases, then the consistency check result of the interval constraint node is consistent. If there is any judgment result that is in the third-level over-limit risk interval, then the consistency check result of the interval constraint node is a violation.

[0225] If the formal constraint node is a causal constraint, the system checks whether the order of the operation nodes associated with the causal constraint node in the target replay sequence is consistent with the process dependency relationship specified in the engineering time-series causal chain. If all operation nodes appear in the specified order, without time reversal or missing preceding processes, the consistency check result of the causal constraint node is consistent. If time reversal is detected, i.e., the operation node of the subsequent process is replayed before the operation node of the preceding process, the consistency check result of the causal constraint node is violated, and the operation node pair with time reversal is marked in the record. The consistency check results of all formal constraint nodes are summarized and combined with the original operation log sequence, business replay status sequence, and rule execution result set to form a unified online verification log.

[0226] S106. Perform topology evolution on the service constraint network based on the offline and online verification logs. Optimize the initial low-code package based on the evolved service constraint network to obtain the engineering low-code package:

[0227] In this embodiment, the node verification parameters of all constraint nodes in the business constraint network are statistically analyzed by combining offline verification logs and online verification logs to update the business constraint network. Then, the engineering business blueprint is updated based on the updated business constraint network, the target specification bytecode is recompiled and generated, and the corresponding engineering specification bytecode module in the initial low-code program package is replaced with the target specification bytecode. The rule call relationship mapping table in the business execution template is updated, and the updated node running attributes and associated weights are solidified to obtain the engineering low-code program package.

[0228] In this step, topology evolution upgrades the business constraint network from a static rule set to a dynamic knowledge structure. It dynamically adjusts the weights of edges between nodes based on observed joint triggering frequency and stability, gradually approximating the constraint coupling relationships in real-world business scenarios. The automatic conversion mechanism for candidate constraint nodes allows applications to automatically discover and absorb new knowledge from operational practice, elevating statistically reliable potential constraints to formal rules, achieving automatic knowledge growth without manual intervention. Continuous updates to node operational attributes establish a multi-dimensional credibility profile for each constraint node. Constraints with high activity and stability receive higher decision weights in subsequent verifications, while long-term ineffective constraints are downgraded or dormant. This process of natural selection continuously improves the verification accuracy and anomaly detection capabilities of the constraint network. Therefore, program optimization based on the evolution results solidifies all knowledge increments discovered during the verification phase into the program package. This ensures that the final delivered application not only undergoes logical completeness verification but also incorporates optimization knowledge accumulated during operational practice, significantly improving the quality and reliability of low-code application generation.

[0229] In step S106, the service constraint network is topologically evolved based on the offline verification log and the online verification log. The initial low-code package is then optimized based on the evolved service constraint network to obtain the engineering low-code package. This process includes the following steps:

[0230] S901. Based on the offline verification logs and online verification logs, calculate the node verification parameters of all constraint nodes in the business constraint network. The node verification parameters include the number of node triggers, the node verification results, and the joint trigger parameters.

[0231] S902. Update the node operation attributes of all constrained nodes according to the node verification parameters, wherein the node operation attributes include node operation activity, node operation stability and node conflict contribution.

[0232] S903. Calculate the association weights between all constraint nodes based on the updated node running attributes, and perform topology evolution on the business constraint network based on the association weights;

[0233] S904. Update the engineering business blueprint based on the topology evolution results of the business constraint network, and compile and generate the target specification bytecode based on the updated engineering business blueprint;

[0234] S905. Optimize the initial low-code package according to the target specification bytecode to obtain the project low-code package.

[0235] In this embodiment, the system combines offline and online verification logs to statistically analyze the node verification parameters of all constraint nodes within the business constraint network. In the offline verification log, the system counts the total number of times the constraint node is called for verification by the engineering specification bytecode module during the local virtual sandbox chaos injection process. In the online verification log, the system counts the total number of times the constraint node is referenced and verified by the rule execution result set during the shadow server replay process. The sum of the two statistical results represents the node trigger count for that constraint node. The node verification result is a binary label indicating whether the constraint node consistently passed consistency verification during this dual-field verification process. For formal constraint nodes, the system checks the constraint consistency verification layer's verification conclusion for that node in the online verification log: if the conclusion is consistent, the node verification result is marked as passed; if the conclusion is violated, the node verification result is marked as failed. For candidate constraint nodes, the system checks whether the offline verification log records that the candidate constraint node was triggered during the chaos injection process, and whether its expected deviation set at the time of triggering matches the actual parameter deviation. If they match, the node verification result is marked as passed; otherwise, it is marked as failed. The joint triggering parameter is a set of pairwise statistical data used to record the frequency with which any two constraint nodes are jointly triggered by the same operation event during this dual-field verification process. Each operation record in the offline and online verification logs is traversed, and the list of constraint nodes triggered in that operation record is extracted. For each pair of constraint nodes in the list, the system increments its joint triggering count by 1. This ultimately forms a joint triggering frequency matrix, where the element in the i-th row and j-th column represents the total number of times constraint node i and constraint node j are jointly triggered during this verification process.

[0236] After calculating the node validation parameters for all constrained nodes, the node operation attributes of each constrained node are updated in batches based on these parameters. Node operation attributes include node activity, node stability, and node conflict contribution, with update rules as follows. The calculation formula for updating node activity is:

[0237] ;

[0238] in, Represents constraint nodes Updated node activity level; Represents constraint nodes Node activity level before the update Represents constraint nodes The number of times the node is triggered; This represents the maximum number of node triggers across all constraint nodes in the business constraint network. This represents the set of all constraint nodes in the business constraint network. This is the historical decay coefficient, used to balance the contribution ratio of historical activity to the activity of this verification. The reference value is 0.70.

[0239] For updating node stability, different update strategies are used based on the node verification result. If the node verification result is passed, the node stability is updated according to an incremental formula:

[0240] ;

[0241] in, Represents constraint nodes The updated node's operational stability; Represents constraint nodes Node stability before the update; The stability increment step size is set to 0.05, with a reference value of 0.05.

[0242] If the node verification result is unsuccessful, the node's operational stability is updated according to a decreasing formula:

[0243] ;

[0244] in, This is the stability decay factor. The stability decay factor is determined based on the principle that a single validation failure should result in a significant but non-catastrophic reduction in confidence; a reference value of 0.30 is used.

[0245] For updating the node conflict contribution, firstly, the total number of constraint consistency check events marked as violations during this check process is counted from the online check log, denoted as . Then, the number of times each constraint node was marked as participating in the judgment in these violation events is counted, denoted as . The update formula for node conflict contribution is:

[0246] ;

[0247] in, Represents constraint nodes Updated node conflict contribution; Represents constraint nodes Node conflict contribution before update; Represents constraint nodes The number of times a violation event was marked as participating in the judgment during this verification; This indicates the total number of violations during this verification process; It is a very small positive number, with a value of 0.001, used to prevent the denominator from being zero; This is the conflict history attenuation coefficient, with a reference value of 0.60.

[0248] After updating the node runtime attributes of all constraint nodes, the association weights between constraint nodes are recalculated based on the updated attribute values, and the topology evolution of the business constraint network is performed accordingly. The association weight calculation is performed on each pair of constraint nodes with associated edges in the business constraint network. For constraint nodes... With constraint nodes The formula for calculating the association weight of the edges between nodes is as follows:

[0249] ;

[0250] in, Represents constraint nodes With constraint nodes The association weight of the edges connecting nodes; Represents constraint nodes With constraint nodes The number of joint triggers during this verification process. This represents the maximum number of times all constraint node pairs can be jointly triggered. and Representing constraint nodes With constraint nodes The updated node's operational stability and Representing constraint nodes With constraint nodes Updated node activity level It is a very small positive number, taking the value 0.001. , , These are weighting coefficients, which control the contribution of joint trigger frequency, stability product, and average activity to the association weight, respectively. The default values ​​are 0.50, 0.30, and 0.20.

[0251] After calculating the association weights of all node-related edges, the system performs topology evolution of the business constraint network. First, the weights of existing node-related edges are adjusted. The weight attribute of each node-related edge is updated to the association weight value calculated by the above formula. After the update, if the association weight of a node-related edge is lower than a preset weak connection threshold, such as 0.15, the system marks the edge as a weak connection. Next, it iterates through all constraint node pairs in the joint trigger frequency matrix with a joint trigger count greater than zero. If there is currently no node-related edge between a pair of constraint nodes, and the calculated association weight exceeds the new association threshold, such as 0.4, a new node-related edge is automatically established between these two constraint nodes, and its association weight is initialized to the calculated value. Finally, it iterates through all candidate constraint nodes in the business constraint network to check whether they meet the conversion conditions.

[0252] The criteria for formalizing a candidate constraint node include two indicators that must be met simultaneously: First, the updated node activity level of the candidate constraint node must not be lower than the activity level formalization threshold, such as 0.30; second, the updated node stability level of the candidate constraint node must not be lower than the stability level formalization threshold, such as 0.8. If the candidate constraint node meets both conditions, the system changes its node type from candidate to formal and includes it in the formal constraint node set. If the candidate constraint node only meets the activity level condition but not the stability condition, it remains in the candidate state and awaits further verification in subsequent verification cycles. If the node activity level of the candidate constraint node is consistently lower than the activity level dormancy threshold, such as 0.05, and this state remains unchanged for multiple consecutive verification cycles (the preset reference value for the number of verification cycles is 5), the system marks the candidate constraint node as dormant. Dormant nodes no longer participate in the subsequent chaotic injection target screening and constraint consistency verification, but their node data and historical attributes are fully preserved.

[0253] When a constraint node transitions from a candidate state to a formal state, the association between the constraint node and existing formal constraint nodes in the formal constraint network is checked. The node association edges originally marked as candidate associations are updated to formal node association edges of the corresponding business type, and the weights of the association edges are recalculated based on the updated node operation attributes of the constraint node.

[0254] After the topology evolution of the business constraint network is completed, the evolved business constraint network replaces the original copy of the business constraint network in the engineering business blueprint. This includes the node operation attributes of all formal constraint nodes and candidate constraint nodes, the association weights of all node-related edges, and any newly added or adjusted topology structures. Simultaneously, the engineering business rule set in the engineering business blueprint is updated, incorporating the engineering business rules corresponding to the newly officially recognized formal constraint nodes into the engineering business rule set, enabling them to participate in formal verification during subsequent operation. After the update is complete, a new version number is assigned to the engineering business blueprint, and a hash calculation and digital signature are performed before storing it in the blueprint version repository.

[0255] The community discovery algorithm is re-executed to re-divide the updated business constraint network into business constraint communities to adapt to the topology changes. Based on the new business constraint community partitioning results, the system recompiles the updated set of engineering business rules into engineering specification bytecode according to the compilation process. The newly compiled engineering specification bytecode is the target specification bytecode. The system locates the engineering specification bytecode module set corresponding to the business constraint communities in the initial low-code package and replaces those modules with newly added constraint nodes or changed attributes due to topology evolution with the corresponding target specification bytecode modules. The replacement process maintains the synchronous update of the module loading mapping table to ensure that cross-community call stub functions between modules point to the correct target module entry point. Next, the rule call relationship mapping table in the business execution template is updated, binding the verification hooks and calculation triggers corresponding to the newly converted formal constraint nodes to the corresponding business execution template fields, enabling the runtime engine to correctly call the newly added verification functions in the target specification bytecode. Next, the updated node runtime attributes are persisted to the persistent storage of the corresponding constraint nodes, and the evolved association weights are written to the configuration layer of the conflict-free document merging engine to guide conflict resolution decisions during subsequent runtime.

[0256] After completing the above optimization operations, the optimized package undergoes overall hash calculation and digital signature to obtain the project low-code package. This project low-code package has incorporated all the effective knowledge increments discovered during the dual-field verification process. Its internal business constraint network, after topology evolution, possesses stronger logical completeness and anomaly detection capabilities, and can serve as the final product for production environment deployment.

[0257] S107. Solidify the business constraint network that has completed topology evolution into the engineering low-code package, and deploy the background auxiliary engine in the solidified engineering low-code package to obtain the engineering low-code application.

[0258] In this embodiment, after program optimization, the system solidifies a complete snapshot of the business constraint network, verified by topology evolution, into the persistent storage layer of the engineering low-code package. The solidified content includes: the final values ​​of the node runtime attributes of all formal constraint nodes and candidate constraint nodes, the final values ​​of the association weights of all node-related edges, and the engineering business rules corresponding to newly formalized constraint nodes during the evolution process. The solidification operation ensures that the current state of the business constraint network becomes an immutable component of the package, distributed and deployed along with the package. After solidification, the system encapsulates and deploys three sets of backend auxiliary engines into the engineering low-code package. The first set is a constraint propagation link inferrer. This inferrer constructs a constraint propagation graph based on the engineering temporal causal chain in the engineering business blueprint and the node-related edges of the business constraint network. When the attribute value of any engineering business entity is modified during runtime, the inferrer starts from the modified point and traverses the directed path in the constraint propagation graph layer by layer, calculating the set of directly affected nodes and the set of indirectly affected nodes, generating a chain-effect prediction report. The report includes information on which downstream processes will have their verification results recalculated, which completed business replays may be marked as requiring review, and the depth and scope of the impact.

[0259] The second system is a digital twin behavior comparison engine. This engine has a built-in physical evolution model of the corresponding construction object. Based on input conditions such as mix proportion parameters, ambient temperature, ambient humidity, and age, it calculates the theoretical index growth curve in real time as the digital twin prediction trajectory. When on-site operators enter test data, the engine calculates the deviation between the actual test value and the digital twin prediction value under the corresponding conditions after verifying compliance with specifications. If the absolute value of the deviation exceeds the preset physical deviation alarm threshold, the engine marks the data as a potential physical anomaly, even if the data meets the range requirements of all specification formulas. The physical deviation alarm threshold is determined based on the upper limit of the normal fluctuation range of the physical properties of engineering materials, with a reference value of 15% of the predicted value.

[0260] The third engine is a dynamic monitoring engine for cumulative deviations. This engine continuously calculates the trigger frequency of controllable deviation ranges and the number of times risk exceeding limits is blocked for each engineering business entity dimension, using a sliding time window for periodic calculations. When the process capability deviation index of a certain dimension exceeds a preset deviation alarm threshold, the engine automatically adjusts the engineering risk parameter range associated with that dimension, narrowing the boundary between the controllable deviation range and the risk exceeding limit range towards a safer direction. The deviation alarm threshold is determined based on the general warning standard for the process capability index in engineering quality management, with a reference value of 0.25. Simultaneously, at the completion node, the engine automatically aggregates all operation logs, constraint consistency verification records, automatic adjudication traces for controllable deviation ranges, and deviation monitoring records to generate a self-certification report. The self-certification report embeds a report integrity verification code, allowing third parties to verify its integrity and authenticity by recalculating the causal hash chain of the report data. After completing the encapsulation and deployment of the above-mentioned backend auxiliary engines, the system applies a digital signature to the final product, resulting in a low-code application for the engineering project.

[0261] On the other hand, this embodiment also provides a low-code application automatic generation system for the engineering and construction industry, including:

[0262] The memory is a machine-readable storage medium storing computer instructions that execute the above-described method for automatically generating low-code applications for the engineering and construction industry.

[0263] The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the aforementioned method for automatically generating low-code applications for the engineering and construction industry.

[0264] The processor can be a central processing unit (CPU). Of course, depending on the actual use, it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc., and this application does not limit it.

[0265] The memory can be an internal storage unit of a computer device, such as a hard disk or RAM, or an external storage device, such as a plug-in hard disk, smart memory card (SMC), secure digital card (SD), or flash memory card (FC) provided on the computer device. Furthermore, the memory can be a combination of internal storage units and external storage devices of a computer device. The memory is used to store computer programs and other programs and data required by the computer device. The memory can also be used to temporarily store data that has been output or will be output. This application does not limit this.

[0266] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0267] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0268] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0269] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0270] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0271] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0272] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0273] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0274] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for automatically generating low-code applications for the engineering and construction industry, characterized in that, Includes the following steps: S101. Based on the pre-constructed multimodal large model, perform specification text parsing on the received engineering industry specification information, construct a business constraint network based on the specification text parsing results, and construct an engineering business blueprint based on the business constraint network. The engineering business blueprint includes engineering business rules and engineering business entities. S102. Divide the business constraint network into business constraint communities according to the community discovery algorithm, and perform double-ended isomorphic compilation on the engineering business rules according to the division results of the business constraint communities to obtain the engineering specification bytecode; S103. Construct a business execution template based on the engineering business entity mapping, and perform program integration based on the business execution template and engineering specification bytecode to generate an initial low-code program package; S104. Perform offline verification on the initial low-code package based on the pre-built local virtual sandbox, and generate offline verification logs based on the offline verification results; S105. Perform causal topology verification of the initial low-code package online based on the offline verification log, and generate online verification log based on the causal topology verification results; S106. Perform topology evolution on the service constraint network based on the offline verification log and the online verification log, and optimize the initial low-code package based on the service constraint network after the topology evolution to obtain the engineering low-code package; S107. Solidify the business constraint network that has completed topology evolution into the engineering low-code package, and deploy the background auxiliary engine in the solidified engineering low-code package to obtain the engineering low-code application.

2. The method for automatically generating low-code applications for the engineering construction industry according to claim 1, characterized in that, In step S101, the received engineering industry standard information is parsed using a pre-constructed multimodal large model. A business constraint network is then constructed based on the parsing results, and an engineering business blueprint is built based on the business constraint network. This includes the following steps: S201. Based on the multimodal large model, identify and extract engineering specification structure blocks of engineering industry standard information. Among them, the engineering specification structure blocks include engineering specification table blocks, engineering specification formula blocks, engineering specification text blocks and engineering specification vector blocks. The multimodal large model includes entity recognition engine, symbol calculation engine and syntactic analysis engine. S202. Perform text semantic parsing on all engineering specification structural blocks using the entity recognition engine, and generate an engineering semantic entity set based on the text semantic parsing results; S203. Retrieve the project form template from the pre-built project database, perform form template matching on all project semantic entities in the project semantic entity set according to the project form template, and complete the parameter filling of the project form template according to the form template matching result to obtain the project template instance; S204. Extract the set of engineering constraints for the engineering specification structure blocks from the multimodal large model, and construct a business constraint network based on the set of engineering constraints. The set of engineering constraints includes the set of engineering calculation constraints, the range of engineering risk parameters, and the engineering temporal causal chain. S205. Using engineering template instances as the backbone of engineering business, and encapsulating business constraint networks and engineering temporal causal chains as core components of engineering business, an engineering business blueprint is constructed. The engineering business blueprint includes engineering business rules, engineering business entities, business constraint networks, and business relationships.

3. The method for automatically generating low-code applications for the engineering construction industry according to claim 2, characterized in that, In step S204, the engineering constraint set of the engineering specification structural block is extracted based on the multimodal large model, and the business constraint network is constructed based on the engineering constraint set, including the following steps: S301. The mathematical expression is parsed from the engineering specification formula block and the engineering specification text block using the symbolic computation engine; S302. Generate forward calculation logic and reverse verification logic based on mathematical expressions, and combine the forward calculation logic and reverse verification logic to generate a set of engineering calculation constraints; S303. Perform flexible semantic recognition based on the engineering specification text block, query the corresponding historical deviation distribution parameters from the engineering database based on the flexible semantic recognition results, and generate the corresponding engineering risk parameter range based on the historical deviation parameters; S304. Use a syntactic analysis engine to identify process relationships and corresponding process relationship confidence from engineering specification text blocks, and construct a directed causal graph of the engineering based on the process relationships; S305. Perform directed cycle detection on the directed causal graph of the project using the graph search algorithm. Based on the directed cycle detection results and the process association confidence, optimize the causal graph of the directed causal graph of the project to obtain the temporal causal chain of the project. S306. Map the set of engineering calculation constraints, the range of engineering risk parameters, and the engineering time-series causal chain to formal constraint nodes, and construct node association edges based on the process association relationships between formal constraint nodes; S307. Retrieve historical engineering business records from the engineering database, and search for engineering event association parameters from the historical engineering business records based on the association rule mining algorithm; S308. Generate candidate constraint nodes based on the engineering event association parameters, and associate the candidate constraint nodes with the corresponding formal constraint nodes or node association edges to obtain the business constraint network.

4. The method for automatically generating low-code applications for the engineering construction industry according to claim 3, characterized in that, In step S102, the business constraint community of the business constraint network is divided according to the community discovery algorithm. Based on the division result of the business constraint community, the engineering business rules are compiled isomorphically by both ends to obtain the engineering specification bytecode, including the following steps: S401. Map the global business constraint graph based on the formal constraint nodes, candidate constraint nodes, and node-associated edges; S402. Retrieve historical engineering business records from the engineering database, calculate the historical operation attributes of all constraint nodes based on the historical engineering business records, and calculate the edge weights of the global business constraint graph based on the historical operation attributes of the nodes. S403. Construct a modularity optimization function to complete the global business constraint graph based on the graph edge weights. Divide the global business constraint graph into communities based on the modularity optimization function and the community detection algorithm to obtain multiple business constraint communities. S404. Traverse all node association edges between business constraint communities and extract all cross-community bridge edges between business constraint communities; S405. Determine the cross-community data flow direction between all business constraint communities based on the cross-community bridging edge, and generate community interaction protocol interfaces based on the cross-community data flow direction; S406. Traverse the business constraint community, extract the engineering business rules corresponding to all formal constraint nodes in the community, and perform double-ended isomorphic compilation on all engineering business rules according to the business constraint community to obtain the standard bytecode module; S407. Establish cross-module call relationships between all standard bytecode modules according to the community interaction protocol interface, and complete the program integration of all standard bytecode modules according to the cross-module call relationships to obtain the engineering standard bytecode.

5. The method for automatically generating low-code applications for the engineering construction industry according to claim 4, characterized in that, In step S103, a business execution template is constructed based on the engineering business entity mapping. The program is then integrated based on the business execution template and the engineering specification bytecode to generate an initial low-code package, including the following steps: S501. Extract the set of business attributes of the engineering business entities based on the engineering business blueprint, wherein the set of business attributes includes entity attribute parameters, entity association relationships and business constraint relationships; S502. Map all engineering business entities to the corresponding business execution template body according to the entity attribute parameters; S503. Based on the business constraint network, map the engineering business rules corresponding to the formal constraint nodes to the business execution template body to obtain the business execution template. Based on the mapping result of the engineering business rules, construct the rule calling relationship between the business execution template and the engineering specification bytecode. S504. Determine the template reference relationships between business execution templates corresponding to engineering business entities based on entity association relationships; S505. Establish program integration relationships based on rule call relationships, template reference relationships, and process association relationships. Based on the program integration relationships, complete the program integration of engineering specification bytecode and business execution templates to generate an initial low-code program package.

6. The method for automatically generating low-code applications for the engineering construction industry according to claim 5, characterized in that, In step S104, the initial low-code package is offline verified based on the pre-built local virtual sandbox, and an offline verification log is generated based on the offline verification results, including the following steps: S601. Deploy the initial low-code package to a pre-built local virtual sandbox; S602. Calculate the node topology attributes of all constraint nodes in the business constraint network, and determine the attack priority of all constraint nodes based on the node topology attributes and the division results of the business constraint community. Among them, constraint nodes include formal constraint nodes and candidate constraint nodes. S603. Retrieve historical engineering business records from the engineering database, and calculate the historical operation attributes of all constraint nodes based on the historical engineering business records. The historical operation attributes of nodes include historical operation activity, historical operation stability, and historical conflict contribution. S604. Calculate the chaotic verification operation sequence based on the attack priority, node historical running attributes, and engineering constraint set; S605. Run the initial low-code program package according to the chaotic verification operation sequence, synchronously collect the program running parameters of the initial low-code program, and generate offline verification logs based on the program running parameters.

7. The method for automatically generating low-code applications for the engineering construction industry according to claim 6, characterized in that, In step S604, the chaotic verification operation sequence is calculated based on the attack priority, the node's historical running attributes, and the engineering constraint set, including the following steps: S701. Based on the attack priority and the historical operation attributes of the nodes, the target constraint nodes and the corresponding target associated edges are selected from the business constraint network. S702. Locate the preceding and subsequent processes in the engineering time-series causal chain based on the target associated edge, and search for the target process path along the engineering time-series causal chain based on the preceding and subsequent processes; S703. Perturb the path sequence of the target process path to obtain the process attack sequence; S704. Based on the set of engineering calculation constraints corresponding to the target constraint node, select all engineering variables and variable constraints, and dynamically perturb all engineering variables and variable constraints to generate a constraint conflict attack sequence. S705. Based on the preset perturbation step size and perturbation direction, continuously perturb all engineering risk parameter intervals corresponding to the target constraint node to obtain the interval attack sequence; S706. Based on the cross-combination of process attack sequence, constraint conflict attack sequence and interval attack sequence, a chaotic verification operation sequence is obtained.

8. The method for automatically generating low-code applications for the engineering construction industry according to claim 7, characterized in that, In step S105, the causal topology verification of the initial low-code package is completed online based on the offline verification log, and an online verification log is generated based on the causal topology verification results, including the following steps: S801. Deploy the initial low-code package to a pre-built shadow server; S802. Extract the operation log sequence from the offline verification log and inject the operation log sequence concurrently into the shadow server; S803. When the shadow server receives the operation log sequence, it uses the multimodal large model to parse out the metadata fields of all operation logs in the operation log sequence. The metadata fields include the hybrid logical clock value, causal hash pointer, business document, and business entity. S804. Using the operation log as the operation node, and combining the hybrid logic clock value and the causal hash pointer, establish the operation causal edge between the operation nodes to obtain the operation causal topology graph; S805. Based on the operation cause-effect topology graph, perform topological sorting of all operation logs to obtain the target replay sequence; S806. Input all operation logs into the initial low-code package according to the target playback sequence, execute business playback through the initial low-code package, and obtain the business playback status; S807. Based on the business playback status, call the engineering specification bytecode to execute the engineering business rules and obtain the rule execution results; S808. Perform constraint consistency verification on all formal constraint nodes in the business constraint network based on the rule execution results, and generate online verification logs based on the constraint consistency verification results.

9. The method for automatically generating low-code applications for the engineering construction industry according to claim 8, characterized in that, In step S106, the service constraint network is topologically evolved based on the offline verification logs and the online verification logs. The initial low-code package is then optimized based on the evolved service constraint network to obtain the engineering low-code package, including the following steps: S901. Based on the offline verification logs and online verification logs, calculate the node verification parameters of all constraint nodes in the business constraint network. The node verification parameters include the number of node triggers, the node verification results, and the joint trigger parameters. S902. Update the node operation attributes of all constrained nodes according to the node verification parameters, wherein the node operation attributes include node operation activity, node operation stability and node conflict contribution. S903. Calculate the association weights between all constraint nodes based on the updated node running attributes, and perform topology evolution on the business constraint network based on the association weights; S904. Update the engineering business blueprint based on the topology evolution results of the business constraint network, and compile and generate the target specification bytecode based on the updated engineering business blueprint; S905. Optimize the initial low-code package according to the target specification bytecode to obtain the project low-code package.

10. A low-code application automatic generation system for the engineering and construction industry, characterized in that, include: The memory is a machine-readable storage medium storing computer instructions that execute any one of claims 1 to 9 of the method for automatically generating low-code applications for the engineering and construction industry. A processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement a method for automatically generating low-code applications for the engineering and construction industry according to any one of claims 1 to 9.

Images