跳转至

11 OpenQASM Compatibility Profiles

Purpose

This chapter defines how UQCI relates to OpenQASM through compatibility profiles.

Profile Model

OpenQASM compatibility is profile-driven. The profile indicates how much timing, calibration, and UQCI-specific extension material may appear in the export surface.

This chapter inherits the central doctrine stated earlier in the specification and in the repository architecture notes:

  • UQCI IR remains canonical
  • OpenQASM remains a compatibility and exchange layer
  • OpenQASM must not be treated as the operating system itself

Compatibility profiles therefore define export envelopes, not semantic ownership.

Compatibility Layer Boundaries

The purpose of a profile is to make export expectations explicit. A profile answers questions such as:

  • whether only portable gate-level syntax is allowed
  • whether timing intent may be expressed
  • whether calibration-aware constructs may be emitted
  • whether UQCI namespaced annotations or pragmas may accompany the export

This profile-driven approach keeps compatibility practical while avoiding the false implication that one .qasm file carries the whole runtime contract.

Profiles

OQ-0 Portable Circuit

Gate-level program, measurement, and classical control only. This is the maximum-portability profile for exchange and cloud submission.

OQ-0 should be preferred when portability matters more than timing or calibration fidelity.

OQ-1 Timed Circuit

OQ-0 plus timing intent such as duration, delay, box, stretch, or related constructs required by compilers and schedulers.

OQ-1 is suitable when timing intent must survive export without moving to calibration-bound forms.

OQ-2 Calibrated Circuit

OQ-1 plus calibration-aware constructs such as defcal, cal, or OpenPulse-aligned bindings for device-specific execution contexts.

OQ-2 is intended for near-hardware or fixed-target situations in which calibration-aware export is acceptable.

OQ-X UQCI Extended

OQ-2 plus UQCI namespaced annotations, pragmas, and explicit bundle-sidecar awareness. This profile is suitable for full-stack QOS execution and deeper interoperability.

OQ-X is the most expressive repository-facing compatibility profile in v0.1, but it is still a compatibility layer rather than a replacement for canonical UQCI objects.

Extension Catalog

Examples of UQCI extensions carried alongside OpenQASM include:

  • @uqci.profile
  • @uqci.device_class
  • @uqci.bundle
  • @uqci.semantic
  • @uqci.sync.group
  • pragma uqci.calset
  • pragma uqci.shots
  • pragma uqci.capture
  • pragma uqci.routing

The reference Word drafts also list additional extension ideas such as error-budget hints, target hints, result-format hints, synchronization tags, and calibration binding markers. These should be treated as namespaced compatibility mechanisms rather than as substitutes for sidecar artifacts.

Relationship to Sidecars

Compatibility profiles do not eliminate normative sidecars. Even in higher profiles:

  • Manifest remains the bundle entry description
  • DeviceSpec remains the capability and constraint declaration
  • CalSet remains the runtime calibration context
  • Bundle remains the auditable and transferable execution package

An exported program.qasm may reference this context, but should not be expected to contain all of it inline.

Normative Rule

The OpenQASM profile is an export surface, not a replacement for UQCI. Compatibility must be additive and explicitly layered, not a quiet substitution of the canonical model.

Deferred Scope

In line with the repository doctrine, v0.1 does not require:

  • a full general-purpose OpenQASM parser
  • a universal OpenPulse compiler
  • full vendor-specific defcal coverage
  • pulse-native lowering for every backend family

The objective is a practical compatibility bridge, not exhaustive language coverage.