Pulse-Level Governance and Optimal Control

Pulse-level control is where the abstract circuit meets the analog machine. It is also where many unsafe assumptions enter a quantum program.

A pulse is not merely a lower-level gate. It is an instrumented physical intervention with timing, bandwidth, amplitude, phase, crosstalk, thermal, and calibration consequences. OpenQASM 3 includes timing and pulse-level mechanisms, while IBM's public user-facing path has moved away from Qiskit Pulse on IBM Quantum processors toward fractional gates and other abstractions. Operators should read that as a governance signal: pulse access is powerful, but not harmless. [R85] [R94]

52.1 The pulse governance problem

flowchart LR
    Circuit[Gate-level circuit] --> Cal[Gate calibration]
    Cal --> Pulse[Pulse schedule]
    Pulse --> Hardware[Control hardware]
    Hardware --> QPU[Physical qubits]
    QPU --> Data[Measurement data]
    Data --> Update[Calibration update]
    Update --> Cal

Pulse governance controls who can change the physical intervention layer, under what evidence threshold, and with what rollback mechanism.

52.2 Pulse artifact model

Every pulse-level experiment should produce an artifact package.

pulse_artifact:
  artifact_id: pulse-x90-q17-2026-04-19T10-00Z
  owner: calibration-team
  target:
    backend: qpu-alpha
    qubits: [17]
    channels: [d17]
  waveform:
    family: drag
    amplitude: recorded
    sigma: recorded
    beta: recorded
    duration_dt: recorded
  constraints:
    max_amplitude: policy-bound
    bandwidth_limit: policy-bound
    collision_domain: [q16, q17, q18]
  validation:
    rb_result_id: rb-q17-after-pulse
    leakage_result_id: leakage-q17-after-pulse
    crosstalk_scan_id: xtalk-region-16-18
  rollout:
    status: candidate | canary | active | retired
    rollback_to: pulse-x90-q17-previous

52.3 Timing is a resource

OpenQASM timing concepts and pulse descriptions show why timing must be treated as an explicit resource, not a hidden compiler detail. Delays, duration expressions, calibrated gate bodies, and control-flow interactions affect whether a physical program is valid. [R94]

sequenceDiagram
    participant Gate as Gate operation
    participant Delay as Delay/duration logic
    participant Pulse as Pulse calibration
    participant Ctrl as Controller schedule
    participant Q as Qubit state

    Gate->>Pulse: Resolve calibrated body
    Delay->>Ctrl: Reserve timing slot
    Pulse->>Ctrl: Emit waveform events
    Ctrl->>Q: Apply timed control
    Q-->>Ctrl: Measurement capture

A production compiler should output a timing report, not just a gate count.

52.4 Optimal control loop

Optimal control searches a continuous parameter space. It can improve performance, but it can also overfit to transient device conditions.

flowchart TB
    Objective[Define objective\nfidelity, leakage, robustness] --> Bounds[Set safe bounds]
    Bounds --> Candidate[Generate pulse candidate]
    Candidate --> Sim[Simulate or emulate]
    Sim --> Execute[Execute calibration experiment]
    Execute --> Score[Score result]
    Score --> Accept{Accept?}
    Accept -- no --> Candidate
    Accept -- yes --> Canary[Canary rollout]
    Canary --> Monitor[Monitor drift and regressions]

The operator's question is not whether a pulse improved one metric once. It is whether the pulse improves the operating envelope.

52.5 Approval gates

flowchart LR
    Candidate[Pulse candidate] --> SimGate[Simulation gate]
    SimGate --> CalGate[Calibration gate]
    CalGate --> LeakGate[Leakage gate]
    LeakGate --> XtalkGate[Crosstalk gate]
    XtalkGate --> WorkloadGate[Workload gate]
    WorkloadGate --> Rollout[Rollout]

52.6 Pulse registry

A pulse registry should behave like an artifact repository plus a safety database.

classDiagram
    class PulseArtifact {
      id
      waveform_family
      parameters_hash
      target_qubits
      channels
      safety_bounds
      validation_status
      rollout_state
    }
    class CalibrationSnapshot {
      id
      timestamp
      backend
      metrics
    }
    class ValidationRun {
      id
      benchmark_type
      result
      confidence
    }
    PulseArtifact --> CalibrationSnapshot
    PulseArtifact --> ValidationRun

52.7 Relationship to fractional gates

When a provider exposes fractional gates or other higher-level constructs instead of raw pulse access, treat that as a managed-control product. The provider retains responsibility for more of the analog layer, while the user gains safer portability but loses some optimization freedom. IBM's pulse migration guidance is an example of this abstraction shift. [R85]

flowchart LR
    RawPulse[Raw pulse access] -->|more control| Expert[Expert optimization]
    RawPulse -->|more risk| Safety[Safety burden]
    Fractional[Fractional/native gates] -->|less analog burden| Portability[Portability]
    Fractional -->|less control| Provider[Provider-managed calibration]

52.8 Anti-patterns

Avoid these patterns:

• optimizing a pulse against one benchmark and declaring global improvement
• promoting a pulse without neighbor and drift analysis
• failing to bind pulse artifacts to calibration snapshots
• mixing pulse-level changes with compiler changes without isolation
• allowing notebook-only pulse experiments to become production dependencies

flowchart TD
    Anti[Pulse anti-pattern] --> OneMetric[One-metric promotion]
    Anti --> NoSnapshot[No calibration snapshot]
    Anti --> HiddenChange[Mixed compiler/control changes]
    Anti --> NoRollback[No rollback artifact]
    Anti --> Notebook[Notebook-only provenance]

Pulse work is hardware engineering. It needs software discipline, but it cannot be governed like ordinary software alone.