10 RunResult 与 ValidationReport¶
目的¶
本章定义标准化的执行结果与验证报告结构。
ValidationReport¶
ValidationReport 是 canonical 的验证抽象。它应提供：
- 总体成功或失败状态
- 带严重级别的结构化消息
- 稳定的消息代码
- 可选的路径信息，用于指出问题位置
验证既应覆盖结构合法性，也应覆盖与执行相关的语义约束。
验证还可能发生在多个阶段，包括：
- Bundle 与 Schema 一致性检查
- canonical 程序检查
- 针对
DeviceSpec的能力边界检查 - 针对
CalSet的校准可用性检查 - 面向 compatibility profile 的导出兼容性检查
即便底层验证器来自具体后端或具体 profile，顶层报告包络也应保持稳定。
RunResult¶
RunResult 是 canonical 的执行结果抽象。它应提供：
- backend 标识
- program 标识
- 执行状态
- measurements 或分类输出
- diagnostics
- 可扩展 metadata
在仓库实践中，结果包络还可以携带诸如 Bundle 标识、profile、shots 数、时间摘要或外部 trace 引用等执行元数据。
标准化规则¶
即便携带 backend-specific metadata，结果与验证的顶层抽象也必须保持 backend-independent。
这一点很重要，因为仓库级互操作依赖于共享的结果包络，而不是依赖某个硬件家族的特定结果格式。
扩展规则¶
未来后端可以增加更丰富的结果载荷，例如 raw IQ、photon counts、site occupancy trace、analog trace 或 vendor-native diagnostics，但这些扩展应是附加性的，而不是替换标准结果包络。
与 Compatibility Profile 的关系¶
结果与验证报告可能受到所选 compatibility profile 的影响，但不应由 profile 单独定义。例如：
- OQ-0 导出仍然可以对应标准
RunResult - OQ-X 导出可以携带更丰富的诊断或扩展元数据
- 某些验证失败可能来自所请求 profile 与 canonical 程序或 sidecar 不兼容
profile 改变的是报告上下文，而不是 canonical 报告包络是否存在。
规范写作约束¶
本章负责定义稳定的报告抽象。详细示例载荷、后端专有 trace 格式与未来诊断工件，应主要通过 examples 或开发者文档进行补充，而不应把本章扩展成结果样例大全。