OpenQASM¶

Purpose¶

This chapter defines the architectural positioning of QOS, UQCI, and OpenQASM.

Core Layering Statement¶

QOS is the runtime, systems, and orchestration layer.
UQCI is the canonical universal quantum control protocol layer.
OpenQASM is the compatibility and exchange layer.

This layered statement is not a naming preference only. It is the normative separation that keeps the repository coherent across specifications, schemas, bundles, and backend integrations.

QOS as the Runtime and Systems Viewpoint¶

Within this specification, QOS refers to the broader operating-system-style viewpoint around quantum workloads. That viewpoint includes responsibilities such as submission, scheduling, resource management, driver coordination, execution packaging, and result handling.

QOS is therefore broader than any single program notation. It is the systems frame in which UQCI and compatibility exports are used.

UQCI as the Canonical Protocol Layer¶

UQCI IR is the single semantic source of truth. Internal validation, planning, bundle formation, and backend adaptation must be defined in terms of UQCI objects rather than OpenQASM text.

The canonical layer owns the meaning of program objects, execution intent, and normative sidecar relationships. It is the layer against which repository models, validation behavior, and backend contracts must align.

OpenQASM as the Compatibility and Exchange Layer¶

OpenQASM is a standardized export and interchange surface. It may carry a portable or timing-aware view of a program, but it does not replace the canonical UQCI model and must not be described as the operating system itself.

This distinction is essential for two reasons:

OpenQASM is valuable for interoperability, exchange, and existing tooling
OpenQASM alone is not an adequate carrier for all device, calibration, execution, and systems-level semantics needed by QOS-oriented workflows

Normative Sidecar Artifacts¶

The following artifacts remain normative and must not be reduced to optional commentary around a .qasm file:

DeviceSpec
CalSet
Manifest
Bundle

DeviceSpec and CalSet preserve execution context that should not be forced into a single textual program representation. Manifest and Bundle preserve structure, traceability, and execution packaging.

Driver and Backend Position¶

The reference drafts also position the driver layer as the point at which canonical semantics are lowered into backend-native execution chains. Drivers therefore sit downstream of UQCI and its sidecars, not downstream of a standalone .qasm file treated as global truth.

Why This Positioning Matters¶

This split allows the repository to remain:

backend-agnostic at the core
interoperable across multiple frontend and runtime ecosystems
extensible to hardware families with materially different physical carriers
standards-friendly without overfitting to one textual language

It also prevents a recurring architectural mistake: treating OpenQASM as if it were the whole operating model rather than one compatibility surface inside a larger control architecture.