Telemetry Normalization and Cross-Stack Observability

Quantum observability fails when every layer names the same event differently. The compiler calls it a target. The provider calls it a backend. The broker calls it a device. The evidence package calls it an execution substrate. OpenTelemetry semantic conventions exist to give common names to operations and data across traces, metrics, logs, profiles, and resources [R249]. Quantum platforms need the same discipline with quantum-specific attributes.

Diagram loads as you read

Telemetry Normalization and Cross-Stack Observability · Figure 1

View diagram source

flowchart LR
    Notebook[Notebook or service] --> Broker[Broker trace]
    Broker --> Compiler[Compiler span]
    Compiler --> Runtime[Runtime span]
    Runtime --> Provider[Provider task]
    Provider --> Evidence[Evidence package]
    Evidence --> Warehouse[Experiment warehouse]

Quantum telemetry vocabulary

The following quantum.* names are proposed platform attributes, not established OpenTelemetry semantic conventions. Record the acceptance rule and rejected-shot count whenever accepted shots differ from completed shots.

Attribute	Meaning
`quantum.provider`	provider or internal platform
`quantum.backend`	concrete execution target
`quantum.runtime.mode`	job, batch, session, reservation, local, simulator
`quantum.compiler.target_version`	target model used for compilation
`quantum.calibration.baseline_id`	calibration baseline attached to execution
`quantum.shots.requested`	requested shots
`quantum.shots.completed`	shots reported as executed by the provider
`quantum.shots.accepted`	completed shots retained after a declared acceptance or postselection rule
`quantum.mitigation.profile`	error-mitigation profile
`quantum.evidence.package_id`	immutable evidence package identifier

Diagram loads as you read

Quantum telemetry vocabulary · Figure 2

View diagram source

classDiagram
    class QuantumSpan {
      trace_id
      span_id
      quantum.provider
      quantum.backend
      quantum.runtime.mode
      quantum.calibration.baseline_id
      quantum.evidence.package_id
    }
    class QuantumMetric {
      name
      unit
      attributes
      timestamp
    }
    class QuantumLog {
      severity
      body
      trace_id
      evidence_id
    }
    QuantumSpan --> QuantumMetric
    QuantumSpan --> QuantumLog

Trace boundaries

A trace should not end at the broker. It should connect the user intent to compilation, scheduling, provider execution, post-processing, and evidence publication.

Diagram loads as you read

Trace boundaries · Figure 3

View diagram source

sequenceDiagram
    participant User as User service
    participant Broker as Broker
    participant Compiler as Compiler
    participant Runtime as Runtime
    participant Provider as Provider
    participant Store as Evidence store
    User->>Broker: Submit workload with trace context
    Broker->>Compiler: Compile with trace context
    Compiler->>Runtime: Submit runtime task
    Runtime->>Provider: Provider job or reservation call
    Provider-->>Runtime: Result
    Runtime->>Store: Evidence package
    Store-->>User: Result pointer and evidence ID

Metrics that matter

Diagram loads as you read

Metrics that matter · Figure 4

View diagram source

mindmap
  root((Quantum observability))
    Availability
      backend usable
      broker healthy
      evidence store reachable
    Quality
      calibration age
      error-rate movement
      mitigation variance
    Performance
      queue time
      compile time
      execution time
      postprocess time
    Economics
      cost per accepted shot
      reservation utilization
      quota burn rate
    Trust
      evidence completeness
      trace coverage
      policy decision capture

Log correlation

OpenTelemetry logs include resource context and can be correlated with traces and metrics [R249]. Quantum logs should additionally correlate to evidence artifacts and provider job IDs, because those are often the bridge from operational observability to scientific reproducibility.

Diagram loads as you read

Log correlation · Figure 5

View diagram source

flowchart TB
    Trace[Trace ID] --> Logs[Logs]
    Trace --> Metrics[Metrics]
    Trace --> Evidence[Evidence package]
    Evidence --> ProviderJob[Provider job ID]
    Evidence --> ResultHash[Result hash]
    Evidence --> Claim[Claim or report]

Semantic versioning of telemetry

Telemetry schemas should be versioned. Breaking changes to attribute names, units, cardinality, or retention class must go through a compatibility window.

Diagram loads as you read

Semantic versioning of telemetry · Figure 6

View diagram source

stateDiagram-v2
    [*] --> DraftAttribute
    DraftAttribute --> Experimental
    Experimental --> Stable
    Stable --> Deprecated
    Deprecated --> Retired
    Experimental --> Rejected

Operating rule

Observability is not “more logs.” It is a shared language that lets operators, researchers, auditors, and customers ask the same question and receive the same answer across the entire quantum execution path.

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