Change Advisory for Calibrations, Compilers, and Runtime Targets

Quantum platforms change constantly. Calibrations are refreshed, target models are updated, compilers are patched, pulse schedules are tuned, control electronics are retimed, and cloud runtimes evolve. Classical software release practices are necessary but insufficient because a quantum release can change the physics experienced by a workload.

The goal of a quantum change-advisory process is not bureaucracy. The goal is controlled learning. The process borrows from risk-management and systems-security engineering practices in [R163] and [R164], but adapts them for calibration, compiler, and target-model change.

Diagram loads as you read

Change Advisory for Calibrations, Compilers, and Runtime Targets · Figure 1

View diagram source

flowchart LR
    Change[Proposed change] --> Scope[Scope impact]
    Scope --> Evidence[Attach evidence]
    Evidence --> Review[Review risk]
    Review --> Canary[Run canaries]
    Canary --> Gate{Gate passed?}
    Gate -- yes --> Rollout[Progressive rollout]
    Gate -- no --> Hold[Hold and revise]
    Rollout --> Monitor[Monitor regression]

Change types

Every change needs a declared type. Type drives review depth, canary selection, rollback strategy, and communication.

Change type	Examples	Risk
calibration	gate amplitude, readout discriminator, frequency update	quality regression
target model	coupling map, instruction durations, error estimates	compile/runtime mismatch
compiler	pass-manager change, routing heuristic, basis-gate update	invalid comparisons
pulse/control	schedule shape, timing alignment, FPGA firmware	physical instability
runtime	primitive behavior, mitigation defaults, session policy	reproducibility failure
governance	policy rule, quota, provider routing	access or cost incident
evidence	schema, retention, hash algorithm	audit breakage

Diagram loads as you read

Change types · Figure 2

View diagram source

mindmap
  root((Quantum change))
    Physical
      calibration
      pulse
      electronics
    Logical
      compiler
      target model
      runtime
    Operational
      scheduling
      quotas
      reservations
    Governance
      policy
      evidence
      claims

Compatibility contracts

A compatibility contract states what a workload may assume. It should be explicit enough that an operator can determine whether a change breaks the contract.

Diagram loads as you read

Compatibility contracts · Figure 3

View diagram source

classDiagram
    class TargetContract {
      target_id
      provider
      modality
      supported_operations
      timing_model
      calibration_epoch
      compiler_profile
      mitigation_policy
    }
    class WorkloadContract {
      workload_id
      required_operations
      max_depth
      required_fidelity_floor
      evidence_requirements
      portability_requirements
    }
    class ChangeRecord {
      change_id
      type
      expected_effect
      rollback_plan
      approval_state
    }
    WorkloadContract --> TargetContract
    ChangeRecord --> TargetContract

Compatibility is not only API compatibility. A compiler can accept the same circuit and still change the answer distribution by choosing a different layout on a drifting device.

Canary suites

Canaries are workload-shaped tests. They should include simple calibration sentinels, representative user circuits, edge-case circuits, and historical regression circuits that have failed before.

Diagram loads as you read

Canary suites · Figure 4

View diagram source

flowchart TB
    Candidate[Candidate change] --> Suite[Canary suite]
    Suite --> Physics[Physics sentinels]
    Suite --> Compiler[Compiler regressions]
    Suite --> User[Representative workloads]
    Suite --> Evidence[Evidence schema checks]
    Physics --> Score[Change scorecard]
    Compiler --> Score
    User --> Score
    Evidence --> Score

Canary	What it detects	Release decision
RB-like sentinel	broad gate-quality shift	block if outside bound
readout sentinel	assignment matrix drift	recalibrate or mark target degraded
layout sentinel	routing instability	pin compiler or update target model
workload surrogate	user-visible quality shift	canary ring only
evidence check	missing metadata	block release

Progressive rollout

Quantum releases should move through rings. Early rings use internal workloads and low-stakes experiments. Later rings include production workloads and external claims.

Diagram loads as you read

Progressive rollout · Figure 5

View diagram source

flowchart LR
    Ring0[Ring 0: lab/internal] --> Ring1[Ring 1: shadow workloads]
    Ring1 --> Ring2[Ring 2: opted-in users]
    Ring2 --> Ring3[Ring 3: default runtime]
    Ring3 --> Ring4[Ring 4: claim-eligible]

A change can be approved for one ring and denied for another. A calibration update may be safe for exploratory experiments but unsafe for a regulatory evidence run.

Rollback and roll-forward

Rollback is not always possible. A calibration can be restored logically, but the device may have physically drifted. A better term is recovery path: restore, recompile, reroute, recalibrate, or hold.

Diagram loads as you read

Rollback and roll-forward · Figure 6

View diagram source

flowchart TD
    Regression[Regression detected] --> Option{Recovery option}
    Option -->|versioned artifact| Restore[Restore previous artifact]
    Option -->|device drift| Recalibrate[Recalibrate affected region]
    Option -->|compiler issue| Pin[Pin previous compiler]
    Option -->|provider issue| Reroute[Reroute workload]
    Option -->|claim risk| Hold[Hold dependent claims]
    Restore --> Verify[Verify recovery]
    Recalibrate --> Verify
    Pin --> Verify
    Reroute --> Verify
    Hold --> Verify

Change-advisory records

A change record should be machine-readable. It is an operating artifact, not a meeting note.

Illustrative listing · yaml

change_id: qchg-2026-0419-017
change_type: compiler
scope:
  targets: [ibm_fez_like_target]
  workload_classes: [vqe, qaoa]
risk:
  user_visible: true
  evidence_affecting: true
canaries:
  required: [layout_regression_suite, vqe_surrogate_suite]
rollback:
  strategy: pin_previous_compiler_profile
approvals:
  calibration_owner: approved
  platform_owner: pending

Operating rule

Every quantum change should answer four questions before it reaches production: what changed, who is affected, how do we know it improved, and how do we recover if it did not?