Logical-Qubit Operations and Decoder Engineering

A logical qubit is an operational service. It is maintained by physical qubits, stabilizer extraction circuits, a syndrome stream, a decoder, a Pauli-frame tracker, calibration policy, and a scheduler that prevents the logical resource from being oversubscribed.

The operating unit changes from a circuit on a noisy device to a time-bounded logical resource with an explicit target failure probability. Google's Willow work made the production lesson clear: the decoder, syndrome stream, and real-time control loop are part of the computer, not post-processing accessories [R50].

35.1 Logical operations are an always-on pipeline

flowchart LR
    Phys[Physical qubits] --> Cycle[QEC cycle]
    Cycle --> Synd[Syndrome stream]
    Synd --> Decode[Decoder]
    Decode --> Frame[Pauli frame]
    Frame --> Logical[Logical qubit service]
    Logical --> Gate[Logical operation]
    Gate --> Cycle

An actively corrected logical-qubit service meets its stated guarantees only while error protection and result interpretation remain within their validated operating limits. A decoder backlog or stream fault can exhaust those limits; an incorrect frame update can corrupt interpretation. Such faults put the logical result at risk, but they do not mean that an encoded qubit immediately ceases to exist.

Logical-operation contract:

35.2 The decoder is latency-critical infrastructure

The decoder converts syndrome history into correction decisions or frame updates. In a fault-tolerant runtime, it is closer to a network switch or storage controller than an analytics job. PyMatching and Stim illustrate the software shape of this problem: the production runtime needs fast syndrome processing, repeatable detector-error modeling, and clear interfaces between the circuit model and decoding layer [R63, R64].

sequenceDiagram
    participant QPU as QPU cycle engine
    participant Stream as Syndrome stream
    participant Dec as Decoder
    participant Frame as Pauli-frame service
    participant Sched as Scheduler
    QPU->>Stream: emit syndrome bits
    Stream->>Dec: append detection events
    Dec->>Frame: correction or frame update
    Frame->>Sched: logical resource health
    Sched->>QPU: continue, pause, or abort policy

Decoder SLOs should be explicit:

35.3 Treat the Pauli frame as a stateful service

Physical corrections are not always applied immediately. Many systems track corrections virtually in a Pauli frame and reinterpret later measurements. This makes the frame tracker a stateful, safety-critical service.

stateDiagram-v2
    [*] --> Clean
    Clean --> PendingUpdate: syndrome indicates correction
    PendingUpdate --> Updated: decoder accepted
    Updated --> Propagated: compiler/runtime adjusts future bases
    PendingUpdate --> Ambiguous: competing corrections
    Ambiguous --> Escalated: budget violation
    Propagated --> Clean: cycle committed

Frame-tracking failure is dangerous because it can look like a successful run with the wrong interpretation. The incident model should include frame divergence, stale frame reads, non-deterministic replay, and compiler/runtime disagreement about basis changes.

35.4 Dynamic circuits become runtime policy

OpenQASM 3 includes classical control and feed-forward concepts, and IBM documents the current OpenQASM 3 feature support surface separately from the language specification [R26, R27, R62]. Logical-qubit operations push this further: dynamic behavior becomes a runtime policy mechanism for correction, routing, teleportation, qubit reuse, and escape handling.

flowchart TB
    Meas[Measurement result] --> Low[Low-latency branch]
    Low --> Basis[Choose basis]
    Low --> Reset[Reset or reuse qubit]
    Low --> Frame[Update frame]
    Low --> Route[Change route]
    Frame --> Audit[Record branch decision]
    Route --> Audit
    Reset --> Audit

Operational guidance:

1. Separate language support from backend support.
2. Record every branch that affects interpretation.
3. Reject workloads that depend on unsupported real-time features.
4. Prefer explicit latency budgets over vague dynamic-circuit claims.

35.5 Decoder placement is an architecture decision

A remote decoder can be useful for offline experiments. It is not enough for low-latency logical operations. NVIDIA describes NVQLink as a low-latency bridge connecting accelerated compute with quantum processors for control and error-correction workflows [R48]. The broader architectural pattern is vendor-neutral: the decoder path belongs close to the machine when feedback latency matters.

flowchart LR
    QPU[QPU] --> FPGA[Fast control and capture]
    FPGA --> LocalGPU[Local accelerator decoder]
    LocalGPU --> Frame[Frame tracker]
    Frame --> Runtime[Runtime scheduler]
    Runtime --> QPU
    LocalGPU -. sampled traces .-> Offline[Offline analytics cluster]

Placement tradeoff:

35.6 Logical resources need admission control

Logical qubits are scarce. A request for logical execution should be admitted only if the platform can satisfy distance, lifetime, decoder throughput, and correlation-risk requirements.

flowchart TD
    Request[Logical workload request] --> Features[Required logical features]
    Features --> Distance{Distance available?}
    Distance -- no --> Reject[Reject or rescope]
    Distance -- yes --> Lifetime{Lifetime budget ok?}
    Lifetime -- no --> Reject
    Lifetime -- yes --> Decoder{Decoder capacity ok?}
    Decoder -- no --> Queue[Queue or reserve]
    Decoder -- yes --> Run[Run with live health gates]

Admission record:

logical_admission_record:
  workload_id: string
  requested_code_distance: int
  requested_logical_qubits: int
  expected_logical_cycles: int
  target_logical_failure_probability: float
  decoder_latency_budget_us: float
  syndrome_bandwidth_budget_mbps: float
  accepted: bool
  rejection_reason: string | null

35.7 Incident classes

Logical-qubit incidents are not the same as NISQ job failures. They can occur while the logical computation appears to continue.

flowchart TB
    Incident[Logical incident] --> Stream[Syndrome stream incident]
    Incident --> Decoder[Decoder incident]
    Incident --> Frame[Frame-tracking incident]
    Incident --> Calibration[Calibration drift incident]
    Incident --> Correlation[Correlated-error incident]
    Incident --> Scheduler[Oversubscription incident]

Runbook triggers:

35.8 Checklist

Before claiming logical-qubit service quality, require:

• a declared code family and distance,
• measured logical error per cycle,
• decoder latency distribution,
• syndrome stream loss metrics,
• frame replay tests,
• calibration compatibility tests,
• admission-control policy,
• incident quarantine rules,
• archived replay artifacts.

flowchart LR
    Metrics[Metrics] --> Evidence[Evidence package]
    Replay[Replay] --> Evidence
    Admission[Admission policy] --> Evidence
    Incident[Incident rules] --> Evidence
    Evidence --> Claim[Logical-service claim]

Additional technical sources: [R5], [R259], [R260].