What a Non-Clifford Circuit Taught Us About Fault Tolerant Control 

How a simple factoring algorithm helped us understand the requirements for real-time quantum computing 

A few years ago, toward the end of 2023, many of the pieces of fault-tolerant quantum computing (FTQC) were already in place, at least in outline. From a quantum control perspective, we knew that Quantum Machines’ control platform would play a central role in minimizing physical error rates through precise control, calibration, and hardware optimization of stabilizer sequences. We also knew that non-Clifford gates, the ones that enable quantum advantage, would require decoding-dependent feed-forward operations with high decoding throughput and low latency.  

What we didn’t know was perhaps a more basic question: what exactly should we build to support the next era of fault-tolerant quantum computation? 

But we weren’t after another million-qubit resource estimate. We wanted something concrete enough to build. So, we broke the high-level resource questions down into operational ones. What does an actual fault-tolerant computation look like, step by step? What data flows through the system, and when? And how fast does decoding really need to be? 

To answer these questions, we took a small-scale non-Clifford circuit and followed it  all the way down. From the logical level, through the surface-code layer, to physical qubits, we pulled out the quantities that matter for a controller. Then we built. 

Starting from a small problem to real requirements 

To find where the real requirements lie, we chose a small implementation of Shor’s factoring algorithm — not because factoring 21 is useful,  but because even this simplified logical circuit contains the one ingredient that makes quantum computing capable of delivering quantum advantage: non-Clifford gates. 

Without non-Clifford gates, quantum computing cannot deliver a computational advantage over efficient classical simulation (Gottesman-Knill theorem). From a control perspective, Clifford circuits (even when protected by QEC)  are executed by a predetermined gate sequence, and decoding can happen offline.  

A single non-Clifford gate changes that. Now the decoder’s result decides which gate comes next, so the controller can no longer run a fixed script. In addition, it must interact with the decoder mid-run, in real time and change its physical gate sequence on the fly. This decoding-dependent feed-forward creates a closed loop between quantum hardware and classical computation. The logical circuit that we targeted contains inter–dependent quantum-classical closed loops. This is where many of the practical challenges of fault tolerance emerge. 

Before gates, logical-to-physical compilation 

The first step was to compile the whole thing end-to-end, from logical to physical, and check two things: that the compilation was complete, and that the result was verifiably fault-tolerant. 

This may look like bookkeeping, but it’s the first time it’s been done for a logical circuit of this size. Resource estimates don’t hand you a gate-level schedule for a specific algorithm at a specific code distance. Byproducts from mid-circuit lattice surgeries and surface measurements propagate through the whole circuit, and each must be tracked and resolved correctly. Get it wrong and the logical error will jump, or the decoder’s matching graph will not compile (kudos to the stim and pymatching developers for that). 

So we built the compiler for it. Built on top of stim (on GitHub), it takes a surface-level circuit with knowledge about the original logical circuit and compiles it to a physical-level one, automatically propagating the byproducts left by mid-circuit lattice surgeries and surface measurements to the end of the circuit.  

The first compilation step though was still manual. We transformed the logical target circuit into native surface-level fault-tolerant gates, including lattice surgeries, X/Z initializations and measurements, and magic state injections. Eventually, we reached an un-optimized circuit involving eighteen logical surfaces and dozens of fault-tolerant steps.  

Then, to verify the correctness of this circuit, we used our compiler to compile the surface-level circuit into a physical-level simulation with thousands of qubits and found the expected fault-tolerance behaviour. It reached the target logical error rates for the algorithm with a code distance of 5 and a physical error rate of 10⁻³. 

None of this yet concretely answers the question we started with. But it shows how much is fixed before runtime, namely where logical qubits live, how information moves, and how operations are scheduled.  

From compilation to real-time decoding 

To simulate the full circuit, we had to take a Clifford version of it, now that we are certain about the correctness of the surface-code sequence, we could examine the additional requirement that arise from the non-Clifford gates. Every non-Clifford operation creates a moment where the future evolution of the circuit depends on a decoding result (orange lines in Figure 2). By the time the conditional gate needs to be applied, stabilizer measurements must be processed, errors must be decoded, and the information must be communicated back to the controller. Thus, the controller and decoder become parts of a single real-time computational pipeline. 

When examining the circuit, we broke it down according to the exact decision-making points, each determined by a separate decoding task (different colors in Figure 3). Our circuit produced thirteen distinct decoding tasks, with up to four active in parallel. This was a major insight. Instead of thinking about decoding as a single large process, it’s more useful to see it as many smaller decoding tasks, running in parallel and linked by dependencies.  

Thus, the decoder should not be viewed as a single unit but as a distributed system running jobs side by side and passing information between the decoding tasks. That reframing is what put controllers, decoders, networking, and scheduling into one picture. 

As for how fast decoding really needs to be, we learned something counterintuitive. The common intuition is that latency must be extremely small. What we found instead is that what matters is a budget, given by the surface-level circuit (how the non-Clifford gates are implemented) and the logical-level target error. 

Indeed, delays cause logical qubits to continue accumulating syndrome data while waiting for a decision. However, the non-Clifford implementation can allow a delayed answer (e.g., when propagating correction through commuting gates). Moreover, given the target logical error of the circuit, the system could tolerate controller-decoder latencies. We found that these additional latencies can reach tens of microseconds without significantly affecting overall circuit performance for our target logical circuit.  

This result is encouraging. It means that practical fault-tolerant systems do not necessarily require impossible classical hardware. Instead, they require carefully engineered integration between high-throughput decoding, low-latency communication, the logical circuit, and its fault-tolerant implementation. The challenge is serious, but it is an engineering challenge rather than a fundamental roadblock. 

An unexpected outcome 

One of the more amusing aspects of this story is that by the time the paper completed peer review, QM had already built much of the hardware and software infrastructure that motivated the study. The journey from submission to publication took longer than the development cycle itself – a reflection of how quickly fault-tolerant quantum engineering is advancing. It also raises an interesting question about whether parts of our community could benefit from faster publication models alongside traditional peer review.

The requirements we identified for real-time decoding, low-latency communication, and controller-decoder integration are now implemented within Quantum Machines’ Open Acceleration Stack. What started with asking what a real fault-tolerant quantum computer would require, ultimately led to building the infrastructure to support it. This paper is the story of why that infrastructure matters.

If you’re building toward fault-tolerant quantum computing, we’d love to hear from you.  

[1] Kurman, Y. et al. Benchmarking the Ability of a Controller to Execute Quantum Error Corrected Non-Clifford Circuits. IEEE Trans. Quantum Eng. 6, 1–14 (2025). 

[2] Kurman, Y. et al. Controller-decoder system requirements derived by implementing Shor’s algorithm with surface codes.  Quantum 10, 2170 (2026). 

[3] The physical-level factorization Circuit Video for distance 3 implementation. 2025. doi: 10.5281/zenodo.17970554. url: https : / / doi . org /10.5281/zenodo.17970554.