Case Study 2: The Error Correction That Made It Worse

The proposal

A hardware group has been improving two-qubit gate fidelity for eighteen months. They are now at a median two-qubit error of roughly $8 \times 10^{-3}$ and a per-qubit idle error around $10^{-2}$ over the relevant window. Real progress, honestly measured.

Someone proposes the obvious next step: start encoding. They have qubits to spare. The three-qubit repetition code is textbook, the syndrome-extraction circuit is four CNOTs, and the demonstration would show a logical qubit outperforming a physical one — the milestone everyone wants.

The simulation is run in advance, as it should be. Idealized, with perfect syndrome extraction:

   physical error rate  0.0100
   logical error rate   0.0002        <-- 50x better

A fiftyfold improvement. The proposal is approved.

What happened

On hardware, the encoded qubit is worse than the unencoded one. Not marginally — consistently, across runs, by more than a factor of two.

The simulation was not wrong about the code. It was wrong about the circuit.

The assumption nobody wrote down

The idealized simulation applies noise to the data qubits and then extracts the syndrome noiselessly. That is not a modelling simplification; it is the entire result. The syndrome-extraction circuit is four CNOTs and three Toffolis, and those gates are built from the same hardware as everything else.

Put an error rate on them and hold the data error at 0.01:

   syndrome gate error   logical error   verdict
              0.0000            0.0002    HELPS      <-- what was simulated
              0.0010            0.0034    HELPS
              0.0020            0.0058    HELPS
              0.0030            0.0092    HELPS
              0.0035            ~0.0100    breakeven
              0.0040            0.0122    HURTS
              0.0050            0.0159    HURTS
              0.0078            0.0238    HURTS      <-- what they have

Breakeven is a syndrome gate error of about 0.0035. They are at 0.0078.

At their actual gate quality, a physical error rate of 0.0100 becomes a logical error rate of 0.0238. Error correction made the error rate 2.4× worse, using three times the qubits. The measured result was not a surprise; it was the simulation, run with one assumption removed.

The shape of the mistake

It is worth naming precisely, because it is not carelessness.

The simulation was correct. Every number in it is right. It answers the question "how much does the three-qubit code suppress data errors, given perfect syndrome extraction?" and the answer is "fiftyfold."

That question was not the decision. The decision was "will encoding improve our logical error rate on our hardware?" — and the two questions have different answers because the second one includes the cost of asking.

The machinery that fixes errors is built from the same imperfect parts that cause them.

This is not a detail. It is what makes the threshold a threshold. If syndrome extraction were free, more distance would always help and there would be no threshold at all — §25.8's naive crossover sits at $p = 0.5$ precisely because that calculation assumes free syndrome extraction. The real threshold, for real codes, is set almost entirely by the quality of the extraction circuit.

Three chapters have now produced the same structure. Chapter 13: mitigation costs shots, and at a fixed budget it can lose. Chapter 19: an ancilla left dirty looks exactly like decoherence — the bookkeeping you added becomes the noise you are fighting. Chapter 24: adding mitigation to a variational loop can increase the final error. Every remedy has a cost denominated in the same currency as the disease.

What they should have run

Not a different simulation — the same simulation with the assumption exposed:

   1. Put a realistic error rate on EVERY gate, including the ones doing the
      correcting. If a gate exists in the circuit, it has an error rate.

   2. Sweep the syndrome-extraction error and find the BREAKEVEN, not the
      improvement factor. The number you need is a threshold, not a ratio.

   3. Compare the breakeven against MEASURED hardware, not target hardware.
      They had the measurement. Chapter 12's calibration data is one API call.

   4. Report the answer as yes-or-no, because that is the kind of question
      it is.

Step 2 is the one that changes the decision. "Fiftyfold improvement" and "breakeven at 0.0035" are answers to different questions, and only the second one is actionable — it converts directly into a hardware target.

And notice that step 4 is not a rhetorical flourish. §25.8 showed that below threshold the logical error falls exponentially in distance and above it rises exponentially. There is no smooth region in between, no partial credit, no "our code helps a little." The group was not slightly short. They were on the wrong side of a phase transition, and no amount of work on code size would have moved them — only work on gate quality.

The version of this that is not a mistake

The same group, a year later, uses the analysis correctly.

They compute the breakeven first: 0.0035 for this code and noise model. That becomes a hardware specification rather than a disappointment. It tells them what two-qubit fidelity has to be reached before any encoding demonstration is worth attempting, and it tells them the number is roughly a factor of two away — which is a tractable eighteen-month goal rather than an open-ended one.

That is what a threshold is for. It converts "is our hardware good enough?" — a vague, morale-driven question — into a specific number that engineering can be pointed at.

The lessons

List the noise sources your simulation omits, and check that the omission is safe. "Perfect syndrome extraction" is not a simplification; it is the assumption that determines the answer. The omitted term dominated.

Compute the breakeven, not the improvement factor. A ratio measured under favourable assumptions tells you nothing about whether to proceed. A threshold tells you exactly what to do next.

Use your own measured hardware numbers. Chapter 12 pulled the median two-qubit error from calibration data in a few lines. The group had this number; it simply was not in the simulation.

A threshold question deserves a yes-or-no answer. Reporting "50× improvement" invited the reading that they were close. Reporting "breakeven at 0.0035, we are at 0.0078, so: no" would have been correct, useful, and would have saved a quarter.

Reproduce it: code/example-03-the-threshold.py §3 sweeps the syndrome-extraction error and marks Chapter 12's measured median; syndrome_breakeven() in code/vqelab/errorcorrection.py returns the number directly, and test_at_chapter_12s_MEASURED_gate_error_the_code_makes_things_worse asserts the conclusion.