Intelligent process compliance checking method and system combining knowledge graph and rpa

Abstract

This invention provides an intelligent process compliance verification method and system that combines knowledge graphs and RPA, belonging to the field of enterprise business process management technology. First, it collects compliance texts and transforms them into a dynamically expandable set of compliance knowledge associations. Then, it integrates an RPA operation execution module into the business process nodes, synchronously collecting full-dimensional process operation information. Next, it establishes a real-time mapping relationship between process operation information and the compliance knowledge association set, performs multi-path logical deduction to generate a deduction result set, and finally generates hierarchical dynamic process correction instructions based on the deduction results. The RPA operation execution module then adjusts the subsequent execution actions of the business process. This invention can improve the accuracy and consistency of compliance verification, achieve real-time verification and dynamic correction, and enhance the enterprise's risk control capabilities.

Description

Technical Field

[0001] This invention relates to the field of enterprise business process management technology, and more specifically, to an intelligent process compliance verification method and system that combines knowledge graphs and RPA. Background Technology

[0002] In the daily operations of a company, the compliance of its business processes is of paramount importance. It not only concerns the company's legal risks but also directly impacts its reputation and economic benefits. Traditional methods for verifying business process compliance have many limitations.

[0003] On the one hand, current compliance verification mainly relies on manual interpretation and application of compliance documents. Compliance documents typically contain numerous complex rules and clauses, and manual interpretation is not only inefficient but also prone to misunderstandings, making it difficult to guarantee the accuracy and consistency of compliance verification. Furthermore, compliance documents are dynamic; new regulations and policies are constantly being introduced, and companies' internal compliance requirements also adjust accordingly. Manual methods struggle to update compliance knowledge in a timely and comprehensive manner, failing to adapt to the rapidly changing compliance environment.

[0004] On the other hand, traditional business process monitoring methods often only obtain partial operational information about the process, lacking the ability to collect and analyze comprehensive process operational information. This makes it impossible to fully and accurately understand the actual execution of business processes during compliance verification, making it difficult to identify potential compliance risks. Moreover, existing verification methods typically conduct post-process checks after the business process has been completed, failing to detect and correct violations in real time during process execution, meaning that violations may have already caused losses to the company. Summary of the Invention

[0005] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide an intelligent process compliance verification method combining knowledge graphs and RPA, the method comprising: Collect various compliance texts corresponding to the target business process, and transform the rule expressions in the compliance texts into a multi-level knowledge association structure through semantic parsing and logical reconstruction to form a dynamic and scalable compliance knowledge association set. The compliance knowledge association set includes rule-related entity descriptions, entity association relationships, association applicable scenarios, and rule priority identifiers. The RPA operation execution module is embedded into each node of the target business process to establish a real-time linkage mechanism between the RPA operation execution module and the process nodes. During the execution of the target business process, the RPA operation execution module synchronously collects the full-dimensional process operation information generated by each node. The process operation information includes node operation behavior, business data involved in the operation, related actions triggered by the operation, and operation environment parameters. Establish a real-time mapping relationship between process operation information and compliance knowledge association set, and through multi-dimensional feature comparison, make each process operation information unit correspond to a specific entity description, entity association relationship and associated applicable scenario in the compliance knowledge association set; The entity association relationships and rule priority identifiers in the compliance knowledge association set are invoked to perform multi-path logic deduction on the process operation information. Combined with cross-node association analysis, a set of deduction results corresponding to the process operation information is generated. The set of deduction results includes single-node deduction conclusions and cross-node association deduction conclusions. Based on the deduction conclusions of individual nodes and cross-node related deduction conclusions in the deduction result set, a hierarchical process dynamic correction instruction is generated and sent to the RPA operation execution module. The RPA operation execution module adjusts the subsequent execution actions of the target business process according to the hierarchical process dynamic correction instruction and rule priority identifier.

[0006] In another aspect, embodiments of the present invention also provide an intelligent process compliance verification system combining knowledge graphs and RPA, including a processor and a machine-readable storage medium connected to the processor. The machine-readable storage medium is used to store programs, instructions, or code, and the processor is used to run the programs, instructions, or code in the machine-readable storage medium to implement the above-described method.

[0007] Based on the above, this invention, by transforming compliance text into a dynamically scalable set of compliance knowledge associations, achieves structured and systematic management of compliance knowledge. This enables timely and accurate updates to compliance knowledge, adapting to the ever-changing compliance environment and significantly improving the accuracy and consistency of compliance verification. By embedding the RPA operation execution module into each node of the target business process and establishing a real-time linkage mechanism, it can synchronously collect full-dimensional process operation information generated by each node, establish a real-time mapping relationship between process operation information and the compliance knowledge association set, and, through multi-dimensional feature comparison and multi-path logic deduction, combined with cross-node correlation analysis, deeply explore potential compliance risks in process operation information. It generates a set of deduction results containing deduction conclusions for individual nodes and cross-node correlation deduction conclusions. Based on the deduction results, it generates hierarchical dynamic process correction instructions, and the RPA operation execution module adjusts the subsequent execution actions of the target business process according to the instructions and rule priority identifiers. This achieves real-time compliance verification and dynamic correction during business process execution, effectively preventing losses to the enterprise caused by violations and improving the compliance and operational efficiency of business processes. Attached Figure Description

[0008] Figure 1 This is a schematic diagram of the execution flow of the intelligent process compliance verification method combining knowledge graph and RPA provided in an embodiment of the present invention.

[0009] Figure 2 This is a schematic diagram of the hardware architecture of the intelligent process compliance verification system combining knowledge graph and RPA provided in an embodiment of the present invention. Detailed Implementation

[0010] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating an intelligent process compliance verification method combining knowledge graphs and RPA, provided in one embodiment of the present invention. The following is a detailed description of this intelligent process compliance verification method combining knowledge graphs and RPA.

[0011] Step S110: Collect various compliance texts corresponding to the target business process, and transform the rule expressions in the compliance texts into a multi-level knowledge association structure through semantic parsing and logical reconstruction to form a dynamic and scalable compliance knowledge association set. The compliance knowledge association set includes rule-related entity descriptions, entity association relationships, association applicable scenarios, and rule priority identifiers.

[0012] In the corporate financial reimbursement process, the first step is to systematically collect all compliant documents related to the process. These documents cover laws and regulations, industry regulatory standards, industry self-regulatory guidelines, and internal management systems. The collection process must ensure coverage of all stages of the financial reimbursement process, including pre-application, in-process approval, and post-reimbursement. After collection, the documents undergo semantic parsing, and natural language processing (NLP) technology is used to extract rule expressions. Logical restructuring transforms the extracted rule expressions into a structured knowledge association structure. This knowledge association structure is entity-centric, connecting different entities through relationships, and combining applicable scenarios and priorities to form a complete knowledge system. Dynamic scalability is reflected in the system's support for continuous updates to the knowledge association set to adapt to changes in regulations, policies, and internal corporate systems.

[0013] Step S111: Collect text data involved in the target business process, perform format standardization processing on the text data, and generate a set of compliant texts. The text data includes legal and regulatory texts, industry regulatory norms texts, industry self-regulatory guidelines texts, and enterprise internal management system texts.

[0014] Text data collection employs a multi-channel approach. Legal and regulatory texts are obtained from publicly available government websites; industry regulatory standards are collected from the official platforms of industry regulatory agencies; industry self-regulatory guidelines are provided by industry associations or extracted from their publicly published materials; and internal management system texts are retrieved from internal document management systems. For format standardization, different text formats, such as PDF, Word, and TXT, are converted to plain text using appropriate conversion tools. During conversion, non-text elements, such as images, tables, and special symbols, are removed, and the text content is cleaned, correcting typos and adding missing information to ensure accuracy and completeness. The processed texts are categorized and stored according to text type, forming a comprehensive collection of compliant texts.

[0015] Step S112: Perform sentence-by-sentence splitting on the compliant text set, splitting each compliant text into independent sentence units. Each sentence unit is split by the standard sentence-ending punctuation mark, and each sentence unit fully carries the semantic meaning of a single rule in the original compliant text.

[0016] Sentence-by-sentence segmentation is achieved through a text segmentation algorithm that uses standard sentence-ending punctuation marks (period, question mark, exclamation mark) as segmentation markers. During segmentation, the text is scanned character by character. When a sentence-ending punctuation mark is encountered, the text preceding that position is extracted as a single sentence unit. For special cases, such as sentence-ending punctuation marks within quotation marks, the algorithm uses context analysis to identify them, avoiding incorrect segmentation. After segmentation, each sentence unit is assigned a unique identifier containing information such as text source, text number, and sentence order, enabling tracking and management of sentence units. Simultaneously, a semantic integrity check is performed on each sentence unit to ensure it fully expresses the single rule semantics of the original compliant text.

[0017] Step S113: Perform semantic annotation processing on each split statement unit to obtain semantic annotation results. Based on the semantic annotation results, filter statement units that contain rule constraint expressions and remove statement units that only have descriptive and explanatory meanings but do not contain any rule constraint meanings to form a preliminary set of rule statement candidates.

[0018] Semantic annotation processing employs a deep learning-based semantic annotation model. This model first segments and tags the sentence units with words, then identifies semantic components such as subject, predicate, object, and adverbial clauses through semantic role labeling. Simultaneously, the model also identifies and marks modal words (such as "must," "must not," "should") and logical connectives (such as "if...then...", "only if...then..."). Based on the semantic annotation results, it can be determined whether the sentence unit contains rule-based constraint expressions. Rule-based constraint expressions typically have clearly defined subjects, actions, and constraints, while descriptive and explanatory statements are mainly used to explain concepts and definitions and do not contain specific constraints. By setting semantic feature thresholds, this embodiment can automatically filter out sentence units containing rule-based constraint expressions, forming a preliminary candidate set of rule-based statements.

[0019] Step S114: Use the named entity recognition model to process each statement unit in the candidate set of rule statements, identify and extract the entities in the statement unit that represent the objects directly affected by the rule constraints. The extracted entity types include business objects, specific operation behaviors, data types, time ranges and permission subjects. Mark the extracted entities as core entities.

[0020] The named entity recognition model employs an architecture combining a bidirectional long short-term memory network (LSTM) and a conditional random field (CRF). Trained on a large-scale financial corpus, this model accurately identifies various entities in financial reimbursement scenarios. When processing sentence units, the model first converts them into word vector sequences, then learns contextual features through the LSTM network, and finally outputs entity labels for each word using the CRF. For the identified entities, this embodiment categorizes them based on their semantic features into business objects (e.g., "travel expenses," "accommodation expenses"), specific operational behaviors (e.g., "reimbursement," "approval"), data types (e.g., "invoice," "itinerary"), time ranges (e.g., "business trip period," "reimbursement deadline"), and authoritative entities (e.g., "employees," "finance department"). These extracted entities are labeled as core entities, serving as the foundation for constructing a knowledge association structure.

[0021] Step S115: Perform dependency parsing and relation extraction on the statement units containing core entities, identify and extract the pre-constraints, post-dependencies, parallel collaboration requirements, prohibited association behaviors and priority ordering relationships represented by the syntactic structure between core entities, and use the extracted relation types as association attributes.

[0022] Dependency parsing analyzes sentence units using a syntactic analyzer to construct a syntactic dependency tree, revealing the dependency relationships between words. Relation extraction, based on the syntactic dependency tree and semantic features, identifies semantic relationships between core entities. For example, in the sentence "Employees need to submit a business trip application," dependency parsing reveals a subject-verb relationship between "employee" and "submit," and a verb-object relationship between "submit" and "business trip application." Therefore, the "submit" relationship between "employee" and "business trip application" is extracted, which is a precondition. For sentence units containing multiple core entities, the relationships between entities can be analyzed one by one, and classified according to the nature of the relationships into types such as preconditions, postconditions, parallel collaboration requirements, prohibited association behaviors, and priority ranking relationships. These relationship types are stored as association attributes.

[0023] Step S116: Using the extracted core entities as basic nodes, construct multi-level node association links based on the association attributes between entities. Each node association link corresponds to a complete logical structure of a rule constraint expression. The hierarchical division is based on the applicable scope and execution order of the rule constraints.

[0024] The core entities are treated as nodes, and the association attributes between entities are treated as edges, constructing an initial node association graph. Then, the node association graph is hierarchically divided according to the scope and execution order of the rule constraints. Rule constraints with broader applicability and earlier execution in the process correspond to node association links at lower levels, while rule constraints with narrower applicability and later execution in the process correspond to node association links at higher levels. For example, the rule constraint "Employees submit business trip applications" applies to all employees on business trips and is executed at the beginning of the process, therefore its node association link is at the first level; the rule constraint "Finance department reviews expense vouchers" applies to the finance department and is executed later in the process, therefore its node association link is at a higher level. Through hierarchical division, multi-level node association links are formed, with each link corresponding to a complete logical structure of a rule constraint statement.

[0025] Step S117: Add an applicable scenario identifier to each node's associated link. The applicable scenario identifier includes the specific business process node, business operation type, business scenario classification, and trigger condition combination corresponding to the rule constraint statement.

[0026] The addition of applicable scenario identifiers is based on in-depth analysis of the rule constraint statements. Specific business process nodes are determined by parsing the process steps involved in the rule constraint statements, such as "business trip application stage" and "reimbursement review stage." Business operation types are determined based on the actions in the rule constraint statements, such as "application operation," "approval operation," and "review operation." Business scenario classifications are based on the characteristics of the business scenarios to which the rule constraint statements apply, such as "domestic business trip scenarios," "international business trip scenarios," and "emergency business trip scenarios." Triggering condition combinations are the set of conditions for the rule constraint statements to take effect, obtained by extracting and combining conditional clauses in the rules, such as "when the business trip destination is overseas and the business trip duration exceeds a specific time." This information is integrated into applicable scenario identifiers and stored in association with the node's associated links.

[0027] Step S118: Calculate the similarity and conflict degree of the logical structure between the links associated with different nodes using a logical consistency algorithm; merge the links associated with nodes whose similarity reaches the first preset threshold and whose conflict degree is lower than the second preset threshold; mark and remove the links associated with nodes whose conflict degree is higher than the third preset threshold; for the links associated with nodes whose conflict degree is between the second preset threshold and the third preset threshold, adjust the association attributes or applicable scenario identifiers according to the priority of the rule source identifier or the preset conflict resolution rules to eliminate logical conflicts and obtain the merged links associated with nodes.

[0028] The logical consistency algorithm first converts node association links into logical expressions, and then calculates the similarity and conflict levels between different node association links through a logical reasoning engine. Similarity calculation is based on the structural and semantic features of the node association links, obtained by comparing the matching degree of entities, associated attributes, and applicable scenario identifiers. Conflict level calculation is obtained by checking for contradictory relationships between logical expressions (such as the contradiction between "allow" and "prohibit"). The first, second, and third preset thresholds are set according to business requirements and historical data. For node association links with a similarity reaching the first preset threshold and a conflict level below the second preset threshold, this embodiment can automatically merge them. The merged node association links contain the common entities and associated attributes of both links and integrate the applicable scenario identifiers. For node association links with a conflict level above the third preset threshold, this embodiment can mark them as conflict links and remove them. For node association links with conflict levels between the second and third preset thresholds, this embodiment can adjust the association attributes or applicable scenario identifiers based on the priority of the rule source identifier (e.g., laws and regulations are higher than industry standards, and industry standards are higher than internal enterprise systems) or preset conflict resolution rules (e.g., "take stricter constraints" or "take the latest published rules") to eliminate logical conflicts.

[0029] Step S119: Arrange the merged node association links in an orderly manner according to the standard execution order of the target business process, and add a rule source identifier to each node association link. The rule source identifier includes the compliance text type, text name, chapter number, clause number and specific page number information corresponding to the process node association link.

[0030] The standard execution sequence of the target business process is predefined using a process modeling tool. For example, the execution sequence of a financial reimbursement process is "travel application → travel approval → travel execution → reimbursement application → reimbursement review → reimbursement payment". This embodiment can arrange the merged node-related links in an orderly manner according to their execution order within the process, based on this execution sequence. The supplementation of the rule source identifier is achieved by tracing the original compliance text corresponding to the node-related link. This embodiment can find the text upon which the node-related link is based from the overall compliance text set, extracting the text type (e.g., laws and regulations, industry standards), text name, chapter number, clause number, and specific page number information. This information is then used as the rule source identifier and associated with the node-related link for storage.

[0031] Step S1110: Assign a rule priority identifier to each node's associated link based on the importance of the rule, its scope of influence, and the severity of the consequences of the violation.

[0032] The importance of a rule is determined by assessing the authority of its source and its criticality to the business process. The authority of the rule source, from highest to lowest, is: laws and regulations, industry regulatory standards, industry self-regulatory guidelines, and internal corporate management systems. The criticality of a rule to the business process is judged based on whether it directly affects core elements such as the accuracy of financial data and the security of funds. The scope of impact is determined by statistically analyzing the number of business process nodes, departments, and personnel involved in the rule constraints; the wider the scope, the greater the impact. The severity of the consequences of a violation is assessed by analyzing factors such as potential economic losses, legal risks, and reputational damage; violations that may lead to significant losses or serious risks have a higher severity. This embodiment can use a weighted scoring method to calculate the comprehensive score of each node's associated links. The weights are set according to business needs, such as 40% for importance, 30% for scope of impact, and 30% for severity of consequences. Based on the comprehensive score, the rule priority is divided into five levels, P1 to P5, with P1 being the highest priority and P5 the lowest.

[0033] Step S1111: Establish an extended interface for node association links, reserve operation channels for rule updates, additions and deletions, and integrate and encapsulate the sorted node association links, corresponding applicable scenario identifiers, rule source identifiers and rule priority identifiers to form a dynamically expandable compliance knowledge association set.

[0034] The extended interface adopts a RESTful API design, providing operation interfaces for rule updates, additions, and deletions. The rule update interface allows users to modify information such as the association attributes and applicable scenario identifiers of node-related links; the rule addition interface allows users to add new node-related links, including core entities, association attributes, and applicable scenario identifiers; the rule deletion interface allows users to remove node-related links that are no longer applicable. The interface also provides authentication and access control functions to ensure that only authorized users can perform operations. During the integration and encapsulation process, this embodiment can store the sorted node-related links, applicable scenario identifiers, rule source identifiers, and rule priority identifiers in a graph database. The graph database uses nodes to represent core entities and edges to represent association attributes, storing the applicable scenario identifier, rule source identifier, and rule priority identifier as edge attributes. Through the efficient query and traversal capabilities of the graph database, rapid access and application of the compliance knowledge association set can be achieved.

[0035] Step S120: Integrate the RPA operation execution module into each node of the target business process in an embedded manner, and establish a real-time linkage mechanism between the RPA operation execution module and the process nodes. During the execution of the target business process, the RPA operation execution module synchronously collects the full-dimensional process operation information generated by each node. The process operation information includes node operation behavior, business data involved in the operation, related actions triggered by the operation, and operation environment parameters.

[0036] Embedded integration of the RPA operation execution module is achieved by installing RPA plugins or agents in the application systems corresponding to each node of the target business process. These plugins or agents interact with the interface elements of the application system, simulating manual operations to automate the process. Real-time linkage is implemented through message queues or an event-driven architecture. When the state of a process node changes (e.g., task start, task completion), the application can send an event notification to the RPA operation execution module. Upon receiving the notification, the RPA operation execution module initiates the corresponding operation process. During process execution, the RPA operation execution module collects comprehensive process operation information through screen capture, keyboard and mouse event logging, and database queries, including node operation behaviors (e.g., clicking buttons, entering text), business data involved in the operation (e.g., reimbursement amount, invoice information), related actions triggered by the operation (e.g., sending notifications, calling interfaces), and operation environment parameters (e.g., operation time, device information, network status).

[0037] Step S121: Decompose the specific operation content, operation standards, operation sequence, operation triggering conditions and operation termination conditions of each process node in the target business process, and generate a process node decomposition list. The process node decomposition list contains the unique identification information of each node.

[0038] The breakdown of process nodes employs a process analysis approach. Through a detailed analysis of the target business process, the specific operational content of each process node is clearly defined. Operational standards are determined based on rules and constraints in compliance documents and internal management requirements, including quality requirements, time requirements, and data format requirements. The operation sequence is described using activity diagrams or flowcharts, clarifying the sequential relationship between each operation step. Operation triggering conditions include the completion status of preceding nodes, the occurrence of specific events, and the fulfillment of data conditions. Operation termination conditions include completion markers, error occurrences, and timeout conditions. Unique identification information is generated using specific coding rules, including process number and node number, ensuring the uniqueness of each node's identifier. After organizing the above information, a process node breakdown list is generated and stored in a structured data format for easy subsequent RPA configuration and process management.

[0039] Step S122: Based on the operation type, operation complexity and data processing requirements of each process node in the process node decomposition list, configure a corresponding RPA operation execution submodule for each process node.

[0040] Operation types are categorized based on the content of the operations at each process node, such as data entry, data verification, and system interaction. Operation complexity is assessed based on factors such as the number of steps, the difficulty of the operation, and whether manual judgment is required. Data processing requirements include data acquisition, data verification, data transformation, and data storage. Based on these factors, appropriate RPA operation execution submodules are selected for each process node. For example, for data entry nodes, a data entry submodule is configured, providing functions such as form filling and data import; for data verification nodes, a data verification submodule is configured, providing functions such as data validation and rule matching. The configuration of RPA operation execution submodules is completed using a visual configuration tool. Users can select the appropriate submodules according to the needs of the process nodes and set the parameters and attributes of the submodules.

[0041] Step S123: Deploy the program code or service interface of each RPA operation execution submodule in the execution environment of the corresponding process node; preset hook functions or listeners in the code of the process node application to send an activation signal containing the process node identifier and timestamp to the RPA operation execution submodule corresponding to the process node through application interface calls or message queues when the process node start event is detected.

[0042] The deployment of the RPA operation execution submodule depends on its implementation method. For script-based submodules, the script code is deployed to the application server or client device corresponding to the process node, and the execution environment is configured. For service-based submodules, the service interface is deployed to the application server, and the service access address and call parameters are configured. Hook functions or listeners are pre-defined by inserting corresponding code into the source code of the process node application. This code monitors the start events of the process node (such as page completion, button clicks, etc.). When a start event is detected, the hook function or listener generates an activation signal, which includes the process node identifier and the current timestamp. The activation signal is sent directly to the RPA operation execution submodule via the application interface call or through a message queue, ensuring that the RPA operation execution submodule can receive the activation signal in a timely manner and start the corresponding operation.

[0043] Step S124: Configure a comprehensive information collection scope for each RPA operation execution submodule. The information collection scope defines the types of node operation behaviors, business data categories, associated action types, and operation environment parameter types that the RPA operation execution submodule needs to collect.

[0044] The information collection scope is configured through configuration files or the management interface. Node operation types include mouse operations (such as clicking, double-clicking, dragging), keyboard operations (such as inputting, pressing keys), and touch operations. Business data categories include basic information (such as personnel information, department information), business document information (such as expense reports, business trip applications), and voucher information (such as invoices, itineraries). Related action types include internal system actions (such as data storage, status updates) and external system interaction actions (such as API calls, email sending). Operating environment parameter types include hardware information (such as device model, CPU, memory), software information (such as operating system version, application version), network information (such as IP address, network bandwidth), and time information (such as operation time, timestamp). Users select the information types to be collected in the configuration file or management interface according to the needs of the process nodes, and the RPA operation execution submodule collects information according to the configured information collection scope.

[0045] Step S125: After the target business process is officially launched, monitor the running status of each process node in real time, continuously obtain the operation trigger condition satisfaction status of each process node, and when it is detected that the Boolean value of all preset operation trigger conditions of a certain process node is true, trigger the hook function or listener bound to the process node, and send an activation signal to the RPA operation execution submodule corresponding to the process node. The activation signal contains the process node identifier and the current time information.

[0046] Once the target business process is officially launched, the process monitoring system begins to monitor the running status of each process node in real time. The running status includes the node's current stage (e.g., pending execution, in progress, completed), task allocation, and operation progress. The status of operation trigger conditions is obtained through periodic queries or event listening, allowing checks to verify whether all preset trigger conditions for each process node are met. For example, for the "reimbursement application review" node, trigger conditions might include "reimbursement application submitted" and "reimbursement application status is pending review." When all trigger conditions have a Boolean value of true, this embodiment can trigger the hook function or listener bound to that process node. The hook function or listener generates an activation signal containing the process node identifier (e.g., node ID) and current time information (accurate to milliseconds), and sends the activation signal to the corresponding RPA operation execution submodule to initiate the submodule's information collection and processing flow.

[0047] Step S126: After receiving the activation signal, the RPA operation execution submodule starts multiple internal acquisition components, including behavior acquisition components, data acquisition components, associated action acquisition components, and environmental parameter acquisition components. This allows the behavior acquisition components to capture all operator actions during the process node operation in real time, including mouse clicks, keyboard inputs, touchscreen actions, voice control actions, and biometric verification actions, and record the specific content of each action. The data acquisition components synchronously collect the raw data input during the process node operation, the intermediate data generated by the system, the output result data, and the data flow during data transmission. The associated action acquisition components record all associated actions triggered during the execution of the process node operation, including actions to start other associated process nodes, external system calls, data transmission, notification sending, and approval triggering actions, and record the triggering order and associated objects of each associated action. The environmental parameter acquisition components collect the operating environment parameters of the process node during runtime, including operating system type and version, network connection status, hardware device operating status, operation time interval, operation location information, and operator permission level.

[0048] Upon receiving the activation signal, the RPA operation execution submodule immediately activates its internal data acquisition components. The behavior acquisition component monitors operator actions in real time using hook or screen capture technology. For mouse clicks, it records the click location coordinates, click type (left or right), and click time; for keyboard input, it records the entered characters, input time, and key state (pressed or released); for touchscreen actions, it records the touch location, touch pressure, and touch time; for voice control actions, it records the content of the voice command, recognition result, and execution time; and for biometric verification actions, it records the verification method (fingerprint, face, iris), verification result, and verification time. The data acquisition component collects data through database queries, file reading, and API calls. Raw data includes form data entered by the operator and uploaded file data; intermediate data includes temporary data and calculation results generated during system processing; result data includes final data output from process nodes and report data; and flow data includes the path, time, and status of data transmission between different systems or modules. The associated action collection component records associated actions by listening to system events and API call logs. For actions initiated by other associated process nodes, it records the node ID and start time; for actions initiated by external systems, it records the API address, parameters, and return result; for actions initiated by data transmission, it records the data source, destination address, and data volume; for actions initiated by notification, it records the notification type, recipient, and content; and for actions initiated by approval, it records the approver, approval item, and trigger time. The environment parameter collection component collects operating environment parameters through system APIs and hardware detection tools. Operating system type and version are obtained by reading the system registry or system commands; network connection status is obtained through ping commands and network interface information; hardware device operating status, including CPU usage, memory usage, and disk space, is obtained through system performance monitoring tools; the operation time range is determined by recording the start and end times; operation location information is obtained through IP address or GPS positioning; and operator permission levels are obtained by querying user account information.

[0049] Step S127: Bind the collected node operation behavior, business data, related actions and operation environment parameters with the unique identifier information of the process node to generate the preliminary operation information unit of the process node.

[0050] The collected information undergoes initial data cleaning and format conversion to ensure consistency and integrity. Then, node operation behaviors, business data, related actions, and operational environment parameters are associated with the unique identifier of the process node (e.g., node ID). This association is achieved through foreign key relationships or key-value pairs in database tables, using the unique identifier as the primary key and other information as attributes. The resulting preliminary operational information unit is a data structure containing all collected information for that process node. This data structure can be in JSON format, XML format, or a single record in a database table. The preliminary operational information unit includes fields such as node identifier, operation behavior record, business data set, related action list, and environmental parameter set for subsequent integration and analysis.

[0051] Step S128: According to the actual execution order of the process nodes, integrate the preliminary operation information units of all process nodes to form process operation information.

[0052] The actual execution order of process nodes is obtained through the process execution log. In this embodiment, the preliminary execution information units can be sorted according to the node execution timestamps in the process execution log. During the integration process, this embodiment can chain together the various preliminary execution information units according to their execution order to form a complete sequence of process execution information. Simultaneously, an integrity check can be performed on the integrated process execution information to ensure that the preliminary execution information units of all process nodes are included and that the logical relationships between the information are correct. The integrated process execution information is stored in a structured data format, such as a table in a database or a structured file in a file system, facilitating subsequent mapping and analysis.

[0053] Step S130: Establish a real-time mapping relationship between process operation information and compliance knowledge association set. Through multi-dimensional feature comparison, make each process operation information unit correspond to a specific entity description, entity association relationship and associated applicable scenario in the compliance knowledge association set.

[0054] The establishment of real-time mapping relationships is achieved through feature extraction and feature comparison. First, feature extraction is performed on the process operation information, extracting key features from each process operation information unit, such as operational behavior features, business data features, and environmental parameter features. Then, the extracted features are compared across multiple dimensions with entity descriptions, entity relationships, and applicable scenarios in the compliance knowledge association set. The comparison process employs methods such as semantic similarity calculation and feature vector matching to determine the degree of matching between the process operation information unit and each item in the compliance knowledge association set. Based on the degree of matching, a corresponding specific entity description, entity relationship, and applicable scenario are found for each process operation information unit, thereby establishing a real-time mapping relationship.

[0055] Step S131: Divide the process operation information into independent process operation information units corresponding to each process node. Each process operation information unit contains all the collected information of that process node.

[0056] The breakdown of process execution information is based on the unique identifier of each process node. This embodiment can traverse the process execution information and assign it to the corresponding process node according to the node identifier in each information unit. The resulting independent process execution information unit contains all information collected during the execution of that process node, such as node operation behavior, business data, related actions, and operating environment parameters. Each independent process execution information unit has a unique identifier, consisting of a process number, a node number, and a timestamp, for management and tracking purposes.

[0057] Step S132: Perform feature extraction processing on each process operation information unit, extracting node operation behavior keywords, business data features, associated action identifiers, operation environment parameter features, and process node identifier information in the unit. The feature extraction adopts a multi-dimensional feature extraction algorithm.

[0058] The multi-dimensional feature extraction algorithm combines various techniques such as text feature extraction, data feature extraction, and behavioral feature extraction. For node operation behavior keywords, text segmentation and keyword extraction algorithms are used to extract representative words from the operation behavior description, such as "submit," "approval," and "review." For business data features, statistical analysis and data mining algorithms are used to extract data distribution characteristics, correlation characteristics, and anomaly characteristics, such as the range of reimbursement amounts and the distribution of invoice types. For associated action identifiers, unique identifiers are generated by encoding the descriptions of associated actions. For operational environment parameter features, key attributes of environmental parameters are extracted, such as operating system type and network connection status. Process node identification information is directly extracted from information units. The extracted features are represented in the form of feature vectors, with each feature vector containing feature values ​​across multiple dimensions.

[0059] Step S133: Extract the entity descriptions, entity relationships, and applicable scenarios of all basic nodes in the compliance knowledge association set, classify and organize them according to entity type and relationship type, and generate a structured compliance knowledge index table.

[0060] The compliance knowledge index table is generated by first extracting entity descriptions, entity relationships, and applicable scenarios for all basic nodes from the compliance knowledge association set. Then, entity descriptions are categorized by entity type (e.g., business object, operational behavior, data type), and entity relationships are categorized by relationship type (e.g., preconditions, post-dependencies). For applicable scenarios, they are categorized by scenario type (e.g., domestic business trips, international business trips). After categorization and organization, the above information is presented in a structured table format. The table columns include entity ID, entity description, entity type, relationship ID, relationship description, relationship type, applicable scenario ID, and applicable scenario description. The compliance knowledge index table is stored in a database for easy and rapid querying and retrieval.

[0061] Step S134: Compare the semantic similarity of the node operation behavior keywords in each process operation information unit with the entity descriptions in the compliance knowledge index table, use a semantic analysis algorithm to calculate the semantic fit between the two, and filter out the entity descriptions that meet the preset standard for semantic fit.

[0062] The semantic analysis algorithm employs a semantic similarity calculation method based on a pre-trained language model. First, node operation behavior keywords and entity descriptions are converted into word vectors. Then, the cosine similarity between word vectors is calculated to measure the semantic fit. A preset standard is set according to business requirements, such as a semantic fit greater than or equal to 0.8. This embodiment can iterate through the entity descriptions in the compliance knowledge index table, calculate the semantic fit between each entity description and the node operation behavior keywords, and filter out entity descriptions that meet the preset standard as candidate entity descriptions.

[0063] Step S135: Simultaneously compare the business data characteristics, associated action identifiers, and operating environment parameter characteristics in the process operation information unit with the entity descriptions in the compliance knowledge index table in multiple dimensions, evaluate the data type matching degree, action logic correlation, and environmental parameter adaptability, and jointly determine the entity descriptions and associated entity relationships corresponding to the relevant characteristics based on the evaluation results.

[0064] Data type matching assessment is achieved by comparing the data type of the business data characteristics with the data type defined in the entity description. For example, the data type of reimbursement amount is numeric, which matches the "amount" data type in the entity description. Action logic relevance assessment is achieved by analyzing whether the associated action identifier is logically consistent with the action description in the entity relationship. For example, the associated action identifier "approved" is logically related to the "approval" action in the entity relationship. Environmental parameter suitability assessment is achieved by checking whether the operating environment parameter characteristics meet the environmental requirements defined in the entity description, such as whether the operating system version meets the requirements. This embodiment can comprehensively consider the assessment results of data type matching, action logic relevance, and environmental parameter suitability, and use a weighted voting method to determine the final corresponding entity description and associated entity relationships. The weight of each assessment result is set according to its importance.

[0065] Step S136: Based on the selected entity descriptions and corresponding entity associations, construct a preliminary mapping relationship between process operation information units and compliance knowledge association sets. In the preliminary mapping relationship, determine the correspondence between each feature of the process operation information unit and the entity description and entity association.

[0066] The initial mapping relationship is constructed based on the selected entity descriptions and entity associations, associating each feature in the process operation information unit (such as node operation behavior keywords, business data features, etc.) with the entity description and entity association. For example, the operation behavior keyword "submit reimbursement application" is associated with the entity description "reimbursement application" and the entity association "submit". The initial mapping relationship is stored in the form of an association table, which contains fields such as process operation information unit ID, entity description ID, entity association ID, and feature type, clearly defining the correspondence between each feature and the entity description and entity association.

[0067] Step S137: Extract the applicable scenario identifier corresponding to the entity association relationship in the preliminary mapping relationship, match and verify the applicable scenario identifier with the process node identifier and operation environment parameters corresponding to the process operation information unit, and compare whether the two meet the preset adaptation rules.

[0068] The adaptation rules are predefined based on business scenarios and compliance requirements. For example, the "domestic business trip" in the applicable scenario identifier must match the "business trip application" in the process node identifier and the "domestic location" in the operating environment parameters. This embodiment can extract the associated applicable scenario identifiers corresponding to the entity associations in the initial mapping relationship, and then compare these identifiers with the process node identifiers and operating environment parameters in the process execution information unit. During the comparison process, this embodiment can check whether the various conditions in the applicable scenario identifier are met in the process node identifiers and operating environment parameters, such as whether the "business trip duration exceeds a specific time" in the applicable scenario identifier matches the duration calculated from the business trip start time and end time in the operating environment parameters.

[0069] Step S138: Retain the preliminary mapping relationship where the matching verification results of the applicable scenario identifier, process node identifier, and operating environment parameters are true; for the preliminary mapping relationship where the matching verification results are false, expand the semantic search range by expanding the list of synonyms and near-synonyms of entity descriptions, and adjust the weight coefficients of business data features, associated action identifiers, and operating environment parameter features in feature comparison, and re-perform feature comparison to find matching applicable scenario identifiers and corresponding entity association relationships.

[0070] For preliminary mappings with true matching results, this embodiment can retain them as part of the final mapping. For preliminary mappings with false matching results, this embodiment can first expand the list of synonyms and near-synonyms for the entity description, for example, adding the synonym "reimbursement application form" for "reimbursement form" to the list to broaden the semantic search scope. Then, the weight coefficients of business data features, associated action identifiers, and operating environment parameter features in feature comparison are adjusted, such as increasing the weight of business data features and decreasing the weight of operating environment parameter features to improve the accuracy of feature comparison. After adjustment, this embodiment can re-perform feature comparison to find applicable scenario identifiers and corresponding entity associations that match the process operation information unit.

[0071] Step S139: When a fully matching applicable scenario identifier cannot be found after multiple adjustments, the semantic expansion mechanism is activated to deduce the appropriate applicable scenario based on the core logic of entity association.

[0072] Once the semantic expansion mechanism is activated, it first analyzes the core logic of entity relationships, extracting key elements such as subject, action, condition, and result. Then, based on these key elements, it performs a semantic search within the compliance knowledge association set to find applicable scenario identifiers with similar core logic. This embodiment can deduce the most suitable applicable scenario that matches the core logic of entity relationships through logical reasoning and semantic matching. During the derivation process, the constraints and business rules of the applicable scenario can be considered to ensure the rationality and compliance of the derivation results.

[0073] Step S1310: Assign a unique mapping identifier to each process operation information unit. The mapping identifier is generated using a unique code. The mapping identifier is deeply bound to the corresponding entity description, entity association, applicable scenario identifier, and process operation information unit to generate a detailed mapping relationship table containing the mapping relationships of all process operation information units. The mapping relationship table records the mapping identifier, entity description, entity association, applicable scenario identifier, and feature comparison results corresponding to each process operation information unit.

[0074] The mapping identifier is generated using a UUID (Universally Unique Identifier) ​​to ensure that each process execution information unit has a unique mapping identifier. Deep binding is implemented through database transactions, storing the mapping identifier, entity description, entity association, applicable scenario identifier, and process execution information unit ID in the same record to ensure data consistency. The mapping relationship table contains multiple fields, such as mapping identifier, process execution information unit ID, entity description ID, entity association ID, applicable scenario identifier ID, and feature comparison results (such as semantic similarity, matching degree, etc.). This mapping relationship table is stored in a relational database for easy querying and management.

[0075] Step S140: Call the entity association relationship and rule priority identifier in the compliance knowledge association set, perform multi-path logic deduction on the process operation information, and generate a deduction result set corresponding to the process operation information by combining cross-node association analysis. The deduction result set includes single node deduction conclusions and cross-node association deduction conclusions.

[0076] The system invokes entity relationships and rule priority identifiers from the compliance knowledge association set, and performs multi-path logical deduction based on process execution information. This multi-path logical deduction employs a rule-based inference engine, analyzing process execution information based on rule constraints and priority identifiers within the entity relationships. Cross-node correlation analysis identifies the mutual influence and synergistic effects between different process nodes by analyzing their relationships. Through multi-path logical deduction and cross-node correlation analysis, it generates single-node deduction conclusions (e.g., whether the node is compliant) and cross-node correlation deduction conclusions (e.g., the synergistic compliance between multiple nodes), forming a deduction result set.

[0077] Step S141: Extract the entity association, rule priority identifier and corresponding process operation information unit corresponding to each mapping identifier, and classify and store them according to the mapping identifier.

[0078] In this embodiment, the corresponding entity association, rule priority identifier, and process execution information unit can be queried from the detailed mapping relationship table based on the mapping identifier. Then, the above information is classified according to the mapping identifier, and information belonging to the same mapping identifier is stored together. Classified storage can be implemented using methods such as folder classification, database table partitioning, or indexing to facilitate subsequent logical deduction and analysis.

[0079] Step S142: Retrieve the complete logical constraint rules corresponding to the relationship between each entity, and extract the interaction requirements, restrictions, execution order specifications and violation judgment criteria between entities in the logical constraint rules.

[0080] Complete logical constraint rules are retrieved from the compliance knowledge association set. These rules are stored in a structured form and include requirements for interaction between entities (such as "employees must submit a business trip application"), restrictions (such as "reimbursement amount shall not exceed the standard"), execution order specifications (such as "approval before reimbursement"), and violation judgment criteria (such as "failure to submit an invoice is considered a violation").

[0081] Step S143: Assign the node operation behavior, business data, related actions and operation environment parameters in each process operation information unit to the corresponding variable slots in the logical constraint rule expression structure; start the derivation engine based on the production rule engine or logic programming framework, and perform forward chain or backward chain reasoning according to the rule set defined by the logical constraint rules. During the logical derivation process, the derivation step tracking component is started synchronously. The derivation step tracking component runs synchronously with the logical derivation process in real time, capturing the specific execution status of each derivation step, including the elements involved in the derivation, the derivation logic, the derivation steps and the derivation results.

[0082] Variable slots are placeholders in the logical constraint rule representation structure, used to receive specific data from the process execution information unit. In this embodiment, node operation behaviors, business data, related actions, and operation environment parameters can be assigned values ​​according to the variable names defined in the rules and filled into the corresponding variable slots. The derivation engine performs reasoning based on the rule set. Forward chain reasoning starts from known facts and applies rules to derive conclusions; backward chain reasoning starts from the target conclusion and searches backward for facts that support the conclusion. The derivation step tracking component records each step in the reasoning process, including the rules used, participating entities, data values, reasoning logic, and intermediate results, for subsequent auditing and traceability.

[0083] Step S144: Record the changes in entity relationships corresponding to each derivation step, track the state transitions of entity relationships during the derivation process, and record the key nodes and derivation basis during the derivation process. Key nodes are the core steps that affect the derivation conclusion.

[0084] Changes in entity relationships include the establishment, termination, and modification of attributes. This embodiment can monitor changes in entity relationships in real time during the derivation process and record the state before and after the change. Key nodes are usually decision points or rule application points in the derivation process, such as "whether the reimbursement conditions are met" or "whether further review is needed." The derivation basis includes the rules, data, and facts used. This embodiment can associate and store the above information with key nodes to ensure the interpretability of the derivation conclusion.

[0085] Step S145: Perform Boolean logic comparisons between the elements involved in the key nodes marked during the derivation process and the propositions corresponding to the logical constraint rules, and output the truth value of each comparison result; based on the Boolean truth values ​​of all comparison results, mark all items whose propositions are true as conforming items and items whose propositions are false as non-conforming items.

[0086] Boolean logic comparison compares key nodes' elements (such as actual reimbursement amount and stipulated reimbursement standards) with propositions in logical constraint rules (such as "reimbursement amount ≤ stipulated standard") to determine the truth value of the propositions. Propositions that are true are marked as compliant, indicating that the process operation information meets the rule requirements; propositions that are false are marked as non-compliant, indicating that the process operation information violates the rule requirements. This embodiment can output the comparison results in the form of Boolean values ​​(true / false) and record the specific content of compliant and non-compliant items.

[0087] Step S146: For the overall derivation of each process operation information unit, generate a separate derivation conclusion. The derivation conclusion includes the fit status of the process operation information unit with the logical constraint rules, the specific content of the non-compliance items, and the rule clauses corresponding to the non-compliance items.

[0088] The compliance status includes "fully compliant," "partially compliant," and "completely non-compliant." This embodiment determines the compliance status based on the number and severity of compliant and non-compliant items. The specific content of non-compliant items includes violations of operational behaviors, business data, related actions, or environmental parameters. The corresponding rule clause specifies which rule constraint was violated, including the rule's source and number. The derived conclusions are generated in the form of a structured report for easy viewing and understanding by users.

[0089] Step S147: Fully associate each derivation conclusion with the corresponding mapping identifier, entity association, rule priority identifier, and process operation information unit to generate a complete derivation result for a single process operation information unit.

[0090] Comprehensive association is achieved through database association operations, storing the derivation conclusions, mapping identifiers, entity relationships, rule priority identifiers, and process execution information unit IDs in the same record. The complete derivation result includes all the content of the derivation conclusions, as well as related mapping information, entity relationships, rule priority identifiers, and process execution information unit data, forming a complete information package.

[0091] Step S148: Summarize and organize the simulation results of all individual process operation information units, sort them in the order of execution of process nodes to form a preliminary sequence of simulation results, and perform cross-node correlation analysis on all simulation results in the preliminary sequence of simulation results to identify the logical connections, causal relationships and mutual influences between simulation results of different process nodes.

[0092] The simulation results of all individual process operation information units are collected and sorted according to the execution order of process nodes (e.g., business trip application → approval → expense reimbursement) to form a preliminary sequence of simulation results. Cross-node correlation analysis identifies logical connections (e.g., the output of one node is the input of another), causal relationships (e.g., a violation in one node leads to an anomaly in another node), and mutual influences (e.g., coordinated violations by multiple nodes cause the overall process to fail) between nodes by analyzing the entities, rules, and data in the simulation results of different nodes.

[0093] Step S1481: Start the cross-node association analysis engine and initialize the analysis parameters, including association analysis dimensions, logical association judgment criteria, causal relationship identification rules, and mutual influence evaluation indicators.

[0094] The cross-node correlation analysis engine is a module specifically designed to analyze the relationships between process nodes. When initializing analysis parameters, correlation analysis dimensions include entity correlation, data correlation, and rule correlation. Logical correlation judgment criteria define how to determine if there are logical relationships between nodes, such as "sharing the same entity" or "data flow exists." Causal relationship identification rules are used to identify causal relationships between nodes, such as "the output of the previous node is the input of the next node" or "a violation in the previous node leads to an anomaly in the next node." Mutual influence evaluation indicators include the degree of influence and the scope of influence, used to quantify the mutual influence between nodes.

[0095] Step S1482: Load all the inference results in the preliminary sequence of inference results into the analysis queue of the cross-node correlation analysis engine according to the execution order of the process nodes.

[0096] The analysis queue is the input buffer for the cross-node correlation analysis engine, used to store the inference results to be analyzed. In this embodiment, the inference results in the preliminary sequence of inference results can be loaded into the analysis queue sequentially according to the execution order of the process nodes (such as time order), ensuring that the analysis is performed according to the actual execution process of the process.

[0097] Step S1483: Extract the key related elements from each deduction result. The key related elements include process node identifiers, core entities involved, rule clause identifiers, deduction conclusion types, and related action identifiers.

[0098] Key relational elements are important information used to analyze the relationships between nodes. Process node identifiers are used to locate nodes; core entities are the objects that nodes operate on; rule clause identifiers are the rules that nodes follow; derivation conclusion types are the compliance status of nodes; and associated action identifiers are the associated actions triggered by nodes.

[0099] Step S1484: Construct a cross-node association analysis model based on key association elements. The cross-node association analysis model includes a node association matrix, an entity association network, and a rule association graph.

[0100] The node association matrix is ​​a two-dimensional matrix, where rows and columns represent process nodes, and matrix elements represent the association strength between nodes; the entity association network is a network structure with core entities as nodes and relationships between entities as edges; the rule association graph is a graph with rule clauses as nodes and relationships between rules (such as pre- and post-relationships) as edges. The above model tools show the association relationships between nodes from different perspectives.

[0101] Step S1485: Analyze the direct correlation between the deduction results of different process nodes through the node association matrix, and identify the combination of process nodes with direct data interaction, action linkage or rule dependence.

[0102] The element values ​​in the node association matrix are calculated by analyzing the direct interactions between nodes, such as the frequency of data transmission, the number of times actions are triggered, and the degree of rule dependence. In this embodiment, a threshold for association strength can be set to filter out node combinations with strong direct associations. For example, the "business trip application node" and the "business trip approval node" have direct data interaction and rule dependence, and are therefore identified as a directly associated node combination.

[0103] Step S1486: Use the entity association network to mine the indirect association between core entities in different inference results. If two process nodes involve the same or related core entities, it is determined that there is an indirect association.

[0104] Entity association networks use graph algorithms (such as path analysis) to uncover indirect relationships between core entities. For example, the "business trip application node" involves the "business trip location" entity, and the "reimbursement application node" also involves the "business trip location" entity. Through the association of the "business trip location" entity, these two nodes are determined to have an indirect relationship. This embodiment can identify the indirect relationships between nodes by analyzing the sharing and association between entities.

[0105] Step S1487: Based on the rule association graph analysis, analyze the logical association between the rule clauses corresponding to different deduction results, and identify the pre- and post-relationships, complementary relationships or constraint relationships between the rule clauses.

[0106] In the rule association graph, rule clauses are connected by logical relationship edges, such as "Rule A is a prerequisite for Rule B", "Rule C is complementary to Rule D", and "Rule E constrains Rule F". This embodiment can identify rule-level associations by traversing the rule association graph and analyzing the logical relationships between rule clauses corresponding to different deduction results. For example, the prerequisite for the "reimbursement approval rule" is that the "business trip approval rule" has been executed. Therefore, the "business trip approval node" and the "reimbursement approval node" are logically related through the rule association graph.

[0107] Step S1488: For the inference result pairs with related relationships identified through the node association matrix, entity association network or rule association graph, determine whether there is a causal correspondence based on the execution time sequence of process nodes, data flow direction and the pre- and post-dependencies of rule clauses, and calculate the causal association strength coefficient according to the tightness of data dependency and the hierarchical depth of rule dependency.

[0108] Causality determination first examines the execution order of related nodes; the causal node must execute before the result node. Next, it analyzes the data flow, checking whether the output data of the causal node serves as the input data for the result node. Finally, it examines the pre- and post-dependencies of rule clauses, ensuring that the rule of the causal node is a precondition of the rule of the result node. The causal relationship strength coefficient is calculated by combining the tightness of data dependencies (such as the directness of data transmission) and the depth of rule dependencies (such as direct or indirect dependencies between rules). The higher the coefficient, the stronger the causal relationship.

[0109] Step S1489: For inference result pairs with causal relationships, calculate the degree of influence value based on the number of core entities associated with non-compliant items in the inference conclusion of the cause node, the rule priority identifier, and the dependency weight of the result node on the cause node; determine the scope of influence based on the number of subsequent nodes reachable in the node association matrix of the causal relationship.

[0110] The impact value is calculated by considering the severity of non-compliance of the causal node (the more core entities, the more severe the impact), rule priority (the higher the priority, the greater the impact), and the degree of dependence of the result node on the causal node (the higher the dependence weight, the greater the impact). The scope of impact is determined by analyzing the number of subsequent nodes that the causal relationship can propagate to in the node association matrix; the more nodes that propagate, the wider the scope of impact.

[0111] Step S14810: Identify cross-node chain relationships, where the chain relationship is the relationship in which the deduction result of one process node, through the transmission of intermediate nodes, has a chain effect on the deduction results of multiple subsequent process nodes.

[0112] The identification of chain relationships is achieved through path analysis algorithms. In this embodiment, a path can be found in the node association matrix or entity association network that starts from a node, passes through multiple intermediate nodes, and ultimately affects multiple subsequent nodes. For example, "business trip application not approved" leads to "reimbursement application rejected", which in turn leads to "reimbursement payment cannot be made", forming a chain relationship of "business trip application node → reimbursement application node → reimbursement payment node".

[0113] Step S14811: Classify and organize the identified logical connections, causal relationships, mutual influences and chain relationships to form cross-node association analysis results and generate a cross-node association analysis report. The cross-node association analysis report records the specific content of each type of association, the identification basis and the impact assessment results.

[0114] The system categorizes and stores different types of relationships separately, summarizing their characteristics. The cross-node relationship analysis report details the nodes involved in each relationship, the basis for the relationship (such as shared entities, rule dependencies), and the impact assessment results (such as the degree of impact and the scope of impact).

[0115] Step S149: Based on the cross-node correlation analysis results, extract the cross-node correlation inference conclusions, and determine the collaborative compliance status, chain influence relationship and overall compliance status among multiple process nodes.

[0116] Collaborative compliance status assessment evaluates the compliance of multiple nodes with the rules. For example, "approval of business trip application" and "approval of expense voucher" together constitute collaborative compliance in the business trip reimbursement process. Chain reaction analysis analyzes the impact of a violation at one node on other nodes; for example, "unapproved business trip application" leads to "rejected expense reimbursement application." Overall compliance status integrates the extrapolation results from all nodes and cross-node correlation analysis results to assess the compliance level of the entire business process, such as "overall compliance," "partial compliance," or "serious violation."

[0117] Step S1410: Integrate the deduction conclusions of a single node with the deduction conclusions of cross-node association, sort them according to the rule priority identifier, and form a set of deduction results.

[0118] The integration process merges the conclusions of individual nodes and cross-node related conclusions into a single set. Then, the conclusions are sorted according to rule priority, with conclusions corresponding to higher-priority rules appearing first. The conclusion set is presented in the form of a list or report, containing all conclusions and related information such as rule priority, node identifier, and violation content.

[0119] Step S150: Based on the deduction conclusions of individual nodes and cross-node related deduction conclusions in the deduction result set, generate hierarchical process dynamic correction instructions and send the hierarchical process dynamic correction instructions to the RPA operation execution module. The RPA operation execution module adjusts the subsequent execution actions of the target business process according to the hierarchical process dynamic correction instructions and rule priority identifiers.

[0120] Based on the conclusions in the simulation results set, this embodiment can identify process nodes and operations that need correction. Hierarchical dynamic process correction instructions are divided into different levels according to rule priority and violation severity, such as urgent correction, general correction, and suggestive correction. Each correction instruction includes the node to be corrected, the content to be corrected, the method of correction, and the execution priority. This embodiment can send the correction instructions to the RPA operation execution module, which adjusts subsequent operations according to the instructions, such as pausing the process, rolling back nodes, and supplementing data, to ensure the compliant execution of the business process.

[0121] Step S151: Perform layer-by-layer analysis on the set of deduction results, and extract the deduction conclusion of a single node, the deduction conclusion of cross-node association, the corresponding process operation information unit, the entity association relationship and the rule priority identifier from each deduction result.

[0122] The analysis proceeds layer by layer, starting from the top layer of the deduction result set and extracting each element of the deduction result sequentially. Individual node deduction conclusions include the node's compliance status and non-compliance items; cross-node related deduction conclusions include collaborative compliance status and chain reaction relationships; process operation information units contain node operational behaviors and business data; entity relationships and rule priority identifiers are used to determine the basis and priority of corrections. The analysis process separates the above information from the deduction result set for subsequent processing and analysis.

[0123] Step S152: Traverse the set of deduction results, filter out deduction results marked with non-compliance items in the deduction conclusion of a single node or the deduction conclusion of cross-node association, determine them as target deduction results, and extract the process operation information unit, the process node to which the target deduction result belongs, the specific operation content and the associated rule clauses corresponding to the target deduction result.

[0124] The simulation results set is traversed, and each simulation result is checked to see if it contains a non-compliance marker. For a target simulation result marked with a non-compliance marker, this embodiment can extract its corresponding process operation information unit (such as the operation data of the node), the process node to which it belongs (such as the reimbursement review node), the specific operation content (such as the review not being passed), and the associated rule clauses (such as the violated reimbursement standard clauses).

[0125] Step S153: Retrieve the entity association relationships and complete logical constraint rules associated with the process nodes corresponding to the target deduction results, and extract the standard operation content, business data specifications, associated action processes and operation environment parameter standards that conform to the requirements of the logical constraint rules.

[0126] In this embodiment, the corresponding entity relationships and complete logical constraint rules can be retrieved from the compliance knowledge association set based on the process node to which the target deduction result belongs. Then, according to the requirements of the logical constraint rules, standard operation content (such as correct review steps), business data specifications (such as data format and value range), related action processes (such as correct approval processes), and standard operating environment parameters (such as required system configuration) that conform to the rules are extracted. The above standard information serves as the benchmark for formulating corrective measures.

[0127] Step S154: Compare the operation content, business data, related actions and operation environment parameters in the process operation information unit corresponding to the target deduction result with the found standard operation content, business data specifications, related action processes and operation environment parameter standards, identify inconsistent fields and values, and classify and mark the inconsistent types based on the preset root cause classification rules.

[0128] Matching and comparison are performed by comparing each field one by one, comparing the actual operation content and business data with standard information to identify inconsistent fields and values. For example, the actual reimbursement amount may not match the standard amount, or an operation step may be omitted. Root cause classification rules categorize inconsistencies based on their characteristics, such as data errors, operational mistakes, or process defects, and mark each type of inconsistency to facilitate the development of targeted corrective measures.

[0129] Step S155: Based on the specific content of the differences and the root cause of the classification, combined with the rule priority identifier, construct targeted hierarchical correction measures. The hierarchical correction measures are divided into multiple correction schemes according to the rule priority. Each correction scheme includes an operational behavior adjustment scheme, a business data supplementation or correction scheme, a related action optimization scheme, and an operational environment parameter adjustment scheme.

[0130] Tiered corrective measures determine the urgency and importance of corrections based on rule priority indicators, with higher-priority rules addressing discrepancies first. Operational behavior adjustment plans address inconsistencies in operational content, such as supplementing missing operational steps; business data supplementation or correction plans address data inconsistencies, such as correcting incorrect amounts or supplementing missing invoice information; related action optimization plans address inconsistencies in related actions, such as adjusting approval processes; and operational environment parameter adjustment plans address inconsistencies in environmental parameters, such as updating system configurations. Each corrective plan is specific, clear, and actionable.

[0131] Step S156: Decompose each graded correction scheme into specific and executable detailed execution steps. Each execution step specifies the operation object, operation method, operation sequence, operation time requirements, and operation result standards.

[0132] Detailed execution steps are the specific steps for implementing the corrective action plan. The target of the correction is clearly defined (e.g., a specific data field or operation button); the method of correction specifies how to perform the correction (e.g., filling in, modifying, deleting); the order of operations clarifies the sequential relationship between the steps; the time limit for completing the correction is specified; and the standard for the result specifies the state that should be achieved after the correction (e.g., data conforms to specifications, operation steps are complete). Detailed execution steps ensure that the corrective measures are accurately implemented.

[0133] Step S157: Match the corresponding process node for each execution step, and determine the specific execution timing for each corrective measure by combining the overall execution progress and logical sequence of the target business process.

[0134] The matching of execution steps with process nodes is determined based on the stage to which the correction content belongs; for example, the data correction step matches the reimbursement application node. The timing of execution considers the overall progress and logical sequence of the business process, such as performing real-time corrections before the current node is completed, or performing pre-emptive corrections before subsequent nodes begin. This embodiment can dynamically determine the optimal execution time based on the process's execution status and the priority of the correction measures.

[0135] Step S158: Integrate the execution steps, operation objects, operation methods, execution order, execution timing and rule priority identifiers corresponding to each hierarchical correction scheme to generate preliminary hierarchical process dynamic correction instructions. The instructions include the corresponding deduction result identifier, process node identifier and correction priority identifier.

[0136] The integration process combines the various elements of the revised plan into a structured instruction format. Deduction result identifiers are linked to specific deduction conclusions, process node identifiers indicate the target nodes for revision, and revision priority identifiers determine the execution order of the instructions. The initial hierarchical dynamic process revision instructions are generated in formats such as JSON or XML, facilitating parsing and execution by the RPA operation execution module.

[0137] Step S159: Standardize the format of the initial hierarchical process dynamic correction command, and send the standardized hierarchical process dynamic correction command to the RPA operation execution module. After receiving the hierarchical process dynamic correction command, the RPA operation execution module sends back a reception confirmation signal.

[0138] Standardized formatting ensures that commands are formatted uniformly, complete in content, and semantically clear, conforming to the interface specifications of the RPA operation execution module. Standardized commands are sent to the RPA operation execution module via a network interface or message queue. Upon receiving the command, the RPA operation execution module parses and verifies it, then sends a reception confirmation signal to the system to acknowledge successful command reception.

[0139] Step S1510: When a fully matching applicable scenario identifier cannot be found after multiple adjustments, the semantic extension mechanism is activated to deduce the appropriate applicable scenario based on the core logic of entity association.

[0140] The semantic expansion mechanism is activated when no matching applicable scenario identifier is found after a preset number of adjustments (e.g., three). Once activated, this embodiment first locks the currently unmatched process execution information units and their corresponding entity relationships to prevent interference from other operations. Then, it deeply analyzes the core logic of the entity relationships, extracting key elements such as the subject, action, condition, and result; these elements constitute the core semantics of the rule.

[0141] Step S1510-1: When the initial mapping relationship still cannot find a fully matching applicable scenario identifier after K or more adjustments, the semantic expansion mechanism is automatically triggered. After the semantic expansion mechanism is activated, the currently unmatched process running information unit and its corresponding entity association relationship are locked.

[0142] The number of adjustments (K) is set according to business needs, such as K=3. If the system fails to find a matching applicable scenario identifier after K feature comparisons and adjustments (such as expanding synonyms or adjusting weights), the semantic expansion mechanism is automatically triggered. The locking operation is implemented by setting status flags to ensure that the information units and entity relationships in the current process are not modified or deleted during the derivation process.

[0143] Step S1510-2: Extract the core logical elements of the entity relationship. The core logical elements include the core constraint relationship between entities, key operational requirements, core data types, and basic applicable conditions.

[0144] Core constraints are the basic relationships that entities must satisfy, such as "employees must submit invoices"; key operational requirements are specific regulations on operational behaviors, such as "invoices must be genuine and valid"; core data types are the basic types of business data, such as "invoice amount is numeric"; basic applicability conditions are the basic premises for the application of rules, such as "applicable to domestic business trips". The above core logical elements are extracted through semantic analysis of entity relationships.

[0145] Step S1510-3: Construct a semantic extension model based on core logical elements. The semantic extension model includes a core logical element extraction module, a scene similarity calculation module, a scene derivation module, and a scene verification module.

[0146] The core logic element extraction module is responsible for extracting core logic elements from entity relationships; the scene similarity calculation module is used to calculate the similarity between the core logic elements and the applicable scenes; the scene derivation module derives suitable applicable scenes based on similarity and logical reasoning; and the scene verification module is used to verify the rationality and compliance of the derivation results. The semantic extension model adopts a modular design, which facilitates maintenance and upgrades.

[0147] Step S1510-4: Retrieve all existing applicable scenario identifiers and their corresponding scenario description information from the applicable scenario library of the compliance knowledge association set. The scenario description information includes the process node characteristics, operation behavior characteristics, environmental parameter characteristics, and business objective characteristics corresponding to the scenario.

[0148] The applicable scenario library is a database that stores information on all applicable scenarios. The scenario description information details the various characteristics of the applicable scenario. Process node characteristics indicate the process nodes to which the scenario applies; operation behavior characteristics describe the operation requirements in the scenario; environmental parameter characteristics specify the environmental conditions of the scenario; and business objective characteristics clarify the business purpose of the scenario.

[0149] Step S1510-5: Calculate the scene similarity between the core logical elements of the entity relationship and the scene description information of each applicable scenario, and select the applicable scenarios whose scene similarity reaches the preset derivation threshold as candidate adaptation scenarios. The candidate adaptation scenarios are sorted according to the similarity level.

[0150] Scene similarity calculation employs a comprehensive scoring method, comparing and scoring various features of the core logical elements and scene description information, such as the matching degree of core constraint relationships and the compliance of key operational requirements. Preset derivation thresholds are set based on experience, such as a similarity score greater than or equal to 0.7. The selected candidate suitable scenes are sorted from high to low similarity scores for easier subsequent selection and verification.

[0151] Step S1510-6: Convert the scene description information of each candidate adaptation scenario into a logical constraint subgraph, calculate the subgraph isomorphic matching degree between the logical constraint subgraph and the logical constraint main graph corresponding to the current entity association relationship, and determine whether the constraint conditions in the logical constraint subgraph meet the necessary constraint set required for rule execution in the logical constraint main graph; mark the candidate adaptation scenarios with a subgraph isomorphic matching degree higher than the preset threshold and meeting the necessary constraint set as logical adaptations.

[0152] The logical constraint subgraph and main graph represent logical constraint relationships using a graph structure, where nodes represent entities and edges represent associations. The subgraph isomorphic matching degree is calculated by comparing the structural similarity between the subgraph and the main graph, with a preset threshold such as 0.8. The necessary constraint set consists of core constraints that must be satisfied for rule execution, such as "valid credentials must be provided." This embodiment can check whether the logical constraint subgraph of a candidate adaptation scenario satisfies the necessary constraint set of the main graph, and mark scenarios that simultaneously satisfy both the subgraph isomorphic matching degree and the necessary constraint set as logically adapted.

[0153] Step S1510-7: From the candidate adaptation scenarios marked as logical adaptations, select the scenario with the highest subgraph isomorphic matching degree and the highest cosine similarity with the operation environment parameters and business target feature vector of the current process running information unit, and determine it as the adaptation scenario. If there are multiple adaptation scenarios, further filtering is carried out in combination with the operation environment parameters and business targets of the process running information unit. The derived adaptation scenario is used as the applicable scenario identifier of the current entity association relationship, and a mapping relationship is established with the process running information unit.

[0154] The cosine similarity of feature vectors is used to measure the degree of matching between operational environment parameters and business objective features and candidate suitable scenarios. In this embodiment, the scenario with the highest subgraph isomorphic matching degree can be selected first, and then the scenario with the highest feature vector cosine similarity can be selected as the suitable scenario among these scenarios. If there are multiple scenarios with the same similarity, further manual or automatic screening is performed in combination with operational environment parameters and business objectives to finally determine a unique suitable scenario and establish a mapping relationship with the process operation information unit.

[0155] Step S1510-8: Record the execution process of the semantic expansion mechanism, including the core logic element extraction results, candidate adaptation scenarios, derivation process, verification results, and the finally determined adaptation scenarios, and form a semantic expansion report.

[0156] The semantic expansion report details each step of the semantic expansion mechanism, including the extracted core logical elements, a list of candidate adaptation scenarios and similarity scores, the rules and algorithms used in the derivation process, verification results (such as subgraph isomorphic matching degree and satisfaction of necessary constraint sets), and the finally determined adaptation scenarios. This semantic expansion report is used to audit, trace, and optimize the semantic expansion mechanism, ensuring the interpretability and reliability of the derivation results.

[0157] Figure 2 The hardware structure schematic of the intelligent process compliance verification system 100 combining knowledge graph and RPA provided in an embodiment of the present invention is shown, as follows: Figure 2 As shown, the intelligent process compliance verification system 100 combining knowledge graph and RPA may include a processor 110, a machine-readable storage medium 120, a bus 130, and a communication unit 140.

[0158] Machine-readable storage medium 120 can store data and / or instructions. In some embodiments, machine-readable storage medium 120 can store data acquired from an external terminal. In some embodiments, machine-readable storage medium 120 can store data and / or instructions used by the intelligent process compliance verification system 100 combining knowledge graphs and RPA to execute or use in order to complete the exemplary methods described in this invention. In a specific implementation, one or more processors 110 execute the computer-executable instructions stored in machine-readable storage medium 120, enabling processor 110 to execute the intelligent process compliance verification method combining knowledge graphs and RPA as described in the above method embodiments. Processor 110, machine-readable storage medium 120, and communication unit 140 are connected via bus 130, and processor 110 can be used to control the sending and receiving actions of communication unit 140. The specific implementation process of processor 110 can be found in the various method embodiments executed by the intelligent process compliance verification system 100 combining knowledge graphs and RPA described above, and their implementation principles and technical effects are similar, so they will not be repeated here.

[0159] Furthermore, embodiments of the present invention also provide a readable storage medium containing computer-executable instructions. When the processor executes the computer-executable instructions, the above-mentioned intelligent process compliance verification method combining knowledge graphs and RPA is implemented.

[0160] It should be noted that, in order to simplify the description of this invention and thus aid in the understanding of one or more embodiments, the foregoing description of the embodiments of this invention sometimes combines multiple features into a single embodiment, drawing, or description thereof. Similarly, it should be noted that, in order to simplify the description of this invention and thus aid in the understanding of one or more embodiments, the foregoing description of the embodiments of this invention sometimes combines multiple features into a single embodiment, drawing, or description thereof.

Claims

1. A method for intelligent process compliance verification combining knowledge graphs and RPA, characterized in that, The method includes: Collect various compliance texts corresponding to the target business process, and transform the rule expressions in the compliance texts into a multi-level knowledge association structure through semantic parsing and logical reconstruction to form a dynamic and scalable compliance knowledge association set. The compliance knowledge association set includes rule-related entity descriptions, entity association relationships, association applicable scenarios, and rule priority identifiers. The RPA operation execution module is embedded into each node of the target business process to establish a real-time linkage mechanism between the RPA operation execution module and the process nodes. During the execution of the target business process, the RPA operation execution module synchronously collects the full-dimensional process operation information generated by each node. The process operation information includes node operation behavior, business data involved in the operation, related actions triggered by the operation, and operation environment parameters. Establish a real-time mapping relationship between process operation information and compliance knowledge association set, and through multi-dimensional feature comparison, make each process operation information unit correspond to a specific entity description, entity association relationship and associated applicable scenario in the compliance knowledge association set; The entity association relationships and rule priority identifiers in the compliance knowledge association set are invoked to perform multi-path logic deduction on the process operation information. Combined with cross-node association analysis, a set of deduction results corresponding to the process operation information is generated. The set of deduction results includes single-node deduction conclusions and cross-node association deduction conclusions. Based on the deduction conclusions of individual nodes and cross-node related deduction conclusions in the deduction result set, a hierarchical process dynamic correction instruction is generated and sent to the RPA operation execution module. The RPA operation execution module adjusts the subsequent execution actions of the target business process according to the hierarchical process dynamic correction instruction and rule priority identifier.

2. The intelligent process compliance verification method combining knowledge graphs and RPA according to claim 1, characterized in that, The collection of various compliance texts corresponding to the target business processes involves semantic parsing and logical reconstruction to transform the rule expressions in the compliance texts into a multi-level knowledge association structure, forming a dynamically expandable compliance knowledge association set, including: Collect text data involved in the target business process, standardize the format of the text data, and generate a set of compliant texts. The text data includes legal and regulatory texts, industry regulatory norms texts, industry self-regulatory guidelines texts, and enterprise internal management system texts. The compliance text set is split sentence by sentence, and each compliance text is divided into independent sentence units. The standard sentence-end punctuation mark is used as the split boundary for each sentence unit. Each sentence unit fully carries the single rule semantics in the original compliance text. Semantic annotation is performed on each of the split statement units to obtain semantic annotation results. Based on the semantic annotation results, statement units containing rule constraint expressions are selected, and statement units that only have descriptive and explanatory meanings but do not contain any rule constraint meanings are eliminated to form a preliminary set of rule statement candidates. The named entity recognition model is used to process each statement unit in the candidate set of rule statements, identify and extract the entities in the statement unit that represent the objects directly affected by the rule constraints. The extracted entity types include business objects, specific operation behaviors, data types, time ranges and permission subjects. The extracted entities are marked as core entities. Dependency parsing and relation extraction are performed on statement units containing core entities. Preconditions, postdependencies, parallel collaboration requirements, prohibited association behaviors, and priority ordering relationships represented by the syntactic structure between core entities are identified and extracted. The extracted relation types are used as association attributes. Using the extracted core entities as basic nodes, multi-level node association links are constructed based on the association attributes between entities. Each node association link corresponds to a complete logical structure of a rule constraint expression. The hierarchical division is based on the applicable scope and execution order of the rule constraints. Add an applicable scenario identifier to each node's associated link. The applicable scenario identifier includes the specific business process node, business operation type, business scenario classification, and combination of triggering conditions corresponding to the rule constraint statement. The similarity and conflict degree of the logical structure between the links of different nodes are calculated by the logical consistency algorithm; the links of nodes whose similarity reaches the first preset threshold and whose conflict degree is lower than the second preset threshold are merged; the links of nodes whose conflict degree is higher than the third preset threshold are marked and removed; for the links of nodes whose conflict degree is between the second preset threshold and the third preset threshold, the association attributes or applicable scenario identifiers are adjusted according to the priority of the rule source identifier or the preset conflict resolution rules to eliminate logical conflicts and obtain the merged links of nodes. According to the standard execution order of the target business process, the merged node association links are arranged in an orderly manner, and a rule source identifier is added to each node association link. The rule source identifier includes the compliance text type, text name, chapter number, clause number and specific page number information corresponding to the process node association link. Based on the importance of the rules, their scope of impact, and the severity of the consequences of violations, a rule priority identifier is assigned to each node's associated link. Establish an extended interface for node association links, reserve operation channels for rule updates, additions, and deletions, and integrate and encapsulate the sorted node association links, corresponding applicable scenario identifiers, rule source identifiers, and rule priority identifiers to form a dynamically scalable compliance knowledge association set.

3. The intelligent process compliance verification method combining knowledge graphs and RPA according to claim 1, characterized in that, The RPA operation execution module is embedded into each node of the target business process, establishing a real-time linkage mechanism between the RPA operation execution module and the process nodes. During the execution of the target business process, the RPA operation execution module synchronously collects full-dimensional process operation information generated by each node, including: The specific operation content, operation standards, operation sequence, operation triggering conditions, and operation termination conditions of each process node in the target business process are broken down to generate a process node breakdown list, which contains unique identification information for each node. Based on the operation type, operation complexity, and data processing requirements of each process node in the process node breakdown list, configure a corresponding RPA operation execution submodule for each process node; Deploy the program code or service interface of each RPA operation execution submodule in the execution environment of the corresponding process node; pre-set hook functions or listeners in the code of the process node application to send an activation signal containing the process node identifier and timestamp to the corresponding RPA operation execution submodule through application interface calls or message queues when the process node start event is detected. Configure a comprehensive information collection scope for each RPA operation execution submodule. The information collection scope defines the types of node operation behaviors, business data categories, related action types, and operation environment parameter types that the RPA operation execution submodule needs to collect. After the target business process is officially launched, the running status of each process node is monitored in real time, and the operation trigger conditions of each process node are continuously obtained. When it is detected that the Boolean values ​​of all preset operation trigger conditions of a certain process node are true, the hook function or listener bound to the process node is triggered, and an activation signal is sent to the RPA operation execution submodule corresponding to the process node. The activation signal contains the process node identifier and the current time information. After receiving the activation signal, the RPA operation execution submodule activates multiple internal acquisition components, including behavior acquisition, data acquisition, associated action acquisition, and environmental parameter acquisition components. The behavior acquisition component captures all operator actions during the process node operation in real time, including mouse clicks, keyboard input, touchscreen touch, voice control, and biometric verification, recording the specific content of each action. The data acquisition component simultaneously collects the raw input data, system-generated intermediate data, output results, and data flow during data transmission at the process node operation. The associated action acquisition component records all associated actions triggered during the process node operation, including actions to start other associated process nodes, external system calls, data transmission, notification sending, and approval triggering, recording the triggering order and associated objects of each action. The environmental parameter acquisition component collects the operating environment parameters of the process node, including operating system type and version, network connection status, hardware device operating status, operation time range, operation location information, and operator permission level. The collected node operation behaviors, business data, related actions, and operating environment parameters are bound to the unique identifier information of the process node to generate a preliminary operation information unit for that process node. According to the actual execution order of the process nodes, the preliminary operation information units of all process nodes are integrated to form process operation information.

4. The intelligent process compliance verification method combining knowledge graph and RPA according to claim 1, characterized in that, The establishment of a real-time mapping relationship between process operation information and compliance knowledge association set involves multi-dimensional feature comparison to ensure that each process operation information unit corresponds to a specific entity description, entity association relationship, and applicable scenario in the compliance knowledge association set, including: The process operation information is divided into independent process operation information units corresponding to each process node, and each process operation information unit contains all the collected information of that process node. For each process operation information unit, feature extraction processing is performed to extract node operation behavior keywords, business data features, related action identifiers, operation environment parameter features, and process node identifier information in the unit. Multi-dimensional feature extraction algorithm is used for feature extraction. Extract the entity descriptions, entity relationships, and applicable scenarios of all basic nodes in the compliance knowledge association set, classify and organize them according to entity type and relationship type, and generate a structured compliance knowledge index table; The keywords of node operation behavior in each process operation information unit are compared with the entity descriptions in the compliance knowledge index table. The semantic similarity is calculated by using a semantic analysis algorithm to calculate the semantic fit between the two and the entity descriptions that meet the preset standard are selected. Simultaneously, the business data characteristics, associated action identifiers, and operating environment parameter characteristics in the process operation information unit are compared with the entity descriptions in the compliance knowledge index table in multiple dimensions. The data type matching degree, action logic correlation, and environmental parameter adaptability are evaluated respectively. Based on the evaluation results, the entity descriptions corresponding to the relevant characteristics and the associated entity relationships are jointly determined. Based on the selected entity descriptions and corresponding entity relationships, a preliminary mapping relationship between process operation information units and compliance knowledge association sets is constructed. The preliminary mapping relationship determines the correspondence between each feature of the process operation information unit and the entity description and entity relationship. Extract the applicable scenario identifiers corresponding to the entity associations in the initial mapping relationship, match and verify the applicable scenario identifiers with the process node identifiers and operating environment parameters corresponding to the process running information units, and compare whether the two conform to the preset adaptation rules. Preliminary mapping relationships where the matching verification results of applicable scenario identifiers, process node identifiers, and operating environment parameters are true are retained; for preliminary mapping relationships where the matching verification results are false, the semantic search scope is expanded by extending the list of synonyms and near-synonyms of entity descriptions, and the weight coefficients of business data features, associated action identifiers, and operating environment parameter features in feature comparison are adjusted, and feature comparison is re-performed to find matching applicable scenario identifiers and corresponding entity association relationships. When a perfectly matching applicable scenario identifier cannot be found after multiple adjustments, the semantic expansion mechanism is activated to deduce the appropriate applicable scenario based on the core logic of entity association. Each process operation information unit is assigned a unique mapping identifier, which is generated using a unique code. The mapping identifier is deeply bound to the corresponding entity description, entity association, applicable scenario identifier, and process operation information unit, generating a detailed mapping relationship table containing the mapping relationships of all process operation information units. The mapping relationship table records the mapping identifier, entity description, entity association, applicable scenario identifier, and feature comparison results corresponding to each process operation information unit.

5. The intelligent process compliance verification method combining knowledge graph and RPA according to claim 1, characterized in that, The entity relationships and rule priority identifiers in the compliance knowledge association set are invoked to perform multi-path logical deduction of process operation information, and a set of deduction results corresponding to the process operation information is generated by combining cross-node association analysis, including: Extract the entity association, rule priority identifier, and corresponding process operation information unit corresponding to each mapping identifier, and classify and store them according to the mapping identifier; Retrieve the complete logical constraint rules corresponding to the relationship between each entity, and extract the interaction requirements, restrictions, execution order specifications and violation judgment criteria between entities in the logical constraint rules; Assign the node operation behaviors, business data, related actions, and operation environment parameters in each process operation information unit to the corresponding variable slots in the logical constraint rule expression structure; start the derivation engine based on the production rule engine or logic programming framework, and perform forward chain or backward chain reasoning according to the rule set defined by the logical constraint rules. During the logical derivation process, the derivation step tracking component is started synchronously. This derivation step tracking component runs synchronously with the logical derivation process in real time, capturing the specific execution status of each derivation step, including the elements involved in the derivation, the derivation logic, the derivation steps, and the derivation results. Record the changes in entity relationships corresponding to each derivation step, track the state transitions of entity relationships during the derivation process, and record the key nodes and derivation basis during the derivation process. Key nodes are the core steps that affect the derivation conclusion. The key nodes marked in the derivation process are compared with the propositions of the corresponding clauses of the logical constraint rules using Boolean logic, and the truth value of each comparison result is output. Based on the Boolean truth values ​​of all comparison results, all items with true propositions are marked as conforming items, and items with false propositions are marked as non-conforming items. For each process operation information unit, a separate derivation conclusion is generated based on the overall derivation. The derivation conclusion includes the fit status of the process operation information unit with the logical constraint rules, the specific content of the non-compliance items, and the rule clauses corresponding to the non-compliance items. Each derivation conclusion is fully associated with its corresponding mapping identifier, entity relationship, rule priority identifier, and process operation information unit to generate a complete derivation result for a single process operation information unit. The simulation results of all individual process operation information units are summarized and sorted, and initially sorted according to the execution order of process nodes to form a preliminary sequence of simulation results. Cross-node correlation analysis is performed on all simulation results in the preliminary sequence of simulation results to identify the logical connections, causal relationships and mutual influences between simulation results of different process nodes. Based on the cross-node correlation analysis results, cross-node correlation inference conclusions are extracted to determine the collaborative compliance status, chain influence relationship and overall compliance status among multiple process nodes; The inference conclusions of a single node are integrated with the inference conclusions of cross-node associations, and sorted according to the priority of the rules to form a set of inference results.

6. The intelligent process compliance verification method combining knowledge graph and RPA according to claim 1, characterized in that, The step of generating hierarchical dynamic process correction instructions based on the deduction conclusions of individual nodes and cross-node correlation deduction conclusions in the deduction result set, and sending the hierarchical dynamic process correction instructions to the RPA operation execution module includes: The set of simulation results is analyzed layer by layer to extract the individual node simulation conclusion, cross-node associated simulation conclusion, corresponding process operation information unit, entity association relationship and rule priority identifier from each simulation result; Traverse the set of deduction results, filter out deduction results marked with non-compliance items in the deduction conclusion of a single node or the deduction conclusion of cross-node association, determine them as target deduction results, and extract the process operation information unit, the process node to which the target deduction result belongs, the specific operation content and the associated rule clauses corresponding to the target deduction result; Retrieve the entity association relationships and complete logical constraint rules associated with the process nodes corresponding to the target deduction results, and extract the standard operation content, business data specifications, associated action processes and operation environment parameter standards that conform to the requirements of the logical constraint rules. The operation content, business data, related actions and operation environment parameters in the process operation information unit corresponding to the target simulation result are compared with the standard operation content, business data specifications, related action process and operation environment parameter standards found. Inconsistent fields and values ​​are identified, and the types of inconsistencies are classified and marked based on the preset root cause classification rules. Based on the specific content of the differences and the root causes of the classification, combined with the rule priority identifier, targeted hierarchical correction measures are constructed. The hierarchical correction measures are divided into multiple correction schemes according to the rule priority. Each correction scheme includes an operational behavior adjustment scheme, a business data supplementation or correction scheme, a related action optimization scheme, and an operational environment parameter adjustment scheme. Each graded correction scheme is broken down into specific and executable detailed execution steps. Each execution step specifies the target object, operation method, operation sequence, operation time requirements, and operation result standards. Match each execution step with a corresponding process node, and determine the specific timing for each corrective measure by combining the overall execution progress and logical sequence of the target business process. The execution steps, operation objects, operation methods, execution order, execution timing and rule priority identifiers corresponding to each hierarchical correction scheme are integrated to generate a preliminary hierarchical process dynamic correction instruction. The instruction includes the corresponding deduction result identifier, process node identifier and correction priority identifier. The initial hierarchical process dynamic correction instructions are formatted and standardized. The standardized hierarchical process dynamic correction instructions are then sent to the RPA operation execution module. After receiving the hierarchical process dynamic correction instructions, the RPA operation execution module sends back a receipt confirmation signal.

7. The intelligent process compliance verification method combining knowledge graph and RPA according to claim 4, characterized in that, When a perfectly matching applicable scenario identifier cannot be found after multiple adjustments, a semantic expansion mechanism is activated to deduce the appropriate applicable scenarios based on the core logic of entity relationships, including: When the initial mapping relationship still cannot find a fully matching applicable scenario identifier after K or more adjustments, the semantic expansion mechanism is automatically triggered. After the semantic expansion mechanism is activated, the currently unmatched process running information unit and its corresponding entity association relationship are locked. Extract the core logical elements of the entity's relationship. These core logical elements include the core constraints between entities, key operational requirements, core data types, and basic applicable conditions. A semantic extension model is constructed based on core logical elements. The semantic extension model includes a core logical element extraction module, a scene similarity calculation module, a scene inference module, and a scene verification module. Retrieve all existing applicable scenario identifiers and their corresponding scenario description information from the applicable scenario library of the compliance knowledge association set. The scenario description information includes the process node characteristics, operation behavior characteristics, environmental parameter characteristics and business objective characteristics corresponding to the scenario. The core logical elements of entity association are compared with the scenario description information of each applicable scenario to calculate the scenario similarity. Applicable scenarios with scenario similarity reaching the preset derivation threshold are selected as candidate adaptation scenarios. Candidate adaptation scenarios are sorted according to the similarity level. The scenario description information of each candidate adaptation scenario is transformed into a logical constraint subgraph. The subgraph isomorphic matching degree between the logical constraint subgraph and the logical constraint main graph corresponding to the current entity association relationship is calculated. It is then determined whether the constraint conditions in the logical constraint subgraph meet the necessary constraint set required for rule execution in the logical constraint main graph. Candidate adaptation scenarios with a subgraph isomorphic matching degree higher than a preset threshold and meeting the necessary constraint set are marked as logical adaptations. From the candidate adaptation scenarios marked as logical adaptation, the scenario with the highest subgraph isomorphic matching degree and the highest cosine similarity with the operation environment parameters and business target feature vector of the current process running information unit is selected as the adaptation scenario. If there are multiple adaptation scenarios, further filtering is carried out in combination with the operation environment parameters and business targets of the process running information unit. The derived adaptation scenario is used as the applicable scenario identifier of the current entity association relationship and a mapping relationship is established with the process running information unit. Record the execution process of the semantic expansion mechanism, including the extraction results of core logical elements, candidate adaptation scenarios, derivation process, verification results, and the finally determined adaptation scenarios, and form a semantic expansion report.

8. The intelligent process compliance verification method combining knowledge graph and RPA according to claim 5, characterized in that, The step of performing cross-node correlation analysis on all the deduction results in the preliminary sequence of the deduction results to identify the logical connections, causal relationships, and mutual influences between the deduction results of different process nodes includes: Start the cross-node correlation analysis engine and initialize the analysis parameters, including correlation analysis dimensions, logical correlation judgment criteria, causal relationship identification rules, and mutual influence evaluation indicators; All inference results in the preliminary sequence of inference results are loaded into the analysis queue of the cross-node correlation analysis engine according to the execution order of the process nodes; Extract the key related elements from each deduction result. The key related elements include process node identifiers, core entities involved, rule clause identifiers, deduction conclusion types, and related action identifiers. A cross-node association analysis model is constructed based on key association elements. The cross-node association analysis model includes a node association matrix, an entity association network, and a rule association graph. By analyzing the node association matrix, the direct correlation between the deduction results of different process nodes is identified, and combinations of process nodes with direct data interaction, action linkage or rule dependence are identified. The indirect relationships between core entities in different inference results are mined by the entity association network. If two process nodes involve the same or related core entities, they are determined to have an indirect relationship. Based on the rule association graph analysis, the logical relationship between the rule clauses corresponding to different deduction results is identified, and the pre- and post-relationship, complementary relationship or constraint relationship between the rule clauses is identified. For inference result pairs with related relationships identified through node association matrix, entity association network or rule association graph, determine whether there is a causal correspondence based on the execution time sequence of process nodes, data flow direction and the pre- and post-dependencies of rule clauses, and calculate the causal association strength coefficient based on the tightness of data dependency and the depth of rule dependency. For inference result pairs with causal relationships, the degree of influence is calculated based on the number of core entities associated with non-compliant items in the inference conclusion of the cause node, the rule priority identifier, and the dependency weight of the result node on the cause node; the scope of influence is determined based on the number of subsequent nodes reachable in the node association matrix of the causal relationship. Identify cross-node chain relationships, where the chain relationship is the relationship in which the deduction result of one process node, through the transmission of intermediate nodes, has a chain effect on the deduction results of multiple subsequent process nodes. The identified logical connections, causal relationships, mutual influences, and chain relationships are classified and organized to form cross-node association analysis results, and a cross-node association analysis report is generated. The cross-node association analysis report records the specific content of each type of association, the identification basis, and the impact assessment results.

9. A computer program product, characterized in that, The computer program product includes machine-executable instructions stored in a computer-readable storage medium. The processor of the intelligent process compliance verification system combining knowledge graph and RPA reads the machine-executable instructions from the computer-readable storage medium and executes the machine-executable instructions to perform the intelligent process compliance verification method combining knowledge graph and RPA as described in any one of claims 1 to 8.

10. An intelligent process compliance verification system combining knowledge graphs and RPA, characterized in that, The system includes a processor and a memory, the memory and the processor being connected. The memory is used to store programs, instructions, or code, and the processor is used to run the programs, instructions, or code in the memory to implement the intelligent process compliance verification method combining knowledge graph and RPA as described in any one of claims 1-8.

Images