Quantum-HPC Software Stacks and the openQSE Reference Architecture: A Survey
Pith reviewed 2026-05-10 01:09 UTC · model grok-4.3
The pith
A survey of nine quantum-HPC stacks identifies recurring patterns and proposes layer boundaries for interoperability and future-proofing.
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
Core claim
Analysis of nine production QHPC stacks reveals common design patterns and emerging requirements; these observations lead to the definition of the openQSE reference architecture, which specifies layer boundaries that permit different implementations to interoperate, preserve deployment flexibility, and support both NISQ workloads and future FTQC systems without changes to upper-layer application interfaces.
What carries the argument
The openQSE reference architecture, a set of layer boundaries that separate runtime abstraction, resource management, orchestration, and execution concerns to enable cross-implementation interoperability.
If this is right
- Different vendor implementations can interoperate at the defined runtime, resource, and orchestration layers.
- Upper-layer applications remain unchanged when stacks transition from noisy intermediate-scale to fault-tolerant quantum operation.
- Observability and interconnect requirements can be met through standardized interfaces at the identified boundaries.
- Deployment flexibility is retained because each layer can be realized by multiple concrete implementations.
Where Pith is reading between the lines
- Clear layer boundaries could encourage development of modular components that plug into multiple environments rather than requiring full-stack reinvention.
- The architecture might reduce vendor lock-in by letting users mix runtime or resource-management pieces from different sources.
- Validation against additional stacks beyond the original nine would test whether the identified patterns truly generalize.
- Standardized layers could ease integration of quantum resources into existing classical HPC schedulers and monitoring tools.
Load-bearing premise
The design patterns and requirements seen in the nine surveyed stacks are common enough and stable enough to define layer boundaries that will actually allow broad interoperability and will need no changes to applications when moving to fault-tolerant systems.
What would settle it
Two independent quantum-HPC stacks that each conform to the proposed layer boundaries and successfully exchange resources or execute a shared workload without modifying their upper-layer application code would support the claim; persistent inability to achieve such exchange after adaptation attempts would challenge it.
Figures
read the original abstract
Quantum resources are increasingly integrated into high-performance computing (HPC) and cloud environments, but quantum high-performance computing (QHPC) software stacks remain isolated, often proprietary, full-stack solutions lacking common interfaces across runtime, resource management, orchestration, and execution layers. This paper analyzes nine production QHPC stacks and identifies common design patterns and emerging requirements, covering deployment models, application interaction patterns, SDK support, and readiness for fault-tolerant operation. The survey exposes consistent needs in runtime abstraction, resource management, interconnect semantics, and observability. Based on these findings, we propose the open quantum-HPC software ecosystem ( openQSE) reference architecture as a first step toward unifying the state-of-the-practice. openQSE defines a set of layer boundaries that allow different implementations to interoperate while preserving deployment flexibility, and is structured to support both current noisy intermediate-scale quantum (NISQ) workloads and future fault-tolerant quantum computing (FTQC) systems without changes to upper-layer application interfaces.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper surveys nine production quantum-HPC (QHPC) software stacks, identifies recurring design patterns and requirements across deployment models, application interaction, SDK support, and fault-tolerance readiness, and proposes the openQSE reference architecture. openQSE defines layer boundaries (runtime abstraction, resource management, interconnect semantics, observability) intended to enable interoperability among implementations while preserving deployment flexibility and supporting both NISQ workloads and future FTQC systems without upper-layer application changes.
Significance. If the extracted patterns prove representative and the layer boundaries stable, the work would offer a practical starting point for unifying currently isolated QHPC stacks and easing the transition to fault-tolerant systems. The survey itself supplies a useful catalog of current practice; the architectural proposal, however, remains a hypothesis whose impact depends on subsequent validation.
major comments (2)
- [Proposal of openQSE (likely §4–5)] The central claim that the nine surveyed stacks suffice to define stable, interoperable layer boundaries rests on observed common needs but provides no explicit per-stack mapping to the proposed openQSE layers, no cross-vendor prototype exercising the interfaces, and no concrete analysis of how FTQC mechanisms (error correction, logical-qubit interfaces, syndrome extraction) would be hidden from upper layers. This gap directly undermines the assertion that the boundaries will require no upper-layer changes when moving from NISQ to FTQC.
- [Survey methodology and analysis sections] The representativeness assumption—that patterns from the nine stacks generalize to broad vendor interoperability—is load-bearing yet untested; the manuscript does not report selection criteria for the stacks, quantitative coverage metrics, or a falsifiable test (e.g., implementing a minimal cross-stack workflow) that would confirm the boundaries are both necessary and sufficient.
minor comments (2)
- Clarify whether the nine stacks are named and tabulated with their key characteristics; a summary table would strengthen the survey presentation.
- The abstract states that openQSE supports FTQC 'without changes to upper-layer application interfaces,' but the manuscript should explicitly list which interfaces are claimed to remain invariant and why.
Simulated Author's Rebuttal
We thank the referee for the constructive feedback, which highlights important areas for strengthening the presentation of our survey and the openQSE proposal. We respond to each major comment below and specify the revisions planned for the next version of the manuscript.
read point-by-point responses
-
Referee: The central claim that the nine surveyed stacks suffice to define stable, interoperable layer boundaries rests on observed common needs but provides no explicit per-stack mapping to the proposed openQSE layers, no cross-vendor prototype exercising the interfaces, and no concrete analysis of how FTQC mechanisms (error correction, logical-qubit interfaces, syndrome extraction) would be hidden from upper layers. This gap directly undermines the assertion that the boundaries will require no upper-layer changes when moving from NISQ to FTQC.
Authors: We agree that an explicit per-stack mapping would improve clarity and verifiability. In the revised manuscript we will add a table in Section 4 that maps the components of each of the nine stacks onto the four openQSE layers. We will also expand the FTQC discussion in Section 5 to describe how the runtime-abstraction and interconnect-semantics layers encapsulate error-correction logic, logical-qubit interfaces, and syndrome extraction so that upper-layer applications remain unchanged; concrete examples drawn from the surveyed stacks will be included. A working cross-vendor prototype, however, lies outside the scope of the present survey paper; we will state this limitation explicitly and note it as planned future work. revision: partial
-
Referee: The representativeness assumption—that patterns from the nine stacks generalize to broad vendor interoperability—is load-bearing yet untested; the manuscript does not report selection criteria for the stacks, quantitative coverage metrics, or a falsifiable test (e.g., implementing a minimal cross-stack workflow) that would confirm the boundaries are both necessary and sufficient.
Authors: We accept that the selection criteria and coverage analysis should have been stated more explicitly. The revised manuscript will include a dedicated subsection under the survey methodology that lists the criteria used to select the nine stacks (production status, vendor diversity, and public availability at the time of writing) and provides a quantitative summary of how many stacks exhibit each identified pattern. A falsifiable cross-stack workflow test would require implementation effort beyond the scope of this survey; we will acknowledge this limitation and identify such validation as an important direction for subsequent research. revision: yes
- Absence of a cross-vendor prototype exercising the proposed openQSE interfaces.
- Empirical falsifiable test confirming that the layer boundaries are both necessary and sufficient.
Circularity Check
No circularity: openQSE layers derived from external survey patterns, not self-definition or fitted inputs
full rationale
The paper's chain consists of surveying nine independent production QHPC stacks, extracting recurring requirements (runtime abstraction, resource management, interconnect semantics, observability), and proposing openQSE layer boundaries as a unification step. No equations, fitted parameters, or self-citations are invoked to justify the boundaries; the architecture is presented as an organizational synthesis of observed external patterns rather than a reduction to author-defined quantities or prior self-work. The claim that the layers support NISQ-to-FTQC transition without upper-layer changes is an unproven assumption about future stability, but it does not create circularity because it is not derived by construction from the proposal itself.
Axiom & Free-Parameter Ledger
axioms (1)
- domain assumption Quantum resources are increasingly integrated into HPC and cloud environments
invented entities (1)
-
openQSE reference architecture
no independent evidence
discussion (0)
Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.