Advanced Scheduling, Queue Economics, and Reservations

Quantum scheduling is not just fair queuing. It is allocation under drift, calibration windows, scarce access, shot budgets, priority contracts, and statistical stopping rules. The scheduler is one of the most economically important services in the platform.

Diagram loads as you read

Advanced Scheduling, Queue Economics, and Reservations · Figure 1

View diagram source

flowchart TB
    Demand[Demand] --> Scheduler[Quantum scheduler]
    Calibration[Calibration windows] --> Scheduler
    Reservations[Reservations] --> Scheduler
    Budgets[Shot and cost budgets] --> Scheduler
    Priority[Priority policy] --> Scheduler
    Scheduler --> QPU[QPU target]
    Scheduler --> Sim[Simulator]
    Scheduler --> Defer[Deferred queue]
    Scheduler --> Reject[Rejected request]

Scheduling objectives

A scheduler balances competing goals:

Objective	Tension
scientific validity	may require narrow target windows
cost control	may prefer batching and lower priority
latency	may require reservation or premium routing
fairness	may conflict with strategic workloads
utilization	may conflict with calibration freshness
reproducibility	may require repeated runs under similar conditions

Diagram loads as you read

Scheduling objectives · Figure 2

View diagram source

flowchart LR
    Objective[Scheduling objective] --> Validity[Validity]
    Objective --> Cost[Cost]
    Objective --> Latency[Latency]
    Objective --> Fairness[Fairness]
    Objective --> Utilization[Utilization]
    Objective --> Repro[Reproducibility]

The scheduler must make tradeoffs explicit.

Admission before scheduling

Bad jobs should not enter the queue.

Diagram loads as you read

Admission before scheduling · Figure 3

View diagram source

flowchart LR
    Request[Request] --> Validate[Validate contract]
    Validate --> Estimate[Estimate shots and duration]
    Estimate --> Check[Check policy and budget]
    Check --> Admit{Admit?}
    Admit -- yes --> Queue[Queue]
    Admit -- no --> Reject[Reject with reason]
    Queue --> Schedule[Schedule]

Admission control protects the queue, the budget, and the evidence system.

Reservation economics

Reservations are useful when queue uncertainty is more expensive than reserved access. They are wasteful when teams reserve capacity to compensate for poor planning.

Diagram loads as you read

Reservation economics · Figure 4

View diagram source

flowchart TB
    Need[Need hardware access] --> Latency{Latency critical?}
    Latency -- no --> Shared[Use shared queue]
    Latency -- yes --> Window{Narrow calibration window?}
    Window -- yes --> Reserve[Reserve target]
    Window -- no --> Priority{Priority service enough?}
    Priority -- yes --> PriorityQueue[Priority queue]
    Priority -- no --> Reserve

A reservation should have a business owner, a run plan, fallback plan, and post-reservation utilization review.

Batch planning

Batching improves throughput but can damage validity if the batch crosses material calibration drift.

Diagram loads as you read

Batch planning · Figure 5

View diagram source

flowchart LR
    Jobs[Candidate jobs] --> Group[Group by target, circuit shape, policy]
    Group --> Drift[Check calibration freshness]
    Drift --> Batch[Batch]
    Batch --> Execute[Execute]
    Execute --> Split{Drift detected?}
    Split -- yes --> Stop[Stop batch and re-plan]
    Split -- no --> Continue[Continue]

Batching should be drift-aware, not just provider-aware.

Statistical stopping

Some workloads can adapt their shot count to a precision target, but the inference procedure must remain valid under the stopping rule. Repeatedly inspecting an ordinary fixed-sample confidence interval and stopping when it is narrow enough does not generally preserve its stated coverage. Use a confidence sequence or another validated sequential design, and record the stopping rule and shot cap. More shots alone do not remove noise or mitigation bias. Confidence-sequence methods formalize time-uniform coverage under explicit assumptions.

Diagram loads as you read

Statistical stopping · Figure 6

View diagram source

stateDiagram-v2
    [*] --> RunShots
    RunShots --> UpdateSequentialInterval
    UpdateSequentialInterval --> Continue: precision unmet and budget remains
    Continue --> RunShots
    UpdateSequentialInterval --> StopSuccess: valid precision target met
    UpdateSequentialInterval --> StopBudget: budget exhausted
    StopSuccess --> [*]
    StopBudget --> [*]

A scheduler that understands stopping rules can save cost and shorten queues.

Queue fairness

Fairness should be policy-driven.

Diagram loads as you read

Queue fairness · Figure 7

View diagram source

flowchart TB
    Queue[Queue] --> Class[Service class]
    Class --> Research[Research]
    Class --> Benchmark[Benchmark]
    Class --> Customer[Customer]
    Class --> Incident[Incident response]
    Research --> Policy[Fairness policy]
    Benchmark --> Policy
    Customer --> Policy
    Incident --> Policy
    Policy --> Dispatch[Dispatch order]

A platform should not pretend all jobs are equal. It should define why they are not.

Practical rule

The scheduler should produce an explanation for every dispatch decision: why this workload, why this target, why this time, why this shot budget, and why alternatives were rejected.