Case Study 2: The Dial That Deleted the Circuit

The reasoning

A team is running a QFT-based subroutine and it is not surviving the hardware. They have done the sensible things: level 2 transpilation, a good layout (Chapter 12), readout mitigation (Chapter 13). The circuit still comes back as noise.

Then someone finds approximation_degree in the transpiler documentation. It synthesizes two-qubit blocks to approximate rather than exact unitaries, trading fidelity for gate count.

The reasoning is genuinely good, and worth stating carefully because it is correct:

Our circuit already loses most of its fidelity to noise. If we can give up 1% of algorithmic fidelity to remove 20% of the two-qubit gates, we come out ahead — the gates we removed were costing us more than 1%.

That is the right trade to be thinking about. Chapter 28 §28.3 measured the circuit retaining ~13% of its noiseless signal, so 1% of algorithmic fidelity is cheap by comparison.

They set approximation_degree=0.99, observe the gate count drop, and ship it.

What 0.99 means

Not 99% fidelity.

Measured on a 5-qubit backend, where the operator is small enough to check:

   approximation_degree   2q gates   depth   process fidelity
                    1.0         19      36           1.000000
                   0.99         15      29           0.925328
                   0.95          8      13           0.657023
                    0.9          0       3           0.455317
                    0.8          0       3           0.455317
                    0.5          0       3           0.117562

approximation_degree=0.99 produced a circuit with 92.5% fidelity, not 99%.

The parameter is a knob on the synthesis routine's internal tolerance, not a specification of the output fidelity. The relationship between them depends on the circuit — how many two-qubit blocks there are, and how much each one can be simplified. It is not a contract.

And it falls off a cliff

Read rows three and four.

                   0.95          8      13           0.657023
                    0.9          0       3           0.455317

At approximation_degree=0.9, the QFT has zero two-qubit gates.

The entire entangling structure has been synthesized away. What remains is a depth-3 circuit of single-qubit rotations with 46% overlap with the operation you asked for. It runs beautifully on hardware — no two-qubit gates to fail — and computes something that is not a QFT.

This is the failure mode that makes the parameter dangerous rather than merely imprecise. A dial that degrades smoothly is manageable; one that goes from "8 two-qubit gates" to "none at all" between 0.95 and 0.9 is a trapdoor. And the circuit that comes out the other side is not obviously broken — it is shallower, faster, and higher-fidelity against the noise model. Every hardware-facing metric improves.

Why nobody caught it

Two reasons, and the second is the interesting one.

First, their validation compared hardware output against simulated output of the same transpiled circuit. Both used approximation_degree=0.99. The comparison agreed beautifully, because both sides were computing the same wrong thing. This is Chapter 27's oracle problem: they had a reference and it was the wrong reference. The comparison must be against the logical circuit, not against a simulation of the approximated one.

Second, and this is the structural problem: on their real 127-qubit backend, the fidelity column above cannot be computed at all.

   Operator.from_circuit(transpiled):  ValueError: Maximum allowed dimension exceeded
   2^127 = 1.7e38 amplitudes

Chapter 26 §26.7's wall. The check that would have caught this is impossible on the device they were targeting. So the parameter is exposed on every backend, and it is verifiable on almost none of them.

What they should have done

Do the approximation study on a small backend.

   1. Transpile the same logical circuit to a 5-qubit fake backend.
   2. Sweep approximation_degree and MEASURE the process fidelity at each.
   3. Pick a setting from the measured curve, not from the parameter's name.
   4. Apply that setting on the real backend.

The setting transfers; the verification does not. That is an awkward workflow and it is the only one available.

The project module makes the refusal structural:

if backend.num_qubits > limit:
    raise ValueError(
        f"refusing to sweep approximation_degree on a {backend.num_qubits}-qubit "
        f"backend: the fidelity you are trading away cannot be computed there. "
        f"Do the study on a small backend, then apply the chosen setting."
    )

Never trade away a quantity you are not measuring. If the measurement is impossible where you are, go somewhere it is possible.

When the trade is right

The team's original reasoning was sound, and it is worth rescuing.

At approximation_degree=0.99: fidelity 0.925, two-qubit gates 19 → 15. Against a noise model where each two-qubit gate costs ~0.8%, removing four of them buys roughly 3% of surviving amplitude, and costs 7.5% of algorithmic fidelity. On these numbers, it is a net loss — but the arithmetic is close, it depends entirely on the circuit and the device, and on a deeper circuit with worse gates it would flip.

That is an empirical question with an empirical answer. The answer requires the fidelity column, which requires a small backend, which is the whole point.

The lessons

A parameter's name is not its semantics. approximation_degree=0.99 gave 0.925. Read the measurement, not the number you typed.

Check for cliffs, not just slopes. Sweeping 1.0 → 0.99 → 0.95 suggests a gentle trade. The next step down removes the circuit. Sample the parameter range widely enough to find the discontinuity before it finds you.

Validate against the logical circuit, never against a simulation of the transformed one. Both sides computing the same wrong thing is the most convincing kind of agreement.

When verification is impossible at your target size, do it at a size where it is possible. Chapter 26's $2^{127}$ wall does not excuse skipping the check; it dictates where the check happens.

And notice this is the third chapter in a row where the mistake was reporting a number that was easy to obtain instead of the one that answered the question. Chapter 25's improvement factor instead of a breakeven. Chapter 27's tolerance without a detection threshold. Here, a parameter value instead of a measured fidelity.

Reproduce it: approximation_sweep in code/vqelab/optimization.py measures the fidelity column and refuses to run on a backend where it cannot; test_approximation_degree_is_not_a_fidelity and test_approximation_degree_falls_off_a_cliff in code/project-checkpoint.py assert both failures.