New Technique: benchmarked noise ZNE

[natestemen]

What is bnZNE?

bnZNE (benchmarked noise ZNE) is a recently proposed technique (https://arxiv.org/abs/2603.10224) that avoids the core assumption of standard ZNE that noise can be artificially scaled by a known factor. Instead it directly measures device noise at execution time using benchmark circuits.

It works in three steps:

1. Generate benchmark circuits from the application circuit $C$. Two approaches:
   • Hardware-agnostic: express each gate in the circuit as a Pauli rotation $R_P(\theta)$, randomly reassign Pauli angles to Clifford values, and add a correction layer (at the end?). The benchmark circuit is classically simulable but must transpile to the same native gate sequence as $C$ (not clear to me how this works).
   • Hardware-tailored: substitute equal-error native gates. On IBM Heron for example: replace $\sqrt{X}$ with $X$, which are implemented by equal-duration pulses. The result is classically simulable and shares $C$'s native gate structure by construction.
2. Characterize device noise by running the benchmark circuits and comparing measured outputs to their known ideal values.
3. Perform ZNE extrapolation using the measured noise characterization rather than an assumed noise model.

Why a separate module (at least at first)?

My main concern is API complexity. execute_with_zne is already fairly involved with many moving parts (noise scaling method, extrapolation factory, etc.), and bnZNE would add several tightly coupled new parameters. E.g. a method generate_benchmark_circuit, which has its own configuration space (method choice, gate substitution rules, transpilation constraints). Before we understand the full shape of the interface it seems premature to "fold" it into the existing signature.

The other issue is that benchmark circuit generation is fundamentally backend-specific. Unlike noise scaling (e.g. fold_gates_at_random), which is a structural transformation that works on any circuit, generating valid benchmark circuits requires knowing which native gates are available. Mitiq can't derive that from the circuit alone and needs information about the users backend. So there's no sensible universal default; every backend needs its own generator. A standalone module makes that "bring your own generator" contract more explicit than a flag on execute_with_zne would.

Proposed initial scope

• mitiq/experimental/bnzne/ with a standalone execute_with_bnzne entry point
• IBM Heron hardware-tailored benchmark generator
• Once stable, revisit whether it makes sense to surface this as flag/kwarg within execute_with_zne

References

Paper: https://arxiv.org/abs/2603.10224
Implementation: https://github.com/joeharrisuk/qem-bias-mitigation

---

cc @livelyke @joeharrisuk — is my description of the technique accurate? Anything important I left out? Any design decisions from your implementation we should know about before scoping this out?

[joeharrisuk]

Many thanks @natestemen for the summary.

I think the implementation of this technique into Mitiq can be heavily simplified versus what we have in our codebase. In particular, the hardware-agnostic method introduces a lot of overhead and can probably be ignored here. Instead, I think it would be better (at least for now) to just generate benchmark circuits via direct gate replacements or any other user-specified method. Also, a lot of our code deals with external things like the choice of fitting method or Pauli twirling, dynamical decoupling, TREX, etc. which I don't think are needed here.

Hence, I propose something along the following lines:

1. Alongside the usual ZNE options, the user inputs:
   • Their target application circuit $A$, assumed to be written in terms of the hardware's native gates.
   • A dictionary specifying the gate replacements required to generate the benchmark circuit $B$ (or just a function for generating $B$ from $A$).
   • A function which takes the generated benchmark circuit and returns the ideal value of $\langle O \rangle_B^{exact}$ (usually $=\pm 1$) for the benchmark circuit.
   • (We should also try to do deal with the last two points automatically if $A$ matches a particular gate set, e.g. [CZ, $R_Z$, $X$, $\sqrt{X}$].)
2. Run the noise-scaled circuits $A(r), B(r)$ through the usual execute function.
3. For each noise-scaled benchmark circuit, calculate the associated error rate $\varepsilon(r) = 1 - \langle O \rangle_{B(r)}^{noisy} / \langle O \rangle_{B(r)}^{exact}$. This is slightly different to how we define the error rate in the paper, but circumvents requiring the user to provide raw counts information or measure observables other than $O$.
4. Extrapolate the values $(\varepsilon(r), \langle O \rangle_{A(r)}^{noisy})$ to $\varepsilon = 0$ and return the result.

As you mentioned, this necessarily demands a fair amount more from the user compared to standard ZNE. Depending on which gate sets are commonly used, it might be possible to cover many use-cases automatically, but there's no getting around the necessity for an option where the user can specify this themselves.

Another important point (from a user's perspective) is that there should be no further gate simplification steps within execute, since we need everything to match between the two kinds of circuit.

Would be interested to hear your thoughts @livelyke @natestemen :)