Traceability Across Quantum Hybrid Executions — Operating Quantum Computers

Hybrid quantum workloads are distributed traces with physics in the middle. A single result may involve a notebook, optimizer, parameter store, compiler, queue, provider runtime, control system, measurement pipeline, mitigation service, and evidence store. Without traceability, the team cannot explain latency, cost, drift, or correctness.

W3C Trace Context defines portable traceparent and tracestate headers for propagating trace identity across systems [R215]. Quantum platforms should adapt the same idea across HTTP services, batch jobs, notebooks, provider connectors, and evidence artifacts.

Diagram loads as you read

Traceability Across Quantum Hybrid Executions · Figure 1

View diagram source

flowchart LR
    Notebook[Notebook] --> Optimizer[Classical optimizer]
    Optimizer --> Compiler[Compiler]
    Compiler --> Scheduler[Scheduler]
    Scheduler --> Provider[Provider runtime]
    Provider --> QPU[QPU execution]
    QPU --> Results[Results pipeline]
    Results --> Mitigation[Mitigation]
    Mitigation --> Evidence[Evidence package]

Span model

A quantum trace should not treat QPU time as one opaque span. It should represent the full operational path.

Diagram loads as you read

Span model · Figure 2

View diagram source

flowchart TB
    Root[experiment.run] --> Prep[problem.prepare]
    Root --> Compile[circuit.compile]
    Root --> Admit[admission.evaluate]
    Root --> Queue[job.queue]
    Root --> Execute[qpu.execute]
    Execute --> Cal[calibration.bind]
    Execute --> Shots[shots.collect]
    Root --> Post[postprocess.infer]
    Root --> Evidence[evidence.write]

Useful spans include compilation, queue wait, reservation wait, runtime execution, shot collection, measurement transport, error mitigation, storage write, and review.

Context propagation

Trace context must cross protocol boundaries.

Diagram loads as you read

Context propagation · Figure 3

View diagram source

sequenceDiagram
    participant N as Notebook
    participant O as Optimizer
    participant C as Compiler
    participant S as Scheduler
    participant P as Provider connector
    participant E as Evidence store
    N->>O: traceparent
    O->>C: traceparent plus run metadata
    C->>S: traceparent plus circuit hash
    S->>P: traceparent plus job contract
    P-->>S: provider job id
    S->>E: trace id plus evidence id

Provider APIs may not preserve arbitrary trace headers. The broker should map internal trace IDs to provider job IDs and store that map in the evidence package.

Quantum-specific trace attributes

A useful span has quantum attributes, not only web attributes.

Attribute	Example
`quantum.workload.id`	`qw-2026-04-20-1192`
`quantum.circuit.hash`	`sha256:...`
`quantum.backend.family`	`superconducting-transmon`
`quantum.baseline.id`	`baseline-2026-04-20-02`
`quantum.shots.requested`	`10000`
`quantum.shots.accepted`	`8000`
`quantum.mitigation.profile`	`zne-lite-v3`
`quantum.evidence.id`	`qev-1192`

Diagram loads as you read

Quantum-specific trace attributes · Figure 4

View diagram source

flowchart LR
    Span[Trace span] --> Workload[Workload attributes]
    Span --> Runtime[Runtime attributes]
    Span --> Physics[Calibration and backend attributes]
    Span --> Cost[Cost and reservation attributes]
    Span --> Evidence[Evidence and claim attributes]

Failure localization

Traceability changes debugging from speculation to localization.

Diagram loads as you read

Failure localization · Figure 5

View diagram source

flowchart TB
    BadResult[Bad result] --> Trace[Open trace]
    Trace --> CompileSpan[Compilation span]
    Trace --> QueueSpan[Queue span]
    Trace --> ExecuteSpan[Execution span]
    Trace --> MitigationSpan[Mitigation span]
    ExecuteSpan --> Calibration[Calibration binding]
    ExecuteSpan --> Backend[Backend status]
    MitigationSpan --> Model[Mitigation model version]

A variance jump could be a compilation change, a stale calibration, a provider-side queue delay, a readout shift, an optimizer regression, or a mitigation-model change. Trace context makes the causal graph inspectable.

Sampling policy

Do not sample away traces for claim-bearing workloads.

Diagram loads as you read

Sampling policy · Figure 6

View diagram source

flowchart LR
    Workload[Workload] --> Class{Evidence class}
    Class -- exploratory --> Sample[Sample traces]
    Class -- internal benchmark --> Keep[Keep root and critical spans]
    Class -- claim-bearing --> Full[Keep full trace]
    Class -- incident --> Preserve[Preserve full trace plus logs]

Exploratory work can use sampling. Acceptance tests, customer workloads, benchmarks, and scientific claims need complete trace retention.

Trace to evidence binding

A trace is operational telemetry. An evidence package is a review artifact. Bind them explicitly.

Diagram loads as you read

Trace to evidence binding · Figure 7

View diagram source

flowchart LR
    TraceID[Trace ID] --> EvidenceManifest[Evidence manifest]
    SpanLinks[Span links] --> EvidenceManifest
    Logs[Logs] --> EvidenceManifest
    Metrics[Metrics] --> EvidenceManifest
    Artifacts[Artifacts] --> EvidenceManifest
    EvidenceManifest --> Reviewer[Reviewer]

The evidence package should include the root trace ID, span inventory, provider job ID mapping, missing-span explanation, and retention location.