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

Chapter 29 — From Report to Source-bound Evidence

Chapter promise: You will distinguish a business result from a sealed directory, keep the receipt outside that directory, and use an independent reader to decide whether the evidence is merely intact, bound to source, or externally attested.

Learning goals

1. Explain the jobs of report, manifest, seal, receipt, and reader.
2. Distinguish LOCAL_INTEGRITY, SOURCE_BOUND, and ATTESTED.
3. Identify which claim is lost after bytes, directory location, Git commit, or runtime cohort changes.
4. Read evidence through a typed reader instead of parsing JSON fields into a release decision.

A copied green report is only a copied green report

The team copies verification-report.json from a developer laptop to a release machine. It still says PASS. That text preserves a claim somebody made; by itself it does not identify the source, toolchain, inputs, or run that made it.

The orange break is deliberate: the receipt must not travel inside the mutable artifact directory. Accepting a newly calculated receipt from the same party that can rewrite the directory collapses the boundary.

Five files form one sealed projection

A published Suite directory can contain:

• verification-manifest.json: bound inputs, runtime identity, Git and run cohort facts.
• verification-report.json: payload-free Suite, Case, Requirement, assurance, coverage, and specialized results.
• verification-summary.md: human review projection.
• JUnit XML: build-system projection of the same verdicts.
• evidence-seal.json: hashes and relationships for the published files.

VerificationArtifacts returns the run directory, run ID, and sealSha256(). Store that SHA-256 in an independently controlled CI record. It is the receipt the later reader must receive from outside the directory.

Integrity and provenance are different promotions

LOCAL_INTEGRITY means the files agree with the seal. A person who can rewrite the directory can also create a new internally consistent seal.

SOURCE_BOUND additionally binds the exact tracked inputs, clean Git commit and worktree, execution profile, classpath/runtime, bootstrap and Operator identity, plus the run cohort supported by that evidence version.

ATTESTED requires an external controlled provenance system to sign the exact source-bound payload under an explicitly trusted key and domain. A signature does not repair missing source binding.

Business status stays independent. A trustworthy FAIL can be source-bound; an unbound PASS remains unsuitable for a team gate.

Publish once, verify from the outside

Configure publication before the run:

ScenarioVerifier verifier = ScenarioVerifier.builder()
        .bootstrap(new LoanVerificationBootstrap())
        .projectRoot(projectRoot)
        .policy(policyPath)
        .outputDirectory(projectRoot.resolve("target/bloge-verification"))
        .executionProfile(VerificationExecutionProfile.builder("ci-safe").build())
        .sourceBoundEvidence()
        .build();

VerificationReport report = verifier.verify(scenarioPath);
VerificationArtifacts artifacts = report.artifacts();
String externalReceipt = artifacts.sealSha256();

Later, pass all three independent inputs to the reader:

VerificationEvidenceTrustResult trust = VerificationSourceBoundEvidence.verify(
        artifacts.directory(), projectRoot, externalReceipt);

The reader recomputes report, summary, JUnit, manifest, source, and receipt relationships. It does not run candidate Operators or customer bootstrap. Oracle v10/v11 is the narrow exception: the reader may rerun the explicitly bound reference-model child JVM.

Attack five boundaries and watch trust move

Start every row from the same untouched artifact: business status PASS, independently supplied receipt, and reader trust SOURCE_BOUND. Change exactly one thing.

One-variable attack	Independent reader observation	Highest defensible trust	What was lost
replace the external receipt	EVIDENCE_RECEIPT_MISMATCH	UNVERIFIED	identity of the sealed byte snapshot
edit summary, update its digest, and reseal	DURABLE_EVIDENCE_PROJECTION_MISMATCH	below valid local evidence	agreement between human and machine projections
edit report semantics, regenerate projections, and reseal	DURABLE_EVIDENCE_INVALID	below valid local evidence	an internally possible verifier result
alter an action digest, regenerate projections, and reseal	SOURCE_BINDING_CASE_EVIDENCE_MISMATCH	LOCAL_INTEGRITY	relation to the tracked action plan
mutate tracked source after publication	SOURCE_BINDING_DRIFT	LOCAL_INTEGRITY	relation to the current source cohort

These are observed RC1 contracts, not hypothetical labels. DurableVerificationEvidenceTest.rejectsAProjectionMutationEvenWhenTheArtifactDigestWasUpdated proves that updating hashes cannot make a contradictory summary valid. rejectsAContradictoryReportEvenAfterAllFilesAreReprojectedAndResealed proves that a fully consistent forgery can still describe an impossible verifier state. DurableSourceBoundVerifierTest.rejectsReplacementReceiptBeforeTrustingSourceBoundDocuments rejects a borrowed receipt before trusting source-bound documents.

The source-drift test adds one operationally important observation: after publication, the plan file changes, the reader returns LOCAL_INTEGRITY / SOURCE_BINDING_DRIFT, and the customer-call counter remains 1. The reader downgraded trust without executing customer code again.

Why resealing cannot restore provenance

The artifact owner can recompute hashes. Therefore a new seal can sometimes restore byte consistency, but it cannot restore the externally retained receipt, the original run identity, or agreement with tracked source. The reader calculates the highest still-supported level; it does not accept the directory's self-description.

Moving or copying the directory has the same principle. The bytes remain useful for inspection, but source-bound publication expects its ignored, non-classpath location inside the bound worktree. A copy does not inherit decision authority merely because filenames and JSON fields survived.

Readers return stable diagnostics and fail closed. Do not replace their result with a filename, a green status field, or a manually parsed evidenceTrust value.

Lab: attack one boundary at a time

1. Publish one source-bound loan Suite and save sealSha256() outside its run directory.
2. Verify the untouched artifact with the original project root and receipt; record SOURCE_BOUND.
3. Execute the five attacks in the table, restoring the untouched artifact before each one.
4. Record business status, reader trust, complete reason codes, and customer-call count.
5. For the reseal attacks, keep both the original receipt and replacement receipt; verify with each and explain why they answer different questions.
6. Copy the directory outside its original worktree and confirm that readable files do not inherit source-bound authority.
7. Finish with a card containing: status, trust, receipt custodian, project commit, first failed relationship, and rerun policy.

Transfer: payroll evidence custody

A payroll report copied from another worktree can still be valid JSON and show every employee calculation as PASS. It must not inherit authority from the original run. Bind the payroll rules, employee-input digest, runtime inventory, commit, and external receipt; then move or reseal one component at a time and record the first trust relationship that fails.

Chapter boundary

• A seal proves relationships among current bytes; it does not identify who produced them.
• SOURCE_BOUND does not prove external account identity, host isolation, production topology, or policy approval authenticity.
• Copying a report is useful for reading, but not for inheriting its source-bound decision capability.
• Use the matching reader and schema catalog; do not infer evidence versions from class names or JSON shape.

Experiment acceptance card

• Expected and observed: Five files form source-bound evidence; integrity and provenance upgrade separately.
• Failure and recovery: Replace a receipt, edit source, or reseal identity; restore the chain or rerun.
• Proof boundary: Proves the fixed reader can verify the chain, not that customer code was never altered.
• Exercise contract: One sealed projection; attack one file at a time; deliver trust/reason changes; stop when all five attacks are attributable.

Summary

Artifact files make a result inspectable, an external receipt makes rewriting detectable, and the reader reconnects both to current source facts. The next chapter determines whether one trusted Case fact contributes to one exact Requirement; Project and Reactor aggregation follow in Chapter 31.

Next: Chapter 30 — From Case Facts to an Exact Requirement Contribution

Coding Agent: Open the versioned task guide.