Resilience Engineering for Quantum Control Planes

A quantum control plane has to keep operating when providers fail, queues saturate, calibration windows shift, telemetry pipelines lag, simulator capacity disappears, or policy services reject a workload. Resilience is not just uptime. It is the ability to anticipate, withstand, recover from, and adapt to adverse conditions while preserving evidence and preventing unsafe execution. NIST SP 800-160 Volume 2 frames cyber resiliency as a systems-engineering discipline applied across the life cycle. [R181]

Diagram loads as you read

Resilience Engineering for Quantum Control Planes · Figure 1

View diagram source

flowchart LR
    Anticipate[Anticipate] --> Withstand[Withstand]
    Withstand --> Recover[Recover]
    Recover --> Adapt[Adapt]
    Adapt --> Anticipate

Resilience objectives

Objective	Quantum interpretation
preserve safe control	block unsafe pulses, stale calibration, and unauthorized overrides
preserve evidence	keep enough records to reconstruct what happened
preserve scientific validity	avoid silently changing inference assumptions during recovery
preserve availability	route to suitable alternatives where meaningful
preserve cost control	prevent retry storms and runaway shot consumption
preserve trust	explain degraded confidence to users

Diagram loads as you read

Resilience objectives · Figure 2

View diagram source

mindmap
  root((Quantum resilience))
    Safe control
    Evidence preservation
    Scientific validity
    Availability
    Cost control
    User trust

Failure classes

Diagram loads as you read

Failure classes · Figure 3

View diagram source

flowchart TB
    Failure[Control-plane failure] --> Provider[Provider outage]
    Failure --> Queue[Queue or reservation failure]
    Failure --> Policy[Policy service failure]
    Failure --> Telemetry[Telemetry lag]
    Failure --> Evidence[Evidence store degradation]
    Failure --> Compiler[Compiler regression]
    Failure --> Calibration[Calibration invalidation]

The control plane should know which failures are fail-closed and which are fail-open. Unsafe physical control, missing evidence, and disallowed data residency should fail closed. Cosmetic dashboards can fail open. Simulator overflow can degrade to delayed execution.

Degradation modes

Diagram loads as you read

Degradation modes · Figure 4

View diagram source

flowchart LR
    Normal[Normal service] --> Degraded[Degraded service]
    Degraded --> ReadOnly[Read-only evidence]
    Degraded --> SimulatorOnly[Simulator-only mode]
    Degraded --> LowRisk[Low-risk workload only]
    Degraded --> QueueOnly[Queue without execution]

Mode	Allowed	Blocked
simulator-only	compilation, dry runs, CI checks	hardware claims
evidence read-only	inspection, audit, export	mutation
low-risk workload only	public examples, training workloads	sensitive or high-cost jobs
queue-only	reserve intent and validate contracts	execution
manual approval	emergency runs with signed waiver	autonomous remediation

Resilience architecture

Diagram loads as you read

Resilience architecture · Figure 5

View diagram source

flowchart TB
    User[User or product service] --> Gateway[Quantum API gateway]
    Gateway --> Policy[Policy and risk engine]
    Gateway --> Broker[Provider broker]
    Broker --> Providers[Providers and simulators]
    Gateway --> Evidence[Evidence service]
    Gateway --> Telemetry[Telemetry service]
    Policy --> Mode[Degradation mode manager]
    Telemetry --> Mode
    Evidence --> Mode
    Mode --> Gateway

The degradation-mode manager should be a small, auditable component. It should not depend on the same failing service it is judging.

Recovery without evidence loss

Diagram loads as you read

Recovery without evidence loss · Figure 6

View diagram source

sequenceDiagram
    participant Runtime
    participant Evidence
    participant Broker
    participant Reviewer
    Runtime->>Evidence: Write partial execution record
    Runtime--xBroker: Provider call fails
    Broker->>Evidence: Append failure and target snapshot
    Broker->>Reviewer: Request recovery decision
    Reviewer->>Broker: Retry, reroute, or abort
    Broker->>Evidence: Append recovery action

Recovery should create more evidence, not less. A failed execution still teaches the platform which provider, target, calibration, compiler, policy, and runtime combination failed.

Retry governance

Retrying a quantum workload is not neutral. A retry may encounter a new calibration epoch, a different queue time, a changed backend target, or a different noise profile.

Diagram loads as you read

Retry governance · Figure 7

View diagram source

flowchart LR
    Failure[Execution failure] --> SameEpoch{Same calibration epoch?}
    SameEpoch -- yes --> Retry[Controlled retry]
    SameEpoch -- no --> Revalidate[Revalidate workload contract]
    Revalidate --> NewEvidence[New evidence package]

A retry budget should include maximum attempts, maximum additional shots, allowed calibration drift, allowed target substitutions, and claim invalidation rules.

Resilience drills

Diagram loads as you read

Resilience drills · Figure 8

View diagram source

timeline
    title Quarterly Quantum Resilience Drill
    Week 1 : provider outage drill
    Week 2 : evidence-store failover
    Week 3 : stale-calibration injection
    Week 4 : post-drill review

Drills should test the boring parts: who can approve degraded mode, who can revoke a provider route, whether evidence remains complete, whether dashboards mark results as degraded, and whether cost caps are honored.

Operational rule

The platform should degrade visibly and safely. A result produced during degraded operations must carry a degradation marker, a recovery trace, and a statement of which assumptions changed.

Diagram loads as you read

Operational rule · Figure 9

View diagram source

flowchart LR
    DegradedRun[Degraded run] --> Marker[Degradation marker]
    Marker --> Trace[Recovery trace]
    Trace --> Assumptions[Changed assumptions]
    Assumptions --> Claim[Bounded claim]