Dynamically orchestratable execution-based smart hub platform system

Abstract

The present application relates to the technical field of artificial intelligence task scheduling and computer system security control, in particular to an executable intelligent hub platform system capable of dynamic scheduling, comprising: obtaining initial intention data and current environment attribute data; generating a dynamic task execution flow composed of multiple execution nodes through a scheduling plane and allocating resources; when the execution plane flows through a node, synchronizing the current execution state and the current environment attribute data to a security plane, performing dynamic attribute self-adaptive authentication based on a role access control model and an attribute access control model; controlling system call tool execution and outputting node execution results based on the authentication result; adjusting the state of the execution flow, continuing the subsequent node when the authentication passes, triggering a downgrade retry when the authentication fails and a downgrade strategy exists, triggering thread interception and state freezing when the authentication fails and no downgrade strategy exists, so as to balance security constraints and business continuity.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence task orchestration and computer system security control technology, specifically to a dynamically orchestratable execution-oriented intelligent central platform system. Background Technology

[0002] With the rapid development of online and intelligent processing of financial services, intelligent hub platforms for multi-tenant, multi-role, and continuous business links are widely used in scenarios such as task acceptance, process orchestration, system calls, and result writing. When handling abnormal refunds, approval reviews, and fund transfers, such platforms need to dynamically generate execution processes based on business intentions, while continuously meeting tenant isolation, access control, and risk constraints during execution. Therefore, how to ensure business continuity while achieving secure and controllable execution flows has become an important issue that needs to be addressed in the construction of current intelligent business platforms.

[0003] Traditional intelligent hubs or process execution systems currently rely mainly on the following methods: pre-configuring fixed business processes, permission verification based on static roles, unified recording of status by the execution system after node completion, and manual interruption or overall rollback when permissions are insufficient or calls fail.

[0004] Fixed business processes struggle to adapt to dynamic orchestration needs arising from changes in natural language intent, task objective parameters, and business conditions. Static role-based permission verification cannot adjust permissions in real time based on environmental attributes such as network address drift, operation time spans, and accumulated failure counts, easily leading to over-delegation or false blocking. Without fine-grained synchronization between node status and security verification, the security side struggles to obtain timely information on the current node, invoked tools, context tokens, and intermediate results, resulting in incomplete authentication criteria. Furthermore, traditional systems typically terminate processes directly when permissions are denied, lacking smooth handling capabilities such as field anonymization, restricted access, and downgraded retries. When unregistered system calls or cross-tenant access risks occur, timely thread-level interception and state freezing are difficult to achieve, impacting security boundaries and business continuity in multi-tenant environments. Summary of the Invention

[0005] The purpose of this invention is to provide a dynamically configurable execution-based intelligent central platform system, solving the following technical problems: It enables synchronous linkage between cross-plane contexts and execution flows, as well as real-time adaptive changes in permissions. Under the premise of multi-tenant isolation, it takes into account both security constraints and business continuity, avoids forced termination of the entire process and interruption of the entire chain execution due to static permission models or restrictions on a single sensitive field, and can effectively prevent single-node unauthorized access from spreading into cross-tenant or cross-system security incidents.

[0006] The objective of this invention can be achieved through the following technical solutions: A dynamically configurable execution-oriented intelligent central platform system includes: The data acquisition module is used to acquire initial intent data and current environmental attribute data; The task orchestration module is used to generate a dynamic task execution flow and allocate resources based on the initial intent data through the scheduling plane; wherein, the dynamic task execution flow consists of multiple execution nodes and is carried by a multi-tenant logical isolation environment including the scheduling plane, the execution plane, and the security plane; the system is pre-configured with system call tools bound to the execution nodes and preset degradation strategies; The core processing module is used to synchronize the current execution state and the current environment attribute data to the security plane when the execution node is transferred in the execution plane and the current execution state is generated; the security plane performs dynamic attribute adaptive authentication on the current execution state and the current environment attribute data based on a preset role-based access control model and an attribute-based access control model, and generates an authentication result; The result generation module is used to control the execution plane to call the system call tool and output the node execution result when the authentication result indicates that execution is allowed; The status update module is used to update the current execution status based on the execution result of the node; The feedback adaptive module is used to adjust the state of the dynamic task execution flow based on the authentication result and the node execution result; The state adjustment of the dynamic task execution flow includes: when the authentication result indicates that the permission verification is successful, controlling the execution plane to continue flowing to subsequent execution nodes; when the authentication result indicates that the permission verification is unsuccessful and the preset degradation strategy exists, triggering a degradation retry mechanism to adjust the access level of the system call tool and re-execute the execution node; when the authentication result indicates that the permission verification is unsuccessful and the preset degradation strategy does not exist, triggering a thread interception and state freeze mechanism to interrupt the dynamic task execution flow.

[0007] Furthermore, the core processing module synchronizes the current execution state and the current environment attribute data to the security plane, including: Extract the context state data corresponding to the execution node from the current execution state; The context state data and the current environment attribute data are encapsulated into a state synchronization data packet; The state synchronization data packets are sent to the security plane via a pre-defined cross-plane communication bus based on shared memory.

[0008] Furthermore, the security plane performs dynamic attribute adaptive authentication, including: The state synchronization data packet is parsed, the current role identifier is extracted from the context state data, and dynamic attribute features are extracted from the current environment attribute data; Input the current role identifier into the preset role-based access control model to obtain a static permission set; The dynamic attribute features are input into the preset attribute-based access control model to obtain dynamic permission constraints. The static permission set is filtered and selected based on the dynamic permission constraints to generate the authentication result.

[0009] Furthermore, triggering the downgrade retry mechanism includes: The execution node is parsed to obtain the target operation object corresponding to the execution node; Determine the original access level of the target operation object; The original access level is reduced to a restricted access level, generating a downgrade operation instruction; wherein, the restricted access level includes field-level de-identification access level; Based on the downgrade operation instruction, the execution plane is controlled to re-invoke the system call tool.

[0010] Furthermore, re-invoking the system call tool includes: Initialize the retry count counter; When the value of the retry count counter is less than the preset maximum retry count threshold, the product of the preset base delay time and the value of the retry count counter is used as the current retry delay time. After the current retry delay time has elapsed, a retry request is initiated, and the value of the retry count counter is increased by a preset step. When the value of the retry count counter is greater than or equal to the preset maximum retry count threshold, the exception handling process is triggered.

[0011] Furthermore, the thread interception and state freezing mechanism is triggered, including: Monitor the system call requests initiated by the execution node; Determine whether the system call request is included in the preset registration and approval list; When the system call request is not included in the preset registration and approval list, an unauthorized alarm signal is generated; when the system call request is included in the preset registration and approval list, the system call request is allowed. In response to the unauthorized access alarm signal, the execution plane is controlled to suspend the current execution thread of the execution node and save the current execution state to a preset running sandbox in the multi-tenant logical isolation environment.

[0012] Furthermore, the current environmental attribute data includes network address drift status data, operation time period span status data, and real-time risk score data calculated by multiplying the number of operation failures of the obtained execution node by a preset penalty coefficient; the initial intent data includes natural language parsing features and task objective parameters.

[0013] Furthermore, the task orchestration module includes a pre-defined task parsing engine based on a natural language processing model; the task orchestration module is specifically used for: The initial intent data is input into the preset task parsing engine based on the natural language processing model; The preset task parsing engine based on the natural language processing model outputs a directed acyclic graph of tasks containing multiple execution nodes; Based on the topology of the directed acyclic graph of the task, the dynamic task execution flow is initialized through the scheduling plane.

[0014] Furthermore, the multi-tenant logical isolation environment is built on a preset microkernel architecture; the microkernel architecture includes an underlying scheduling engine and multiple mutually isolated running sandboxes; the execution nodes are loaded into the running sandboxes in the form of plug-ins, and the underlying scheduling engine performs unified resource allocation.

[0015] Furthermore, the state update module is specifically used to perform the following operations after outputting the node execution result: The execution result of the node is used as the input status data for the next execution node; Update the current execution status; The updated current execution status is fed back to the scheduling plane to update the global execution progress of the dynamic task execution flow.

[0016] The beneficial effects of this invention are: 1) By introducing a task parsing engine based on a natural language processing model, this invention enables the system to automatically convert initial intent data into a directed acyclic graph of tasks and initialize dynamic task execution flow accordingly. This mechanism breaks the limitations of traditional fixed business processes, allowing the system to flexibly adapt to different conditions and complex intents, and optimizes the orchestration efficiency and intelligence level of the business chain. 2) This invention adopts a dual access control model that combines roles and attributes, and integrates environmental attributes such as network address drift, time period span, and risk scoring into the authentication calculation in real time. This method enables the permission boundary to dynamically shrink or widen as the risk of the environmental context rises or falls, effectively solving the problems of excessive delegation and false interception caused by traditional static permissions, and improving the accuracy of multi-tenant management. 3) This invention constructs a cross-plane communication bus based on shared memory, which can encapsulate the extracted fine-grained context state data and environmental attributes into data packets and efficiently synchronize them to the security plane; this constructs a data link between the execution process and security control, providing a complete and real-time decision basis for dynamic authentication and avoiding security vulnerabilities caused by incomplete state information. 4) This invention designs a degradation retry mechanism. When the permission fails and a degradation strategy exists, the operation on the target object is proactively reduced to a restricted access level such as field-level desensitization, and a retry is initiated with an incremental delay. This successfully transforms the original direct failure into a smooth continuation under restricted conditions, reducing the damage to the global business continuity caused by the restriction of single-point sensitive data. 5) This invention establishes a call monitoring and interception system based on a registration and approval list. Once an unregistered system call request is detected, an over-authority alarm is immediately triggered and the current execution thread is suspended. In conjunction with the logical isolation sandbox of the microkernel architecture, the system can safely freeze and isolate the current state, effectively preventing the risk of a single node from spreading abnormally to cross-tenant or underlying systems. Attached Figure Description

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

[0018] Figure 1 This is a schematic diagram of the modules of the dynamically arrangable execution-oriented intelligent central platform system provided in the embodiments of this application. Detailed Implementation

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

[0020] Please see Figure 1 A dynamically orchestratable execution-oriented intelligent central platform system, including: a data acquisition module, used to acquire initial intent data and current environmental attribute data; The task orchestration module is used to generate a dynamic task execution flow and allocate resources based on the initial intent data through the scheduling plane; wherein, the dynamic task execution flow consists of multiple execution nodes and is carried by a multi-tenant logical isolation environment including the scheduling plane, the execution plane and the security plane; the system is pre-configured with system call tools bound to the execution nodes and preset degradation strategies; The core processing module is used to synchronize the current execution state and current environment attribute data to the security plane when the execution plane flows through the execution node and generates the current execution state. The security plane performs dynamic attribute adaptive authentication on the current execution state and current environment attribute data based on the preset role-based access control model and attribute-based access control model, and generates authentication results. The result generation module is used to control the execution plane to call system call tools when the authentication result indicates that execution is allowed, and to output the node execution result; The status update module is used to update the current execution status based on the node execution result; The feedback adaptive module is used to adjust the state of the dynamic task execution flow based on the authentication result and the node execution result; The state adjustment of the dynamic task execution flow includes: when the authentication result indicates that the permission verification is successful, the control execution plane continues to flow to subsequent execution nodes; when the authentication result indicates that the permission verification is unsuccessful and there is a preset degradation strategy, a degradation retry mechanism is triggered to adjust the access level of the system calling tool and re-execute the execution node; when the authentication result indicates that the permission verification is unsuccessful and there is no preset degradation strategy, a thread interception and state freeze mechanism is triggered to interrupt the dynamic task execution flow.

[0021] This embodiment provides a mechanism for a dynamically orchestratable execution-oriented intelligent central platform system; specifically, the system is deployed in the multi-tenant operation platform of the bank's head office to handle the continuous business chain of abnormal refund approval and fund transfer for corporate clients.

[0022] Different tenants in the platform correspond to different branches or business units. Although different tenants share the underlying infrastructure, they are logically isolated from each other. The system receives refund processing intentions initiated by counter staff, risk control staff or clearing staff, and completes a complete closed loop from task parsing, node execution to permission contraction or freezing interruption under the coordination of the three planes of control, execution and security.

[0023] Specifically, the data acquisition module obtains initial intent data and current environment attribute data; the initial intent data may include structured task information such as processing an abnormal refund application of RMB 1 million with reason code R07 for customer A, or natural language instructions such as verifying the original transaction, supplementing attachments and submitting for financial review. The current environment attribute data may include the network segment where the initiating terminal is located, the login time period, the current risk score, the number of failed attempts, etc. For ease of understanding, a detailed example can be provided: Suppose that a certain business request is parsed to form a task parameter set T, which includes customer number C01, refund amount 1,000,000, currency CNY and target account B01. At the same time, the environmental attribute set E is collected. The environmental attribute set E includes the office network segment W1, the time period H1, and the risk score 0.35. After receiving the task parameter set T, the task orchestration module generates a dynamic task execution flow through the scheduling plane. This execution flow can be simplified into four execution nodes, namely N1 reading the original transaction flow, N2 verifying the refund materials, N3 generating approval opinions, and N4 initiating a fund transfer application. Each execution node is pre-bound with a corresponding system call tool, such as a transaction reading tool, a document extraction tool, an approval writing tool, and a fund interface tool. At the same time, corresponding degradation strategies are pre-configured, such as switching to field desensitization reading when the complete account field cannot be read. The execution node is dynamically bound to the system call tool and the preset degradation policy through a unified mapping registry preset in the system control center. The unified mapping registry is configured with node type identifier, tool application interface call path, parameter template required for normal access level, and restricted access level and de-identified data mapping rules corresponding to the degradation trigger. When the core processing module executes the flow of the above nodes, it continuously generates the current execution state; the current execution state may include at least the node identifier, intermediate results generated, number of calls, thread number, and context token; The context token is automatically generated by the scheduling plane when initializing the dynamic task execution flow. It contains a tamper-proof lifecycle timestamp, a globally unique identifier for the dynamic task execution flow, and an encrypted signature. It is used to verify the legitimacy of the state record and the identity of the flow during data synchronization between the execution plane and the security plane.

[0024] Taking the completion of N1 as an example, the system obtains state S1, which includes the current node N1, the read transaction number TX9, the intermediate result R1, and the thread number TH21. The system does not directly enter N2, but synchronizes state S1 and environmental attribute set E to the security plane; the security plane performs joint authentication based on the preset role model and attribute model; if the initiator belongs to the branch reviewer role, the static permission set Ps1 is first obtained from the role model. The static permission set Ps1 includes, for example, readable transaction summary, readable attachment index, and funds that cannot be directly transferred. Combining the attribute model, a dynamic constraint set A1 is obtained based on the current risk score of 0.35, the office network segment W1, and the time period H1. The dynamic constraint set A1 includes, for example, data extensions that allow reading summaries, allow querying materials, and disallow reading all sensitive fields. The security plane filters the static permission set Ps1 to form the authentication result Q1. If the authentication result Q1 is successful, the execution plane continues to flow to N2 and calls the binding tool. If authentication result Q1 fails but the platform finds a downgrade strategy for the corresponding node, such as reading from a plaintext account downgraded to reading from a de-identified account, the system triggers a downgrade retry mechanism. If authentication result Q1 fails and there is no downgrade strategy, for example, if a node attempts to directly trigger the transfer of public funds but the current role and environment do not allow it, the planar trigger thread interception and state freeze mechanism is executed to interrupt the execution flow of the dynamic task.

[0025] To make the execution flow status adjustment process clearer, we can continue with a set of exemplary process simulations; assuming that when N2 reads the customer's attachments, it originally planned to call tool U2 to obtain a complete scanned copy of the business license and an image of the legal representative's certificate, with a normal access level of L3; The security plane determined that the current time period was in the midst of the end-of-day settlement window, and the dynamic attributes increased the risk constraints, causing L3 access to be no longer allowed. However, the node had a preset downgrade strategy, so the system adjusted the access level to L2, only allowing the acquisition of business license summary information and the last four digits of the certificate number, and re-executed N2. If the re-execution is successful, the execution plane will continue to send the desensitized results to N3 to generate approval opinions, so that the entire refund approval process will not be suspended due to a single sensitive field. Conversely, if an execution node intends to call an unregistered external transfer interface and there is no alternative restricted call path, the system will directly freeze the node's thread and save the current state, waiting for manual review or exception handling process to intervene.

[0026] To avoid symbol ambiguity, in this embodiment, execution nodes are uniformly represented by node identifiers such as N1, N2, N3, and N4, network or network segment related environmental attributes are uniformly represented by network segment identifiers such as W1 and W2, and time periods are uniformly represented by time period identifiers such as H1, H2, and H3. The aforementioned office network segment W1 and execution node N1 are not the same object; they are used to represent environmental attributes and process nodes, respectively.

[0027] As a supplement, when the initial intent data is missing key task target parameters, such as an empty refund amount or an unmatched customer number, the task orchestration module does not generate a formal execution flow, but instead creates an abnormal data entry node and transfers the task to the data entry queue; when environmental attribute data collection fails, the system can enable a conservative default strategy to mark dynamic attributes as high risk, thereby enabling subsequent authentication to be performed under stricter restrictions. When the security plane is unavailable within a preset time period, the execution plane does not directly allow sensitive calls, but only allows access to low-risk nodes that have cached authorization results and have not expired. For high-risk nodes, execution is suspended and the process waits for recovery. If the same node fails to be downgraded multiple times, the node enters an abnormal handling state, and the scheduling plane decides whether to jump to the manual review node or terminate the entire refund dynamic task execution flow.

[0028] At 17:55, a branch office reviewer initiated an abnormal refund for a corporate client. The preset security threshold is the upper limit of the allowed safe processing value pre-set by the system based on the risk score statistical distribution of historical normal processing tasks. The system detected that the client was on the office intranet and the risk score was lower than the preset security threshold. Therefore, it arranged the execution chain of transaction verification - material verification - generation of approval opinion - submission of fund transfer. The first two nodes are executing normally. However, after entering the clearing sensitive period at 18:02, the environmental attributes changed, and the security plane dynamically reduced subsequent permissions. At this point, the system allows the generation of approval opinions to continue, but only retains the limited ability to submit applications for review for the fund transfer node, and does not allow the direct completion of the transfer; if the node has a downgrade policy, the dynamic task execution flow will be automatically downgraded to suspension pending higher authorization; if there is no corresponding policy, the thread will be frozen and the context will be retained, and the subsequent processing will be carried out by the head office fund authorization post.

[0029] The purpose of this step is to incorporate task orchestration, dynamic authentication, degraded execution, and abnormal freezing into the same closed loop, thereby achieving synchronous linkage between cross-plane contexts and execution flows. Under the premise of multi-tenant isolation, it takes into account both security constraints and business continuity, avoids the forced termination of the entire process due to static permission models, and also prevents hidden privilege overreach due to the number of execution chain nodes exceeding the preset threshold.

[0030] In a preferred embodiment of the present invention, the core processing module synchronizes the current execution state and current environment attribute data to the security plane, including: extracting the context state data corresponding to the execution node from the current execution state; encapsulating the context state data and current environment attribute data into a state synchronization data packet; and sending the state synchronization data packet to the security plane through a preset cross-plane communication bus based on shared memory.

[0031] This embodiment provides a mechanism for cross-plane state synchronization. Specifically, in the above-mentioned refund approval and fund transfer scenarios, if the execution plane only sends a basic execution status identifier to the security plane after the node ends, although coarse-grained flow can be completed, the problem of incomplete context information is likely to occur.

[0032] For example, the security plane cannot determine which transaction number the current node has accessed, which tool it has used, or whether a partial degradation has occurred, so it cannot implement targeted dynamic authentication. To solve this deficiency, this embodiment uses a method of extracting context state data from the current execution state, encapsulating it into a state synchronization data packet, and sending it through a shared memory bus. Specifically, the execution plane maintains a fine-grained state record during the execution of each node; this state record includes not only an identifier such as node N2 is executing, but also node input summary, current intermediate results, invoked tool identifier, tenant identifier, thread number, number of retries, and upstream node output summary; Assuming the current execution node is N3 generating approval opinions, the context state data extracted from the current execution state can be represented as C3. C3 includes tenant T02, node identifier N3, upstream result summary R2, calling tool U3, thread TH21, retry count 1, and target object O7.

[0033] The current environment attribute data can be represented as E3, which includes network segment W1, time period H2, and risk score of 0.62. The system encapsulates C3 and E3 into a state synchronization data packet P3. This data packet can be organized using a fixed header and a variable-length body. The header stores the version number, tenant identifier, data length, and checksum, while the variable-length body stores the context state field and environment attribute field in sequence. The advantage of this is that the security plane does not need to send multiple query requests to the execution plane during parsing, thereby reducing cross-plane round-trip overhead.

[0034] In terms of communication path, this embodiment adopts a cross-plane communication bus based on shared memory; the shared memory area can be pre-divided into multiple ring buffers, each tenant corresponds to a logical partition, and status synchronization data packets are written in the order of node events within each partition.

[0035] For example, tenant T02's circular buffer has slots B1, B2, and B3. When N3 starts execution, the execution plane writes the state synchronization data packet P3 to B2 and updates the write pointer. After the security plane polls or interrupts reception, it reads the data in B2 and performs verification. If the verification values ​​match, the synchronization is considered successful; if they do not match, the packet is discarded and a retransmission is requested. Compared with the forwarding method based on network sockets, shared memory avoids additional protocol encapsulation and kernel mode switching, making it more suitable for high-frequency state synchronization at the microsecond to millisecond level.

[0036] As a supplement, when the shared memory bus becomes congested, for example, when more than the preset concurrency threshold of tenants execute high-frequency nodes at the same time, the system can prioritize writing data packets corresponding to high-risk nodes or sensitive tool nodes, while writing lightweight digest packets to low-risk nodes; when the circular buffer is full, newly arriving data packets will not directly overwrite unconsumed high-priority data, but will instead discard reconstructable low-priority digests according to priority and trigger a retransmission flag. When there are missing fields in the context state data, such as when the target object identifier cannot be extracted, the system will automatically fill in null values ​​and field missing identifiers, so that the security plane can adopt a conservative strategy to handle the situation, rather than allowing the process to proceed based on incomplete data.

[0037] In the aforementioned refund process, after N1 reads the original transaction history, the execution plane generates context state data, which includes transaction number TX9, the called transaction history query tool U1, the current thread TH21, and a summary of the queried amount. This data, combined with environmental attributes including the office intranet, the pre-clearing period, and a risk score of 0.35, is written to the security plane via the shared memory bus.

[0038] When the business enters the end-of-day window, the time period field in the data packet corresponding to the N4 fund transfer application has changed to H3, and the risk score has also risen to 0.81; the security plane can immediately perceive the environmental changes based on this, without having to wait for the entire workflow to be completed before making a unified verification.

[0039] Furthermore, to maintain consistency with the authentication input of the subsequent security plane, the context state data also includes the current role identifier or a session identity field that can map to the current role identifier.

[0040] In other words, when the execution plane extracts context state data, it not only retains the information of the node execution itself, but also simultaneously retains the role identity information of the node that initiated it; for example, the above C3 can be further refined into C3 that includes tenant T02, role identifier R_branch_reviewer, node identifier N3, upstream result summary R2, calling tool U3, thread TH21, retry count 1, and target object O7.

[0041] When the role identifier changes due to session renewal or proxy authorization, the execution plane writes the currently effective role identifier into the state synchronization data packet instead of using the historical cached role, so as to avoid the security plane performing authentication based on expired identities. If the plaintext role identifier is not directly put in for the purpose of minimizing transmission, it can also be put into the session identity index or job code, so that the security plane can complete a unique mapping based on the field.

[0042] Furthermore, the context state field and environment attribute field in the state synchronization data packet are written in a fixed order during encapsulation to ensure stable parsing by the security plane. Preferably, the tenant identifier, role identifier, node identifier, tool identifier, thread number, target object identifier, and retry count can be written first, followed by environment attribute fields such as network segment, time period, and risk score. If a field is missing, a null value placeholder and a missing marker are written without changing the field order.

[0043] This avoids the security plane mistakenly resolving the thread number as a role identifier or the environment field as a context field due to field displacement, thereby improving the consistency of cross-plane synchronization.

[0044] Furthermore, to maintain consistency of symbols throughout the text, the state synchronization data packets in this embodiment are uniformly represented by P plus a sequence number, the context state data are uniformly represented by C plus a sequence number, and the network segments in the environment attribute data are uniformly represented by W plus a sequence number, to avoid confusion with the node identifier of the execution node, which is N plus a sequence number.

[0045] The purpose of this step is to establish a low-latency, fine-grained, verifiable cross-plane state transmission path to achieve consistent synchronization between the execution context and environment attributes, providing complete input for subsequent dynamic authentication and avoiding false release or false interception due to state fragmentation.

[0046] In a preferred embodiment of the present invention, the security plane performs dynamic attribute adaptive authentication, including: parsing the state synchronization data packet, extracting the current role identifier from the context state data, and extracting dynamic attribute features from the current environment attribute data; inputting the current role identifier into a preset role-based access control model to obtain a static permission set; The dynamic attribute features are input into a preset attribute-based access control model to obtain dynamic permission constraints; the static permission set is filtered and selected according to the dynamic permission constraints to generate authentication results.

[0047] This embodiment provides a dynamic attribute adaptive authentication mechanism; specifically, in the aforementioned scenario, although the role model can distinguish between positions such as teller, reviewer, financial supervisor, and fund authorization officer, it cannot handle sudden changes in the environment during business operations. For example, the same reviewer can view the refund summary during office hours, but should not continue to read the complete sensitive fields after crossing the sensitive period of liquidation or after the risk score increases; if only static role set is relied upon, the permissions will exceed the preset boundary; therefore, this embodiment superimposes dynamic attribute constraints on the basis of static role permissions, so that the permission results can be contracted or relaxed in real time as the environment changes.

[0048] Specifically, after receiving the state synchronization data packet, the security plane first parses it. Among the parsing results, one type is the current role identifier extracted from the context state data, such as the current role identifier R being a branch reviewer; the other type is the dynamic attribute features extracted from the environmental attribute data, such as dynamic attribute feature A including office network segment W1, time period H3, risk score 0.81, and number of failures 2. The system inputs the role identifier into the role model to obtain the static permission set Ps.

[0049] For branch reviewers, the static permission set Ps returned by the role model includes p1 reading transaction summary, p2 reading customer attachment index, p3 generating approval opinion, p4 not being able to directly transfer funds, and p5 being able to submit review application; inputting dynamic attribute features into the attribute model yields dynamic constraint conditions D; For example, when the risk score is greater than or equal to 0.8 and the time period is H3, the dynamic constraint D output by the attribute model includes prohibiting plaintext reading of the full account number and only allowing anonymized reading, prohibiting direct triggering of fund transfers, and allowing submission of pending authorization work orders; The static permission set Ps is filtered and screened according to the dynamic constraint D to generate the final authentication result Q. The filtering here is not a simple all-negation, but a filtering by permission granularity. Thus, the authentication result Q can be obtained, which includes p1 allowed, p2 allowed but only digest, p3 allowed, p4 prohibited, and p5 allowed.

[0050] Furthermore, the filtering process can be implemented using a permission bitmap; assuming the static permission set Ps is encoded as a five-bit vector [1,1,1,0,1], the allowable mask corresponding to the dynamic constraint D is [1,0.5,1,0,1], where 0.5 indicates that a downgrade is required rather than a complete rejection; After system calculation, the result can be transformed into [1,0.5,1,0,1]; the second bit is not completely cleared, but is marked as restricted executable, which is convenient for feedback to the execution plane to trigger subsequent degradation strategies; if the dynamic constraints are more stringent, such as the risk score reaching 0.95 and the network address drifting, the mask may become [1,0,0,0,0], indicating that only querying the digest is allowed, and all other operations are closed. As a supplement, when role identifiers cannot be identified, such as when unregistered job codes appear in tenant synchronization data, the system does not return blank permissions, but uniformly maps them to the lowest permission set, allowing access only to public non-sensitive metadata; when environmental attributes are missing or attribute model calculations time out, the system uses a conservative high-risk constraint template for filtering. When the role model and attribute model give contradictory results, such as the role model allowing direct submission for review while the attribute model requires complete freezing, the prohibited items in the attribute model take precedence to ensure that environmental risks can cover static role authorization; if all executable permissions in the authentication result are cleared, the system marks the node as unprogressable and writes the failure reason along with the context back to the execution plane. When the refund process reaches the stage of generating approval opinions, the initiator is still the branch reviewer. However, at this time, the network protocol address drifts from the internal network W1 to the external network proxy W2, and the risk score rises from 0.35 to 0.81. After the security plane parses the data packets, it first obtains the basic approval capabilities based on the job position, and then applies contraction conditions based on the new network environment and risk status. The final result allows the user to continue writing approval opinions, but prohibits the user from viewing the full number of the customer's identification documents and prohibits the subsequent nodes from directly transferring funds. The user can only enter the path of waiting for advanced authorization.

[0051] Furthermore, in engineering implementation, the above-mentioned permission bitmap method is preferably expressed as a combination of basic permission bitmap and execution state label, rather than directly using non-binary quantities as the traditional binary bitmap body.

[0052] The static permission set Ps can still use a binary bitmap to represent whether it has basic permissions, such as [1,1,1,0,1]; the dynamic attribute model outputs execution status labels for each permission item, and the execution status labels include at least three states: allowed execution, restricted execution, and prohibited execution. Taking the aforementioned permission items as an example, after filtering, it can be expressed as: p1 corresponds to allowed execution, p2 corresponds to restricted execution, p3 corresponds to allowed execution, p4 corresponds to prohibited execution, and p5 corresponds to allowed execution. After the execution plane receives the restricted execution tag, it combines the preset degradation strategy to decide whether to use field desensitization access, digest access, or pending authorization submission path. This not only retains the efficiency of bitmap filtering, but also avoids misunderstanding intermediate values ​​such as 0.5 as the value range of traditional bitmaps, thus making the authentication results clearer and the implementation path more consistent.

[0053] Furthermore, when there are situations such as proxy processing, session renewal, or job switching in the context state data, the security plane extracts the current role identifier based on the currently effective role in the state synchronization data packet, and performs consistency verification in conjunction with the tenant identifier; if the same thread continues to use the old role but the session context has been switched to the new role, the role model is recalculated based on the currently effective role, instead of directly reusing the static permission set of the previous node, so as to avoid the mis-amplification of permissions due to the lag in role caching.

[0054] Furthermore, to avoid symbol ambiguity, in this embodiment, Ps always represents the static permission set, D always represents the dynamic permission constraint condition, Q always represents the authentication result, W1, W2, etc. always represent the network segment or address domain identifier in the network environment, while N1, N2, etc. are only used to represent the execution node identifier and are not used in this embodiment to represent the network address with N plus a sequence number.

[0055] The purpose of this step is to combine static job responsibilities with dynamic environmental risks into a unified authentication result, thereby enabling permissions to adapt to changes in real time with the context. This avoids both excessive delegation of authority due to role-based control and the direct severing of all business capabilities due to attribute fluctuations.

[0056] In a preferred embodiment of the present invention, triggering a degradation retry mechanism includes: parsing the execution node to obtain the target operation object corresponding to the execution node; determining the original access level of the target operation object; reducing the original access level to a restricted access level and generating a degradation operation instruction; wherein, the restricted access level includes a field-level de-identified access level; and controlling the execution plane to re-call the system call tool based on the degradation operation instruction.

[0057] This embodiment provides a mechanism for downgraded retry. Specifically, in the aforementioned refund scenario, if the execution node terminates execution when it encounters a failure to pass permission verification, the entire business chain will be interrupted because some sensitive fields cannot be obtained. For example, the approval opinion generation node essentially only needs the transaction amount, refund reason, the last four characters of the company name, and some fields of the certificate to complete the review suggestion, and does not necessarily need the complete account and full certificate number. If the system does not provide a degradation path, the execution chain will be interrupted unnecessarily once the security constraints are tightened. Therefore, this embodiment achieves smooth continuation under restricted conditions by parsing the execution node, identifying the target operation object, reducing the access level and re-invoking the binding tool.

[0058] Specifically, when the security plane returns a permission failure but allows downgrade, the feedback adaptive module parses the current execution node and identifies the target operation object that the node needs to access; the target operation object here can be an account information table, customer attachment files, transaction records, or the structure returned by an external interface.

[0059] Taking the reading of customer account information node as an example, its target operation object can be denoted as Oa; the system determines the original access level Lo of the target operation object Oa; a simplified deduction can be made: when the original access level Lo is L3, it means that the dataset including the full account number, bank name, account name, ID number, and contact information can be read; if only restricted access is currently allowed, the platform will reduce the original access level Lo to L2 and generate a downgrade operation instruction G; Under restricted access level L2, the readable dataset is limited to a set including the last four digits of the account number, the bank name, the account name abbreviation, and the last four digits of the ID number; if more stringent constraints are required, it can be reduced to L1, which only returns the existence of the object and its category label, without exposing any detailed fields; After generating the downgrade operation instruction, the execution plane will not change the business node logic, but will re-call the bound system call tool, but with new access level parameters. For example, the original Uacc tool was called with parameters to read the full account, OA and L3, but now the Uacc tool is called with parameters to read the de-identified account, OA and L2. After receiving the L2 parameters, the tool layer directly performs field filtering and desensitization on the data source side, instead of retrieving all data first and then deleting fields at the application layer. This avoids sensitive original text from entering the execution plane memory, further reducing the risk of leakage. If the target object of the node is an attached image, the degradation strategy can be to return the optical character recognition summary text instead of the original image. If the target object is a fund interface, the degradation strategy can be to change from directly initiating the transfer to generating an authorization instruction but not issuing it.

[0060] As an exception handling mechanism, not all nodes are suitable for degradation. When an execution node must rely on complete fields to complete legitimate processing, such as when a regulatory reporting node requires complete transaction account and legal information, the system will not forge degradation data even if it receives a failed result. Instead, it will mark the node as non-degradable.

[0061] When the target object cannot be identified, for example, when the object type is unknown due to an exception returned by the tool, the system does not perform an unconditional retry, but instead enters the exception handling process; when the original access level is already the lowest level L1 and still fails, it means that the current environment does not allow any related access. At this time, the thread should be frozen, rather than continuing to shrink to an unavailable state.

[0062] When the refund process reaches the customer material verification stage, the stage originally requires reading a scanned copy of the business license, an image of the handler's ID, and account verification. However, because the system detected that the operation period had entered a high-risk window, the security plane only allowed restricted access. Therefore, the platform reduced the original access level for reading the original image and complete document information to the restricted level for reading the optical character recognition digest and field anonymization results, and re-called the document extraction tool.

[0063] This node can still obtain key information such as the company name being consistent, the last four digits of the document number matching, and the account proof being valid, which is sufficient to support the generation of subsequent approval opinions.

[0064] The purpose of this mechanism is to transform complete failure into restricted continuation through fine-grained access level contraction, thereby achieving compatibility between security constraints and business continuity, and reducing the risk of chain-wide shutdown due to restrictions on a single sensitive field.

[0065] In a preferred embodiment of the present invention, re-invoking the system call tool includes: initializing a retry count counter; when the value of the retry count counter is less than a preset maximum retry count threshold, using the product of a preset base delay time and the value of the retry count counter as the current retry delay time.

[0066] After the current retry delay time has elapsed, a retry request is initiated, and the value of the retry count counter is increased by a preset step. When the value of the retry count counter is greater than or equal to the preset maximum retry count threshold, the exception handling process is triggered.

[0067] This embodiment provides a retry control mechanism after degradation. Specifically, if the system immediately and repeatedly calls the tool during periods of restricted access or unstable external interface status after only introducing degradation operations, two problems may arise: First, high-concurrency retries will further increase the interface load; second, if the environment attributes have not yet recovered, continuous retries will only produce the same failure result, reducing overall execution efficiency. Therefore, this embodiment introduces retry control with increasing delay on the basis of degradation to achieve smooth system recovery rather than disordered replay. Specifically, when a node is determined to be allowed to perform downgraded execution but the first call fails, the plane initialization retry count counter k is executed; the preset maximum retry count threshold can be set to 3, the base delay time is 200 milliseconds, and the preset step size is 1; Using this as an example: Before the first retry, the retry counter k is 0, and the current retry delay is 200 × 0 = 0 milliseconds, so a fallback call can be initiated immediately; if it fails, k increases to 1; the second retry delay is 200 × 1 = 200 milliseconds; after the second failure, k increases to 2; the third retry delay is 200 × 2 = 400 milliseconds; if the third still fails, k becomes 3, reaching the preset maximum retry threshold, and the system no longer continues to retry, but triggers the exception handling process; this forms a simple and controllable linear backoff process; In actual execution, retry requests use the same node identifier and the same business context, but will include the updated number of retries, the most recent failure reason, and the current downgrade level; for example, for a node that reads de-identified account information, the first failure reason may be a temporary timeout of the data source, and the second failure reason may be that the permission cache has not been refreshed; Before each retry, the system can reconfirm with the security plane whether the current authentication still allows downgraded execution, preventing the environmental risk from further increasing during the delay period. If the dynamic attribute recovers to a lower risk level during the retry interval, the platform can also restore a higher level of restricted access in the next retry. If the risk further deteriorates, subsequent retries can be directly terminated and the system can be frozen.

[0068] As an exception handling mechanism, when the base delay time is configured to 0 or an abnormally negative value, the system automatically falls back to the default delay template to avoid forming a spin call; when the retry count counter goes out of bounds or is lost due to an exception, the system treats it as if the threshold has been reached and directly enters the exception process to prevent infinite retries. When a node fails for a reason that clearly indicates it is unrecoverable, such as the target object no longer existing, the current tenant being blocked, or the policy explicitly prohibiting the operation, the system does not enter the retry queue but immediately terminates the node and records the reason. The exception handling process may include: generating a work order, notifying manual review, persisting the current state, rolling back the temporary results that have been generated, and transferring the execution flow to an alternative node. In the refund approval process, the system initiates a downgraded call to the node that reads the de-identified customer material summary. If the first call encounters an image service timeout, the system immediately performs the first retry. The system waits 200 milliseconds before the second retry and 400 milliseconds before the third retry. If the summary still cannot be obtained successfully on the third attempt, the system will no longer continue to attempt to access the image service. Instead, it will transfer the refund task to the manual document verification process and retain the verification results and approval context of the previous transaction for subsequent processing.

[0069] The purpose of this mechanism is to control the pace of degradation retry in a bounded, incremental delay manner, so as to achieve controllable recovery of resource consumption in failure scenarios and avoid system performance fluctuations and multi-node service interruptions caused by infinite retries or intensive replays.

[0070] In a preferred embodiment of the present invention, the thread interception and state freezing mechanism includes: monitoring system call requests initiated by the execution node; determining whether the system call request is included in a preset registration and approval list; generating an unauthorized alarm signal when the system call request is not included in the preset registration and approval list; and allowing the system call request when the system call request is included in the preset registration and approval list. In response to an unauthorized access alarm signal, the execution plane suspends the current execution thread of the execution node and saves the current execution state to a pre-defined running sandbox in a multi-tenant logical isolation environment.

[0071] This embodiment provides a mechanism for thread interception and state freezing; specifically, after introducing degradation and retry, most business execution anomalies caused by permission contraction can be smoothly controlled, but there is still a higher risk situation, namely, an execution node attempts to initiate an unregistered system call; For example, a node that should only query transaction summaries might attempt to access an external transfer interface, or a plugin that should read the current tenant's data might try to access another tenant's cache across the sandbox; such behavior cannot be mitigated by ordinary degradation and needs to be intercepted immediately; therefore, this embodiment sets up a registration approval list and a thread-level freezing mechanism. Specifically, before each node invokes a system tool, the execution plane passes through a call monitoring layer. The monitoring layer reads the system call request submitted by the current node, including the call name, parameter summary, target object, tenant identifier, and sandbox number. The request is then compared with a preset registration and approval list. This list can be understood as a whitelist mapping between nodes and callable tools. For example, node N1 is allowed to access the set of data including U1 transaction query and Ulog audit records when reading the original transaction log, but is not allowed to access the set of data including Ufund fund allocation and Ucache cross-tenant cache read / write. A simplified deduction can be made: if the current request information includes node N1, access to Ufund, and tenant T02, but N1 is only registered with U1 and Ulog in the whitelist, then it is determined that the current request information is not included in the registration approval list, and the system immediately generates an unauthorized alarm signal A1. In response to an overreach warning signal, the execution plane does not wait for the request to actually reach the underlying interface, but instead suspends the currently executing thread; for example, it switches the state of thread TH21 from RUNNING to SUSPEND and prevents it from continuing to acquire CPU time slices. Meanwhile, the system serializes the current execution state and writes it to the runtime sandbox to which the tenant belongs. The serialized content may include the current node identifier, executed steps, intermediate result summary, call stack summary, the most recent legitimate authentication result, and a snapshot of unauthorized requests. The effect of this is that, on the one hand, unauthorized behavior is blocked immediately; on the other hand, the task context is completely preserved, which is convenient for subsequent manual review, policy learning, or security forensics. If the review confirms that it is a mismatched tool or a missing approval list, it can be restored from the freeze point after correction. If it is confirmed that it is an unauthorized access, the task can be terminated and the responsible party can be traced.

[0072] As an exception handling mechanism, when a system call request fails to match the approval list but only because of a version number discrepancy, such as a change in name after a tool upgrade but no change in actual permissions, the system can first write it to the pending confirmation alarm queue and suspend the thread according to a high-risk conservative strategy, waiting for the rules to be synchronized. When the sandbox storage space is close to the limit, the system prioritizes saving necessary state summaries and evidence of unauthorized access, without losing key fields for security auditing; when the same thread triggers multiple unauthorized access alarms in a row, the system can upgrade to a tenant-level temporary restriction, suspending new tasks of the same plugin version in that tenant from entering the execution plane, thus preventing the spread of risks. During the approval opinion generation stage of the refund process, a plugin attempted to directly call the fund transfer interface without registration in order to bypass the advanced authorization node; the monitoring layer identified that the call was not in the set of tools allowed by the node and immediately generated an unauthorized alarm. The execution plane immediately suspends thread TH21 and saves the currently completed transaction verification results, material summary, approval draft, and unauthorized call snapshot to the T02 tenant's runtime sandbox; subsequently, the security administrator reviews whether the plugin version has been tampered with, or the business administrator confirms whether it is a missing configuration in the approval list.

[0073] The purpose of this mechanism is to establish an immediate blocking path for unauthorized calls that cannot be downgraded or tolerated, thereby blocking and isolating risky behaviors during execution and preserving the scene, preventing single-node unauthorized calls from spreading into security incidents across tenants or systems.

[0074] In a preferred embodiment of the present invention, the current environment attribute data includes network address drift status data, operation time period span status data, and real-time risk score data calculated by multiplying the number of operation failures of the acquired execution node by a preset penalty coefficient; the initial intent data includes natural language parsing features and task objective parameters.

[0075] This embodiment provides a mechanism for constructing environmental attributes and initial intent data. Specifically, in the aforementioned business scenario, if the environmental attributes only collect static login information and do not describe changes during the business execution process, the security plane will find it difficult to detect risk migration in a timely manner. Similarly, if the initial intent only retains a piece of raw text without extracting its structured features, the scheduling plane will find it difficult to stably generate an executable node flow. Therefore, this embodiment clarifies the environmental attributes and the composition of the initial intent, so that subsequent orchestration and authentication have a basis.

[0076] Specifically, the current environmental attribute data includes at least three categories. The first category is network address drift status data, which describes whether the terminal source has changed within the same task lifecycle. This can be simplified to a binary or multi-valued label. For example, when the network address drift status data Dnet is 0, it indicates that the network address is stable; when Dnet is 1, it indicates a switch from the intranet to the external proxy; and when Dnet is 2, it indicates a cross-regional jump. The second category is operation period crossing status data, which characterizes whether the business has entered a sensitive time window. For example, when the operation period crossing status data Hcross is 0, it indicates that it is still in normal business hours; and when Hcross is 1, it indicates that it has entered the end-of-day settlement window. The third category is real-time risk score data, which can be obtained by multiplying the number of current operation failures by a preset penalty coefficient. For example, if the current node has 2 failures and the penalty coefficient is 0.15, then the real-time risk score is 0.30. If network drift and time period spanning two states are superimposed, the score can be further interpreted as a higher risk level in the attribute model. The initial intent data includes at least natural language parsing features and task objective parameters. Natural language parsing features reflect the actions, objects, and constraints in the original instructions. For example, from "Please verify this enterprise refund application and submit it for review after the materials are complete", the action features include verification and submission for review; the object features include enterprise refund application and materials; and the condition features include "after the materials are complete". Task target parameters are structured parameters that are directly used for execution orchestration, such as customer number, transaction number, refund amount, refund reason, target account, and priority. For ease of deduction, we can assume that a certain request, after being parsed, yields a feature F, which includes action f1 verification, action f2 submission, constraint f3 material completeness; and a target parameter M, which includes customer C01, transaction TX9, amount 1,000,000, and reason R07. Based on this, the scheduling plane can generate an execution flow biased towards the verification-review path, instead of mistakenly scheduling it as a direct allocation path.

[0077] As an exception handling mechanism, when the network address drift status cannot be collected, the system can record the network address drift status data Dnet as an unknown state and treat it as a high-risk state in the attribute model; when the number of operation failures is greater than or equal to the preset limit, for example, due to the instantaneous accumulation of external dependency failures, the system can truncate the upper limit of the number of failures to avoid the risk score from increasing indefinitely and causing all tasks to be locked for a long time. When the natural language parsing features are incomplete, such as only being able to identify refunds but not submissions for review, the system can first generate a minimum executable chain based on the identified target parameters and add a manual confirmation node; when there is a conflict between the task target parameters, such as a mismatch between the customer number and the transaction number, the system will suspend formal execution and initiate a parameter verification process. In the refund process, the teller submitted a text message to process the abnormal large refund from yesterday for customer C01. First, the original transaction and information were verified, and then the information was submitted to the finance department for review. The system extracted natural language parsing features such as verifying the original transaction, verifying information, and submitting to the finance department for review, and combined them with the transaction number TX9 and the amount of 1 million yuan in the input page to form the task target parameters. Meanwhile, the system continuously records whether the network address drifts from the counter's dedicated network, whether it enters the clearing period after 6 PM, and the real-time risk score formed by multiplying the number of node failures by 0.15 during task execution; the above data together serve as the input basis for subsequent orchestration and authentication.

[0078] Furthermore, to maintain consistency with the risk scoring examples in the aforementioned embodiments, the basic generation rule for real-time risk scoring at the environmental attribute level is fixed as the current number of operation failures × a preset penalty coefficient. However, network address drift status data and operation time span status data do not directly rewrite the product result itself, but are fed into the attribute model as parallel inputs, and the attribute model gives the same risk score a more stringent or more lenient interpretation. For example, when the number of failures is 2 and the penalty coefficient is 0.15, the basic real-time risk score is 0.30. If Dnet is 0 and Hcross is 0 at this time, the attribute model can classify it as low to medium risk. If it is still 0.30 but Dnet is 1 or Hcross is 1 at the same time, the attribute model can raise the overall constraint to a higher level. This can avoid confusing the score generation rules with the score interpretation rules, and ensure that the source of the risk score is clear and consistent with the calculation method.

[0079] Furthermore, in the actual system, the aforementioned values ​​such as 0.35, 0.62, and 0.81 can be understood as the standardized real-time risk score output values; the underlying value still uses the product of the number of failures and the penalty coefficient as the original input, and then writes it into the environmental attribute data after falling into the corresponding standardized range according to the tenant's unified score mapping table. For example, when the original product value is low, it can be mapped to a low-risk range around 0.35, and when the original product value increases, it can be mapped to a medium-to-high-risk range corresponding to 0.62 or 0.81. This mapping does not change the fundamental source of the risk score, which is generated by the product of the number of failures and the penalty coefficient. It is only used to solve the problem of inconsistent risk scales between different nodes and different tenants.

[0080] The purpose of this step is to transform business intent and environmental changes from raw, chaotic information into computable features and parameters, thereby enabling accurate subsequent task orchestration and real-time dynamic authentication.

[0081] In a preferred embodiment of the present invention, the task orchestration module includes a preset task parsing engine based on a natural language processing model; the task orchestration module is specifically used to: input initial intent data into the preset task parsing engine based on a natural language processing model; output a directed acyclic graph of tasks containing multiple execution nodes from the preset task parsing engine based on a natural language processing model; and initialize a dynamic task execution flow through a scheduling plane based on the topology of the task directed acyclic graph.

[0082] This embodiment provides a task orchestration mechanism based on a natural language processing model. Specifically, in the aforementioned continuous business, if the system can only receive fixed processes that are pre-configured manually, it is difficult to adapt to changes in different refund reasons, different material completeness, and different authorization levels. For example, some refunds require checking the original transaction first and then verifying the attachments, while others must first go through anti-fraud verification. Fixed templates easily lead to poor orchestration flexibility.

[0083] Therefore, in this embodiment, the initial intent is transformed into a directed acyclic graph of tasks through a task parsing engine, and then the scheduling plane initializes the dynamic task execution flow according to the topology.

[0084] Specifically, the task parsing engine receives the initial intent data and extracts the action words, object words, sequence words, and condition words from it; For example, when inputting a statement to verify the original transaction and attachments of yesterday's large refund for a company, if the materials are complete, an approval opinion is generated and submitted for financial review. The engine can identify the action sequence including verifying the original transaction, verifying attachments, generating an approval opinion, and submitting for financial review, as well as the conditional dependency including that the approval opinion can only be generated after the materials are complete; the engine outputs a directed acyclic graph of tasks. For ease of understanding, a four-node graph G can be constructed. The four-node graph G includes N1 original transaction verification, N2 attachment verification, N3 approval opinion generation, and N4 submission for financial review. The edge relationship is N1 pointing to N3, N2 pointing to N3, and N3 pointing to N4. Here, N1 and N2 can be performed in parallel, N3 must wait for the two to complete before starting, and N4 depends on the output of N3. The scheduling plane initializes the dynamic task execution flow based on the topology of the directed acyclic graph; specifically, the in-degree of the graph can be counted first: N1 and N2 have an in-degree of 0, N3 has an in-degree of 2, and N4 has an in-degree of 1. During initialization, N1 and N2 are added to the ready queue Qready; after both produce results and update their in-degree, N3 enters the ready state; then N4 is executed; this topology initialization method enables the system to naturally express parallel verification, conditional dependencies, and post-approval without having to hardcode the process; if a node is subsequently downgraded due to authentication contraction, the scheduling plane can also replace only the execution version or access level of the node without changing the graph structure.

[0085] As an exception handling mechanism, when the graph output by the natural language processing model contains loops, such as incorrectly identifying N3 as dependent on N1 to form a closed loop, the system will perform loop detection before initialization. Once a loop is found, it will not enter the execution plane, but will instead return to manual confirmation or use the default template. When the model cannot identify explicit dependencies, a linear conservative process can be generated first, and the basic order of verification, approval, and submission can be followed. When the input intent is too brief, only containing the processing of a refund application without specifying the specific action, the system can match the corresponding standard subgraph based on the amount, reason code, and tenant policy in the task objective parameters, and then supplement the manual confirmation node. A branch office inputs a request to process an abnormal refund for customer C01. First, it checks yesterday's transaction history and business license materials. After approval, it generates an approval opinion and then submits it to the finance manager. The task parsing engine identifies two parallel pre-tasks: flow verification and material verification. Following these are approval opinion generation and financial submission, thus forming a four-node directed acyclic graph. The scheduling plane starts the two verification nodes first according to the topological relationship. After the two are completed, the approval node is started. If the approval node passes the authentication, it continues to submit to the financial manager; otherwise, it is downgraded or frozen according to the result of the security plane.

[0086] The purpose of this step is to transform natural language business intent into a structured, schedulable task dependency graph, thereby enabling dynamic orchestration and controllable execution of complex business processes.

[0087] In a preferred embodiment of the present invention, the multi-tenant logical isolation environment is built based on a preset microkernel architecture; the microkernel architecture includes an underlying scheduling engine and multiple mutually isolated running sandboxes; execution nodes are loaded into the running sandboxes in the form of plug-ins, and the underlying scheduling engine performs unified resource allocation.

[0088] This embodiment provides a multi-user logical isolation mechanism based on a microkernel architecture. Specifically, although the execution order can be organized after orchestration is completed solely based on the directed acyclic graph of tasks, if different tenants and different plugins share the same execution environment, it is very easy to cause context interference, resource contention, and unauthorized access. Especially in the unified platform of the bank's head office, refund tasks from multiple branches will enter concurrently. If there is no isolation structure, a tenant plugin may accidentally read the intermediate state of other tenants. To solve this defect, this embodiment adopts a microkernel architecture of underlying scheduling engine + multiple mutually isolated running sandboxes. Specifically, the underlying scheduling engine is responsible for unified resource allocation, task queuing, and lifecycle management, while specific business functions are loaded into each running sandbox as plug-ins; each running sandbox corresponds to an isolated execution domain, which can be bound to tenant identifiers, permission boundaries, and visible resource ranges.

[0089] A simplified deduction can be made: Assume there are two tenants T01 and T02, corresponding to two running sandboxes S1 and S2; the refund task nodes N1, N2, and N3 of T01 are loaded into S1, and the corresponding nodes of T02 are loaded into S2; Even if both call the same transaction query plugin, the plugin instances run within their respective sandboxes, with memory space, temporary file paths, and state caches isolated from each other. The underlying scheduling engine is only responsible for allocating CPU time slices, memory quotas, and tool access tokens to S1 and S2 according to priority, without allowing one sandbox to directly access the context object of another sandbox.

[0090] The advantage of loading in the form of plugins is that the node functions can be expanded as needed; for example, the original transaction verification node can load a transaction query plugin, the material verification node can load an image summary plugin, and the approval node can load an opinion generation plugin; after receiving the directed acyclic graph of tasks, the underlying scheduling engine only needs to load the corresponding plugins into the specified sandbox according to the node type, and inject the tool binding relationship and security policy together.

[0091] This preserves functional scalability while controlling plugin boundaries through sandbox isolation. Furthermore, the scheduling engine can perform unified resource allocation based on tenant priority and node sensitivity level, such as placing high-priority liquidation-related nodes in a high-security queue and ordinary query nodes in a standard queue.

[0092] As an exception handling mechanism, when a plugin fails to load, such as due to version incompatibility or signature verification failure, the scheduling engine does not skip the node directly, but attempts to load a backup plugin of the same type; if there is no backup plugin, the task is transferred to the manual or exception handling path; when a running sandbox exits abnormally, the scheduling engine only reclaims the tasks in that sandbox, without affecting the continued execution of other tenant sandboxes. When resources are scarce, the scheduling engine prioritizes nodes that have entered the sensitive stage, while applying rate limiting to low-priority non-critical nodes; if a plugin is detected to have a tendency to access across sandboxes, the underlying scheduling engine can work with the security plane to directly disable that plugin version. During peak refund periods, Branch A and Branch B simultaneously submit multiple abnormal refunds. The system places Branch A's task nodes into sandbox S1 and Branch B's task nodes into sandbox S2. The underlying scheduling engine allocates resources to S1 and S2 uniformly and prioritizes the verification nodes of higher-amount refunds based on their amount. Even if a plugin in Branch A is suspended due to version anomalies, Branch B's sandbox and task flow will not be affected, thus ensuring stable operation under multi-tenant concurrency.

[0093] The purpose of this mechanism is to implement unified scheduling and tenant isolation simultaneously by combining microkernel and sandbox isolation, thereby achieving pluggable expansion of execution nodes and stable maintenance of cross-tenant security boundaries.

[0094] In a preferred embodiment of the present invention, the state update module is specifically used to perform the following operations after the output node execution result: using the node execution result as the input state data of the next execution node; updating the current execution state; and feeding back the updated current execution state to the scheduling plane to update the global execution progress of the dynamic task execution flow.

[0095] This embodiment provides a node result-driven state update mechanism. Specifically, in the aforementioned scheme, even if orchestration, authentication, degradation, and freezing capabilities are already available, if the node execution results cannot be written back to the global state in a timely manner, the scheduling plane cannot accurately determine which subsequent nodes have met the startup conditions and which nodes should switch to alternative paths, which may lead to duplicate execution, dependency confusion, or progress distortion. Therefore, this embodiment sets up a state update module to immediately complete input transmission, state update, and global progress write-back after each node outputs its results.

[0096] Specifically, when a node completes execution and outputs the node execution result, the state update module converts the result into input state data that the next node can directly read. Taking the N1 original transaction verification and N2 material verification in a directed acyclic graph as an example, the N1 output result R1 may be that the original transaction exists, the amount is consistent, and the transaction number TX9 is valid. The N2 output result R2 may be that the business license is valid, the last four digits of the document match, and the account certificate is valid.

[0097] The status update module writes R1 and R2 into the global current execution status Sg and forms the input status In3 for N3 to use in generating approval opinions. The input status In3 can be represented as transaction verification passed, material verification passed, or sensitive fields have been desensitized. N3 can carry out processing based on the input status In3 without having to look back at the original data source again.

[0098] Furthermore, the state update module updates the current execution state, including node completion flag, result summary, execution duration, actual access level, and exception flag; a simplified deduction can be made: the initial global state can be represented as Sg0, where Sg0 includes N1 not completed, N2 not completed, N3 not ready, and N4 not ready; When N1 is completed, it is updated to Sg1, which includes N1 completed, N2 not completed, N3 not ready, and N4 not ready. When N2 is also completed, it is updated to Sg2, which includes N1 completed, N2 completed, N3 ready, and N4 not ready. At this time, the updated current execution status is fed back to the scheduling plane. The scheduling plane finds that the preconditions of N3 have been met based on Sg2, so it adds N3 to the ready queue and updates the global execution progress. For example, the total progress can be advanced from 50% to 75%. If N2 is completed in a degraded manner, the scheduling plane also records the tag that the input of N3 contains the de-identified field, so that subsequent nodes can select the adaptation logic.

[0099] As an exception handling mechanism, when the node output result is empty or in the wrong format, the status update module does not directly pass the empty result to the subsequent node, but writes an invalid result flag, and the scheduling plane decides whether to retry the current node, go to the alternative node or terminate the execution. When multiple preceding nodes complete in parallel and their results conflict, for example, the amount determined by N1 is consistent while the amount in the accompanying materials of N2 is inconsistent, the status update module will first generate a conflict flag and then feed the flag back to the scheduling plane, which will insert a manual review node instead of unconditionally allowing N3 to proceed. When the scheduling plane fails to provide feedback, the status update module will still persist the current status change to ensure that the task can resume from the latest status when it is restored.

[0100] In the refund process, the original transaction verification node first returns that the transaction was a corporate payment received yesterday, amounting to 1 million yuan, which meets the basis for a refund. The material verification node returns that the company's business license is valid, but the account information is obtained in an anonymized manner. The status update module merges these two results into the input status of the approval node, updates the global status to "approval node ready", restricts subsequent sensitive fields, and feeds back to the scheduling plane. The scheduling plane initiates the approval opinion generation node based on this; if the approval node is successful, its result is then used as input for the financial review node, continuously advancing the entire refund execution flow.

[0101] The purpose of this mechanism is to establish a closed-loop update path between node results and global progress, so as to ensure that the execution flow can maintain a consistent state evolution under parallel, degraded and abnormal conditions, and avoid scheduling distortion and context breakage.

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

Claims

1. A dynamically programmable execution-oriented intelligent central platform system, characterized in that, include: The data acquisition module is used to acquire initial intent data and current environmental attribute data; The task orchestration module is used to generate a dynamic task execution flow and allocate resources based on initial intent data through the scheduling plane; wherein, the dynamic task execution flow consists of multiple execution nodes and is carried by a multi-tenant logical isolation environment including the scheduling plane, the execution plane and the security plane; the system is pre-configured with system call tools bound to the execution nodes and preset degradation strategies; The core processing module is used to synchronize the current execution state and the current environment attribute data to the security plane when the execution node is transferred in the execution plane and the current execution state is generated; the security plane performs dynamic attribute adaptive authentication on the current execution state and the current environment attribute data based on a preset role-based access control model and an attribute-based access control model, and generates an authentication result; The result generation module is used to control the execution plane to call the system call tool and output the node execution result when the authentication result indicates that execution is allowed; The status update module is used to update the current execution status based on the execution result of the node; The feedback adaptive module is used to adjust the state of the dynamic task execution flow based on the authentication result and the node execution result; The state adjustment of the dynamic task execution flow includes: when the authentication result indicates that the permission verification is successful, controlling the execution plane to continue flowing to subsequent execution nodes; when the authentication result indicates that the permission verification is unsuccessful and the preset degradation strategy exists, triggering a degradation retry mechanism to adjust the access level of the system call tool and re-execute the execution node; when the authentication result indicates that the permission verification is unsuccessful and the preset degradation strategy does not exist, triggering a thread interception and state freeze mechanism to interrupt the dynamic task execution flow.

2. The dynamically programmable execution-oriented intelligent central platform system according to claim 1, characterized in that, The core processing module synchronizes the current execution state and the current environment attribute data to the security plane, including: Extract the context state data corresponding to the execution node from the current execution state; The context state data and the current environment attribute data are encapsulated into a state synchronization data packet; The state synchronization data packets are sent to the security plane via a pre-defined cross-plane communication bus based on shared memory.

3. The dynamically programmable execution-oriented intelligent central platform system according to claim 2, characterized in that, The security plane performs dynamic attribute adaptive authentication, including: The state synchronization data packet is parsed, the current role identifier is extracted from the context state data, and dynamic attribute features are extracted from the current environment attribute data; Input the current role identifier into the preset role-based access control model to obtain a static permission set; The dynamic attribute features are input into the preset attribute-based access control model to obtain dynamic permission constraints. The static permission set is filtered and selected based on the dynamic permission constraints to generate the authentication result.

4. The dynamically programmable execution-oriented intelligent central platform system according to claim 1, characterized in that, The triggering downgrade retry mechanism includes: The execution node is parsed to obtain the target operation object corresponding to the execution node; Determine the original access level of the target operation object; The original access level is reduced to a restricted access level, generating a downgrade operation instruction; wherein, the restricted access level includes field-level de-identification access level; Based on the downgrade operation instruction, the execution plane is controlled to re-invoke the system call tool.

5. The dynamically programmable execution-oriented intelligent central platform system according to claim 4, characterized in that, The re-invocation of the system call tool includes: Initialize the retry count counter; When the value of the retry count counter is less than the preset maximum retry count threshold, the product of the preset base delay time and the value of the retry count counter is used as the current retry delay time. After the current retry delay time has elapsed, a retry request is initiated, and the value of the retry count counter is increased by a preset step. When the value of the retry count counter is greater than or equal to the preset maximum retry count threshold, the exception handling process is triggered.

6. The dynamically programmable execution-oriented intelligent central platform system according to claim 1, characterized in that, The trigger thread interception and state freezing mechanism includes: Monitor the system call requests initiated by the execution node; Determine whether the system call request is included in the preset registration and approval list; When the system call request is not included in the preset registration and approval list, an unauthorized alarm signal is generated; when the system call request is included in the preset registration and approval list, the system call request is allowed. In response to the unauthorized access alarm signal, the execution plane is controlled to suspend the current execution thread of the execution node and save the current execution state to a preset running sandbox in the multi-tenant logical isolation environment.

7. The dynamically programmable execution-oriented intelligent central platform system according to claim 1, characterized in that, The current environment attribute data includes network address drift status data, operation time period crossing status data, and real-time risk score data calculated by multiplying the number of operation failures of the obtained execution node by a preset penalty coefficient. The initial intent data includes natural language parsing features and task objective parameters.

8. The dynamically programmable execution-based intelligent central platform system according to claim 1, characterized in that, The task orchestration module includes a preset task parsing engine based on a natural language processing model; The task orchestration module is specifically used for: The initial intent data is input into the preset task parsing engine based on the natural language processing model; The preset task parsing engine based on the natural language processing model outputs a directed acyclic graph of tasks containing multiple execution nodes; Based on the topology of the directed acyclic graph of the task, the dynamic task execution flow is initialized through the scheduling plane.

9. The dynamically arrangable execution-type intelligent central platform system according to claim 8, characterized in that, The multi-tenant logical isolation environment is built on a preset microkernel architecture; the microkernel architecture includes an underlying scheduling engine and multiple mutually isolated running sandboxes; the execution nodes are loaded into the running sandboxes in the form of plug-ins, and the underlying scheduling engine performs unified resource allocation.

10. The dynamically arrangable execution-based intelligent central platform system according to claim 1, characterized in that, The state update module is specifically used to perform the following operations after outputting the execution result of the node: The execution result of the node is used as the input status data for the next execution node; Update the current execution status; The updated current execution status is fed back to the scheduling plane to update the global execution progress of the dynamic task execution flow.

Images