Realization Divergence in Multi-Provider Quantum Computing: A Pre-Registered Study of What Survives Measurement

arXiv:2610.21714 · cs.SE, quant-ph · Submitted 2026-10-15 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: Quantum Radio. Generated commentary on the latest quantum physics and condensed matter papers.

Kai: I'm Kai.

Mira: And I'm Mira, here with Lev.

Kai: Today's paper: "Realization Divergence in Multi-Provider Quantum Computing".

Mira: The gist The observable difference in how an identical source circuit is realized and behaves across quantum software stacks is called realization divergence,

Kai: First, who's behind it and why it matters.

Paper summary: Kai: So, to recap, this paper is about realizing that when you have identical source circuits on different quantum software stacks, they can produce different observed outcomes. They call this distance realization divergence and they’ve done a hardware study across three vendors and four devices.

Mira: The thesis is that this divergence isn't just noise; it’s tied to the compilation, transpilation, and vendor services that happen before execution. They focus on the observable difference in the compiled structure and execution behavior of identical source circuits across providers.

Lev: What matters is how they set up their experiment because they combine pre-registered predictions with explicitly identified exploratory analyses and amendments as part of their study design. That adds a layer of rigor to what they’re claiming is a measurable phenomenon.

Kai: They look at specific metrics too, like embedding radius correlating with two-qubit overhead at Spearman zero point eight zero five versus zero point four nine two for circuit size in one compilation experiment <ref:2610.21714#pg1,with two-qubit overhead at Spearman 0.805>. It shows how those structural metrics affect the execution divergence we're measuring across different hardware stacks on some systems, right?

Mira: And they found that under a fixed lowest-index policy, an eight-qubit Bernstein–Vazirani circuit showed greater execution divergence than a twelve-qubit circuit specifically on IQM Emerald. But this ordering flips when you look at IQM Garnet.

Lev: It’s telling us that the results aren't universally stable across all hardware configurations; they are dependent on the specific vendor and the placement policy they assign during compilation. That dependency is central to what they’re investigating here.

Kai: And then there's this look at interface failures in composed toolchains, where they classify them as needed but undeclared, declared but unconsumed, and accepted but overridden contracts. These are tangible artifacts you can look for when building complex quantum software pipelines.

Mira: The paper’s main contribution is showing that the stability of a supported-operation list doesn't guarantee that the device’s native gate set hasn't changed underneath it. That forces us to be extremely careful about what we assume when comparing results from different providers.

Lev: So, this isn't just theoretical noise discussion; it’s providing an empirically grounded classification of interface failures in these composed toolchains, which helps guide quality assurance practices for cross-platform tools.

Kai: It really matters because it moves the conversation from "is my circuit running?" to "what specific software and hardware layers are causing this observable divergence?" That shifts the focus of debugging a lot.

Mira: And they also quantified structural divergence using Dstruct(A, R) which is the weighted mean of relative metric differences across circuit depth, two-qubit gate count, and total gate count. They pair that up with execution-layer divergence using Jensen–Shannon divergence for output probability distributions.

Lev: That framework gives us a way to formally quantify the structural difference versus the actual distributional difference in measurement outcomes. It separates the problem into what's compiled wrong versus what's noisy during execution on real hardware.

Kai: So, this whole study is about providing a framework for making these comparisons more meaningful by accounting for all those different layers of transformation involved between writing code and getting a result on a quantum machine.

Conclusion: Mira: So, looking at the whole picture from this study, the authors are showing us that cross-platform comparisons aren't just about checking if an algorithm works; they have to account for the entire software stack involved.

Kai: Right. The title itself points to this realization divergence—the observable difference in how a circuit is realized and behaves across different quantum software stacks. It’s not just a theoretical concept; it’s something we see when we try to use cloud platforms or multi-provider access for development.

Lev: What this means in practice is that portability isn't automatic anymore, even if the high-level interface looks the same to you, because the underlying compilation and mapping decisions are what cause the divergence.

Kai: So for someone listening who just wants to run an algorithm, this paper suggests they need to record a lot more metadata with every comparison: source code, compiled artifacts, distribution used, metric weights, physical layout of the device profile.

Mira: And that isn't just nice practice; it’s necessary for regression investigation and for assessing portability accurately. You can’t assess portability without capturing all those variables you mentioned.

Lev: The paper highlights that the limitations are tied to the specific devices, circuits, and toolchains they exercised in their study, which means we can't just assume these findings apply universally across every single quantum system out there right now.

Kai: Exactly. They’re not trying to solve every possible problem; they’re defining where the current understanding is strong enough to guide the next steps in building better tools and quality assurance practices.

Mira: So, the implication is a shift toward explicit context—explicitly considering observability and measured outcomes when you are doing any cross-provider comparison. It’s about making sure your comparisons are actually meaningful.

Jouni Peltonen, Vlad Stirbu, Tommi Mikkonen

University of Jyvaskyla · QMill Oy

cs.SE, quant-ph

Submitted: 2026-10-15

Updated: 2026-10-15

Comments: 36 pages. Submitted to Software Quality Journal. Replication package: https://doi.org/10.5281/zenodo.22471564

Code: https://github.com/Qiskit/qiskit

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

Importance score: 91/100

The gist: The gist The observable difference in how an identical source circuit is realized and behaves across quantum software stacks is called realization divergence, which requires explicit conditions to be

Key concepts

Realization Divergence: This is the observable difference in how an identical source quantum circuit is actually built (realized) and performs when run across different quantum software stacks or hardware providers. It measures the gap between what was written and what actually executes.
Placement Policy: This refers to the rules or strategies used during the compilation process to decide where on a specific quantum device a circuit should be mapped. The study showed that these placement policies significantly influence how structural differences manifest, affecting results across different hardware vendors.
Structural Divergence: This type of divergence measures differences in the circuit's structure after it has been transpiled for a specific provider. It is quantified by comparing metrics like gate counts and depth between circuits realized on different platforms, helping researchers pinpoint where the compilation process introduces variations.

Summary

The gist The observable difference in how an identical source circuit is realized and behaves across quantum software stacks is called realization divergence, which requires explicit conditions to be portable

How it works

The study introduces a framework that models quantum program execution through four layers: source language (Lsrc), intermediate representations (Lir), transpiled target-constrained circuits (Ltr), and execution (Lexec). This layered observation model focuses on observable artifacts at Ltr and Lexec, as the internal layer Lir includes transformations that are typically inaccessible in production toolchains. The framework analyzes artifacts at two primary observation points: transpiled circuits (Ltr) produced by client-side Qiskit compilation and execution results (Lexec) retrieved via Amazon Braket API.

The operational toolchain implements a four-stage pipeline:

Transpilation, where Qiskit compiles source circuits for provider-specific gate sets and device topologies.
Structural analysis, which parses transpiled OpenQASM to extract depth, gate counts and qubit mappings to compute structural divergence pairwise across providers.
Execution, where circuits are submitted to QPUs via the Amazon Braket API with standardized shot counts.
Divergence quantification, which compares measurement distributions and links structural transformations to execution outcomes.

Key Findings and Research Questions

The research addresses three core questions regarding realization divergence:

RQ1: Which cross-provider realization-divergence claims are portable, and which hold only under stated conditions of metric weighting, placement policy and submission track?

The study found that realized radius is positively associated with two-qubit overhead across the placement variants. Furthermore, the BV8–BV12 structural inversion survives all 66 tested weightings on Emerald and Cepheus under lowest-index placement, but disappears under compiler-default placement.

RQ2: What does a provider’s interface actually guarantee about an execution, and how does the resulting variation in observability constrain what can be compared across providers?

The study identified that a supported-operation list can remain unchanged while the native entangler changes. It also noted that a ported result must therefore name the device generation measured, because the advertised contract may not record that the generation changed.

RQ3: What failure modes arise when heterogeneous compilation and execution components are composed, and what invariants detect them?

The study identified three failure modes in composed toolchains: Needed but undeclared, Declared but unconsumed, and Accepted but overridden. The practical response is to validate the specific contract at each boundary, while recognizing that unobserved failure modes remain outside those checks.

Quantification and Metric Validity

The framework uses a taxonomy of observable divergence types, distinguishing between Transpilation-layer structural divergence and Execution-layer distributional divergence. Structural divergence is quantified using Dstruct(A, R) = X, which is the weighted mean of relative metric differences across circuit depth, two-qubit gate count, and total gate count. Execution-layer divergence compares output probability distributions using Jensen–Shannon (JS) divergence. The study also tested metric weighting by re-scoring results over a grid of alternative weightings, showing that the BV8–BV12 structural inversion under lowest-index placement remains present on Emerald and Cepheus and absent on Garnet.

Implications for Practice

Practitioners should record the observation layer, source and compiled artifacts, reference distribution, metric weights, physical layout, device profile and software versions with each comparison. These records can support regression investigation and portability assessment. Quality assessment requires explicit consideration of both observability and measured outcomes.

Limitations and Future Work

The findings are bounded by the devices, circuits and toolchains exercised in this study. Future work should focus on Cross-toolchain validation, Physical attribution, Coverage and scalability, Longitudinal replication, and Fault-tolerant compilation. The layered model suggests a possible extension to logical-to-fault-tolerant compilation.

Improvements for AI systems

Bold header: Cross-layer divergence quantification

An improved system can quantify divergence by comparing structural metrics to the source circuit and output distributions to its ideal simulation, explicitly linking the observed artifacts at Ltr and Lexec as described in Section 4.4, rather than assuming a single layer is sufficient for comparison.

Bold header: Placement-dependent explanation verification

The system can test hypotheses by performing Targeted placement experiments and hardware replications to determine if an embedding-based explanation of selected divergence orderings holds, thereby distinguishing descriptive associations from targeted tests of their interpretation.

Bold header: Interface observability constraint mapping

The AI can map what a provider's interface guarantees by identifying differences in available records, noting that a stable supported-operation list need not expose changes in a device’s native gate set, which constrains the scope of cross-provider comparison.

Bold header: Composed toolchain failure mode detection

The system can detect Needed but undeclared or Accepted but overridden failures by implementing boundary checks for the observed cases, such as checking that count totals must match the recorded shots at the analysis boundary.