One auditable trail from quantum job to verdict —
that checks its own models before it questions your hardware.
Quantum Clarity is an end-to-end assurance layer for quantum operations. QuantaCore™ qualifies and freezes not only the selected backend and qubits, but the physical execution path the workload will actually experience — placement, compiled schedule, timing exposure, dynamic-control context, and workload-relevant probes. Eigenspectrum™ then scores the returned result against a contract fixed before the outcome is seen. Every step is hash-bound, and the final verdict is recomputable from the provider's own raw output — no re-run required.
Calibration tells you whether qubits look healthy. It does not necessarily tell you whether your compiled workload will remain healthy while it executes. On IBM hardware we observed nearly identical zero-delay baselines across two runs, while the same nominal delayed path differed by 4.37σ. That is the gap QuantaCore is being extended to qualify before a costly workload is trusted.
A single provenance trail,
submission to verdict.
The two halves are not separate tools that hand off. They are the preflight and postflight ends of one continuous, tamper-evident chain. Each stage emits a hash-bound artifact; the verdict at the end is bound to the contract declared at the start.
in integration.
Calibration says the QPU is healthy.
QuantaCore asks whether your workload will be.
Quantum providers publish valuable calibration data. IBM Quantum, for example, exposes per-qubit T1, T2 and readout error, plus instruction error rates and durations through the platform and Qiskit. Those numbers describe the device. They do not, by themselves, describe the physical timeline your transpiled workload will experience once routing, idle windows, measurement, feed-forward and conditional control are introduced.
What the provider already gives you
QuantaCore starts from the provider's own calibration and target data rather than replacing it.
IBM documents these properties through backend.properties(), backend.qubit_properties()
and backend.target. See
IBM Quantum · View backend details.
What QuantaCore adds
It evaluates the realized physical execution: which physical qubits were chosen, how the circuit was transpiled and routed, where the state sits idle, whether mid-circuit measurement or classical feed-forward is present, and whether a small matched probe says that path is behaving inside a frozen tolerance.
Where each half
does its job.
A quantum result can be untrustworthy for two different reasons: it ran somewhere unreliable, or it came back violating the rules it was supposed to preserve. The pipeline addresses both — and is honest about the maturity of each end.
QuantaCore™
Records and freezes the conditions under which a quantum workload runs — backend and physical-qubit selection, calibration and device-health context, circuit and transpilation provenance, realized timing exposure, dynamic-control context, execution plans and limits. It can also run small matched probes to qualify whether the actual execution path is behaving inside a predeclared envelope before a larger workload is trusted.
QuantaCore detail →
Eigenspectrum™
Evaluates a returned result against a contract declared before the run — the invariants the result was supposed to preserve — and produces an auditable ACCEPT / FLAG / ABSTAIN. The contract, scoring policy, and thresholds are frozen and hashed before the outcome is known, so the acceptance rule cannot be quietly changed after the data is seen.
Eigenspectrum detail →
What the pipeline
has actually shown.
Every figure below is reproducible. Hardware results are tied to public IBM Quantum job IDs — across three independent Heron-class processors to date — and the reported observables recompute from the provider's own returned measurement data.
The pipeline caught a fault in its own reference model.
A five-probe suite on IBM hardware produced a large residual on the single-qubit idle-relaxation probe. A conventional pipeline might have blamed the device. Ours did not. Investigation found the reference model had declared idle thermal relaxation as "modeled" while its executable path never applied duration-matched relaxation to the delay — a false capability claim inside our own reference, not a hardware fault.
The first repair was also rejected: it computed the correct analytic answer but reused it while claiming executable verification. Only a second repair — a real duration-aware path, independently sampled — qualified. After correction, a residual remained:
And we still did not call it a hardware anomaly. The evidence establishes a result-versus-reference discrepancy — most likely a frozen snapshot stale relative to execution — and does not yet isolate the cause. The entire correction reused the original hardware counts, with no additional QPU execution.
Preflight selection, proven on someone else's protocol.
In February 2026, Yamaguchi, Kempf and collaborators published encrypted quantum cloning — a lawful workaround structure to the no-cloning theorem — and proposed quantum storage as its headline application, without measuring the storage regime itself. Our preflight layer selected the qubits from the same-day calibration snapshot and ran the first storage-lifetime measurement of their protocol, on ibm_kingston, the same device as their original demonstration, on a calibration day below chip median.
Pre-registered — including a prediction miss, documented in the record rather than hidden. Data, calibration snapshot, and a public reproduction script: DOI 10.5281/zenodo.21299091.
Our own 8.9σ result did not survive our own follow-up.
On ibm_kingston, a Bell-state timing study measured a large, highly significant loss across a nominal 1.444-µs idle window. Rather than publish it, we pre-registered a held-out replication on the same qubit pair, with that point excluded from the grid used to predict it. It did not reproduce.
We do not know which run was correct, and do not claim to. What is established is narrower and more useful: a zero-delay baseline can reproduce to 0.28σ while a timing-dependent condition on the same qubits differs by 4.37σ. This was designed by hand, not caught by a preflight gate — it is the gap QuantaCore is being extended to close, not a capability it has.
The follow-up also found a fault we had missed: the earlier sweep sampled every 21.28 µs against a 20.2 µs Nyquist limit, making an ordinary phase winding look like chaotic decoherence. The finer grid resolved it at −24.804 ± 0.173 kHz (reduced χ² = 0.79). Nothing in the pipeline flagged the sampling error — which is why a sampling-adequacy check is on the roadmap, not in the product.
Two quantum processors, one frozen contract — fully public.
In a separate, openly published study, a single pre-registered contract (SHA-256 44d34db0…), hashed before any result was seen, was applied across an exact solver, a noisy simulator, a device-calibrated twin, and two independent IBM Heron processors — Kingston and Fez.
It accepted the exact reference, abstained honestly on a shot-limited valid hardware run, and flagged a deliberately corrupted one — the complete ACCEPT / FLAG / ABSTAIN triad, on real hardware, from one hashed contract. Every verdict recomputes from published data with two one-command scripts: no QPU re-run, no "trust us."
Open repository — code, data, and verifiers: github.com/amitb-quantum/helium-vqe-assurance
<Y0·Z1> = −0.701172
exactly. The claim is not "trust us" — it is "clone the repo and run the verifier scripts": every verdict
recomputes from published data, anchored to public IBM Quantum job IDs, with no QPU re-run and no
dependence on third-party job access.
An assurance layer,
not another algorithm.
For a platform like IBM Quantum or Google Quantum AI, the value is not merely a faster result. It is a workload-specific execution assurance layer: use the provider's calibration, qualify the realized physical path, freeze the contract before execution, and adjudicate the returned result afterward. The goal is to spend QPU budget on executions whose placement, timing and control context are actually fit for the workload.
Pre-registered verdicts
Contracts, policies, and thresholds are frozen and hashed before the result is seen — the acceptance rule can't move after the data lands.
Recomputable results
Verdicts and observables regenerate from the provider's own returned data, tied to public job IDs — auditable by anyone, after the fact, with no QPU re-run.
Self-suspecting by design
The pipeline is architected to flag its own reference models and repairs before attributing a discrepancy to hardware — the property that prevents false alarms about your QPU.
Execution-path qualification
Evaluates the physical path the transpiled workload will experience — placement, schedule, idle exposure and dynamic-control context — rather than assuming a healthy calibration snapshot guarantees a healthy workload.
Temporal sampling adequacy
Checks whether a registered time-domain sampling grid can resolve the dynamics the analysis claims to infer, reducing the risk that aliasing is mistaken for decoherence, drift or anomalous hardware behavior.
Shadow-mode ready
Runs alongside jobs that execute anyway, logging the verdicts and placements it would have produced — evaluated against real outcomes without affecting a single user job.
Knows when to abstain
A verifier that always answers is not measuring its own resolution. When the data cannot certify a result, the verdict is ABSTAIN — an honest "not yet," not a false pass. That restraint is what makes an ACCEPT mean something.
The same discipline,
wherever you can't check the answer.
Declare the invariants, freeze and hash the contract before the result, score ACCEPT / FLAG / ABSTAIN. Nothing in that is quantum-specific. It applies wherever you cannot check a result against ground truth but can constrain it by rules the right answer must obey — financial model validation (SR 11-7), AI/ML evaluation contracts, simulation conservation laws, clinical endpoint pre-specification.
Stated as intended applications, not demonstrated capability. Quantum is where the method has been exercised on real hardware, and where invariants are unusually sharp — which is what makes it a good proving ground.
What the pipeline is —
and the lines we hold.
What it is
- An end-to-end provenance trail: preflight context → execution → postflight verdict
- A validated invariant detector — simulation ground truth, then real hardware
- Frozen, hash-bound contracts with verdicts recomputable from the provider's own data
- A pipeline that flags its own reference-model faults before blaming hardware
- Preflight qubit selection demonstrated end-to-end on a third party's published protocol
- Execution-path qualification methodology demonstrated on IBM hardware with a prospectively held-out timing test
- Temporal sampling adequacy identified as a preflight gate after a follow-up resolved an aliased device dynamic
- Architecturally end-to-end today; unified single-command runner in integration
We attribute discrepancies conservatively — never to hardware without isolating the cause. No detected anomaly is claimed unless the mundane explanations are ruled out first.
We state IP precisely. QuantaCore™ and Eigenspectrum™ are filed trademark applications (Eigenspectrum on an intent-to-use basis) — described as filed, never as registered.
Built on evidence, bound by provenance.
Quantum Clarity is an end-to-end assurance pipeline for quantum operations — from provider calibration and workload-specific execution-path qualification through postflight, contract-bound verdicts. Every figure is designed to remain reproducible from the provider's own output. We are open to technical evaluation, research collaboration, and shadow-mode validation partnerships.
Or contact directly: info@quantum-clarity.com