Why Benchmark

A datasheet for a quantum processor is not a list of promises — it is a list of measured numbers. Before anyone trusts a device to run an algorithm, they must answer a blunt question: how good is it, actually? This module is about the family of experimental protocols that turn that question into quantitative, reproducible numbers. The discipline is called benchmarking and noise characterization, and it sits between the idealized circuits you have written so far and the imperfect hardware that runs them.

The gap between the circuit and the device

Every circuit you compose in this course evolves a perfectly isolated state vector. Real hardware does not. Each physical operation leaks a little: a single-qubit gate might be off by a fraction of a percent, a two-qubit gate by a few percent, a measurement might report the wrong bit once in a hundred shots, and an idle qubit slowly decoheres. These are not bugs to be patched — they are the physics of open quantum systems. The job of benchmarking is to quantify them so that we can predict, compare, and improve.

Three quantities recur throughout the module:

Gate fidelity $F$ : how close a realized operation is to its ideal. A common summary is the average gate fidelity, the overlap between the target and the actual output averaged uniformly over all input states.
Error rate $r = 1 - F$ (the infidelity): the complementary quantity, often quoted per gate.
Effective noise channel: the full description of what the noise does, not just how much — whether it dephases, depolarizes, or relaxes.

Why a single number is hard to get right

It is tempting to benchmark a gate by preparing a known input, applying the gate, and measuring how often the output matches. This naive approach has two fatal flaws.

First, it conflates errors from different sources. The number you measure is contaminated by state-preparation and measurement (SPAM) errors — if you cannot prepare $|0\rangle$ perfectly or read it out perfectly, you cannot tell whether a low score is the gate's fault or the preparation's.

Second, it depends on which input you happened to choose. A gate might be accurate for $|0\rangle$ but poor for $|+\rangle$ . Averaging by hand over many inputs is laborious and still leaves SPAM in the result.

A map of the module

The protocols differ in what they characterize and how much they cost:

Tomography (state and process) reconstructs the full density matrix or channel. It is maximally informative but its cost grows exponentially with the number of qubits, so it is practical only for one or two qubits.
Randomized benchmarking (RB) and its interleaved variant extract a single average error rate per gate, cheaply and SPAM-robustly, by exploiting the structure of the Clifford group.
Cross-entropy benchmarking (XEB) scores how well a device samples from random circuits — the protocol used to claim quantum advantage on near-term processors.
Quantum volume (QV) compresses width and depth into a single holistic figure of merit for a whole device.
Error mitigation (readout correction and zero-noise extrapolation) does not measure noise for its own sake — it uses a characterization to cancel noise from the results of other experiments.

Characterization is the prerequisite for correction

There is a deeper reason to care. Quantum error correction, which you met in earlier modules, only works below threshold — when physical error rates are small enough. You cannot know whether you are below threshold without measuring the error rate, and you cannot decode efficiently without knowing the dominant noise channel. Benchmarking is therefore not a postscript to building a quantum computer; it is the instrument that tells you whether the machine you built can be made to work at all. de Wolf's lecture notes frame the entire fault-tolerance program around an assumed per-gate error rate — benchmarking is how that assumption becomes a measurement.

By the end of this module you will have implemented, on the in-repo simulator, scaled-down versions of tomography, randomized benchmarking, readout correction, and zero-noise extrapolation — and you will have estimated a gate fidelity from benchmark data yourself.