Maintainer Handbook for Quantum Platforms — Operating Quantum Computers

Quantum platforms are maintained, not merely built. Hardware changes, providers change APIs, compilers evolve, calibration practices drift, standards mature, teams rotate, and old claims require reanalysis. The maintainer protects continuity.

Diagram loads as you read

Maintainer Handbook for Quantum Platforms · Figure 1

View diagram source

flowchart LR
    Maintain[Maintain platform] --> Verify[Verify assumptions]
    Verify --> Patch[Patch systems]
    Patch --> Review[Review evidence]
    Review --> Teach[Teach operators]
    Teach --> Retire[Retire stale paths]
    Retire --> Maintain

Maintainer responsibilities

Area	Responsibility
interfaces	keep APIs, schemas, adapters, and SDKs compatible
evidence	preserve provenance and reviewability
policy	update guardrails as risks change
references	refresh current-state claims
runbooks	remove stale steps and drill procedures
dependencies	track SDK, compiler, simulator, and provider changes
culture	keep review habits alive

Diagram loads as you read

Maintainer responsibilities · Figure 2

View diagram source

mindmap
  root((Maintainer role))
    Interface stewardship
    Evidence stewardship
    Policy stewardship
    Reference stewardship
    Runbook stewardship
    Dependency stewardship
    Training stewardship

Maintenance cadence

Diagram loads as you read

Maintenance cadence · Figure 3

View diagram source

flowchart TB
    Daily[Daily] --> Weekly[Weekly]
    Weekly --> Monthly[Monthly]
    Monthly --> Quarterly[Quarterly]
    Quarterly --> Annual[Annual]

Cadence	Work
daily	failed collectors, provider incidents, critical alerts
weekly	contract tests, change reviews, postmortem actions
monthly	scorecards, cost trends, runbooks, training scenarios
quarterly	policy drift, provider exit readiness, reference refresh
annual	architecture review, records review, scenario reset

Reference drift

A claim that was true about a provider API, pricing model, or roadmap in one year may become false later.

Diagram loads as you read

Reference drift · Figure 4

View diagram source

flowchart LR
    Claim[Current-state claim] --> Source[Primary source]
    Source --> ReviewDate[Review date]
    ReviewDate --> StillValid{Still valid?}
    StillValid -- yes --> Keep[Keep]
    StillValid -- no --> Revise[Revise claim and reference]

Review frequency should match volatility: vendor APIs and pricing are reviewed more often than foundational papers.

Dependency drift

Diagram loads as you read

Dependency drift · Figure 5

View diagram source

flowchart TB
    Dependency[Dependency update] --> Inventory[Update inventory]
    Inventory --> Tests[Run contract tests]
    Tests --> Evidence[Compare evidence]
    Evidence --> Promote{Promote?}
    Promote -- yes --> Release[Release]
    Promote -- no --> Hold[Hold or rollback]

Use SBOM and service BOM practices where appropriate, but extend them with execution BOM fields: compiler profile, runtime options, target snapshot, calibration epoch, mitigation profile, and evidence validators. CycloneDX provides a useful vocabulary for BOMs and attestations. [R178]

Runbook maintenance

Diagram loads as you read

Runbook maintenance · Figure 6

View diagram source

stateDiagram-v2
    [*] --> Draft
    Draft --> Tested
    Tested --> Active
    Active --> Stale: not exercised
    Stale --> Revised
    Revised --> Tested
    Active --> Retired

Runbook review questions:

Was the procedure used or drilled recently?
Are commands, dashboards, owners, and providers current?
Does it preserve evidence before mutation?
Does rollback still work?
Are escalation paths current?
Is it short enough for incident use?

Maintainer dashboard

Diagram loads as you read

Maintainer dashboard · Figure 7

View diagram source

flowchart LR
    Signals[Drift and debt signals] --> Dashboard[Maintainer dashboard]
    Dashboard --> Debt[Operational debt]
    Dashboard --> Risks[Emerging risks]
    Dashboard --> Actions[Maintenance actions]

Minimum indicators: stale references, failing contract tests, unresolved postmortem actions, orphan evidence artifacts, provider API changes, runbook exercise age, and scorecard regressions.

Retirement discipline

Diagram loads as you read

Retirement discipline · Figure 8

View diagram source

flowchart TB
    Candidate[Retirement candidate] --> Impact[Impact analysis]
    Impact --> Evidence[Evidence dependency check]
    Evidence --> Notice[Notice and migration path]
    Notice --> Disable[Disable]
    Disable --> Archive[Archive or delete]

The platform should not keep every path runnable forever, but it should preserve enough context to explain past claims.

Operating rule

A quantum platform that cannot be reviewed, patched, retired, and explained over years is not ready for serious work.