⚛️ quantum physics

Hardware-in-the-Loop Syndrome-to-Decoder Validation for Repetition, Surface, CSS-LDPC, and Digitized-GKP Codes

This paper validates a hardware-in-the-loop syndrome-to-decoder interface across three IBM quantum circuits and a digitized-GKP model, demonstrating that while hardware noise significantly reduces exact error localization, the system reliably maintains target-containing localization to support auditable decoding rather than threshold claims.

Original authors: Dennis Delali Kwesi Wayo, Chinonso Onah, Rodrigo Alves Dias, Leonardo Goliatt, Sven Groppe

Published 2026-07-23

📖 7 min read🧠 Deep dive

CC BY 4.0

Original authors: Dennis Delali Kwesi Wayo, Chinonso Onah, Rodrigo Alves Dias, Leonardo Goliatt, Sven Groppe

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to send a secret message across a noisy, chaotic room. You whisper the message to a friend, who whispers it to another, and so on, until it reaches the end. But the room is full of people shouting, dropping things, and accidentally changing your words. To fix this, you don't just send the message once; you send a bunch of extra "check" signals along with it. These signals tell the receiver, "Hey, if the word 'cat' sounds like 'bat' here, you know something went wrong."

In the high-tech world of quantum computing, scientists are trying to build computers that can solve problems impossible for today's machines. But these quantum computers are incredibly fragile. The slightest bump, heat, or noise can scramble their calculations. To save the day, they use Quantum Error Correction. Think of it as a super-smart spell-checker that constantly monitors the computer's memory. It measures tiny "syndromes" (like the check signals in our noisy room) to figure out if an error happened. Once it spots a problem, a decoder (the spell-checker's brain) has to instantly decide how to fix it.

The big question isn't just "Can we fix errors?" but "Can we actually get the raw data from the messy, noisy quantum machine to the decoder without losing the meaning?" If the machine says "Error at spot A" but the decoder hears "Error at spot B" because of a translation mistake, the whole system fails. This paper is like a rigorous quality-control test to make sure the "phone line" between the noisy quantum hardware and the smart decoder is working perfectly, even when the hardware is acting up.

The Great Translation Test: From Noisy Hardware to Smart Decoders

The authors of this study, led by Dennis Delali Kwesi Wayo and colleagues, set up a massive "translation challenge." They wanted to see if they could take raw, messy data from real quantum computers and a simulated model, feed it into a decoder, and get the right answer back. They didn't just look at one type of computer; they tested four different "languages" or code families to see if the translation pipeline held up.

The Four Test Cases

The Simple Repetition Code: Imagine you have five friends in a line. If one of them sneezes, the person next to them hears it. This is a simple way to spot an error. The team tested this on a real quantum chip (IBM's "ibm fez").
The Surface Code (The Big One): This is the gold standard for quantum memory, like a complex grid of tiles where errors are caught by checking neighbors. They tested a version of this with 40 data qubits (the "friends") and 16 check qubits (the "listeners"). This is a much bigger, more complex circuit.
The CSS-LDPC Code (The Steane Code): This is a compact, efficient code that uses a sparse matrix (a grid with lots of empty spaces) to check for errors. It's like a clever puzzle where you only need to check a few specific spots to know the whole picture.
The Digitized-GKP Code (The Bosonic Cousin): This one is different. Instead of using a real quantum chip, they used a software simulation (PennyLane) to mimic a type of quantum code that lives in "oscillator" space (like waves in a pond). They took these wave-like signals, turned them into digital bits, and fed them into the same decoder used for the real chips.

The Experiment: 4,096 Shots and a Lot of Noise

For every test, they ran the circuits 4,096 times (called "shots"). They ran two types of streams:

Clean Streams: Where nothing was supposed to go wrong.
Injected Streams: Where they deliberately planted an error (like flipping a switch) to see if the system could find it.

They then took the raw results and ran them through a decoder pipeline using three different strategies:

MWPM (Minimum Weight Perfect Matching): The "gold standard" baseline, like finding the shortest path to fix the error.
UF (Union-Find): A faster, simpler method.
BP (Belief Propagation): A method that guesses based on probabilities.

What They Found: The Good, The Bad, and The "Close Enough"

The results were a mix of triumphs and reality checks.

The Simple Stuff Worked Great: For the Repetition Code and the CSS-LDPC (Steane) code, the system was a star. When they injected an error, the decoder almost always found the exact right spot.
- For the Repetition code, the "exact localization" rate (finding the exact error) was between 0.821 and 0.868.
- For the Steane code, it was between 0.843 and 0.858.
- Even better, if you just asked, "Did the fix include the right person?" (target-containing), the rates went up to 0.923 and 0.858 respectively. This proved that for smaller, simpler circuits, the "phone line" between the hardware and the decoder is crystal clear.
The Big Circuit Got Noisy: When they moved to the Surface Code (the 40-qubit monster), things got messy. The real hardware was so noisy that the decoder couldn't pinpoint the exact error anymore.
- The "exact localization" rate dropped to a very low 0.003 to 0.108.
- However, the decoder wasn't totally lost. It still found the error somewhere in the right neighborhood. The "target-containing" rate (finding the error or a neighbor) stayed decent, between 0.279 and 0.642.
- The authors explain this isn't a failure of the decoder's logic, but a sign that the hardware itself is generating so much background noise (like static on a radio) that the signal gets drowned out. The decoder is doing its job, but the input is just too messy for a perfect answer.
The Simulation Matched the Theory: The Digitized-GKP study, which used software to simulate waves and turn them into bits, showed that this "translation" works for different types of quantum physics too.
- The exact localization was 0.350 to 0.495.
- The target-containing rate was 0.417 to 0.608.
- This suggests that even if you have a weird, wave-based quantum computer, you can still translate its signals into the same language that the decoder understands.

The Verdict: A Reliable Pipeline, Even if the Signal is Fuzzy

The most important takeaway isn't that they built a perfect, error-free quantum computer. It's that they proved the interface works. They showed that you can take raw, noisy data from a real quantum chip (or a simulation), translate it into a standard request, and feed it to a decoder without losing the "meaning" of the error.

The paper explicitly rules out the idea that the decoder is broken or that the translation is wrong. Instead, it suggests that for larger circuits (like the 56-qubit surface code), the hardware noise is currently the bottleneck, not the software. The decoder is ready; the hardware just needs to get quieter.

The authors conclude that this "syndrome-to-decoder" pipeline is now a verified, reproducible tool. It's a solid foundation for future experiments. Whether they are testing bigger codes, trying to fix errors over multiple rounds, or mixing in those wave-based GKP codes, they now have a trusted way to check if their data is being read correctly. It's a crucial step toward the day when quantum computers can actually fix their own mistakes and solve the world's hardest problems.

Technical Summary: Hardware-in-the-Loop Syndrome-to-Decoder Validation

Problem Statement
Quantum error correction (QEC) relies on a critical interface between physical hardware readout and classical decoding algorithms. While numerical decoder studies often assume idealized syndrome streams, and hardware demonstrations frequently focus on circuit execution or logical observables, the mapping between measured syndrome bits and decoder-native correction requests is prone to practical errors. Issues such as bit ordering, check indexing, circuit transpilation, and backend-specific measurement layouts can alter the semantic mapping of a nominal syndrome. This paper addresses the narrow question of whether syndrome extraction circuits executed on live superconducting hardware, and digitized syndromes derived from bosonic-code models, can be converted into decoder requests and replayed through a correction pipeline without losing the intended code or check semantics.

Methodology
The study evaluates four distinct cases using a unified "syndrome-to-decoder" replay pipeline. All cases utilize 4,096 shots per stream, comparing "clean" circuits against streams with injected faults. The pipeline expands hardware counts or analog samples into per-shot records, constructs LiDMaS+ requests, and replays them through three decoder policies: Minimum-Weight Perfect Matching (MWPM), Union-Find (UF), and Hard-Decision Belief Propagation (BP).

Repetition Code: A five-data-qubit repetition code with four adjacent parity checks. The hardware implementation uses a path-graph parity check structure.
Surface Code (Z-check): A distance-five rotated-surface-code Z-check extraction layer. This involves 40 data qubits and 16 Z-check ancillas (56 measured bits total). Only the Z-check half is executed because the injected faults are X-type. Eight representative injected-X targets are tested to sample both boundary and interior columns of the incidence matrix.
CSS-LDPC (Steane Code): The Z-check half of the Steane CSS code, represented by a sparse $3 \times 7$ parity-check matrix. This serves as a compact benchmark for matrix-based decoder interfaces used in larger CSS and qLDPC codes.
Digitized-GKP: A companion study using a PennyLane-backed digitized-GKP model. Instead of physical GKP modes, finite-squeezed Gaussian-CV q-readout samples and injected q-shifts are digitized into binary outer-code Z-check syndromes using the same surface-code incidence matrix ( $H_{surf,Z}$ ).

The hardware experiments were executed on the IBM ibm_fez backend. The digitized-GKP study is an off-hardware simulation. The primary metric is localization rate (exact and target-containing), with MWPM serving as the baseline for plotting, while UF and BP serve as interface validation controls.

Key Results

Repetition and CSS-LDPC: Both the repetition code and the Steane CSS-LDPC experiments successfully preserved the dominant expected syndrome and correction for every injected target. Hardware exact-localization rates ranged from 0.821 to 0.868 (Repetition) and 0.843 to 0.858 (CSS-LDPC). The results confirm that the parser, bit order, and check order remain aligned with the intended syndrome semantics despite backend transpilation.
Surface Code (Hardware): The distance-five surface circuit (56 routed qubits) exhibited broad hardware-induced syndrome activation. While the local simulator maintained sparse, column-like syndromes with high localization, the IBM hardware showed significant background activation. Consequently, exact localization dropped to 0.003–0.108, though target-containing localization remained higher (0.279–0.642). The mean correction weight increased significantly compared to the local reference, indicating that the hardware noise drives multi-site corrections rather than single-target fixes.
Digitized-GKP: The digitized study achieved exact q-shift localization of 0.350–0.495 and target-containing localization of 0.417–0.608. The results demonstrate that analog GKP-derived information can be reduced to the same binary request interface used by stabilizer-code runs, with the target often included in the correction even when the exact MWPM representative differs due to syndrome degeneracy.
Decoder Audit: Across all four studies, the MWPM, UF, and BP policies successfully closed every measured syndrome (zero nonzero residuals in the audit), confirming the robustness of the interface construction rather than the superiority of a specific decoder.

Significance and Claims
The paper explicitly states that its contribution is methodological, not a claim of fault tolerance or threshold estimation. The study is scoped below threshold estimation, utilizing single-round syndrome extraction and finite code sizes.

The primary significance is the provision of a reproducible, auditable route from circuit construction and hardware execution to decoder request construction and quantitative reporting. The authors argue that the results support an auditable syndrome-to-decoder interface rather than a threshold claim. By isolating the boundary between syndrome extraction and decoding, the study provides a compact experimental framework where expected syndromes are checked directly from parity matrices. This allows for the isolation of interface errors (bit ordering, transpilation mapping) from decoder performance issues. The work complements larger hardware-QEC demonstrations by validating that the "handshake" between hardware and decoder remains semantically intact, even when hardware noise degrades the raw localization rates in larger circuits.

The Great Translation Test: From Noisy Hardware to Smart Decoders

Technical Summary: Hardware-in-the-Loop Syndrome-to-Decoder Validation

More like this