Introducing PPVM: A Step Toward a Quantum Digital Twin

Quantum computers are advancing toward utility scale, and fault-tolerant quantum computation (FTQC) is the enabler that will get them there. At that scale, we will need to operate and understand quantum systems of unprecedented complexity. An FTQC system operating with more than 10,000 physical qubits will require highly dynamic operations, some of them asynchronous. Our computational tools must evolve alongside the hardware.

We recently announced our roadmap for a Libra-class machine with 256 logical qubits and more than 10,000 physical qubits. A machine of this scale introduces an entirely new level of complexity, not only in its quantum hardware, but also in its control systems, underlying physics, and computer architecture.

QuEra quantum roadmap

The path to fault-tolerant quantum computing

Launched 2022AquilaNISQ system
Launched 2025GeminiNISQ system & QEC testbed
Launching 2028LibraMegaquop fault tolerant
Coming 2028/29Next GenGigaquop fault tolerant

A simplified view of QuEra’s roadmap, highlighting fault-tolerant milestones.Explore the full, current roadmap

Historically, much of the work on emulating quantum computers has focused on a fundamental question: how many qubits can a classical computer simulate? Tensor-network simulators have, for example, challenged the classical-runtime claims around Google’s Sycamore experiment and surpassed results from IBM’s Eagle kicked-Ising experiment; LOWESA also used Pauli propagation to reproduce the IBM experiment.^[1–4] This challenge has driven important progress in areas such as decision diagrams, ZX calculus, and stabilizer-rank decomposition.^[5–7] For many large-scale circuits, practical simulation has therefore required either approximation or restriction to Clifford operations, supported by specialized tools such as Stim, the de facto tableau simulator for Clifford circuits.^[8] More recently, simulators such as SOFT, Tsim, and Clifft have targeted the near-Clifford regime, incorporating the non-Clifford operations needed to study protocols such as magic-state cultivation.^[9–11]

These methods are valuable for studying quantum circuits and validating claims of quantum advantage. But reproducing an idealized quantum circuit is not enough to understand how a large quantum computer behaves as a complete system. At fault-tolerant scale, quantum operations, noise, atom loss, error correction, and classical control logic all interact.

ControllerCPU · runtime orchestrationCoordinates classical decisions and hardware commands.

OpticsAOD · SLM · lasersRepresents the physical control interface.

QuantumCircuit simulatorModels quantum operations, noise, and measurements.

DecoderDEM · manager · decoding algorithmBuilds the error model, manages decoding, and returns likely corrections.

Traditional simulators stop at the quantum module. A complete machine emulator integrates classical control, optics, quantum execution, DEM management, and a decoder.

We therefore need something broader than a circuit simulator: a digital twin that can reproduce the behavior of the entire system, including its noise, controllers, optics, and classical runtime. Such a model would help us address the practical questions that emerge at this scale: How does active decoding behave on real hardware? Will a decoder remain effective in the presence of atom loss, or can atom loss information even be harnessed to decode better? How does atom loss affect a logical trotter circuit? Our goal is to build this software counterpart of a quantum computer so that we can better understand, develop, and ultimately interact with increasingly complex quantum systems.

Today, we are introducing the first public component of that effort: the Pauli Propagation Virtual Machine (PPVM).

Starting with PPVM

PPVM is a circuit-level virtual machine designed to emulate noisy quantum devices together with the classical controllers that operate them. This combination matters: a large-scale quantum computer is not simply a collection of qubits executing a fixed circuit. Its behavior also depends on classical decisions made during execution: responding to measurements, tracking atom loss, running error-correction procedures, and determining what should happen next. Under the hood, PPVM is not a single simulation method but four: stabilizer tableaus, generalized tableaus, mixtures of tableaus, and Pauli propagation.

Like its name suggests, PPVM is a virtual machine in the traditional sense: it maintains a state that can be manipulated by a set of instructions. What makes it different from a classical virtual machine is that part of its state is quantum, represented by “Pauli” operators (as Pauli sum, generalized tableau or mixture of tableau). It supports familiar classical concepts such as variables, call frames, and control flow alongside quantum operations.

Exact

∣ ψ_{S} ⟩ ⟷ s = ⟨ S ⟩, d = ⟨ D ⟩ \subset P_{n}

	tableau										lost
	d₁	d₂	d₃	d₄	d₅	s₁	s₂	s₃	s₄	s₅	bool
q₀	Pauli Z	identity	identity	identity	identity	Pauli X	Pauli Z	Pauli Z	Pauli Z	Pauli Z	false
q₁	identity	Pauli X	identity	identity	identity	Pauli X	Pauli Z	identity	identity	identity	false
q₂	identity	identity	Pauli X	identity	identity	Pauli X	identity	Pauli Z	identity	identity	false
q₃	identity	identity	identity	Pauli X	identity	Pauli X	identity	identity	Pauli Z	identity	false
q₄	identity	identity	identity	identity	Pauli X	Pauli X	identity	identity	identity	Pauli Z	true

The five-qubit GHZ tableau: one column per generator, one row per qubit, sign bits not drawn. Atom loss adds exactly the last column, here with

q_{4}

gone.

Exact for: Clifford circuits
Cost grows with: Qubits — $O (n^{2})$ memory
Reads out: A bitstring per shot
Atom loss: One bool per qubit

Exact

∣ ϕ ⟩ = α \sum v_{α} d_{α} ∣ ψ_{S} ⟩

	tableau										lost	sparse $v_{α}$ : rows are $d_{1} \dots d_{5}$
	d₁	d₂	d₃	d₄	d₅	s₁	s₂	s₃	s₄	s₅	bool	α⁽¹⁾	α⁽²⁾
q₀	Pauli Z	identity	identity	identity	identity	Pauli X	Pauli Z	Pauli Z	Pauli Z	Pauli Z	false	false	true
q₁	identity	Pauli X	identity	identity	identity	Pauli X	Pauli Z	identity	identity	identity	false	false	false
q₂	identity	identity	Pauli X	identity	identity	Pauli X	identity	Pauli Z	identity	identity	false	false	false
q₃	identity	identity	identity	Pauli X	identity	Pauli X	identity	identity	Pauli Z	identity	false	false	false
q₄	identity	identity	identity	identity	Pauli X	Pauli X	identity	identity	identity	Pauli Z	true	false	false
$v_{α}$												0.924	−0.383i

The same tableau after a

T

q_{0}

: the non-Clifford gate never touches it and writes into a sparse coefficient vector instead, here 2 nonzero entries out of

2^{5}

, indexed over the destabilizers.

Exact for: Any circuit, per shot
Cost grows with: Non-Clifford gates
Reads out: A bitstring per shot
Atom loss: One bool per qubit

Truncated

ρ = k \sum p_{k} ∣ ϕ_{k} ⟩ ⟨ ϕ_{k} ∣

	branches
	k₀	k₁	k₂	k₃	k₄	k₅	k₆	k₇
q₀	identity	identity	identity	identity	identity	identity	identity	identity
q₁	identity	Pauli X	identity	identity	Pauli X	Pauli X	identity	Pauli X
q₂	identity	identity	identity	identity	identity	identity	identity	identity
q₃	identity	identity	Pauli Z	identity	Pauli Z	identity	Pauli Z	Pauli Z
q₄	identity	identity	identity	leakage	identity	leakage	leakage	leakage
$p_{k}$	0.941	0.019	0.019	0.019	0.0004	0.0004	0.0004	0.000008

All eight branches of a circuit with three channels at

p = 0.02

: one clean, three with a single error, three with two, one with everything. Weights multiply, so a cutoff of

C = 1 0^{- 3}

eats the whole tail.

Exact for: Any circuit, untruncated
Cost grows with: Probabilistic ops, magic
Reads out: Bitstrings, one propagation
Atom loss: One bool per qubit, per branch

Truncated

O = j \sum c_{j} P_{j}, P_{j} \in {I, X, Y, Z, L}^{\otimes n}

	terms of $O$
	P₁	P₂	P₃	P₄
q₀	Pauli Z	Pauli Y	leakage	leakage
q₁	identity	Pauli X	identity	identity
q₂	identity	identity	identity	leakage
q₃	identity	identity	identity	identity
q₄	identity	identity	identity	identity
$c_{j}$	0.941	0.019	0.941	0.941

One column per Pauli word. Loss is a level here, not a flag: reset writes the leakage projector

L

into the basis as a fifth character, carrying the coefficient of the word it came from. Only its contribution is small, so the truncation counts

L

s, here at one: a word with

k

of them pays out at the odds of losing

k

atoms at once.

Exact for: Untruncated propagation
Cost grows with: Number of terms
Reads out: Expectation values
Atom loss: $∣ 0 ⟩$ $∣ 1 ⟩$ $∣ L ⟩$ A third level, not a flag

All four run as step-wise algorithms behind the same bytecode, so the machine state stays inspectable at every instruction, and all four carry the noise channels below, each in the way its own representation allows.

Faithful emulation also means faithful noise. PPVM models the error processes that are dominant in neutral-atom hardware, starting with atom loss: independent loss during single-qubit gates, correlated loss when two atoms share an entangling gate, the altered dynamics an atom sees when its partner is already gone, and the reset that returns a leaked atom to the computational subspace.

Select a channel to see how it is modeled. Kraus operators for the loss channels are extracted from full simulations of the underlying atom dynamics.
Channel	Acts on	Parameters
	Single-qubit gates	$p_{0}, p_{1}$
An atom leaks out of the computational subspace into a third state $∣ L ⟩$ at rates $γ_{0}$ and $γ_{1}$ , so $p_{i} = 1 - e^{- γ_{i} t}$ over the operation time. Loss can be state dependent ( $p_{0} \neq = p_{1}$ ), which matters for post-selection bias; the symmetric approximation $p_{0} = p_{1}$ is what Pauli propagation uses.
	Two-qubit gates	$p_{LL}, p_{L Q}$
Two atoms driven through the same entangling gate do not fail independently. PPVM tracks the probability that both are lost ( $p_{LL}$ ) separately from the probability that exactly one is ( $p_{L Q}$ ).
	Two-qubit gates	$p_{L N}$
An atom whose partner was already lost before the gate sees different dynamics than one paired with an atom that is still present, and therefore a different loss probability $p_{L N}$ .
	Reset operations	—
Returns population from $∣ L ⟩$ back to $∣ 0 ⟩$ and leaves the computational subspace untouched, so hardware with loss detection and atom reloading can be emulated end to end.
	Measurement	—
A measurement that reports a lost atom as $∣ 0 ⟩$ rather than flagging it as missing. The same reset channel captures this false detection.
	One- and two-qubit gates	$p_{dpl}$
One- and two-qubit depolarization applied after rotations and entangling gates. Each application inserts three new branches into the propagated observable.
	Anywhere in a circuit	$p_{X}, p_{Y}, p_{Z}$
Bit flip, phase flip, and general Pauli channels; a single bit flip adds one branch. Branch counts stay manageable because branches carrying many errors scale with the product of their probabilities.
	Anywhere in a circuit	${K_{i}}$
Any channel supplied as a set of Kraus operators ${K_{i}}$ , including non-Pauli ones. This is what lets the loss channels above be derived from full AMO simulations of the gate dynamics instead of approximated by Pauli twirls.

That makes it possible to build and explore far more realistic execution scenarios. For example, we have integrated PPVM with deq, Microsoft’s recent QEC decoding system.^[12] In this setup, PPVM runs alongside a control-flow scheduler and real-time decoder, enabling system-level simulation of adaptive, non-Clifford quantum programs.

A magic-state distillation protocol running as a live PPVM emulation. Encoded states feed a Distill round, and the MeasureZ outcome drives a classical branch that repeats the whole block until it succeeds; the quantum operations and the control flow deciding whether to retry are executing in the same virtual machine. Click to interact, then step through a shot with the transport controls. This widget is one view from QEC Studio, where you can build error-correcting codes and analyze the latency of your decoding infrastructure.

Open QEC Studio

PPVM is useful as a standalone tool today, but it also establishes one of the foundations needed for a larger quantum digital twin: before we can construct a faithful software counterpart of a quantum computer, we need a way to represent and execute the interaction between quantum operations, noise, and classical control. PPVM is our first step toward that capability.

Rethinking How We Build Scientific Software

The scale of this ambition also led us to reconsider how scientific software should be built in the age of AI agents. Traditionally, a project like this begins with months spent designing a fast algorithm in theory, followed by more time translating it into code and hand-optimizing details such as memory layout and SIMD behavior. PPVM is one of our first substantial packages built a different way, with an agent-assisted methodology also known as harness engineering.^[13]

The first version of PPVM was built by human engineers in 2025. Rather than optimizing every part of its performance manually, we later developed an agent called autotune, inspired by Andrej Karpathy’s autoresearch experiment.^[14] Its purpose is not simply to generate code: it works within an engineering harness that provides explicit goals, automated evaluation, enforced logic, and persistent state. Within those boundaries, the agent can propose changes, measure their effects, retain useful findings, and continue searching for better implementations.

5.04×faster noisy tableau-sum buildPR #157 32.3%faster MSD samplingPR #49 47%faster branching at 1M coefficientsPR #55 14.6%faster full MSD circuitPR #149

This process produced significant performance improvements over the first, hand-written version of PPVM for all its backends. The chart below runs the same Trotter propagation through PPVM and the four other single-threaded Pauli-propagation engines we know of, on the transverse-field Ising and Heisenberg workloads; the harness diffs every engine’s propagated support term-for-term against PPVM’s before it reports a timing.

Below we show one of the most interesting results: the performance of PPVM’s Pauli propagation backend against existing open-source implementations.

Cross-library Pauli-propagation benchmark

How close does a searched implementation get to hand-tuned C++?

Not a speed claim. Pauli propagation is one of PPVM's four backends, and nobody hand-tuned it: autotune searched its memory layout, hashing and vectorization. Against monoprop, hand-written C++, that costs 3.1× on Ising and 1.9× on Heisenberg.

Trotter propagation, single-threaded on one Apple M4 Pro. Lower is faster; the logarithmic time axis is shared by both panels. Hover or focus a panel for exact times.

† monoprop and Qiskit's pauli-prop prune each term as it is created, a different approximation, so neither is a like-for-like curve. The section folded in below plots where the two rules come apart.

PPVM
monoprop^†
pauli-prop (Qiskit)^†
PauliPropagation.jl
PauliStrings.jl

Transverse-field Ising — magnetization

64 qubits

PPVM143 ms

monoprop46.9 ms

pauli-prop (Qiskit)817 ms

PauliPropagation.jl1.61 s

PauliStrings.jl1.88 s

Isotropic Heisenberg — autocorrelator

14 qubits

PPVM6.09 s

monoprop3.27 s

pauli-prop (Qiskit)5.33 s

PauliPropagation.jl13.6 s

PauliStrings.jl43.2 s

Accuracy — where the two truncation rules actually diverge

A Pauli rotation sends Q → cos θ·Q + sin θ·(iPQ), so every word receives at most two contributions: itself, scaled by cos, and its partner, scaled by sin. PPVM thresholds the sum; monoprop and pauli-prop threshold each contribution as it is emitted. The consequence is sharp: they drop a child whenever |c|·sin θ < atol even though its parent survives, so they lose every child of a parent in the band atol < |c| < atol/sin θ, a band whose width is 1/sin θ, set by the rotation angle alone.

Seeing that cost the difference needs three things at once: small angles to widen the band, depth to populate it, and a circuit with no lattice and no conserved quantity, so the loss shows up in the answer instead of averaging out. The first two panels are that instance at two angle scales, five circuit seeds each, median line with a min-to-max band: 8 qubits, random all-to-all two-qubit rotations, the Z₀ autocorrelator. The third is the Trotter circuit the timing panels above measure, at the same width and the same observable, which has none of the three and is the control. Everything is diffed against an untruncated reference propagation of the same circuit (atol = 1e-16), and the vertical axis is the L2 norm of the coefficient error over it, so it weighs the whole propagated operator rather than a single expectation value.

PPVM
monoprop
pauli-prop (Qiskit)^‡

Scramble, small angles — 3,200 rotations, θ ≤ 0.1

Threshold |c| < 1e-5 · monoprop 2.43× PPVM

PPVM8.0e-3 · 65,376 terms

monoprop1.9e-2 · 65,378 terms

Scramble, large angles — 80 rotations, θ ≤ π/2

Threshold |c| < 1e-5 · monoprop 0.85× PPVM

PPVM1.0e-3 · 65,366 terms

monoprop9.6e-4 · 65,362 terms

Heisenberg Trotter — nearest-neighbour, uniform angle

Threshold |c| < 1e-7

PPVM1.5e-5 · 16,377 terms

monoprop1.5e-5 · 16,558 terms

pauli-prop (Qiskit)3.0e-5 · 16,528 terms

‡ The Trotter panel is the control, and it is close to a null result: monoprop lands within 7% of PPVM at every threshold, and PPVM, PauliPropagation.jl and PauliStrings.jl agree to 13 digits and share that violet line exactly. Only pauli-prop separates, at 1.2–2.0×, and it has no scramble runner so it appears on this panel alone. TFIM behaves the same way and is not plotted; its numbers are in the harness CSV.

At small angles the gap is real and it is systematic: monoprop carries 2.96× PPVM's coefficient error at 1e-4 (2.90–3.06× across the five seeds) and 2.43× at 1e-5, with the two engines holding supports that differ by less than 0.1%. Nothing is hiding in the seed band on that panel; it is narrower than the lines are thick, which is the point. That is the rejection band being populated and compounded over 3,200 gates, not a difference in how much state each keeps. Read the 1e-3 column as a floor rather than a result: both engines are at ‖Δc‖₂ ≈ 0.95 out of a total norm of 1, holding about 7,300 of 65,535 words, so the operator is gone for both and the ratio there means nothing.

The middle panel is the one that catches people out: large angles favour monoprop, by 1.06–1.18× (median ratios 0.96, 0.89 and 0.85 as the threshold tightens). At θ = π/4 the rejection band is only 1.41× wide, the narrowest it can be, and this is where PPVM's own rule has its failure mode, since truncating after each gate permanently deletes a term whose merged coefficient has transiently cancelled below the threshold, where monoprop keeps the row and lets a later gate revive it. Flat amplitudes and a wide band are mutually exclusive: you only get the band from small angles, and small angles force the geometric spread that makes amplitudes non-uniform.

Neither engine's error can run away from the other's, though. A sum of two terms exceeds its larger member by at most 2×, so the mass PPVM rescues is O(atol) per word: both errors are anchored to the same threshold, and driving atol low enough that PPVM is accurate makes monoprop accurate too. And none of this is visible in the observable: at a fixed 1e-4 on the small-angle circuit PPVM's own autocorrelator error ranges over two decades across the five seeds, from 7.2e-6 to 2.1e-3, because a single scalar's truncation error changes sign. On the Trotter panel it misleads in the other direction: at 1e-6 the monoprop autocorrelator lands 1.9e-9 from exact against 1.9e-7 for PPVM, two decades better than its coefficients are, and 1e-13 for the two Julia engines is a forgiving observable, not matching operators. Compare coefficient vectors, not readouts.

Show every number

Scramble, small angles — 3,200 rotations, θ ≤ 0.1 — 8 qubits, 400 steps, dt = 0.05, observable `Z₀`, reference 65,535 terms carrying ‖c‖₂ = 1, median of 5 seeds
Threshold	Engine	Terms	Coefficient error ‖Δc‖₂	‖Δc‖₂ across seeds	Observable error \|Δ⟨O⟩\|
1e-3 1.02×	PPVM	7,277	9.5e-1	9.5e-1–9.6e-1	6.4e-3
1e-3 1.02×	monoprop	8,026	9.7e-1	9.6e-1–9.7e-1	2.0e-2
1e-4 2.96×	PPVM	63,904	1.4e-1	1.4e-1–1.4e-1	6.5e-4
1e-4 2.96×	monoprop	63,950	4.2e-1	4.1e-1–4.2e-1	4.2e-3
1e-5 2.43×	PPVM	65,376	8.0e-3	7.8e-3–8.7e-3	2.6e-5
1e-5 2.43×	monoprop	65,378	1.9e-2	1.9e-2–2.0e-2	9.8e-5

Scramble, large angles — 80 rotations, θ ≤ π/2 — 8 qubits, 10 steps, dt = π/4, observable `Z₀`, reference 65,535 terms carrying ‖c‖₂ = 1, median of 5 seeds
Threshold	Engine	Terms	Coefficient error ‖Δc‖₂	‖Δc‖₂ across seeds	Observable error \|Δ⟨O⟩\|
1e-3 0.96×	PPVM	46,519	2.5e-1	1.5e-1–3.1e-1	9.2e-4
1e-3 0.96×	monoprop	47,075	2.4e-1	1.4e-1–2.7e-1	5.0e-4
1e-4 0.89×	PPVM	63,800	1.7e-2	1.5e-2–1.7e-2	1.4e-5
1e-4 0.89×	monoprop	63,817	1.4e-2	1.3e-2–1.6e-2	5.6e-5
1e-5 0.85×	PPVM	65,366	1.0e-3	8.2e-4–1.2e-3	6.5e-7
1e-5 0.85×	monoprop	65,362	9.6e-4	6.3e-4–9.7e-4	1.7e-6

Heisenberg Trotter — nearest-neighbour, uniform angle — 8 qubits, 10 steps, dt = 0.1, observable `Z₀`, reference 16,384 terms
Threshold	Engine	Terms	Coefficient error ‖Δc‖₂	Observable error \|Δ⟨O⟩\|
1e-3	PPVM	4,566	1.9e-1	7.9e-4
	monoprop	5,106	1.9e-1	6.2e-4
	pauli-prop (Qiskit)	5,072	2.4e-1	2.5e-3
1e-4	PPVM	11,923	2.6e-2	1.1e-4
	monoprop	13,143	2.7e-2	4.1e-5
	pauli-prop (Qiskit)	13,628	4.5e-2	6.8e-5
1e-5	PPVM	16,101	2.4e-3	2.3e-6
	monoprop	17,223	2.6e-3	2.3e-6
	pauli-prop (Qiskit)	17,803	4.5e-3	3.0e-6
1e-6	PPVM	16,324	1.9e-4	1.9e-7
	monoprop	16,910	2.0e-4	1.9e-9
	pauli-prop (Qiskit)	17,004	3.8e-4	4.3e-8
1e-7	PPVM	16,377	1.5e-5	6.9e-9
	monoprop	16,558	1.5e-5	4.3e-10
	pauli-prop (Qiskit)	16,528	3.0e-5	1.9e-9

Run details — machine, versions, protocol

Machine: Apple M4 Pro (Mac16,7), 10 performance + 4 efficiency cores, 48 GB unified memory, macOS 26.6 (build 25G72), otherwise idle.
Threads: Single-threaded end to end: PPVM is built without Rayon, Julia runs under julia -t1, and pauli-prop is single-threaded by design.monoprop is the one that has to be held down: left alone it takes one serial partition per physical core, which reports a wall time about 3× faster than its serial one on this machine, so it runs under monoprop_NUM_THREADS=1 and monoprop_PARTITIONS=off. Because those are read once into a cached C++ static and go stale silently, its runner also measures its own CPU-per-wall-second around the timed region and fails the run if the cap did not take; every point here reported 1.00. No engine is given more cores than another.
Engines: PPVM ppvm-pauli-sum 0.1.0, release build, rustc 1.96.0 · monoprop 0.8.0 (Algorithmiq; C++ with Python bindings) · PauliPropagation.jl 0.7.3 and PauliStrings.jl 1.10.1, both on Julia 1.12.6 · pauli-prop 0.2.0 on Qiskit 2.5.1.
Workload: 10 first-order Trotter steps, dt = 0.1, J = 1, h = 1, truncation |c| < 1e-6. TFIM sweeps 8 → 64 qubits with observable Σᵢ Zᵢ; Heisenberg sweeps 6 → 14 qubits with the Z₀ autocorrelator.
Timing: Two timed repeats per point, the minimum reported. Julia is timed after a warm-up call so JIT compilation is excluded, and circuit construction sits outside the timed region for every engine.
Agreement check: Every engine runs the same gate list in the same order, and before any timing each one dumps its whole propagated support at n = 4, steps = 3, atol = 1e-14, a threshold small enough that the two pruning rules coincide. The driver diffs that support term-for-term against PPVM's and aborts on any missing or extra term, or any coefficient off by more than 1e-10. At the benchmark's own threshold the three accumulate-then-truncate engines still match exactly, and the Terms column below is that shared support. The two branch-pruning engines diverge from it in both directions: pauli-prop runs 11–36% under it on TFIM, the gap widening with the register, and up to 15% over it on Heisenberg; monoprop stays within 1% on TFIM and runs up to 12% over on Heisenberg.
Engine caveats: monoprop keeps monomials whose coefficient has cancelled to exactly zero, so it tracks more rows than it reports: 7,355,928 at Heisenberg n = 14 against the 3,204,697 terms it holds above threshold. It and PPVM are therefore not making the same space/time trade. It also takes a mandatory Pauli-weight cutoff, set to the whole register here so that it never binds. pauli-prop has a mandatory max_terms cap, set to 2²²; the harness fails the run if the support ever reaches it, rather than quietly reporting a differently-truncated number.
Source: Harness, per-engine runners and the raw CSV live in benchmarks/cross-library.

Show every number

Transverse-field Ising — magnetization
Qubits	Terms	PPVM	monoprop	pauli-prop (Qiskit)	PauliPropagation.jl	PauliStrings.jl
8	4,701	2.83 ms	2.77 ms	31.5 ms	6.84 ms	13.9 ms
16	19,529	12.2 ms	8.45 ms	67.6 ms	37.8 ms	76.5 ms
24	34,353	26 ms	14 ms	138 ms	150 ms	209 ms
32	49,177	43.1 ms	19.4 ms	304 ms	215 ms	362 ms
40	64,001	65.7 ms	28.3 ms	347 ms	416 ms	604 ms
48	78,825	89.9 ms	35.5 ms	482 ms	658 ms	811 ms
56	93,649	119 ms	41.3 ms	633 ms	1.24 s	1.17 s
64	108,473	143 ms	46.9 ms	817 ms	1.61 s	1.88 s

Isotropic Heisenberg — autocorrelator
Qubits	Terms	PPVM	monoprop	pauli-prop (Qiskit)	PauliPropagation.jl	PauliStrings.jl
6	1,022	2.75 ms	2.83 ms	13.8 ms	11.8 ms	18.6 ms
8	16,324	50.5 ms	42.1 ms	102 ms	173 ms	316 ms
10	225,353	529 ms	408 ms	797 ms	1.64 s	3.59 s
12	1,174,849	2.75 s	1.84 s	3.12 s	7.12 s	17.9 s
14	2,915,879	6.09 s	3.27 s	5.33 s	13.6 s	43.2 s

No human hand-picked PPVM’s memory layout, its hashing strategy, or where it vectorizes. autotune searched for those decisions in a few long-running iterations, and the harness timed, validated, and rejected candidates on its own, where the usual route is months of manual optimization, is the result worth reporting.

The agent also discovered implementation strategies human engineers could inspect, test, and keep. Faster code is not automatically correct code, though, so PPVM uses theorem provers in its harness as well: during a recent refactor we formalized core concepts such as Pauli propagation and generalized tableaus, and those definitions caught correctness bugs and now guard the implementation as it evolves. From what we have learned so far, the formalism is a lot more important than the implementation itself: formalism defines the search space of agents, once formalism is in place, the agent can explore the space and find the best possible implementation.

This is an early shift in methodology. Think of an agent as a new stage in the compiler: a traditional compiler lowers formal language to assembly, and an agent lowers natural language to formal language. That moves the human work to the front of the pipeline: working out the algorithm and building the harness that judges the output. Harness engineering is a new kind of engineering, and in our experience it does not only make scientific software faster to build. It makes the software better. The implementation strategies autotune kept are ones we had not thought to try, and the formal definitions we wrote to keep it honest are now permanent guardrails on the code.

Summary

PPVM is the first public component of our quantum digital twin effort. It gives us a foundation for studying how quantum hardware and classical control interact as these systems grow in scale and complexity. It is also our first substantial test of an agent-assisted methodology for developing scientific software. The experience has already changed how we think about performance optimization, correctness, and the role of human engineers in the development loop.

We hope that PPVM does not only help the community understand the behavior of large-scale quantum computers, but also convey a new direction of circuit emulation towards realistic hardware emulation and a new methodology for building scientific software in the age of AI agents.

PPVM · Python and Rust

Start building with PPVM

Explore the quick start, hardware-aware noise models, developer guide, and API reference.

Read the documentation

Discuss These Ideas at CEVNAC 2026

These challenges extend well beyond any one project. The Compilation, Emulation and Verification of Neutral Atom Computing (CEVNAC 2026) workshop will bring researchers and developers together to discuss open problems across compilation, realistic emulation, programming languages, and formal verification. The workshop is co-located with IEEE Quantum Week 2026 in Toronto.

Authors

Xiu-Zhe Luo, David Plankensteiner, Rafael Haenel, Kai-Hsin Wu, Neelay Fruitwala, Alexander Schuckert, Oriol Rubies-Bigorda, Refaat Ismail, Stefan Ostermann, and Shengtao Wang

Acknowledgements

We thank Manuel Rudolph, Tyson Jones, Danylo Lykov, and Chen Zhao.

@misc{luo2026introducing,
  author         = {Xiu-Zhe Luo and David Plankensteiner and Rafael Haenel
                    and Kai-Hsin Wu and Neelay Fruitwala
                    and Alexander Schuckert and Oriol Rubies-Bigorda
                    and Refaat Ismail and Stefan Ostermann
                    and Shengtao Wang},
  title          = {Introducing {PPVM}: A Step Toward a Quantum Digital Twin},
  howpublished   = {Bloqade blog, QuEra Computing},
  year           = {2026},
  month          = {aug},
  url            = {https://bloqade.quera.com/blog/introducing-ppvm-a-step-toward-a-quantum-digital-twin/},
}

References

C. Huang et al., “Classical Simulation of Quantum Supremacy Circuits,” arXiv:2005.06787 (2020). ↩
F. Pan and P. Zhang, “Simulation of Quantum Circuits Using the Big-Batch Tensor Network Method,” Physical Review Letters 128, 030501 (2022). ↩
J. Tindall, M. Fishman, E. M. Stoudenmire, and D. Sels, “Efficient Tensor Network Simulation of IBM’s Eagle Kicked Ising Experiment,” PRX Quantum 5, 010308 (2024). ↩
M. S. Rudolph, E. Fontana, Z. Holmes, and L. Cincio, “Classical Surrogate Simulation of Quantum Systems with LOWESA,” arXiv:2308.09109 (2023). ↩
R. Wille, S. Hillmich, and L. Burgholzer, “Tools for Quantum Computing Based on Decision Diagrams,” ACM Transactions on Quantum Computing 3(3), Article 13 (2022). ↩
M. Sutcliffe and A. Kissinger, “Fast Classical Simulation of Quantum Circuits via Parametric Rewriting in the ZX-Calculus,” EPTCS 426, 247–269 (2025). ↩
S. Bravyi et al., “Simulation of Quantum Circuits by Low-Rank Stabilizer Decompositions,” Quantum 3, 181 (2019). ↩
C. Gidney, “Stim: A Fast Stabilizer Circuit Simulator,” Quantum 5, 497 (2021). ↩
R. Li et al., “SOFT: A High-Performance Simulator for Universal Fault-Tolerant Quantum Circuits,” arXiv:2512.23037 (2025). ↩
R. Haenel, X.-Z. Luo, and C. Zhao, “Tsim: Fast Universal Simulator for Quantum Error Correction,” arXiv:2604.01059 (2026). ↩
B. A. Chase and F. Labib, “Clifft: Fast Exact Simulation of Near-Clifford Quantum Circuits,” arXiv:2604.27058 (2026). ↩
Microsoft, “deq: a dynamic and generic QEC decoding system,” Quantum Development Kit for Error Correction, GitHub repository. ↩
R. Lopopolo, “Harness Engineering: Leveraging Codex in an Agent-First World,” OpenAI Engineering (2026). ↩
A. Karpathy, “autoresearch,” GitHub repository (2026). ↩