Control system and method for hybrid HPC-QPU orchestration

Abstract

Disclosed are a computer-implemented method and a computer-implemented system for orchestrating hybrid quantum-classical execution between high-performance computing (HPC) infrastructure and one or more quantum processors (QPU). An orchestration module breaks down a work flow into subtasks and, for each subtask, compiles multiresource HPC and QPU processing telemetrics, normalises same to a canonical vector and evaluates proposed plans under hard budget constraints (time, executions, cost and / or depth). The system automatically selects an execution resource (HPC or QPU) and, when executed in an QPU, applies tiered error mitigation and verifies the result using an acceptance gate. In the event of rejection, the system executes a deterministic recovery policy with retry, execution resource switching and / or backup routing to HPC. An auditable record of decisions and metrics is generated for traceability and feedback.

Description

[0001] CLOSED-LOOP CONTROL SYSTEM AND PROCEDURE FOR HPC-QPU HYBRID ORCHESTRATION 1. Technical Field

[0002] The present invention relates to the field of hybrid quantum-classical computing systems integrated with high-performance computing (HPC), and, in particular, to computer-implemented methods and systems for the dynamic orchestration of workloads that combine one or more quantum processors (QPUs) — accessible locally or remotely — with classical computing infrastructures (CPU / GPUs) managed by schedulers and parallel execution environments.

[0003] More specifically, the invention belongs to the area of ​​control and execution planning of hybrid workflows in NISQ (Noisy Intermediate-Scale Quantum) environments, where the temporal variability of noise, qubit availability, network latency, and execution queues significantly affect the reliability and efficiency of the results.The invention addresses the interaction between: (i) multi-backend telemetry of the QPU (e.g. fidelity metrics, error rates, decoherence parameters, and calibration status) and (ii) operational telemetry of the HPC (e.g., cluster saturation, queues, resource availability), to execute a control mechanism that decides, by subtask, the allocation of compute to the QPU or the HPC, applies error mitigation under budget constraints, verifies the results through an acceptance gateway, and executes deterministic recovery policies by retrying, backend switching, or fallback to HPC, leaving auditable evidence of the decision.

[0004] The invention is applicable to multiple industrial and scientific domains that require highly complex simulation and optimization, including, but not limited to, computational chemistry, drug discovery, materials science, combinatorial optimization, and machine learning, where the goal is to selectively leverage quantum resources without compromising the continuity, traceability, and reproducibility of the hybrid workflow.

[0005] 2. Background and technical problem (summary)

[0006] Hybrid quantum-classical algorithms (e.g., variational and optimization) have driven the use of quantum processors (QPUs) in conjunction with high-performance computing (HPC) to address simulation, optimization, and machine learning problems. In practice, these workflows are structured as processes composed of multiple subtasks, some of which can benefit from quantum execution, while others are efficiently solved on CPU / GPU. However, currently available quantum environments are characterized by NISQ limitations, including noise, decoherence, time variability in calibration, and constraints on the number of qubits, circuit depth, and availability, as well as queues and latencies associated with remote access.

[0007] In the current state of the art, hybrid integration approaches exist that allow sending circuits to a QPU and running classical computing on HPC infrastructures, as well as scheduling or prioritization mechanisms based on availability or time estimates. Error mitigation techniques are also employed to improve the quality of quantum results.However, such solutions often present relevant limitations for industrial operation: (i) HPC / QPU allocation decisions that depend on fixed rules or human intervention, (ii) use of mitigation as a configured parameter without a control loop that verifies results and reacts automatically, (iii) lack of a consistent operational metric to compare heterogeneous telemetry from multiple backends (multi-backend telemetry), and (iv) absence of a comprehensive, deterministic, and explainable policy for recovery from invalid quantum executions (e.g., retries, backend switching, or fallback to HPC) under real cost / time / resource constraints.Consequently, an objective technical problem arises: how to reliably and efficiently execute hybrid HPC-QPU workflows, minimizing unsuccessful quantum executions and preventing noise-degraded results from contaminating subsequent workflow stages, all within technical constraints (computation time, shots, cost, depth limits, availability) and with sufficient traceability for reproducibility and auditing. Specifically, a mechanism is required that: (a) collects and normalizes critical HPC and QPU metrics, (b) makes subtask allocation decisions under constraints, (c) applies mitigation in stages when necessary, (d) determines acceptance / rejection using an Acceptance Gate, and (e) executes a deterministic recovery policy (retry / switch / fa / / £>ac) while maintaining an auditable record of decisions.

[0008] 3. Summary of the invention

[0009] The present invention provides a procedure and a hybrid quantum-classical computing system configured to dynamically orchestrate the execution of a workflow composed of a plurality of subtasks between a high-performance computing (HPC) infrastructure and one or more locally or remotely accessible quantum processors (QPUs).The invention is based on a closed-loop control mechanism that, for each subtask, operates in a verifiable and explainable manner through a mandatory technical sequence: (i) collecting and normalizing multi-backend telemetry; (ii) executing decision logic for HPC / QPU allocation under strict budget constraints; (iii) executing, where appropriate, automatic and phased error mitigation; (iv) applying a post-mitigation Acceptance Gate that determines the acceptance or rejection of the result; (v) executing a deterministic recovery policy that includes retry, backend switch, postponement, or fallback to HPC; and (vi) generating and storing an auditable decision record that documents the metrics used, the decision taken, the mitigation applied, the verification result, and the reason for any recovery or fallback.

[0010] In one embodiment, the procedure decomposes a computational problem into subtasks with technical attributes (e.g., estimated complexity, qubit requirements, expected depth, tolerances, and / or deadlines). The orchestration module collects metrics from the QPU (e.g., fidelity, error rate, decoherence parameters, calibration time state, queues, and latency) and HPC metrics (e.g., CPU / GPU availability, cluster saturation, queues, and estimated times) and transforms them into a canonical decision vector. A decision function (implemented using rules and / or machine learning) is then evaluated on this vector to allocate each subtask to the most suitable resource. The invention further imposes a technical budget (e.g., time limits, number of shots, cost, or circuit depth) as a formal operational constraint.When a subtask is assigned to the QPU, the system evaluates a quality metric of the result and, if it does not meet the predefined criteria, automatically applies mitigation techniques (e.g., statistical repetition, zero-noise extrapolation, or others), after which it verifies the result using the Acceptance Gate. If the result still does not meet the criteria, the system executes the deterministic recovery policy and, in particular, may activate a fallback to execute that subtask in the HPC, ensuring workflow continuity. The invention produces significant technical effects: a reduction in unsuccessful quantum executions, a decrease in the total workflow completion time (TCT), better utilization of HPC / QPU resources, and greater reproducibility by preventing noise-degraded results from propagating to subsequent stages and by maintaining traceability and evidence of decisions. The invention is applicable to multiple industrial and scientific domains (e.g.(computational chemistry, materials, combinatorial optimization, machine learning), and can be deployed in on-premises, cloud, or hybrid deployments.

[0011] In further embodiments, the orchestration module can be run wholly or partially on reconfigurable hardware (FPGA) to reduce scheduling latency and allow controlled logic updates, always maintaining the same special inventive concept: verifiable closed-loop control for hybrid HPC-QPU orchestration.

[0012] 3. Glossary and definitions

[0013] For the purposes of this application, the following terms are used with the meaning indicated, without limiting the scope of the invention to specific embodiments.

[0014] Workflow. A set of computational operations associated with a problem, representable as a directed graph G = (V, E), where each node ie V corresponds to a subtask and each edge (i, j) e E represents a data or precedence dependency.

[0015] Subtask. Minimum execution unit that can be scheduled by the orchestration module. Each subtask i can be associated with an attribute vector uj that includes, but is not limited to: estimated complexity, qubit requirements q_i, estimated circuit depth dj, number of shots s_i, tolerance E_i and / or time T_i.

[0016] Backends / execution resources. Set of available resources B = {HPC} or {QPU_1, ..., QPU_N}. HPC denotes classical infrastructure (CPU / GPU) and QPU denotes a locally or remotely accessible quantum processor.

[0017] Telemetry. Set of observed metrics of the system state. For a backend B, raw telemetry is denoted as r_{i, b}. In preferred embodiments, QPU telemetry comprises at least one of: estimated fidelity F_b, gate error rate, and A gate_b, read error rate e A ro_b, decoherence parameters T1_b and T2_b, calibration status or age At A cal_b, queue Q A qpu_b and communication latency L A net_b. HPC telemetry comprises at least one of: saturation U A HPC, Q-tail A hpc, CPU / GPU availability and estimated execution time t A run_{i,HPC}.

[0018] Normalization of telemetry (canonical vector). Transformation of heterogeneous telemetry to a comparable vector x_{¡, b} ∈ R AD by means of a function x_{i,b} = cp_b(r_{i,b}). In preferred embodiments, <p_b incluye escalado, recorte a rangos y manejo conservador de faltantes, de modo que distintas tecnologías de QPU y diferentes entornos HPC se evalúan bajo un formato común.

[0019] Decision logic / orchestration. Computable function f that, based on (uj, x_{¡ , b}) , determines an assignment (b*, a*) for subtask i, where b* ∈ B and a* ∈ A is a mitigation plan. The logic f may implement heuristic rules and / or a machine learning model, but includes a backup deterministic behavior as described.

[0020] Mitigation plan. Element ae A that defines error mitigation actions for a quantum execution, including, but not limited to: statistical repetition, zero-noise extrapolation, result filtering, probabilistic cancellation, or other techniques. Mitigation escalation is understood as the increase in level a — > a' in the event of rejection due to verification, subject to budget.

[0021] Technical budget. Operational constraints B_max applicable to a subtask or workflow, such as maximum time T_max, maximum shots S_max, maximum cost $_max and / or depth limits d_max. A hard constraint is one whose violation forces a recovery action (e.g., backend change or fallback).

[0022] Acceptance Gate. A post-mitigation verification criterion that classifies a result y_i as ACCEPTED or REJECTED. In one embodiment, the criterion is based on a fidelity or error threshold (e.g., accept if F > F_min or if e < e_max); in another embodiment, it is based on statistical consistency (confidence intervals, variance, or others).

[0023] Deterministic recovery policy. A set of TT rules that, in the event of a rejected result, executes at least one of the following actions: retry, mitigation escalation, quantum backend switch, postponement, or fallback to HPC.

[0024] Decision record (auditable record). A structured record R_¡ associated with each decision / execution, comprising at least: subtask identifier, timestamp, relevant normalized metrics, selected backend, mitigation plan applied, Acceptance Gate result, recovery action (if applicable), and reason or cause code. This record supports auditing, reproducibility, and experimental validation.

[0025] Validation metrics (examples). To evaluate the technical effect, aggregate metrics are defined such as: quantum acceptance rate QAR = N_acc / N_Q, quantum failure rate with fallback QFR = N_fail / N_Q, retry rate RR, and total workflow completion time (JCT). These metrics are preferably compared under conditions “with” and “without” the described control mechanism.

[0026] 4. Brief description of the figures

[0027] Figure 1. Component diagram illustrating the functional architecture of a hybrid HPC / QPU computing system configured to execute the verifiable control mechanism described in the claims.The figure shows (i) an III / API module for ingesting a problem or workflow; (ii) a control plane comprising an orchestration module with workflow decomposition into a subtask graph, collection of HPC and QPU telemetry, multi-backend normalization to a canonical vector, a decision engine under hard budget constraints, a mitigation manager with escalation, an Acceptance Gate for post-mitigation verification, and a deterministic recovery policy that contemplates retries, backend switchover and / or fallback; (iii) execution resources including an HPC cluster and one or more QPUs connected via an interface or SDK; and (iv) a knowledge base for persisting metrics and traceability via an auditable decision record, with optional feedback for adjusting thresholds or models.The figure also includes an optional experimental validation module to incorporate empirical results into the repository, allowing reproducibility and iterative improvement of the control.

[0028] Figure 2. Flowchart illustrating the operation of the hybrid HPC / QPU control procedure. The figure shows the workflow reception and its decomposition into subtasks; the collection of telemetry from the HPC infrastructure and one or more QPUs; the normalization of multi-backend telemetry to a canonical vector; the evaluation of candidate plans under a decision function and strict budget constraints; the selection of the backend (HPC or QPU) and initial mitigation level; quantum execution with error mitigation and verification via an Acceptance Gate; and, in case of rejection, the deterministic recovery policy, which includes retries, switching to the quantum backend, and / or fallback to HPC. The figure also shows the auditable decision record of metrics, decisions, applied mitigation, and recovery actions, as well as the generation of a workflow performance report.

[0029] Figure 3. Flowchart detailing the subtask control loop executed by the orchestration module for hybrid HPC / QPU computing. The figure shows the selection of a ready subtask, the collection of telemetry from HPC (queue, saturation, estimated times) and from one or more QPUs (noise / fidelity, error rates, latency, queue, and calibration status), and the multi-backend normalization of these metrics to a canonical decision vector. The generation and evaluation of candidate plans (backend and mitigation level) using time (JCT), cost, and probability of success estimates, and the application of hard budget constraints (e.g., maximum time, maximum shots, maximum cost, and / or maximum depth) are then illustrated.If a feasible quantum plan exists, the figure shows execution on the selected QPU, application of error mitigation, and evaluation via an Acceptance Gate. Upon rejection, a deterministic recovery cycle is executed, comprising mitigation escalation and / or switching to an alternative QPU, subject to budget. If the result still fails to meet the acceptance criteria or the budget is exhausted, the figure shows quantum failure marking and fallback to HPC to complete the subtask.

[0030] Finally, the storage of an auditable record (decision record) is represented, which includes the telemetry used, the decision (HPC / QPU), the mitigation applied, the gate result, the recovery action (retry / switch / fallback), the budget consumptions and the associated reason, for traceability and feedback of the system.

[0031] Figure 4. State diagram representing the finite state machine (FSM) of the controller implementing the hybrid HPC / QPU control mechanism. The figure shows the workflow initialization, its decomposition into subtasks, and, for each selected subtask, the execution of a control loop comprising the states of observing HPC and QPU telemetry, multi-backend normalization to a canonical vector, generation of candidate plans, and evaluation under a decision function with hard budget constraints. Depending on feasibility, the controller transitions to allocation and execution states in either QPU or HPC. For QPU executions, the figure shows the application of error mitigation and verification via Acceptance Gate; upon rejection, a deterministic recovery sub-automaton is activated, which includes retry, mitigation escalation, and / or switching to an alternative QPU, subject to budget.When the acceptance criteria are not met or resources are exhausted, the FSM transitions to a quantum failure state and executes a fallback to HPC. Finally, the figure includes the auditable decision record for storing telemetry, decisions, gate results, recovery actions, and budget consumption, as well as workflow status updates up to final assembly and metrics reporting.

[0032] Figure 5. Block diagram and data flow illustrating the data model and decision function under constraints executed by the orchestration module to select, for each subtask, the execution backend and mitigation level. The figure shows as inputs the attributes of a subtask uj (e.g., qubit requirements, depth, shots, and tolerances) and the telemetry of the HPC infrastructure and one or more QPUs (e.g., queue, saturation, estimated times; and noise / fidelity, error rates, latency, queue, and calibration status). These metrics are transformed by a normalization function cp_b() into a canonical vector x_{i, b} comparable across backends. From the canonical vector and the subtask attributes, candidate plans (b, a) are generated that combine a backend b (HPC or a specific QPU) and a mitigation plan a. For each plan, estimators of time T(i,b,a), cost C(i,b,a) and probability of success p_succ(i,b,a) are calculated.The figure represents the application of hard budget constraints (e.g., T <T_max, S<S_max, C<C_max, d<d_max) y la evaluación de una función de puntuación J(¡ ,b,a) para seleccionar el plan óptimo (b*,a*) sujeto a dichas restricciones. Finalmente, la figura muestra la emisión de la decisión de ejecución (HPC o QPU) y la generación de un Decision Record R_¡ que conserva, con fines de trazabilidad y auditoría, la telemetría normalizada, la selección (b*,a*), el cumplimiento de restricciones y los parámetros relevantes, almacenándose en una base de conocimiento para.

[0033] optional feedback of thresholds or policies.

[0034] Figure 6. Sequence diagram illustrating the message exchanges and coordination between system components during the execution of the hybrid HPC / QPU workflow. The figure shows how a user or client sends a workflow through a UI / API, and how the orchestrator decomposes the workflow into subtasks. For each subtask, the orchestrator requests telemetry from the HPC cluster (e.g., queue, saturation, and estimated times) and from the quantum backend using a quantum SDK / API (e.g., noise / fidelity metrics, latency, queue, and calibration status). Based on this telemetry, the orchestrator normalizes the metrics to a canonical vector, generates candidate plans (backend and mitigation level), and applies hard budget constraints to select a plan (b*, a*).If a feasible quantum plan exists, the figure shows the sending of the circuit and execution parameters to the QPU provider, the reception of the result and observed metrics, the application of error mitigation, and the evaluation via an Acceptance Gate. Upon rejection, a deterministic recovery cycle is depicted, comprising retries, mitigation escalation, and / or switching to an alternative QPU, subject to budget. If the result remains rejected or the budget is exhausted, a fallback to HPC is triggered to complete the subtask. Finally, the figure shows the writing of a Decision Record to a knowledge base, including the telemetry used, selection (b*, a*), gate result, recovery actions, and budget consumption, and the return of aggregated results and metrics (e.g., acceptance rate, failure rate, and JCT) via the UI / API.

[0035] 5. Detailed description of the achievements

[0036] The following are non-limiting embodiments of the invention, sufficient for a person skilled in the art to implement it. These embodiments are presented in terms of a closed-loop, hybrid HPC-QPU orchestration controller that normalizes multi-backend telemetry, decides subtask allocation under budget constraints, applies tiered mitigation, verifies results using an Acceptance Gate, executes deterministic recovery policies (retry / switch-off / fallback), and records an auditable decision record. References to figures are illustrative and not limiting.

[0037] 5.1 General architecture of the hybrid system

[0038] In a preferred embodiment, the hybrid system comprises: (i) a high-performance computing (HPC) infrastructure with CPU / GPU clusters, a queue manager, and distributed storage capabilities; (ii) one or more quantum processors (QPUs) accessible locally or remotely; (iii) an intelligent orchestration module (MOI) acting as a control plane; (iv) a communication and integration layer with APIs / SDKs; and (v) a repository / knowledge base for results and metadata. The MOI can be deployed as a cloud service, as an on-premises microservice, or partially on reconfigurable hardware (FPGA) to reduce decision latency.

[0039] The MOI integrates, in a coordinated manner, (a) a subtask scheduler, (b) an error and retry manager, (c) an application-level mitigation / correction module, (d) an Acceptance Gate, and (e) a decision recorder. In implementations with multiple QPLIs, the MOI maintains a catalog of backends and their states and can switch between QPLIs to preserve workflow continuity.

[0040] 5.2 Workflow model and decomposition into subtasks

[0041] The objective problem is represented as a workflow composed of subtasks with dependencies. In one implementation, the workflow is modeled as a directed graph G = (V, E), where V is the set of subtasks and E is the set of precedence or data dependencies. Each subtask, i.e., V, includes technical attributes uj, which may include: qubit requirements, estimated circuit depth, number of shots, tolerances, input / output data size, deadlines, and priority.

[0042] Notation example: G = (V, E), ie \ / u = (q¡, d¡, s¡, s¡, T¡, ...)

[0043] In one embodiment, the MOI assigns subtasks of high-throughput screening, large-scale simulations, or model training to HPC, and assigns refinement subtasks with high electronic correlation or combinatorics to QPU. The assignment can be re-evaluated in discrete cycles (ticks) to accommodate variations in noise, tailing, or latency.

[0044] 5.3 Multi-Backend Telemetry and Normalization (Canonical Vector) The MOI collects heterogeneous telemetry from HPC and QPll(s). In preferred implementations, QPU telemetry includes quality and operational metrics such as estimated fidelity, gate and read error rates, decoherence parameters (T1 / T2), calibration age, queue, and remote access latency. HPC telemetry includes cluster saturation, queue times, CPU / GPU availability, and estimated execution times.

[0045] To enable comparable decisions between backends, the MOI transforms the raw telemetry r_{¡ , b} into a canonical vector x_{¡ , b} using a normalization function <p_b que incluye escalado a rangos, recorte (clipping), imputación conservadora de faltantes y / o penalization por incertidumbre.

[0046] Canonical normalization: x! tb = cpuífi, b ), be ®

[0047] In one realization, ® = {HPC} or {QPU_1, ..., QPU_N}. The function <p_b puede definirse para cada tipo de QPU (superconductores, iones atrapados, fotónica) y para entornos HPC distintos, preservando un formato común para la lógica de decisión.

[0048] 5.4 Decision and allocation logic under budget constraints

[0049] The MOI determines, for each subtask i, a backend b* and, when b* corresponds to a QPU, a mitigation plan a* from an ordered set of mitigation levels. The decision is made based on (i) the attributes u_i, (ii) the normalized vectors x_{i, b}, and (iii) hard budget constraints. In a preferred embodiment, the MOI evaluates a utility function or score S(i, b, a) that approximates the expected benefit of running subtask i on backend b with mitigation plan a, subject to constraints. The function can incorporate objectives such as total time (JCT), probability of success / acceptance, monetary cost, and resource consumption. The selection is made by maximizing utility or minimizing a loss function.

[0050] Non-limiting example of decision: (b*, a*) = argmax_{be®, ae2I} S(i,b,a) sa C(i,b,a) < Bmax

[0051] In the above expression, C(i,b,a) represents a cost or consumption associated with time, shots, circuit depth, energy, or monetary cost; and B_max represents a maximum budget applicable to the subtask or workflow. In preferred embodiments, the budget is expressed as a vector of hard constraints, for example: maximum time T_max, maximum shots S_max, maximum cost $_max, and maximum depth d_max.

[0052] Budget constraints (example): t¡, b , a < T max Yes, b , a < S max ; d¡ < d max

[0053] Decision logic can be implemented using heuristic rules, a machine learning model, or a combination of both. In implementations using a machine learning model, the MOI employs a confidence threshold and a deterministic failsafe: if the model's confidence falls below a threshold, a conservative deterministic rule prevails (e.g., assign to HPC or apply minimum mitigation).

[0054] 5.5 Automatic Mitigation and Under-Budget Escalation When a subtask is assigned to the QPU, the MOI selects a mitigation plan ae 21 and runs the quantum circuit with that plan. If verification indicates that the quality does not meet the criterion, the MOI can escalate to a higher mitigation level, provided there is remaining budget. In one implementation, the mitigation levels are ordered by increasing cost: a0 (no mitigation), a1 (statistical repetition), a2 (zero-noise extrapolation), a3 (combination or advanced techniques).

[0055] Level Mitigation Action Relative Cost / Consumption (examples)

[0056] aO Without mitigation; minimum execution

[0057] base

[0058] a1 Statistical Repetition and Low

[0059] filtered

[0060] a2 Extrapolation to zero noise; Medium

[0061] depth adjustment

[0062] a3 Combination; High Cancellation

[0063] probabilistic or other

[0064] The escalation can operate as a state machine that, after every k attempts, checks for quality and, if the criterion is not met, decides between: (i) escalate mitigation, (ii) retry at the same level, (iii) switch from QPU, or (iv) trigger fallback to HPC. In preferred implementations, a maximum number of retries per subtask is limited.

[0065] 5.6 Acceptance Gate and execution classification

[0066] The invention incorporates a post-mitigation acceptance gate that verifies the suitability of the quantum result before integrating it into the workflow. The acceptance gate evaluates a quality metric, such as estimated fidelity F, error e = 1 - F, or statistical consistency of measurements, and classifies the run as ACCEPTED or REJECTED. Threshold criterion (example): ACCEPT if F > F min ', REJECT otherwise. In a statistical alternative, a confidence interval (CI) is calculated over a quantity of interest and accepted when the lower limit of the CI satisfies the tolerance. The acceptance gate is applied to the already mitigated result (if there was mitigation) and is executed before propagating the data to subsequent stages.

[0067] Statistical criterion (example): ACCEPT if LCI(6) > 6 min

[0068] The MOI records the result of the acceptance gate and classifies the execution into operational states such as: ACCEPT_QPU (accepted into QPU), RETRY_MITIGATE (required mitigation / retry), and Q_FAIL_FALLBACK (quantum failure with fallback).

[0069] 5.7 Deterministic Recovery Policy (retry / switch / fallback) When the acceptance gateway rejects a result, the MOI executes a deterministic recovery policy. This policy may include: (i) retrying with the same parameters, (ii) escalating mitigation, (iii) switching to an alternate QPU, (iv) postponing the subtask until the calibration status improves, or (v) triggering a fallback to run the subtask in HPC. The selection is made within a budget and with maximum retry limits.

[0070] In a preferred implementation, the recovery policy uses threshold rules to simplify operation: when the error or noise falls within a moderate range, mitigation is attempted; and when it exceeds a threshold, the execution is marked as failed and fallback to HPC is triggered. The numeric values ​​are preferred implementations and do not limit the scope.

[0071] Illustrative threshold rule (preferred implementation): if ee [0.03, 0.05] => apply mitigation; if e > 0.05 => fallback to HPC.

[0072] In implementations with multiple QPUs, switching can prioritize a backend with a shorter queue or better fidelity. In implementations with variable latency, the MOI can estimate the total time t_total = t_queue + t_execution + t_network and favor HPC when the total QPU time does not meet deadlines.

[0073] Total remote execution time (example): t to tai = t coia + t eJec + t red

[0074] 5.8 Auditable decision record and feedback

[0075] The MOI generates a decision record per subtask and per execution attempt to enable auditing, reproducibility, and iterative improvement. In a preferred implementation, the decision record includes: subtask identifier, timestamp, selected backend, relevant telemetry (raw and / or normalized), mitigation plan applied, Acceptance Gate result, recovery action executed, and a coded reason (e.g., 'high noise', 'budget exhausted', 'excessive queue').

[0076] Field Description Type Example taskjd String identifier !=2048

[0077] subtask

[0078] backend Backend enum QPU_2 / HPC selected

[0079] telemetry Vector canonical vector F=0.962; L=120ms x_{i,b} and / or r_{¡,b}

[0080] mitigation Level a applied enum a2 (ZNE) gate Result enum ACCEPT Acceptance Gate

[0081] recovery Action of enum fallback recovery

[0082] Budget and structure S=1500 / 2000

[0083] consumption

[0084] Reason: Decision record code ERR_GT_THRESH. Feedback uses decision records to adjust scheduler parameters, such as acceptance thresholds, latency penalties, retry limits, or utility function weights. In implementations with a learning model, the records are used as a training or calibration dataset, always maintaining a deterministic failsafe.

[0085] 5.9 Additional implementation achievements (not limited to)

[0086] 5.9.1 Implementation with machine learning. In one embodiment, the MOI incorporates a model that estimates the probability of acceptance of the quantum result p_acc(i,b,a) and / or the expected time, based on x_{i,b} and uj. The decision may favor the backend with the highest expected utility. To ensure safe operation, a confidence threshold for the model is defined; below this threshold, a deterministic conservative rule is applied.

[0087] Example of expected utility (not limiting): S(¡, b,a) = p acc(i,b,a) ■ V¡ - A ■ C(i,b,a) 5.9.2 Partial Implementation on an FPGA. In one embodiment, the MOI is implemented wholly or partially on an FPGA as a control plane to reduce latency for rule evaluation, normalization, and recovery triggering. In preferred embodiments, the FPGA executes the control loop state machine and issues commands to (i) QPU APIs, (ii) the HPC queue manager, and (iii) the register repository. Partial reprogramming is contemplated to update heuristics or parameters without stopping the system.

[0088] 5.9.3 Multi-QPU Compatibility and Open APIs. In one implementation, the MOI communicates with QPUs of different qubit technologies using SDKs or open APIs and remote services. The integration layer translates the execution plan into the formats required by each vendor and maintains technological independence (avoiding vendor lock-in).

[0089] 5.9.4 Security and access control. In one embodiment, communication between MOI, HPC, and QPU is protected by authentication and channel encryption. Decision records and results are stored with access controls and versioning to support auditing and compliance.

[0090] 5.10 Validation and comparison metrics (test realizations)

[0091] To validate the controller's technical effect, comparable aggregate metrics across runs are recommended. In preferred implementations, the following are computed: quantum acceptance rate (QAR), quantum failure rate with fallback (QFR), retry rate (RR), and total workflow completion time (JCT). These metrics are compared under 'with' and 'without' closed-loop control conditions.

[0092] Definitions (example): QAR = N acc / N Q -, QFR = N fa ii / N Q -, JCT = max j tj

[0093] In one embodiment, the system generates periodic reports summarizing the above metrics, the distribution of HPC / QPU decisions, the effectiveness of each mitigation level, and the fallback frequency, facilitating threshold calibration and resource sizing. 6. Examples of embodiment (non-limiting) The examples of embodiment described below are provided for illustrative purposes only and do not limit the scope of the claims. In each example, an orchestration module configured to execute a control procedure dynamically distributes subtasks between high-performance classical (HPC) infrastructure and one or more quantum processors (QPUs), measuring telemetry (noise / fidelity, latency, queues, cost, and budget) and applying, where appropriate, error mitigation, retries, and a fallback recovery policy.

[0094] 6.1 Example 1: Discovery of new generation antibiotics (HPC + VQE)

[0095] Problem context.

[0096] A library of candidate compounds is available (e.g., 10 A 6 to 10 A 8 molecules) and a bacterial target (enzyme or protein complex). The goal is to prioritize a small subset of candidates with a high probability of success for experimental validation, reducing R&D cost and time.

[0097] Phase A - Mass screening in HPC.

[0098] 1. a) In HPC, a classic filtering pipeline is executed that includes docking, QSAR and / or ML models to estimate affinity and ADMET properties.

[0099] 2. b) A top-K set is selected (e.g., K = 10 A 3 to 10 A 4) and chemical representations and inputs for refined electronic calculation are constructed (geometries, charge states, fragmentation).

[0100] 3. c) For each candidate, a quantum subtask is generated that estimates a target quantity associated with bond energy or electronic correlation, using a variational algorithm (VQE) and a depth-limited ansatz compatible with NISQ.

[0101] Phase B - HPC / QPU decision and budgets.

[0102] 4. d) The orchestrator calculates a canonical telemetry vector m = [r, L, q, c, s], where r represents noise (or 1 - fidelity), L expected latency, q QPU queue time, c estimated cost and s remaining budget (shots / time / cost).

[0103] m = [r, L, q, c, s]

[0104] 5. e) An objective function is evaluated under constraints, for example: minimize J = w_T T + w_C C + w_F (1 - p_succ) subject to C < C_max, S < S_max, L < L_max, where p_succ is the estimated probability of exceeding the Acceptance Gate.

[0105] J = w_T T + w_C C + w_F (1 - p_succ)

[0106] 6. f) If (r < r_max) and (L and q are below thresholds) are met, the subtask is sent to the QPU. Otherwise, a higher-fidelity classical method (e.g., approximate DFT / CC) is executed in HPC or the subtask is postponed.

[0107] Phase C - Mitigation, Acceptance Gate and recovery policy.

[0108] 7. g) After receiving the quantum result, the orchestrator applies mitigation if the noise level is moderate (e.g., statistical repetition or noise extrapolation).

[0109] 8. h) Acceptance Gate: the quantum result is accepted if the estimated uncertainty is < E_E and the confidence level is > 1 - a (e.g., using over-measurement confidence intervals). In case of rejection, a retry is activated with adjusted parameters (e.g., increased shots, reduced depth) up to a maximum of N_retry.

[0110] 9. i) If, after mitigation and retries, an error above the threshold persists, the orchestrator marks the execution as “quantum failed” and activates fallback to HPC, preserving pipeline continuity.

[0111] 10. j) An auditable Decision Record is registered with: telemetry, circuit version, mitigation applied, gate criteria, and final route (QPU / HPC).

[0112] Exit.

[0113] The system produces a final ranking of candidates and complete traceability. In preferred implementations, the acceptable execution rate is measured as R_acc = N_acc / N_total, where N_acc is the number of executions that pass the Acceptance Gate.

[0114] R_acc = N_acc / N_total

[0115] 6.2 Example 2: Optimization of catalysts in MOF materials (HPC + VQE / QAOA)

[0116] Problem context. In a set of MOF structures and adsorbates, the goal is to maximize a catalytic performance metric (e.g., minimum activation energy, selectivity, or target adsorption energy) under stability and synthesis constraints. Phase A - High-performance computing (HPC) simulation.

[0117] 11. a) The HPC performs molecular dynamics (MD) and / or approximate calculations to explore conformations, thermal stability and diffusion, generating a set of representative configurations.

[0118] 12. b) A preprocessing module reduces the problem (selection of fragments, active orbitals, or effective models) for quantum computation.

[0119] Phase B - Critical quantum subroutine.

[0120] 13. c) For critical configurations, a reduced Hamiltonian is defined and VQE is run to estimate highly correlated electronic energies; alternatively, QAOA is used to solve a combinatorial active site selection subproblem.

[0121] 14. d) The orchestrator selects backend / QPU and circuit parameterization according to noise and budget metrics, applying mitigation where appropriate.

[0122] Phase C - Feedback and decision.

[0123] 15. e) The quantum results (energies, effective states) are reintegrated into the HPC to recalibrate potentials or ML models and generate a new exploration iteration.

[0124] 16. f) Acceptance Gate: the quantum result is accepted if it improves the uncertainty of the classical model above a threshold AJmp and meets stability constraints.

[0125] 6.3 Example 3: Design of solid-state lithium batteries (HPC + quantum refinement)

[0126] Problem context. Compositions and microstructures of solid electrolytes and interface materials are optimized to maximize ionic conductivity and electrochemical stability, minimizing migration barriers and parasitic reactions.

[0127] Phase A - Exploration in HPC.17. a) The HPC performs massive screening of compositions (e.g., dopant substitutions), and simulations to estimate stability and ion transport (classical models or approximate DFT).

[0128] 18. b) “Bottlenecks” are detected where electronic correlation or the accuracy of activation barriers dominates the model error.

[0129] Phase B - Quantum subroutine for critical properties.

[0130] 19. c) Subtasks are sent to the QPU to estimate relative energies and / or activation barriers with a reduced electronic model (e.g., active) using VQE, using shallow circuits.

[0131] 20. d) The orchestrator adjusts shots and mitigation according to the observed noise; if the fidelity falls below the gate, it activates retry or fallback to HPC.

[0132] Phase C - Integration and final selection.

[0133] 21. e) Quantum results feed a surrogate model (ML) and a multi-objective optimizer in HPC that proposes new compositions.

[0134] 22. f) The output is a reduced set of candidate formulations with traceability of why they were chosen (Decision Record).

[0135] 6.4 Example 4: Optimization and Logistics (HPC + QAOA / Grover with feasibility gate)

[0136] Problem context. A routing, resource allocation, or scheduling problem (e.g., VRP or job-shop) is being solved, with hard constraints (capacity, time windows) and an objective of minimizing total cost or time.

[0137] Phase A - Decomposition and heuristics in HPC.

[0138] 23. a) The HPC executes heuristics / global search (e.g., metaheuristics) and / or MIP formulations to obtain feasible solutions and bounds.

[0139] 24. b) The orchestrator identifies high combinatoriality subinstances (e.g., subgraphs) that are candidates for quantum acceleration.

[0140] Phase B - Quantum subroutine.

[0141] 25. c) The subproblem is formulated in a Hamiltonian / cost (Ising / QUBO) and QAOA or Grover is executed, with limited depth.

[0142] 26. d) Feasibility Acceptance Gate: the quantum solution is accepted if (i) it satisfies all hard constraints verified in HPC and (ii) it improves the best known solution by at least A_obj.

[0143] 27. e) If the gate fails or the noise exceeds the threshold, the orchestrator activates a retry or returns control to HPC with an update of search parameters.

[0144] 6.5 Example 5: Quantum Machine Learning in Image Classification (demonstrative)

[0145] Problem context. A classifier is being trained on a set of labeled images. The hybrid flow is used demonstratively to validate the control mechanism (telemetry, gate, and fallback), rather than to maximize absolute accuracy in a NISQ environment.

[0146] Phase A - Preprocessing and training in HPC.28. a) HPC normalizes data, extracts features (e.g., embeddings) and trains a classical base model.

[0147] 29. b) A “lightweight” parameterizable quantum circuit is defined to act as a feature layer or quantum kernel on a subset of samples.

[0148] Phase B - Quantum execution and gate.

[0149] 30. c) The orchestrator sends batches to the QPU when telemetry indicates acceptable noise and latency, and applies mitigation when appropriate.

[0150] 31. d) Acceptance Gate: the quantum batch is accepted if the improvement of a metric (e.g., loss or accuracy) exceeds a threshold and the variance of measurements remains below o_max.

[0151] 32. e) If the gate fails, fallback to classical training is activated, maintaining pipeline coherence.

[0152] 6.6 Example 6: Zybo A7-20 FPGA control prototype (control plane)

[0153] In a small-scale validation implementation, the control mechanism is implemented on a Zybo A7-20 FPGA (or Z7-20 with Zynq-7000), with a Scheduler Core that decides whether to send subtasks to a remote QPU (or simulator) or solve them in HPC (external or simulated).

[0154] Architecture and communications.

[0155] 33. a) The Scheduler Core is implemented in programmable logic (HDL or HLS), managing task tables and FIFO queues in internal memory (BRAM).

[0156] 34. b) Communication with an HPC host and with the quantum API is done via Ethernet (e.g., IwlP on ARM CPU) or UART, exchanging REST / gRPC packets or other equivalent protocols.

[0157] Decision and mitigation thresholds.

[0158] 35. c) At each 'tick' of the Scheduler, QPU noise / quota and latency parameters are checked; if the noise is below a threshold (e.g., < 5%) and the latency is acceptable, it is routed to the QPU; otherwise, it is run on HPC or postponed.

[0159] 36. d) The mitigation submodule compares the reported fidelity with a threshold (e.g., 95%). If the error exceeds 5%, retry or fallback to HPC is triggered; if the noise is moderate (e.g., 3-5%), statistical repetition or noise extrapolation is applied.

[0160] 37. e) The system records by subtask: times, fidelity, latency and decision taken, adjusting heuristics in successive iterations.

[0161] 6.7 Example 7: Cloud implementation with Amazon EC2 F1 FPGA and QPU as a service

[0162] In a scalable implementation, the control mechanism is deployed on an FPGA in the cloud (e.g., Xilinx Virtex UltraScale+ on Amazon EC2 F1 instances), acting as a low-latency Quantum-Classical Orchestrator (QCO), connected via PCIe to a host CPU and cloud HPC and QPU services.

[0163] Reference architecture.

[0164] 38. a) The QCO on the FPGA maintains high-speed buffers (local DDR), scheduling and mitigation logic (FSM or ML blocks) and interfaces with the HPC environment (e.g., managed cluster and S3 storage) and with the quantum backend (e.g., AWS Braket).

[0165] 39. b) The HPC launches massive batches and sends candidate subtasks for quantum execution to the QCO; the QCO consults noise, queue and calibration of the QPU and decides to send, postpone or fallback.

[0166] 40. c) By operating in the same cloud region, control cycle latency is reduced; the system maintains an auditable record and applies continuous threshold improvement.

[0167] 6.8 Conclusion of the examples

[0168] The preceding examples illustrate implementations where the inventive core is a verifiable technical control procedure: multi-backend telemetry normalization, objective function under budget constraints, automatic mitigation and escalation selection, statistical Acceptance Gate, and deterministic recovery policy with Decision Record. The invention can be implemented in software, reconfigurable hardware (FPGA), and / or hybrid infrastructures, maintaining independence from the QPU vendor and the HPC queue manager.

[0169] 7. Industrial applicability

[0170] The invention is industrially applicable according to patentability criteria, as it provides a computer-implemented procedure and system for the repeatable, verifiable, and scalable execution of hybrid HPC-QPU workflows in production environments. Specifically, the invention enables operation with noisy or variable-availability quantum processors (QPUs) (NISQ environments), maintaining workflow continuity through a closed-loop control mechanism that normalizes multi-backend telemetry, decides subtask allocation under budget constraints, applies error mitigation, verifies results via an Acceptance Gate, and executes deterministic recovery policies (retry / switch / fa / / £>ac), also generating an auditable decision record for traceability.

[0171] The invention is applicable, without limitation, in the following sectors and use cases:

[0172] 1. Pharmaceutical and biotechnology industry (R&D and drug discovery). Execution of high-throughput screening pipelines in HPC (e.g., docking and machine learning models) with selective quantum refinement (e.g., energy estimation or optimization subproblems), ensuring that accepted quantum results meet quality criteria and that, in case of noise degradation, fallback to HPC is activated to avoid contamination of subsequent stages.

[0173] 2. Computational Chemistry and Materials Science.

[0174] Simulation of systems with high electronic correlation or refined evaluation of properties (relative energies, activation barriers, effective states), where the invention allows assigning critical subtasks to the QPU only when fidelity / noise thresholds and technical budget (time, shots, cost, depth) are satisfied, maintaining the reproducibility of the process.3. Combinatorial optimization and industrial logistics.

[0175] Solving sub-instances of planning problems (e.g., assignment, routing, scheduling) using quantum algorithms and / or classical heuristics, with feasibility and goal improvement Acceptance Gate, and with deterministic recovery if the quantum result does not meet the acceptance criterion.

[0176] 4. Machine learning and advanced analytics.

[0177] Training and evaluation of hybrid models (classical + quantum subroutines) in scenarios where the invention controls the incorporation of quantum results according to quality metrics, avoiding statistical degradation of the training and preserving experimental traceability.

[0178] The invention is deployable in on-premises, cloud, or hybrid environments and can be integrated with HPC queue managers and remote quantum platforms via standard interfaces. The orchestration module can run in software and / or reconfigurable hardware (FPGA) to reduce scheduling latency and allow controlled policy adjustments without interrupting operation, while maintaining the special inventive concept of closed-loop control.

[0179] In industrial applications, technical utility is measurable through objective indicators such as quantum acceptance rate, quantum failure rate with fallback, total workflow completion time (JCT), HPC / QPU resource utilization, and budget consumption (time / shots / cost). The systematic generation of decision records enables auditing, compliance, and reproducibility, allowing the invention to be used in regulated environments and continuous, high-volume operations.

Claims

Claims 1. A computer-implemented method for controlling, in a closed loop, the execution of a plurality of subtasks in a hybrid environment comprising at least one high-performance computing resource and at least one quantum processor, comprising, for a subtask i: (a) obtaining telemetry associated with a plurality of candidate backends b; (b) transforming, for each backend b, said telemetry into a canonical feature vector x_{i, b} by means of a normalization function phi_b(.) that produces comparable vectors between backends; (c) evaluating, for each backend b, a feasibility predicate subject to a plurality of hard constraints defined for subtask i; (d) calculating, for each feasible backend b, a target score J_{i, b} as a function of x_{i, b} and a stored decision policy; (e) selecting a backend b* as a function of J_{i, b} and the feasibility predicate;(f) when the backend b* corresponds to a quantum processor, select an error mitigation level from a plurality of configurable levels based on x_{i, b*}, the target score, and a budget allocated to subtask i; (g) execute subtask i on the backend b* applying the selected mitigation level where appropriate; (h) evaluate an execution result using an acceptance gate that determines whether the result meets a predefined quality condition; (i) when the acceptance gate rejects the result, execute a deterministic recovery policy that selects a recovery action from a finite set of actions;and (j) record a decision record associated with subtask i that includes at least the selected backend, the canonical vector used in the decision, the mitigation level applied where applicable, the result of the acceptance gate and the recovery action executed, producing as output an accepted result or an alternate result obtained by recovery.; 2. The method of claim 1, wherein the telemetry comprises, for each backend b, at least two of: availability, queue length, estimated latency, estimated cost, resource limits, recent failure rate, configuration version, or calibration age.

3. The method of claim 1, wherein the telemetry for a quantum backend comprises at least two of: gate error metrics, read error, coherence metrics, effective connectivity, maximum estimated depth, recommended number of taps, or estimated noise per circuit.

4. The method of claim 1, wherein the normalization function phi_b(.) includes at least one of: range scaling, standardization, categorical variable coding, or uncertainty penalty when telemetry is incomplete or exceeds an age threshold.

5. The method of claim 1, wherein the feasibility predicate includes simultaneously verifying at least two of: maximum time, maximum cost, maximum latency, maximum memory, maximum power, maximum circuit depth, or minimum fidelity.

6. The method of claim 1, wherein the target score J_{¡ , b} is calculated as a multi-criteria aggregation that weights at least two of: expected quality, cost, latency, and estimated probability of success.

7. The method of claim 1, comprising applying a deterministic tie-breaking rule when two or more feasible backends exhibit indistinguishable target scores within a predefined tolerance.

8. The method of claim 1, wherein the plurality of error mitigation levels includes a no-mitigation level and at least one of: read mitigation, zero-noise extrapolation, probabilistic error cancellation, or dynamic decoupling.

9. The method of claim 1, wherein selecting the mitigation level comprises estimating an incremental mitigation cost and selecting the level that satisfies the feasibility predicate and optimizes the target score under the allocated budget.

10. The method of claim 1, wherein executing the subtask on the quantum processor comprises compiling a circuit for a selected backend topology and adjusting at least one of: qubit allocation, insertion of mitigation operations, or number of executions.

11. The method of claim 1, wherein the acceptance gate accepts the result when a quality metric calculated for the result meets a predefined threshold.

12. The method of claim 1, wherein the acceptance gate calculates a statistic from repeated runs and accepts the result when a confidence interval or estimated lower bound satisfies an acceptance threshold.

13. The method of claim 1, wherein the acceptance gate comprises validating the result by at least one of: deterministic verification on the high-performance computing resource, comparison with a reference generated on the high-performance computing resource, or comparison with a surrogate model, and rejecting the result when a discrepancy exceeds a threshold.

14. The method of claim 1, wherein the deterministic recovery policy selects the recovery action from among: retrying on the same backend up to a maximum of N, switching to an alternate backend, escalating the mitigation level, simplifying or modifying execution parameters, postponing execution, or executing a backup path on the high-performance computing resource.

15. The method of claim 1, wherein the deterministic recovery policy is encoded as a finite state machine that defines states, transitions, and transition conditions based on at least one of: the outcome of the acceptance gate, budget consumption, or canonical telemetry.

16. The method of claim 1, wherein the decision record further includes at least two of: subtask identifier, timestamp, hard constraint values, target score value, coded reason for backend selection, or coded reason for recovery action.

17. The method of claim 1, comprising updating the budget allocated to subtask i after a rejected execution and restricting, in a subsequent execution of subtask i, the selection of backends or mitigation levels based on the updated budget.

18. The method of claim 1, comprising, for a plurality of linked subtasks, preventing the propagation of a rejected result to a dependent subtask by retaining or replacing said result until an accepted result or an alternative result is obtained by recovery.

19. The method of claim 1, wherein obtaining telemetry comprises querying a near real-time telemetry source and discarding, for selection purposes, telemetry that exceeds a certain age threshold.

20. The method of claim 1, wherein calculating the target score comprises applying a penalty when a telemetry metric has uncertainty greater than a predefined threshold.

21. The method of claim 1, wherein the selection of backend b* comprises selecting the high-performance computing resource when the feasibility predicate for the quantum backends fails or when the estimated probability of success for the quantum backends is below a threshold.

22. The method of claim 1, wherein executing the subtask comprises issuing the execution as a job with metadata that includes at least the subtask identifier and the selected mitigation level, and associating a job identifier with the decision record.

23. The method of claim 1, wherein the stored decision policy includes parameters configurable by subtask type, and the method selects applicable parameters based on a classification of subtask i.

24. The method of claim 1, comprising storing and reusing, for subsequent subtasks, at least one of: normalized telemetry, previous target scores, or acceptance gate results, to adjust backend selection or mitigation level.

25. A computer-implemented method for performing deterministic recovery of quantum outcomes in a hybrid environment, comprising: (a) executing a subtask on a quantum processor under a selected mitigation level; (b) evaluating the outcome by means of an accepting gate; (c) when the gate rejects the outcome, transitioning a recovery controller through a finite state machine that selects, in deterministically order, actions from among retry, backend change, mitigation escalation, and backup path in high-performance computing; (d) terminating the recovery when the gate accepts an outcome or when a terminal budget or retry condition is met; and (e) recording, at each transition, a decision record that includes the state, the selected action, and the gate outcome.

26. The method of claim 25, wherein the terminal budget condition comprises exceeding at least one of: maximum cost, maximum time, or maximum number of executions.

27. The method of claim 25, wherein the backend switch selects an alternate backend based on comparable normalized telemetry between backends.

28. The method of claim 25, wherein the mitigation escalation selects a higher mitigation level when the coded cause of the gate rejection corresponds to an error class associated with reading or stochastic noise.

29. A hybrid execution control system comprising: a memory that stores hard constraints per subtask, a decision policy, and a deterministic recovery policy; and one or more processors configured to: collect telemetry from a plurality of candidate backends; normalize the telemetry to produce comparable canonical vectors; evaluate feasibility under the hard constraints; compute target scores; select a backend for a subtask; when the selected backend is a quantum processor, select a mitigation level; execute the subtask; evaluate a result using an acceptance gate; execute the deterministic recovery policy when the result is rejected; and generate and store decision records associated with the subtask.

30. The system of claim 29, wherein the one or more processors comprise a decision engine logically separate from a recovery controller, and the recovery controller is configured to enforce retry limits and budget limits per subtask.

31. The system of claim 29, wherein the acceptance gate is configured to operate in a threshold mode and a statistical mode, the mode being selected according to the type of subtask or the available budget.

32. The system of claim 29, wherein the system is configured to block the propagation of results to dependent subtasks until the accepting gate accepts the result or an alternate result is produced by retrieval.

33. A non-transient, computer-readable medium that stores instructions that, when executed by one or more processors, cause the one or more processors to execute the method of any one of claims 1 to 24.

34. A non-transient, computer-readable medium that stores instructions that, when executed by one or more processors, cause the one or more processors to execute the method of any one of claims 25 to 28.

Images