Customer-Facing SLAs, SLO-as-Code, and Promise Management

A quantum platform must be careful with promises. Classical cloud SLAs often speak in uptime and latency. Quantum services need more nuanced commitments: access availability, queue behavior, evidence completeness, result delivery, calibration freshness, replay support, and claim language.

OpenSLO is an open specification for defining SLOs as code, with a vendor-neutral orientation toward thresholds, metrics, and goals [R233]. Google’s SRE workbook emphasizes that useful SLOs should measure reliability as experienced by customers and should drive alerting before error budgets are exhausted [R241]. Quantum platforms should encode SLOs as operational contracts, not slideware.

flowchart LR
    Promise[Customer promise] --> SLI[SLI]
    SLI --> SLO[SLO as code]
    SLO --> Alert[Alerting]
    Alert --> Action[Operational action]
    Action --> Review[Promise review]

Promise layers

flowchart TB
    SLA[SLA] --> Access[Access promise]
    SLA --> Queue[Queue promise]
    SLA --> Evidence[Evidence promise]
    SLA --> Replay[Replay promise]
    SLA --> Support[Support promise]
    SLA --> Caveats[Caveats and exclusions]

SLO-as-code example

apiVersion: openslo/v1
kind: SLO
metadata:
  name: quantum-evidence-completeness
spec:
  service: quantum-platform
  budgetingMethod: Occurrences
  timeWindow:
    - duration: 30d
      isRolling: true
  indicator:
    metadata:
      name: quantum-evidence-evaluations
    spec:
      ratioMetric:
        counter: true
        good:
          metricSource:
            type: Prometheus
            spec:
              query: evidence_evaluations_total{outcome="complete"}
        total:
          metricSource:
            type: Prometheus
            spec:
              query: evidence_evaluations_all_total
  objectives:
    - target: 0.995

This illustrative OpenSLO v1 object assumes a metrics adapter that evaluates counter increases over the declared window and handles resets. Emit one deduplicated evaluation per eligible result at a declared evidence deadline: increment the total for every evaluation and the good counter only when required evidence is complete. Use the same cohort for both counters, define behavior for missing data and zero traffic, and validate the object and adapter against the adopted OpenSLO implementation [R233].

Quantum SLIs

flowchart LR
    SLIs[Quantum SLIs] --> Access[Admission success]
    SLIs --> Latency[Queue latency]
    SLIs --> Evidence[Evidence completeness]
    SLIs --> Replay[Replay availability]
    SLIs --> Quality[Quality-window hit rate]
    SLIs --> Cost[Cost predictability]

Recommended SLIs:

Promise risk

flowchart TB
    PromiseRisk[Promise risk] --> Overpromise[Overpromise correctness]
    PromiseRisk --> Underinstrument[Cannot measure promise]
    PromiseRisk --> ProviderDependency[Provider dependency hidden]
    PromiseRisk --> ScientificCaveat[Scientific caveat omitted]
    PromiseRisk --> LegalMismatch[Legal SLA differs from technical SLO]

Customer-facing language should never imply that quantum hardware produces deterministic correctness unless the workload and evidence support that claim. The safest promises are measurable, scoped, caveated, and linked to escalation rules.

Error-budget policy

flowchart LR
    Burn[Error-budget burn] --> Check{Threshold?}
    Check -- no --> Normal[Continue]
    Check -- warning --> Review[Review rollout and routing]
    Check -- critical --> Freeze[Freeze risky changes]
    Freeze --> Recover[Recovery plan]

If evidence-completeness SLO is burning too fast, stop accepting high-stakes claims until the evidence pipeline recovers. If queue SLO is burning, reduce low-priority demand or purchase reservations. If quality-window SLO is burning, reroute or pause affected workload classes.

Operating rule

Do not sell a quantum SLA that the control room cannot measure, alert on, and enforce.