Quantum Chaos Engineering and Resilience Testing

Classical chaos engineering tests whether a distributed system withstands turbulent conditions. Quantum platforms need the same instinct, but the fault model is broader. Jobs can fail because a cloud API is down, a reservation is lost, a target is recalibrating, a compiler profile changed, a calibration snapshot is stale, a pulse path is disabled, a mitigation routine overcorrects, or a result warehouse loses metadata.

Quantum chaos engineering is not random damage to a lab. It is controlled fault injection into the platform around the QPU. It builds confidence that the system preserves safety, evidence, and cost controls when parts of the stack degrade. NIST contingency planning, OpenTelemetry-style observability, and chaos-engineering principles provide useful background for designing these exercises. [R142]

Diagram loads as you read

Quantum Chaos Engineering and Resilience Testing · Figure 1

View diagram source

flowchart LR
    Hypothesis[Resilience hypothesis] --> Drill[Controlled drill]
    Drill --> Observe[Observe behavior]
    Observe --> Learn[Identify gaps]
    Learn --> Fix[Fix controls]
    Fix --> Repeat[Repeat with larger scope]

Quantum fault domains

Diagram loads as you read

Quantum fault domains · Figure 2

View diagram source

flowchart TB
    Faults[Quantum platform faults] --> Provider[Provider and cloud faults]
    Faults --> Hardware[Hardware and calibration faults]
    Faults --> Compiler[Compiler and artifact faults]
    Faults --> Data[Data and evidence faults]
    Faults --> Human[Human process faults]

    Provider --> P1[API timeout]
    Provider --> P2[queue surge]
    Hardware --> H1[target offline]
    Hardware --> H2[calibration drift]
    Compiler --> C1[pass regression]
    Compiler --> C2[target mismatch]
    Data --> D1[missing metadata]
    Data --> D2[result warehouse lag]
    Human --> U1[wrong target]
    Human --> U2[unreviewed claim]

Start with hypotheses

A chaos drill should begin with a falsifiable statement:

If the preferred QPU becomes unavailable, production jobs fall back to simulator mode or an approved alternate target.
If calibration freshness exceeds the policy threshold, high-sensitivity jobs stop before execution.
If result metadata ingestion fails, the platform does not publish a claim.
If a compiler plugin is revoked, dependent workloads are blocked or recompiled.

Diagram loads as you read

Start with hypotheses · Figure 3

View diagram source

flowchart LR
    Fault[Injected fault] --> Expected[Expected safe behavior]
    Expected --> Metric[Observable metric]
    Metric --> Threshold[Pass threshold]

Drill lifecycle

Diagram loads as you read

Drill lifecycle · Figure 4

View diagram source

stateDiagram-v2
    [*] --> Design
    Design --> Approve: blast radius accepted
    Approve --> Prepare: rollback ready
    Prepare --> Inject: start drill
    Inject --> Observe
    Observe --> Abort: safety threshold hit
    Observe --> Complete: hypothesis evaluated
    Abort --> Recover
    Complete --> Recover
    Recover --> Review
    Review --> [*]

A drill record should include:

hypothesis;
blast radius;
injection method;
abort condition;
expected signals;
affected teams;
rollback plan;
postmortem owner.

Safe injection points

Do not start by perturbing physical hardware. Start in software control planes, queues, metadata stores, and simulated providers.

Diagram loads as you read

Safe injection points · Figure 5

View diagram source

flowchart TB
    Injection[Fault injection points] --> Safe[Low physical risk]
    Injection --> Medium[Medium operational risk]
    Injection --> High[High physical risk]
    Safe --> S1[Mock provider API failure]
    Safe --> S2[metadata ingest delay]
    Safe --> S3[policy denial fixture]
    Medium --> M1[reservation conflict]
    Medium --> M2[compiler rollback]
    Medium --> M3[calibration staleness]
    High --> H1[control electronics perturbation]
    High --> H2[cryogenic event]

High physical-risk drills require lab safety review, vendor coordination, and explicit stop conditions.

Fallback behavior

The most common resilience mistake is failing open. Quantum platforms should fail safe.

Diagram loads as you read

Fallback behavior · Figure 6

View diagram source

flowchart LR
    Request[Request] --> TargetOK{Target usable?}
    TargetOK -- yes --> Execute[Execute]
    TargetOK -- no --> Alternative{Approved fallback?}
    Alternative -- simulator --> Sim[Run simulator]
    Alternative -- alternate QPU --> Alt[Route to alternate]
    Alternative -- none --> Hold[Hold and notify]

Fallbacks must preserve the semantics of the result. A simulator fallback cannot silently replace a hardware run if the claim requires hardware evidence.

Observability for drills

The platform should emit drill-specific telemetry.

Diagram loads as you read

Observability for drills · Figure 7

View diagram source

flowchart LR
    Drill[Drill event] --> Trace[Trace annotations]
    Drill --> Metric[Metrics]
    Drill --> Log[Structured logs]
    Drill --> Evidence[Evidence package]
    Trace --> Review[Post-drill review]
    Metric --> Review
    Log --> Review
    Evidence --> Review

Useful metrics:

Metric	Purpose
time_to_detect	Whether monitoring saw the fault
time_to_safe_state	Whether guardrails converged quickly
invalid_jobs_admitted	Admission-control failure indicator
evidence_loss_count	Data-governance failure indicator
fallback_success_rate	Continuity indicator
cost_overrun_units	FinOps failure indicator

Calibration chaos

Calibration is a special fault domain because it can degrade correctness without obvious availability failure.

Diagram loads as you read

Calibration chaos · Figure 8

View diagram source

sequenceDiagram
    participant Drill as Drill controller
    participant Policy as Policy engine
    participant Runtime as Runtime
    participant Warehouse as Evidence warehouse

    Drill->>Policy: Mark calibration snapshot stale in fixture
    Runtime->>Policy: Request high-sensitivity execution
    Policy-->>Runtime: Deny or require review
    Runtime->>Warehouse: Record blocked execution

A calibration chaos drill should never falsify vendor telemetry in production without clear labeling. Use test tenants, fixtures, or shadow admission paths first.

Result-governance chaos

Inject faults into evidence collection, not only execution.

Diagram loads as you read

Result-governance chaos · Figure 9

View diagram source

flowchart TB
    Job[Completed job] --> Ingest[Metadata ingest]
    Ingest --> Fail{Injected failure}
    Fail -- missing calibration --> Quarantine[Quarantine result]
    Fail -- missing shots --> Requeue[Requeue download]
    Fail -- missing policy decision --> Hold[Hold publication]
    Fail -- no fault --> Publish[Eligible for review]

Game-day cadence

Diagram loads as you read

Game-day cadence · Figure 10

View diagram source

gantt
    title Quarterly Quantum Resilience Game Day
    dateFormat  YYYY-MM-DD
    section Prepare
    Select hypothesis           :a1, 2026-04-01, 2d
    Approve blast radius        :a2, after a1, 1d
    section Execute
    Inject fault                :b1, 2026-04-08, 1d
    Monitor and recover         :b2, after b1, 1d
    section Learn
    Postmortem                  :c1, 2026-04-10, 2d
    Remediation tracking        :c2, after c1, 7d

Operating rule

Do not claim platform resilience because a dashboard is green. Claim resilience only after controlled failures prove that the platform reaches a safe state.