Skip to main content

BLOGE 0.9.9-RC1 在线版 · 编制 2026-11-02 · English

第六阶段回顾——业务证据

第 23–32 章始终追踪一个承诺：graph、runtime 或环境变化后，贷款决策仍应符合业务负责人批准的业务合同。

十章证据路径​

  1. 限定 claim——第 23 章。 分开 verdict、evidence trust 和 decision capability。
  2. 运行第一个故事——第 24 章。 把批准、拒绝、人工复核映射为 Suite、Case 和 Expectation。
  3. 控制输入——第 25 章。 用 Policy、Fixture、execution profile 和 assurance 拒绝假绿。
  4. 让时间可信——第 26 章。 观察 suspend、signal、resume、logical time 和 temporal contract。
  5. 杀死弱 mutant——第 27 章。 测量 suite 能否察觉选定的受控业务规则变化。
  6. 搜索有限领域——第 28 章。 把 property 展开成有限 cases，保留 counterexample，并明确 Oracle boundary。
  7. 绑定源码——第 29 章。 把 artifact 连接到 source、run cohort、seal、external receipt 和 independent reader。
  8. 精确贡献——第 30 章。 判断可信 Case 事实能否贡献给一条 versioned Requirement。
  9. 聚合同一 cohort——第 31 章。 从权威 inventory 推导 Project/Reactor completeness 与 capability，再写出剩余 gap。
  10. 归因变化——第 32 章。 冻结一个变化轴，完成 comparison，只报告现有 evidence 支持的最高发布能力。

用三个轴读取每个结果​

  • VerificationStatus：本次 Case 发生了什么——PASS、FAIL、INVALID 还是 INCOMPLETE？
  • EvidenceTrust：独立 reader 能否把结果绑定到声明的 source 和 run inputs？
  • ClaimCapability：这份 evidence 只支持 AUTHORING，还是也支持 TEAM_GATE、GOVERNED_GATE 或 RELEASE_QUALIFIED？

不要把三个轴压成一个绿色徽标。

发布负责人的快速检查​

做发布决策前，逐项指向具体事实：

  1. active Requirement version、partition、binding 和 approved Oracle closure。
  2. 完整、同 cohort 的 governed Project aggregate。
  3. 保存在可变 artifact directory 外的 source-bound child receipts。
  4. 一份可归因的 DSL_GRAPH 或 BLOGE_TOOLCHAIN comparison。
  5. 可信 external attestation 绑定 exact governed receipt、comparison receipt、change axis 和 Oracle closure。
  6. 明确的证明边界：这份 evidence 仍不能证明哪些生产事实。

缺少任何一项，就保留较低 capability，并写出 gap。不要用协商把 enum 抬高。

最终挑战：先分类，再声称​

一个 candidate build 的贷款 Cases 全部通过，并有有效 local seal；但 business Operator 和 BLOGE runtime 同时变化。report directory 里同时放着 receipt，没有 governed Project aggregate，也没有发布负责人签署的 attestation。

请这样分类：

  • Verdict： 声明的 Cases 可以是 PASS。
  • Trust： local seal 可以建立字节完整性，但同目录 custody 和缺失的 source/governance 事实无法建立发布信任链。
  • Attribution： 两因素变化不能识别单一原因。
  • Capability： AUTHORING，并明确 source、governance、comparison 和 attestation gap。

接着拆开两个变化轴，重新生成 source-bound evidence，满足 governed Requirement，并把 receipts 保存到外部。完成这些后，才能请发布负责人 assess 并签署 exact payload。

保留这张地图​

claim 混乱时回到第 23 章，需要可运行 starter 时看第 24 章，需要 counterexample 时看第 28 章，需要 trust boundary 时看第 29 章，需要精确 Requirement contribution 时看第 30 章，需要 aggregation 与 capability limit 时看第 31 章，需要 comparison 和 release decision 时看第 32 章。最后用第七阶段回顾判断这个问题是否根本需要 BLOGE。