Workflow processing method and system thereof

Abstract

A workflow processing method and system are disclosed. A plurality of first rulebooks define analysis logic and structured output formats, while a plurality of second rulebooks define action execution flows and conditions for selecting execution paths. In response to a trigger event, an orchestration flow sequentially executes multiple processing nodes, each using a corresponding rulebook, with output of one node serving as input to the next. For a first- rulebook node, an artificial intelligence model analyzes input data and produces a validated structured result. For a second-rulebook node, a workflow engine schedules pending actions and routes each action to autonomous execution or human approval according to the defined conditions. During execution, a processing record for each node is written as a blockchain block. Upon completion, a terminal block containing summary information of preceding blocks is appended, thereby providing a configurable end-to-end workflow with a tamper-evident and independently verifiable audit trail.

Description

1 WORKFLOW PROCESSING METHOD AND SYSTEM THEREOF TECHNICAL FIELD

[0001] The present disclosure relates to the field of workflow automation and intelligent data processing, and more particularly to a workflow processing method and system that integrate rulebook-driven artificial intelligence analysis, automated action execution, and blockchain- based audit verification BACKGROUND

[0002] In modern enterprise environments, organizations rely on workflow systems to manage complex operational processes. These processes often involve two categories of tasks. The first category comprises analytical tasks, including extracting requirements from policy documents, generating risk assessments, and producing compliance reports. The second category comprises execution tasks, including assigning actions to responsible owners, sending notifications, and updating records in downstream systems.

[0003] Existing workflow automation solutions typically address analysis and execution as separate, manually configured pipelines. When intelligent analysis is required, a human operator must interpret the output of an analytical tool and manually determine what actions to take and in what order. This manual intervention introduces delays, increases the risk of human error, and makes it difficult to maintain a consistent and repeatable process across the organization.

[0004] Furthermore, in regulated industries, there is an increasing demand for tamper-evident and independently verifiable audit trails that record every decision and action taken during a workflow run. Traditional audit logging mechanisms store records in centralized databases that are susceptible to modification, deletion, or unauthorized access. Such mechanisms do not provide stakeholders with the ability to independently verify, at a later date, that the recorded history has not been altered. SUMMARY

[0005] According to a first aspect, the present disclosure provides a workflow processing method.The workflow processing method includes: configuring a plurality of first rulebooks and a plurality of second rulebooks, wherein the first rulebooks are configured to describe analysis logic for input data and an output data structure for analysis results, and the second rulebooks are configured to describe an action execution flow and execution path determination conditions for at least one action; in response to a trigger event, sequentially executing N processing nodes of an orchestration flow, wherein each of the processing nodes employs a corresponding target rulebook, and output data of an n-th processing node serves as input data of an (n+1)-th processing node, where n is a positive integer between 1 and N−1; when the target rulebook corresponding to a currently executing processing node is one of the first rulebooks, driving an artificial intelligence model to perform analysis processing on the input HK 30138179 A 2 data according to the analysis logic in the target rulebook, and generating a corresponding structured analysis result in accordance with the output data structure in the target rulebook; when the target rulebook corresponding to a currently executing processing node is one of the second rulebooks, scheduling, by a workflow engine, respective pending actions according to the action execution flow in the target rulebook, and determining an execution path corresponding to each pending action based on the execution path determination conditions in the target rulebook; during execution of the orchestration flow, writing a processing record generated by each of the processing nodes as a block to a blockchain; upon completion of the orchestration flow, writing a terminal block containing summary information of all preceding blocks to the blockchain, so as to form an audit record corresponding to the orchestration flow.

[0006] In some embodiments, each of the first rulebooks is derived from, and is configured by reference to, one or more primary rules stored in a primary rule repository, the primary rules constituting authoritative source instruments that govern the organisation, including without limitation statutes, regulations, technical standards, control frameworks, operational policies and contractual instruments. The analysis logic, classification taxonomy, scoring criteria and validation conditions of each first rulebook are drawn from the one or more primary rules associated therewith, and each structured analysis result generated under a first rulebook includes a traceable reference to the primary rule, and to the clause thereof, from which the result is derived. The processing record written to the blockchain for a processing node employing a first rulebook records an identifier and a version of each primary rule relied upon, such that the audit record traces every analysis result, and every downstream action, back to the authoritative primary rule from which it originates.

[0007] In some embodiments, when the target rulebook corresponding to the currently executing processing node is one of the first rulebooks, the method further includes: after the artificial intelligence model generates the structured analysis result, verifying the structured analysis result against preset validation conditions; when the structured analysis result does not satisfy the validation conditions, feeding the structured analysis result as supplementary context together with the input data back into the artificial intelligence model to re-execute the analysis processing; and when the structured analysis result satisfies the validation conditions, determining the structured analysis result as the output data of the current processing node.

[0008] In some embodiments, when the number of times the artificial intelligence model has executed the analysis processing reaches a preset maximum iteration count, the structured analysis result is determined as the output data of the current processing node.

[0009] In some embodiments, the execution path includes an autonomous execution path and a manual execution path. When the execution path determination conditions indicate that the pending action satisfies requirements for autonomous execution, the pending action is automatically completed via the workflow engine. When the execution path determination conditions indicate that the pending action does not satisfy requirements for autonomous execution, the pending action is routed to a human operator terminal to await manual execution.

[0010] In some embodiments, writing the processing record as a block to the blockchain specifically includes: after the current (n+1)-th processing node has completed execution, HK 30138179 A 3 generating a corresponding processing record; and combining the processing record with a hash value of the block corresponding to the n-th processing node to generate a block corresponding to the current processing node, and writing the block to the blockchain.

[0011] In some embodiments, the processing record includes one or more of: a node identifier of the current processing node, a rulebook identifier of the target rulebook corresponding to the current processing node, the input data, and the output data.

[0012] In some embodiments, writing the terminal block specifically comprises: obtaining the hash value of each preceding block in the blockchain; constructing a Merkle tree based on all of the hash values; taking the hash value of the root node of the Merkle tree as the summary information; and writing the summary information into the terminal block and appending the terminal block to the blockchain.

[0013] In some embodiments, the method further includes: receiving a natural language instruction input by a user;performing semantic parsing on the natural language instruction to decompose the natural language instruction into at least one processing task; for each of the processing tasks, matching a corresponding target rulebook from among the plurality of first rulebooks and the plurality of second rulebooks; determining an execution order among the plurality of corresponding target rulebooks based on logical relationships among the processing tasks, and generating the orchestration flow; wherein the sequentially executing the N processing nodes of the generated orchestration flow is initiated in response to the trigger event.

[0014] In some embodiments, at least two of the processing tasks are permitted to be matched to a same target rulebook, and the at least two processing tasks matched to the same target rulebook are merged into a single processing node.

[0015] According to a second aspect, the present disclosure provides a workflow processing system. The workflow processing system includes a rulebook storage module, an orchestration module, an artificial intelligence module, a workflow engine, and a blockchain audit module.The rulebook storage module stores a plurality of first rulebooks and a plurality of second rulebooks. The first rulebooks are configured to describe analysis logic for input data and an output data structure for analysis results. The second rulebooks are configured to describe an action execution flow and execution path determination conditions for at least one action. The orchestration module is configured to, upon occurrence of a trigger event, invoke the artificial intelligence module and the workflow engine to sequentially execute N processing nodes of an orchestration flow. Each of the processing nodes employs a corresponding target rulebook, and output data of an n-th processing node serves as input data of an (n+1)-th processing node, where n is a positive integer between 1 and N−1. The artificial intelligence module is configured to, when the target rulebook corresponding to a currently executing processing node is one of the first rulebooks, perform analysis processing on the input data according to the analysis logic in the target rulebook, and generate a corresponding structured analysis result in accordance with the output data structure in the target rulebook. The workflow engine is configured to, when the target rulebook corresponding to a currently executing processing node is one of the second rulebooks, schedule respective pending actions according to the action execution flow in the target rulebook, and determine an execution path corresponding to each pending action based on the execution path HK 30138179 A 4 determination conditions in the target rulebook. The blockchain audit module is configured to, during execution of the orchestration flow, write a processing record generated by each of the processing nodes as a block to a blockchain, and upon completion of the orchestration flow, write a terminal block containing summary information of all preceding blocks to the blockchain, so as to form an audit record corresponding to the orchestration flow.

[0016] At least one advantage of the present disclosure is that, by configuring two types of rulebooks and chaining a plurality of processing nodes in a sequential orchestration flow in which the output of one node serves as the input of the next node, the method enables complex multi-step workflows to be executed in a repeatable and configurable manner without manual intervention between steps.Furthermore, by writing the processing record generated by each processing node as a respective block to a blockchain and appending a terminal block containing summary information of all preceding blocks upon completion of the orchestration flow, the method provides an immutable and independently verifiable audit trail that covers the entire workflow execution.

[0017] A further advantage of the present disclosure is that it is designed to keep a human at the centre of all use of the artificial intelligence model. The artificial intelligence module is confined to analysis and to the preparation of recommended actions, while the authority to execute any consequential action is reserved to a human: the execution path determination conditions are configured such that any pending action which changes a contractual right or obligation, carries a regulatory consequence, or exceeds a defined approval authority is necessarily routed to the manual execution path and withheld until a human operator provides sign-off; and the human operator is presented with the full provenance of each action - including the primary rule and clause from which it derives, the recommended decision, and the audit trail recorded so far - and retains the ability to approve, reject, escalate or override. The artificial intelligence model therefore augments rather than displaces human judgement, and every autonomous action is one that a human has, by configuration of the rulebooks, pre-authorised as low-risk. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] One or more embodiments are illustrated by way of example in corresponding drawings, which exemplary illustrations do not constitute limitations on the embodiments. Elements denoted by identical reference numerals in the drawings represent similar elements unless specifically stated otherwise, and the drawings are not necessarily drawn to scale.

[0019] FIG. 1 is a flowchart of a workflow processing method.

[0020] FIG. 2 is a flowchart of detailed processing performed by a processing node when the corresponding target rulebook is a first rulebook.

[0021] FIG. 3 is a flowchart of detailed processing performed by a processing node when the corresponding target rulebook is a second rulebook.

[0022] FIG. 4 is a flowchart of a process of generating audit information.

[0023] FIG. 5 is a flowchart of a process of generating an orchestration flow in response to a natural language instruction input by a user. HK 30138179 A 5

[0024] FIG. 6 is a functional block diagram of the workflow processing system.

[0025] FIG. 7 is a schematic diagram illustrating an end-to-end overview of the workflow processing method. DETAILED DESCRIPTION

[0026] The present application will be described in detail below in conjunction with specific embodiments. It should be emphasized that the following description is merely exemplary and is not intended to limit the scope and application of the present application.

[0027] The terms "first," "second" are used merely for descriptive purposes and should not be construed as indicating or implying relative importance or tacitly indicating the number of technical features being referenced. Thus, features defined as "first" and "second" may explicitly or implicitly include one or more such features. The term "plurality" means two or more. The term "and / or" includes any and all combinations of one or more of the associated listed items. Those skilled in the art can understand the specific meanings of the above terms in the present disclosure according to specific contexts.

[0028] FIG. 1 is a flowchart of a workflow processing method provided by an embodiment of the present application. As shown in FIG. 1, the workflow processing method includes the following steps.

[0029] S1: A plurality of first rulebooks and a plurality of second rulebooks are configured.

[0030] The first rulebooks are configured to describe analysis logic for input data and an output data structure for analysis results.The term "analysis logic" as used herein refers to the set of instructions that define what the AI module should analyse and how it should perform the analysis, including parsing rules, classification taxonomies, scoring criteria, de-duplication rules, forecasting methods, and any other analytical operations. The term "output data structure" refers to the schema definition that specifies the required fields, data types, allowable values, and formatting constraints that the analysis result must conform to.

[0031] In other words, the first rulebook is AI analysis rulebook and used to tell the AI module what data to process, what analytical procedures to apply, and what form the analysis result must take.

[0032] The term "primary rules" as used herein refers to the authoritative source instruments from which a first rulebook draws its material. Whereas a first rulebook expresses how the artificial intelligence module is to analyse input data, the primary rules constitute the ground-truth source of the requirements, obligations and criteria that the first rulebook operationalises. A first rulebook stands in a derivation relationship to one or more primary rules: its analysis logic and output data structure are configured so as to extract, classify and score the requirements contained in those primary rules, and to express each extracted element together with a citation to the originating primary rule and clause. By way of example, in the embodiments described below the suite of approved operational policies (see Table 1) and the vendor contract rules (see Table 8) each constitute primary rules, and the Policy Requirement Harvesting Rulebook and the Vendor Contract Rulebook are the respective first rulebooks derived therefrom. HK 30138179 A 6

[0033] For example, a first rulebook may instruct the AI module to analyse meeting notes and score action items by urgency and owner, with the output data structure specifying that the result must be a table containing fields for action item identifier, description, urgency score, owner name, and deadline date. Another first rulebook may instruct the AI module to ingest a set of operational policies and extract all embedded requirements, with the output data structure specifying a register format containing source policy identifier, clause reference, requirement description, responsible owner, frequency, and required evidence.

[0034] The second rulebooks are configured to describe an action execution flow and execution path determination conditions for at least one action. The term "action execution flow" as used herein refers to the sequenced list of actions that the workflow engine 640 must perform, including the ordering, dependencies, and branching logic among those actions. The term "execution path determination conditions" refers to the criteria, rules, or decision logic that determine whether a given action may proceed autonomously (i.e., without human intervention) or must be routed to a human operator for approval.

[0035] It should be understood that the "execution path determination conditions" recited herein are implemented in the present embodiments as a yes / no gate (also referred to as a gate, a gate decision, or an approval gate). That is, for a pending action identified by the orchestration flow, the execution path determination conditions are evaluated to produce a binary decision as to whether the pending action is to be executed, and the corresponding processing node proceeds along one of two execution paths accordingly: where the conditions are satisfied, the gate decision is "yes" and the pending action is executed; where the conditions are not satisfied, the gate decision is "no" and the pending action is withheld or routed to an alternative path. Accordingly, the terms "yes / no gate", "gate decision", and "approval gate" used in connection with the embodiments are particular implementations of the "execution path determination conditions", and the determination produced thereby is recorded as the execution-path determination (gate) record described above.

[0036] In other words, the second rulebook is workflow rulebooks and used to tell the workflow engine 640 what actions to perform, in what order, and under what conditions each action requires human approval versus autonomous execution.

[0037] For example, a second rulebook may instruct the workflow engine 640 to: assign scored tasks to their owners, send notification emails, and book follow-up meetings, where the execution path determination conditions specify that administrative notifications may be auto- executed, external communications require the use of a pre-approved template, and actions that change contractual obligations require human sign-off.

[0038] S2: In response to a trigger event, N processing nodes of an orchestration flow are sequentially executed.

[0039] The processing nodes of one orchestration flow are numbered 1 through N and are executed in sequential order. The output data of an n-th processing node serves as input data of an (n+1)-th processing node, where n is a positive integer between 1 and N−1.

[0040] The term "orchestration flow" refers to a defined pipeline of processing steps, where each step is driven by a specific rulebook and the outputs flow sequentially from one node to the next. The term "processing node" refers to a single execution unit within the orchestration flow. HK 30138179 A 7 Each of the processing nodes is associated with a corresponding target rulebook, and the orchestration flow may contain processing nodes that alternate between first rulebooks and second rulebooks in any order.

[0041] For example, an orchestration flow with three processing nodes might employ: a first rulebook at the first node (AI analysis), a second rulebook at the second node (workflow execution), and another first rulebook at the third node (further AI analysis on the workflow results). This flexibility allows the system to support arbitrarily complex workflows.

[0042] This chaining mechanism means that each node builds upon the work of its predecessor, enabling complex multi-step pipelines.

[0043] The "trigger event" that initiates the orchestration flow may take various forms. It may be a scheduled event (e.g., a periodic timer), a user-initiated event (e.g., a button press or command entry), or a system-generated event (e.g., a condition detected by a monitoring system).

[0044] For each processing node, the specific processing varies depending on the type of the corresponding target rulebook:

[0045] When the target rulebook corresponding to a currently executing processing node is one of the first rulebooks, an artificial intelligence model is driven to perform analysis processing on the input data according to the analysis logic in the target rulebook, and a corresponding structured analysis result is generated in accordance with the output data structure in the target rulebook.

[0046] The term "driving an artificial intelligence model" refers to invoking an AI model (which may be a large language model, a specialised analytical model, or a combination thereof) and providing it with both the analysis logic from the target rulebook and the input data received from the preceding processing node, or in the case of the first processing node in the orchestration flow, from the trigger event.

[0047] The term "perform analysis processing on the input data according to the analysis logic" means that the AI model follows the instructions defined in the first rulebook to carry out analytical operations on the input data. These operations may include, without limitation: ingesting and parsing structured or unstructured documents; extracting specific information elements; classifying extracted elements into categories; scoring elements against defined criteria; identifying responsible owners, frequencies, and deadlines; de-duplicating overlapping elements; computing forecasts or risk assessments; or generating summaries.

[0048] The term "generating a corresponding structured analysis result in accordance with the output data structure" means that the AI model's output must conform to the schema specified in the first rulebook. This ensures that the output is machine-readable, consistent, and suitable for consumption by downstream processing nodes. The structured analysis result is not free- form text but rather a defined data object with specific fields, types, and values.

[0049] When the target rulebook corresponding to a currently executing processing node is one of the second rulebooks, respective pending actions are scheduled by a workflow engine according to the action execution flow in the target rulebook, and an execution path corresponding to each pending action is determined based on the execution path determination conditions in the target rulebook. HK 30138179 A 8

[0050] The term "scheduling respective pending actions according to the action execution flow" means that the workflow engine reads the second rulebook's action execution flow, identifies all actions that need to be performed, resolves their dependencies and ordering, and queues them for evaluation and execution.

[0051] The term "pending actions" refers to the individual tasks defined in the action execution flow that have not yet been completed. These may include, without limitation: sending notifications, assigning tasks, booking meetings, updating database records, generating documents, issuing requests, escalating items, or posting results to downstream systems.

[0052] The term "determining an execution path corresponding to each pending action based on the execution path determination conditions" means that for each pending action, the workflow engine evaluates the conditions defined in the second rulebook to decide how the action should proceed.

[0053] S31: During execution of the orchestration flow, at least one processing record generated by each of the processing nodes is written as a respective block to a blockchain.

[0054] The term "blockchain" as used herein refers to a sequential chain of cryptographically linked records (blocks), where each block contains the hash of the previous block, thereby creating an append-only, tamper-evident ledger. A blockchain overlay is applied on top of every rulebook execution so that each recorded processing activity is written as a cryptographically linked block.

[0055] The term "processing record" refers to a data payload that captures a processing activity occurring at a given processing node, including one or more of the identity of the rulebook invoked, the input received, the output produced, and a timestamp indicating when the processing occurred. It should be understood that a single processing node may give rise to one or more processing records, depending on the granularity of the processing activities performed at that node.

[0056] S32: Upon completion of the orchestration flow, a terminal block containing summary information of all preceding blocks is written to the blockchain, so as to form an audit record corresponding to the orchestration flow.

[0057] The term "terminal block" refers to the closing block of the blockchain, which serves as a cryptographic seal for the entire orchestration flow. In this step, once all processing nodes in the orchestration flow have completed execution, a terminal block that seals the audit trail is generated and written to the blockchain as the final block in the chain. The terminal block contains summary information of all preceding blocks in the chain, thereby enabling a verifier to confirm the integrity of the entire chain without needing to inspect every individual block.

[0058] The term "summary information" refers to a compact cryptographic representation of each block in the chain. In one embodiment, the summary information comprises a hash value computed over the contents of all preceding blocks, such that any modification to any preceding block would result in a detectable inconsistency.

[0059] The term "audit record corresponding to the orchestration flow" refers to the complete blockchain formed during a single orchestration flow, including the genesis block, all intermediate blocks generated by the respective processing nodes, and the terminal block. HK 30138179 A 9 Together, these blocks constitute an immutable and independently verifiable record of the entire workflow execution.

[0060] FIG. 2 is a flowchart illustrating the detailed processing of a processing node when the corresponding target rulebook is a first rulebook. As shown in FIG. 2, the processing includes the following steps:

[0061] S211: An artificial intelligence model is driven to perform analysis processing on the input data according to the analysis logic in the target rulebook, and a corresponding structured analysis result is generated in accordance with the output data structure in the target rulebook.

[0062] S212: It is determined whether the structured analysis result satisfies preset validation conditions.

[0063] The term "preset validation conditions" refers to a set of rules that define what constitutes a valid output from a processing node. The preset validation conditions may include one or more of the following: schema conformance checks (verifying that all required fields are present and of a correct data type); value range checks (verifying that numerical values fall within allowable ranges); completeness checks (verifying that no required elements are missing); consistency checks (verifying that related fields do not contradict each other); and format checks (verifying that dates, identifiers, and other formatted values comply with expected patterns).

[0064] S213: When the structured analysis result satisfies the validation conditions, the structured analysis result is determined as the output data of the current processing node.

[0065] S214: When the structured analysis result does not satisfy the validation conditions, it is further determined whether the number of times the artificial intelligence model has executed the analysis processing has reached a preset maximum iteration count.

[0066] S215: When the maximum iteration count has not been reached, the structured analysis result is fed as supplementary context together with the input data back into the artificial intelligence model, and step S211 is re-executed.

[0067] The term "feeding the structured analysis result as supplementary context together with the input data back into the artificial intelligence model" refers to an iterative correction mechanism. When the validation fails, the AI model receives not only the original input data again but also its previous (failed) output together with information about which validation conditions were not met.

[0068] This additional context enables the AI model to understand what was wrong with its previous attempt and to produce a corrected output in the next iteration. The AI module is instructed to call the validation tools and update its output based on the responses received from the validation tools in a loop until all output conditions are passed.

[0069] S216: When the maximum iteration count has been reached, the most recent structured analysis result is determined as the output data of the current processing node.

[0070] The preset maximum iteration count serves as a safety bound that ensures the orchestration flow can always progress within a finite time. If the maximum iteration count is reached, the most recent structured analysis result (which may partially satisfy the validation conditions) is accepted as the output data and passed to the next processing node. HK 30138179 A 10

[0071] FIG. 3 is a flowchart illustrating the detailed processing of a processing node when the corresponding target rulebook is a second rulebook. As shown in FIG. 3, the processing includes the following steps:

[0072] S221: Respective pending actions are scheduled by a workflow engine according to the action execution flow in the target rulebook.

[0073] S222: For each pending action, the execution path determination conditions corresponding to the pending action are obtained.

[0074] The execution path determination conditions are the specific rules defined in the second rulebook that govern whether a particular action may be self-executed by the system or must involve a human. These conditions may relate to: the risk level of the action (e.g., low-risk administrative actions may be automated); the action classification (e.g., internal notifications versus external communications); approval authority thresholds (e.g., actions involving expenditure above a threshold require committee approval); template availability (e.g., external communications may only be auto-sent if a pre-approved template exists); regulatory implications (e.g., any action that constitutes a regulatory notification requires human sign-off); or any other configurable criteria.

[0075] S223: It is determined whether the pending action satisfies requirements for autonomous execution based on the execution path determination conditions.

[0076] S224: When the pending action satisfies the requirements for autonomous execution, the execution path corresponding to the pending action is determined as an autonomous execution path, and the pending action is automatically completed via the workflow engine.

[0077] Examples of actions that typically follow the autonomous execution path include: sending deadline reminders to named owners, issuing attestation forms, refreshing access review packs, updating the obligations register or GRC system, sending internal escalation notifications, and assigning tasks using standard templates.

[0078] S225: When the pending action does not satisfy the requirements for autonomous execution, the execution path corresponding to the pending action is determined as a manual execution path, and the pending action is routed to a human operator terminal to await manual execution.

[0079] Examples of actions that typically follow the manual execution path include: drafting committee papers for non-compliance, preparing regulatory notifications, approving deviations from policy, sending external communications that change contractual rights, and any action where the contract value or risk level exceeds the defined approval authority.

[0080] It should be understood that the foregoing execution-path mechanism embodies a design principle whereby a human is kept at the centre of all use of the artificial intelligence model. The division of responsibility between the artificial intelligence module 630 and the workflow engine 640 ensures that the artificial intelligence model performs analysis and proposes actions but does not itself execute consequential actions; rather, autonomous execution is permitted only for those classes of action that a human has, through configuration of the second rulebooks and their execution path determination conditions, designated in advance as suitable for automation. All remaining actions are routed to a human operator terminal, where the operator is furnished with the context necessary to exercise informed judgement and may HK 30138179 A 11 approve, reject, escalate or override the proposed action. The blockchain audit record further reinforces this principle by attributing every gate decision and every executed action to an identified actor, whether the workflow engine acting under delegated authority or a named human approver.

[0081] FIG. 4 is a flowchart illustrating the detailed process of generating audit information and writing it to the blockchain. As shown in FIG. 4, the process includes the following steps:

[0082] During the execution of the orchestration flow, for each processing node that has completed execution, the following steps S311 and S312 are performed. In the following, the currently completed processing node is referred to as the n-th processing node, where n is a positive integer between 1 and N.

[0083] S311: After the n-th processing node has completed execution, at least one corresponding processing record is generated.

[0084] Specifically, each processing record includes at least one of: a node identifier of the n-th processing node; a rulebook identifier of the target rulebook corresponding to the n-th processing node; the input data; and the output data.

[0085] S312: The processing record is combined with a hash value of the block corresponding to the immediately preceding processing activity to generate a block corresponding to the n-th processing node, and the block is written to the blockchain.

[0086] The term "combining the processing record with a hash value of the block corresponding to the immediately preceding processing activity" means that the new block is cryptographically linked to its predecessor. Specifically, the block corresponding to the current processing record includes a "previous_hash" field that stores the block_hash of the immediately preceding block. This linkage creates the chain: any alteration to a historical block would change its block_hash, which would cause a mismatch with the previous_hash stored in the subsequent block, thereby making the tampering detectable. The above linkage mechanism applies to all blocks of the chain, including the first block generated by the first processing node (n=1), whose immediately preceding block is the genesis block.

[0087] In the case of the first processing node (n=1), the block corresponding to the immediately preceding processing activity is the genesis block. The genesis block is generated and written to the blockchain when the trigger event initiates execution of the orchestration flow. Where the orchestration flow is generated from a natural language instruction as described below, the semantic parsing of the natural language instruction and the generation of the orchestration flow are completed beforehand, and the genesis block is written when the trigger event subsequently initiates execution of the generated orchestration flow. The genesis block captures information including the trigger type, a timestamp, and an identifier of the initiating system or user. The genesis block thereby anchors the entire blockchain to a verifiable start point of the orchestration flow.

[0088] Upon completion of the orchestration flow, the following steps S321 through S324 are performed:

[0089] S321: The hash value of each preceding block in the blockchain is obtained.

[0090] S322: A Merkle tree is constructed based on all of the hash values. HK 30138179 A 12

[0091] The term "Merkle tree" refers to a binary tree data structure in which every leaf node contains the hash of a data block (i.e., the block_hash of a preceding block) and every non-leaf node contains the hash of its two child nodes.

[0092] S323: The hash value of the root node of the Merkle tree is taken as the summary information.

[0093] The root node of the Merkle tree (i.e., the Merkle root) is therefore a single hash value that cryptographically summarises all blocks in the chain.

[0094] S324: The summary information is written into a terminal block, and the terminal block is appended to the blockchain.

[0095] Any alteration to any preceding block would change that block's hash, which would propagate up through the tree and result in a different Merkle root value, thereby making any tampering immediately detectable. Including the Merkle root in the terminal block allows efficient integrity verification: a verifying party can confirm the integrity of the entire chain by comparing the recomputed Merkle root against the stored value. Because the security of this integrity seal rests on the collision resistance of the underlying hash function, rather than on any public-key hardness assumption, the Merkle-tree seal is comparatively robust against attack by a quantum computer: the best known quantum attack on a well-constructed cryptographic hash function is a Grover-type search conferring only a quadratic speed-up, which is readily countered by an appropriate choice of digest length as described following. The hash-based integrity seal is therefore a long-term strength of the present design.

[0096] In some embodiments, the blockchain audit module 650 is cryptographically agile, and each block records an algorithm identifier specifying the hash function and, where applicable, the signature scheme used to generate that block. The hash function used to compute the block_hash, the version hash and the Merkle tree, and any signature scheme used to sign a block or a timestamp, may be selected from quantum-resistant (post-quantum) algorithms, so as to preserve the tamper-evidence of the audit record against an adversary having access to a quantum computer. For example, the hash function may employ a digest length sufficient to resist a Grover-type search (e.g., a 384-bit or 512-bit digest), and any digital signature applied to a block or timestamp may employ a post-quantum signature scheme such as a lattice-based or hash-based scheme. The recording of the algorithm identifier in each block enables the algorithms to be migrated over time without invalidating previously written blocks, thereby protecting long-lived audit records against a "harvest-now, verify-later" adversary.

[0097] For the purpose of integrity verification, the blocks of the blockchain are indexed sequentially from a genesis block (index 0), through the processing-record blocks generated during execution of the N processing nodes, to the terminal block. It should be noted that, because a single processing node may generate one or more processing-record blocks as described above, the total number of blocks in the chain is generally greater than the number N of processing nodes, and the terminal block is the final block of the chain. In the present disclosure, N denotes the number of processing nodes of the orchestration flow and does not denote the index of the terminal block.

[0098] Based on the above chain structure, any authorised party may verify the integrity of a given workflow run by performing the following operations. The verifying party retrieves the HK 30138179 A 13 blockchain corresponding to the workflow run identifier. For each block in the chain, the verifying party recomputes the block_hash from the fields contained in that block and confirms that the recomputed value matches the stored block_hash, and further confirms that the previous_hash field in that block matches the block_hash of the immediately preceding block. In an embodiment in which each block additionally stores a timestamp_hash as described below, the verifying party further confirms , using the public key of the Time Stamp Authority, that the Time Stamp Authority’s signature over the timestamp_hash of that block is valid, and that the value so authenticated matches the block_hash stored in that block. Additionally, to verify any particular block in the chain without having to recalculate the hash of every step, the verifying party recomputes the hash for the nodes in the Merkle tree between the block of interest and the root and confirms that the recomputed value matches the Merkle root stored in the terminal block. If all of the above checks pass, the audit record is verified as unaltered. A mismatch at any step indicates that tampering has occurred at the corresponding point in the chain.

[0099] It will be appreciated that, whereas the chain-of-hashes and the Merkle-tree integrity seal described above depend only on the collision resistance of the hash function and are therefore comparatively robust against quantum attack, the Time Stamp Authority’s signature, and any other public-key digital signature applied to a block, depends on a public-key hardness assumption and is therefore vulnerable to an adversary having access to a sufficiently large quantum computer (for example, by application of Shor’s algorithm). Accordingly, in some embodiments the signature applied to a timestamp or to a block is generated using a quantum- resistant digital signature scheme, such as a NIST-standardised post-quantum signature scheme (for example, a lattice-based scheme such as ML-DSA, or a hash-based scheme such as SLH-DSA), and the algorithm identifier recorded in the block as described in

[0100] identifies the signature scheme used. Recording the scheme identifier in each block enables a verifying party to select the correct verification procedure, and permits the signature scheme to be migrated to a stronger scheme over time without invalidating previously written blocks, thereby preserving the verifiability of long-lived audit records against a “harvest-now, verify- later” adversary.

[0100] FIG. 5 is a flowchart illustrating the process of generating an orchestration flow in response to a natural language instruction input by a user. As shown in FIG. 5, prior to executing the orchestration flow, the method further includes the following steps:

[0101] S41: A natural language instruction input by a user is received.

[0102] S42: Semantic parsing is performed on the natural language instruction to decompose the natural language instruction into at least one processing task.

[0103] The term "semantic parsing" refers to the process of analysing the natural language instruction to identify the distinct operational intents contained therein and to decompose the natural language instruction into corresponding processing tasks. For example, if a user enters the instruction "Read every approved operational policy, extract the requirements and obligations from each policy, build a consolidated required-actions register, route each action for approval, and execute permitted actions using the approved templates," the semantic parsing process identifies five distinct processing tasks: (1) reading policies, (2) extracting HK 30138179 A 14 requirements, (3) building a register, (4) routing for approval, and (5) executing actions. Each identified processing task is subsequently mapped to a corresponding processing node in the orchestration flow.

[0104] S43: For each of the processing tasks, a corresponding target rulebook is matched from among the plurality of first rulebooks and the plurality of second rulebooks.

[0105] The term "matching a corresponding target rulebook" refers to the process of identifying, from the stored collection of first and second rulebooks, which rulebook is best suited to accomplish each identified processing task.

[0106] S44: It is determined whether at least two of the processing tasks are matched to a same target rulebook.

[0107] S45: When at least two of the processing tasks are matched to the same target rulebook, the at least two processing tasks are merged into a single processing node.

[0108] This means that if the semantic parsing identifies multiple tasks (e.g., "harvest requirements" and "build a consolidated register") that are both governed by the same rulebook (e.g., the Policy Requirement Harvesting Rulebook), these tasks are combined into one processing node rather than being executed as separate nodes invoking the same rulebook redundantly. This optimisation avoids unnecessary duplication of AI model invocations and ensures that logically related tasks governed by the same rules are handled efficiently in a single pass.

[0109] S46: An execution order among the plurality of corresponding target rulebooks is determined based on logical relationships among the processing tasks, and the orchestration flow is generated.

[0110] The term "determining an execution order" refers to the process of arranging the matched target rulebooks into a sequential pipeline based on the logical dependencies among the tasks. Tasks that produce outputs needed by subsequent tasks are placed earlier in the sequence.

[0111] The present disclosure further provides a workflow processing system for implementing the above-described method. As shown in FIG. 6, the workflow processing system 60 includes a rulebook storage module 610, an orchestration module 620, an artificial intelligence module 630, a workflow engine 640, and a blockchain audit module 650.

[0112] The rulebook storage module 610 stores a plurality of first rulebooks and a plurality of second rulebooks. Each of the first rulebooks defines analysis logic for input data and an output data structure for analysis results. Each of the second rulebooks defines an action execution flow and execution path determination conditions for at least one action.

[0113] In some embodiments, the rulebook storage module 610 maintains a versioned repository of all rulebooks. Each rulebook is stored with a unique rulebook identifier, a version number, a version hash (computed over the rulebook content using SHA-256), a creation timestamp, and an author identifier. The rulebook storage module supports version management operations including creation of new rulebooks, updating existing rulebooks (which creates a new version), retrieval of specific versions, and retrieval of the latest approved version.

[0114] In terms of content, the first rulebooks stored in the rulebook storage module 610 each define: the scope of analysis (specifying what data to analyse and from which sources); the HK 30138179 A 15 analysis logic (specifying how to analyse the data, including parsing rules, classification taxonomies, scoring criteria, de-duplication rules, and other analytical operations); callable validation tools and instructions for their use (specifying the validation functions available and how the AI module should invoke them); and the output data structure (specifying the schema, required fields, data types, allowable values, and formatting constraints that the output must conform to).

[0115] In some embodiments, the rulebook storage module 610 further stores a plurality of primary rules in a versioned primary rule repository, together with linkage data recording, for each first rulebook, the one or more primary rules from which that first rulebook is derived. When a primary rule is created or updated, the rulebook storage module 610 identifies, from the linkage data, each first rulebook derived from the affected primary rule and flags that first rulebook for revalidation, so that the analysis logic remains consistent with the current version of its primary rules. When the orchestration module 620 requests a first rulebook, the rulebook storage module 610 returns the latest approved version of that first rulebook together with the identifiers and versions of the primary rules from which it is derived, for inclusion in the corresponding processing record.

[0116] The second rulebooks stored in the rulebook storage module 610 each define: the sequenced list of actions constituting the action execution flow; the dependencies and ordering constraints among actions; the execution path determination conditions for each action (including criteria for autonomous execution versus manual execution); approved templates to be used for specific action types; escalation rules for overdue or blocked actions; and references to downstream rulebooks that may be triggered upon completion of specific actions.

[0117] The orchestration module 620 is configured to, upon occurrence of a trigger event, sequentially execute N processing nodes of an orchestration flow by selectively invoking the artificial intelligence module 630 or the workflow engine 640 according to the type of target rulebook corresponding to each processing node. Each of the processing nodes employs a corresponding target rulebook, and output data of an n-th processing node serves as input data of an (n+1)-th processing node, where n is a positive integer between 1 and N−1. When the orchestration module 620 requests a target rulebook from the rulebook storage module 610 for execution at a processing node, the rulebook storage module 610 returns the latest approved version of the requested rulebook unless a specific version is explicitly designated.

[0118] The artificial intelligence module 630 is configured to, when the target rulebook corresponding to a currently executing processing node is one of the first rulebooks, perform analysis processing on the input data according to the analysis logic in the target rulebook, and generate a corresponding structured analysis result in accordance with the output data structure in the first rulebook.

[0119] The workflow engine 640 is configured to, when the target rulebook corresponding to a currently executing processing node is one of the second rulebooks, schedule respective pending actions according to the action execution flow in the target rulebook, and determine an execution path corresponding to each pending action based on the execution path determination conditions in the target rulebook. HK 30138179 A 16

[0120] The blockchain audit module 650 is configured to, during execution of the orchestration flow, write a processing record generated by each of the processing nodes as a block to a blockchain, and upon completion of the orchestration flow, write a terminal block containing summary information of all preceding blocks to the blockchain, so as to form an audit record corresponding to the orchestration flow.

[0121] It should be noted that the workflow processing system described in the present embodiment is configured to implement the workflow processing method described in the foregoing method embodiments. For details not elaborated herein regarding the specific implementation of each module, reference may be made to the corresponding descriptions in the above method embodiments, which are incorporated herein and not repeated for the sake of brevity.

[0122] FIG. 7 is a schematic diagram illustrating an end-to-end overview of the workflow processing method. The left-hand portion of FIG. 7 represents the sequential execution of the orchestration flow, and the right-hand portion represents the blockchain ledger that is written in parallel therewith, the dashed arrows indicating the writing of a respective block in response to a corresponding processing activity. FIG. 7 thereby illustrates the correspondence between the individual processing activities of the orchestration flow and the respective blocks written to the blockchain.

[0123] As shown in FIG. 7, execution of the orchestration flow is initiated by a trigger event, which may be an event-based trigger or a schedule-based trigger. In response to the trigger event, a genesis block recording a trigger hash and a timestamp is written to the blockchain ledger.

[0124] A first processing node employs a first rulebook (denoted "Rulebook A" in FIG. 7), which instructs the artificial intelligence module to perform analysis processing on the input data, such as analysing, forecasting, and summarising. The invocation of the first rulebook is recorded as a block storing the rulebook identifier and the previous hash, and the structured analysis result produced by the artificial intelligence module is recorded as a further block storing an output hash and associated metadata.

[0125] The output of the first processing node is passed as the input of a second processing node, and this chain handoff is itself recorded as a block. The second processing node employs a second rulebook (denoted "Rulebook B" in FIG. 7), which reads the action list and the decision gates, the invocation of the second rulebook being recorded as a block storing the rulebook identifier and an input hash.

[0126] For each pending action, the execution path determination condition is evaluated in the form of a yes / no gate (shown as "Auto-approve?" in FIG. 7). Where the gate decision is "yes", the pending action follows the autonomous execution path and is self-executed by the workflow engine, for example to book, notify, or update; where the gate decision is "no", the pending action follows the manual execution path and is routed for human approval, for example for review, confirmation, or override. The gate decision is recorded as a block storing the gate result and a corresponding reason, and the execution of the action is recorded as a further block storing an action hash, an actor, and an outcome.

[0127] Optionally, the orchestration flow may chain a further rulebook (denoted "Rulebook C" in FIG. 7) as a successive processing node, thereby supporting arbitrarily long pipelines as HK 30138179 A 17 described above. Upon completion of the orchestration flow, a terminal block is written, the terminal block storing the Merkle root and a chain hash that seal the entire audit trail.

[0128] It should be understood that the block labels and the number of blocks shown in FIG. 7 are illustrative only.

[0129] In order to more clearly illustrate the technical solution of the present invention, two specific embodiments are described in detail below. The first embodiment demonstrates how the system harvests requirements from operational policies and executes the resulting actions. The second embodiment demonstrates how the system applies a vendor contract rulebook, automates permitted steps by reference to a database, and verifies each step using blockchain records. It should be understood that these embodiments are provided for the purpose of explanation only and are not intended to limit the scope of the present invention.

[0130] First Embodiment: Harvesting Requirements from Operational Policies and Executing Required Actions

[0131] This embodiment provides a concrete example of how the workflow processing system processes a portfolio of approved operational policies. In this embodiment, the orchestration flow includes a plurality of processing nodes that sequentially extract requirements and obligations from the policies, classify the resulting actions, route them to accountable owners, apply approval gates, and execute permitted actions.

[0132] In this embodiment, the company maintains a suite of operational policies that collectively define how the business must operate. These policies span multiple domains, including information security, data protection, business continuity, outsourcing, financial crime, conduct, risk, complaints handling, training, and change management.

[0133] In this embodiment, the orchestration flow comprises two chained processing nodes. The first processing node employs a first rulebook, referred to herein as the "Policy Requirement Harvesting Rulebook." The second processing node employs a second rulebook, referred to herein as the "Action Execution Rulebook." The output of the first processing node serves as the input to the second processing node, such that requirements extracted by the first processing node are directly consumed by the second processing node for execution.

[0134] The Policy Requirement Harvesting Rulebook defines the analysis logic for extracting requirements from operational policies and the output data structure for the extracted results. Specifically, the Policy Requirement Harvesting Rulebook contains a taxonomy that classifies operational policies by domain, identifies the categories of requirements they typically contain, and assigns the accountable owner for each domain. To illustrate the structure of this taxonomy, Table 1 below sets out the policy domains defined in the Policy Requirement Harvesting Rulebook, together with an example policy for each domain, the typical categories of embedded requirements, and the corresponding accountable owner.

[0135] Table 1 Policy domain Example policy Embedded requirements Accountable owner Information security Information Security Policy Access reviews, password resets, patching cadence, encryption standards, vulnerability management Chief Information Security Officer HK 30138179 A 18 Policy domain Example policy Embedded requirements Accountable owner Data protection Data Protection / Privacy Policy DPIA triggers, data retention, subject access response times, breach notification timelines Data Protection Officer Business continuity Business Continuity Policy BCP test cadence, RTO / RPO confirmations, supplier resilience checks, scenario testing Chief Operating Officer Vendor and outsourcing Outsourcing Policy Materiality reviews, due diligence refresh, exit plans, regulator notifications Procurement Lead Financial crime AML / CTF Policy KYC refresh, sanctions screening cadence, suspicious matter reporting, training cycles Money Laundering Reporting Officer Conduct and ethics Code of Conduct Conflicts attestations, gifts and hospitality register, whistleblowing channel checks Chief Compliance Officer Risk management Risk Management Policy Risk register reviews, control attestations, KRI monitoring, risk appetite reporting Chief Risk Officer Complaints and dispute Complaints Handling Policy Acknowledgement timeframes, root-cause review, regulator reporting thresholds Customer Officer HR and training Training and Competency Policy Mandatory training cycles, attestations, license renewals Head of Human Resources Change management Change Management Policy Change advisory board sign-off, risk-rated approvals, post- implementation review Head of Change

[0136] During execution of the first processing node, the artificial intelligence module 630 performs analysis processing according to the Policy Requirement Harvesting Rulebook. Specifically, the artificial intelligence module 630 is instructed to:

[0137] ingest each approved operational policy in the policy library; parse the policy structure (purpose, scope, roles, controls, frequencies, evidence, and escalation rules); extract every discrete requirement, obligation, or mandated activity; classify each requirement by type (preventive control, detective control, attestation, training, reporting, review, or notification); identify the responsible owner, frequency, deadline, and required evidence; tag each requirement with the source policy identifier, version, and clause reference; de-duplicate overlapping requirements that appear in more than one policy; and produce a structured Required Actions Register conforming to the output data structure defined in the Policy Requirement Harvesting Rulebook.

[0138] The Action Execution Rulebook defines the action execution flow for processing the Required Actions Register and the execution path determination conditions for each action therein. During execution of the second processing node, the workflow engine 640 schedules and routes actions according to the Action Execution Rulebook. Specifically, the workflow engine 640 is instructed to:

[0139] ingest the Required Actions Register produced by the first processing node; classify each action by execution mode (automated, semi-automated, human approval, or control owner HK 30138179 A 19 only); assign each action to the named owner; raise an approval task where the action requires sign-off; execute permitted actions using approved templates; capture the outcome and the evidence reference for each completed action; update the consolidated obligations register or Governance, Risk and Compliance system; escalate overdue or blocked actions to the next approval level; and trigger downstream rulebooks where the action requires regulatory notification or committee escalation.

[0140] In the first embodiment, the orchestration flow is generated from a natural language instruction submitted by the administrator. The natural language instruction is as follows:

[0141] "Read every approved operational policy, harvest the requirements and obligations embedded in each, build a consolidated required-actions register, route each action for approval where it is needed, execute permitted actions using the approved templates and capture evidence and update the register "

[0142] Upon receiving the natural language instruction, the orchestration module 620 performs semantic parsing on the natural language instruction in accordance with step S42. The semantic parsing identifies six discrete command elements within the instruction, each expressing a distinct processing objective. The orchestration module 620 then matches each command element to a target rulebook in the rulebook library based on semantic correspondence between the command element and the rulebook's declared scope.

[0143] Table 2 below illustrates the decomposition result, showing each command element extracted from the natural language instruction, the system interpretation assigned to it by the orchestration module 620, and the target rulebook to which it is matched.

[0144] Table 2 Command element System interpretation Rulebook used Read every approved operational policy Retrieve the policy library and load latest approved versions only Policy Requirement Harvesting Rulebook Harvest the requirements and obligations Extract and classify every mandated activity from each policy Policy Requirement Harvesting Rulebook Build a consolidated required- actions register Generate a structured action register, de-duplicated across policies Policy Requirement Harvesting Rulebook Route each action for approval where needed Apply yes / no gates by action class and risk level Action Execution Rulebook Execute permitted actions Self-execute approved actions using approved templates Action Execution Rulebook Capture evidence and update the register Record outcome and write evidence reference back to obligations register Action Execution Rulebook

[0145] As shown in Table 2, the semantic parsing yields six command elements. The first three are matched to the Policy Requirement Harvesting Rulebook and are merged into the first processing node in accordance with step S45. The remaining three are matched to the Action Execution Rulebook and are merged into the second processing node. The orchestration module 620 determines the execution order based on data dependency. Specifically, the second processing node requires as input the Required Actions Register produced by the first processing node, and therefore must execute after the first processing node. Accordingly, the orchestration module 620 generates the orchestration flow with N=2 sequentially chained processing nodes. HK 30138179 A 20

[0146] The operation of the first embodiment is now described with reference to a specific worked example. In this example, the orchestration flow includes two processing nodes (N=2): a first processing node associated with the Policy Requirement Harvesting Rulebook and a second processing node associated with the Action Execution Rulebook.

[0147] Upon receiving the natural language instruction described in paragraph

[0140] , the orchestration module 620 first performs semantic parsing to decompose the instruction into processing tasks, matches each task to a target rulebook, merges tasks matched to the same rulebook, and determines the execution order, thereby generating the orchestration flow having N=2 sequentially chained processing nodes. The trigger event then initiates execution of the generated orchestration flow, whereupon blockchain audit module 650 writes a genesis block (Block 0) to the blockchain, recording that the operational policy harvest workflow has been triggered. The orchestration flow then commences execution sequentially through the processing nodes.

[0148] The first processing node invokes the Policy Requirement Harvesting Rulebook. A block is written to the blockchain recording the rulebook identifier and version (v1.2). The AI module 630, operating under the instructions defined in the first rulebook, retrieves the latest approved versions of the operational policies, which in this example include: Information Security Policy v3.2; Data Protection Policy v2.4; Business Continuity Policy v1.7; Outsourcing Policy v2.1; AML / CTF Policy v4.0; Code of Conduct v1.5; Risk Management Policy v3.0; Complaints Handling Policy v2.2; Training and Competency Policy v1.9; and Change Management Policy v2.6.

[0149] The AI module 630 parses each policy document, extracts mandated activities, and produces a structured analysis result in the form of a Required Actions register. Table 3 below shows a representative sample of the Required Actions register. Each row corresponds to one harvested action item, and the columns record the action identifier, source policy, originating clause, requirement description, mandated frequency, designated owner, and required evidence type.

[0150] Table 3 Action ID Source policy Clause Requirement Frequency Owner Required evidence ACT- 0014 Information Security Policy 6.3 Privileged user access review Quarterly CISO Signed access review report ACT- 0027 Data Protection Policy 4.5 Records of Processing Activity refresh Annual DPO Updated ROPA and DPIA log ACT- 0041 Business Continuity Policy 5.1 BCP scenario test for critical processes Annual COO Test report and lessons learned ACT- 0053 Outsourcing Policy 7.2 Material vendor exit-plan refresh Annual Procurement Lead Signed exit plan HK 30138179 A 21 Action ID Source policy Clause Requirement Frequency Owner Required evidence ACT- 0066 AML / CTF Policy 8.4 High-risk customer KYC refresh Annual MLRO KYC review record ACT- 0072 Code of Conduct 3.2 Conflicts of interest attestation cycle Annual CCO Signed attestations register ACT- 0088 Risk Management Policy 9.1 Control owner attestation cycle Half-yearly CRO Signed attestations ACT- 0094 Complaints Handling Policy 4.4 Complaints root- cause analysis review Quarterly Customer Officer Trend analysis report ACT- 0107 Training and Competency Policy 6.1 Mandatory training completion check Quarterly HR Lead LMS completion report ACT- 0119 Change Management Policy 5.5 Post- implementation review of high-risk changes Per change Head of Change PIR report

[0151] The structured analysis result is verified by the validation tool against the preset validation conditions defined in the first rulebook. Upon passing validation, the Required Actions register is determined as the output data of the first processing node. A block is written to the blockchain recording the output hash.

[0152] Upon completion of the first processing node, the orchestration module performs the chain handoff. The output data of the first processing node (i.e., the Required Actions register) is passed as the input data to the second processing node. A block is written to the blockchain recording the source rulebook, destination rulebook, and data hash.

[0153] The second processing node invokes the Action Execution Rulebook. A block is written to the blockchain recording the rulebook identifier and version. The workflow engine 640 reads the action execution flow defined in the second rulebook and classifies each harvested action according to the execution path determination conditions specified therein. Table 4 below illustrates the classification logic:

[0154] Table 4 Action class Example action Execution mode Approval gate Administrative reminder Notify owner of upcoming deadline Automated None - auto-execute Evidence request Request signed attestation from control owner Automated Approved template only Internal notification Send escalation to control owner Automated None Register update Update obligations register or GRC record Automated None External communication Send vendor exit-plan refresh request Semi-automated Owner approval before send HK 30138179 A 22 Action class Example action Execution mode Approval gate Committee paper Draft committee paper for non- compliance Semi-automated Owner and Secretariat approval Regulatory notification Submit breach notification to regulator Manual approval MLRO and Compliance Officer Policy waiver request Approve a deviation from policy Manual approval Policy Owner and Risk Committee

[0155] As shown in Table 4, actions classified as "Automated" are executed by the workflow engine 640 autonomously within its defined permissions. Actions classified as "Semi- automated" or "Manual approval" require human sign-off before execution. Table 5 below provides examples of the agentic AI execution behaviour for permitted actions.

[0156] Table 5 Task Agentic AI action Human approval required? Send deadline reminder Generates and sends reminder email to the named owner No Request attestation Issues attestation form and tracks completion No Refresh access review pack Compiles privileged access list and sends to CISO No Draft committee paper Generates draft non-compliance paper for committee review Yes - Owner and Secretariat Draft regulatory notification Prepares draft notification using approved template Yes - Compliance Officer Update obligations register Writes new status, owner and due date to register No Escalate overdue action Sends escalation to next approval level No Recommend policy waiver Drafts waiver request with rationale for review Yes - Policy Owner

[0157] For actions that require human sign-off, the system presents an approval task to the designated human approver. The approval task surfaces the following information: the action ID and a plain-language extract of the requirement; the source policy ID, version and clause reference; the proposed action and the template that will be used; the supporting evidence already on file; the system's recommended approve, reject or escalate decision; and the audit trail recorded so far in the workflow run.

[0158] Upon receiving an approval decision, the workflow engine 640 executes the action using the approved template, captures the outcome, and writes the evidence reference back to the obligations register. Upon receiving a rejection decision, the workflow engine 640 reroutes the action to an alternative approver or returns the action to the owner for re-work, and the rejection reason is recorded in the blockchain.

[0159] After each action fires, the workflow engine updates the consolidated obligations register so that the live status of every harvested requirement is visible at any time. Table 6 below shows an example of the register state after partial execution.

[0160] Table 6 HK 30138179 A 23 Action ID Previous status Updated status Evidence reference ACT-0014 Due Completed (auto) Access review report 0014- Q1 ACT-0027 Open In progress (DPO) DPO assignment notice ACT-0041 Due Approval pending Draft test plan ACT-0053 Overdue Escalated to Risk Committee Committee paper draft ACT-0066 Open Assigned to MLRO KYC refresh task ACT-0072 Due Attestations issued (auto) Attestation campaign 0072 ACT-0088 Open Assigned to control owners Attestation campaign 0088 ACT-0094 Due Trend report drafted Draft report ID 0094-Q1 ACT-0107 Due LMS report requested LMS report ID 0107-Q1 ACT-0119 Open Auto-monitored, awaiting trigger Change pipeline reference

[0161] Throughout the execution of both processing nodes, each step is written to the blockchain audit overlay. Table 7 below shows the complete sequence of blockchain events for this worked example.

[0162] Table 7 Block Event Example record 0 Genesis trigger Operational policy harvest workflow triggered 1 Rulebook invoked Policy Requirement Harvesting Rulebook v1.2 invoked 2 Policy library scan Ten approved policies loaded; library hash recorded 3 AI output Required Actions register generated; output hash recorded 4 Chain handoff Register passed to Action Execution Rulebook 5 Workflow rulebook invoked Action Execution Rulebook v2.0 invoked 6 Gate decision ACT-0014 classified as automated; auto-execute permitted 7 Action executed Privileged access review reminder sent to CISO 8 Gate decision ACT-0053 requires human approval 9 Human approval Risk Committee Chair approves committee paper 10 Action executed Committee paper issued; evidence reference recorded 11 Register update Obligations register updated; update hash recorded 12 Gate decision ACT-0066 routed to MLRO for execution 13 Action executed KYC refresh task assigned to MLRO Terminal Workflow close Final Merkle root and chain hash recorded

[0163] Upon completion of the orchestration flow, the workflow processing system generates a verifiable end-to-end record documenting: which operational policies were scanned and at which version; which requirements were harvested from each policy; which clause of which policy each action traces back to; which actions were classified as automated; which actions required human approval; who approved each restricted action; which actions were executed and when; which evidence was captured against each completed action; which obligations register fields were updated; and whether the final record has been tampered with.

[0164] Second embodiment: Vendor Contract Rulebook, Agentic AI Automation, Database Reference and Blockchain Verification HK 30138179 A 24

[0165] The second embodiment provides a concrete example of how the system uses a vendor contract rulebook to identify required actions under vendor contract rules, uses the AI module to automate the process by reference to a database, and uses blockchain records to verify each step.

[0166] The second embodiment assumes the company has a vendor management database containing contracts, service providers, risk ratings, renewal dates, due diligence records, service levels, data protection assessments, outsourcing classifications and approval records.

[0167] The target rulebook applied by the first processing node is a Vendor Contract Rulebook. The Vendor Contract Rulebook contains rules that determine what actions must be performed during the lifecycle of a vendor contract. Table 8 below sets out the rules defined in the Vendor Contract Rulebook.

[0168] Table 8 Rule ID Rule Action VCR-001 If the vendor provides a critical or important function, enhanced due diligence is required Trigger enhanced due diligence workflow VCR-002 If the contract involves personal data, data protection review is required Assign DPO or privacy owner VCR-003 If the vendor has system access, cyber / security review is required Assign information security assessment VCR-004 If the contract renews within 120 days, renewal review is required Notify contract owner VCR-005 If there is no exit plan for a material vendor, create exit plan action Assign exit plan owner VCR-006 If insurance certificates have expired, request updated certificates Send vendor request VCR-007 If service levels are missed twice in a quarter, escalate to Vendor Committee Create escalation paper VCR-008 If the contract value exceeds approval authority, route to Board or delegated committee Create approval task

[0169] During rulebook evaluation, the AI module 630 references structured data held in the vendor management database to determine which rules are triggered. Table 9 below identifies the database tables and their key fields that are referenced during this evaluation.

[0170] Table 9 Database table Key fields Vendor Master Vendor ID, vendor name, jurisdiction, relationship owner and risk rating Contract Register Contract ID, vendor ID, contract type, start date, renewal date and termination rights Outsourcing Register Materiality, criticality, outsourced function and regulator notification status Data Protection Register Personal data involved, data transfer location, DPA status and privacy owner Security Register System access, security rating, penetration test status and cyber questionnaire status HK 30138179 A 25 Database table Key fields Insurance Register Required insurance, certificate expiry date and minimum limits SLA Register Service levels, SLA breaches and remediation actions Approval Register Approval authority, approval status and approving body Blockchain Register Workflow run ID, block hash, previous hash and verification status

[0171] The contract manager enters a high-level natural language command and the system generates the orchestration flow therefrom. The natural language instruction is as follows:

[0172] "Review all active vendor contracts against the approved vendor contract rulebook, identify required actions, automate permitted steps, route restricted steps for approval, update the vendor database, and write each step to the blockchain verification ledger."

[0173] Upon receiving the natural language instruction, the system decomposes the command into rulebook-driven actions. Table 10 below shows the decomposition of each command element into its system interpretation and the corresponding rulebook or database used.

[0174] Table 10 Command element System interpretation Rulebook or database used Review all active vendor contracts Query active contracts from Contract Register Vendor database Against the approved vendor contract rulebook Apply latest approved rulebook version Vendor Contract Rulebook Identify required actions Evaluate each contract against rules Workflow rulebook Automate permitted steps Execute low-risk actions automatically Agentic AI and workflow engine Route restricted steps for approval Apply yes / no gates Approval workflow Update the vendor database Write new action status and metadata Vendor database Write each step to the blockchain Record all events and hashes Blockchain audit module

[0175] The operation of the second embodiment is now described by reference to a specific worked example. In this example, the system evaluates a vendor contract record for a cloud hosting and managed infrastructure provider ("CloudHost Services Ltd"). Table 11 below shows the relevant fields of the contract record as retrieved from the vendor management database.

[0176] Table 11 Field Example value Vendor CloudHost Services Ltd Contract type Cloud hosting and managed infrastructure Contract value USD 250,000 per annum Renewal date 90 days from review date Criticality Important business service Personal data Yes System access Yes Cyber questionnaire Out of date HK 30138179 A 26 Field Example value Data processing agreement Executed but older than current template Insurance certificate Expired Exit plan Not recorded SLA breaches Two in current quarter

[0177] The AI module 630, operating under the Vendor Contract Rulebook, evaluates the contract record against each rule. Table 12 below shows the result of the rulebook assessment, including the rule triggered, the reason, the required action, and the automation status determined by the execution path determination conditions.

[0178] Table 12 Rule triggered Reason Required action Automation status VCR-001 Vendor supports important business service Enhanced due diligence Auto-start, human review VCR-002 Vendor processes personal data Data protection review Assign to privacy owner VCR-003 Vendor has system access Cyber review Assign to security owner VCR-004 Renewal due within 120 days Renewal review Auto-notify contract owner VCR-005 No exit plan recorded Create exit plan action Auto-create task VCR-006 Insurance certificate expired Request updated certificate Auto-send vendor email VCR-007 Two SLA breaches Escalate to Vendor Committee Human approval required VCR-008 Contract value exceeds management authority Board or committee approval Human approval required

[0179] For actions classified as automated, the workflow engine 640 executes the permitted steps autonomously. Table 13 below illustrates the specific tasks performed by the workflow engine 640 for each permitted action.

[0180] Table 13 Action Agentic AI task Renewal notice Drafts and sends renewal review notice to contract owner Due diligence request Generates due diligence checklist based on vendor type Cyber review Assigns information security questionnaire to security owner Privacy review Assigns data protection review to privacy owner Insurance request Drafts vendor email requesting updated certificates Exit plan Creates exit plan task and pre-populates template Contract summary Summarises key contract obligations, termination rights and renewal deadlines Committee paper Drafts escalation paper for Vendor Committee review

[0181] For actions that require human sign-off, the workflow engine applies a series of decision gates to determine the execution path. Table 14 below sets out the gate logic applied in this embodiment. HK 30138179 A 27

[0182] Table 14 Gate Condition Result Gate 1 Is the task administrative and low-risk? If yes, execute automatically Gate 2 Does the action send a communication to an external vendor? If yes, execute only if pre- approved template is used Gate 3 Does the action change contractual rights or obligations? If yes, human approval required Gate 4 Does the contract exceed approval authority? If yes, escalate to approving body Gate 5 Does the matter require regulatory notification? If yes, trigger regulatory review rulebook Gate 6 Is there a data protection or cyber gap? If yes, assign control owner and track remediation

[0183] After each action is executed, the workflow engine updates the corresponding fields in the vendor management database. Table 15 below shows the database state change resulting from the actions executed in this worked example.

[0184] Table 15 Field Previous status Updated status Renewal review Not started In progress Cyber questionnaire Out of date Assigned to security owner Data protection review Not started Assigned to privacy owner Insurance certificate Expired Request sent to vendor Exit plan Missing Draft task created SLA escalation Not escalated Committee paper drafted Approval status Not submitted Pending Vendor Committee approval

[0185] Throughout the execution of the orchestration flow, each action is written to the blockchain. Table 16 below shows the complete sequence of blockchain events for this worked example.

[0186] Table 16 Block Event Example record 0 Genesis trigger Vendor contract review workflow started 1 Rulebook invoked Vendor Contract Rulebook v3.2 invoked 2 Database query Active vendor contracts queried; query hash recorded 3 AI analysis output Vendor action list generated; output hash recorded 4 Gate decision Renewal review classified as automated action 5 Action executed Renewal notice sent to contract owner 6 Gate decision External vendor insurance request permitted using approved template 7 Action executed Insurance certificate request sent 8 Gate decision SLA escalation requires human approval 9 Human approval Contract owner approves Vendor Committee escalation 10 Action executed Vendor Committee paper created 11 Database update Vendor record updated; update hash recorded Terminal Workflow close Merkle root and closing chain hash recorded HK 30138179 A 28

[0187] Upon completion of the orchestration flow, the workflow processing system generates a verifiable end-to-end record documenting: which vendor contract rulebook was used and at which version; which database records were assessed; which vendor contract rules were triggered; which actions were classified as automated; which actions required human approval; who approved each restricted action; which actions were executed and when; which database fields were updated; whether a vendor communication was sent; and whether the final record has been tampered with. HK 30138179 A 1 Claims 1. A workflow processing method, comprising: configuring a plurality of first rulebooks and a plurality of second rulebooks, wherein the first rulebooks are configured to describe analysis logic for input data and an output data structure for analysis results, and the second rulebooks are configured to describe an action execution flow and execution path determination conditions for at least one action; in response to a trigger event, sequentially executing N processing nodes of an orchestration flow, wherein each of the processing nodes employs a corresponding target rulebook, and output data of an n-th processing node serves as input data of an (n+1)-th processing node, where n is a positive integer between 1 and N−1; when the target rulebook corresponding to a currently executing processing node is one of the first rulebooks, driving an artificial intelligence model to perform analysis processing on the input data according to the analysis logic in the target rulebook, and generating a corresponding structured analysis result in accordance with the output data structure in the target rulebook; when the target rulebook corresponding to a currently executing processing node is one of the second rulebooks, scheduling, by a workflow engine, respective pending actions according to the action execution flow in the target rulebook, and determining an execution path corresponding to each pending action based on the execution path determination conditions in the target rulebook; during execution of the orchestration flow, writing a processing record generated by each of the processing nodes as a block to a blockchain; upon completion of the orchestration flow, writing a terminal block containing summary information of all preceding blocks to the blockchain, so as to form an audit record corresponding to the orchestration flow. 2. The workflow processing method according to claim 1, wherein when the target rulebook corresponding to the currently executing processing node is one of the first rulebooks, the method further comprises: after the artificial intelligence model generates the structured analysis result, verifying the structured analysis result against preset validation conditions; when the structured analysis result does not satisfy the validation conditions, feeding the structured analysis result as supplementary context together with the input data back into the artificial intelligence model to re-execute the analysis processing; when the structured analysis result satisfies the validation conditions, determining the structured analysis result as the output data of the current processing node. 3. The workflow processing method according to claim 2, wherein the method further comprises: when the number of times the artificial intelligence model has executed the analysis processing reaches a preset maximum iteration count, determining the structured analysis result as the output data of the current processing node. 4. The workflow processing method according to claim 1, wherein the execution path comprises an autonomous execution path and a manual execution path, and the determining an execution HK 30138179 A 2 path corresponding to each pending action based on the execution path determination conditions in the target rulebook comprises: obtaining the execution path determination conditions corresponding to the pending action; when the execution path determination conditions indicate that the pending action satisfies requirements for autonomous execution, determining that the execution path corresponding to the pending action is the autonomous execution path, and automatically completing the pending action via the workflow engine; when the execution path determination conditions indicate that the pending action does not satisfy requirements for autonomous execution, determining that the execution path corresponding to the pending action is the manual execution path, and routing the pending action to a human operator terminal to await manual execution. 5. The workflow processing method according to claim 1, wherein the writing a processing record generated by each of the processing nodes as a block to a blockchain during execution of the orchestration flow specifically comprises: after an n-th processing node has completed execution, generating at least one corresponding processing record, where n is a positive integer between 1 and N; combining the processing record with a hash value of an immediately preceding block to generate a block corresponding to the n-th processing node, and writing the block to the blockchain. 6. The workflow processing method according to claim 5, wherein the processing record comprises one or more of the following: a node identifier of the current n-th processing node; a rulebook identifier of the target rulebook corresponding to the current n-th processing node; the input data; and the output data. 7. The workflow processing method according to claim 5, wherein the writing a terminal block containing summary information of all preceding blocks to the blockchain upon completion of the orchestration flow so as to form an audit record corresponding to the orchestration flow specifically comprises: obtaining the hash value of each preceding block in the blockchain; constructing a Merkle tree based on all of the hash values; taking the hash value of the root node of the Merkle tree as the summary information; writing the summary information into the terminal block and appending the terminal block to the blockchain. 8. The workflow processing method according to claim 1, wherein the method further comprises: receiving a natural language instruction input by a user; performing semantic parsing on the natural language instruction to decompose the natural language instruction into at least one processing task; for each of the processing tasks, matching a corresponding target rulebook from among the plurality of first rulebooks and the plurality of second rulebooks; HK 30138179 A 3 determining an execution order among the plurality of corresponding target rulebooks based on logical relationships among the processing tasks, and generating the orchestration flow; wherein the sequentially executing the N processing nodes of the generated orchestration flow is initiated in response to the trigger event. 9. The workflow processing method according to claim 8, wherein at least two of the processing tasks are permitted to be matched to a same target rulebook, and the at least two processing tasks matched to the same target rulebook are merged into a single processing node. 10. The workflow processing method according to claim 1, wherein each of the first rulebooks is derived from one or more primary rules stored in a primary rule repository, the primary rules constituting authoritative source instruments; the analysis logic and the output data structure of each first rulebook are configured by reference to the one or more primary rules from which the first rulebook is derived; the structured analysis result generated by a processing node employing a first rulebook includes, for each element thereof, a traceable reference to the primary rule and clause from which the element is derived; and the processing record written to the blockchain for that processing node records an identifier and a version of each primary rule relied upon. 11. The workflow processing method according to claim 10, further comprising: in response to creation or update of a primary rule, identifying, from linkage data associating each first rulebook with the one or more primary rules from which it is derived, each first rulebook derived from the primary rule; and flagging each identified first rulebook for revalidation against the updated primary rule. 12. The workflow processing method according to claim 4, wherein the execution path determination conditions are configured such that a pending action that changes a contractual right or obligation, carries a regulatory consequence, or exceeds a defined approval authority is routed to the manual execution path; and the routing of the pending action to the human operator terminal comprises presenting, at the human operator terminal, a provenance of the pending action including a recommended decision and an audit trail recorded for the orchestration flow, and receiving from the human operator terminal one of an approval, a rejection, an escalation and an override of the pending action. 13. The workflow processing method according to claim 12, wherein each gate decision and each executed action is written to the blockchain together with an identifier of the actor responsible therefor, the actor being one of the workflow engine acting under delegated authority and a named human approver, so that the audit record attributes every consequential action to an identified human or to an action class pre-authorised by a human. 14. A workflow processing system, comprising a rulebook storage module, an orchestration module, an artificial intelligence module, a workflow engine, and a blockchain audit module; wherein the rulebook storage module stores a plurality of first rulebooks and a plurality of second rulebooks, the first rulebooks are configured to describe analysis logic for input data and an output data structure for analysis results, and the second rulebooks are configured to describe HK 30138179 A 4 an action execution flow and execution path determination conditions for at least one action; the orchestration module is configured to, upon occurrence of a trigger event, invoke the artificial intelligence module and the workflow engine to sequentially execute N processing nodes of an orchestration flow; wherein each of the processing nodes employs a corresponding target rulebook, and output data of an n-th processing node serves as input data of an (n+1)-th processing node, where n is a positive integer between 1 and N−1; the artificial intelligence module is configured to, when the target rulebook corresponding to a currently executing processing node is one of the first rulebooks, perform analysis processing on the input data according to the analysis logic in the target rulebook, and generate a corresponding structured analysis result in accordance with the output data structure in the first rulebook; the workflow engine is configured to, when the target rulebook corresponding to a currently executing processing node is one of the second rulebooks, schedule respective pending actions according to the action execution flow in the target rulebook, and determine an execution path corresponding to each pending action based on the execution path determination conditions in the target rulebook; the blockchain audit module is configured to, during execution of the orchestration flow, write a processing record generated by each of the processing nodes as a block to a blockchain, and upon completion of the orchestration flow, write a terminal block containing summary information of all preceding blocks to the blockchain, so as to form an audit record corresponding to the orchestration flow. HK 30138179 A 1 Drawings A plurality of first rulebooks and a plurality of second rulebooks are configured In response to a trigger event, N processing nodes of an orchestration flow are sequentially executed At least one processing record generated by each of the processing nodes is written as a respective block to a blockchain A terminal block containing summary information of all preceding blocks is written to the blockchain, so as to form an audit record corresponding to the orchestration flow During execution of the orchestration flow Upon completion of the orchestration flow S31 S32 S1 S2 FIG.1 HK 30138179 A 2 An artificial intelligence model is driven to perform analysis processing on the input data according to the analysis logic in the target rulebook, and a corresponding structured analysis result is generated in accordance with the output data structure in the target rulebook Whether the structured analysis result satisfies preset validation conditions The structured analysis result is determined as the output data of the current processing node Whether the number of times the artificial intelligence model has executed the analysis processing has reached a preset maximum iteration count The most recent structured analysis result is determined as the output data of the current processing node The structured analysis result is fed as suppleme ntary context together with the input data back into the artificial intelligenc e model Yes No Yes No S211 S212 S213 S214 S215 S216 FIG.2 HK 30138179 A 3 Respective pending actions are scheduled by a workflow engine according to the action execution flow in the target rulebook For each pending action, the execution path determination conditions corresponding to the pending action are obtained Whether the pending action satisfies requirements for autonomous execution based on the execution path determination conditions The execution path corresponding to the pending action is determined as an autonomous execution path, and the pending action is automatically completed via the workflow engine The execution path corresponding to the pending action is determined as a manual execution path, and the pending action is routed to a human operator terminal to await manual execution Yes No S221 S222 S223 S224 S225 FIG.3 HK 30138179 A 4 After the n-th processing node has completed execution, at least one corresponding processing record is generated The processing record is combined with a hash value of the block corresponding to the immediately preceding processing activity to generate a block corresponding to the n-th processing node, and the block is written to the blockchain Upon completion of the orchestration flow The hash value of each preceding block in the blockchain is obtained A Merkle tree is constructed based on all of the hash values The hash value of the root node of the Merkle tree is taken as the summary information The summary information is written into a terminal block, and the terminal block is appended to the blockchain S324 S323 S322 S321 S311 S312 FIG.4 HK 30138179 A 5 A natural language instruction input by a user is received Semantic parsing is performed on the natural language instruction to decompose the natural language instruction into at least one processing task For each of the processing tasks, a corresponding target rulebook is matched from among the plurality of first rulebooks and the plurality of second rulebooks Whether at least two of the processing tasks are matched to a same target rulebook The at least two processing tasks are merged into a single processing node An execution order among the plurality of corresponding target rulebooks is determined based on logical relationships among the processing tasks, and the orchestration flow is generated Yes No S43 S44 S45 S46 S42 S41 FIG.5 HK 30138179 A 6 Rulebook storage module 610 Orchestration module 620 Artificial intelligence module 630 Workflow engine 640 Blockchain audit module 650 Workflow processing system 60 FIG.6 HK 30138179 A 7 Start: event or schedule trigger Rulebook A — AI analysis rulebook Instructs AI: analyse, forecast, summarise AI module executes Produces report, forecast, summary Output passed to Rulebook B AI result becomes workflow input Rulebook B — workflow rulebook Reads action list and decision gates Auto-approve? Yes / No gate Self-execute Book, notify, update Route for manual approval Human reviews, confirms, overrides Rulebook C — successive action Optional: chain another rulebook Workflow complete — log and notify Blockchain ledger Immutable audit trail Block 0 — genesis Trigger hash + timestamp Block 1 Rulebook A ID + prev hash Block 2 AI output hash + metadata Block 3 Chain event: A to B handoff Block 4 Rulebook B ID + input hash Block 5 Gate result: yes / no + reason Block 6 Action hash + actor + outcome Terminal block — close Merkle root + chain hash Yes No FIG.7 HK 30138179 A