Error Mitigation vs Error Correction

Two different promises

Mitigation infers a better estimate from noisy runs: calibration, extrapolation to zero noise, post-processing, cleverly designed sampling. The qubits stay noisy; the answer gets cleaner. Correction encodes information into a larger system, extracts syndrome data, and actively protects or restores the logical state. The representation itself changes.

The boundary matters because the two have different ceilings. Mitigation can improve near-term experiments whose circuits are shallow enough to survive at all. Fault-tolerant computation — arbitrarily long, arbitrarily reliable — requires correction plus reliable logical operations. No sampling trick crosses that gap.

What each one costs

Mitigation pays in shots. Its estimates are still sampled, so $\mathrm{SE}(\hat{p})\approx \sqrt{p(1-p)/S}$ applies, and methods like zero-noise extrapolation tend to raise variance as they remove bias — the total shot cost can grow steeply with circuit size.

Correction pays in qubits. The overhead estimate from Chapter 43 applies: $physical\_qubits\approx logical\_qubits\times physical\_per\_logical$, with the multiplier set by the code, the distance, and the physical error rate. Mitigation changes how noisy estimates are interpreted; correction changes how information is represented and protected. Budget accordingly.

Worked example: the oral exam

Prompt: "Why should a mitigated near-term experiment not be marketed as a fault-tolerant machine?"

A strong answer: mitigation can reduce bias in estimates from noisy runs, but it does not encode arbitrary logical information for long computations. Error correction uses redundancy and syndrome extraction to protect logical states, and fault tolerance adds reliable logical gates, repeated syndrome cycles, decoding, and control — at substantial resource overhead. A mitigated demo may be valuable evidence. It becomes evidence of protected logical computation only when logical error behavior itself is demonstrated.

Where the line gets blurred

The first trap: "mitigation fixes the qubits." It does no such thing — it improves estimates or compensates for noise in the reported number, and the underlying device is exactly as noisy afterward as before.

The second trap: "more physical qubits solve it." More qubits without lower error rates, syndrome extraction, and logical operations build a larger noisy system, not a more reliable one. Scale is an ingredient, not the recipe.

The engineering view

Mitigation resembles statistical correction around a faulty measurement pipeline — you model the distortion and un-warp the readings. Correction resembles redundant encoding with online detection and recovery, except quantum mechanics bans the two moves classical redundancy relies on: copying the data and inspecting it directly.

Keep a review table for every reliability claim, with five columns:

• method
• what it improves
• what evidence it needs
• what it cannot claim
• what failure mode remains

The table exists to stop demos from sliding across claim categories as the marketing draft matures. Also ask when each method fails. Mitigation fails when the noise model is wrong, when sampling cost explodes, or when extrapolation leaves the regime the data supports. Correction fails when syndrome extraction is too noisy, overhead too high, or decoding too slow. Fault tolerance fails when logical gates spread errors faster than the code can contain them. These failure modes belong in the same memo as the claimed benefit.

What this buys you in diligence

When a vendor claims useful output from noisy hardware, ask which of the three regimes the claim lives in — mitigation, correction, or fault tolerance. If the terms are used interchangeably, the claim is not ready for partnership diligence. If each evidence level is labeled cleanly, the team may be technically disciplined even when the result is early, and that discipline is itself signal.

Exercise

Mitigation vs correction oral. Take one current demo claim and classify it.

• Evidence: write a three-column table — example, benefit, limitation — for mitigation and for correction, plus the evidence each requires.
• Check: apply the shot standard error to any sampled estimate and the physical-per-logical overhead to any correction claim.
• Submit: a label for the claim — learning demo, mitigated experiment, correction evidence, or fault-tolerance evidence — and one sentence on what would move it up a level.
• Repair: if your table uses mitigation and correction interchangeably, rework it after Chapter 45 (Decoherence and Error Channels), which builds the noise vocabulary both methods answer to.

Check your understanding

Without notes: compare mitigation and correction with one example, one benefit, and one failure mode each.

Oral defense: a founder says their error-mitigation results show they are "on the path to fault tolerance." Steelman the claim, then name the evidence gap it skips.

If you get stuck

If your answers treat mitigation as fault tolerance, or raw qubit counts as sufficient proof, return to Chapter 45 (Decoherence and Error Channels) and rebuild the noise model first; the next three chapters then construct correction on top of it.