BLOGE
0.9.8-RC1在线版 · 事实校验 2026-09-15 · English
第 30 章 —— 从 Case 事实到精确 Requirement Contribution
本章承诺： 为业务 Requirement 建立精确身份，把它绑定到批准的 Oracle 字节和 Expectation 语义，并解释为什么同样引用该规则的 passing Case 仍可能没有任何贡献。
学习目标
- 区分 Requirement association 与 governed contribution。
- 用显式 evaluation context 选择唯一 versioned partition。
- 绑定精确 Expectation 语义和 Oracle revision，而不只绑定名称。
- 正确读取 bootstrap 前的 governance failure，不把它叫作业务失败。
“提到规则”不等于“满足规则”
三个贷款 Case 都提到 LOAN-DECISION-001。但本次发布 obligation 是 version 3、cn-retail partition、release 2026.09。Case 即使通过，也可能因为属于 version 2、EU partition、retired Oracle、不同 Expectation digest 或 assurance depth 不足而完全不贡献。
这个区别阻断了一个简单但危险的捷径：在 report 中统计字符串，再宣布 Requirement 已满足。
建立不会碰撞的身份
schemaVersion: 1
catalogId: loan-governance
requirements:
- requirementRef: LOAN-DECISION-001
version: 3
owner: risk-policy-team
status: ACTIVE
effectiveFrom: 2026-09-01T00:00:00Z
partitions:
- partitionId: cn-retail
dimensions: {jurisdiction: CN, product: RETAIL_LOAN}
targetReleaseIds: ['2026.09']
obligations:
minimumPassingCases: 2
minimumDepth: L2
allowedOracleTypes: [APPROVED_EXAMPLE]
有效身份是：
catalogId + requirementRef + version + partitionId
GovernanceEvaluationContext 提供 asOf、target release 和有限 dimensions。必须且只能有一个 partition 适用。裸 LOAN-DECISION-001 不能借用另一个版本或市场的 evidence。
RC1 测试 producesOnlyTheExactApplicableVersionedPartitionContribution 只观察到一个 key：loan-governance / LOAN-R-017 / v3 / cn-retail，approve-low-risk 同时是 associated 与 contributing Case。同 ref 的 version 2 或 eu-retail 是不同 key。选择 release 2026.10 会返回 REQUIREMENT_NOT_APPLICABLE，且不会再次调用客户 bootstrap。
绑定答案，而不只绑定标签
binding 固定：
suiteId + caseId；- 精确
expectationIds与规范化expectationSha256； oracleId + oracleRevision与批准 artifact digest；- minimum assurance 与 allowed Oracle type。
这关闭了“名称相同、含义已变”的漏洞。在 bindsExactExpectationSemanticsAndReportsInsufficientAssurance 中，只把 expected APPROVE 改成 REVIEW，所有名称都不变，仍会在 bootstrap 前得到 INVALID / GOVERNANCE_BINDING_INVALID。把 required depth 从 L0 提高到 L4 后允许执行，但 evidence 会记录 DEPTH_INSUFFICIENT 和 contributes=false。
| Case 状态 | Associated? | Contributes? | 原因 |
|---|---|---|---|
| ref、version、partition、binding 精确匹配且 assurance 足够 | 是 | 是 | governed business evidence 匹配 |
| 同 ref、错误 partition | 文字上是 | 否 | GOVERNANCE_BINDING_MISSING |
| 名称相同、expected 语义改变 | 是 | 否 | GOVERNANCE_BINDING_INVALID |
| binding 正确、depth 不足 | 是 | 否 | DEPTH_INSUFFICIENT |
| Oracle 过期或 digest 不匹配 | 没有可用贡献 | 否 | ORACLE_GOVERNANCE_INVALID |
跟踪一个贷款 Case 通过 contribution filter
- Scenario 把
auto-approve关联到LOAN-DECISION-001。 - Evaluation context 选择 version 3、
cn-retail、release2026.09。 - Binding 找到精确 Suite、Case 和 business Expectation digest。
- Oracle catalog 匹配批准内容与 revision。
- Verifier 执行 Case，并从观察到的控制推导 assurance。
- 到这里，
verifyVersionedGoverned(Path)才输出 contribution。
Contribution 故意只属于一个 Suite。它描述该 Case 提供了什么，还不裁决跨 Project 或 module 所需的两个 Case 是否齐全。
实验：保留 ref，破坏含义
- 运行有效的 version-3
cn-retailCase，记录 Requirement key 与 contribution。 - 只把 partition context 改成 EU，确认
GOVERNANCE_BINDING_MISSING和零次 bootstrap。 - 恢复 context，只把 expected
APPROVE改成REVIEW，ID 全部保留；确认GOVERNANCE_BINDING_INVALID。 - 恢复语义，把
minimumDepth提高到 observation 之上；确认发生执行，但 contribution 因DEPTH_INSUFFICIENT被拒绝。 - 填写四列评审卡：associated、evaluated、contributes、first reason。
映射到你的业务
税务规则、医疗资格、欺诈冻结或账户注销都适用同一模型。为你的规则写一个精确身份，再指出一个同 ref Case：它必须因为市场、版本、Oracle 或 assurance 不同而不能贡献。
本章边界
- Requirement ref 只是 association hint，不是 satisfaction evidence。
- 一个 Suite contribution 无法独自满足跨 Suite 的 minimum。
- Owner label 和 approved digest 是治理事实，不是人员身份认证。
- Governance preflight failure 表示实验无效，不是客户决策 verdict。
实验验收卡
- 预期与观察： Requirement 的 identity 与 semantics 同时匹配才算 contribution。
- 失败与恢复： 保留 ref 但改变含义；恢复精确版本和语义绑定。
- 证明边界： 证明 contribution filter，不证明 Owner 已批准 Requirement。
- 练习合同： 一个 Requirement 和 Case；只改 semantics；交付 accepted/rejected；同名异义被拒绝即停止。
小结
Governance 把熟悉的 Requirement 名称变成精确 obligation，再从 passing Cases 中筛出有效 contribution。第 31 章补上完整性事实源：Project 与 Reactor child 必须来自同一冻结 cohort，之后才能推导 capability 和 gap。
下一章：第 31 章——Project、Reactor 与 Claim Capability
Coding Agent: Open the versioned task guide.