PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Jouni Peltonen, Vlad Stirbu, Tommi Mikkonen

arXiv:2610.21714v1cs.SEquant-ph

TL;DR

Identical quantum circuits can be compiled and executed differently across provider stacks, while the artifacts users can inspect do not expose every transformation. This paper combines a layered framework with hardware comparisons and interface analysis; its results support conditional placement-dependent orderings, identify observability limits, and classify composed-toolchain failures.

  • Problem

    Compilation and qubit mapping affect the circuits exposed to hardware noise, while multi-provider comparisons rely on artifacts that may not reveal all transformations.

    Source: §1 · p. 2, §2 · p. 3

  • Method

    The study develops and applies a layered divergence framework and integrated toolchain to observable compilation and execution artifacts across providers.

    Source: §1 · p. 2, §11 · p. 30

  • Results

    Emerald and Garnet show replicated opposite BV8–BV12 execution orderings under lowest-index placement, supporting an embedding-dependent explanation without identifying individual noise mechanisms.

    Source: §11 · p. 30

  • Takeaways & Limitations

    Cross-provider comparisons should specify the observed artifact, parameter domain, device generation, and conditions such as weighting and placement.

    Source: §11 · p. 30

    The findings are bounded by the devices, circuits, and toolchains studied, and the measurements do not establish quantum-state fidelity or causal attribution to particular noise sources.

    Source: §7.2 · p. 25, §9 · p. 27

Abstract

from arXiv · show

Quantum programs pass through compilers, transpilers and vendor services before execution. However, the distance between what was written and what runs is rarely measured. We call this distance realization divergence: the observable difference in how an identical source circuit is realized and behaves across quantum software stacks. We report a hardware study across three vendors and four devices, combining pre-registered predictions with explicitly identified exploratory analyses and amendments. In a compilation experiment with assigned placement policies, embedding radius correlates with two-qubit overhead at Spearman 0.805, against 0.492 for circuit size. Under a fixed lowest-index policy, an eight-qubit Bernstein-Vazirani circuit exhibits greater execution divergence than a twelve-qubit circuit on IQM Emerald. The opposite ordering occurs on IQM Garnet. Both comparisons replicate across two repetitions with disjoint confidence intervals. These results support a placement-dependent explanation, without isolating individual hardware noise mechanisms. The same ordering inversion is absent on the all-to-all IonQ control. On Rigetti Cepheus, a follow-up using topology-aware native placement found no consistent advantage in correct-answer probability for either submission track, but did not establish equivalence between the tracks. Structural comparisons depend on metric weighting, placement and device generation. Provider interfaces also limit observability: Rigetti's supported-operation list remained unchanged across a device generation that replaced the native entangler. We classify silent interface failures in composed toolchains and identify checks at toolchain boundaries, connecting valid cross-provider comparisons with concrete software-quality practices.

1 Introduction

The paper measures realization divergence—the observable structural and behavioral differences between identical source circuits across software stacks—because compilation and qubit mapping shape the circuits exposed to hardware noise. It combines a framework and hardware evidence to test which comparisons hold under stated conditions and to identify observability limits and toolchain failures.

1 Introduction

  • Identical circuit specifications can yield different observed outcomes because compilation and qubit mapping affect circuits exposed to hardware noise.The paper therefore frames efficient development workflows as needing to account for both software and execution context.Source: §1 · p. 2
  • The paper studies realization divergence as observable differences in compiled structure and execution behavior, not as a separation of software effects from hardware noise.Its comparisons are based on artifacts exposed by heterogeneous provider interfaces.Source: §1 · p. 2
  • The study examines which cross-provider comparisons survive changes in placement and measurement choices, using evidence across three vendors and four devices.It combines registered predictions with explicitly identified exploratory analyses.Source: §1 · p. 2
  • The framework is the instrument; the evaluated questions concern which divergence claims survive measurement, what interfaces expose, and what fails when components are composed.The work follows Design Science Research principles to develop the practical artifact and measure representative circuits on commercial platforms.Source: §1 · p. 2
  • The contributions combine evidence for conditional divergence orderings, characterization of provider-interface observability, and a classification of interface failures in composed toolchains.The paper stresses that structural rankings depend on weighting, placement, and device generation.Source: §1 · pp. 2–3
  • Provider interfaces can leave supported-operation lists unchanged across native-gate changes, while composed toolchains can produce explicit errors or valid-looking artifacts with inconsistent relationships.The paper identifies boundary checks for the observed failure cases.Source: §1 · p. 3

2 Background and Related Work

Quantum compilation and provider interfaces make cross-platform comparisons difficult because transformations vary and are often opaque. The paper situates its framework among work on compilation, benchmarking, equivalence, reproducibility, and software engineering, then illustrates why comparisons must specify their observation layer and conditions.

2 Background and Related Work

  • Cloud platforms expose heterogeneous hardware and provider-specific programming models, transpilers, and runtime services, complicating cross-provider compatibility.The background positions this diversity alongside growing use of multi-provider quantum platforms.Source: §2 · p. 3

2.1 Motivating Example: Bell Circuit Divergence

  • The Bell example requires seven gates on IQM Emerald and eight on Rigetti Cepheus in native realizations, with no routing needed.The structural difference therefore comes from gate-set synthesis rather than connectivity.Source: §2.1 · p. 4
  • At the supported gate set, evaluated devices return the Bell source unchanged, so observing only that layer would miss native-gate differences.A portability claim must name its observation layer.Source: §2.1 · p. 4, Figure 1 · p. 4

2.2 Quantum Languages and Compilation

  • Compiler research spans automated translation and comparison, device-specific compilation, pass selection, benchmarking, and verified optimization.This study complements those approaches by testing comparisons based on client-visible artifacts and provider records.Source: §2.2 · pp. 4–5

2.3 Benchmarking and Cross-Platform Evaluation

  • Benchmarking covers quality, speed, scale, application performance, and quantum volume, while compilation can explicitly trade gate count against output fidelity.The paper examines placement, metric choice, submission track, and observability jointly as comparison conditions.Source: §2.3 · p. 5

2.4 Quantum Circuit Equivalence and Optimization

  • Equivalence-checking and differential-testing methods address correctness questions that structural counts cannot decide; this paper instead characterizes compiled structure and noisy execution.Reproducibility records must also identify the compiled circuit, placement, and outcome representation that each measurement describes.Source: §2.4 · p. 5, §2.5 · p. 5

2.5 Reproducibility, Software Engineering, and Semantic Models

  • Prior work addresses temporal transpilation drift and multi-provider provenance; this paper studies cross-provider divergence at both transpilation and execution layers.The paper describes its work as complementary to semantic models and proposes portability-aware validation as a possible extension to drift gates.Source: §2.5 · pp. 5–6
  • The study evaluates conditional comparison claims using a layered observation model, hardware replications, placement controls, and provider-interface limits.It builds on compiler comparison, benchmarking, and testing while focusing on what accessible artifacts support.Source: §2.5 · p. 6

3 Research Methodology

The methodology develops and evaluates a Divergence Analysis Framework using observable artifacts from multi-provider executions. Its toolchain analyzes compilation and execution records, while research questions specify which divergence claims are conditional, what interfaces expose, and how composed components fail.

3 Research Methodology

  • The study follows Design Science Research to build a framework combining a layered observation model, a divergence taxonomy, and an operational toolchain.It analyzes observable artifacts from multi-provider executions.Source: §3 · pp. 6–7

3.1 Artifact Design

  • The toolchain compiles provider-specific circuits, extracts structural metrics and mappings, submits executions through Amazon Braket, validates results, and compares distributions.Cross-layer correlations link structural transformations to execution outcomes.Source: §3.1 · p. 7
  • The toolchain uses API-accessible OpenQASM, device specifications, and measurement results; CI/CD regression-gate deployment is proposed, not evaluated.Supported and native submission tracks differ in whether the provider or client performs further compilation and placement.Source: §3.1 · p. 7

3.2 Research Questions

  • The research questions ask which divergence claims are portable or conditional, what provider interfaces guarantee about execution, and what failures arise when components are composed.The questions also ask which invariants detect those failures.Source: §3.2 · pp. 7–8
  • Pre-registration and the guard discipline distinguish scored outcomes from outcomes selected after the fact.They are means of answering the questions, not results themselves.Source: §3.2 · p. 8

4 Divergence Analysis Framework

The framework compares observable structural and execution artifacts across layers, using explicit references and metrics while recording conditions that constrain interpretation. Its measurements characterize operational portability but do not establish ideal equivalence or isolate hardware noise.

4.1 Design Objectives and Scope

  • The framework is designed to identify, compare, and localize realization divergence across heterogeneous platforms using accessible artifacts and provenance.Its scope is gate-based circuits on cloud-accessible QPUs; execution measurements combine transformations and hardware noise.Source: §4.1 · p. 8

4.2 Layered Observation Model

  • The observation model spans source, intermediate representations, target-constrained transpiled circuits, and execution; empirical analysis focuses on transpiled circuits and execution results.The internal intermediate layer is typically inaccessible in production toolchains.Source: §4.2 · p. 8
  • The source uses OpenQASM as a vendor-neutral reference, while the transpiled layer captures device-specific gate conversion, layout, routing, and often scheduling.The transpiled layer is the primary locus for cross-platform structural divergence.Source: §4.2 · pp. 8–9

4.3 Realization Divergence Taxonomy

  • The taxonomy distinguishes structural divergence from transpilation and behavioral divergence in measured distributions at execution.These categories capture changes in circuit structure and sampling behavior across layers.Source: §4.3 · p. 9

4.4 Operationalization and Quantification

  • Structural comparisons use accessible transpiled circuits and execution records, with the source circuit as a reference for provider-induced divergence.Structural drift is adapted for source-relative and cross-provider comparisons.Source: §4.4 · p. 9
  • Dstruct averages relative differences across depth, two-qubit gate count, and total gate count, excluding zero-reference metrics and renormalizing retained weights.Dstruct = 0 means equality on retained metrics, not circuit identity; the score is reference-directed and is not a mathematical distance.Source: §4.4 · p. 10
  • Execution distributions are compared with Jensen–Shannon divergence, which remains finite and bounded when finite shots leave outcomes unobserved.Ideal-output algorithms are compared with noiseless simulation; variational or stochastic algorithms use pairwise comparisons.Source: §4.4 · p. 11

4.5 Metric Validity Conditions

  • Across 66 alternative weightings, the BV8–BV12 structural inversion under lowest-index placement remains on Emerald and Cepheus but is absent on Garnet.The full circuit ranking changes with weights, so the tested ordering is conditional and does not imply cross-device clustering.Source: §4.5 · p. 11

5 Framework Demonstration

The framework compares identical circuits across provider-supported and native compilation layers, then examines how compiled structure and execution behavior vary across platforms. Its demonstrations show that portability conclusions depend on the observation layer, while structural and execution comparisons require explicit conditions.

5.1.1 Quantum Platforms and Toolchain

  • The workflow uses identical OpenQASM source circuits, Qiskit v2.5.1 at optimization level 3, fixed seeds and enforced hardware coupling maps.Repeated native-track transpilation was bit-identical under forced layout in tested cases, while supported-track QAOA depth varied by twelve percent; scheduling, calibration and internal compilation remain uncontrolled.Source: §5.1.1 · pp. 12–13
  • Hardware execution covers four platforms: IonQ Forte-1 (trapped-ion, all-to-all connectivity), IQM Emerald and Garnet, and Rigetti Cepheus (superconducting, lattice connectivity).Emerald and Garnet share a native gate set but differ in device size, available connectivity and calibration state; they are not identical-topology controls.Source: §5.1.1 · p. 12

5.1.2 Test Circuit Selection

  • The circuit set targets connectivity, gate-set expressivity and routing, with small 4–6-qubit instances and medium 8–12-qubit instances; larger circuits are excluded to enable comparable real-hardware execution.The demonstration's Table 2 circuit set is narrower than the pre-registered Section 6 campaign's Table 3 set.Source: §5.1.2 · p. 13, Table 2 · p. 13

5.2 Bell Circuit: Layer-Specific Interpretation

  • All four evaluated devices return the Bell circuit unchanged at the supported gate set, but native compilation differs across devices and IonQ requires a vendor plugin.Emerald produces six single-qubit rotations around one entangler; Cepheus produces seven rotations around one entangler from a different basis, while IonQ's native gates are unavailable through the common toolchain.Source: §5.2 · pp. 13–14
  • Source-level portability does not imply operational portability, and the layer used to make a portability claim determines whether divergence is observable.IonQ's native layer requires leaving the common toolchain, so a single-interface study may record this gap as missing data.Source: §5.2 · p. 14

5.3 Representative Case Study: Bernstein–Vazirani Algorithm

  • BV12 is used to connect compilation and execution observations; its deterministic ideal output and routing sensitivity make it suitable for measuring divergence across layers.Its shallow logical depth limits noise-dominated effects while its scale can induce non-trivial routing overhead on constrained topologies.Source: §5.3 · p. 14

5.3.1 Transpilation-Layer Divergence

  • On Emerald, Garnet and Cepheus, BV12 native artifacts have (depth, two-qubit gate count, total gate count) values of (45, 18, 83), (61, 35, 132) and (73, 29, 129), respectively.Under equal weighting, Garnet is structurally closer to Cepheus than to Emerald; these artifact measurements are not hardware-quality scores.Source: §5.3.1 · p. 14

5.3.2 Execution-Layer Divergence

  • The evaluation compares JS divergence and target probability against BV12's ideal point-mass reference, using per-run confidence intervals and circuit-size comparisons.The main campaign uses 1000 shots, and the placement-matched follow-up uses 8000; neither measure alone identifies the cause of departure from the reference.Source: §5.3.2 · p. 14

6 Evaluation

The evaluation examines realization divergence across devices and toolchains through hardware tests, compilation-only experiments, and interface and toolchain analyses, with some rules amended after initial observations. It also examines explicit rejections and silent relational failures in composed toolchains, alongside contract-specific boundary validation and its limits.

6.1 Evaluation Setup

  • The evaluation used 132 main-campaign runs plus 18 noise-floor runs, with separate placement and IonQ controls; not every rule was preregistered before the first run.The original predictions preceded the first BV submissions, but amendments introduced scoring categories after some repetition-one results; later follow-up rules were set beforehand.Source: §6.1 · pp. 15, 17

6.2 RQ1: What Can Be Claimed, and Under What Conditions

  • All available native-track artifacts differed from their sources on selected structural metrics, while supported-track artifacts often agreed; source agreement does not establish identical realizations or execution.Structural scores were source-referenced, not pairwise device distances, and their interpretation depended on metric weighting.Source: §6.2 · p. 17, Table 4 · p. 18

6.2.1 Assigned-Placement Experiment

  • Across 239 assigned-policy embeddings, radius correlated with two-qubit overhead at Spearman 0.805, versus 0.492 for circuit size.The association was positive within each placement policy, but placement assignment changed multiple embedding properties and did not isolate radius alone.Source: §6.2.1 · p. 19, Figure 3 · p. 20

6.2.2 Placement-Policy Test

  • The BV8–BV12 structural inversion persisted across 66 weightings on Emerald and Cepheus under lowest-index placement, but disappeared under compiler-default placement.Qiskit and tket agreed on which tested device–placement combinations exhibited the inversion; it is not a circuit-size-only property.Source: §6.2.2 · p. 19

6.2.3 Hardware Replication and Control Devices

  • Under lowest-index placement, Emerald’s BV8 diverged more than BV12 while Garnet showed the opposite ordering, with disjoint individual intervals in both repetitions.The reversal supports an embedding-based account but does not isolate device-specific noise or other hardware mechanisms. The limited all-to-all IonQ control showed no Emerald-like inversion in either repetition.Source: §6.2.3 · pp. 20–21, Table 6 · p. 21

6.2.4 Matched-Placement Comparison of Submission Tracks

  • The placement-matched Cepheus comparison found no uniform winner between submission tracks, and all six upper ratio limits remained below two.BV5 favored the supported track by 1.66× and 1.71×; the comparison did not establish track equivalence or isolate calibration-aware placement as the cause.Source: §6.2.4 · pp. 21–22, Table 7 · p. 22

6.3 RQ2: What a Provider’s Interface Guarantees

  • Provider observability varied: IQM and Rigetti returned compiled programs and per-shot records, while the evaluated IonQ interface returned neither.Rigetti’s supported-operation list stayed identical across Ankaa-3 and Cepheus although the native entangler changed from iswap to cz; native two-qubit-count ratios ranged from 0.63 to 1.20, without a uniform direction. Interfaces also under-specified admissible rotation angles and other submission constraints.Source: §6.3 · pp. 22–23, Table 8 · p. 23

6.4 RQ3: Failure Modes of a Composed Toolchain

  • Composed-toolchain failures included undeclared constraints, published constraints ignored by clients, and accepted instructions silently overridden by later stages.At the analysis boundary, probabilities treated as shot counts could yield empty distributions, while mismatched bitstring widths could produce maximal divergence despite well-formed artifacts.Source: §6.4 · p. 24
  • A reporting entry cited an analysis file missing its reported value, prompting a test-suite check that regenerates values from run records and compares them with the findings ledger.The comparison specifies the finding, device, track, repetition, and column rather than hard-coding an expected value; this was an RQ3 failure in the measurement pipeline, not a separate contribution about scientific writing.Source: §6.4 · p. 24
  • Published qubit, shot-count, and execution-window constraints can be checked before submission; undocumented angle limits require capability probes or observed rejections, not repeated metadata review.Source: §6.4 · p. 24
  • Placement checks compare requested with realized mappings and test contrasts expected to remain distinct; arbitrary input changes need not change an optimized output.Source: §6.4 · pp. 24–25
  • At analysis, shot totals must match recorded shots; probability-only responses need separate normalization and shot-count handling, and comparisons require consistent outcome width and bit ordering.Valid samples can have disjoint observed outcomes; the implemented width check catches a reported mismatch but does not verify every aspect of outcome semantics.Source: §6.4 · p. 25
  • The composed toolchain exhibited both explicit rejections and silent relational failures, requiring boundary-specific contract checks while leaving unobserved failures outside their scope.Source: §6.4 · p. 25

7 Discussion

Structural divergence scores depend on metric weighting, placement, and device generation, while measured agreement does not establish fidelity or identify specific noise causes. Placement interventions support an embedding-based explanation for selected orderings but do not isolate radius or rule out other causes.

7.1 Why a Divergence Magnitude Is Not a Device Property

  • Only 12 of 66 native-track weightings reproduce the equal-weight circuit ranking, and the minimum Spearman correlation with that ranking is zero.The score characterizes a circuit, compiler configuration, reference, and device profile jointly, not an intrinsic device property.Source: §7.1 · p. 25
  • The BV inversion survives tested weightings under lowest-index placement, but orderings generally need not survive changes in placement, device, or generation.Changing placement alters routing costs; changing the native entangler can alter synthesis costs even when the supported-operation list is unchanged.Source: §7.1 · p. 25

7.2 Interpretation and Scope

  • Structural metrics and output distributions expose aspects of operational portability but do not establish quantum-state fidelity or attribute results to particular noise sources.A zero score in Table 4 means agreement on selected metrics, not identity of complete circuits or physical realizations.Source: §7.2 · p. 25
  • The placement intervention supports an embedding-based explanation, but it does not isolate radius from other embedding properties or rule out interacting hardware and provider causes.The placement-matched comparison bounds an observed track difference; it is not a causal estimate of calibration-aware placement alone.Source: §7.2 · p. 25

8 Implications for Quantum Software Engineering

The discussion translates the study’s measurements into practices for recording comparison conditions and checking software quality. These records can aid regression investigation and portability assessment, but provider-selection comparisons require comparable workloads, explicit conditions, and uncertainty estimates.

8.1 Implications for Practice

  • Record the observation layer, source and compiled artifacts, reference distribution, metric weights, physical layout, device profile, and software versions; a seed alone is insufficient.Capability checks should cover native parameter domains and returned result types, not just gate names.Source: §8.1 · p. 26
  • A pre-campaign Qiskit 0.45.2 versus 2.3.0 comparison found measurable structural differences, illustrating why software provenance belongs in reproducible records.Automated multi-provider CI remains to be evaluated; provider-selection assessment additionally requires comparable workloads, explicit placement and compilation conditions, and uncertainty estimates.Source: §8.1 · p. 26

8.2 Implications for Software Quality

  • On Cepheus, topology-aware native placement provided greater control over the submitted circuit, but neither submission track had a consistent correct-answer advantage across tested cases.Quality assessment should consider observability alongside measured outcomes.Source: §8.2 · p. 26
  • Interface failures can leave compilation and submission apparently successful while placement requirements are ignored or returned outcomes are misinterpreted.Checks should validate relationships among source circuits, compiled artifacts, submitted programs, and returned results, not only each artifact separately.Source: §8.2 · p. 26
  • A portability figure, reproducibility claim, or regression gate supports comparisons beyond its recorded conditions only when its validity conditions are stated.The study maps its evidence to five engineering quality concerns (Table 9).Source: §8.2 · pp. 26–27, Table 9 · p. 27

9 Limitations and Threats to Validity

The reported findings are bounded by the circuits, devices, and toolchains evaluated, with distinct limits on repetition, coverage, measurement, and generalization. The study does not establish scalability to substantially larger circuits or validate its orderings on fault-tolerant hardware.

9.1 Threats to the Empirical Findings

  • Two repetitions support recurrence of specified headline orderings, not stable divergence levels or characterization of longer-term drift.Garnet’s available qubits and execution levels changed between repetitions; the separate IonQ Bell probe had one repetition.Source: §9.1 · p. 27
  • The pinned Qiskit v2.5.1 harness and repeated compilation checks establish repeatability in tested cases, not general compiler independence.Compiler versions, stochastic choices, placement, and metric weighting can change structural comparisons; vendor-internal transformations remain partly unobserved.Source: §9.1 · pp. 27–28
  • IonQ’s nine execution records limit cross-device comparisons, and its targeted control does not support a balanced provider ranking or universal circuit-class claim.Connectivity remains confounded with hardware technology.Source: §9.1 · p. 28
  • Cepheus track ratios characterize tested submission choices, not the isolated effect of calibration-aware selection, because placement and provider processing differ.The follow-up did not match physical qubits, pulse programs, or calibration conditions; comparable native artifacts were unavailable for IonQ.Source: §9.1 · p. 28
  • Boundary checks address identified interface failure modes but do not validate every scientific claim or detect every possible pipeline failure.Successful analysis and passing tests provide evidence only for the relationships checked.Source: §9.1 · p. 28
  • Amendment chronology and later repetitions separate prospective tests from exploratory interpretation, but cannot make earlier observations prospective or eliminate selection effects.Per-run intervals and exploratory, unadjusted permutation tests quantify conditional sampling uncertainty, not unobserved calibration changes; overlapping intervals do not establish equivalence.Source: §9.1 · pp. 28–29

9.2 Scalability and Generalization Beyond NISQ

  • The evaluation covers reported circuit sizes and NISQ-era devices, not substantially larger circuits or fault-tolerant hardware.The applicability of the layered model beyond NISQ remains an open validation question.Source: §9.2 · p. 29

10 Future Work

The future-work agenda targets validation across toolchains, better physical attribution, broader coverage and scale, longitudinal replication, and extension to fault-tolerant compilation.

10 Future Work

  • Repeat placement and weighting analyses across toolchains, add calibration, pulse, and noise-model evidence, and expand circuit, all-to-all-device, dynamic-circuit, and scale coverage.These studies would test validity beyond the pinned toolchain and help distinguish compilation effects from physical mechanisms.Source: §10 · p. 29
  • Repeat campaigns across calibration cycles and hardware generations to test ordering stability beyond two repetitions and distinguish drift from provider differences.Longitudinal replication is proposed, not established by the current study.Source: §10 · p. 30
  • Extend the observation model to fault-tolerant compilation with validated logical-level measures, resource-aware scheduling, and distributional metrics suited to logical-error regimes.Candidate measures include T-count, logical depth, and logical-qubit overhead.Source: §10 · p. 30

11 Conclusion

The paper measures realization divergence across language, transpilation, and execution layers, making comparison conditions explicit. Its findings support selected conditional orderings and identify provider-interface and toolchain checks needed to interpret them.

11 Conclusion

  • The framework and toolchain make the study’s contributions testable through observable artifacts by following common circuit specifications through compilation and execution.The evaluation connects observed differences to their measurement conditions.Source: §11 · p. 30
  • The Emerald BV8–BV12 execution ordering and its opposite on Garnet replicate under lowest-index placement, while placement evidence supports an embedding-dependent explanation without identifying individual noise mechanisms.On Cepheus, all supported-to-native target-probability ratios remain below the registered factor of two, but this establishes neither equivalence nor calibration-aware selection.Source: §11 · p. 30
  • Provider interfaces expose different evidence and may omit execution constraints; a supported-operation list can remain unchanged even when the native entangler changes.Comparisons should name the observed artifact, parameter domain, and device generation.Source: §11 · p. 30
  • Composed toolchains show explicit rejections and silent inconsistencies between otherwise valid artifacts, addressed by metadata, capability, layout, and outcome-encoding checks.These checks test explicit relationships but do not guarantee coverage of every failure mode.Source: §11 · p. 30
  • Operational portability must be measured at stated observation layers and under explicit validity conditions to determine which realization-divergence claims remain defensible.The paper connects these conditions to reproducible comparisons and interface checks.Source: §11 · p. 30

Artifact Availability

The accompanying research artifact provides the framework implementation, experimental data, and analysis scripts. Its checks cover selected findings-ledger values but do not establish complete claim coverage or byte-identical regeneration.

Artifact Availability

  • The accompanying artifact includes raw run records, archived device profiles, analysis outputs, and scripts to regenerate them.It also includes the framework implementation, experimental data, and analysis scripts.Source: Artifact Availability · p. 31
  • Tests compare selected findings-ledger values with analysis artifacts and reject distribution-width mismatches.These checks do not cover every claim or establish byte-identical regeneration of every artifact.Source: Artifact Availability · p. 31
  • Dated registrations and findings ledgers are preserved as historical records, with original scoring rationale distinguished from the manuscript’s statistical interpretation.Source: Artifact Availability · p. 31

Statements and Declarations

The paper reports its funding, competing-interest disclosures, data and code availability, and author contributions.

Statements and Declarations

  • The work received support from Business Finland and the Research Council of Finland through named projects and the Finnish Quantum Flagship.Source: Statements and Declarations · p. 31
  • The first author is employed by QMill Oy, which provided Braket access but neither manufactures nor operates quantum hardware; evaluated providers had no role in the study.The remaining authors declare no competing interests.Source: Statements and Declarations · p. 31
  • Measurement records, device profiles, derived analysis files, pre-registered clauses, and scored outcomes are available in the accompanying research artifact.Source: Statements and Declarations · p. 31
  • The analysis toolchain, campaign harness, and figure and table generation scripts are included in the research artifact; Peltonen led the work, with Stirbu and Mikkonen supervising.All authors approved the final manuscript.Source: Statements and Declarations · p. 31
Loading 2610.21714v1…