Quantum Faultstack

In short, this is an educational tool disguised as a game. I worked hard to make sure the concepts become clearer as we go, and I loved working with Codex and GPT-5.6 to make this happen.

Learn to engineer the systems that make large-scale quantum computing possible

Quantum Faultstack is an educational systems simulation about the classical infrastructure required to operate and scale a fault-tolerant quantum computer.

Rather than focusing only on qubits, gates, and quantum algorithms, the game explores the engineering systems surrounding the quantum processor: control, readout, timing, routing, decoding, calibration, feedback, and error correction.

The player builds and operates these systems, observes their behavior, diagnoses failures, and improves the architecture through hands-on experimentation.

Inspiration

Most introductions to quantum computing begin with superposition, entanglement, quantum gates, and small circuits. These concepts are important, but they do not fully explain what makes building a useful large-scale quantum computer difficult.

Scaling toward millions of physical qubits is also a systems-engineering problem.

Measurements must be acquired and interpreted. Error information must be transported and decoded. Corrections must return before they become stale. Classical processors, control electronics, communication links, scheduling systems, and feedback loops must all keep pace with the quantum hardware.

I created Quantum Faultstack to make those challenges visible and understandable.

The goal is not to tell players that scalable quantum computing is impossibly complicated. It is to give them the tools and intuition to understand the problem and begin reasoning about how it can be solved.

What the player learns

Quantum Faultstack teaches players to think about a quantum computer as a complete system.

Players explore questions such as:

How does raw readout become useful error information?
Why is decoding part of a real-time feedback loop?
What happens when measurements arrive faster than the classical stack can process them?
How do latency, throughput, buffering, topology, and scheduling interact?
Why can a locally optimal component create a system-level bottleneck?
What changes when a design grows from a small experiment into a fault-tolerant machine?

The current game uses superconducting quantum-computing terminology in parts of its hardware presentation, but many of the central lessons apply across modalities. Superconducting circuits, trapped ions, neutral atoms, spins, and photonic systems all require substantial classical infrastructure to operate reliably at scale.

More than a scripted puzzle

The simulation does not simply select a predetermined failure whenever the player makes the wrong choice.

Where practical, Quantum Faultstack uses real algorithms and engineering-inspired statistical models to produce its behavior. This includes minimum-weight perfect-matching decoding through Fusion Blossom, probabilistic error generation, noisy evidence, queueing, processing delays, and deadline-sensitive correction paths.

The player does not receive access to the hidden quantum state. Decisions must be made from visible measurements, detector events, system telemetry, and operational outcomes.

This creates an important distinction: the player is not solving a puzzle with access to the answer. They are operating an imperfect system and reasoning from evidence.

The gameplay loop

Players commission hardware, assemble processing systems, route communication paths, configure runtime behavior, and bring the control stack online.

A typical loop is:

Understand the service objective.
Assemble the required classical infrastructure.
Connect control, acquisition, decoding, and correction paths.
Run the workload.
Observe public telemetry and system behavior.
Diagnose bottlenecks or failure modes.
Modify the architecture or configuration.
Test the improved system.

As the game progresses, the player moves from basic QPU bring-up toward readout, protected logical operation, decoder performance, correction deadlines, scaling pressure, and increasingly complex workloads.

OpenAI Build Week

Quantum Faultstack existed before OpenAI Build Week as an evolving Rust and Bevy simulation.

For Build Week, I extended its educational layer into a more deliberate training experience. The new work focused on helping players connect what they observe in the simulation to the underlying systems-engineering and quantum-error-correction concepts.

The training experience was designed around active learning:

introduce a concrete engineering concept;
let the player operate the relevant system;
expose the evidence produced by the simulation;
connect the observed outcome to the underlying principle;
encourage another experiment rather than simply revealing the answer.

I used Codex throughout the Build Week development process for repository-scale analysis, implementation, testing, debugging, refactoring, and iteration. I used GPT-5.6 to help develop and evaluate clear, technically grounded educational explanations around the simulation and its observable system behavior.

The repository contains a dedicated Build Week baseline so the pre-existing project and the new hackathon work can be reviewed separately.

How I built it

Quantum Faultstack is written in Rust using the Bevy game engine and an entity-component-system architecture.

The project is divided into separate crates for simulation, missions, operations, UI, hardware behavior, and application integration. The browser build is compiled to WebAssembly and distributed as a playable web demo.

Key technical elements include:

a packet-based classical control and measurement pipeline;
QPU evidence generation with hidden internal error state;
readout and detector-event processing;
minimum-weight perfect-matching decoding;
correction proposals and frame updates;
latency, queues, deadlines, and backpressure;
persistent hardware assembly and system layouts;
structured missions and learning objectives;
deterministic testing around simulation and progression behavior.

Codex was particularly valuable for navigating interactions across the Rust workspace, tracing behavior through the ECS architecture, implementing focused changes, expanding test coverage, and identifying inconsistencies between simulation logic and player-facing explanations.

I retain responsibility for the product direction, quantum-computing model, architecture, teaching goals, and final engineering decisions.

Challenges

One of the largest challenges is balancing realism with clarity.

A complete quantum-control system contains enough detail to overwhelm a new player. Simplifying too aggressively, however, can remove the very feedback loops and architectural tradeoffs that make the subject interesting.

Another challenge is maintaining the boundary between hidden simulation truth and observable evidence. The game must produce enough telemetry for meaningful diagnosis without turning that telemetry into an oracle.

Technical realism also needs to serve gameplay. A real algorithm is useful only when its behavior creates a decision the player can understand and influence.

Finally, because Quantum Faultstack is a pre-existing project, the Build Week work needed to remain clearly identifiable. I created an explicit repository baseline and documented the commits, Codex sessions, implementation decisions, and educational features added during the submission period.

What I learned

Building Quantum Faultstack reinforced that quantum error correction cannot be understood only as an isolated algorithm.

A decoder may produce the right answer but produce it too late. A higher measurement rate may reduce uncertainty while overwhelming downstream processing. Additional code distance may improve theoretical protection while increasing the demands on the surrounding classical system.

The behavior emerges from the complete loop.

I also learned that technical education becomes more effective when the learner can form a hypothesis, change the system, and observe the result. The objective is not merely to explain the correct architecture, but to create an environment in which the reason for that architecture becomes visible.