Hardware-Aware QEC¶
From ideal models to real devices.
Surface Codes, Minimum-Weight Perfect Matching, and Lattice Surgery all quietly assumed something convenient: every physical qubit, gate, and measurement behaves the same way, all the time. That assumption made the ideas easier to learn. It isn't true of real hardware.
The Assumption We Have Been Making¶
What if the physical qubits don't all behave the same way?
Fabricated quantum devices contain physical variation. Individual qubits, gates, and measurements can perform differently from one another. This doesn't invalidate anything from earlier in this module — a uniform model was a useful abstraction for learning how QEC machinery works. Now that abstraction gets relaxed.
Real Hardware Is Not Uniform¶
Here's a small device, laid out exactly like the surface-code patches you already know. Click a physical qubit to inspect it.
Click any physical qubit to inspect its calibration values.
You should see:
This is called spatial variation: the physical error environment may vary across a quantum processor. No single metric on its own tells you whether a qubit is "good" or "bad" — a qubit with a shorter \(T_1\) might still have excellent readout, for instance.
Hardware Also Changes Over Time¶
Take one qubit — q(1,1), the center one above — and watch a single metric across a few calibration runs:
This is temporal variation, or drift: a device characteristic measured during one calibration may not remain exactly the same indefinitely. You now have two distinct kinds of variation to track:
| What varies | Example | |
|---|---|---|
| Spatial | Different parts of the device | Qubit A and Qubit B, measured at the same time, have different \(T_1\) |
| Temporal | The same part of the device, over time | Qubit A's \(T_1\) today vs. Qubit A's \(T_1\) last week |
The numbers above are illustrative — how fast (or slowly) any specific metric actually drifts depends heavily on the hardware platform, the metric itself, and the operating conditions. Don't read a universal drift rate into this example.
Calibration and Characterization¶
Quantum hardware must be measured, characterized, and adjusted so that control operations and measurements behave as intended. This is an active, ongoing process — the system doesn't simply possess perfect built-in knowledge of its own physical state.
We won't go into the underlying calibration experiments or device physics here — that's a deeper topic for a future pass. What matters at this level is the shape of the process: measure, estimate, adjust.
What Is Calibration Telemetry?¶
Calibration telemetry is information describing the measured or estimated characteristics of a physical device. Here's a simplified example panel, for the same q(1,1) from above:
| Category | Field | Example value |
|---|---|---|
| Qubit | \(T_1\) | 82 μs |
| Qubit | \(T_2\) | 61 μs |
| Qubit | Frequency | 5.12 GHz |
| Operation | 1-qubit gate error | 0.08% |
| Operation | 2-qubit gate error | 0.6% |
| Measurement | Readout error | 1.7% |
| Context | Qubit ID | q(1,1) |
| Context | Connectivity | 4 neighboring qubits |
| Context | Calibration age | ~3 hours ago |
A few of these, briefly:
- \(T_1\) — how quickly excited-state population tends to relax.
- \(T_2\) — how quickly phase coherence is lost, under the relevant measurement definition.
- Readout error — how reliably the measurement process distinguishes the expected outcomes.
- Gate error / fidelity — how closely an implemented operation matches its intended behavior, under a particular estimation method.
These aren't interchangeable with each other, and none of them is itself a direct probability of every possible physical error.
Warning
These values come from measurements, characterization procedures, and estimation methods. They are not quantities the quantum computer automatically knows exactly.
Main Interactive — Uniform Model vs. Hardware-Informed Model¶
This connects directly back to Minimum-Weight Perfect Matching. Here's a small decoding graph with two candidate explanations for the same detection events: pair A with B, or pair A with C.
The syndrome hasn't changed. What changed is the decoder's model of which error explanations are more plausible — the exact idea from Minimum-Weight Perfect Matching, now with the weight change motivated by (simplified, illustrative) hardware information instead of an arbitrary hypothetical. Real calibration telemetry doesn't automatically or mechanically convert into MWPM weights like this — this is a simplified educational picture of the idea, not a telemetry-processing pipeline.
Telemetry Is Not the Error Model¶
It's tempting to compress the whole idea into one step:
That's too direct. A telemetry value like \(T_1\) is not itself a complete QEC error model — multiple measurements and assumptions are usually needed to characterize the errors relevant to a particular code, circuit, or decoder:
Calibration Information Has Limitations¶
Four worth knowing:
- Measurement uncertainty — calibration values are estimates derived from experiments, not exact readouts.
- Incomplete information — a collection of telemetry metrics doesn't describe every possible hardware error.
- Time dependence — hardware characteristics may change after calibration.
- Model dependence — different QEC or software systems may use hardware information differently.
Is the earlier snapshot still perfectly representative? Not necessarily. This is the idea of calibration staleness — we're not trying to predict how it goes stale here, just to make the concept concrete.
Hardware Information Can Be Used in Different Ways¶
QEC is only one consumer of hardware/device information. Depending on the system, information about hardware behavior can potentially influence:
- control and recalibration
- qubit selection or placement
- compilation
- noise modeling
- decoder weighting
- code or protocol choices
This section has kept the focus on that QEC path, but it's one possible use of device information among several — not its sole purpose, and not all of these uses are equally mature or universally deployed today.
Hardware-Aware QEC Is a Research and Design Space¶
"Hardware-aware QEC" is useful here as an umbrella description for approaches that incorporate information about physical-device behavior into QEC design or operation. It does not refer to one universally standardized QEC architecture.
Different approaches use hardware information for different things:
- decoder calibration or weighting
- adapting to nonuniform noise
- code selection or design
- qubit/layout choices
- exploiting known noise bias or erasure information
- other cross-layer decisions
Some QEC research instead focuses on other aspects of fault tolerance entirely — decoding algorithms, code design, architectures, or hardware itself — without centering device-specific calibration data. Treat hardware awareness as one active research and design direction, not an inevitable final stage every QEC system must reach.
Optional Exploration — Inspect the Device¶
Optional: inspect the device across two calibration snapshots →
The device map above shows spatial variation at a single point in time. This one adds a second calibration snapshot, so you can see spatial and temporal variation together — pick a qubit, then flip between snapshots.
Click a physical qubit, then compare Snapshot A against Snapshot B.
The goal isn't to rank qubits as universally good or bad — it's to make device heterogeneity and drift tangible. Try q(1,1) specifically: it's the one used in the examples earlier on this page, and it's also the qubit that moved the most between these two snapshots.
Takeaway¶
Real quantum hardware does not perfectly match the uniform error models used in introductory examples. Calibration and characterization provide information about device behavior, and some QEC approaches can use that information to build more realistic error models or make hardware-informed decisions.
One important qualification: hardware-aware QEC is not one standardized solution, and not the universally accepted direction of all QEC research. It's a broad, active area exploring how knowledge of physical hardware can inform error correction — among several legitimate directions QEC research takes.
This closes out Module 07's Scaling arc, and with it, the whole module: from a single physical qubit's error, to logical qubits protected across a lattice, decoded, interacting through lattice surgery, and now grounded in the realities of the hardware all of it has to run on.