Quantum platforms need service-level objectives, but the useful objectives are not only uptime and queue latency. A quantum service can be available and still produce scientifically weak results. It can finish quickly and still violate the user’s cost, confidence, or calibration assumptions. This chapter treats SLO engineering as a bridge between platform reliability and scientific validity.
Google’s SRE material frames SLOs as explicit reliability targets and error budgets as the amount of tolerated SLO miss over a window [R191]. Quantum platforms need the same discipline, with a wider set of failure modes.
View diagram source
flowchart LR
User[User intent] --> Contract[Runtime contract]
Contract --> SLI[Service level indicators]
SLI --> SLO[Service level objectives]
SLO --> Budget[Error budget]
Budget --> Policy[Change and routing policy]
Policy --> Execution[Execution and evidence]
Execution --> Review[Budget review]
Review --> SLIQuantum SLIs
Classical services often begin with availability, latency, durability, and correctness. Quantum services inherit those concerns but add physical and statistical indicators.
| SLI class | Quantum interpretation |
|---|---|
| availability | target backend, simulator, broker, and evidence pipeline can accept work |
| latency | queue time, compilation time, execution time, and post-processing time |
| physical quality | calibration recency, gate error, readout error, crosstalk, drift, leakage, temperature stability |
| statistical quality | shot budget, confidence interval, variance, effective sample size, reproducibility |
| economic quality | cost per accepted result, cost per evidence package, cost per validated claim |
| governance quality | policy decision latency, evidence completeness, control exceptions |
View diagram source
mindmap
root((Quantum SLIs))
Service
availability
latency
throughput
Physical
calibration recency
error rates
drift
Statistical
confidence
variance
reproducibility
Economic
cost per result
queue efficiency
Governance
evidence completeness
policy latencySLOs are scoped promises
A useful SLO must name the workload class, target class, measurement window, exclusion policy, and evidence threshold. “Ninety-nine percent success” is not enough. A VQE workload, a randomized benchmark, a calibration experiment, and a fault-tolerant resource-estimation job do not share the same success predicate.
View diagram source
flowchart TB
SLO[SLO statement] --> Workload[Workload class]
SLO --> Target[Target class]
SLO --> Window[Measurement window]
SLO --> Predicate[Success predicate]
SLO --> Exclusions[Exclusion policy]
SLO --> Evidence[Evidence threshold]Example:
For chemistry-estimation jobs tagged
internal/research, 95% of accepted jobs should complete with a full evidence manifest, calibration snapshot younger than the approved validity window, and confidence interval narrower than the workload contract threshold over a rolling 30-day window.
Error budgets for physical systems
A service error budget counts permitted SLO violations over a defined window. Define separate observable predicates for availability, excessive queue delay, drift-invalidated runs, uncertainty-width requirements, and evidence gaps. Keep these service budgets distinct from an algorithm’s logical-failure probability or numerical error tolerance; minutes, failed jobs and estimation error are not interchangeable units.
View diagram source
flowchart LR
Budget[Quantum error budget] --> Availability[Unavailable minutes]
Budget --> Drift[Drift-induced invalid runs]
Budget --> Reruns[Rerun rate]
Budget --> Confidence[Confidence misses]
Budget --> Evidence[Evidence gaps]
Budget --> Cost[Cost overruns]The budget must be owned. Research teams may tolerate wider uncertainty when exploring a new workload. Production services should not.
Budget burn signals
View diagram source
stateDiagram-v2
[*] --> Healthy
Healthy --> Watch: slow burn
Watch --> Freeze: fast burn
Freeze --> Recovery: reliability work
Recovery --> Healthy: budget restored
Watch --> Healthy: stabilized| Burn signal | Default response |
|---|---|
| rising queue latency | route to alternate target, reduce low-priority jobs |
| calibration freshness violations | pause affected workload classes |
| rerun rate above threshold | open incident or problem record |
| uncertainty-width requirement missed | diagnose sampling variance versus bias or drift; add shots only under a valid stopping plan, or revise the method or reject the result |
| evidence gaps | block external claim and require replay or exception |
| cost per result spike | review admission control and batching policy |
User-facing contracts
SLOs should surface in API contracts. Developers should know what level of confidence, latency, cost, and evidence they are buying. Internal systems should reject ambiguous requests.
View diagram source
sequenceDiagram
participant App as Application
participant Broker as Quantum Broker
participant SLO as SLO Registry
participant QPU as QPU Runtime
participant Evidence as Evidence Store
App->>Broker: submit workload contract
Broker->>SLO: resolve service class
SLO-->>Broker: SLO and budget policy
Broker->>QPU: execute if budget permits
QPU-->>Broker: result and telemetry
Broker->>Evidence: persist evidence package
Broker-->>App: bounded responseChapter close
SLO engineering turns quantum operations from ad hoc experimentation into an explicit service discipline. The platform should not promise quantum magic. It should promise scoped reliability, bounded uncertainty, cost visibility, and reviewable evidence.