Online edition for BLOGE 0.9.8-RC1 · facts verified 2026-09-15 · 中文

Chapter 30 — From Case Facts to an Exact Requirement Contribution

Chapter promise: Give a business Requirement an exact identity, bind it to approved Oracle bytes and Expectation semantics, and explain why a passing Case with the same reference may still contribute nothing.

Learning goals

1. Separate Requirement association from governed contribution.
2. Select exactly one versioned partition with an explicit evaluation context.
3. Bind exact Expectation semantics and Oracle revision, not only names.
4. Read pre-bootstrap governance failures without calling them business failures.

“Mentions the rule” is not “satisfies the rule”

Three loan Cases mention LOAN-DECISION-001. The release obligation, however, is version 3 for the cn-retail partition and release 2026.09. A Case can pass and still fail to contribute because it belongs to version 2, an EU partition, a retired Oracle, a different Expectation digest, or insufficient assurance depth.

The distinction prevents an easy but dangerous shortcut: counting strings in reports and calling the Requirement satisfied.

Build an identity that cannot collide

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]

The effective identity is:

catalogId + requirementRef + version + partitionId

GovernanceEvaluationContext supplies asOf, target release, and finite dimensions. Exactly one partition must apply. A bare LOAN-DECISION-001 cannot borrow evidence from another version or market.

RC1 test producesOnlyTheExactApplicableVersionedPartitionContribution observes one key—loan-governance / LOAN-R-017 / v3 / cn-retail—with approve-low-risk as both associated and contributing Case. The same ref at version 2 or partition eu-retail is a different key. Selecting release 2026.10 returns REQUIREMENT_NOT_APPLICABLE without another customer bootstrap.

Bind the answer, not just the label

The binding fixes:

• suiteId + caseId;
• exact expectationIds and normalized expectationSha256;
• oracleId + oracleRevision and approved artifact digest;
• minimum assurance and allowed Oracle type.

This closes the “same names, changed meaning” loophole. In bindsExactExpectationSemanticsAndReportsInsufficientAssurance, changing only expected APPROVE to REVIEW leaves all names intact but yields INVALID / GOVERNANCE_BINDING_INVALID before bootstrap. Raising required depth from L0 to L4 allows execution, but the evidence records DEPTH_INSUFFICIENT and contributes=false.

Case state	Associated?	Contributes?	Why
same ref, exact version/partition/binding, sufficient assurance	yes	yes	governed business evidence matches
same ref, wrong partition	yes in prose	no	GOVERNANCE_BINDING_MISSING
same names, changed expected semantics	yes	no	GOVERNANCE_BINDING_INVALID
exact binding, insufficient depth	yes	no	DEPTH_INSUFFICIENT
expired or digest-mismatched Oracle	no usable contribution	no	ORACLE_GOVERNANCE_INVALID

Follow one loan Case through the contribution filter

1. Scenario associates auto-approve with LOAN-DECISION-001.
2. Evaluation context selects version 3, cn-retail, release 2026.09.
3. Binding finds the exact Suite, Case, and business Expectation digest.
4. Oracle catalog matches approved content and revision.
5. Verifier executes the Case and derives assurance from observed controls.
6. Only then does verifyVersionedGoverned(Path) emit a contribution.

The contribution is deliberately local to one Suite. It says what this Case supplied; it does not yet decide whether two required Cases across projects or modules exist.

Lab: keep the ref, break the meaning

1. Run the valid version-3 cn-retail Case and record its Requirement key and contribution.
2. Change only the partition context to EU. Confirm GOVERNANCE_BINDING_MISSING and zero bootstrap calls.
3. Restore context; change only expected APPROVE to REVIEW while keeping IDs. Confirm GOVERNANCE_BINDING_INVALID.
4. Restore semantics; increase minimumDepth beyond observed assurance. Confirm execution occurs but contribution is rejected with DEPTH_INSUFFICIENT.
5. Write a four-column review card: associated, evaluated, contributes, first reason.

Transfer the model

The same pattern applies to tax rules, medical eligibility, fraud holds, or account closure. Write one exact identity for a rule in your domain, then name one same-reference Case that must not contribute because its market, version, Oracle, or assurance differs.

Chapter boundary

• A Requirement reference is an association hint, not evidence of satisfaction.
• One Suite contribution cannot satisfy a cross-Suite minimum by itself.
• Owner labels and approved digests are governance facts, not authenticated human identity.
• A governance preflight failure means the experiment is invalid; it is not a customer decision verdict.

Experiment acceptance card

• Expected and observed: Requirement identity and semantics must both match to contribute.
• Failure and recovery: Keep the ref but change meaning; restore the exact version and semantic binding.
• Proof boundary: Proves the contribution filter, not owner approval of the Requirement.
• Exercise contract: One Requirement and case; change semantics only; deliver accepted/rejected results; stop when same-name/different-meaning is rejected.

Summary

Governance turns a familiar Requirement name into an exact obligation and filters passing Cases into valid contributions. Chapter 31 adds the missing completeness authority: one frozen cohort across Project and Reactor children, followed by a derived capability and explicit gaps.

Next: Chapter 31 — Project, Reactor, and Claim Capability

Coding Agent: Open the versioned task guide.