Research

The software between an algorithm and a noisy device.

We spend most of our time on three questions: how to compile a circuit for a machine it was never written for, how to simulate it honestly, and how to read a trustworthy number out of a noisy one. Below are the areas we work in, and the lab notes we write as we go.

Research areas

Four lines of work, one theme.

01 · CIRCUIT TRANSPILATION

Compiling for a real machine

Every backend has a fixed qubit topology and a small native gate set. Transpilation is the art of rewriting a logical circuit — gate decomposition, qubit mapping, SWAP routing, scheduling — into the shortest physical circuit that computes the same thing, with the same answer, on hardware that can actually run it.

gate decompositionSWAP routingqubit mapping
02 · ERROR MITIGATION

Reading past the noise

Without fault tolerance, every expectation value is biased by gate and readout error. We study methods that trade classical sampling for less bias: zero-noise extrapolation, Pauli twirling, and readout correction — and, just as importantly, the regimes where each one quietly stops working.

ZNEPauli twirlingreadout correction
03 · SIMULATION

Honest classical surrogates

A statevector simulator for the small circuits you can afford to store, a density-matrix simulator for the noisy ones, and tensor-network methods for the shallow, wide ones in between. The point is to model decoherence well enough to test a mitigation strategy before you spend device time.

statevectordensity matrixdecoherence
04 · FAULT TOLERANCE

The surface code, plainly

The surface code is where most error correction is heading. We work on the software side — stabilizer measurement, decoding, and how a logical circuit maps onto a patch — and on explaining it well enough that a newcomer can follow the argument end to end.

surface codestabilizersdecoding
Lab notes

What we're working through.

Dated notes, written for ourselves and published for anyone else. Not every one resolves cleanly — several end in an open question.

2026-08-19note 10

Trotter error is not the whole story

When you simulate a Hamiltonian with a Trotter decomposition, the step size is usually chosen to control the state error. But most experiments measure a specific observable, and that observable's error can be far smaller — or far larger — than the state's. We're reworking the step-size heuristic to match the observable you actually read out, not the one you can compute.

simulation · observables
2026-08-04note 09

SWAP routing on sparse connectivities without a cost model

Most routers rank candidate SWAP insertions with a heuristic that assumes a uniform error model. On a sparse connectivity that assumption breaks first. We're looking at routing directly against a device's measured gate-error profile, and the surprising result that greedy depth-minimization is not always the best proxy for fidelity.

transpilation · routing
2026-07-02note 08

Zero-noise extrapolation, sparsely

ZNE scales noise by boosting gate count and extrapolating back to zero. Each noise level costs real sampling budget. We're mapping how few levels you can get away with before the extrapolation error dominates the bias you set out to remove — and the answer is lower than the folklore suggests.

error mitigation
2026-06-17note 07

Pauli twirling, and the noise it can hide

Pauli twirling converts coherent errors into stochastic ones, which are easier to model. But the twirl changes the noise you measure, and not always in a way that matches the noise your application will actually see. We're cataloguing the cases where the twirled model is the wrong thing to trust.

error mitigation
2026-05-27note 06

A cheaper fidelity estimate for compiled circuits

Estimating the success probability of a compiled circuit usually needs a reference-state reconstruction, which is expensive. We're testing a shortcut that estimates fidelity from the same samples you'd take anyway — useful when you just want to know whether the compiler helped.

transpilation · benchmarking
2026-05-09note 05

Decomposing multi-controlled gates into the native set

An n-controlled gate does not exist natively on any machine we target, so it must be decomposed into single-qubit rotations and CNOTs. The textbook construction is correct but wasteful; we're comparing the ancilla-free and ancilla-assisted decompositions head-to-head on depth and gate count.

gate decomposition
2026-04-14note 04

Readout correction on a budget

Readout error — measuring a |1⟩ as |0⟩ or vice versa — can be corrected with a calibration matrix, but calibrating every qubit is costly and the matrix drifts between runs. We're looking at how much correction you keep if you calibrate a subset and interpolate the rest.

readout · mitigation
2026-03-30note 03

Why decoherence isn't a single timescale

"T₂" gets quoted as one number, but decoherence is a spectrum of processes — amplitude damping, dephasing, leakage — each with its own rate. We're working through what a simulator has to model to reproduce an observed decay curve, and what it can safely ignore.

simulation · noise
2026-02-19note 02

Statevector simulation: what fits, what doesn't

A statevector of n qubits is 2ⁿ complex amplitudes. The memory wall is real, but the practical limits are softer than the asymptotic ones. We're benchmarking how far a single machine gets — and where the density-matrix and tensor-network methods take over.

simulation · statevector
2026-01-28note 01

The surface code, drawn for newcomers

The surface code is usually introduced through its stabilizers and syndromes, which is correct but opaque. We're writing an introduction that starts from the geometry — a grid of data and ancilla qubits — and builds the X and Z stabilizers up from there.

fault tolerance · surface code