Fault tolerance changes the operating model, but it does not remove the need for operations. It adds new layers: logical qubits, syndrome extraction, decoding, magic-state factories, lattice surgery or other logical operations, and resource scheduling across physical and logical domains.
The near-term platform should be built so it can migrate toward those layers instead of being replaced by them.
26.1 From NISQ jobs to logical services
View diagram source
flowchart LR
NISQ[NISQ experiment] --> Mitigated[Mitigated workload]
Mitigated --> EarlyLogical[Early logical memory / operation]
EarlyLogical --> FTModule[Fault-tolerant module]
FTModule --> LogicalService[Logical-qubit service]
LogicalService --> Application[Application-level service]The transition is gradual. Platforms that already have provenance, resource estimation, admission control, telemetry, and trust reports will adapt faster.
26.2 New resource types
View diagram source
flowchart TB
FT[Fault-tolerant platform] --> Physical[Physical qubits]
FT --> Logical[Logical qubits]
FT --> Syndrome[Syndrome bandwidth]
FT --> Decoder[Decoder capacity]
FT --> Magic[Magic-state factories]
FT --> Interconnect[Interconnects]
FT --> Time[Logical clock cycles]Fault-tolerant resource model:
| Resource | Operational question |
|---|---|
| physical qubits | how many are healthy and allocatable? |
| logical qubits | how many meet target logical error rate? |
| syndrome bandwidth | can measurement data be processed in time? |
| decoder capacity | can correction decisions keep up? |
| magic states | are non-Clifford resources bottlenecked? |
| interconnect | are logical modules linked with enough quality? |
| logical time | how many logical cycles are required? |
26.3 Error correction as a production pipeline
Google’s Willow work reported below-threshold surface-code memories with a real-time decoder, and IBM has published a roadmap toward large-scale fault-tolerant systems including logical operations and modular components [R50, R47]. Regardless of vendor, the operational lesson is the same: error correction is not a background feature. It is a production pipeline.
View diagram source
sequenceDiagram
participant QPU as Physical qubits
participant Meas as Syndrome measurement
participant Dec as Decoder
participant Ctrl as Control system
participant Log as Logical state tracker
QPU->>Meas: repeated stabilizer measurements
Meas->>Dec: syndrome stream
Dec-->>Ctrl: correction or frame update
Ctrl->>Log: update logical frame
Log-->>Ctrl: logical operation statePipeline SLOs:
| SLO | Why it matters |
|---|---|
| syndrome capture completeness | missing measurements can corrupt decoding |
| decoder latency | late corrections can break online control |
| logical error estimate freshness | stale estimates mislead admission control |
| factory output rate | magic-state starvation stalls workloads |
| frame-update correctness | wrong Pauli frame corrupts logical results |
26.4 Logical admission control
A fault-tolerant scheduler admits logical workloads, not just physical circuits.
View diagram source
flowchart TB
Request[Logical workload request] --> Estimate[Resource estimate]
Estimate --> Budget[Logical error budget]
Budget --> Resources[Resource availability]
Resources --> Factories[Magic-state factory capacity]
Factories --> Decoder[Decoder capacity]
Decoder --> Admit{Admit?}
Admit -- yes --> Schedule[Schedule logical execution]
Admit -- no --> Repair[Suggest reduced scope or later window]Admission fields:
logical_admission_request:
algorithm_id: string
logical_qubits_required: int
logical_cycles_required: int
target_failure_probability: float
non_clifford_resources:
t_count: int
t_depth: int
decoder_class: string
deadline: timestamp|null
evidence_class: exploratory|publication|productionThe scheduler should reject workloads that cannot meet their logical error target. Running them anyway produces expensive noise.
26.5 Magic-state factories and bottlenecks
Many fault-tolerant algorithms require expensive non-Clifford resources. In several architectures, magic-state distillation becomes a factory scheduling problem.
View diagram source
flowchart LR
Raw[Raw magic states] --> Distill[Distillation factory]
Distill --> Verify[Verification]
Verify --> Inventory[Magic-state inventory]
Inventory --> Consume[Logical workload consumes]
Consume --> Demand[Demand forecast]
Demand --> DistillFactory telemetry:
| Metric | Use |
|---|---|
| factory throughput | capacity planning |
| factory failure rate | quality monitoring |
| inventory age | scheduling and expiry policy |
| workload T demand | admission and batching |
| distillation overhead | cost accounting |
A logical workload can be blocked by factory output even when enough logical qubits appear available.
26.6 Resource estimation feedback loop
Microsoft’s resource estimator documents a stack-wide estimation approach that calculates physical qubits, logical qubits, runtime, and formulas under configurable assumptions [R49]. In a production roadmap, estimates should feed architecture decisions.
View diagram source
flowchart TB
Workload[Target workload] --> Estimate[Resource estimate]
Estimate --> Bottleneck[Bottleneck analysis]
Bottleneck --> Hardware[Hardware roadmap]
Bottleneck --> Compiler[Compiler roadmap]
Bottleneck --> Code[Error-correction code choices]
Bottleneck --> Product[Product scope]
Hardware --> Estimate
Compiler --> Estimate
Code --> EstimateUse estimates to decide whether to invest in:
- lower physical error rates,
- faster measurements,
- better decoders,
- alternative codes,
- magic-state factory optimization,
- compiler T-count reduction,
- modular interconnects,
- different product scope.
26.7 Migration plan for today’s platform
View diagram source
gantt
title Migration from NISQ platform to logical services
dateFormat YYYY-MM-DD
section Today
Governed experiment bundles :a1, 2026-04-18, 90d
Calibration-aware compilation :a2, 2026-05-01, 120d
section Near term
Resource estimation integration :b1, 2026-06-01, 180d
Logical workload schemas :b2, 2026-08-01, 180d
section FT readiness
Decoder telemetry model :c1, 2026-10-01, 240d
Logical admission control prototype :c2, 2027-01-01, 240d
section Product
Logical service API :d1, 2027-06-01, 365dImmediate investments that survive the transition:
| Investment | Why it carries forward |
|---|---|
| experiment bundles | logical workloads still need provenance |
| trust reports | logical results still need uncertainty and assumptions |
| resource estimates | become admission and roadmap tools |
| telemetry | expands to syndrome, decoder, and logical layers |
| target contracts | evolve from physical to logical targets |
| cost engineering | becomes more important, not less |
26.8 Logical service API
A future user should not have to manage every physical detail. They should declare intent, target error, budget, and constraints.
logical_quantum_service_request:
workload: chemistry_phase_estimation
inputs:
molecule: string
basis: string
target:
energy_precision: 1.0e-3
max_failure_probability: 0.01
constraints:
max_runtime: 24h
max_cost: 50000
evidence:
trust_report: required
resource_breakdown: requiredView diagram source
flowchart LR
User[User intent] --> Service[Logical service API]
Service --> Estimate[Estimate]
Estimate --> Admit[Admit]
Admit --> Execute[Execute logical workload]
Execute --> Report[Evidence report]The API should expose assumptions, not hide them.
26.9 Chapter rule
Fault tolerance is not magic. It is a more demanding operating model with better error semantics. Build today’s platform so that logical qubits, decoders, factories, and resource estimates can become first-class resources tomorrow.