Skip to main content

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

Arc 6 Recap — Business Evidence

Chapters 23–32 followed one promise: a loan decision must still match an owner-approved business contract after the graph, runtime, or environment changes.

The ten-chapter evidence path​

  1. Frame the claim — Chapter 23. Separate verdict, evidence trust, and decision capability.
  2. Run the first story — Chapter 24. Map approved, rejected, and manual-review outcomes into Suite, Case, and Expectation.
  3. Control the inputs — Chapter 25. Use Policy, Fixture, execution profile, and assurance to reject false greens.
  4. Keep time honest — Chapter 26. Observe suspend, signal, resume, logical time, and temporal contracts.
  5. Kill weak mutants — Chapter 27. Measure whether the suite notices selected, controlled business-rule changes.
  6. Search bounded domains — Chapter 28. Turn properties into finite cases, retain counterexamples, and keep the Oracle boundary explicit.
  7. Bind the source — Chapter 29. Connect artifacts to source, run cohort, seal, external receipt, and an independent reader.
  8. Contribute exactly — Chapter 30. Decide whether a trusted Case fact contributes to one versioned Requirement.
  9. Aggregate one cohort — Chapter 31. Derive Project/Reactor completeness and capability from an authoritative inventory, then name the remaining gaps.
  10. Attribute the change — Chapter 32. Freeze one axis, compare, and report the highest supportable release capability.

Read every result on three axes​

  • VerificationStatus: what happened in this Case—PASS, FAIL, INVALID, or INCOMPLETE?
  • EvidenceTrust: can an independent reader bind the result to the declared source and run inputs?
  • ClaimCapability: does that evidence support only AUTHORING, or also TEAM_GATE, GOVERNED_GATE, or RELEASE_QUALIFIED?

Never collapse these axes into one green badge.

The release-owner scan​

Before a release decision, point to each concrete item:

  1. The active Requirement version, partition, binding, and approved Oracle closure.
  2. A complete same-cohort governed Project aggregate.
  3. Source-bound child receipts retained outside mutable artifact directories.
  4. One attributable DSL_GRAPH or BLOGE_TOOLCHAIN comparison.
  5. A trusted external attestation binding the exact governed receipt, comparison receipt, change axis, and Oracle closure.
  6. The declared boundary: what the evidence still does not prove about production.

If one item is absent, keep the lower capability and name the gap. Do not negotiate the enum upward.

Final challenge: classify before you claim​

A candidate build has passing loan Cases and a valid local seal. Its business Operator changed together with the BLOGE runtime. The report directory contains its receipt, no governed Project aggregate exists, and no release owner signed an attestation.

Classify it:

  • Verdict: the declared Cases may be PASS.
  • Trust: a local seal may establish byte integrity, but co-located custody and missing source/governance facts do not establish the release chain.
  • Attribution: the two-factor change cannot identify a single cause.
  • Capability: AUTHORING, with explicit source, governance, comparison, and attestation gaps.

Now split the two change axes, regenerate source-bound evidence, satisfy the governed Requirement, and retain the receipts externally. Only then ask the release owner to assess and sign the exact payload.

Keep the map​

Return to Chapter 23 when claims blur, Chapter 24 for the runnable starter, Chapter 28 for counterexamples, Chapter 29 for trust boundaries, Chapter 30 for exact Requirement contribution, Chapter 31 for aggregation and capability limits, and Chapter 32 for comparison and release decisions. Then use Arc 7 to decide whether BLOGE belongs in the problem at all.