Party building group-oriented low-code process checking method, system and equipment based on knowledge graph and storage medium

Abstract

The invention relates to the technical field of low-code development and compliance management, in particular to a party construction group-oriented low-code process checking method, system and equipment based on a knowledge graph and a storage medium. The method comprises the following steps: receiving and preprocessing an entry information set to obtain a policy set, and executing field naming unification, time format unification and necessary item placeholder processing to generate a normalized parameter set; constructing a policy knowledge graph based on the policy set and the normalized parameter set, forming a node dictionary through term alignment and synonymous merging, performing mapping according to constraint types of elements and fields, generating a rule interpretation plan and element mapping list, generating a red line strategy library through a rule matching algorithm, and binding the red line strategy library with low-code process nodes; performing real-time red line detection to identify illegal nodes and position policy sources, and generating rectification guidance flow; and performing risk assessment and grading processing on the violation state, generating a compliance score in combination with a rectification path, outputting a release list, and updating the policy knowledge graph and the red line policy library.

Description

Technical Field

[0001] This invention relates to the field of low-code development and compliance management technology, and in particular to a knowledge graph-based low-code process verification method, system, device and storage medium for Party building and mass organizations. Background Technology

[0002] Low-code development platforms are widely used in policy-intensive fields such as government administration, Party building, and mass organizations. Through graphical interfaces and visual process orchestration, low-code platforms enable non-technical personnel to quickly build business processes, thereby optimizing the efficiency of non-technical personnel in terms of processes and providing innovative new solutions for government services.

[0003] However, existing low-code process orchestration technologies still have many problems when dealing with complex policy compliance issues. For example, traditional compliance checks mainly rely on simple rules or predefined rule sets. However, these methods are difficult to quickly output adapted solutions and accurate verification when faced with scenarios with numerous policy clauses, complex relationships between requirements, and multiple constraints. This is especially true in areas such as Party building and mass organizations, where policy documents involve multiple dimensions such as organizational structure, role permissions, and approval processes. Furthermore, there are cross-references and hierarchical relationships between different policies, and a single rule matching cannot handle this complexity.

[0004] In existing low-code platforms, process data often comes from different systems and departments, and problems such as inconsistent field naming, inconsistent time formats, and missing required fields are common. The lack of automated data preprocessing and standardization methods makes it easy for subsequent compliance verification processes to make misjudgments or omissions, affecting the accuracy of process execution. Existing technologies lack a systematic method for establishing the mapping relationship between policy clauses and process fields, making it difficult to achieve accurate alignment between policy requirements and business data.

[0005] After violations are discovered, the lack of automated rectification guidelines and risk classification and handling plans makes it impossible to formulate differentiated handling strategies based on the severity and scope of the violation; the lack of tracking of the rectification process and dynamic updating of the policy knowledge base leads to the possibility of repeated occurrence of the same compliance issues, making it impossible to form a virtuous cycle of continuous optimization. Summary of the Invention

[0006] In view of the problems existing in the prior art, the present invention is proposed.

[0007] Therefore, the problems to be solved by this invention are: how to achieve automated and accurate mapping of complex policy provisions and process data; how to build a systematic compliance verification and detect violation nodes in real time; how to formulate differentiated rectification plans based on the risk level of the violation status; and how to establish a complete management system from violation detection and rectification guidance to closed-loop optimization.

[0008] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, embodiments of the present invention provide a knowledge graph-based low-code process verification method for Party building and mass organizations, which includes receiving an entry information set and preprocessing it, obtaining a policy set, and generating a standardized parameter set through unified field naming, unified time format, and mandatory field placeholder processing. Based on the policy set and the standardized parameter set, a policy knowledge graph is constructed. Through terminology alignment and synonym merging between policy clause nodes and field nodes, an aligned node dictionary is formed. The nodes are then mapped according to the constraint types of the requirements and fields to generate a rule interpretation plan and a requirement mapping list. Based on the rule interpretation plan and the requirement mapping list, the low-code process data is checked. A redline strategy library is generated through a rule matching algorithm, and the redline strategies are bound to the low-code process nodes to generate a strategy layer binding list. Real-time red line detection is performed based on the strategy layer binding list to identify violation nodes and locate policy sources, extract the complete description of policy clauses, extract relevant clause steps from the rule interpretation plan, and generate rectification guidance flow; Based on the rectification guidelines, risk assessments and tiered handling of non-compliance status are conducted. Compliance scores are generated by combining the rectification path, and release orders are output, while the policy knowledge graph and red line strategy library are updated.

[0009] As a preferred embodiment of the knowledge graph-based low-code process verification method for Party building and mass organizations described in this invention, the construction of the policy knowledge graph includes extracting policy clauses and essential information from a policy set as policy clause nodes. Extract field names, field types, and field values ​​from the normalized parameter set to create field nodes; By connecting policy clause nodes with field nodes, a mapping relationship between policy clauses and fields is established, forming a policy knowledge graph.

[0010] As a preferred embodiment of the knowledge graph-based low-code process verification method for Party building and mass organizations described in this invention, the step of forming an aligned node dictionary includes performing term alignment and synonym merging in the policy knowledge graph to merge different terms expressing the same concept into a unified term. The policy clause node is used to perform noun storage processing on the field node, and the names of the field node are compared with the names of the policy clause node to establish a clear correspondence and generate an aligned node dictionary.

[0011] As a preferred embodiment of the knowledge graph-based low-code process verification method for Party building and mass organizations described in this invention, the mapping according to the constraint type of the elements and fields includes mapping policy clause nodes to field nodes one-to-one and one-to-many based on the aligned node dictionary. In a one-to-one mapping, each policy clause node corresponds to a unique field node; in a one-to-many mapping, one policy clause node corresponds to multiple field nodes. Record the mapping relationships and generate a mapping table. Extract executable rules and parameter value paths from the mapping table, arrange them into a rule interpretation plan, and obtain the requirement mapping list.

[0012] As a preferred embodiment of the knowledge graph-based low-code process verification method for Party building and mass organizations described in this invention, the step of generating a red line strategy library through a rule matching algorithm includes performing existence, value legality, and role constraint verification on low-code process data according to the mapping relationship between the rule interpretation plan and the requirement mapping list, and obtaining the process dataset. Based on the process dataset and the constraints in the policy clauses, a rule matching algorithm is used to verify whether the fields meet the requirements of the clauses. Mark successfully matched fields as meeting the conditions, generate corresponding redline strategies, assign a unique identifier to each redline strategy, and form a redline strategy library.

[0013] The beneficial effects of this preferred technical solution are as follows: By performing existence verification, value validity verification, and role constraint verification on low-code process data, it is possible to comprehensively identify format errors, missing fields, and permission mismatches in the process data in the early stages; Combined with the restrictions in policy clauses, the rule matching algorithm verifies whether the fields meet the requirements of the clauses, achieving a precise correspondence between policy clauses and process fields; Successfully matched fields are marked as compliant and corresponding red line strategies are generated, and a unique identifier is assigned to each red line strategy to form a red line strategy library, establishing a standardized rule system for policy compliance checks.

[0014] As a preferred embodiment of the knowledge graph-based low-code process verification method for Party building and mass organizations described in this invention, the generation of the strategy layer binding list includes matching low-code process nodes with red-line strategies in the red-line strategy library to verify whether the process node operation conforms to the restriction conditions in the red-line strategy. Bind eligible redline strategies to corresponding process nodes to generate a process orchestration interface with bound redline strategies. Perform compliance verification on the process orchestration interface that has been bound to redline policies. Check the binding status of each low-code process node with the corresponding redline policy, verify whether each low-code process node meets the constraints in the redline policy, record the low-code process nodes that do not meet the redline policy requirements as non-compliant items, and mark the reasons for non-compliance. Compile and summarize all the binding status and non-compliant items of low-code process nodes with the corresponding redline policies to generate a policy layer binding list.

[0015] The beneficial effects of this preferred technical solution are as follows: It matches low-code process nodes with red-line policies in the red-line policy library, verifies whether the operation of process nodes complies with the restrictions in the red-line policies, and achieves real-time compliance judgment during process orchestration, enabling the discovery of potential violation risks at the process design stage; it binds compliant red-line policies with corresponding process nodes, generating a process orchestration interface with bound red-line policies, making the compliance requirements of each process node intuitively visible, facilitating process designers' understanding and compliance with policy constraints; it performs compliance verification on the process orchestration interface with bound red-line policies, checking the binding status of low-code process nodes with corresponding red-line policies one by one, recording low-code process nodes that do not meet the red-line policy requirements as non-compliant items and indicating the reasons for non-compliance, and compiling and summarizing all low-code process nodes with corresponding red-line policies and non-compliant items to generate a policy layer binding list, achieving full-process compliance tracking and problem localization.

[0016] As a preferred embodiment of the knowledge graph-based low-code process verification method for Party building and mass organizations described in this invention, the step of risk assessment and graded handling of violation status according to the rectification guidance flow includes risk assessment of the remaining violation status in the rectification plan and identification of potential risks. Based on the severity, scope of impact, and difficulty of resolution, the violation status is divided into high-risk, medium-risk, and low-risk categories, generating a tiered disposal list. The rectification plan is evaluated for compliance based on the tiered disposal list, the rectification path is recorded, and the final rectification plan is generated. The remaining violations will be rectified according to the final rectification plan, and the verified and qualified rectification results will be recorded as a list of resolved issues. Based on compliance scores and rectification paths, combined with a list of resolved issues, a release order is generated, and the policy knowledge graph and red line strategy library are updated.

[0017] Secondly, embodiments of the present invention provide a knowledge graph-based low-code process verification system for Party building and mass organizations, which includes a preprocessing module for receiving an entry information set and performing preprocessing, obtaining a policy set, and generating a standardized parameter set. The graph construction module is used to construct a policy knowledge graph based on the policy set and the standardized parameter set, form an aligned node dictionary, and generate a rule interpretation plan and a list of requirements mapping. The strategy verification module is used to interpret the plan and the requirement mapping list according to the rules, perform verification on the low-code process data, generate a redline strategy library and bind it, and generate a strategy layer binding list. The detection and rectification module is used to perform real-time red line detection based on the list bound to the strategy layer, identify violation nodes and generate rectification guidance flow; The closed-loop optimization module is used to conduct risk assessment and graded handling of non-compliance status based on the rectification guidelines, generate compliance scores, output release forms, and update the policy knowledge graph and red line strategy library.

[0018] Thirdly, embodiments of the present invention provide a computer device, including a memory and a processor, wherein the memory stores a computer program, wherein: when the computer program instructions are executed by the processor, they implement the steps of the knowledge graph-based low-code process verification method for Party building and mass organizations as described in the first aspect of the present invention.

[0019] Fourthly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program instructions are executed by a processor, they implement the steps of the knowledge graph-based low-code process verification method for Party building and mass organizations as described in the first aspect of the present invention.

[0020] The beneficial effects of this invention are as follows: By receiving an entry information set and implementing unified field naming, unified time format, and placeholder processing for required fields, this invention solves the problem of misjudgment in compliance verification caused by heterogeneous data sources and inconsistent formats in low-code platforms. By constructing a policy knowledge graph and performing terminology alignment and synonym merging, it accurately maps policy clause nodes to field nodes in one-to-one and one-to-many ways, generating a rule interpretation plan and a requirement mapping list, thus realizing the transformation of policy semantics into executable rules. By generating a red-line strategy library through a rule matching algorithm and binding the strategies to process nodes, it can detect violation risks in real time during the process orchestration stage. By identifying violation nodes and locating policy sources through real-time red-line detection, it extracts relevant clause steps from the rule interpretation plan to generate a rectification guidance flow, providing responsible persons with clear rectification directions and operational steps. By conducting risk assessment and graded handling of violation status, combined with the rectification path, it generates a compliance score and updates the policy knowledge graph and red-line strategy library; ensuring that the same compliance issues do not recur, it achieves continuous optimization and dynamic adaptation of low-code processes in policy-intensive scenarios. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A flowchart of a knowledge graph-based low-code process verification method for Party building and mass organizations; Figure 2 This is a computer equipment diagram for a knowledge graph-based low-code process verification method for Party building and mass organizations. Detailed Implementation

[0023] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0024] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0025] Secondly, the term "an embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places throughout this specification does not necessarily refer to the same embodiment, nor is it a single embodiment or an embodiment selectively excluded from other embodiments.

[0026] Example 1 Reference Figure 1 - Figure 2 As the first embodiment of the present invention, this embodiment provides a knowledge graph-based low-code process verification method for Party building and mass organizations, including: S100: Receives and preprocesses the set of entry information, obtains the policy set, and generates a standardized parameter set through unified field naming, unified time format, and mandatory field placeholder processing.

[0027] S200: Based on the policy set and the standardized parameter set, a policy knowledge graph is constructed. Through terminology alignment and synonym merging between policy clause nodes and field nodes, an aligned node dictionary is formed. The nodes are then mapped according to the constraint types of the requirements and fields to generate a rule interpretation plan and a requirement mapping list. Based on the rule interpretation plan and the requirement mapping list, the low-code process data is checked. A redline strategy library is generated through a rule matching algorithm, and the redline strategies are bound to the low-code process nodes to generate a strategy layer binding list.

[0028] S300: Real-time red line detection is performed based on the policy layer binding list, identifying violation nodes and locating policy sources, extracting the complete description of policy clauses, extracting relevant clause steps from the rule interpretation plan, and generating rectification guidance flow.

[0029] S400: Based on the rectification guidelines, conduct risk assessments and classify and handle violations, generate compliance scores by combining rectification paths, output release forms, and update the policy knowledge graph and red line strategy library.

[0030] It should be noted that traditional process orchestration methods lack a deep understanding of policy semantics and cannot establish a precise mapping relationship between policy clauses and process fields, resulting in frequent violations of policy requirements during process execution. The policy requirements for different organizations and roles vary, and issues such as inconsistent field naming, inconsistent time formats, and missing required fields in process data further exacerbate the difficulty of compliance verification, affecting the accuracy and efficiency of process execution.

[0031] Therefore, S100 receives and preprocesses the ingress information set, unifying field naming, time format, and mandatory field placeholders in the policy set to solve the problems of heterogeneous data sources and inconsistent formats. S200 constructs a policy knowledge graph based on a standardized parameter set, forming a unified node dictionary through terminology alignment and synonym merging, and accurately mapping according to the constraint types of requirements and fields to generate rule interpretation plans and red line strategy libraries. S300 identifies violation nodes through real-time red line detection, locates the policy source, and generates rectification guidance flow to provide operational guidance for the rectification of violations. S400 performs risk assessment and graded handling of violation status, generates compliance scores based on rectification paths, and updates the knowledge graph, forming a complete closed loop from problem discovery, analysis, handling to knowledge base optimization.

[0032] Example 2 Reference Figure 1 - Figure 2 This is the second embodiment of the present invention.

[0033] In this embodiment, the generation of the normalized parameter set in step S100 includes the following step A1: A1: Receive and preprocess the entry information set, obtain the policy set, and generate a standardized parameter set by unifying field naming, time format, and handling required field placeholders.

[0034] Specifically, the entry information set includes process description, data content, release type, tenant identifier, organization code, role set, policy identifier, version number, and tracking number. Process descriptions are collected from business requirement documents, reflecting the execution steps and task descriptions of the business process; data content is received through interface queries, containing specific data related to the business process; release types are collected through the release management node, recording the release type of the process; tenant identifiers are received through the tenant management node, ensuring that this field accurately identifies the tenant to which the process belongs; organization codes are obtained from the organization structure management system, reflecting the unique identifier of the organizational unit involved in the process; role sets are received through the permission management node, containing role information related to the process; policy identifiers are obtained through the policy management node, recording the unique identifier of the relevant policies or regulations involved in the process; version numbers are obtained through the version control node, identifying the specific version of the process or policy; and tracking numbers are received through the process tracking node, generating a unique tracking number for each process for subsequent auditing and troubleshooting.

[0035] Perform data format validation on the entry information set to generate a formatted entry information set. Verify that the process description field is in text format by matching keywords and sentence structure in the process description using regular expressions, and check if it includes necessary process step descriptions and task instructions. Check that the data content fields are in the expected data format, including JSON format validation, number format validation, and text format validation. For JSON formatted data content, parse the JSON structure and verify that the data type and nesting level of each field conform to the predefined pattern. Check the date format of the data content, verifying that the date field conforms to the yyyy-MM-dd format. For date data that does not conform to the standard format, use a date parsing algorithm to identify common date representation methods and convert them to the standard format. Verify that numeric type fields are positive integers and check that the number range is within a reasonable range. For floating-point type fields, retain the specified number of decimal places and perform rounding. Check that the release type field value belongs to the predefined release type set, which contains allowed release types such as "urgent release," "scheduled release," "temporary release," and "planned release." Release types not in the predefined set are marked as exceptions and logged. Verify that the tenant identifier field is an identifier that conforms to the UUID format. Check the length, character composition, and segmentation format of the identifier using a UUID format verification algorithm.

[0036] The policy identifier and version number are extracted from the formatted entry information set and then segmented and standardized to generate a policy set. The extracted policy identifier and version number are segmented according to specific rules, splitting the policy identifier into a prefix and a number. For example, the policy identifier "DJQT-2024-001" is split into the prefix "DJQT", the year "2024", and the number "001". The numeric and date portions of the version number are also split; the version number "v1.2.0-20240101" is split into the major version number "1", the minor version number "2", the revision number "0", and the release date "20240101". After segmentation, the data is standardized by converting the prefix to uniform uppercase letters, padding the number to a fixed number of digits, and standardizing the date format to yyyy-MM-dd. The processed policy identifier and version number constitute the policy set, and each element in the policy set contains information such as the standardized policy identifier, version number, release date, and policy category.

[0037] Based on the policy set, combined with organizational codes and role sets, the formatted entry information set undergoes standardized field naming and time format unification to generate a standardized set. The policy set is matched with relevant information in the organizational codes and role sets to determine the correct name for each field. Field naming is standardized according to the definitions in the role set, which is based on organizational structure and responsibility allocation definitions and includes attributes such as role name, role code, role level, and role permissions. Fields involving approval roles are uniformly named "Approver," fields involving task allocation are uniformly named "Responsible Person," and fields involving time limits are uniformly named "Deadline." Date fields are uniformly formatted as the standard date format yyyy-MM-dd, time fields as HH:mm:ss, and date-time fields as yyyy-MM-dd HH:mm:ss. The time format of all date fields is checked. For date-time data that does not meet the unified requirements, a time parsing algorithm is used for conversion. This algorithm can recognize various date-time representations, including timestamps, ISO-8601 format, and localized date formats, and convert them to the unified standard format. After standardizing field naming and time formats, all data is reorganized to form a standardized set. Each data item in the standardized set contains a uniformly named field, a data value in a standard format, and complete metadata information.

[0038] Each field in the standardized set is checked individually to verify whether it is a required field. The definition of required fields is based on the essential information in the policy set and the mandatory requirements in the business rules. For each required field, if it is not filled, a placeholder is used. The choice of placeholder is determined by the field type: "To be filled" is used for text fields, "-1" is used for numeric fields, "1900-01-01" is used for date fields, and false is used for boolean fields. During the required field validation process, the field is checked for null values, missing values, or invalid values. Null values ​​include null values, empty strings, and strings containing only whitespace characters. Missing values ​​mean the field does not exist in the data structure, and invalid values ​​mean the field value does not meet the data type or format requirements. When any required field is missing, it is marked as an anomaly, and the anomaly type, field name, and missing location are recorded. A placeholder is then used during placeholder processing to ensure data integrity. For required fields that have already been filled in, check whether they meet the data type and format requirements. For text fields, check whether the length is within the allowed range. For numeric fields, check whether the value is within the range. For date fields, check whether the date is within a reasonable time range.

[0039] In this embodiment, step S200 constructs a policy knowledge graph based on the policy set and the standardized parameter set. Through terminology alignment and synonym merging between policy clause nodes and field nodes, an aligned node dictionary is formed. This dictionary is then mapped according to the constraint types of requirements and fields to generate a rule interpretation plan and a requirement mapping list. Based on the rule interpretation plan and the requirement mapping list, the low-code process data is verified. A redline strategy library is generated using a rule matching algorithm, and the redline strategies are bound to the low-code process nodes to generate a strategy layer binding list. This includes the following steps B1-B5: B1: Construct a policy knowledge graph, including extracting policy clauses and essential information from the policy set as policy clause nodes; Extract field names, field types, and field values ​​from the normalized parameter set to create field nodes; By connecting policy clause nodes with field nodes, a mapping relationship between policy clauses and fields is established, forming a policy knowledge graph.

[0040] Specifically, each policy clause is identified and extracted from the policy set, containing the policy's specific content, scope of application, and requirements. The extraction of policy clauses is achieved using natural language processing technology. First, the policy document is segmented, divided hierarchically by chapters, clauses, and provisions, identifying the title and content of each clause. Then, semantic analysis is performed on the content of each clause to extract keywords and key phrases. Keywords include terms related to policy elements such as approval, authority, time limits, roles, and organizations, while key phrases include the specific requirements and constraints described in the clause. The policy clauses are then decomposed into specific clause texts and labeled with corresponding element information, including key attributes such as approval requirements, time limits, role permissions, organizational hierarchy, and data format.

[0041] For approval requirements, the approval role, approval level, and approval process are marked. For example, "requires department head approval" is parsed as "department head" as the approval role, "department level" as the approval level, and "single-level approval" as the approval process. For time-limited requirements, the deadline, processing time limit, and warning time are marked. For example, "The task should be completed within three working days" is parsed as a processing time limit of "3 days," with the time unit being "working days." Policy clause information is organized into node format, with each node containing key information such as the policy clause's title, description, applicable scope, and constraints. Policy clause nodes are stored using a graph database node structure. Node attributes include fields such as node ID, clause number, clause title, clause content, requirement type, constraints, and related policies. The extracted policy clauses and requirement information are organized into a set of policy clause nodes. Each node in this set represents an independent policy clause, and nodes are connected through relationships, which represent references, dependencies, and hierarchical relationships between clauses.

[0042] The field name record serves as the field's identifier. Field identifiers adhere to a unified naming convention, ensuring consistent names for fields with the same concept from different sources. The field type is associated with the field name, indicating the specific type of data in the field. Field types include basic data types such as string, integer, floating-point, date, boolean, and enumeration, as well as composite data types such as array, object, and JSON. Field values ​​are extracted and validated based on their type to ensure they match the field type. For string fields, the string length is validated to be within the allowed range, and illegal characters are checked. For strings requiring specific formats, such as phone numbers, email addresses, and ID numbers, regular expressions are used for format validation. For numeric fields, the value is validated to be within the specified range, and the precision and decimal places are checked to meet requirements. For enumeration fields, the field value is validated to be within a predefined list of enumeration values. For date fields, verify that the date format conforms to yyyy-MM-dd or yyyy-MM-dd-HH:mm:ss, and check that the date is within a reasonable time range, such as no earlier than the system's activation date and no later than the current date plus a reasonable future time range. Construct field nodes from the extracted field names, field types, and field values. These field nodes are also stored using the node structure of a graph database. Node attributes include node ID, field name, field type, field value, data source, update time, and verification status.

[0043] Each policy clause node is connected to a field node, representing the mapping relationship between policy clauses and fields. The connection operation is achieved by establishing edge relationships. In a graph database, edge relationships represent the association between two nodes, and the attributes of an edge include relationship type, mapping strength, and constraints. The relationship type describes the specific association method between the policy clause and the field, including types such as "requirement to exist," "value constraint," "format restriction," "role permission," and "time constraint." For example, an edge relationship of type "role permission" is established between the policy clause node "Approval Role Requirement" and the field node "Approver," representing the association between the field requirement of the approval role and a specific field.

[0044] B2: Forming an aligned node dictionary, including performing term alignment and synonym merging in the policy knowledge graph, merging different terms expressing the same concept into a unified term; The policy clause node is used to perform noun storage processing on the field node, and the names of the field node are compared with the names of the policy clause node to establish a clear correspondence and generate an aligned node dictionary.

[0045] Specifically, term matching is achieved through semantic similarity calculation. A word vector model is used to convert terms into high-dimensional vector representations. This model is built upon pre-trained language models such as Word2Vec or BERT. The input to the model is the text representation of the term, and the output is a fixed-dimensional vector representation. The cosine similarity between two term vectors is calculated using the following formula: in, and These are vector representations of the two terms, For vector dot product, and Let be the Euclidean norm of the vector. When the similarity exceeds a preset threshold, the two terms are considered to express the same concept. The preset threshold is determined based on the actual application scenario and test results, and is typically set to 0.8 or 0.85. In matching professional terms in the field of Party building and mass organizations, the threshold can be appropriately increased to ensure matching accuracy.

[0046] During the synonym merging process, standard terms are selected as unified terms. The selection criteria for standard terms include their frequency of occurrence in policy documents, their standardization, and their usage in industry standards. For the terms "responsible person," "person in charge," and "executor" in policy clause nodes, semantic similarity calculations revealed that they express the same concept; therefore, "responsible person" was selected as the unified term, and other terms were merged into "responsible person." For the terms "reviewer" and "approver" in field nodes, semantic analysis revealed that they express the same role concept in some scenarios, but subtle differences exist under strict policy requirements. Review emphasizes content inspection, while approval emphasizes authority decision-making; therefore, merging needs to be determined based on the context. A term synonym table is established, recording all merged terms and their corresponding unified terms. The synonym table uses a hash table structure for storage, with the key being the original term and the value being the unified term, supporting fast term lookup and replacement operations.

[0047] The noun matching process is implemented through name matching and semantic mapping. First, the names of the field nodes are segmented and tagged with parts of speech to extract nouns and noun phrases. Then, they are matched with the terms in the policy clause nodes. For names that match exactly, a direct correspondence is established. For names that match partially, the strength of the correspondence is determined through semantic similarity calculation. For example, the field node "task leader" is matched with the policy clause node "leader requirements," extracting the key noun "leader," confirming that they express the same concept, and establishing a correspondence. For field nodes that cannot be directly matched, their correspondence with the policy clause nodes is determined through contextual analysis and domain knowledge reasoning. For example, although the field node "completion date" does not directly match the policy clause node "time limit requirements" in name, semantic analysis reveals that "completion date" indicates the task deadline, thus corresponding to "time limit requirements."

[0048] B3: Map according to the constraint type of the requirements and fields, including mapping policy clause nodes to field nodes one-to-one and one-to-many based on the aligned node dictionary; In a one-to-one mapping, each policy clause node corresponds to a unique field node; in a one-to-many mapping, one policy clause node corresponds to multiple field nodes. Record the mapping relationships and generate a mapping table. Extract executable rules and parameter value paths from the mapping table, arrange them into a rule interpretation plan, and obtain the requirement mapping list.

[0049] Specifically, constraint types describe the specific requirements of policy clauses for fields, including existence constraints, value constraints, format constraints, range constraints, and relational constraints. Existence constraints require a specific field to exist. For example, the policy clause "All processes must specify a responsible person" corresponds to an existence constraint, requiring the field node "Responsible Person" to exist and not be empty. Value constraints restrict the specific content of field values. For example, the policy clause "The approval role must be at the department head level or above" corresponds to a value constraint, requiring the value of the field node "Approver" to be in a predefined role list. Format constraints specify the format requirements for field values. For example, the policy clause "Contact phone numbers must be 11 digits" corresponds to a format constraint, requiring the value of the field node "Contact Phone Number" to conform to an 11-digit format. Range constraints restrict the numerical or time range of field values. For example, the policy clause "Task deadlines must not exceed 30 days" corresponds to a range constraint, requiring the difference between the value of the field node "Deadline" and the current date to not exceed 30 days. Relationship constraints describe the association requirements between multiple fields. For example, the policy clause "the organizational level of the approver must be higher than or equal to the organizational level of the applicant" corresponds to a relationship constraint that requires the organizational levels of the field nodes "Approver" and "Applicant" to have a specific size relationship.

[0050] One-to-one mapping is suitable for scenarios where policy clauses explicitly specify a single field. For example, a policy clause "Approval Role" forms a one-to-one relationship with the field node "Approver," and a policy clause "Task Deadline" forms a one-to-one relationship with the field node "Deadline." The establishment of one-to-one mappings is based on the correspondence in the node dictionary, directly associating the ID of the policy clause node with the ID of the field node. The mapping relationship is stored in tuple form, containing the policy clause node ID, field node ID, mapping type, and constraints. For one-to-one mappings, the mapping type is marked as "one-to-one," and the constraints record the specific constraint type and constraint parameters corresponding to the mapping relationship. For example, in the one-to-one mapping between the policy clause node "Approval Role Requirements" and the field node "Approver," the constraint type is "Value Constraint," and the constraint parameter is "The role must be at the department head level or above."

[0051] One-to-many mapping is suitable for scenarios where policy clauses involve multiple related fields. For example, the policy clause "Task Assignment" involves the field nodes "Responsible Person," "Task Content," and "Task Time Limit," forming a one-to-many relationship. The policy clause "Approval Process" involves the field nodes "First-Level Approver," "Second-Level Approver," and "Approval Opinion," also forming a one-to-many relationship. One-to-many mapping is established through association analysis. First, all field concepts mentioned in the policy clause are identified. Then, the corresponding field nodes are searched in the node dictionary, and all related field nodes are associated with the policy clause nodes.

[0052] The mapping relationships are recorded and a mapping table is generated. The mapping table is stored using a relational database table structure. The table fields include mapping ID, policy clause node ID, field node ID list, mapping type, constraint type, constraint parameters, and creation time. The mapping table supports querying all associated field nodes by policy clause node ID, and also supports querying all associated policy clause nodes by field node ID. Indexing improves query efficiency. Each record in the mapping table represents a mapping relationship. For a one-to-one mapping, the field node ID list contains only one element; for a one-to-many mapping, the field node ID list contains multiple elements. Executable rules and parameter value paths are extracted from the mapping table. Executable rules refer to operational steps or conditional judgments that can be directly used for compliance verification. Parameter value paths refer to the paths to obtain specific field values ​​associated with the rules. For example, for the mapping relationship "Policy Clause Node" Approval Role Requirement "→ Field Node" "Approver", the extracted executable rule is "Check whether the Approver field value is in the allowed role list", and the parameter value path is "Process Data - Approver". For the mapping relationship "Policy Clause Node 'Task Assignment Requirements' → Field Node ['Responsible Person', 'Task Content', 'Task Time Limit']", the extracted executable rules include "Check if the Responsible Person field exists", "Check if the Task Content field is empty", and "Check if the Task Time Limit field value is within a reasonable range", with parameter value paths of "Process Data.Responsible Person", "Process Data.Task Content", and "Process Data.Task Time Limit", respectively.

[0053] Each rule unit in the rule interpretation plan contains attributes such as rule description, rule type, parameter list, judgment condition, and execution action. The rule description uses natural language to describe the meaning and purpose of the rule; the rule type identifies the rule's category, such as existence check, value validation, format validation, and relationship judgment. The parameter list records all parameters required for rule execution and their value paths; the judgment condition describes the rule's logical judgment expression; and the execution action specifies the action to be taken when the rule's judgment result is true or false. For example, the rule unit "Check whether the approver field value is in the allowed role list" has a rule type of "value validation," the parameter list contains "approver field value" and "allowed role list," the judgment condition is "approver field value in allowed role list," and the execution action is "pass the check if the judgment result is true, mark it as a violation if the judgment result is false." The rule interpretation plan sorts rules according to their dependencies and execution priorities to ensure that the execution order of rules conforms to logical relationships. For example, existence check rules should be executed before value validation rules because a field's value can only be validated if it exists.

[0054] The requirement mapping list is presented in tabular form. The table columns include requirement name, requirement description, corresponding fields, constraint type, constraint parameters, and rule unit ID. The requirement name identifies the specific requirement in the policy clause, such as "approval role requirement," "task time limit requirement," and "organizational level requirement." The requirement description uses natural language to describe the content and requirements of the requirement in detail. The corresponding fields list the names of all field nodes related to the requirement. The constraint type and constraint parameters describe the specific constraints the requirement places on the fields. The rule unit ID is associated with the corresponding rule unit in the rule interpretation plan and is used for subsequent rule execution.

[0055] B4: Generate a redline strategy library through rule matching algorithms, including performing existence, value validity and role constraint checks on low-code process data based on the mapping relationship between the rule interpretation plan and the requirement mapping list, and obtaining the process dataset; Based on the process dataset and the constraints in the policy clauses, a rule matching algorithm is used to verify whether the fields meet the requirements of the clauses. Mark successfully matched fields as meeting the conditions, generate corresponding redline strategies, assign a unique identifier to each redline strategy, and form a redline strategy library.

[0056] Specifically, existence verification is achieved by checking whether the process data contains fields required by the rules. For fields that the rules require to exist, the system checks whether the field name exists in the field list of the process data. If the field does not exist, the existence verification fails, and the name of the missing field and the corresponding rule unit ID are recorded. For cases where the rules require that field values ​​cannot be empty, the system further checks whether the field value is null, an empty string, or contains only whitespace characters. If the field value is empty, the existence verification also fails. The results of the existence verification include a list of fields that passed the verification and a list of fields that failed. Fields that failed the verification need to be placed as placeholders or the user needs to be prompted to supplement the missing information.

[0057] Role constraint validation involves two aspects: role permission validation and organizational hierarchy validation. Role permission validation checks whether a specified role has the authority to perform a specific operation. For example, if a policy requires that "approval operations must be performed by a role at the department head level or above," it's necessary to verify whether the "Approver" field represents a department head or higher. Role permission information is obtained from the permission management system, which maintains the mapping relationship between roles and permissions and supports querying the permission list and permission level of a specified role. Organizational hierarchy validation checks whether the organizational hierarchy to which a role belongs meets the policy requirements. For example, if a policy requires that "the approver's organizational hierarchy must be higher than or equal to the applicant's organizational hierarchy," it's necessary to query the organizational hierarchy information of "Approver" and "Applicant" and compare their hierarchical relationship. Organizational hierarchy information is obtained from the organizational structure management system, which maintains the tree structure and hierarchical relationship of organizations and supports calculating the hierarchical difference and superior-subordinate relationship between two organizational nodes.

[0058] Specifically, the rule-matching algorithm employs a conditional expression-based matching engine. This engine converts the restrictions in policy clauses into executable conditional expressions, then performs conditional checks on the field values ​​in the process dataset. These conditional expressions combine logical and comparison operators, supporting complex logical judgments. For example, the policy clause "The approval role must be at the department head level or above, and the organization must be a first-level organization" is converted into a conditional expression: (

[0059] Here, ∧ represents the logical AND operation. The rule matching algorithm traverses each field in the process dataset, obtains the field value and related attribute information, substitutes them into the conditional expression for calculation, and determines whether the field meets the requirements of the clause based on the calculation result. For fields that meet the requirements, they are marked as successfully matched; for fields that do not meet the requirements, they are marked as unsuccessfully matched, and the specific reason for the failure and the relevant clause information are recorded.

[0060] Successfully matched fields are marked as compliant, generating corresponding redline policies. Redline policies are compliance restriction rules set for specific operations or fields in low-code workflow orchestration to ensure processes comply with policy regulations. Redline policies include attributes such as policy name, policy description, applicable conditions, restriction rules, and violation handling. The policy name concisely and clearly identifies the main content of the policy, such as "Approval Role Permission Check," "Task Time Limit Control," and "Organizational Hierarchy Verification." The policy description details the policy's purpose, applicable scenarios, and specific requirements; the applicable conditions describe the prerequisites for the policy to take effect; the restriction rules describe the specific restrictions the policy places on fields or operations; and the violation handling specifies the measures to be taken when the policy is violated. For example, the redline policy "Approval Role Permission Check" has the policy description "Ensure approval operations are performed by roles with the appropriate permissions," the applicable condition is "The process contains approval nodes," the restriction rule is "The approver role must be a department head or above," and the violation handling is "Prevent process submission and prompt insufficient role permissions."

[0061] Each red-line policy is assigned a unique identifier, generated using UUID or auto-incrementing sequence number format, ensuring its uniqueness and non-repeatability within the system. This unique identifier is used for policy storage, retrieval, and referencing, allowing for quick location of specific policies in the policy library. All generated red-line policies are organized into a red-line policy library, stored using a relational database or document database, supporting queries and filtering by policy name, applicable conditions, associated policy clauses, and other dimensions.

[0062] B5: Generate a list of strategy layer bindings, including matching low-code process nodes with redline strategies in the redline strategy library and verifying whether the process node operations comply with the restrictions in the redline strategies. Bind eligible redline strategies to corresponding process nodes to generate a process orchestration interface with bound redline strategies. Perform compliance verification on the process orchestration interface that has been bound to redline policies. Check the binding status of each low-code process node with the corresponding redline policy, verify whether each low-code process node meets the constraints in the redline policy, record the low-code process nodes that do not meet the redline policy requirements as non-compliant items, and mark the reasons for non-compliance. Compile and summarize all the binding status and non-compliant items of low-code process nodes with the corresponding redline policies to generate a policy layer binding list.

[0063] Specifically, low-code process nodes are the basic building blocks in process orchestration, including start nodes, end nodes, task nodes, approval nodes, decision nodes, and sub-process nodes. Each process node contains attributes such as node type, node name, node configuration, and associated data. The node configuration describes the node's specific parameters and execution logic, while the associated data contains the field information processed by the node. Matching process nodes with red-line policies is based on node type and associated data. For approval nodes, red-line policies involving approval roles and permissions are matched; for task nodes, policies involving task allocation and time limits are matched; and for decision nodes, policies involving conditional judgments and branch selections are matched. The matching process is implemented by querying the red-line policy library. Based on the process node type and associated fields, the library retrieves applicable red-line policies that match the conditions and returns a list of matched policies. For each matched red-line policy, the configuration and associated data of the process node are verified to conform to the policy's constraints. The verification method is similar to the rule matching algorithm: the node data is substituted into the policy's constraints for conditional judgment. A true result indicates compliance with the conditions, while a false result indicates non-compliance.

[0064] Redline policies that meet the criteria are bound to the corresponding process nodes, generating a process orchestration interface with bound redline policies. Policy binding is the process of associating redline policies with process nodes. The binding information is stored in the process node's configuration data. A "Bound Policy List" field is added to the process node's configuration data, recording the identifiers and brief information of all redline policies bound to that node. The binding operation is presented visually in the process orchestration interface, with a policy binding indicator displayed on the process node icon. For example, a small red dot in the upper right corner of the node icon indicates that the node is bound to a redline policy. When a user clicks on a process node, the node details panel displays a list of bound redline policies. The list includes policy name, policy description, and restriction rules, allowing users to view the detailed content of the policies and understand the compliance requirements that the node must follow. The process orchestration interface with bound redline policies provides real-time compliance prompts. When a user configures a process node, the system automatically checks the legality of the configuration based on the bound redline policies. If the configuration does not meet the policy requirements, a warning message is displayed on the interface, pointing out the non-compliant configuration item and the corresponding policy requirements, guiding the user to make the correct configuration.

[0065] Perform compliance checks on the workflow orchestration interface that has been bound to redline policies, checking the binding status of each low-code workflow node with its corresponding redline policy. The compliance check is triggered when the workflow is saved or submitted. It iterates through all nodes in the workflow, checking the binding policy list for each node. For nodes bound to redline policies, it executes the policy's restriction rule check. The check process obtains the node's configuration data and associated field values, substitutes the data into the redline policy's restriction rules for conditional judgment, and records the judgment result and check status. The check status includes three states: "Pass," "Fail," and "Warning." "Pass" indicates that the node configuration fully complies with the redline policy requirements; "Fail" indicates that the node configuration violates the mandatory requirements of the redline policy and must be modified before saving or submitting the workflow; "Warning" indicates that the node configuration does not fully comply with the recommended requirements of the redline policy, the workflow can be saved but optimization is recommended.

[0066] Verify that each low-code process node complies with the constraints in the redline policy. For nodes that do not meet the constraints, record them as non-compliance items and indicate the reason for non-compliance. The record of non-compliance items includes information such as node identifier, node name, bound redline policy identifier, constraint description, and reason for non-compliance. The reason for non-compliance details the difference between the node configuration and the redline policy requirements, such as "the approver role is configured as 'ordinary employee,' which does not meet the redline policy's 'approval role permission check' requirement of 'department head or above.'" Annotating the reasons for non-compliance helps users quickly locate problems and understand the direction of rectification, improving the efficiency of compliance rectification.

[0067] Organize and summarize the binding status and non-compliance items of all low-code process nodes and their corresponding redline policies, generating a redline policy layer binding list. The binding list is presented in tabular form, with columns including node identifier, node name, node type, number of bound policies, compliance status, number of non-compliance items, and remarks. The compliance status summarizes the overall compliance of each node. If all bound policies of a node pass verification, the compliance status is "compliant"; if any policies fail verification, the compliance status is "non-compliant"; if only policies in the warning status exist, the compliance status is "warning". The number of non-compliance items counts the number of items in a node that do not meet the redline policy requirements, and the remarks field records additional information and rectification suggestions for the node.

[0068] In this embodiment, the generation of the rectification guidance flow in step S300 includes the following step C1: C1: Real-time red line detection is performed based on the policy layer binding list to identify violation nodes and locate the policy source, extract the complete description of the policy clauses, extract relevant clause steps from the rule interpretation plan, and generate rectification guidance flow.

[0069] Specifically, the redline policies for low-code process nodes are extracted from the redline policy layer binding list, and real-time redline detection is performed, recording the redline detection feedback. Real-time redline detection is triggered during process runtime or editing, monitoring the state changes and data updates of process nodes. When a change in node state or data is detected, the bound redline policy is immediately executed for verification. Real-time detection is implemented using an event-driven approach. The process engine publishes events when node state changes or data is updated, and the redline detection module subscribes to these events and responds accordingly. For each triggered event, the detection module obtains the identifier and updated data of the relevant node, queries the list of redline policies bound to the node, executes the policy's restriction rule verification, and determines whether the node complies with the policy requirements. Redline detection feedback records the detection time, node information, policy information, detection results, and violation details. Detection results include two states: "compliant" and "violation," and violation details describe the specific content of the violation and the fields involved.

[0070] Based on the redline detection feedback, compliance indicators and violation conditions are marked for low-code process nodes, and compared with the redline policy library to obtain violation status and violation reason data. The redline detection feedback is read, and unmet requirements are summarized according to the unique identifier of the low-code process node, generating a list of low-code process nodes to be marked. The list of low-code process nodes to be marked is traversed, and for each low-code process node, an initial compliance indicator value of compliant is generated, along with an empty table of low-code process node violation conditions. Unmet requirements in the redline detection feedback are parsed, and the names of the inspected fields and condition descriptions are extracted and written to a temporary table of low-code process node violation conditions. Using the inspected field name and condition description as search keys, a matching redline policy entry is retrieved from the redline policy library. When a redline policy entry is found, the compliance indicator of the low-code process node is updated to non-compliant, and the redline policy entry name, redline policy entry indicator, inspected field name, and condition description are merged into a low-code process node violation reason entry and written to the low-code process node violation condition table. After processing all non-compliant items, the low-code process node violation status is output as the current value of the low-code process node compliance identifier, and the low-code process node violation reason data is output as the low-code process node violation condition table.

[0071] Based on violation status and cause data, the policy source is located and a complete description of the policy clauses is extracted. Clause steps related to the low-code process nodes of the violation are extracted from the rule interpretation plan, generating a prompt flow for rectification guidance. The source of each violation node is traced based on violation status and cause data, identifying the relevant policy clauses. Through the association between strategies and policy clauses recorded in the red-line strategy library, the policy clause node corresponding to the violation strategy is traced, obtaining the node ID and basic information of the policy clause. Detailed information of the policy clause node is queried from the policy knowledge graph, including clause number, clause title, clause content, and clause requirements, extracting a complete description of the policy clause. The violation conditions of each violation node are matched with clauses in the policy set to determine the specific content of the relevant policy clauses. Based on the clause conditions and execution steps listed in the rule interpretation plan, the operational requirements related to the violation node are found. The rule interpretation plan records the correspondence between each rule unit and policy clause; by using the violation rule unit ID, the relevant clause steps are queried in the rule interpretation plan. The terms and conditions describe the specific operations and configuration methods required to meet the policy requirements. For example, for the violation "approval role does not meet the requirements", the relevant terms and conditions include "the approval role must be the department head", "the department head role needs to be selected in the approval node configuration", and "if the current user is not the department head, the approver needs to be reassigned".

[0072] The system compiles the policy sources, policy clause descriptions, and rectification steps for all violation nodes, generating a prompt flow of rectification guidelines. The rectification guidelines are stored in a structured data format. Each guidance item includes violation node information, violation reason, policy source, policy clause description, rectification steps, and rectification example. Violation node information includes a node identifier, node name, and node type; the violation reason references the description in the violation reason data; the policy source indicates the name of the relevant policy document and clause number; the policy clause description provides the complete text of the clause; the rectification steps list the specific operations required to resolve the violation; and the rectification example provides a reference for the correct configuration after rectification. The rectification guide prompt flow is sorted by the severity and scope of the violation, prioritizing high-risk violations to guide users to address key compliance issues first. The prompt flow is presented in the workflow orchestration interface as a pop-up or sidebar. Users can view detailed rectification guidelines for each violation. Clicking on a rectification step automatically redirects to the corresponding configuration interface, assisting users in quickly completing the rectification operation.

[0073] In this embodiment, step S400 involves risk assessment and tiered handling of the violation status based on the rectification guidance flow, generating a compliance score in conjunction with the rectification path, outputting a release order, and updating the policy knowledge graph and red line strategy library, including the following step D1: D1: Conduct risk assessment and graded handling of non-compliance status according to the rectification guidelines, including risk assessment of the remaining non-compliance status in the rectification plan and identification of potential risks; Based on the severity, scope of impact, and difficulty of resolution, the violation status is divided into high-risk, medium-risk, and low-risk categories, generating a tiered disposal list. The rectification plan is evaluated for compliance based on the tiered disposal list, the rectification path is recorded, and the final rectification plan is generated. The remaining violations will be rectified according to the final rectification plan, and the verified and qualified rectification results will be recorded as a list of resolved issues. Based on compliance scores and rectification paths, combined with a list of resolved issues, a release order is generated, and the policy knowledge graph and red line strategy library are updated.

[0074] Specifically, each remaining violation status in the rectification plan is assessed to identify potential risks. The risk assessment process includes analyzing the impact of each violation status, considering factors such as the severity, scope of impact, and difficulty of resolution. The severity assessment evaluates the degree of impact of the violation on process execution and policy compliance, categorized into three levels: "Severe," "Moderate," and "Minor." Severe violations directly cause the process to fail or seriously violate mandatory policy requirements, such as "lacking necessary approval nodes" or "insufficient approval role permissions leading to invalid approvals." Moderate violations affect some functions of the process or do not fully comply with policy requirements, but do not cause the process to completely fail, such as "unreasonable task time limits but still within the allowable range" or "field naming does not conform to standards but does not affect data processing."

[0075] The scope of impact is categorized into three levels: "Broad," "Medium," and "Partial." Broad-level violations affect multiple process nodes or critical shared fields, impacting users across multiple organizations or roles; for example, "a global approval role misconfiguration affects all approval nodes." Medium-level violations affect some process nodes or specific business scenarios, impacting users limited to specific organizations or roles; for example, "a department's task allocation rules do not meet requirements." Partial-level violations only affect a few process nodes or non-critical fields, impacting a smaller user base; for example, "the format of an optional field does not conform to the recommended specifications."

[0076] The difficulty of resolving violations is categorized into three levels: "Difficult," "Medium," and "Easy." Difficult violations require modifying the core logic of the process, reconfiguring complex permission relationships, or coordinating with multiple relevant departments, resulting in a longer rectification period and greater resource investment. Medium violations require adjusting some node configurations, updating field mapping relationships, or communicating and confirming with relevant personnel, with a moderate rectification period and manageable resource investment. Easy violations can be resolved through simple configuration modifications or data updates, with a shorter rectification period and less resource investment. Based on the assessment results, a comprehensive risk score is calculated for each violation status. The risk score uses a weighted calculation method, with weights allocated as follows: Severity 40%, Impact Scope 35%, and Resolution Difficulty 25%. The risk score formula is:

[0077] Among them, the severity score, the scope of impact score, and the difficulty of resolution score correspond to different levels of values: severe level 10 points, moderate level 6 points, minor level 2 points, widespread level 10 points, moderate level 6 points, local level 2 points, difficult level 10 points, moderate level 6 points, and easy level 2 points.

[0078] Specifically, based on the assessment results, each violation status is categorized into high-risk, medium-risk, and low-risk, generating a tiered handling list. Risk levels are based on a comprehensive risk score: a score of 8 or higher is high-risk, a score between 4 and 8 is medium-risk, and a score less than 4 is low-risk. High-risk violations require immediate attention, have the highest priority, and must be rectified within 24 hours. A dedicated person must be assigned to oversee the rectification process and monitor its progress. Medium-risk violations require prompt attention, have a medium priority, and must be rectified within 3 working days, following standard rectification procedures. Low-risk violations can be addressed later, have a lower priority, and must be rectified within 7 working days. They can be handled concurrently with other optimization efforts. The tiered handling list records the risk level, risk score, handling priority, rectification deadline, and responsible person assignment for each violation status. The list is sorted by risk level and risk score, with high-risk issues listed first for easy access and handling.

[0079] A compliance assessment of the rectification plan is conducted based on a tiered handling list, the rectification path is recorded, and a final rectification plan is generated. Each task in the preliminary rectification plan is checked against the handling level, approval requirements, and evidence requirements using the tiered handling list, recording the verification results as compliant or non-compliant and generating a compliance assessment conclusion. The handling level check verifies whether the risk level allocation of the inspection task is reasonable; the approval requirements check whether the inspection task requires an approval process and whether the approval role meets the requirements; and the evidence requirements check whether rectification evidence is required after the inspection task is completed, and the form and content requirements of the evidence. Tasks that do not meet the handling level, approval requirements, or evidence requirements are marked as non-compliant, and the specific non-compliance items are recorded. The compliance assessment conclusion summarizes the verification results of all tasks, counts the number of compliant and non-compliant tasks, and calculates the compliance rate. A rectification path from triggering to closure is generated based on task sequence, responsible role, approval role, and completion criteria.

[0080] Based on the compliance assessment conclusions, the task list is supplemented or deleted, and the task order and responsibility allocation are solidified, generating a final rectification plan that includes the compliance assessment conclusions and rectification paths. For tasks assessed as non-compliant, adjustments are made according to the non-compliance items, including modifying the task's handling level, adding approval steps, clarifying evidence requirements, and reassigning responsible persons. For missing critical tasks, they are added to the task list to ensure the completeness of the rectification plan. Redundant or unnecessary tasks are removed from the task list to improve rectification efficiency. Solidifying the task order ensures that tasks are executed in a reasonable logical order, such as prioritizing high-risk issues and arranging dependent tasks in the order of dependency.

[0081] According to the final rectification plan, the remaining violations will be rectified, and the verified rectification results will be recorded as a list of resolved issues. Following the task list in the final rectification plan, adjustments will be made to the field configurations, permission mappings, triggering conditions, and data verification rules related to the remaining violations. These adjustments will be performed by the responsible personnel according to the rectification steps, and the system will record the time, operator, and content of each adjustment. After each adjustment, the conditions will be verified against the red-line policy library, and the restriction rules of the red-line policy will be re-executed to verify whether the adjusted configuration meets the policy requirements. The verified rectification results will be recorded as resolved issue entries. Resolved issue entries include a unique identifier for the low-code process node, the triggered red-line policy entry identifier, the corresponding remedial measures, the rectification time, the rectification personnel, and the verification results. These will be summarized into a resolved issue list in chronological and node order. The resolved issue list provides a complete record of the rectification work for the display and audit traceability of rectification results.

[0082] Based on compliance scores and rectification paths, and combined with a list of resolved issues, a release order is generated, and the policy knowledge graph and red-line strategy library are updated. A compliance score is calculated based on the compliance assessment conclusions. The compliance score reflects the overall compliance level of the process after rectification, and the score calculation considers factors such as the number of resolved issues, the number of remaining issues, the risk level of the issues, and the timeliness of rectification. The compliance score calculation formula is:

[0083] The compliance score ranges from 0 to 100, with higher scores indicating better compliance. The compliance score is written into the release order, along with the order of tasks, responsible roles, and approval records in the rectification path. A list of resolved issues is attached as the release order's handling results. A release order containing a version identifier, scope of application, and effective conditions is generated. The version identifier uses a date plus serial number format, for example, "20240315-001" indicates version 1 released on March 15, 2024. The scope of application describes the applicable process type, organizational scope, and business scenarios. The effective conditions explain the prerequisites and timeline for the release order to take effect.

[0084] Specifically, the policy knowledge graph updates the relationship attributes and statuses for compliance relationships between policy entries and low-code process nodes. Relationship attributes include compliance status, last verification time, and violation history, while the relationship status is updated to "rectified" or "compliant." In the red-line policy library, the scope of application and description fields for revised red-line policy entries are updated, and version change information is recorded. Updates to the scope of application reflect the latest scenarios and conditions for policy application, the description field supplements the reasons for policy revision and changes, and version change information records the policy's historical versions, change times, and responsible parties. The updates to the policy knowledge graph and red-line policy library ensure the timeliness and accuracy of the knowledge base, providing the latest reference for subsequent compliance verification and forming a closed-loop management system for continuous optimization.

[0085] In summary, by extracting policy clauses and requirement information from the policy set and connecting policy clause nodes with field nodes, a graph database node structure is used to store the mapping relationship between policy clauses and fields, achieving structured expression and efficient querying of policy semantics. Through terminology alignment and synonym merging, different terms expressing the same concept are merged into a unified terminology, and policy clause nodes are used to perform noun storage processing on field nodes, eliminating semantic differences between policy documents and process data and improving mapping accuracy. By performing one-to-one and one-to-many mappings based on the constraint types of requirements and fields, a rule interpretation plan containing executable rules and parameter value paths is generated, transforming abstract policy requirements into executable verification rules. By performing existence, value legality, and role constraint checks on low-code process data, and combining the restrictions in policy clauses, a red-line strategy library is generated. The red-line strategies are then bound to low-code process nodes to generate a strategy layer binding list, enabling real-time compliance monitoring and problem localization during process orchestration.

[0086] Example 3 The above is an illustrative scheme of a knowledge graph-based low-code process verification method for Party building and mass organizations. It should be noted that the technical solution of this knowledge graph-based low-code process verification system for Party building and mass organizations belongs to the same concept as the aforementioned knowledge graph-based low-code process verification method for Party building and mass organizations. Details not described in detail in the knowledge graph-based low-code process verification system for Party building and mass organizations in this embodiment can be found in the description of the aforementioned knowledge graph-based low-code process verification method for Party building and mass organizations.

[0087] This embodiment also provides a knowledge graph-based low-code process verification system for Party building and mass organizations, including: The preprocessing module is used to receive and preprocess the ingress information set, obtain the policy set, and generate a standardized parameter set. The graph construction module is used to construct a policy knowledge graph based on the policy set and the standardized parameter set, form an aligned node dictionary, and generate a rule interpretation plan and a list of requirements mapping. The strategy verification module is used to interpret the plan and the requirement mapping list according to the rules, perform verification on the low-code process data, generate a redline strategy library and bind it, and generate a strategy layer binding list. The detection and rectification module is used to perform real-time red line detection based on the list bound to the strategy layer, identify violation nodes and generate rectification guidance flow; The closed-loop optimization module is used to conduct risk assessment and graded handling of non-compliance status based on the rectification guidelines, generate compliance scores, output release forms, and update the policy knowledge graph and red line strategy library.

[0088] This embodiment also provides an electronic device applicable to the verification of low-code processes for Party building and mass organizations based on knowledge graphs, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the method for verifying low-code processes for Party building and mass organizations based on knowledge graphs as proposed in the above embodiment.

[0089] This embodiment also provides a storage medium on which a computer program is stored. When the program is executed by a processor, it implements the knowledge graph-based low-code process verification method for Party building and mass organizations as proposed in the above embodiments.

[0090] The storage medium proposed in this embodiment and the implementation method of low-code process verification for Party building and mass organizations based on knowledge graph proposed in the above embodiments belong to the same inventive concept. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0091] Based on the above description of the implementation methods, those skilled in the art can clearly understand that the present invention can be implemented using software and necessary general-purpose hardware, and of course, it can also be implemented using hardware. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0092] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A knowledge graph-based low-code process verification method for Party building and mass organizations, characterized in that: This includes receiving and preprocessing the collection of incoming information, obtaining the policy set, and generating a standardized parameter set through unified field naming, unified time format, and mandatory field placeholder processing. Based on the policy set and the standardized parameter set, a policy knowledge graph is constructed. Through terminology alignment and synonym merging between policy clause nodes and field nodes, an aligned node dictionary is formed. The nodes are then mapped according to the constraint types of the requirements and fields to generate a rule interpretation plan and a requirement mapping list. Based on the rule interpretation plan and the requirement mapping list, the low-code process data is checked. A redline strategy library is generated through a rule matching algorithm, and the redline strategies are bound to the low-code process nodes to generate a strategy layer binding list. Real-time red line detection is performed based on the strategy layer binding list to identify violation nodes and locate policy sources, extract the complete description of policy clauses, extract relevant clause steps from the rule interpretation plan, and generate rectification guidance flow; Based on the rectification guidelines, risk assessments and tiered handling of non-compliance status are conducted. Compliance scores are generated by combining the rectification path, and release orders are output, while the policy knowledge graph and red line strategy library are updated.

2. The knowledge graph-based low-code process verification method for Party building and mass organizations as described in claim 1, characterized in that: The construction of the policy knowledge graph includes extracting policy clauses and essential information from the policy set as policy clause nodes; Extract field names, field types, and field values ​​from the normalized parameter set to create field nodes; By connecting policy clause nodes with field nodes, a mapping relationship between policy clauses and fields is established, forming a policy knowledge graph.

3. The knowledge graph-based low-code process verification method for Party building and mass organizations as described in claim 2, characterized in that: The process of forming the aligned node dictionary includes performing term alignment and synonym merging in the policy knowledge graph, merging different terms expressing the same concept into a unified term. The policy clause node is used to perform noun storage processing on the field node, and the names of the field node are compared with the names of the policy clause node to establish a clear correspondence and generate an aligned node dictionary.

4. The knowledge graph-based low-code process verification method for Party building and mass organizations as described in claim 3, characterized in that: The mapping according to the constraint type of the elements and fields includes mapping policy clause nodes to field nodes in a one-to-one and one-to-many manner based on the aligned node dictionary; In a one-to-one mapping, each policy clause node corresponds to a unique field node; In a one-to-many mapping, one policy clause node corresponds to multiple field nodes; Record the mapping relationships and generate a mapping table. Extract executable rules and parameter value paths from the mapping table, arrange them into a rule interpretation plan, and obtain the requirement mapping list.

5. The knowledge graph-based low-code process verification method for Party building and mass organizations as described in claim 4, characterized in that: The process of generating a redline strategy library through a rule matching algorithm includes performing existence, value validity, and role constraint checks on low-code process data based on the mapping relationship between the rule interpretation plan and the requirement mapping list, and obtaining the process dataset. Based on the process dataset and the constraints in the policy clauses, a rule matching algorithm is used to verify whether the fields meet the requirements of the clauses. Mark successfully matched fields as meeting the conditions, generate corresponding redline strategies, assign a unique identifier to each redline strategy, and form a redline strategy library.

6. The knowledge graph-based low-code process verification method for Party building and mass organizations as described in claim 5, characterized in that: The generated strategy layer binding list includes matching low-code process nodes with redline strategies in the redline strategy library and verifying whether the process node operations meet the restrictions in the redline strategies. Bind eligible redline strategies to corresponding process nodes to generate a process orchestration interface with bound redline strategies. Perform compliance verification on the process orchestration interface that has been bound to redline policies. Check the binding status of each low-code process node with the corresponding redline policy, verify whether each low-code process node meets the constraints in the redline policy, record the low-code process nodes that do not meet the redline policy requirements as non-compliant items, and mark the reasons for non-compliance. Compile and summarize all the binding status and non-compliant items of low-code process nodes with the corresponding redline policies to generate a policy layer binding list.

7. The knowledge graph-based low-code process verification method for Party building and mass organizations as described in claim 6, characterized in that: The risk assessment and graded handling of non-compliance status according to the rectification guidelines includes risk assessment of the remaining non-compliance status in the rectification plan and identification of potential risks; Based on the severity, scope of impact, and difficulty of resolution, the violation status is divided into high-risk, medium-risk, and low-risk categories, generating a tiered disposal list. The rectification plan is evaluated for compliance based on the tiered disposal list, the rectification path is recorded, and the final rectification plan is generated. The remaining violations will be rectified according to the final rectification plan, and the verified and qualified rectification results will be recorded as a list of resolved issues. Based on compliance scores and rectification paths, combined with a list of resolved issues, a release order is generated, and the policy knowledge graph and red line strategy library are updated.

8. A knowledge graph-based low-code process verification system for Party building and mass organizations, based on the knowledge graph-based low-code process verification method for Party building and mass organizations as described in any one of claims 1 to 7, characterized in that: It also includes a preprocessing module, which receives and preprocesses the ingress information set, obtains the policy set, and generates a standardized parameter set; The graph construction module is used to construct a policy knowledge graph based on the policy set and the standardized parameter set, form an aligned node dictionary, and generate a rule interpretation plan and a list of requirements mapping. The strategy verification module is used to interpret the plan and the requirement mapping list according to the rules, perform verification on the low-code process data, generate a redline strategy library and bind it, and generate a strategy layer binding list. The detection and rectification module is used to perform real-time red line detection based on the list bound to the strategy layer, identify violation nodes and generate rectification guidance flow; The closed-loop optimization module is used to conduct risk assessment and graded handling of non-compliance status based on the rectification guidelines, generate compliance scores, output release forms, and update the policy knowledge graph and red line strategy library.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the knowledge graph-based low-code process verification method for Party building and mass organizations as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the knowledge graph-based low-code process verification method for Party building and mass organizations as described in any one of claims 1 to 7.

Images