A business review intelligent management method fusing quantum technology

Abstract

The application discloses a kind of business review intelligent management methods of fusion quantum technology, belong to business review technical field, specifically include: first input business event identification and multidimensional constraint declaration, parse and build constraint condition effective range atlas after.First, the matching historical business records of each relevant entity are screened based on the atlas, the step sequence in the record is analyzed to merge commonness and build a deduction template, and the template parameters are optimized using quantum annealing strategy.Then, the current event is deduced and marked in combination with the atlas and the declaration, and a simulated execution path is generated.The trigger marks in the path are analyzed, and the logically exclusive constraint condition combinations are identified and defined as conflict points.Finally, a modification scheme is obtained by calling a conflict resolution strategy library, and an executable business path is formed by adjusting the step sequence.The application realizes the transformation of business review from passive response to active prediction and conflict pre-resolution, and improves the automation and reliability of the review process.

Description

Technical Field

[0001] This invention relates to the field of business review technology, and more specifically to a business review intelligent management method that integrates quantum technology. Background Technology

[0002] In a business environment where digital transformation is deepening, the business processes involved in enterprise operations are becoming increasingly complex, and cross-departmental and cross-system collaboration has become the norm. Against this backdrop, business review, as a core component for ensuring compliant operations, controlling operational risks, and improving decision-making quality, is becoming increasingly important. Traditional business review processes typically rely on human experience and static rule bases, making it difficult to cope with the challenges posed by dynamic changes in business processes and the multi-dimensional interplay of constraints. This is especially true when dealing with transactions with high timeliness requirements and complex constraints, where the accuracy and efficiency of reviews face significant pressure.

[0003] However, in existing enterprise business review management practices, for a business transaction involving multiple constraints such as compliance, timeliness, and risk, the review process is typically executed in stages and in isolation by different departments or systems. The checking logic for each constraint is pre-defined in its respective review stage, lacking a mechanism for global collaborative verification before the actual execution of the transaction. This leads to potential implicit conflicts between different constraints during actual operation; for example, the operational steps that satisfy constraint A may violate constraint B. Such conflicts often only surface at specific stages of execution, causing process interruptions, rollbacks, or requiring additional resources for manual coordination and correction, resulting in uncertainty and efficiency bottlenecks in the execution path of the business transaction. Furthermore, the rule engines in existing technical solutions struggle to flexibly adapt to dynamic changes in business processes and implicit conflicts in constraint clauses, and pattern matching based on historical data lacks the ability to globally extrapolate execution paths and simulate conflicts. These shortcomings collectively restrict the evolution of business review systems towards higher levels of automation, intelligence, and reliability. Summary of the Invention

[0004] The purpose of this invention is to provide a business review intelligent management method that integrates quantum technology, and to solve the following technical problems:

[0005] In the existing business review process, the review stages for business transactions involving multi-dimensional constraints are fragmented and lack a global collaborative verification mechanism before execution, resulting in implicit conflicts between different constraints.

[0006] The objective of this invention can be achieved through the following technical solutions:

[0007] A business review intelligent management method integrating quantum technology includes the following steps:

[0008] S1. Input the set of identifiers for the current business event and the business constraint statement, wherein the business constraint statement includes constraint texts for compliance, timeliness, and risk dimensions;

[0009] S2. Parse the constraint text of the business constraint declaration, identify the constraint conditions and the effective business entities, and construct a constraint condition effective scope map based on the hierarchy and relationship of the business entities;

[0010] S3. For each effective business entity in the constraint scope map, filter out historical business records from their respective databases that match the business type and key attributes of the current business event.

[0011] S4. Analyze the execution step sequence in the historical business records, merge common steps to construct a deduction template for the current business event, combine the constraint effective range map and business constraint declaration to perform deduction marking, use quantum annealing strategy to optimize template parameters, and generate simulated execution path;

[0012] S5. Analyze the trigger markers in the simulated execution path, identify logically mutually exclusive constraint combinations, and define each logically mutually exclusive constraint combination as a conflict point.

[0013] S6. Submit the conflict point to the conflict resolution strategy library, obtain the step modification plan for the conflict point, adjust the step sequence in the simulated execution path according to the step modification plan, and form an executable business path.

[0014] As a further aspect of the present invention: in step S2, the process of constructing the constraint effective range map is as follows:

[0015] Parse the constraint text of the business constraint declaration and identify the constraint subject name expressed in the text; query the organizational unit node corresponding to the constraint subject name in the enterprise organizational relationship database, and mark the queried organizational unit node as the directly effective node;

[0016] Traverse the reporting link table and collaboration project table in the enterprise organizational relationship database, extract all management nodes on the upstream reporting path starting from the directly effective node, and extract parallel collaboration nodes that are related to the directly effective node in the collaboration project table; use the set of directly effective nodes, upstream management nodes, and parallel collaboration nodes as the graph vertex set; based on the reporting and collaboration relationships recorded in the organizational relationship database, connect the corresponding vertices to form directed edges, and generate the constraint condition effective range graph.

[0017] As a further aspect of the present invention: in step S3, the process of filtering and matching historical business records is as follows:

[0018] Obtain the business type code and key attribute key-value pair list of the current business event, read the vertex set of the constraint effective range graph, where each vertex in the vertex set corresponds to an effective business entity; for each effective business entity, access its dedicated historical transaction storage area, traverse each historical business record in the historical transaction storage area, and read the business type code field and key attribute field stored in the record;

[0019] Perform a comparison operation, which requires that the business type code field of the historical business record be completely consistent with the business type code of the current business event, and that the key attribute field value of the historical business record match the value of the corresponding key in the key attribute key-value pair list of the current business event. Collect all historical business records that pass the comparison operation to form a set of matched historical business records.

[0020] As a further aspect of the present invention: in step S4, the process of constructing the deduction template and applying it to the current business event is as follows:

[0021] From the set of matched historical business records, extract the structured execution step sequence from each record; compare the extracted execution step sequences pairwise to identify step units that appear in more than half of the sequences and have the same order, and record the step units and their order relationship as common logic units; based on the recorded common logic units, assemble and generate a parameterized deduction template, which defines the execution logic of the steps and the interface for injectable parameters;

[0022] Before injecting the attribute data of the current business event into the parameter interface of the simulation template, quantum annealing is used to optimize the initial parameter configuration of the interface. The optimized simulation template is then driven to perform simulations sequentially. During each simulation step, the effective business entity range is located based on the constraint effective range map, and the clauses in the business constraint declaration applicable to that range are verified. If the triggering condition is met, the corresponding constraint identifier is added to the simulation step. After all simulation steps are completed, the simulation execution path with the identifier is output.

[0023] As a further aspect of the present invention: the process of identifying the step unit that appears in more than half of the sequences and appears in the same order is as follows:

[0024] Each execution step sequence is converted into a string-based tag sequence, where each substring in the tag sequence corresponds to a basic step unit; a prefix tree is constructed using the set of tag sequences, where each node of the prefix tree stores a substring, and the path from the root node to any leaf node represents a complete or partial tag sequence.

[0025] Traverse all nodes of the prefix tree, record how many different tag sequences share the path from the root node to each node, filter out the paths that are shared more than half the total number of tag sequences, extract all substrings stored in order on these paths, and the extracted substrings form the common logic unit.

[0026] As a further aspect of the present invention: in step S5, the process of identifying combinations of logically mutually exclusive constraints is as follows:

[0027] Scan the simulation execution path and identify the constraint identifiers attached to each simulation step, and compile all identifiers that appear at any position in the path; based on the preset business rule lookup table, query whether there is a mutual exclusion relationship declaration between every two constraint identifiers, and the mutual exclusion relationship declaration is recorded in the mutual exclusion relationship field of the business rule lookup table;

[0028] Filter out all constraint condition pairs marked as "yes" in the mutual exclusion relationship field of the business rule comparison table, and bind each selected constraint condition pair to its occurrence position in the simulated execution path to generate a conflict point record.

[0029] As a further aspect of the present invention: the process of querying whether there is a mutually exclusive relationship declaration between every two constraint identifiers based on a preset business rule lookup table is as follows:

[0030] The pre-defined business rule lookup table is a data table containing a first constraint identifier field, a second constraint identifier field, and a relation status field. It receives a query pair consisting of two constraint identifiers. In the data table, the first identifier in the query pair is matched against the first constraint identifier field for strict equality, and the second identifier in the query pair is matched against the second constraint identifier field for strict equality. A structured query language retrieval is performed to obtain data rows that simultaneously satisfy both strict equality matching conditions. The status value stored in the relation status field of the obtained data row is read. The status value is a predefined enumeration type value, where one enumeration value represents a mutually exclusive relation declaration.

[0031] As a further aspect of the present invention: in step S6, the process of calling the conflict resolution strategy library and adjusting the step sequence is as follows:

[0032] The conflict point records are transmitted to the input interface of the conflict resolution strategy library. The conflict resolution strategy library searches its internal strategy index table based on the constraint condition identifiers in the conflict point records and returns a set of pre-configured step adjustment instructions. The step adjustment instructions include the step position index to be adjusted, the adjustment type code, and the specific parameters required for adjustment. According to the instructions, the target step position in the simulated execution path is located, and the corresponding operation is performed according to the adjustment type code. The operation includes deleting a step, inserting a new step, swapping the step order, or modifying step attributes. After all instructions have been executed, the adjusted step sequence is traversed to confirm that the constraint condition identifiers in the original conflict point records are no longer triggered at the same or adjacent positions, thus forming the final executable business path.

[0033] The beneficial effects of this invention are:

[0034] This invention achieves full-path virtual simulation and conflict prediction before business event execution by constructing a constraint effective range map, generating parameterized simulation templates based on historical business records, and marking constraint trigger states in advance during simulation. Furthermore, it uses a conflict resolution strategy library to automatically adjust and reorganize the step sequences of identified mutually exclusive constraint combinations, ultimately outputting an executable business path that avoids conflicts. This solution integrates the previously phased and isolated review process into a globally collaborative verification process, exposing and resolving implicit conflicts between different constraints before actual business execution, thus effectively avoiding resource consumption caused by process interruptions and rollbacks. By introducing a quantum annealing strategy to initialize and optimize the simulation template parameters, the model's optimization capability and convergence efficiency in complex parameter spaces are enhanced. The entire method forms a complete technical closed loop from historical data-driven modeling, full-path simulation, intelligent conflict identification to automatic strategy resolution, ultimately transforming the traditional uncertain and repetitive business execution path into a deterministic, continuous, and inherently consistent efficient trajectory. Attached Figure Description

[0035] The invention will now be further described with reference to the accompanying drawings.

[0036] Figure 1 This is a flowchart illustrating the present invention. Detailed Implementation

[0037] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0038] Please see Figure 1As shown, this invention is a business review intelligent management method integrating quantum technology, comprising the following steps:

[0039] S1. Input the set of identifiers for the current business event and the business constraint statement, wherein the business constraint statement includes constraint texts for compliance, timeliness, and risk dimensions;

[0040] S2. Parse the constraint text of the business constraint declaration, identify the constraint conditions and the effective business entities, and construct a constraint condition effective scope map based on the hierarchy and relationship of the business entities;

[0041] S3. For each effective business entity in the constraint scope map, filter out historical business records from their respective databases that match the business type and key attributes of the current business event.

[0042] S4. Analyze the execution step sequence in the historical business records, merge common steps to construct a deduction template for the current business event, combine the constraint effective range map and business constraint declaration to perform deduction marking, use quantum annealing strategy to optimize template parameters, and generate simulated execution path;

[0043] S5. Analyze the trigger markers in the simulated execution path, identify logically mutually exclusive constraint combinations, and define each logically mutually exclusive constraint combination as a conflict point.

[0044] S6. Submit the conflict point to the conflict resolution strategy library, obtain the step modification plan for the conflict point, adjust the step sequence in the simulated execution path according to the step modification plan, and form an executable business path.

[0045] In a preferred embodiment of the present invention, the process of constructing the constraint effective range map in step S2 is as follows:

[0046] First, the constraint text of the input business constraint declaration is parsed using natural language. This parsing process identifies the names of the constraint entities directly stated in the text, such as specific titles or department names like the General Manager of Finance Department, Sales Director of North China Region, and Compliance Office. Next, the enterprise organizational database is accessed. This database typically contains an organizational unit table, which stores the standardized names and unique identifiers of all departments, positions, and ranks within the company. By performing exact matching or fuzzy matching based on edit distance between the identified constraint entity names and the name field in the organizational unit table, the corresponding organizational unit nodes can be retrieved. Each successfully matched organizational unit node is marked as a directly effective node, meaning that the constraint declaration directly points to these business entities at the text level.

[0047] Subsequently, to determine the full scope of the actual impact of the constraints, it is necessary to expand the directly effective nodes based on the enterprise's internal management and collaboration network. Enterprise organizational relationship databases typically maintain two core relationship tables: the reporting chain table and the collaboration project table. The reporting chain table stores the hierarchical reporting relationships between organizational unit nodes in a two-dimensional table format. Each row contains a subordinate node identifier, a superior node identifier, and a reporting relationship type code between them. The collaboration project table records temporary or permanent collaboration relationships across departments or positions. Each row contains the identifiers of participating node A and node B, the collaboration project number, and the collaboration strength coefficient.

[0048] For each directly effective node, the following traversal operation is performed to expand the scope of effectiveness. First, in the reporting chain table, starting from the directly effective node, a recursive or iterative traversal is performed upstream along the reporting relationship. The traversal process continuously tracks the reporting chain until a preset upper limit is reached, such as three levels, or until the company's highest management level node is reached. All superior management nodes accessed during this process are included in the expanded scope. For example, if the directly effective node is the project team leader, then its department manager, business unit director, and even the company's vice president in charge may be included. Second, in the collaborative project table, all records associated with the identifier of the directly effective node are retrieved. From these records, the identifiers of parallel collaborative nodes with which it has a collaborative relationship are extracted. These parallel collaborative nodes usually come from different reporting chains, but have business intersections with the directly effective node due to project work needs.

[0049] After completing the above traversal and extraction, a set of nodes is obtained, which includes directly effective nodes, all upstream management nodes traced through the reporting chain, and all parallel collaborative nodes associated through the collaborative project table. This set is defined as the complete set of effective business entities under the current constraints, serving as the vertex set for subsequent graph construction.

[0050] Finally, based on the relationships recorded in the organizational relationship database, connecting edges are generated within this vertex set. Specifically, for reporting relationships, the system searches for superior-subordinate node pairs in the reporting link table within the vertex set and generates directed edges from subordinates to superiors. For collaboration relationships, the system searches for node pairs in the collaboration project table within the vertex set and generates undirected or bidirectional directed edges, with the collaboration project number and strength coefficient recorded in the edge attributes. In this way, all relevant effective business entities and their relationships are integrated into a unified directed graph structure, thus generating a constraint scope graph. This graph visually depicts the actual scope and path of influence of a single constraint within the enterprise organization.

[0051] In another preferred embodiment of the present invention, the process of filtering and matching historical business records in step S3 is as follows:

[0052] Enter a description of the current business event, including a standardized business type code and a list of key-value pairs for key attributes. The business type code is a predefined numeric or string enumeration value, such as 50 representing procurement-related business and 60 representing contract approval-related business. The list of key-value pairs for key attributes is a set of attribute names and their corresponding values ​​that describe the specific characteristics of the business event, such as project code project_123, contract amount of 100,000, and product line involved being software.

[0053] The process begins by reading the constraint scope graph generated in step S2. Each vertex in the graph uniquely corresponds to an effective business entity, such as a finance department node, a legal department node, or a specific approval position node. The filtering operation will be performed independently for each effective business entity in the graph.

[0054] For each vertex in the graph, i.e., the effective business entity, it is necessary to access the entity's dedicated historical transaction storage area to find relevant records. Physically, the historical transaction storage area can be a separate database table partition, a dedicated file directory, or a collection of documents tagged with the business entity. The historical business records stored therein have a unified structured format, and each record contains at least the following core fields: a globally unique identifier, a timestamp of the business occurrence, a business type code field, and one or more key attribute fields. The names of the key attribute fields are consistent with the attribute names in the aforementioned key-value pair list, for example, they also include fields such as project code and contract amount.

[0055] The specific filtering process is implemented through a loop traversal logic. For the currently active business entity being processed, the program locates its corresponding historical transaction storage area and sequentially or in parallel traverses each historical business record in the storage area. For each traversed historical business record, a strict comparison operation is performed. This comparison operation includes two conditions that must be met simultaneously.

[0056] The first condition is a complete consistency comparison of the business type codes. The program reads the value of the business type code field stored in the historical business records and directly compares it with the business type code of the current business event. The first condition is only satisfied if the two code values ​​are exactly the same. For example, if the current event is a procurement business with code 50, then the value of the business type code field in the historical records must also be 50; records with code 60 will be excluded in this step.

[0057] The second condition is the matching comparison of key attribute values. The program reads the list of key-value pairs of key attributes for the current business event. For each attribute key in the list, such as project code, the program checks whether a key attribute field with the same name exists in historical business records. If it exists, it further compares whether the value of that field matches the value of the corresponding attribute in the current event. The matching rules can be predefined according to the attribute type: for string type attributes such as project code, they usually require exact equality or meeting a specific pattern; for numeric type attributes such as contract amount, a floating percentage range can be set, such as plus or minus 10%, and historical records with amounts within 10,000 of 100,000 are considered a match; for enumeration type attributes, the values ​​must be exactly the same. The second condition is only satisfied when all field values ​​in historical business records corresponding to the key attribute list of the current event meet their respective matching rules.

[0058] Only historical business records that pass both of the above conditions will be temporarily marked as candidate matching records. After traversing all historical business records for a single effective business entity, the program collects all marked candidate records. Then, the program moves to the next effective business entity vertex in the graph and repeats the process of locating the storage area, traversing records, performing the two-condition comparison, and collecting results.

[0059] Once all active business entity vertices in the graph have been processed, the candidate record sets selected for each entity are merged, removing duplicate records that may arise due to data redundancy. This results in a global, matching set of historical business records. This set contains past cases processed by all relevant business entities within the scope of constraints, which are highly similar in type and key characteristics to the current business event under review, providing a high-quality data foundation for subsequent inference and modeling. The entire selection process, through structured data access and explicit matching logic, ensures the accuracy and comprehensiveness of the historical experience data selection.

[0060] In another preferred embodiment of the present invention, the process of constructing the deduction template and applying it to the current business event in step S4 is as follows:

[0061] First, extract the execution step sequence from each historical business record. Assume the matching set of historical business records contains 5 records. The step sequence for each record might look like this: Record 1's sequence contains steps A, B, C, and D; Record 2's sequence contains steps A, B, X, and D; Record 3's sequence contains steps A, B, C, and D; Record 4's sequence contains steps A, Y, and C; and Record 5's sequence contains steps A, B, and Z. Each step unit is typically defined by metadata such as step type code, execution role, and operation object identifier. The extraction operation reads this structured data into memory, forming a list of multiple step sequence objects for subsequent analysis.

[0062] Next, pairwise comparisons are performed on the extracted sequences of execution steps to identify common patterns. Specifically, the goal is to find combinations of consecutive or non-consecutive step units that appear in more than half of the input sequences and maintain a consistent order. Taking the five sequences above as an example, steps A and B appear in all five sequences, with step B always immediately following step A, constituting a strong common pattern. Step C appears in records 1, 3, and 4, but its position is the third step in records 1 and 3, and the second step in record 4; its sequential consistency needs to be determined according to a preset tolerance rule. Step D appears in records 1, 2, and 3, and is always at the end of the sequence. These common patterns can be identified through systematic sequence alignment and pattern mining algorithms. All identified step units that satisfy the condition of being common to more than half of the sequences and maintaining a consistent order, along with their determined sequential relationships, are recorded as one or more common logical units. For example, two common logical units might be identified: the first unit contains step A followed by step B; the second unit contains step C.

[0063] Then, based on the identified and recorded common logical units, a parameterized derivation template is assembled. This template is essentially an executable logic flowchart or state machine script, its skeleton composed of common logical units. The position and logical relationship of each step unit in the template are fixed, but the specific business parameters involved are abstracted into injectable variable interfaces. For example, step A might involve approval amounts, and step B might involve approval departments; the specific values ​​of these amounts and departments are defined in the template as parameters `place_holder_1` and `place_holder_2`. The assembly process combines the fixed step logic and control flow with the variable parameter interface declarations to generate a complete, instantiable template file, which can be in a domain-specific language script or a configuration object with metadata.

[0064] After obtaining the parameterized simulation template, the attribute data of the current business event is not immediately injected. Before this, an optimization step is introduced: quantum annealing computation is used to optimize the initial configuration of the template parameter interfaces. This process first requires formalizing the parameter configuration optimization problem into a combinatorial optimization problem model suitable for quantum annealing. Specifically, each parameter interface of the template has a set of possible values. For example, the approval amount parameter may correspond to multiple empirically reasonable midpoints, and the approval department parameter may correspond to multiple department codes with similar functions. Different parameter configuration combinations will affect the efficiency and path rationality of subsequent simulation execution. An evaluation function is defined to assess the merits of any parameter configuration combination. This function may consider factors such as the success rate of similar historical cases and the average execution time of the path. The problem of finding the minimum value of this evaluation function is mapped to a quadratic unconstrained binary optimization problem model. Subsequently, this model is submitted to a quantum annealing computation device or simulator. The quantum annealing device performs annealing evolution on the physical qubit system, ultimately returning a low-energy state with a high probability. This state corresponds to an optimized parameter configuration binary code. After decoding this encoding, a set of recommended initial parameter values ​​is obtained, such as initializing the approval amount to 50,000 and the approval department to the department code dept_456. The goal of this optimization is to provide a better starting point for the simulation, rather than dynamically adjusting the parameters during the simulation process.

[0065] After initial parameter optimization, the attribute data of the current business event is combined with the optimized initial parameter values ​​and injected into the corresponding parameter interface of the simulation template. This instantiation of the template generates a specific executable process instance for the current event. Subsequently, the simulation drives this instantiated process to execute sequentially. The simulation execution is performed by an interpreter or workflow engine, which progressively "executes" each logical step in the template. The simulation execution does not involve operating the actual operating system or calling real interfaces; instead, it calculates state transitions and logs them in a sandbox environment.

[0066] At each step of the simulation, constraint compliance verification is required. This verification process relies on the constraint scope graph generated in step S2. When the simulation enters a step, such as step A, this step may be associated with an execution role, a finance specialist. Based on the constraint scope graph, the finance specialist business entity node can be located, and through the edges in the graph, all its superior management nodes and related collaborating nodes can be identified. The set of business entities represented by these nodes constitutes the scope of business entities effective for the current step. Next, the business constraint statements are traversed, filtering out all constraint clauses that explicitly point to any business entity within this scope. For example, a statement might be filtered out: payment applications exceeding 10,000 yuan initiated by the finance specialist require the department manager's countersignature. Then, it is verified whether the status data of the current simulation step meets the triggering condition of this clause. For example, if the approval amount parameter of the current simulation step is 50,000 yuan, the triggering condition is met. Once met, the corresponding constraint identifier is attached to the simulation step, for example, marked as `triggered_constraint_id_001` in the step log.

[0067] In this manner, the simulation execution is progressively advanced until all steps of the process instance are completed. Throughout the process, each step may trigger zero, one, or more constraints, and all trigger markers are recorded in real time. When all simulation steps are completed, a complete simulation execution path is output. This path not only contains the sequence of steps, but more importantly, it contains the sequence of constraint trigger markers attached to each step, clearly showing when and where which constraints will be triggered if the business is executed according to this path.

[0068] It is worth noting that the sub-step of identifying common logical units in the above process has its own independent and refined implementation method. Specifically, each sequence of execution steps in text or code form is first converted into a string-based tag sequence. The conversion rule is usually to assign a unique short string code to each basic step unit type, for example, the step type approval code is A, the step type verification code is B, and the step type archiving code is C. A step sequence containing approval, verification, and archiving is then converted into a tag string like ABC. Assume there are 5 tag sequences: S1:ABC, S2:ABD, S3:ABC, S4:AEC, S5:ABF.

[0069] Next, a prefix tree is constructed using this set of marked sequences. The construction process begins by creating a root node, which does not store any characters. Then, for each marked sequence, starting from the root node, each character in its string is inserted as a child node. If a path from the root node to the current character already exists, that path is shared, simply by incrementing the count at the node corresponding to the last character. For example, after inserting the sequence ABC, the tree contains the path root->A->B->C. When inserting ABD, the path root->A->B already exists, so nodes A and B are shared, and a new child node D is created from node B. In the final prefix tree, each node stores a character, and the path from the root node to any node represents a common prefix of one or more input sequences.

[0070] Then, traverse all nodes of this prefix tree. During traversal, record how many different original label sequences share the path from the root node to the current node. For example, path AB is shared by sequences S1, S2, S3, and S5, so the sharing count is 4. Path ABC is shared only by S1 and S3, so the count is 2. The total number of label sequences is 5, and the half threshold is set to 2.5, rounded up to 3.

[0071] Finally, all paths with a shared count greater than 3 are selected. For example, path A has a count of 5, and path AB has a count of 4, both satisfying the condition. The characters stored sequentially on these paths are extracted: path A extracts A, and path AB extracts A and B. Since path AB contains path A and represents a longer common pattern, the sequence represented by the longest path that satisfies the condition is usually chosen. The extracted substring sequence set A->B constitutes a common logical unit. This method allows for the objective and efficient extraction of the most common execution pattern fragments from a large number of historical step sequences.

[0072] In another preferred embodiment of the present invention, the process of identifying logically mutually exclusive constraint combinations in S5 is as follows:

[0073] First, a full path scan is performed on the simulated execution path. The scan starts from the first simulated step of the path and processes each step sequentially. For the currently processed simulated step, its associated list of constraint identifiers is read. Assume a simulated execution path contains three steps: step 1 triggers constraint identifiers C001 and C002, step 2 does not trigger any constraints, and step 3 triggers constraint identifiers C003 and C001. The program extracts the identifiers appearing in each step and adds them to a global temporary set, while also recording the step location information for each identifier. For example, after the scan, all collected constraint identifiers are C001, C002, and C003. C001 appears in both steps 1 and 3, C002 appears only in step 1, and C003 appears only in step 3. After this step, a list containing all unique constraint identifiers that have appeared in the path, as well as a list of the specific locations of each identifier in the path, is obtained. For example, the unique identifier list is C001, C002, and C003.

[0074] Subsequently, based on a pre-defined business rule lookup table, the system queries whether a mutually exclusive relationship exists between any two constraint identifiers. The business rule lookup table is a pre-defined table stored in a relational database, used to explicitly record the logical relationships between different constraints. This table contains at least three core fields: a first constraint identifier field, a second constraint identifier field, and a relationship state field. The first and second constraint identifier fields store the unique codes for the constraints, such as C001, C002, etc. The relationship state field stores a predefined enumeration type value indicating the logical relationship between the two constraints. Enumeration values ​​typically include MUTEX (representing mutual exclusion), COMPATIBLE (representing compatibility), and DEPENDENT (representing conditional dependency), etc. For example, the table might contain a row with a first constraint identifier field value of C001, a second constraint identifier field value of C002, and a relationship state field value of MUTEX. This indicates that constraints C001 and C002 are mutually exclusive under any circumstances and cannot be satisfied simultaneously.

[0075] The query process needs to process all the unique constraint identifiers obtained in the previous step. The program will generate all pairwise combinations of these identifiers. For example, for identifiers C001, C002, and C003, the pairwise combinations include C001 and C002, C001 and C003, and C002 and C003. For each combination, the program will construct a query pair.

[0076] The specific query operation is as follows. The program receives a query pair consisting of two constraint identifiers, such as query pair C001 and C002. Subsequently, the program connects to the database storing the business rule lookup table and constructs a Structured Query Language (SCL) statement. Since the mutual exclusion relationships between constraints are usually unordered—that is, C001 and C002 being mutually exclusive is equivalent to C002 and C001 being mutually exclusive—the design of the business rule lookup table needs to ensure this symmetry. A common practice is to store two records in the table for each pair of mutual exclusion relationships, namely C001, C002, MUTEX and C002, C001, MUTEX. Another practice is to store only one record, but the query needs to check both orders simultaneously. For clarity, let's assume the first practice is used, where the table stores bidirectional records for each pair of relationships.

[0077] The program performs an exact equality match on the first identifier in the query pair, such as C001, against the first constraint identifier field in the business rule lookup table, requiring the field value to be exactly equal to C001. Simultaneously, it performs an exact equality match on the second identifier in the query pair, such as C002, against the second constraint identifier field in the table, requiring the field value to be exactly equal to C002. The program executes this query statement, retrieving all data rows from the database that simultaneously satisfy both exact equality match conditions.

[0078] After executing the query, the program retrieves the query results. If a row of data exists in the table, the query is successful, and the program reads the status value stored in the relation status field of that row. If the status value equals the enumeration value representing a mutual exclusion relationship, such as the string "MUTEX" or the number 1, it is determined that the constraint indicates a mutual exclusion relationship declaration. If the query returns no rows, or the relation status field value in the returned row is not a mutual exclusion enumeration value, it is determined that the constraint indicates no mutual exclusion relationship declaration, or the relationship is of another type.

[0079] For example, for query pair C001 and C002, if the database returns a single record with the relation status field value of MUTEX, then C001 and C002 are considered mutually exclusive. For query pair C001 and C003, if the database query returns no results or the returned record's status value is COMPATIBLE, then C001 and C003 are considered not mutually exclusive.

[0080] The program will repeat the above query process for all generated pairwise identifier combinations to obtain a list that records which constraint identifier pairs are mutually exclusive.

[0081] Next, the program needs to filter out all constraint pairs that are determined to be mutually exclusive. Specifically, it iterates through the query results list of the business rule lookup table, extracting all constraint pairs whose relation status field is marked as a mutually exclusive enumeration value. For example, after querying, it might be found that only the pair C001 and C002 are marked as mutually exclusive.

[0082] Finally, for each selected pair of mutually exclusive constraint identifiers, the program needs to bind them to their specific locations in the simulated execution path, generating a conflict point record. The conflict point record is a data structure that typically contains the following fields: the conflict identifier pair, i.e., two mutually exclusive constraint identifiers, such as C001 and C002; the conflict location, i.e., the step location information in the simulated execution path where these two identifiers appear; and possibly other metadata, such as conflict type, severity level, etc.

[0083] When the location of the conflict is determined, the program traces back to the location information stored in the scan results of the simulated execution path. For mutex pairs C001 and C002, it needs to check whether they appear in the same step or adjacent steps in the path. If they appear in the same step, such as step 1, then the location field of the conflict point record records step 1. If they appear in different but adjacent steps, such as C001 in step 1 and C002 in step 2, then the location field of the conflict point record may record both steps 1 and 2, and mark them as adjacent step conflicts. The program will generate a corresponding conflict point record. For example, for mutex pairs C001 and C002, since they both appear in step 1, a conflict point record is generated with the content: Mutex pair C001_C002, conflict location step 1.

[0084] After completing the checking and recording of all mutual exclusion pairs, step S5 outputs a conflict point record list. This list details where potential business conflicts exist in the simulated execution path due to logical mutual exclusion of constraints, providing clear targets for subsequent conflict resolution.

[0085] It's worth noting that the above query process relies on a pre-defined business rule mapping table. This table is typically implemented as a relational database table, such as a table named `business_rule_mapping` created in MySQL or PostgreSQL. The table contains the fields described earlier: `first_constraint_id` (VARCHAR20 type) stores the identifier of the first constraint; `second_constraint_id` (also VARCHAR20 type) stores the identifier of the second constraint; and `relation_status` (INT or ENUM type) stores the relationship status enumeration value. An example of data stored in the table might be as follows: one row contains `first_constraint_idC001, second_constraint_idC002, relation_status1`, where 1 represents mutual exclusion. Another row contains `C002, C001, 1`, ensuring that reverse queries also succeed.

[0086] When the program needs to query the identifier pairs C001 and C002, it constructs and executes the following SQL statement example: `SELECT relation_status FROM business_rule_mapping WHERE first_constraint_id='C001' AND second_constraint_id='C002'`. The program executes this statement through the database connector to obtain the result set. If the result set is not empty, it reads the value of the `relation_status` field from the first row. The program internally predefines relation status enumeration values, such as the constant `MUTEX=1`. By comparing the read field value with the constant `MUTEX`, a mutual exclusion relationship can be determined. The entire process does not involve complex logical calculations but is achieved through efficient data table retrieval, ensuring that query performance remains controllable even with tens of thousands of rules.

[0087] In another preferred embodiment of the present invention, in step S6, the process of calling the conflict resolution strategy library and adjusting the step sequence is as follows:

[0088] First, the conflict point record is transmitted to the input interface of the conflict resolution strategy library. This interface can be a function call entry point, a message queue receiving endpoint, or a network service API. The transmitted data format is usually structured, such as a JSON object, whose content comes directly from the conflict point record. Assume the transmitted conflict point record contains: a mutex pair C001_C002, and a conflict location step index 3.

[0089] The conflict resolution strategy library internally maintains a strategy index table. The core function of this table is to map specific conflict patterns to predefined solutions. The strategy index table can be a database table, an in-memory hash map, or a configuration file. Its data structure typically contains at least the following keys: a conflict pattern key, used to match incoming conflict identifier pairs; and the corresponding step adjustment instruction set. The conflict pattern key is designed to uniquely identify a mutual exclusion relationship; for example, a concatenated string of identifier pairs, C001_C002, can be used as the key. The step adjustment instruction set details the specific modifications needed to the simulated execution path to resolve the conflict.

[0090] When the conflict resolution strategy library receives a conflict point record through the input interface, it extracts the constraint identifier pair from the record, such as C001_C002, and uses this as the lookup key to retrieve the value in its internal strategy index table. The retrieval operation might involve executing a database query or looking up the corresponding value in a hash map based on the key. If the retrieval is successful, a set of pre-configured step-by-step adjustment instructions is returned. This set of instructions is typically also a structured list.

[0091] Each step adjustment instruction contains several essential elements. The first element is the step position index to be adjusted. This specifies which step in the simulated execution path the operation should be performed on. Position indices are typically counted starting from 0 or 1, corresponding to the step order in the simulated execution path. For example, an instruction might have a step position index of 3. The second element is the adjustment type code. This is a short code indicating the type of adjustment operation to be performed. Common adjustment type codes include DELETE for deleting a step, INSERT for inserting a new step, SWAP for swapping step order, and MODIFY for modifying step attributes. The third element is the specific parameters required for the adjustment. The parameter content varies depending on the adjustment type. For example, for the INSERT type, the parameters need to include the complete definition of the new step to be inserted; for the SWAP type, the parameters need to specify the index of the other step to be swapped with the target step; and for the MODIFY type, the parameters need to specify the name of the attribute to be modified and the new attribute value.

[0092] For example, for the conflict identifier C001_C002, one possible instruction returned by the retrieval is as follows: Step position index 3, Adjust type code INSERT, the specific parameter is a new step definition object, its step type is "Add Approval", and the execution role is "Senior Manager". Another possible instruction is: Step position index 3, Adjust type code MODIFY, the specific parameter is to change the attribute approval amount from 100000 to 80000.

[0093] After obtaining the step adjustment instruction set, the program begins to modify the original simulated execution path according to the instructions. First, the program locates the target step position in the simulated execution path based on the step position index in the instruction. The simulated execution path is usually represented in memory as a list or array of step objects, and a specific step object can be directly accessed through the index.

[0094] Then, the program performs the corresponding operation based on the adjustment type code. If the code is DELETE, the program removes the step object at that index position from the step list, and the indices of subsequent steps are automatically shifted forward. If the code is INSERT, the program inserts a new step object before or after the specified index position, according to the specific parameters, and the indices of subsequent steps are shifted forward accordingly. If the code is SWAP, the program swaps the two step objects at the specified index position with another index position provided in the parameters. If the code is MODIFY, the program finds the target step object and updates the corresponding attributes of that object according to the attribute names and new attribute values ​​specified in the parameters.

[0095] The program executes each step adjustment instruction returned by the policy library sequentially. For example, it first executes the instruction to insert a new step before step 3, and then executes the instruction to modify a certain attribute of step 3. The execution of all instructions involves operations on a copy of the simulated execution path in memory.

[0096] After all instructions have been executed, the program obtains an adjusted sequence of steps. To ensure the effectiveness of the adjustment, the program needs to perform a traversal verification of this new sequence of steps. The core objective of the verification is to confirm whether the pairs of mutually exclusive constraint identifiers in the original conflict point record are no longer triggered at the same or adjacent positions. The verification process simulates the execution of the adjusted path, but usually only performs lightweight constraint trigger checks, rather than completely repeating the full simulation of step S4. The program checks the new sequence of steps to see if there are still steps that simultaneously or adjacently trigger identifiers C001 and C002. If the check passes, meaning the conflict has been resolved, then this adjusted sequence of steps is considered the final executable business path. If the check finds that conflicts still exist, an exception handling process may need to be triggered, such as logging and attempting to apply alternative strategies, or marking it as requiring manual intervention. Finally, the confirmed executable business path is output.

[0097] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should still fall within the patent coverage of this invention.

Claims

1. A business review intelligent management method integrating quantum technology, characterized in that, Includes the following steps: S1. Input the set of identifiers for the current business event and the business constraint statement, wherein the business constraint statement includes constraint texts for compliance, timeliness, and risk dimensions; S2. Parse the constraint text of the business constraint declaration, identify the constraint conditions and the effective business entities, and construct a constraint condition effective scope map based on the hierarchy and relationship of the business entities; S3. For each effective business entity in the constraint scope map, filter out historical business records from their respective databases that match the business type and key attributes of the current business event. S4. Analyze the execution step sequence in the historical business records, merge common steps to construct a deduction template for the current business event, combine the constraint effective range map and business constraint declaration to perform deduction marking, use quantum annealing strategy to optimize template parameters, and generate simulated execution path; S5. Analyze the trigger markers in the simulated execution path, identify logically mutually exclusive constraint combinations, and define each logically mutually exclusive constraint combination as a conflict point. S6. Submit the conflict point to the conflict resolution strategy library, obtain the step modification plan for the conflict point, adjust the step sequence in the simulated execution path according to the step modification plan, and form an executable business path.

2. The intelligent management method for business review integrating quantum technology according to claim 1, characterized in that, In S2, the process of constructing the constraint effective range map is as follows: Parse the constraint text of the business constraint declaration and identify the constraint subject name expressed in the text; query the organizational unit node corresponding to the constraint subject name in the enterprise organizational relationship database, and mark the queried organizational unit node as the directly effective node; Traverse the reporting link table and collaboration project table in the enterprise organizational relationship database, extract all management nodes on the upstream reporting path starting from the directly effective node, and extract parallel collaboration nodes that are related to the directly effective node in the collaboration project table. The set of directly effective nodes, upstream management nodes, and parallel collaborative nodes is taken as the graph vertex set; Based on the reporting and collaboration relationships recorded in the organizational relationship database, directing edges are formed by connecting the corresponding vertices, generating a graph of the effective range of the constraint conditions.

3. The intelligent management method for business review integrating quantum technology according to claim 1, characterized in that, In S3, the process of filtering and matching historical business records is as follows: Obtain the business type code and key attribute key-value pair list of the current business event, read the vertex set of the constraint effective range graph, where each vertex in the vertex set corresponds to an effective business entity; for each effective business entity, access its dedicated historical transaction storage area, traverse each historical business record in the historical transaction storage area, and read the business type code field and key attribute field stored in the record; Perform a comparison operation, which requires that the business type code field of the historical business record be completely consistent with the business type code of the current business event, and that the key attribute field value of the historical business record match the value of the corresponding key in the key attribute key-value pair list of the current business event. Collect all historical business records that pass the comparison operation to form a set of matched historical business records.

4. The intelligent management method for business review integrating quantum technology according to claim 1, characterized in that, In step S4, the process of constructing the deduction template and applying it to the current business event is as follows: From the set of matched historical business records, extract the structured execution step sequence from each record; compare the extracted execution step sequences pairwise to identify step units that appear in more than half of the sequences and have the same order, and record the step units and their order relationship as common logic units; based on the recorded common logic units, assemble and generate a parameterized deduction template, which defines the execution logic of the steps and the interface for injectable parameters; Before injecting the attribute data of the current business event into the parameter interface of the simulation template, quantum annealing is used to optimize the initial parameter configuration of the interface. The optimized simulation template is then driven to perform simulations sequentially. During each simulation step, the effective business entity range is located based on the constraint effective range map, and the clauses in the business constraint declaration applicable to that range are verified. If the triggering condition is met, the corresponding constraint identifier is added to the simulation step. After all simulation steps are completed, the simulation execution path with the identifier is output.

5. The intelligent management method for business review integrating quantum technology according to claim 4, characterized in that, The process of identifying the step unit that appears in more than half of the sequences and appears in the same order is as follows: Each execution step sequence is converted into a string-based tag sequence, where each substring in the tag sequence corresponds to a basic step unit; a prefix tree is constructed using the set of tag sequences, where each node of the prefix tree stores a substring, and the path from the root node to any leaf node represents a complete or partial tag sequence. Traverse all nodes of the prefix tree, record how many different tag sequences share the path from the root node to each node, filter out the paths that are shared more than half the total number of tag sequences, extract all substrings stored in order on these paths, and the extracted substrings form the common logic unit.

6. The intelligent management method for business review integrating quantum technology according to claim 1, characterized in that, In step S5, the process of identifying combinations of logically mutually exclusive constraints is as follows: Scan the simulation execution path and identify the constraint identifiers attached to each simulation step, and compile all identifiers that appear at any position in the path; based on the preset business rule lookup table, query whether there is a mutual exclusion relationship declaration between every two constraint identifiers, and the mutual exclusion relationship declaration is recorded in the mutual exclusion relationship field of the business rule lookup table; Filter out all constraint condition pairs marked as "yes" in the mutual exclusion relationship field of the business rule comparison table, and bind each selected constraint condition pair to its occurrence position in the simulated execution path to generate a conflict point record.

7. The intelligent management method for business review integrating quantum technology according to claim 6, characterized in that, The process of querying whether there is a mutually exclusive relationship declaration between every two constraint identifiers based on the pre-set business rule lookup table is as follows: The pre-defined business rule lookup table is a data table containing a first constraint identifier field, a second constraint identifier field, and a relation status field. It receives a query pair consisting of two constraint identifiers. In the data table, the first identifier in the query pair is matched against the first constraint identifier field for strict equality, and the second identifier in the query pair is matched against the second constraint identifier field for strict equality. A structured query language retrieval is performed to obtain data rows that simultaneously satisfy both strict equality matching conditions. The status value stored in the relation status field of the obtained data row is read. The status value is a predefined enumeration type value, where one enumeration value represents a mutually exclusive relation declaration.

8. The intelligent management method for business review integrating quantum technology according to claim 1, characterized in that, In step S6, the process of calling the conflict resolution strategy library and adjusting the step sequence is as follows: The conflict point records are transmitted to the input interface of the conflict resolution strategy library. The conflict resolution strategy library searches its internal strategy index table based on the constraint condition identifiers in the conflict point records and returns a set of pre-configured step adjustment instructions. The step adjustment instructions include the step position index to be adjusted, the adjustment type code, and the specific parameters required for adjustment. According to the instructions, the target step position in the simulated execution path is located, and the corresponding operation is performed according to the adjustment type code. The operation includes deleting a step, inserting a new step, swapping the step order, or modifying step attributes. After all instructions have been executed, the adjusted step sequence is traversed to confirm that the constraint condition identifiers in the original conflict point records are no longer triggered at the same or adjacent positions, thus forming the final executable business path.

Images