跳转至

08 CalSet

Purpose

This chapter defines the calibration-set abstraction.

Role

CalSet is the normative runtime calibration sidecar. It carries versioned, execution-relevant calibration references that are not robustly represented as plain OpenQASM text.

The source drafts define calset.json as the versioned runtime calibration set. It is intended to hold the execution context required to realize canonical semantics on a concrete backend at a particular calibration state.

Versioning and Execution Role

CalSet should be versioned and time-qualified. At minimum, a conforming calibration set should identify:

  • calibration-set identity
  • platform type
  • generation or validity timestamp
  • optional device, site, or target applicability

This versioning role is normative because replay, audit, and reproducibility depend on knowing which runtime calibration context was used.

Typical Contents

A calibration set may include:

  • per-qubit or per-site transition parameters
  • pulse amplitudes and durations
  • detuning, phase, or wavelength references
  • readout thresholds or discriminator identifiers
  • pairwise entangler parameters
  • references to beam or channel resources

In schema-aware terms, the Word drafts organize this content into three broad areas:

  • per-target or per-site parameters
  • pairwise interaction parameters
  • references to beam, channel, or other hardware resources

Per-Target and Pairwise Parameters

Per-target calibration information may include:

  • transition frequency or effective transition frequency
  • wavelength or detuning values
  • drive amplitude
  • pulse duration
  • phase offsets
  • discriminator or threshold information

Pairwise calibration information may include:

  • entangler type
  • coupling strength
  • blockade radius
  • calibrated gate time

These values do not redefine the semantics of a program. They provide the calibrated realization context needed by compilers, drivers, and runtime execution.

Platform Examples

  • superconducting systems commonly need qubit frequency, readout frequency, drive amplitude, pulse length, and discriminator references
  • ion-trap systems may need effective transition frequencies, wavelengths, detuning values, beam identifiers, and fluorescence thresholds
  • neutral-atom systems may need Rydberg detuning, local beam maps, tweezer parameters, and imaging thresholds

These examples are intentionally diverse. They illustrate why a single textual program representation cannot safely serve as the whole runtime contract.

Relationship to DeviceSpec

DeviceSpec and CalSet are complementary rather than interchangeable:

  • DeviceSpec describes the stable capability and constraint envelope
  • CalSet describes the time-sensitive calibration and runtime realization context

Keeping those artifacts distinct helps preserve both clarity and replayability.

Normative Rule

CalSet must be versionable, replayable, and attachable to execution bundles. It exists to preserve runtime context that cannot safely be inferred from canonical program structure alone.

Implementations should therefore treat CalSet as execution input, not as incidental metadata.

Boundary Rule

CalSet provides execution references and values, not canonical program semantics. UQCI IR remains the semantic truth; CalSet supplies the runtime calibration context used to realize that truth.

Likewise, CalSet should not become a hidden container for vendor-native execution programs. Backend-native realization remains the responsibility of backend modules and drivers.