1,722 IBM Quantum jobs as of 2026-10-27. The first 1,605, every one enumerated.

The corpus

What is in the manifest.

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.

Circuit width is read off each device’s parsed circuits. ibm_torino’s 11 jobs returned no circuits, so this file records no width for them; IBM’s own device data (2026-03-14) lists ibm_torino at 133 qubits, a Heron r1.

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 and r3 are 156 qubits; the first Heron, r1, is 133. Here is what 3,436 transpiled circuits in this corpus actually contain:

156 is the transpiled device width — every parsed circuit is laid out across the full chip of a 156-qubit Heron. How many bits each circuit reads out is in the same file: 1 bit ×1,879 · 2 bits ×168 · 4 bits ×507 · 6 bits ×629, running all the way to 156. A readout count is not a width either — a circuit can entangle many qubits and read out one. Of the 1,879 single-bit circuits, 650 carry 50 or more two-qubit gates, up to 7,261. The 135 estimator circuits read out nothing by design and are counted apart.

Verification · tiers 2 and 3

The rest, honestly.

1. Anyone, no account. The totals and gate histogram above, and the sha256 below: the full manifest you receive under NDA must hash to it.
2. A reviewer we grant instance read access. Every job id in the full manifest 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, counted. The detail, under NDA.

The full per-job manifest — job id, device, primitive, status, queue and run timestamps, QPU seconds, per-circuit width, depth, size and gate counts, and per-result shot counts for all 1,605 jobs — is the router’s calibration data, so it is not published. It is available under NDA from john@epochcoreqcs.com.

Its fingerprint is published, so the copy you receive can be checked against what this page committed to:

sha256 4ba47c5b9046efdfa13cc5416a02b1c0a2768949e3005729b7f61cba374e647d · 1021 KB

In the manifest, IBM instance identifiers are credentials and are replaced with the labels A–D. The build refuses to write it 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 were submitted as OpenQASM 2.0 strings rather than compiled circuits, and our 2026-09-18 retrieval did not decode them — our bug, not IBM’s. Decoded on 2026-09-22 and published separately: 11 completed, with 8,960 shots between them, and 13 failed IBM’s validation (error 1517). They address 1–12 qubits directly, so they stay out of the aggregates on this page, which describe the 3,436 compiled circuits. The 24-job addendum (13 KB) is part of the manifest available under NDA.
• 1,416 of 1,605 carry result data in the main file, and 11 more in the addendum. The remainder either failed, were cancelled, or completed without our retrieving their results.

Every number on this page about the corpus is computed from the file at build time. Figures from other documents — the routing backtest, the pharma build’s artifact, the swarm receipt, the R13 receipt, the clinical seal — are named where they appear, and the build checks each one this file can check.

Cross-substrate experiment · R13

The A/B, and what came back.

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, taken from the run’s receipt, are in the full manifest above. Four completed — the flash_sync arm and its control, for one algorithm, in both variants — and returned 1,024 shots each. The run’s own harness recorded none, and our 2026-09-18 retrieval could not decode them either: they were submitted as OpenQASM 2.0, and IBM returns their results in a raw per-shot format both readers missed. The shots were recovered on 2026-09-22 and are in the OpenQASM addendum under Completeness, above. The other twelve failed IBM’s validation with error 1517: each circuit placed a two-qubit gate on a qubit pair the device does not couple, because it had not been routed for the target, so none of them produced 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. Four circuits read out 24 qubits or more with at least 100 two-qubit gates, on real Heron, to completion. The gate floor is deliberate: it excludes full-register readouts, which read out many qubits 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 full manifest, 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 on this corpus, plus live selection.

The routing weights were fitted on this corpus. That is what “calibrated on 1,601 real IBM Heron jobs” means — a fit against recorded outcomes, not a credential. The figure is the router’s, and this corpus matches its count: sorted by submission time, job 1,601 here ran on 2026-06-26. Which of these jobs the fit used is not in any record we hold — the original tuner’s output has not been recovered — so this page checks the count, not the fit.

What routes today is live. At submit, the dispatcher reads every eligible Heron backend’s queue depth and operational flag and takes the least-queued — and the clinical chain seals that decision, every candidate and its value, into each run (below). This corpus of 1,605 jobs is what that policy is measured against.

Here is why the choice matters 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 — GHZ-3, Grover-2, QFT-3, Bell, and two copies of GHZ-3 submitted as zero-noise-extrapolation folds — fired only once the queue drained to 15 pending. GHZ-3 splits 000/111, QFT-3 concentrates on 000, Bell gives 00+11. Grover-2 came back close to uniform — its most frequent outcome holds p 0.269 — and is in the full manifest as returned.

Three independent records agree on it: the build’s own captured artifact, its evidence dossier, and the full manifest — which lists the same job with six circuits at depths 10, 9, 32, 7, 10, 10, and top-outcome probabilities that match the artifact’s counts. One thing the manifest shows that the dossier does not say: the two fold pubs compiled to exactly the base GHZ-3 circuit, same depth and the same 2 CZ, so on hardware they ran as repeats rather than as noise-amplified copies. None of the three records 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 shows an effect. No claim rests on it — see R13.