Drift, Aging, and Reliability Engineering

Quantum systems age. Frequencies move, lasers drift, microwave chains change, vacuum conditions evolve, calibration recipes become stale, firmware changes, compiler assumptions diverge from hardware reality, and user workloads apply pressure in patterns the lab did not expect.

Reliability engineering turns those changes into observable, governable phenomena.

44.1 Reliability is a distribution

A quantum platform should not be described as simply “up” or “down.” It has a distribution of readiness across qubits, couplers, zones, modes, instructions, calibration families, and workload classes.

flowchart LR
    Healthy[Healthy enough for workload A] --> Degraded[Degraded for workload B]
    Degraded --> Unfit[Unfit for workload C]
    Unfit --> Repair[Repair or recalibrate]
    Repair --> Healthy

The same device can be acceptable for shallow sampling and unacceptable for a deep entangling circuit. Reliability therefore needs workload-relative SLOs.

44.2 Drift taxonomy

mindmap
  root((Drift))
    physical
      temperature
      vibration
      magnetic field
      vacuum
    control
      amplitude
      phase
      timing
      waveform distortion
    device
      frequencies
      coherence
      readout contrast
      crosstalk
    software
      compiler target
      calibration schema
      runtime image
      analysis code
    workload
      circuit depth
      shot volume
      reservation pressure

IBM backends expose operational state and pending-job information through backend status APIs, and job tags can be used to organize and search experiments. These are basic building blocks for reliability analytics because they tie health and queue state to actual workload history. [R74] [R75]

44.3 Aging curves

Do not assume every failure mode appears immediately. Some appear only after repeated thermal cycles, long queue pressure, firmware changes, or months of recalibration.

gantt
    title Reliability observation horizon
    dateFormat  YYYY-MM-DD
    section Immediate
    install defects          :a1, 2026-05-01, 14d
    section Early life
    calibration instability  :b1, 2026-05-15, 45d
    section Useful life
    ordinary drift           :c1, 2026-07-01, 180d
    section Wear-out
    component degradation    :d1, 2026-12-15, 120d

The goal is not to prevent all drift. The goal is to classify drift quickly enough to avoid contaminating evidence.

44.4 Reliability state machine

stateDiagram-v2
    [*] --> Nominal
    Nominal --> Watch: weak regression
    Watch --> Degraded: confirmed regression
    Degraded --> Restricted: workload impact
    Restricted --> Maintenance: repair needed
    Maintenance --> Requalification
    Requalification --> Nominal: evidence passes
    Requalification --> Restricted: evidence fails
    Watch --> Nominal: regression clears

The Watch state is important. It prevents the organization from oscillating between panic and complacency.

44.5 Workload-relative SLOs

Quantum SLOs should be expressed against workload classes.

flowchart TB
    Workload[Incoming workload] --> Classify[Classify workload]
    Classify --> SelectSLO[Select SLO family]
    SelectSLO --> CheckHealth[Check device health]
    CheckHealth --> Admit{Admit?}
    Admit -- yes --> Execute[Execute]
    Admit -- no --> Route[Delay, reroute, or reject]

This is stricter than a generic uptime target. It allows the platform to accept workloads it can support while protecting users from workloads it cannot.

44.6 Reliability review

A monthly reliability review should compare:

• calibration convergence time,
• median and tail queue delay,
• rejected jobs by cause,
• readout and gate-quality trends,
• crosstalk regressions,
• benchmark confidence intervals,
• incident recurrence,
• user-visible quality regressions,
• cost per accepted workload.

flowchart LR
    Metrics[Reliability metrics] --> Review[Monthly review]
    Incidents[Incident records] --> Review
    User[User reports] --> Review
    Vendor[Vendor notices] --> Review
    Review --> Actions[Repair, retune, restrict, or invest]

44.7 Reliability debt

Reliability debt is accumulated whenever the team accepts a workaround without retiring it.

reliability_debt_item:
  id: string
  description: string
  accepted_by: string
  date_opened: date
  affected_workloads: [string]
  compensating_controls: [string]
  retirement_condition: string
  review_cadence: string

Examples:

44.8 Operating rule

Treat drift as a normal operating input. The failure is not drift. The failure is allowing drift to enter results without detection, qualification, or provenance.