跳转至

04 Canonical UQCI Model

Purpose

This chapter defines the canonical internal model of UQCI.

Canonical Ownership

The reference drafts make a sharp distinction between semantic ownership and export ownership:

  • UQCI owns semantic meaning
  • OpenQASM profiles own export level and compatibility presentation

This repository preserves that distinction. The canonical model is therefore defined in UQCI terms, not in terms of any single .qasm representation.

Canonical Program Structure

UQCIProgram is the canonical internal representation of a program. A program consists of an ordered operation list plus metadata that may influence validation, profiling, bundling, export, and execution.

The canonical program model must be able to survive editing, validation, bundling, export, and backend adaptation without losing its semantic role.

Minimal Object Surface for v0.1

The repository-native v0.1 object surface is intentionally compact. At minimum, it includes:

  • GateOp
  • PulseOp
  • MeasureOp
  • SweepOp
  • UQCIProgram
  • ExecutionPlan
  • RunResult

Future revisions may add richer timing, routing, calibration, and runtime objects. Such additions should extend the canonical model rather than bypass it.

Operation Semantics

  • GateOp expresses backend-independent logical gate intent
  • PulseOp expresses pulse-oriented control intent without requiring one universal physical carrier model
  • MeasureOp expresses classified measurement intent in a backend-neutral form
  • SweepOp expresses parameter-sweep intent without forcing one execution strategy

Together, these objects define a semantic layer that can be interpreted by validators, compatibility exporters, and backends without giving semantic authority to backend-native syntax.

Metadata and Execution Intent

The reference drafts consistently treat metadata as execution-relevant rather than merely decorative. Program metadata may influence:

  • bundle packaging
  • compatibility profile selection
  • diagnostics and traceability
  • backend hints carried through compatible extension mechanisms

Metadata may shape execution handling, but it must not be used to smuggle backend-private semantics into the canonical layer.

Backend Independence

The canonical model must avoid hard-coding:

  • vendor instruction sets
  • hardware-port identifiers as universal truth
  • one hardware family's pulse grammar as the global semantic model

This rule is particularly important because the reference architecture is intended to cover materially different physical platforms. The canonical layer must therefore describe intent at a level that survives technology diversity.

Relationship to Sidecars

The canonical program does not stand alone in practical execution. DeviceSpec and CalSet provide normative execution context, while Manifest and Bundle preserve packaging and traceability. Those artifacts complement the canonical program without displacing it.

Relationship To Schema

The canonical model should have a stable machine-readable schema surface. JSON Schema is used to formalize structure, but the semantics themselves belong to the canonical UQCI model, not to a textual export profile.

The Word drafts include a core UQCI program schema to emphasize this independence. In repository-native form, the same principle should be preserved by keeping machine-readable schemas aligned with canonical models while avoiding duplication of full schema listings in every chapter.