How to read a quantum computing claim.

The six terms that decide everything

Post-selected. Many results discard runs that fail a check before scoring the rest. That is a legitimate technique — and a number that only describes the shots that survived. The honest form always states the acceptance rate. A 99.9% fidelity at 96% acceptance and a 99.9% fidelity at 0.1% acceptance are radically different achievements; without the acceptance rate you cannot tell them apart.

One-basis vs two-basis. A qubit has two ways to fail — bit flips and phase flips — and protecting only one of them is classical memory, not a qubit. One-basis numbers look spectacular precisely because they ignore half the problem. Any memory or error-correction claim should say which bases were measured.

Detection vs correction. Detection notices an error and throws the run away. Correction fixes it mid-run and keeps going. Detection results are real and useful, but they do not scale the way correction does — discarding compounds. The words are not interchangeable, though marketing frequently swaps them.

Encoded vs fault-tolerant. “Encoded” means the state lives inside an error-correcting code. “Fault-tolerant” is a far higher bar: every operation, including the error-correction machinery itself, must fail safely. Most published “logical qubit” results are encoded; very few are fault-tolerant; the difference is years of engineering.

Per-run vs per-cycle. Error rates only compare when the unit of exposure matches. A per-circuit error over one short run and a per-cycle error over a million syndrome cycles can differ by orders of magnitude for the same hardware. Comparing across units is the single most common sleight of hand in this field.

Whose hardware. A measurement made on rented cloud hardware characterizes the rented machine at least as much as the team that ran it. That does not make the measurement worthless — ours are all made this way, and we say so — but a number is not evidence about a company’s own device unless the device is theirs.

Four questions to ask any vendor — including us

1. Was it post-selected, and at what acceptance rate? 2. How many bases — and per what unit of exposure? 3. Detection or correction — and did anything happen mid-run? 4. Whose hardware, and can I see the raw data? A team with good answers will enjoy the questions. A team without them will change the subject.

A worked example: our own headline number

Our ledger leads with 99.94% — a three-basis logical Bell-state fidelity in the [[4,2,2]] code. Run the checklist against it: it is post-selected at ~96% acceptance per basis; it is three-basis but a single-run preparation, not a per-cycle rate; it is detection, not correction — distance-2 corrects nothing; it is encoded, nowhere near fault-tolerant; and it ran on rented IBM hardware, so it substantially characterizes one of IBM’s coupler pairs, not any device of ours. Encoded [[4,2,2]] Bell states are also published prior work on several platforms — we claim no first. That is what the number honestly is. It is still worth publishing — with all of that attached, which is why the ledger attaches it.

If a claim — anyone’s — cannot survive this checklist with its meaning intact, the number was doing the work the evidence couldn’t.