1,605 Heron jobs. Every one enumerated.

The corpus

What is in the file.

Status: done 1,565 · error 26 · cancelled 14. Primitives: sampler 1,459, estimator 135. Account instances, labelled rather than named because instance ids are credentials: A 1,129 · B 259 · C 193 · D 24. Circuit depth runs 1 to 23,856, median 107.

Verification · tier 1

What you can check with no account at all.

IBM job ids are scoped to the instance that submitted them. A stranger who queries one of these gets RuntimeJobNotFound, so publishing the ids does not by itself make them checkable, and this page does not pretend otherwise.

The gate histogram is different. It is checkable by anyone against IBM’s public device documentation, in about five minutes, with no account and no cooperation from us.

Heron’s native two-qubit gate is CZ, realised through tunable couplers. Eagle and every earlier IBM device use ECR. Heron R2 is 156 qubits. Here is what 3,436 transpiled circuits in this corpus actually contain:

156 is the transpiled device width — every circuit is laid out across the full chip. The logical width is separate and it is in the same file: 0q×135 · 1q×1,879 · 2q×168 · 4q×507 · 6q×629, running all the way to 156. Both numbers are worth reading, and neither is a proxy for the other.

Verification · tiers 2 and 3

The rest, honestly.

1. Anyone, no account. The gate histogram above, plus internal consistency: shot counts against result cardinality, queue timestamps against QPU seconds, device names against IBM’s fleet.
2. A reviewer we grant instance read access. Every job id below resolves in IBM’s own console, with IBM’s timestamps, not ours. Ask and we will arrange it under NDA — that is the offer, and it costs us nothing because the jobs are real.
3. IBM. Can confirm the account and the jobs directly.

The record

Every job, in one file.

Job id, device, primitive, status, queue and run timestamps, QPU seconds, per-circuit width, depth, size and full gate counts, and per-result shot counts. Sixteen rows of it, evenly spaced through the corpus rather than chosen:

Download all 1,605 · JSON, 1021 KB

sha256 5e58a35392141bafc2c09eccbf348d3ae5f827dd9267f5a08e428186b223b88c

IBM instance identifiers are credentials and are replaced with the labels A–D. Nothing else is removed. The build refuses to write the file if any CRN, UUID or account-id-shaped string survives into it.

Completeness

Three gaps, named.

A published dataset that hides its holes is worth less than one that points at them.

• 11 jobs (all ibm_torino) return no API payload. They appear from the CSV export only, with device and status but no circuit detail.
• 24 jobs returned a payload our 2026-09-18 retrieval could not decode. That is our bug, not IBM’s. They carry no circuit or result detail here and are excluded from every aggregate on this page.
• 1,416 of 1,605 carry result data. The remainder either failed, were cancelled, or completed without our retrieving their results.

Every number on this page is computed from the file at build time. None of them is typed by hand.

Cross-substrate experiment · R13

The A/B, and why it is not a result yet.

On 2026-05-16 we ran one experiment across five substrates: GPU statevector, GPU MPS, our router, IBM with the flash_sync carrier, and IBM without it as the control. Four proprietary algorithms, two variants each, forty runs.

All sixteen of its IBM job ids are in the file above. Twelve of them returned RuntimeJobFailureError; four completed. None returned shots. The GPU arms returned 1,024 shots per run; the eight that failed outright were all on GPU MPS.

Width, on hardware

The wide circuits.

Most of this corpus is small circuits — that is what a fingerprinting and calibration workload looks like. It is not the whole of it. 4 circuits ran at 24 logical qubits or above with at least 100 two-qubit gates, on real Heron, to completion. The gate floor is deliberate: it excludes wide-register readouts, which carry a large clbit count without being a wide computation.

A 110-qubit circuit at depth 415 with 1,204 two-qubit gates, completed on ibm_kingston. A 108-qubit one at depth 556 with 1,353. These are not toy circuits and they are not simulations — each row is a job id in the file above, on a named device, with IBM’s own status.

What they are, and why they are batched

These are φ-weighted swarm-consensus circuits from the deployed quantum_consensus tool, which runs an exact state-vector below a calibrated threshold and escalates to hardware above it. The wide runs are the escalations — and the design is the interesting part:

The small arm and the wide arm ride in the same job. Same chip, same calibration window, one SamplerV2 session — so the parity circuit is not a separate experiment you have to trust, it is a control that experienced exactly what the escalation experienced. The manifest shows it directly: those jobs carry n_pubs 2 with both widths inside.

The project’s own dossier reports that for the 4-qubit consensus circuit, the exact state-vector top outcome was 1111 and real Heron agreed, at Hellinger fidelity 0.920 raw and un-mitigated. This corpus confirms the hardware half of that independently — pulled from IBM’s API, not from the receipt — showing top 1111 at p 0.375 on that pub.

The router

A fit, not a live loop.

The routing weights were fitted on this corpus. That is what “measured on 1,605 real IBM Heron jobs” means — a fit against recorded outcomes, not a credential and not a real-time telemetry feed.

Here is why a table is worth having at all, straight out of the file. Wall time from submission to finish, completed jobs:

The median tells you nothing — every device answers in seconds, within a few seconds of each other. The tail is everything. At p90 the spread is 13x, from pittsburgh at 61 s out to 783 s. The gap between wall time and QPU seconds is almost entirely queue, which is why a scheduling decision moves an order of magnitude while the physics does not move at all.

We backtested the policy rather than asserting it

A counterfactual backtest over this corpus (15 September 2026) scored four routing policies against the operator’s real choices on the 1,333 jobs after a 30-day training window, with coverage accounted for so no policy can look good by being scored on the easy half:

Both of our own candidate policies lost to the human, and we publish that. A frozen calibration-style table is 3× worse than the operator at p90, and a trailing-median proxy is better than the table and still worse than the operator. What the backtest does establish is headroom: an oracle reaches p90 8.8 s, 36× below the operator. The signal is there; a trailing median is not it.

Month to month the best-performing backend held its position in 0 of 3 transitions. With n=3 that cannot establish non-persistence — it establishes that the persistence a frozen table assumes is unevidenced here, which is enough to stop trusting one.

Two signals the backtest could not use, because a historical export does not carry them, are live queue depth at submit and the backend’s operational flag and recent error state. The dispatcher reads both today and publishes every candidate’s value on each run; recording them per job and re-running this exact backtest against the same baselines is the next piece of work.

The threshold that does exist

Inside the discovery chain the gate that actually decides is the drug-likeness pre-screen, and it is a number:

score = qed − 0.10 × lipinski_violations − 0.05 × n_alerts
rule: Lipinski Ro5 (≤1 violation) + Veber + verdict != deprioritize

Measured behaviour, which is the interesting part: it passes 93% of the candidates our own generator proposes, but only 3.1% of 97 known potent KRAS G12D compounds, 65.1% of 415 EGFR, and 59.1% of 232 MAT2A. The KRAS number is not a bug — real G12D inhibitors are beyond-Rule-of-5 by design, and a Ro5 screen rejects them. It is published here because it is the honest limit of the screen.

The discovery chain has no automated GPU→QPU escalation today — that specific chain, not the product. The quantum_consensus tool above escalates on a calibrated threshold and has done so on hardware. Sealing the discovery chain's routing decision as a visible step, including when it says no, is the next build.

On hardware · the pharma build

One job, six circuits, checkable three ways.

The Quantum Pharma build’s batched end-to-end validation ran on ibm_kingston on 2026-06-22 as a single Qiskit Runtime job holding six pubs — four circuits plus two zero-noise-extrapolation folds — fired only once the queue drained to 15 pending. Its results are physically correct: GHZ-3 splits 000/111, QFT-3 concentrates on 000, Bell gives 00+11.

Three independent records agree on it: the build’s own captured artifact, its evidence dossier, and the manifest on this page — which lists the same job with six circuits at depths 10, 9, 32, 7, 10, 10 and the CZ counts those circuits imply. None of the three was produced from the others. That is what a checkable claim looks like, and it is the reason the whole export is published rather than a summary.

On hardware · the clinical chain

The clinical chain routes to a QPU.

Step 03 of the clinical-evidence chain prioritises trial arms with QAOA, executed on IBM Heron through Qiskit Runtime SamplerV2. It is not a simulator and not a stand-in. The sealed record carries what a reviewer needs:

That last row is the routing decision itself, written down. Six candidate devices, each with its queue depth at the moment of submission, the eligibility filter, and the rule that picked one. It is published on every run, so the claim that the dispatcher reads live backend state is checkable per mint rather than asserted.

The job id is not in the corpus above, and that is not a discrepancy: the export ends 2026-07-02 and this ran on 2026-09-20. Same instance-scoping caveat applies — the verify line is the call a reviewer with access runs.

Not claimed

What this page does not say.

• That any discovery step ran on quantum hardware. None has. The clinical trial-design step does, and is evidenced above.
• That this corpus is current. It ends 2026-07-02 and is not a live feed.
• That the seal proves execution. It proves integrity — that our key signed a given content and nothing changed after. It does not prove which machine ran it.
• That a stranger can resolve these job ids unaided. They cannot; see tier 2.
• That any affinity number here or elsewhere is a measurement. They are predictions.
• That the flash_sync experiment has a hardware result. It does not, yet.