Metrology, Timing, and Precision Measurement Workflows

Quantum computers depend on precision measurement. Timing, frequency references, microwave pulse generation, laser stability, cryogenic instrumentation, and synchronization all shape whether a computation is possible. A platform team that ignores metrology will mistake symptoms for software bugs.

OpenQASM 3 includes timing constructs, delays, durations, and pulse-level calibration concepts to describe experiments that depend on time ordering and calibrated control. Those features point to an operational reality: timing is part of the program contract, not an implementation detail. [R148]

Diagram loads as you read

Metrology, Timing, and Precision Measurement Workflows · Figure 1

View diagram source

flowchart LR
    Reference[Frequency and time reference] --> Control[Control electronics]
    Control --> Pulse[Pulse schedule]
    Pulse --> Device[Quantum device]
    Device --> Measurement[Measurement chain]
    Measurement --> Timestamp[Timestamped result]
    Timestamp --> Analysis[Analysis]

The timing stack

Diagram loads as you read

The timing stack · Figure 2

View diagram source

flowchart TB
    Timing[Timing stack] --> Clock[Clock source]
    Timing --> Sync[Synchronization]
    Timing --> Scheduler[Pulse scheduler]
    Timing --> Trigger[Trigger distribution]
    Timing --> Capture[Measurement capture]
    Timing --> Metadata[Timing metadata]

A timing fault can appear as:

lower fidelity;
unexpected phase drift;
correlated readout errors;
failed dynamic-circuit branches;
inconsistent benchmark results;
apparent crosstalk;
simulator/hardware mismatch.

Timing as a requirement

A workload should declare timing sensitivity.

Illustrative listing · yaml

workload_timing_profile:
  timing_sensitive: true
  requires_dynamic_feedback: true
  max_classical_feedback_latency_ns: 800
  requires_pulse_alignment: true
  max_clock_drift_ppb: 1
  evidence:
    - timing_trace
    - pulse_schedule_hash
    - capture_window_metadata

Diagram loads as you read

Timing as a requirement · Figure 3

View diagram source

flowchart LR
    Workload[Workload] --> TimingProfile[Timing profile]
    TimingProfile --> Capability[Target capability check]
    Capability --> Compile[Schedule-aware compile]
    Compile --> Execute[Execute]
    Execute --> Evidence[Timing evidence]

Measurement-chain observability

The measurement chain is part of the computer.

Diagram loads as you read

Measurement-chain observability · Figure 4

View diagram source

flowchart TB
    Qubit[Qubit state] --> Sensor[Readout resonator or detector]
    Sensor --> Amplifier[Amplifier]
    Amplifier --> ADC[Digitization]
    ADC --> Classifier[State classifier]
    Classifier --> Bit[Classical bit]
    Bit --> Result[Result distribution]

Operational telemetry should cover each stage where possible:

Stage	Example telemetry
signal generation	waveform ID, amplitude, phase, duration
routing	channel assignment, mixer settings, trigger path
device interaction	calibrated gate, schedule block, target qubits
capture	acquisition window, sampling rate, discriminator version
classification	confusion matrix, threshold, model version

Drift and reference integrity

Diagram loads as you read

Drift and reference integrity · Figure 5

View diagram source

flowchart LR
    Ref[Reference drift] --> PulseError[Pulse phase error]
    PulseError --> GateError[Gate error]
    GateError --> CircuitBias[Circuit bias]
    CircuitBias --> ClaimRisk[Claim risk]

Metrology review should ask whether the reference itself is stable before blaming the compiler, user program, or qubit.

Calibration hierarchy

Diagram loads as you read

Calibration hierarchy · Figure 6

View diagram source

flowchart TB
    Facility[Facility reference] --> Rack[Rack reference]
    Rack --> Controller[Controller calibration]
    Controller --> Channel[Channel calibration]
    Channel --> Gate[Gate calibration]
    Gate --> Circuit[Circuit-level validation]

A gate calibration is not independent of upstream references. Traceability matters.

Precision measurement workflow

Diagram loads as you read

Precision measurement workflow · Figure 7

View diagram source

sequenceDiagram
    participant Planner
    participant Scheduler
    participant Controller
    participant Device
    participant Analyzer

    Planner->>Scheduler: declare measurement protocol
    Scheduler->>Controller: allocate timing resources
    Controller->>Device: run timed pulse sequence
    Device-->>Controller: captured signals
    Controller-->>Analyzer: raw and classified data
    Analyzer-->>Planner: estimate + uncertainty

For high-value experiments, store raw capture summaries as well as classified bitstrings. Classification algorithms change; reanalysis may need earlier levels of evidence.

Timing incident response

Diagram loads as you read

Timing incident response · Figure 8

View diagram source

flowchart TB
    Symptom[Unexpected result] --> Check1[Check target health]
    Check1 --> Check2[Check timing trace]
    Check2 --> Check3[Check schedule hash]
    Check3 --> Check4[Check measurement classifier]
    Check4 --> Decision{Timing issue?}
    Decision -- yes --> Mitigate[Drain or restrict target]
    Decision -- no --> Continue[Continue normal triage]

Timing evidence

Timing evidence package:

Illustrative listing · yaml

timing_evidence:
  clock_profile: lab_ref_10mhz_v2
  synchronization_profile: syncnet_a
  pulse_schedule_hash: sha256:...
  controller_firmware: ctrl_fw_5.8.0
  capture_profile: readout_capture_v4
  discriminator_version: disc_2026_04_12
  max_observed_jitter_ns: 3.2

Diagram loads as you read

Timing evidence · Figure 9

View diagram source

flowchart LR
    TimingEvidence[Timing evidence] --> Firmware[Firmware]
    TimingEvidence --> Schedule[Schedule hash]
    TimingEvidence --> Clock[Clock profile]
    TimingEvidence --> Capture[Capture profile]
    TimingEvidence --> Classifier[Classifier version]

Operating rule

When a result depends on nanoseconds, timing metadata is not optional. It is part of the scientific claim.