Quantum platforms depend on scarce hardware, vendor roadmaps, cloud services, specialized facilities, and fast-changing software stacks. Business continuity is therefore not an afterthought. It is a core operating requirement.
NIST contingency-planning guidance emphasizes preparation for disruptions, recovery priorities, and continuity across the system lifecycle [R117]. Quantum platforms need the same discipline, extended to physical targets, provider access, calibration state, and evidence retention.
66.1 Continuity scope
View diagram source
flowchart TB
Continuity[Quantum continuity] --> Cloud[Cloud service access]
Continuity --> QPU[QPU availability]
Continuity --> Data[Evidence and data]
Continuity --> Toolchain[Toolchain dependencies]
Continuity --> Talent[Specialized operators]
Continuity --> Vendor[Vendor contracts]A continuity plan should cover both production services and research programs. The failure of a research evidence store can be as damaging as a runtime outage.
66.2 Failure scenarios
View diagram source
flowchart LR
Scenario[Scenario] --> Provider[Provider outage]
Scenario --> Target[Target retired]
Scenario --> Queue[Queue unavailable]
Scenario --> Tool[SDK breaking change]
Scenario --> Data[Data loss]
Scenario --> Staff[Key staff unavailable]
Scenario --> Contract[Contract termination]Scenario planning should be concrete: which workloads stop, which claims become unreproducible, and which customers or internal decisions are affected?
66.3 Dependency map
View diagram source
flowchart TB
Product[Quantum product / program] --> Runtime[Runtime provider]
Product --> SDK[SDK and compiler]
Product --> Storage[Artifact storage]
Product --> IAM[Identity and access]
Product --> Baselines[Classical baselines]
Product --> Review[Review process]
Runtime --> QPU[QPU target]
SDK --> IR[IR / language]Every dependency should have an owner, recovery target, and substitute strategy.
66.4 Recovery classes
View diagram source
stateDiagram-v2
[*] --> Normal
Normal --> Degraded: provider or target issue
Degraded --> AlternateTarget: route to substitute
Degraded --> ClassicalFallback: serve baseline
AlternateTarget --> Normal: primary restored
ClassicalFallback --> Normal: quantum path restored
Normal --> Suspended: evidence riskRecovery does not always mean immediate quantum execution. For many services, a classical fallback with clear labeling is better than a blocked workflow.
66.5 Exit strategy
View diagram source
flowchart LR
VendorA[Vendor A] --> Portable[Portable artifacts]
Portable --> VendorB[Vendor B]
Portable --> Simulator[Simulator]
Portable --> Archive[Long-term archive]Exit strategy is not disloyalty to a vendor. It is risk management.
Minimum exit artifacts:
- source code
- manifest schemas
- circuit or workload artifacts
- target profiles
- IR where available
- raw and processed results
- evidence packages
- cost and performance baselines
- review decisions
66.6 Portability tiers
View diagram source
flowchart TB
Portability[Portability] --> Source[Source portability]
Portability --> IR[IR portability]
Portability --> Runtime[Runtime portability]
Portability --> Evidence[Evidence portability]
Portability --> Claim[Claim portability]| Tier | Meaning |
|---|---|
| Source portability | code can be adapted elsewhere |
| IR portability | intermediate representation preserves enough intent |
| Runtime portability | workload can run under another provider contract |
| Evidence portability | old results remain interpretable outside vendor tools |
| Claim portability | claim remains valid under changed target or baseline |
QIR and OpenQASM can help with portability, but neither eliminates target-specific behavior [R110] [R112]. Portability remains an operating practice.
66.7 Evidence escrow
View diagram source
sequenceDiagram
participant Platform as Platform
participant Store as Primary store
participant Escrow as Escrow archive
participant Auditor as Auditor
Platform->>Store: write evidence package
Store->>Escrow: replicate signed package
Auditor->>Escrow: verify hash and retention
Escrow-->>Auditor: integrity reportFor important claims, evidence should survive provider account loss, project reorganization, and toolchain drift.
66.8 Continuity tests
View diagram source
flowchart LR
Test[Continuity test] --> Restore[Restore evidence]
Test --> Replay[Replay workflow]
Test --> Reroute[Reroute target]
Test --> Fallback[Exercise classical fallback]
Test --> Access[Recover access]Do not wait for an incident to discover that the team cannot reconstruct a result.
Suggested tests:
- restore an evidence package from archive
- rerun a canonical workflow on a simulator
- reroute a small workload to an alternate provider
- rebuild environment from lock files
- exercise classical fallback
- verify access recovery for key operators
66.9 Business impact analysis
View diagram source
flowchart TB
Workload[Workload] --> Impact{Impact if unavailable}
Impact --> Revenue[Revenue]
Impact --> Research[Research milestone]
Impact --> Customer[Customer promise]
Impact --> Compliance[Compliance]
Impact --> Reputation[Reputation]Quantum work often starts in research, where continuity is informal. As soon as a workflow supports customer promises, investment decisions, or public claims, continuity planning must become formal.
66.10 Operating rule
A quantum platform is mature when it can survive the loss of a target, provider, toolchain version, or key operator without losing its evidence or its decision path.
View diagram source
flowchart LR
Disruption[Disruption] --> Continuity[Continuity plan]
Continuity --> Evidence[Evidence preserved]
Continuity --> Service[Service degraded gracefully]
Continuity --> Learning[Lessons incorporated]Continuity is not pessimism. It is what makes long-horizon quantum investment credible.