02 QOS / UQCI / OpenQASM 定位¶
目的¶
本章定义 QOS、UQCI 与 OpenQASM 的体系定位。
核心分工¶
- QOS 是运行时、系统与编排层
- UQCI 是 canonical 通用量子控制协议层
- OpenQASM 是兼容层与交换层
这种分层不仅是命名偏好，更是保证规范、Schema、Bundle 与后端接入保持一致的规范性边界。
QOS 作为运行时与系统视角¶
在本规范中，QOS 表示围绕量子任务的系统级视角，涵盖任务提交、调度、资源管理、驱动协调、执行封装与结果反馈等职责。
因此，QOS 的范围天然大于任何单一程序表示语言。它是 UQCI 与兼容导出所处的系统上下文。
真源规则¶
UQCI IR 是唯一语义真源。内部验证、执行计划、Bundle 组织和后端适配都必须围绕 UQCI 对象展开，而不是围绕 OpenQASM 文本展开。
canonical 层拥有程序对象、执行意图与规范性 sidecar 关系的语义解释权。仓库中的模型、验证行为与后端契约都必须与这一层对齐。
OpenQASM 作为兼容与交换层¶
兼容规则¶
OpenQASM 是标准化导出与互换表示。它可以承载可移植电路视图或带时序的兼容视图，但不能取代 canonical UQCI 模型，也不能被描述为量子操作系统本身。
这一分工之所以重要，是因为：
- OpenQASM 对互操作、交换和既有工具链集成非常有价值
- 仅凭 OpenQASM 本身并不足以承载 QOS 导向工作流所需的全部设备、校准、执行与系统级语义
规范性 Sidecar 工件¶
Sidecar 规则¶
以下工件是规范性的，不得被降格为围绕 .qasm 文件的附属注释：
DeviceSpecCalSetManifestBundle
DeviceSpec 与 CalSet 用于保留不宜被压缩进单一程序文本的执行上下文；Manifest 与 Bundle 则承担结构化交付、可追踪与可审计职责。
Driver 与后端位置¶
参考草案还明确将 driver 层定位为 canonical 语义下降到 backend-native 执行链的边界。因此，driver 的输入应来自 UQCI 及其 sidecar，而不是把独立 .qasm 文件当作全局真相。
为什么需要这样的定位¶
这种分工使框架能够同时保持：
- core 层对后端无关
- 面向多工具链的互操作能力
- 面向多硬件路线的可扩展性
- 面向未来标准化工作的可推进性
它也避免了一种常见架构误用：把 OpenQASM 错当成整个操作模型，而不是更大控制架构中的一个兼容层。