FusionQ Proves You Can Chop a Quantum Decoding Problem Into Local Pieces and Lose Nothing

A new framework decomposes quantum error correction into local tasks fused at runtime, matching global optimal decoding while slashing latency. Backend-agnostic by design.

You know how Google Maps doesn't compute one giant route from your house to every destination in the country? It breaks the world into tiles, solves routing locally within each tile, and stitches the tile-edge handoffs together. If the local routing within each tile is optimal, and the stitching rules are correct, you get the same answer as solving the whole map at once — but orders of magnitude faster because most tiles are trivially empty. FusionQ does exactly this for quantum error correction decoding. The committed claim: FusionQ is a generic fusion decoding framework that decomposes a monolithic detector error model (DEM) into local decoding tasks derived from the observed syndrome, fuses their results, and — with an exact minimum-weight local backend — provably recovers the global most-likely error (MLE) solution. Not an approximation. Not a heuristic tradeoff. The same answer, with a compositional optimality proof. Traditionally, QEC decoding has been organized around fixed instances — you collect a full block of syndrome data, hand it to a monolithic decoder, and wait. Windowed decoders improved latency by sliding a temporal window, but the window size is predetermined and the decoder still processes the full spatial footprint each round. FusionQ breaks this mold by building open-boundary local DEMs around fired detector clusters — the actual error signatures observed in each shot — and expanding footprints only when a local solution touches virtual boundary errors. The key insight is that most of the detector graph is quiet on any given shot, so most local problems are tiny. Architecturally, FusionQ is a scheduler sitting above any backend decoder. The interface contract is minimal: the backend returns a local correction and a boundary-use flag. This means exact solvers (integer linear programming, brute force on small clusters), matching-based decoders on graph-like DEMs (think PyMatching/Sparse Blossom), and heuristic decoders can all plug in. The framework doesn't care — it orchestrates. The compositional optimality theorem guarantees that if the local backend is exact minimum-weight and the published local result is boundary-free, fusion yields the global MLE. With heuristic backends, you lose the proof but still get the latency win. The integrity story is strong for a theory-plus-systems paper. The optimality claim rests on a mathematical proof, not just empirical benchmarks. The evaluation shows shot-by-shot MLE agreement with monolithic decoding when using an exact backend — not statistical equivalence, literal identity on every shot. Across backends, the paper demonstrates substantial latency reduction by overlapping local decoding with hardware syndrome acquisition, which is the real engineering payoff. The paper does not, however, report physical error rates on real hardware or benchmark against the latest streaming/online decoders with wall-clock numbers on specific hardware platforms. The milestone that matters for QEC decoding is real-time decoding at the speed of syndrome acquisition for surface codes at distance 15-25 — the regime where fault-tolerant quantum computing becomes practical. FusionQ's latency reduction through parallelism and locality-exploitation is pointed directly at this target, but the paper stops short of demonstrating real-time parity with syndrome generation on actual quantum hardware. The gap between simulation-validated framework and hardware-validated real-time decoder is the next cliff to climb. The obvious experiment not run: deploying FusionQ on a real superconducting or trapped-ion device with live syndrome streams and measuring wall-clock decoding latency against syndrome generation rate. The honest read is (a) — this is a framework paper from a team establishing theoretical foundations and software architecture, and the hardware integration is a different kind of engineering effort requiring device access and low-level integration work. The paper also doesn't compare latency head-to-head against recent streaming decoders like Helios or AceCR with matched hardware assumptions, which would have sharpened the ladder positioning.