Logical Resource Brokers and Fault-Tolerant Service Queues

Fault-tolerant quantum services will need a broker that accounts for encoded state, error-correction overhead, decoding, classical feedback, and wall-clock budgets. In the surface-code design used as this chapter’s example, that includes code distance, magic-state factories, and lattice-surgery space. Other codes and logical gate implementations have different resource requirements. A QPU queue that only counts jobs is too crude.

Diagram loads as you read

Logical Resource Brokers and Fault-Tolerant Service Queues · Figure 1

View diagram source

flowchart LR
    Workload[Fault-tolerant workload] --> Estimate[Resource estimate]
    Estimate --> Broker[Logical resource broker]
    Broker --> Queue[Service queue]
    Queue --> Execute[Logical execution]
    Execute --> Evidence[Logical evidence]

Resource objects

Resource	Why it matters
logical qubits	application state capacity
code distance	target logical error rate
physical qubits	hardware footprint
syndrome cycles	time and decoder load
decoder bandwidth	real-time correction feasibility
magic-state factories	non-Clifford throughput
feed-forward lanes	adaptive control capacity
verification budget	evidence and rerun cost

Diagram loads as you read

Resource objects · Figure 2

View diagram source

mindmap
  root((Logical resources))
    Logical qubits
    Code distance
    Physical qubits
    Syndrome cycles
    Decoder bandwidth
    Magic-state factories
    Feed-forward lanes
    Verification budget

Broker inputs

A logical broker needs richer input than a circuit file. It needs an objective, logical error budget, resource estimate, target family, allowed compilation strategies, priority class, evidence level, and abort conditions.

Diagram loads as you read

Broker inputs · Figure 3

View diagram source

flowchart TB
    Spec[Workload specification] --> Error[Logical error budget]
    Spec --> Estimate[Resource estimate]
    Spec --> Policy[Policy constraints]
    Spec --> Evidence[Evidence level]
    Error --> Broker[Broker]
    Estimate --> Broker
    Policy --> Broker
    Evidence --> Broker

Queue classes

Diagram loads as you read

Queue classes · Figure 4

View diagram source

stateDiagram-v2
    [*] --> Intake
    Intake --> FeasibilityCheck
    FeasibilityCheck --> Reservation
    Reservation --> WaitingForFactory
    WaitingForFactory --> Executing
    Executing --> Verifying
    Verifying --> Complete
    FeasibilityCheck --> Rejected
    Executing --> Aborted

Queue class	Example workload	Broker behavior
exploratory	resource-estimation sweep	cheap, preemptible, simulator-backed
validation	benchmark or algorithm proof	evidence-heavy, bounded target set
production	customer-facing service	strict SLO and rollback
mission	high-value scientific or defense workload	manual approval and redundant verification

Magic-state factory scheduling

Diagram loads as you read

Magic-state factory scheduling · Figure 5

View diagram source

flowchart LR
    Factories[Magic-state factories] --> Pool[Factory pool]
    Pool --> JobA[Job A T-gates]
    Pool --> JobB[Job B T-gates]
    Pool --> Reserve[Reserved capacity]
    JobA --> Evidence[Consumption ledger]
    JobB --> Evidence
    Reserve --> Evidence

Non-Clifford resources will often dominate service behavior. The broker should account for factory warmup, factory failure, distillation level, expected consumption, and idle loss.

Admission control

Diagram loads as you read

Admission control · Figure 6

View diagram source

flowchart TB
    Request[Logical job request] --> Feasible{Feasible under current plan?}
    Feasible -- no --> Reject[Reject with estimate]
    Feasible -- yes --> Budget{Within error and cost budget?}
    Budget -- no --> Revise[Request revised spec]
    Budget -- yes --> Reserve[Reserve logical resources]
    Reserve --> Commit[Commit queue slot]

Admission should reject impossible jobs early, with an explanation. A useful rejection includes the limiting resource, nearest feasible alternative, and uncertainty in the estimate.

Preemption and fairness

Diagram loads as you read

Preemption and fairness · Figure 7

View diagram source

flowchart LR
    Queue[Logical queue] --> Priority[Priority policy]
    Priority --> Fairness[Fair-share limits]
    Priority --> Preempt[Preemption rules]
    Preempt --> Checkpoint[Checkpoint or abort]
    Checkpoint --> Evidence[Evidence and billing]

An arbitrary unknown logical state cannot be saved as a reusable classical checkpoint. Pausing it requires continued protected quantum storage or a state-transfer protocol; a restart may require repeating the computation. The broker should distinguish preemptible classical or preparation stages, protected logical execution windows, and explicit abort points.

Broker evidence

Diagram loads as you read

Broker evidence · Figure 8

View diagram source

sequenceDiagram
    participant User
    participant Broker
    participant Scheduler
    participant Evidence
    User->>Broker: Submit logical workload
    Broker->>Evidence: Record estimate and policy
    Broker->>Scheduler: Reserve resources
    Scheduler-->>Broker: Allocation
    Broker->>Evidence: Record allocation and assumptions
    Broker-->>User: Acceptance with bounds

Broker evidence should include the accepted error budget, resource estimate version, compilation profile, queue decision, reservation, runtime deviations, decoder capacity assumptions, and verification results.

Operational rule

Fault-tolerant services should expose queue decisions as resource contracts, not as vague wait times.

Diagram loads as you read

Operational rule · Figure 9

View diagram source

flowchart LR
    Vague[Estimated wait time] --> Weak[Weak contract]
    Contract[Logical resource contract] --> Strong[Strong contract]
    Strong --> Trust[User trust and auditability]

Additional technical sources: [R254], [R268], [R275].