Beyond generic noise. Plaquette simulates the errors that actually dominate on your hardware.
In our overview of design software for large-scale FTQC, we looked at why hardware teams need a tool that understands real physical imperfections, not idealized noise. In this post, we go platform by platform and show how Plaquette captures the platform-specific physics that drives real fault-tolerance performance.
Plaquette is a single library covering codes, error models, samplers, and decoders. You only need to describe your hardware once, and threshold analysis follows without you needing to stitch different tools together. Below, we walk through five representative hardware platforms (superconducting, neutral atoms, trapped ions, spins, and photonic) and show how Plaquette captures the physics that dominates each one. The same approach applies to any platform whose physics you can write down.
Why a platform-accurate simulator matters
Different imperfections act on logical qubits in very different ways. Erasure (e.g. the loss of a qubit to optical loss or atom loss) can be tolerated up to roughly 10% and the logical qubit still works. Dephasing, on the other hand, typically has to be below 1%. Leakage to non-computational states is worse still, and left unmitigated it can spread correlated errors across neighboring qubits. Which imperfection dominates on your platform is what decides your real logical error rate.
Pen-and-paper analysis will not tell you where those thresholds sit for a real device, and a noise model that wasn’t built around your specific hardware will often hide the effects that matter most. To pick the right code, decoder, and qubit control scheme, you need scalable circuit-level simulation, and the error models fed into those circuits have to capture the physics rather than an idealization of it.
Plaquette was built for exactly this. It translates real hardware physics into error models that a fault-tolerance simulator can consume. That holds across the platforms we walk through below and, as the next section explains, for any platform whose physics you can write down.
Bring your own noise
If you already have a noise characterization of your hardware in any of the standard forms, Plaquette can simulate QEC against it. You do not need your noise or even your platform to be one of the examples in the rest of this post.
Plaquette accepts noise in the representations hardware teams already use, including Kraus operators, Pauli transfer matrices, Hamiltonians, and Lindbladians. Defining custom error models from whatever form the customer already has is one of Plaquette’s core strengths. Say a hardware manufacturer has performed gate tomography on their two-qubit gate and has a Kraus representation in hand. They can drop that representation into Plaquette, attach it to the relevant gate locations in a QEC circuit, and run threshold simulations against it the same day.
With that in place, let’s look at what Plaquette captures for five representative platforms.
Superconducting qubits
Superconducting qubits are a mature matter platform with a distinctive set of imperfections: imperfect control pulses, decay and dephasing, leakage out of the computational subspace into higher transmon levels, two-qubit depolarization that often comes with its own leakage channel, and cosmic ray effects that produce spatially correlated burst-like noise events. Each of these is known to affect logical performance differently, and each has its own threshold.
Leakage is the one that most often produces misleading results when not modeled directly. Population that leaves the computational subspace and later returns requires tracking what happens outside the qubit levels, which most simulation approaches don’t handle.
Plaquette’s XPauli simulator is designed for this: inside the computational subspace it uses Clifford simulation, so it stays fast, while population outside that subspace is tracked as a classical jump process that can come back. That lets you include leakage in threshold studies at scale, not just in small full-state simulations.
XPauli discards coherences outside of the computational states. We’ve nevertheless observed that this approximation provides accurate results that match full state simulations for several relevant error models including leakage and heating.
Coherent over-rotation errors, common when a control pulse is slightly too long or too short, can also produce misleading results when the simulation doesn’t account for the coherent nature of the error. Plaquette’s Near-Clifford quasiprobability sampler handles these exactly, and it estimates up front how many shots you need for a given error bar. Near-Clifford sampling is useful when coherent errors cannot be safely Pauli-twirled away. It gives an unbiased estimate for the specified near-Clifford channel, with the expected tradeoff that the shot cost depends on how far the circuit is from Clifford.
The combination of XPauli for leakage and Near-Clifford for coherent errors covers the two failure modes most often baked into a transmon roadmap.
Cosmic ray effects are a different category of imperfection. Plaquette models spatially correlated burst events of the kind triggered by cosmic rays, tracking the full sequence from seeding through spatial spread to collapse and recovery, using the same XPauli sectors that handle leakage.
Support extends beyond transmons to flux-tunable gates and to fluxonium and related modalities, and the library continues to expand.
Neutral atoms
Neutral-atom hardware, of the kind developed by teams such as Yaqumo, trades microwave control for optical control and gains large qubit counts and reconfigurable connectivity in exchange. Its dominant imperfections are Rydberg-state scattering through intermediate levels (for example the 6P state in rubidium), imperfect readout and re-trapping, shot-to-shot control variance from atomic motion, and straightforward atom loss from the tweezer array.
Plaquette captures the CZ-gate physics at the Lindblad level, including scattering through intermediate states, and compiles the result into an XPauli-compatible error model you can use for threshold studies.
Finite Rydberg blockade is handled the same way: Plaquette models the actual blockade dynamics rather than the clean infinite-blockade idealization.
Atom loss where the location of loss is known completely or partially is also addressed. If the space-time location of the loss is known exactly, such an error is modeled directly as an erasure channel. Because erasure is relatively forgiving for QEC (tolerable up to 10% or beyond), modeling it accurately rather than folding it into a simpler approximation can substantially change the architectural choices you make. If the location is known partially, Plaquette can address these errors using the latest methods from leakage-aware decoding (sometimes also called loss-aware decoding).
Trapped ions
Trapped-ion processors earn their reputation on gate fidelity and all-to-all connectivity within a trap. The price is paid elsewhere: two-qubit gates often couple ions through a shared vibrational mode, and heating of that mode is a critical error channel. Shuttling between trap zones introduces distance-dependent errors, including possibly distance-dependent heating, and over-rotation shows up when pulse calibration drifts.
Plaquette models the shared vibrational mode as an ancillary quantum system attached to each ion, which is one of the original motivating use cases for the XPauli simulator. Heating is captured as transitions of that ancillary mode, modeled as part of the physical dynamics rather than approximated after the fact, which matters because heating correlates errors across the ions participating in a gate.
Shuttling errors are supported through a parametric, tag-dependent error model: circuits can be tagged with per-gate distances, and the error channel scales with the tag. Over-rotation from pulse miscalibration is handled by the Near-Clifford sampler, as on other matter platforms.
Teams such as QUDORA and ZuriQ, which builds Penning-trap processors, have adopted Plaquette for their trapped-ion fault-tolerance work.
Spin qubits
Silicon spin qubits (Si/SiGe), donor spins, NV centers in diamond, and carbon nanotube spin qubits such as those built by C12 share a common fault-tolerance structure: leakage out of the computational subspace and decoherence from the local environment.
Left unmodeled, leakage out of the computational subspace is the most likely imperfection to distort simulation results. In silicon spin qubits, for example, valley splitting is a possible cause of this: a low valley splitting places a non-computational valley excited state close to the qubit ground state, where population can leak during gate operations. Plaquette handles leakage through XPauli: fast Clifford simulation inside the computational subspace, with population outside tracked as a classical jump process.
Plaquette also generates hardware-tailored QEC circuits for spin platforms, with native support for the CZ gate set that silicon spin hardware uses.
Photonic quantum computing
Photonic hardware is a different beast. The qubits fly at the speed of light, measurements destroy them, and two-qubit “gates” are inherently probabilistic. That combination means the usual circuit-based picture of fault tolerance does not apply: photonic fault tolerance is instead built on fusion-based quantum computing (FBQC) and measurement-based quantum computing (MBQC), or something in between. The dominant imperfections are optical loss, fusion failures, stray photons, and static fabrication defects.
Plaquette’s photonic tooling is built around these paradigms from the ground up. It models fusion failures and heralded erasure directly, foliates QEC codes into FBQC circuits automatically, and tracks loss as its own channel rather than folding it into a simpler approximation. Because a 10% erasure rate is tolerable where a 1% dephasing rate already hurts, keeping erasure as a distinct channel is a large part of what makes photonic thresholds come out right.
Teams such as Quantum Source have adopted Plaquette for exactly this kind of photonic fault-tolerance design work.
For photonic architectures where quantum dots serve as single-photon emitters, Plaquette also models the imperfections in the photon-generation pipeline itself. Quantum dots generate resource states that photonic FTQC circuits consume, and errors at the dot level, including dephasing during emission and state-generation failures, propagate into those resource states. Plaquette traces that chain from quantum dot physics through to photonic FTQC threshold plots.
From platform physics to design decisions
Once you have a code and a hardware-accurate error model, everything downstream comes together without your team building extra tooling. Plaquette’s simulators, decoders, and threshold analysis share one pipeline, and simulations parallelize across available CPU cores automatically. The same pipeline supports a range of simulators, from Stim and XPauli for large-scale threshold studies to Near-Clifford and full-state CPU or GPU backends for higher accuracy with more complex error types. You describe the hardware once, and the rest of the workflow runs on top of that description.
Concretely, that means you can:
- Run threshold studies to find the code distance your platform actually needs, rather than a distance that happens to work for idealized noise.
- Compare codes and decoders under hardware-accurate noise, so the winner on paper is also the winner on your chip.
- Turn simulation output into hardware specs, informing your engineering team how much logical fidelity can be gained by reducing each imperfection.
This also lets teams explore which trade-offs are optimal for their approach. For example:
- a superconducting team can ask how often it’s best to include possibly imperfect leakage detection units, which can turn leakage into more tolerable erasure errors at the cost of these units adding Pauli noise to the circuit;
- a neutral-atom team can decide whether logical error rates are improved by longer pulses that offer better two-qubit gates or shorter ones that reduce idling errors; or
- a trapped-ion team can ask whether a different shuttling schedule reduces logical error enough to justify added compilation complexity.
Plaquette’s library grows each release. New codes, decoders, error models, and platform support land on an ongoing basis and often in response to direct customer requests, so the set of designs you can evaluate grows with the platform.
Next steps
If you’d like to do a deeper dive into how Plaquette works for your own platform, get in touch and we can share a demo.
Not ready yet? You can also join our practitioners mailing list to be notified when we release new features or publish technical content like this.