REVIEW 3 major objections 3 minor 2 cited by
Quantum-HPC Software Stacks and the openQSE Reference Architecture: A Survey
T0 review · 3 major / 3 minor · reviewed 2026-07-05 · glm-5.2
Pith's one-line read Survey of nine quantum-HPC stacks yields openQSE reference architecture
desk verdict Survey of nine QHPC stacks plus a proposed reference architecture (openQSE). The survey is the real contribution; the architecture is a reasonable design proposal but the interoperability claim is aspirational, not demonstrated. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The openQSE reference architecture, defined by layer boundaries extracted from a comparative survey of nine production QHPC stacks. The survey methodology identifies common design patterns across deployment models, application interaction patterns, SDK support, and fault-tolerance readiness, then distills those patterns into interface contracts that separate concerns at the runtime, resource-management, orchestration, and execution layers.
What would settle it
A stack outside the surveyed nine exhibits a fundamentally different architecture that cannot be decomposed along the openQSE layer boundaries without loss of functionality, demonstrating that the identified common patterns are an artifact of the sample rather than a property of the domain.
Extended reading notes
Core claim
Nine independently developed quantum-HPC software stacks share enough common design patterns—particularly in runtime abstraction, resource management, interconnect semantics, and observability—that a single reference architecture (openQSE) can capture their collective structure. The key claim is that defining layer boundaries at these common seams enables interoperability across different implementations without sacrificing deployment flexibility, and that these same boundaries serve both NISQ and FTQC workloads without requiring application-level changes.
Load-bearing premise
The nine surveyed stacks are representative of the broader quantum-HPC landscape, and the common design patterns identified across them generalize to stacks not included in the survey. The paper does not explain how these nine were selected or whether they span the full design space.
Editorial extensions
If this is right
- If openQSE layer boundaries are adopted, quantum-HPC vendors could specialize in individual layers (runtime, resource management, orchestration) rather than building monolithic full stacks, lowering barriers to entry for new contributors.
- Application developers could write quantum programs against stable upper-layer interfaces that survive the transition from NISQ to fault-tolerant hardware, protecting software investment.
- Standardized interconnect semantics would enable quantum resources to be scheduled and orchestrated within existing HPC job-management frameworks, potentially treating quantum devices as schedulable accelerators alongside GPUs and FPGAs.
- Observability layer standardization could give operators cross-vendor visibility into quantum job execution, enabling benchmarking and debugging tools that work across different quantum-HPC platforms.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. This manuscript surveys nine production quantum-HPC (QHPC) software stacks and, based on observed common design patterns, proposes the open Quantum-HPC Software Ecosystem (openQSE) reference architecture. The architecture defines layer boundaries intended to enable interoperability across different QHPC implementations while preserving deployment flexibility, and is structured to support both NISQ and future FTQC workloads without changes to upper-layer application interfaces. The paper positions openQSE as a 'first step toward unifying the state-of-the-practice.' This review is based on the abstract only, as the full text was not available for assessment.
Significance. The problem addressed — lack of common interfaces and interoperability across quantum-HPC software stacks — is timely and practically important for the field. If the openQSE architecture is well-motivated by the survey findings and the layer boundaries are concretely specified, the work could serve as a useful community reference point. The proposal of falsifiable, prescriptive layer boundaries derived from production stack analysis is a contribution of potential interest to practitioners and standards efforts. However, assessment of the actual significance is severely limited by the absence of the full text: the abstract does not indicate whether the architecture is validated by a reference implementation, conformance examples, or stakeholder agreement, which would materially affect the strength of the contribution.
major comments (3)
- The abstract asserts that openQSE 'defines a set of layer boundaries that allow different implementations to interoperate,' presenting interoperability as an achieved property. However, the supporting evidence described is descriptive — common design patterns identified across nine stacks. Observing convergent patterns across existing stacks does not by itself establish that a proposed set of boundaries will achieve interoperability when implemented. The manuscript needs to provide, in the full text, either a reference implementation, a conformance test suite, a worked interoperability example, or explicit stakeholder agreement from stack vendors. Without any of these, the claim should be reframed as a design hypothesis or aspirational goal rather than a demonstrated property of the architecture.
- The claim that openQSE 'support[s] both current NISQ workloads and future fault-tolerant quantum computing (FTQC) systems without changes to upper-layer application interfaces' is a strong architectural commitment. NISQ execution (direct circuit execution with error mitigation) and FTQC execution (logical qubits with error correction cycles) involve fundamentally different execution models. If none of the nine surveyed stacks yet implement FTQC, the NISQ/FTQC portability assertion is extrapolating beyond the survey's empirical basis. The full text should clarify what evidence or reasoning supports the 'without changes' claim for FTQC specifically, or the claim should be qualified accordingly (e.g., 'designed to support' rather than 'supports').
- The survey methodology is not described in the abstract: the selection criteria for the nine stacks, the design-space coverage they represent, and whether they span the relevant variation in deployment models, hardware backends, and architectural approaches are all unstated. If the nine stacks are not representative — for example, if they are predominantly cloud-based or predominantly from one vendor ecosystem — the generalizability of the identified patterns to the broader QHPC landscape is uncertain. The full text should explicitly state selection criteria and discuss potential selection bias, particularly whether the observed commonalities reflect genuine architectural convergence rather than shared lineage or market influence among the surveyed stacks.
minor comments (3)
- The abstract does not name the nine surveyed stacks. Listing them (or at least categorizing them) in the abstract or prominently in the introduction would help readers assess coverage and relevance at a glance.
- The phrase 'first step toward unifying the state-of-the-practice' suggests the authors acknowledge the preliminary nature of the proposal. This framing should be used consistently; the stronger claims about interoperability and NISQ/FTQC portability should be aligned with this preliminary positioning.
- No mention is made in the abstract of related standardization efforts (e.g., QIR, OpenQASM 3, IQCP). The full text should discuss how openQSE relates to, complements, or differs from these existing efforts to position the contribution clearly.
Simulated Author's Rebuttal
We thank the referee for a careful and constructive review. The referee raises three substantive points, all of which are well-taken. We address each below. In brief: (1) we agree that the interoperability claim should be reframed as a design goal rather than an achieved property, and will revise accordingly; (2) we agree that the NISQ/FTQC portability claim should be qualified, since none of the surveyed stacks yet implement FTQC; and (3) we agree that the survey methodology, selection criteria, and potential selection bias should be made explicit in the full text. We note that this review was based on the abstract alone; the full manuscript already contains substantial material addressing several of these concerns, but we will strengthen the presentation in revision.
read point-by-point responses
-
Referee: The abstract asserts that openQSE 'defines a set of layer boundaries that allow different implementations to interoperate,' presenting interoperability as an achieved property. However, the supporting evidence described is descriptive — common design patterns identified across nine stacks. Observing convergent patterns across existing stacks does not by itself establish that a proposed set of boundaries will achieve interoperability when implemented. The manuscript needs to provide, in the full text, either a reference implementation, a conformance test suite, a worked interoperability example, or explicit stakeholder agreement from stack vendors. Without any of these, the claim should be reframed as a design hypothesis or aspirational goal rather than a demonstrated property of the architecture.
Authors: The referee is correct. Observing convergent design patterns across nine production stacks supports the motivation for openQSE's layer boundaries, but it does not demonstrate that interoperability has been achieved. We will reframe the claim in both the abstract and the body. Specifically, the abstract will be revised to state that openQSE 'defines a set of layer boundaries intended to enable interoperability across different implementations,' rather than presenting interoperability as an achieved property. In the body, we will explicitly characterize openQSE as a design hypothesis grounded in empirical observation of convergent patterns, and we will state clearly that validation via reference implementation, conformance testing, or stakeholder agreement is future work. We note that the full text does include a worked example showing how two surveyed stacks would map onto the openQSE layer boundaries, but this is illustrative rather than validating, and we will label it as such. revision: yes
-
Referee: The claim that openQSE 'support[s] both current NISQ workloads and future fault-tolerant quantum computing (FTQC) systems without changes to upper-layer application interfaces' is a strong architectural commitment. NISQ execution (direct circuit execution with error mitigation) and FTQC execution (logical qubits with error correction cycles) involve fundamentally different execution models. If none of the nine surveyed stacks yet implement FTQC, the NISQ/FTQC portability assertion is extrapolating beyond the survey's empirical basis. The full text should clarify what evidence or reasoning supports the 'without changes' claim for FTQC specifically, or the claim should be qualified accordingly (e.g., 'designed to support' rather than 'supports').
Authors: The referee is correct that none of the nine surveyed stacks currently implement FTQC execution, and therefore the FTQC portability claim is not grounded in the survey's empirical basis. The claim is based on architectural reasoning: the openQSE layer boundaries place the NISQ/FTQC execution-model distinction below the runtime abstraction layer, so that upper-layer application interfaces interact with a stable runtime API regardless of whether the backend executes physical or logical qubits. However, this is a design argument, not an empirically validated result. We will qualify the claim in the abstract to 'designed to support both current NISQ workloads and future FTQC systems without changes to upper-layer application interfaces,' and in the body we will explicitly state that the FTQC portability property is an architectural hypothesis that remains to be validated as FTQC-capable stacks emerge. revision: yes
-
Referee: The survey methodology is not described in the abstract: the selection criteria for the nine stacks, the design-space coverage they represent, and whether they span the relevant variation in deployment models, hardware backends, and architectural approaches are all unstated. If the nine stacks are not representative — for example, if they are predominantly cloud-based or predominantly from one vendor ecosystem — the generalizability of the identified patterns to the broader QHPC landscape is uncertain. The full text should explicitly state selection criteria and discuss potential selection bias, particularly whether the observed commonalities reflect genuine architectural convergence rather than shared lineage or market influence among the surveyed stacks.
Authors: The referee is correct that the abstract does not describe the survey methodology. The full text does include selection criteria and a discussion of design-space coverage, but we agree this should be more prominent and that potential selection bias should be explicitly addressed. The nine stacks were selected to span: (a) on-premises HPC-integrated deployments and cloud-based deployments; (b) multiple hardware backend modalities (superconducting, trapped-ion, photonic); and (c) different architectural lineages (academic-derived, vendor-proprietary, and open-source community stacks). We will add a methodology paragraph to the abstract briefly stating the selection criteria, and we will expand the body's discussion of selection bias, including the concern that some observed commonalities may reflect shared lineage or market influence rather than independent architectural convergence. We will also add a limitations subsection acknowledging that nine stacks, while covering the variation we identified, do not exhaust the design space. revision: partial
Circularity Check
No circularity: the paper proposes a reference architecture from observed patterns in external stacks; no fitted parameters, self-referential definitions, or self-citation chains are present.
full rationale
This is an abstract-only review of a survey paper proposing a reference architecture (openQSE) based on analysis of nine external production QHPC software stacks. The derivation chain is: (1) observe common design patterns across surveyed stacks, (2) abstract those patterns into layer boundaries, (3) propose the reference architecture. There are no fitted parameters being re-presented as predictions, no definitions that circularly enforce the result, no self-citation chain load-bearing the central claim, and no ansatz smuggled through citation. The paper's claim that openQSE 'defines a set of layer boundaries that allow different implementations to interoperate' is an architectural proposal, not a mathematical derivation or a fitted prediction. The concerns raised by the reader and skeptic — survey representativeness, the leap from description to prescription, and the unsupported NISQ/FTQC portability assertion — are correctness and validation concerns, not circularity. They question whether the proposal is well-grounded and whether its claims are empirically validated, which falls outside the scope of circularity analysis. No step in the available text reduces to its own inputs by construction.
Assumptions & free parameters
assumptions (3)
- domain assumption The nine surveyed QHPC stacks are representative of the broader landscape
- domain assumption Common design patterns identified across the nine stacks generalize to stacks not included
- ad hoc to paper Layer boundaries can be defined that allow interoperability without sacrificing deployment flexibility
invented entities (1)
-
openQSE reference architecture
Cite this review
Pith. "Pith review of Quantum-HPC Software Stacks and the openQSE Reference Architecture: A Survey." pith.science (2026). https://pith.science/paper/TYCCYR4J
@misc{pith2026260420912,
author = {Pith},
title = {Pith review of: Quantum-HPC Software Stacks and the openQSE Reference Architecture: A Survey},
year = {2026},
howpublished = {\url{https://pith.science/paper/TYCCYR4J}},
note = {Machine review of arXiv:2604.20912}
}
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.
Figures
Forward citations
Cited by 2 Pith papers
-
Examining QRMI as a Unified Interface for Quantum-HPC Integration
QRMI's acquire-execute-release interface can be adapted to PBS, LSF, Grid Engine, Kubernetes, and partly Flux, with three reusable integration patterns.
-
SQUIRO: A Framework for Security-Aware Quantum-Classical Scheduling on Kubernetes
SQUIRO enforces security posture as hard scheduling constraints and ranks quantum backends by coherence margin and queue pressure, reporting up to 51% cost and 63% energy savings on synthetic underloaded Kubernetes clusters.
Reviewed July 5, 2026 · model on record in the stance chip above.
Discussion (0). Sign in to comment.