Quantum Incident Forensics and Root-Cause Analysis

Most production incident programs assume that the failed system can be replayed. Quantum platforms violate that assumption. A failed result may involve a drifting device, a changed calibration, a compiler regression, a queue-policy change, a firmware timing error, a provider-side outage, a corrupted evidence package, or an invalid scientific assumption. The incident process has to preserve enough context to reconstruct the chain of reasoning, even when the quantum state itself is gone.

This chapter treats incident forensics as an operating discipline. It extends the incident-response framing in [R161] and the recovery-planning framing in [R162] to quantum platform operations.

flowchart LR
    Symptom[Symptom] --> Freeze[Freeze evidence]
    Freeze --> Classify[Classify incident]
    Classify --> Hypotheses[Build hypotheses]
    Hypotheses --> Tests[Run confirmation tests]
    Tests --> Cause[Root cause statement]
    Cause --> Fix[Corrective action]
    Fix --> Learn[Learning artifact]

What counts as a quantum incident

A quantum incident is any event that invalidates the expected relationship between workload intent, execution conditions, measurement distribution, evidence, and claim. It does not need to be a security breach. It may be a scientific validity failure.

mindmap
  root((Quantum incident))
    Physics
      drift
      crosstalk
      readout
    Software
      compiler
      SDK
      runtime
    Operations
      queue
      reservation
      calibration window
    Evidence
      missing provenance
      inconsistent artifacts
    Governance
      access
      residency
      claims

Evidence must be frozen before interpretation

The first mistake in a quantum incident is rerunning the workload before preserving the original context. A rerun is useful, but it is not the same experiment. The device may have changed, the queue may have changed, and the calibration state may have been overwritten.

A freeze captures the minimum forensics package:

• workload contract and business or research intent
• circuit, Hamiltonian, annealing schedule, or analog program
• compiler version, target model, and pass configuration
• backend properties, calibration snapshot, and queue state
• raw counts, readout data, mitigation configuration, and post-processing code
• provider, region, reservation, and identity context
• claim or decision that depended on the result

flowchart TB
    Incident[Incident detected] --> Snapshot[Snapshot artifacts]
    Snapshot --> Hash[Hash and sign package]
    Hash --> Seal[Seal immutable evidence]
    Seal --> Branch{Need rerun?}
    Branch -- yes --> Rerun[Rerun as separate experiment]
    Branch -- no --> Analyze[Analyze original evidence]
    Rerun --> Analyze

Incident timeline reconstruction

A useful timeline distinguishes observed events from inferred causes. That separation prevents teams from turning the first plausible explanation into the final explanation.

sequenceDiagram
    participant Submitter
    participant Platform
    participant Compiler
    participant Provider
    participant Evidence
    participant Reviewer
    Submitter->>Platform: submit workload contract
    Platform->>Compiler: compile to target
    Compiler-->>Platform: circuit and metadata
    Platform->>Provider: execute job
    Provider-->>Platform: counts and backend metadata
    Platform->>Evidence: store package
    Reviewer->>Evidence: detect anomaly
    Reviewer->>Platform: open incident

A timeline should record clock times, system events, calibration state changes, job-state transitions, and human decisions. For sensitive or regulated workflows, the timeline also records the approval path and access-control state.

Hypothesis-driven root cause analysis

Quantum incidents rarely have one cause. Treat root cause analysis as competing hypotheses with evidence weights. The goal is not to produce an elegant story. The goal is to explain why this result was possible and what must change to reduce recurrence.

flowchart LR
    H1[H1: device drift] --> T1[Test: sentinel circuits]
    H2[H2: compiler regression] --> T2[Test: compile old and new targets]
    H3[H3: mitigation bias] --> T3[Test: raw vs mitigated distribution]
    H4[H4: evidence corruption] --> T4[Test: hash and lineage audit]
    T1 --> Decision{Best supported cause?}
    T2 --> Decision
    T3 --> Decision
    T4 --> Decision

Quantum-specific containment

Containment must avoid hiding the signal. The safest default is to freeze affected targets or workload classes, not the entire platform. Overbroad freezes waste scarce capacity and can obscure the actual failure domain.

flowchart TD
    IncidentClass{Incident class} -->|single-qubit drift| Mask[Mask affected qubits]
    IncidentClass -->|compiler pass| Pin[Pin compiler version]
    IncidentClass -->|runtime control| Disable[Disable dynamic-circuit feature]
    IncidentClass -->|evidence failure| Hold[Hold claims and publications]
    IncidentClass -->|access issue| Block[Block provider route]
    Mask --> Monitor[Monitor containment]
    Pin --> Monitor
    Disable --> Monitor
    Hold --> Monitor
    Block --> Monitor

Containment records should state the blast radius, temporary controls, rollback trigger, and owner. If containment changes scientific conclusions, the evidence package must record that later results are not identical to the original run.

Postmortems that improve the platform

A postmortem is not complete when it names a person, a faulty vendor, or a flaky qubit. It is complete when it changes the operating system: admission control, calibration release gates, compiler pinning, evidence schema, dashboards, runbooks, or claim-review policy.

flowchart LR
    RCA[Root cause] --> Control[Preventive control]
    Control --> Detection[Detection improvement]
    Detection --> Runbook[Runbook update]
    Runbook --> Exercise[Future drill]
    Exercise --> Metrics[Metric review]

A good quantum postmortem includes:

1. factual timeline
2. impacted workloads and claims
3. evidence package inventory
4. root-cause hypotheses considered
5. reason the winning hypothesis is preferred
6. corrective actions and owners
7. recurrence signals
8. decision on whether previous claims must be amended

Operating rule

Do not let a quantum incident become folklore. Preserve the evidence, test competing explanations, and convert the lesson into executable platform controls.