04 Canonical UQCI 模型¶
目的¶
本章定义 UQCI 的 canonical 内部模型。
语义归属¶
参考草案明确区分“语义归属”和“导出级别归属”：
- UQCI 负责对象与执行意图的语义含义
- OpenQASM Profile 负责导出层级与兼容呈现
因此，canonical 模型必须以 UQCI 为中心定义，而不能以任何单一 .qasm 表示为中心定义。
Canonical Program 结构¶
UQCIProgram 是 canonical 的内部程序表示。一个程序由有序操作序列及其元数据组成，这些元数据可影响验证、profile 选择、Bundle 组织、兼容导出与执行。
canonical 程序模型必须能够在编辑、验证、封装、导出与后端适配过程中持续保持其语义角色。
v0.1 的最小对象面¶
v0.1 的最小对象集合包括：
GateOpPulseOpMeasureOpSweepOpUQCIProgramExecutionPlanRunResult
未来版本可以扩展更丰富的 timing、routing、calibration 与 runtime 对象，但这些扩展应建立在 canonical 模型之上，而不是绕过它。
操作语义¶
GateOp表达与后端无关的逻辑门意图PulseOp表达脉冲级控制意图，但不强制单一物理载波模型MeasureOp以 backend-neutral 方式表达分类测量意图SweepOp表达参数扫描意图，而不绑定唯一执行策略
这些对象共同定义了一个可被验证器、兼容导出器与后端消费的语义层，而不会把语义解释权交给 backend-native 语法。
元数据与执行意图¶
参考草案始终把元数据视为与执行相关，而非纯说明性内容。程序元数据可以影响：
- Bundle 打包
- compatibility profile 选择
- 诊断与可追踪性
- 通过兼容扩展机制传递的后端提示
但元数据不得成为把 backend-private 语义偷偷塞回 canonical 层的通道。
后端无关约束¶
canonical 模型不得把以下内容硬编码为全局真相：
- 厂商专有指令集
- 单一硬件族群的端口命名
- 某一类脉冲语法作为通用语义
这一点尤其重要，因为参考架构面向的正是物理技术路线差异显著的平台。canonical 层必须描述能够跨技术路线保持稳定的执行意图。
与 Sidecar 的关系¶
canonical 程序在实际执行中并不是孤立存在的。DeviceSpec 与 CalSet 提供规范性的执行上下文，Manifest 与 Bundle 则提供封装与可追踪性。这些工件与 canonical 程序互补，但不会取代它。
与 Schema 的关系¶
canonical 模型应具有稳定的机器可读 Schema 表达。JSON Schema 用于形式化结构，但语义归属 canonical UQCI 模型本身，而非任何兼容导出 profile。
参考草案专门给出 UQCI Program Core Schema，就是为了强调这种独立性。在仓库原生形式中，这一原则应通过“模型与 Schema 对齐但不重复粘贴长清单”的方式继续保持。