Deterministic Replay and Time-Travel Debugging

Quantum measurement outcomes are generally probabilistic, although some ideal circuits have definite outcomes. Re-running a preparation does not reproduce a historical sequence of random measurement results. The classical experiment envelope can instead preserve the workload contract, source artifact, compiler version, target model, available calibration metadata, shot budget, mitigation profile, classical random seeds, provider job, and analysis pipeline. Replaying saved classical data is distinct from executing a new physical experiment.

Time-travel debugging is the ability to ask: what did the platform believe was true at the time this result was accepted?

Diagram loads as you read

Deterministic Replay and Time-Travel Debugging · Figure 1

View diagram source

flowchart LR
    Result[Accepted result] --> Envelope[Replay envelope]
    Envelope --> Code[Code and dependencies]
    Envelope --> Compile[Compiler and target]
    Envelope --> Cal[Calibration baseline]
    Envelope --> Runtime[Runtime settings]
    Envelope --> Analysis[Analysis pipeline]
    Analysis --> Replay[Replay or reconstruct]

Replay levels

Not all replay is the same. The platform should label replay strength.

Level	Name	What is replayed	Use
L0	metadata replay	IDs, timestamps, owners, provider job metadata	audit triage
L1	analysis replay	raw counts through analysis pipeline	result verification
L2	simulation replay	compiled circuit on simulator/noise model	regression testing
L3	provider replay	same provider family and compatible backend	drift-aware reproduction
L4	historical reconstruction	archived artifacts, environment, and available calibration context	claim review; does not restore past physical hardware state

Diagram loads as you read

Replay levels · Figure 2

View diagram source

flowchart TB
    L0[L0 metadata] --> L1[L1 analysis]
    L1 --> L2[L2 simulation]
    L2 --> L3[L3 provider replay]
    L3 --> L4[L4 historical reconstruction]

Replay envelope

A replay envelope should be a durable artifact, not a best-effort query over logs. It should include the provenance concepts needed to reason about entities, activities, and agents. The W3C PROV data model is a useful generic frame because it represents how data, activities, and responsible agents relate [R239].

Illustrative listing · yaml

replay_envelope:
  envelope_id: replay-2026-05-00127
  result_id: qres-8e17
  workload_hash: sha256:...
  circuit_hash: sha256:...
  compiled_circuit_hash: sha256:...
  compiler:
    name: platform-transpiler
    version: 2026.05.0
    target_id: superconducting-grid-v4
  runtime:
    primitive: sampler
    version: v2
    shots: 20000
  calibration:
    baseline_id: cal-2026-05-04T03:12Z
    valid_from: 2026-05-04T03:12Z
    valid_until: 2026-05-04T05:12Z
  analysis:
    container_digest: sha256:...
    notebook_retired: true

What must be frozen

Diagram loads as you read

What must be frozen · Figure 3

View diagram source

flowchart TB
    Replayable[Replayable result] --> Inputs[Inputs]
    Replayable --> Transforms[Transforms]
    Replayable --> Context[Context]
    Replayable --> Outputs[Outputs]
    Inputs --> Problem[Problem definition]
    Inputs --> Circuit[Circuit source]
    Transforms --> Compiler[Compiler pipeline]
    Transforms --> Mitigation[Mitigation pipeline]
    Context --> Calibration[Calibration snapshot]
    Context --> Backend[Backend properties]
    Outputs --> Counts[Counts]
    Outputs --> Evidence[Evidence package]

The frozen set should be sufficient to distinguish scientific disagreement from operational drift. If a replay changes because the default compiler changed, the platform should not call that a scientific replication failure. It is a platform-change effect.

Time-travel queries

The control room should support queries such as:

Illustrative listing · sql

-- Which accepted claims depend on mitigation profile zne.v1?
SELECT claim_id, workload_id, accepted_at
FROM evidence_claims
WHERE mitigation_profile = 'zne.v1'
  AND claim_status = 'accepted';

-- Which results used a calibration baseline later marked suspect?
SELECT result_id, backend_id, calibration_baseline_id
FROM result_evidence
WHERE calibration_baseline_id IN (
  SELECT baseline_id FROM calibration_findings WHERE severity IN ('high', 'critical')
);

Diagram loads as you read

Time-travel queries · Figure 4

View diagram source

flowchart LR
    Finding[Finding] --> Query[Time-travel query]
    Query --> Affected[Affected results]
    Affected --> Replay[Replay plan]
    Replay --> Decision[Claim update]

Replay failure taxonomy

Failure	Meaning	Action
missing artifact	evidence package incomplete	quarantine claim
incompatible dependency	environment no longer buildable	reconstruct image or downgrade replay level
backend unavailable	physical system retired or changed	use simulator or compatible provider replay
calibration missing	historical context incomplete	mark result non-reconstructable
statistical mismatch	replay differs beyond tolerance	open scientific or operational investigation

Replay as release gate

Replay should not be only an incident tool. It should gate platform changes.

Diagram loads as you read

Replay as release gate · Figure 5

View diagram source

sequenceDiagram
    participant Release as Release candidate
    participant Corpus as Historical corpus
    participant Replay as Replay service
    participant Gate as Release gate
    Release->>Corpus: select representative results
    Corpus->>Replay: provide envelopes
    Replay->>Replay: run analysis and simulation replay
    Replay-->>Gate: compatibility report
    Gate-->>Release: approve, hold, or require migration notes

Operating rule

A quantum platform is not mature until it can explain old results under old assumptions. Reproducibility is not nostalgia; it is operational memory.

Additional technical sources: [R17], [R288], [R289].