Error Budgets

Quantum computing needs an error-budget discipline. Without it, teams choose circuits by aspiration instead of feasibility.

In classical site reliability engineering, an error budget defines how much unreliability a service can tolerate while still meeting its objective. In quantum computing, an error budget defines how much physical and statistical error a workload can tolerate while still producing a useful result.

5.1 The error budget mindset

A quantum workload is acceptable only if the total uncertainty and bias remain below the threshold required by the application.

flowchart LR
    Target[Target precision / decision threshold] --> Budget[Allowed total error]
    Budget --> Physical[Physical gate and readout error]
    Budget --> Statistical[Shot noise]
    Budget --> Compilation[Compilation overhead]
    Budget --> Mitigation[Mitigation bias / variance]
    Budget --> Modeling[Problem encoding error]

    Physical --> Result[Reported estimate]
    Statistical --> Result
    Compilation --> Result
    Mitigation --> Result
    Modeling --> Result

Define the output metric and combine errors only through a justified model. Raw gate-error probabilities, observable bias, and sampling variance are different quantities; they cannot simply be added. Compilation and mitigation can change several contributions at once, so avoid double-counting. The budget belongs to the whole workflow.

5.2 Physical error sources

The major physical error sources include:

The dominant source depends on architecture, device, workload, and calibration state.

5.3 Statistical error

Even a perfect quantum device needs repeated measurements for most expectation-value estimates. For independent, identically distributed shots with finite variance, the sample mean has standard error sigma / sqrt(N). Under those assumptions, reducing sampling error by 10× requires about 100× as many shots. Correlations and drift can invalidate this scaling; more shots alone do not remove systematic bias.

That tradeoff should be visible before execution.

flowchart TD
    A[Required confidence interval] --> B[Estimate variance]
    B --> C[Compute shot count]
    C --> D[Estimate runtime and cost]
    D --> E{Acceptable?}
    E -- yes --> F[Run workload]
    E -- no --> G[Change observable grouping, ansatz, backend, or precision target]
    G --> B

5.4 Compilation error exposure

Compilation affects error exposure by changing depth, gate count, routing, and idle time. Two equivalent circuits in ideal math may be very different in hardware reality.

Example policy comparison:

The operator should not pick by one metric alone. The right choice depends on current device data and workload sensitivity.

5.5 Error mitigation versus error correction

Error mitigation tries to extract better estimates from noisy executions without fully correcting errors during computation. It can be useful, but it is not a substitute for fault tolerance.

Error correction encodes logical information across physical qubits and extracts error syndromes. Below a code-and-noise-model-dependent threshold, increasing code distance can suppress logical errors. Beating a particular physical-qubit baseline is a separate finite-size comparison; merely being below threshold does not guarantee that every small code achieves it. Google’s surface-code memory experiments illustrate these distinctions [R5].

flowchart TB
    subgraph Mitigation[Error mitigation]
        N1[Run noisy circuits]
        N2[Model or amplify noise]
        N3[Post-process estimates]
    end

    subgraph Correction[Error correction]
        E1[Encode logical qubit]
        E2[Measure syndromes repeatedly]
        E3[Decode errors]
        E4[Apply correction or frame update]
    end

    Mitigation --> NearTerm[Near-term usefulness]
    Correction --> FaultTolerant[Fault-tolerant computing]

Mitigation is an estimation strategy. Correction is an architectural strategy.

5.6 Logical error budgets

As systems move toward fault tolerance, error budgets shift from physical operations to logical operations. The relevant question becomes:

How many logical operations can the algorithm execute before the probability of failure becomes unacceptable?

IBM’s roadmap materials discuss targets for fault-tolerant systems and large logical circuits in the late 2020s and beyond. See R1, R2, and R3.

A logical error budget should include:

• logical qubit count,
• logical gate count,
• code distance,
• syndrome cycle time,
• decoder latency,
• logical error rate,
• magic-state or non-Clifford resource requirements,
• total runtime.

5.7 Budget worksheet

A practical error budget can be written as a worksheet before execution. The values below are illustrative; they are not a forecast derived from the listed gate errors. Define the Max-Cut approximation ratio against a stated positive reference optimum, and justify the reported standard error for the chosen measurement and mitigation procedure.

error_budget:
  workload: qaoa_maxcut_trial
  target:
    metric: approximation_ratio
    required_resolution: 0.02
    confidence: 0.95
  circuit:
    circuit_qubits: 24
    compiled_depth: 180
    two_qubit_gates: 220
  physical_backend:
    calibration_snapshot: cal_2026_04_18_0900
    max_allowed_two_qubit_error: 0.012
    max_allowed_readout_error: 0.03
  statistical:
    shots: 50000
    expected_standard_error: 0.008
  mitigation:
    measurement_error_mitigation: true
    zero_noise_extrapolation: false
  accept_reject:
    reject_if_depth_above: 220
    reject_if_two_qubit_gates_above: 260
    reject_if_calibration_age_minutes_above: 90

The worksheet does not guarantee success. It prevents unbounded optimism.

5.8 Error-budget SLOs

A quantum platform can expose service-level objectives that are specific to quantum execution:

SLOs convert quantum quality into operational language.

5.9 Failure modes

Failure: spending the entire budget in compilation

A circuit may be acceptable before routing and unacceptable afterward.

Failure: reducing bias while exploding variance

Some mitigation methods improve bias at the cost of much higher variance. The result may need many more shots.

Failure: optimizing for qubit count instead of logical quality

More qubits do not help if their quality or connectivity makes the workload worse.

Failure: reporting values without uncertainty

A point estimate without uncertainty can create false confidence.

5.10 Operator checklist

Before execution:

• Define target precision and confidence.
• Estimate physical error exposure after compilation.
• Estimate statistical error from shot count.
• Decide whether mitigation changes variance materially.
• Set reject thresholds for depth, gate count, calibration age, and backend quality.
• Store the error budget with the job record.

5.11 Chapter summary

Error budgets turn quantum execution from hope into engineering. They force teams to specify what accuracy is needed, how much noise can be tolerated, how many shots are required, and when a workload should not run. Near-term systems need physical and statistical budgets; fault-tolerant systems will need logical error budgets.