QuaST Decision Tree Framework

• QuaST Decision Tree is a modular framework that automates decision support for hybrid quantum-classical combinatorial optimization by integrating encoding, algorithm selection, and hyperparameter tuning.
• The framework employs a directed acyclic graph of nodes configured via YAML to execute end-to-end workflows through dynamic query-driven decision processes.
• It features a feasibility module for variational quantum algorithms that benchmarks finite sampling errors against optimizer noise thresholds to assess scalability.

Searching arXiv for the specified paper and closely related QuaST Decision Tree work to ground the article in the literature. The QuaST Decision Tree (QDT) is a modular, configurable decision-support and orchestration framework for hybrid quantum-classical optimization workflows. It “provides a framework for decision support which recommends combinations of quantum and classical algorithms suited to a specific use case,” and extends the quantum software stack “to fully reach the end user at the application level by automating (quantum and classical) algorithm selection and the tasks necessary for it — problem encoding, hyperparameter tuning” (Poggel et al., 18 May 2026). In the 2026 formulation, the framework is centered on combinatorial optimization and couples end-to-end workflow orchestration with data-based recommendation modules, notably a module for judging the feasibility of variational algorithms through scalability analysis (Poggel et al., 18 May 2026). A 2024 precursor established the same application-facing orientation, modular node structure, and forward/backward execution model, framing QDT as a reusable path-construction layer between optimization applications and hybrid quantum solutions (Poggel et al., 2024).

1. Scope and problem setting

The QDT addresses a practical gap in the quantum software stack: the absence of an application-facing layer that can connect domain problems to appropriate combinations of preprocessing, encoding, classical solvers, quantum solvers, postprocessing, and backend selection. The motivating setting is hybrid quantum-classical combinatorial optimization, where the classical computer is required not only for preprocessing and postprocessing, but also for decomposition steps, and where many quantum algorithms themselves involve quantum-classical iteration (Poggel et al., 18 May 2026).

Within this setting, the QDT spans the full application-facing pipeline. It begins with problem modeling and instance loading through ProblemData, continues through formulation and encoding such as QUBO generation, selects among classical, quantum, or hybrid algorithms, configures hyperparameters, executes the chosen path, and then performs postprocessing and decoding on a backward pass. Automation enters at decision points through query-driven selection, builder wrappers that normalize heterogeneous interfaces, and specialized automation modules that return instance-specific recommendations together with executable configurations (Poggel et al., 18 May 2026).

The framework is therefore not limited to isolated solver recommendation. Its stated role is to cover the tasks that make algorithm selection operational: problem encoding, hyperparameter tuning, and integration with backend information and result interpretation. This suggests that the QDT is intended as application middleware rather than as a narrow solver picker.

2. Architectural model

Architecturally, the QDT is a directed acyclic graph whose vertices are Node instances and whose edges are parent-to-child relations set in configuration. Nodes “flexibly execute atomic computational tasks” and are composed into end-to-end workflows through child relations. The graph is configured through YAML, which supplies node names, children edges, and initialization parameters (Poggel et al., 18 May 2026).

Each node declares three structural properties: requires, listing ProblemData entries needed as inputs; creates/modifies, listing the ProblemData entries the node will produce; and children, listing possible successors. Runtime behavior is split into a forward and backward phase. On the forward pass, Node.execute(problem_data, path_info) performs the node’s local computation. On the backward pass, Node.interpret_result(result, problem_data) interprets downstream results in light of prior transformations. Specialized branching nodes implement next_node() to choose the correct child dynamically when multiple outgoing edges are available (Poggel et al., 18 May 2026).

The shared state passed through the graph is ProblemData, described as a shared, typed dictionary and centralized data structure. For branching, next_node() is invoked when a node has multiple children, and the choice is made from the current runtime state in ProblemData. This makes branching dependent on data and prior selections rather than purely on static tree structure (Poggel et al., 18 May 2026).

The orchestration layer is the DecisionTree class. It creates, validates, and runs the DAG. Its run(problem_instance, path) method performs a forward pass from the root to a final node—typically a submission or execution node—and then a backward pass that applies interpret_result from the final node back to the root. The paper summarizes this behavior in Algorithm 1: load configuration and root node, initialize ProblemData and an execution-path record, execute nodes until a final node is reached, execute the final node, and then traverse the stored path in reverse for result interpretation (Poggel et al., 18 May 2026).

Component	Role	Key interface
Node	Atomic computation unit	execute, interpret_result, next_node
ProblemData	Shared typed state	Passed along graph edges
DecisionTree	DAG orchestration	validate, run, load_backends
Query	Configurable choice mechanism	Manual or automatic mode
Builder	Interface normalization	Hyperparameter-driven instantiation

Two auxiliary abstractions are central to configurability. The Query class implements selectable automation: a global flag switches between manual mode, where the user is prompted but defaults or recommendations remain available, and automatic mode, where defaults or computed recommendations are chosen directly from ProblemData. Query subclasses include typed queries and multi-step QueryTree variants for dependent prompts. Separately, Builder wrappers expose a common interface for heterogeneous components such as optimizers or ansätze. Each builder advertises required HyperParam objects, allowing selection nodes to gather parameters through path files, queries, or automation and instantiate components without modifying the node that performs the selection (Poggel et al., 18 May 2026).

3. Decision process and automation semantics

The implemented decision process is organized around explicit node-level decision points. These include preprocessing and encoding, algorithm choice, hyperparameter tuning, backend selection and submission, and postprocessing or decoding. In preprocessing, a problem instance is read from JSON and formulated into a target representation such as a QUBO matrix, with formulation modes defined in the relevant ProblemClass. Algorithm choice then branches among classical solvers, direct quantum solvers, and variational algorithms, with common subpaths shared where appropriate. Hyperparameter tuning is handled through builders for optimizers such as COBYLA, SPSA, NGD, Powell, and NFT, and for ansatz or mixer configuration in QAOA variants or VQE (Poggel et al., 18 May 2026).

Path control is partly static and partly dynamic. Nodes can declare path keys so that a YAML path file forces particular values; otherwise a Query or an automation module supplies them. This gives a precise mechanism for expert override without removing automated behavior. The same node can therefore act in a fully automatic pipeline, an interactive exploratory workflow, or a partially fixed benchmark path (Poggel et al., 18 May 2026).

Backend integration is encapsulated in specialized BackendNode instances. The DecisionTree maintains a backend registry and exposes dynamic information through request_info(), including qubit count, connectivity, calibration, and queue length, so that later nodes can make backend-aware decisions. Backend nodes also encapsulate submission and result-retrieval logic, acting as adapters between QDT-level orchestration and lower-level execution interfaces (Poggel et al., 18 May 2026).

Automation is treated as a first-class design property rather than a later addition. Queries can run in automatic mode, builders standardize component instantiation, nodes declare their inputs and outputs explicitly, and the orchestration layer provides runtime backend information. The stated result is “automation without restriction”: recommendations can be computed automatically, but expert overrides remain possible at configuration and path levels (Poggel et al., 18 May 2026). This also clarifies a common misconception induced by the name: the QDT is not a static branching diagram with fixed choices; it is a configurable execution graph with runtime branching and reversible interpretation of results.

4. VQA feasibility module and robust scalability analysis

The most distinctive automation contribution in the 2026 paper is a module that judges the feasibility of variational quantum algorithms using a scalability database and explicit solvability criteria. Its inputs are a QUBO matrix $Q \in \mathbb{R}^{n \times n}$, characterized by size $n$ and density $\rho$, together with an optional problem class such as Knapsack with capacity ratio $r$ or MaxCut with density. If the problem class is absent, the general QUBO subset of the database is used (Poggel et al., 18 May 2026).

The module combines two benchmark-derived effects. The first is finite-sampling error, $\epsilon_{\mathrm{FS}}(n, n_{\mathrm{shots}})$, which scales as $1/\sqrt{n_{\mathrm{shots}}}$ for fixed system size and grows exponentially in $n$ at fixed shot count. The second is the optimizer noise resilience threshold, $\epsilon^*(n)$, defined as the maximum noise level under which the classical optimizer can still converge and fitted empirically from success rates normalized by the loss variance. Solvability is defined by the inequality

$$\epsilon_{\mathrm{FS}}(n, n_{\mathrm{shots}}) < \epsilon^*(n).$$

Inverting this relation yields a minimum shot requirement $n_{\mathrm{shots}}(n)$ for a given VQA, optimizer, and scaling hypothesis, with uncertainty bounds obtained from full error propagation (Poggel et al., 18 May 2026).

The module does not stop at solvability. It also applies a hard feasibility filter through the “quantum disadvantage boundary,” defined by comparison to brute-force enumeration:

$n$0

Here $n$1 depends on the optimizer. Any configuration whose total quantum cost exceeds or matches $n$2 evaluations is rejected as offering no benefit over exhaustive classical search (Poggel et al., 18 May 2026).

To manage model uncertainty, the recommendation engine uses the conservative rule “worst-case across valid scaling fits.” Scaling hypotheses for $n$3 include exponential, power-law, and logarithmic decay. Each VQA/optimizer pair is then classified as Feasible, Infeasible, or Not characterizable. “Feasible” means the worst-case valid estimate remains below the disadvantage boundary; “Infeasible” means valid estimates exist but all exceed the boundary; “Not characterizable” means no consistent scaling fit can be established because convergence at small $n$4 is inconsistent. Among feasible configurations, ranking minimizes $n$5 (Poggel et al., 18 May 2026).

The module writes two concrete artifacts. scalability_assessment.json contains structured input features, shot estimates with uncertainties under all scaling hypotheses, feasibility flags relative to the disadvantage boundary, and a recommended configuration. recommended_config.yaml contains a concrete QDT path specifying algorithm, optimizer, circuit depth, and backend. Hyperparameters are set to the benchmarking values used to build the database, so that the prediction regime and execution regime coincide (Poggel et al., 18 May 2026).

The database coverage reported in the paper includes VQE with hardware-efficient ansatz, QAOA, warm-start QAOA, ma-QAOA, QAOA+, and DC-QAOA; optimizers NGD, COBYLA, SPSA, Powell, and NFT; random QUBO densities $n$6; the same density values for MaxCut; and Knapsack capacity ratios $n$7. Fits are derived from $n$8 random instances per configuration for sizes $n$9 and extrapolated to $\rho$0 with propagated uncertainty (Poggel et al., 18 May 2026).

5. Interfaces, integration contexts, and reported evaluations

The QDT uses YAML for tree configuration and path definition, JSON for problem instances and results, and Python 3.11 as the implementation language. The package structure includes core classes such as DecisionTree, Node, ProblemData, Query, and backend integration, as well as modules for nodes, algorithms, problems, and utilities. Execution is exposed through DecisionTree.run(problem_instance, path), where the optional YAML path can force algorithmic choices and hyperparameters. Run-specific and persistent logs are created automatically (Poggel et al., 18 May 2026).

Several integration contexts are described. In an HPC quantum software stack such as the Munich Quantum Software Stack, the QDT can act as an upper layer provided that a backend provider node exists, the QDT configuration is fixed, and a server exposes a submission interface that accepts JSON problem instances and optional YAML paths. In that setting, the QDT performs encoding, submission, and result processing. For rapid prototyping, researchers can define configurations and path files to sweep encodings, algorithms, and hyperparameters, while new components are integrated through nodes and builders with low estimated code overhead. For industrial deployment, the QDT can serve as a reusable pre- and postprocessing accelerator within a commercial solver (Poggel et al., 18 May 2026).

The paper reports validation of HPC integration through submission of Linear-Ramp QAOA to the EuroQExa20 20-qubit backend via the Munich Quantum Portal. The central result is that local QDT overhead is negligible relative to hardware latency, even with empty queues (Poggel et al., 18 May 2026).

QUBO size	Forward pass	Wait time	Backward pass
4	< 1 s	11.8 ± 1.7 s	< 1 s
12	< 2 s	33.4 ± 1.7 s	< 1 s
20	< 2 s	39.4 ± 1.5 s	< 1 s

A second reported evaluation concerns the recommendation module on a 60-variable MaxCut instance with density $\rho$1. The module evaluated VQE, vanilla QAOA, warm-start QAOA, ma-QAOA, QAOA+, and DC-QAOA across optimizers NGD, Powell, NFT, COBYLA, and SPSA. Under the conservative worst-case-valid-fit rule, only VQE+NGD, with approximately $\rho$2 shots, and VQE+Powell, with approximately $\rho$3 shots, were classified as feasible. All assessed QAOA variants were classified either as infeasible—for example QAOA $\rho$4 with Powell at $\rho$5 shots—or as not characterizable because convergence was inconsistent at small $\rho$6. The resulting recommendation was VQE with NGD, and the generated recommended_config.yaml fixed the algorithm, optimizer, and hyperparameters to the values used in database creation (Poggel et al., 18 May 2026).

The paper also reports estimated integration effort for extending the framework in prototyping contexts: roughly 10 lines of code for a new encoding, 5 for an optimizer builder, 5 for an ansatz builder, 50 for quantum algorithm nodes, 50 for a backend node, 50 for an automation module, and 20 for a custom extraction pipeline (Poggel et al., 18 May 2026). These figures do not quantify scientific difficulty, but they do quantify the intended software-level granularity of extensions.

6. Demonstrated advantages, constraints, and projected development

The stated benefits of the QDT are operational rather than asymptotic. Automation reduces “expensive trial-and-error testing,” improves end-to-end performance, highlights where hybrid quantum solutions may provide benefit, and improves utilization of quantum devices by routing workflows toward feasible options or away from unpromising variational configurations (Poggel et al., 18 May 2026). The architecture is deliberately flexible and modular, supports “automation without restriction,” and allows expert overrides, additional modules, and third-party integration (Poggel et al., 18 May 2026). The HPC timings further show that orchestration overhead is sub-second to approximately two seconds, whereas backend wait times remain in the tens of seconds (Poggel et al., 18 May 2026).

The main practical constraint is the present scope of the scalability database. Benchmark fits are derived only for $\rho$7 and extrapolated up to $\rho$8, and the paper explicitly notes that these extrapolated estimates “naturally carry substantial uncertainty” (Poggel et al., 18 May 2026). Feasibility judgments also depend on optimizer call counts and fitted noise-tolerance thresholds, and some VQA families remain “not characterizable” because convergence is inconsistent even at small sizes (Poggel et al., 18 May 2026). These are limitations of current evidence coverage rather than merely of software engineering.

The roadmap is correspondingly empirical. The paper identifies broader validation “at increasing technology readiness,” expansion of the scaling database to more VQA variants, optimizers, and problem classes, and the addition of automation modules beyond VQA scalability (Poggel et al., 18 May 2026). A precursor had already emphasized modular extension and executable top-down paths from application to hybrid solution (Poggel et al., 2024); the 2026 paper turns that architectural claim into a concrete data-based recommendation mechanism. This suggests a development trajectory from orchestration framework to evidence-backed orchestration framework.

Regarding availability, the authors state that “The source code for the QuaST Decision Tree framework without the automation module described in Section 8 will be provided as open source software in summer 2026,” and they note that a no-code instance is available online for exploration (Poggel et al., 18 May 2026). This division between framework and automation module is itself informative: the orchestration layer is presented as reusable infrastructure, while the recommendation modules are treated as evidence-bearing components whose scope and coverage can expand independently.