Skip to main content

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

Chapter 31 — Project, Reactor, and Claim Capability

Chapter promise: Aggregate exact Requirement contributions only from a complete frozen cohort, reject borrowed children, and end with the highest evidence-backed decision capability plus named gaps.

Learning goals

  1. Explain why aggregation needs an authoritative inventory and one run cohort.
  2. Distinguish Project completeness from direct-module Reactor completeness.
  3. Observe cohort mismatch and borrowed-child rejection before trusting totals.
  4. Treat ClaimCapability and missingEvidence as derived reader output.

Two valid children can still make an invalid parent

The decision module contributes one valid loan Case; the funding module contributes another. Together they meet minimumPassingCases: 2—but only if both belong to the same governance snapshot, selection, source commit, and parent run.

Figure 31.1: A parent accepts complete same-cohort children and rejects a borrowed child

This is the aggregation version of a cut-and-paste report problem. Child validity is necessary; parent membership is a separate fact.

Project aggregation freezes discovery before execution

VerificationGovernedProjectEvidence evidence =
VerificationProjectRunner.runGovernedEvidence(
scenarioDirectory,
verifier,
VerificationSelection.all(),
projectIdentity,
outputDirectory);

The runner freezes Scenario discovery, effective selection, governance context, project POM identity, and source-bound child receipts before calculating the Requirement. If a required binding is absent or filtered out, it reports GOVERNANCE_BINDING_MISSING or GOVERNANCE_BINDING_FILTERED; it does not lower the minimum to fit the available children.

RC1 test aggregatesDistinctSuiteCasesAndRejectsAMissingGovernedChildBeforeBootstrap protects this distinction: separate Suite contributions may combine only through the Project aggregate that owns their complete inventory.

Reactor adds a different completeness authority

VerificationReactorRunner.runGovernedEvidence(...) reads the root pom.xml direct <modules> list. Every module supplied to the runner must match that inventory, literal GAV, Suite/Case inventory, shared Git commit, selection, and governance cohort.

In recomputesOneGlobalRequirementFromTwoIndependentModules, either module alone returns INVALID / GOVERNANCE_BINDING_MISSING with zero calls. The Reactor run executes both once, lists two qualified Suite identities, and recomputes one Requirement with two satisfied Cases.

Current Preview covers direct modules in one Git worktree. Nested reactors, arbitrary Maven profiles, external-parent effective models, and deployment topology remain outside this completeness claim.

Attack the cohort before reading the count

The test rejectsAReactorGovernanceCohortMismatchBeforeCustomerBootstrap changes only the second module's catalogId. The result is:

status = INCOMPLETE
reasonCodes = [REACTOR_GOVERNANCE_COHORT_MISMATCH]
module calls = 0 + 0

The runner rejects the parent before customer bootstrap. This is stronger than discovering a mismatch after two expensive or side-effecting executions.

Another attack runs two valid Reactor parents, then replaces one Suite in the first in-memory parent with a valid Suite from the second. reactorClaimRejectsAValidChildBorrowedFromAnotherParentRun drops capability to AUTHORING and restores SOURCE_BOUND_PROJECT_AGGREGATE as a TEAM_GATE gap. Valid child plus wrong parent still equals invalid aggregate.

Let Claims name the remaining decision boundary

VerificationClaimAssessment assessment =
VerificationClaims.assess(evidence, projectRoot);

ClaimCapability current = assessment.capability();
Map<ClaimCapability, List<VerificationEvidenceGap>> gaps =
assessment.missingEvidence();

Figure 31.2: ClaimCapability rises only when every cumulative gap for the next level is closed

CapabilityEvidence-backed decision contextTypical remaining gap
AUTHORINGlocal diagnosis and witness discoverysource-bound Suite/Project evidence
TEAM_GATEteam integration with continuity, replay, and CI-safe controlsgoverned aggregate or Oracle provenance
GOVERNED_GATEversioned business obligations and trusted Oracle provenanceattributed comparison and release attestation
RELEASE_QUALIFIEDexact governed evidence and comparison signed for releaseno missing item in the declared release contract

Gaps are cumulative. A string written into JSON cannot promote the evidence, and a Policy cannot award itself a capability. A trustworthy FAIL may have strong provenance; capability still does not replace business status.

Lab: borrow one child

  1. Run a two-module parent and retain its external receipt.
  2. Run the same modules again into a second parent directory.
  3. Confirm each parent independently verifies.
  4. Replace one child projection in parent A with the valid child from parent B.
  5. Assess the mixed parent. Record AUTHORING and SOURCE_BOUND_PROJECT_AGGREGATE.
  6. Restore parent A and draw the ownership links: root POM → parent run ID → child receipt → Suite contribution.
  7. End with a gap card: current capability, desired capability, missing evidence, owner, and next experiment.

Transfer: a multi-module billing release

Imagine tax, invoice, and ledger modules each publish valid child evidence. Combining a tax child from yesterday's parent with today's invoice and ledger children creates a readable but mixed cohort. Require one root build identity, one parent run, and owned child receipts before claiming project completeness; otherwise stop at AUTHORING and name the missing owner.

Chapter boundary

  • Valid child evidence does not prove membership in a particular parent run.
  • Project completeness does not imply direct-module Reactor completeness or deployment completeness.
  • A Reactor total is meaningful only after inventory and cohort checks.
  • ClaimCapability states the supported decision context; it neither changes the verdict nor approves a release.

Experiment acceptance card

  • Expected and observed: Two valid children can still leave a parent capability gap.
  • Failure and recovery: Borrow a child from another cohort; restore the frozen discovery set.
  • Proof boundary: Proves Project/Reactor completeness, not acceptance of residual risk.
  • Exercise contract: One parent and two children; replace one child; deliver the gap; stop when the borrowed child is identified.

Summary

Aggregation is not addition. It is addition under an authoritative inventory and one frozen cohort. The Claims reader then reports how far that evidence may travel and what still blocks the next decision. Chapter 32 runs the last controlled experiments: one DSL change and one BLOGE toolchain change.

Next: Chapter 32 — Change Attribution, Maven, and Release Decisions

Coding Agent: Open the versioned task guide.