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

Chapter 23 — Business Correctness Is Not Test Pass

Promise: You will separate “the code runs,” “the graph succeeds,” “the business result satisfies the contract,” and “the evidence can support release,” then see why PASS cannot be rewritten as “safe to release.”

Learning Goals

1. Distinguish syntax, execution, business, and evidence correctness.
2. Build three independent axes: VerificationStatus, EvidenceTrust, and ClaimCapability.
3. Identify the boundary between the business owner, BLOGE developer, verifier, and release owner.
4. Run a real BLOGE verifier with a minimal Scenario instead of comparing only the final GraphResult.

Start with the business question

The loan operations owner gives a reviewable standard: low-risk applications are auto-approved, high-risk applications are auto-rejected, boundary applications enter manual review, and funding failures follow the policy for retry, fallback, or compensation.

This is not one “tests pass” statement. Start with the relationship map:

The point of the diagram is that the three axes do not substitute for one another:

VerificationStatus — answers what happened in this Suite / Case. It does not prove that the evidence is bound to source and runtime inputs.

EvidenceTrust — answers which source, Scenario, Policy, Fixture, and runtime are bound. It does not prove that the business policy itself is correct.

ClaimCapability — answers whether the evidence supports authoring, team, governed, or release decisions. It does not prove that the business verdict is PASS.

Separate the four kinds of correctness

Chapter 18 already teaches Graph tests for node status, execution order, and GraphResult. Those tools remain useful, but they cover only part of the complete question.

Syntax correctness — Can the .bloge file parse and compile? Use the parser, compiler, and DSL test. This does not prove that the business branch is right.

Execution correctness — Did nodes follow dependencies and propagate errors? Use GraphTestRunner and GraphResult. This does not prove the business standard.

Business correctness — Is riskDecision really auto_approve? Use a Scenario with BUSINESS_CONTRACT. This does not prove source and runtime identity.

Evidence usability — Can others use the result for a team or release decision? Use a source-bound reader and VerificationClaims. This does not approve the business policy.

GraphResult.isSuccess() means that the graph did not fail under engine semantics. It does not automatically show that a rejection branch was not bypassed or that an external effect matches the production contract.

The first verifier entry point

ScenarioVerifier.verify(Path) is the shortest single-Suite entry point. The starter uses BlogeScenarioTests.fromDirectory(...) to turn a Scenario directory into JUnit dynamic tests; both paths use the real parser, compiler, and engine.

The snippet shows the entry shape only. Replace bootstrap, projectRoot, and Policy with project facts:

ScenarioVerifier verifier = ScenarioVerifier.builder()
        .bootstrap(caseContext -> VerificationEnvironment.controlled(operatorRegistry))
        .projectRoot(projectRoot)
        .policy(projectRoot.resolve("src/test/bloge/verification-policy.yaml"))
        .build();

VerificationReport report = verifier.verify(
        projectRoot.resolve("src/test/bloge/scenarios/loan-approval.scenario.yaml"));

assertEquals(VerificationStatus.PASS, report.status());

This PASS means that the declared Suite satisfied its Expectations in this run. Without source-bound artifacts, a receipt, and an independent reader, do not silently upgrade it to SOURCE_BOUND or RELEASE_QUALIFIED.

Read one PASS three ways—and reject all three

Suppose the loan report contains only these facts:

suiteId=loan-approval-decisions
caseId=auto-approve
status=PASS
reasonCodes=[]

Three readers can turn that honest report into three dishonest claims:

Misreading	What is missing	Correct reading
“The decision rule is correct for every applicant.”	Cases outside this Suite and a sensitivity challenge	This Case satisfied its declared Expectations.
“The result came from the reviewed commit.”	seal, source digest, worktree identity, and reader result	The report object alone is UNVERIFIED.
“The release can ship.”	policy continuity, governed receipts, comparison, and release attestation	No release capability follows from PASS alone.

This is not philosophical caution; RC1 makes the axes disagree on purpose. VerificationReportWriterTest.rechecksArtifactBytesAfterThePublicationGuard starts with a PASS report, then lets the publication guard push the summary above 4096 bytes. The writer returns INCOMPLETE / RESOURCE_LIMIT_EXCEEDED and leaves the output directory empty. A business verdict cannot override a failed publication boundary.

VerificationContractEvidenceTest adds the opposite guard: a PASS Case cannot carry failure reasons, a FAIL Case cannot claim satisfaction, and aggregate identities must match the Suite, Case, Requirement, and assurance records. On 2026-09-14 at BLOGE commit cc38fbe5, these focused classes produced 5 tests, 0 failures, 0 errors, and 0 skips.

The practical reading order is fixed:

1. Read VerificationStatus: did the declared contract match this run?
2. Read EvidenceTrust: what immutable inputs does the evidence bind?
3. Read ClaimCapability: which decision is the complete evidence allowed to support?

Stopping after step 1 is fine during authoring. Renaming step 1 as step 3 is not.

Three common false greens

Skipped manual_review — an ordinary test may see a final object that is still approved. Business verification must assert business output and the human path separately; skipped nodes are structural facts.

Hidden fallback — an ordinary test may see a Graph that is still SUCCESS. Business verification must record retry disposition, fallback, and effect handling, then confirm that the degradation is allowed.

Direct Operator call — an ordinary test may see a PASS from the Operator unit test. Business verification must run the Scenario through the real parser/compiler/engine and restrict undeclared effects.

This does not make JUnit useless. Each layer should answer the question it is good at, and the results should be composed within their evidence boundaries.

What each role provides

Business owner — provides standard answers, boundary Cases, Requirements, acceptable failures, and Oracle provenance. Does not turn a green test directly into release approval.

BLOGE developer — provides the DSL, Operators, Scenario, Policy, Fixture, and bootstrap. Does not copy implementation code as the standard answer.

Verifier / platform — provides controlled execution, observations, reason codes, artifacts, seal, and reader. Does not change business policy to remove a failure.

Release owner — provides the commit, worktree, receipt, ClaimCapability, and gaps. Does not rename AUTHORING as RELEASE_QUALIFIED.

Lab: split one green test apart

1. Pick a loan Case that asserts only GraphResult and add one BUSINESS_OUTPUT assertion.
2. Add one STRUCTURAL_CONTRACT assertion for a branch skip or invocation fact.
3. List two facts still unproven, such as missing source binding or missing independent external-system evidence.
4. Record status, evidence trust, and claim capability as three columns; one word must not stand in for all three.

Stop when the input, Policy, or bootstrap is incomplete. The report should remain INVALID or INCOMPLETE; do not retry a contract problem until it becomes a green light.

Transfer: a medication-release workflow

In a hospital pharmacy, “the workflow completed” means the prescription moved through its declared steps. It does not mean the dose satisfies the approved medication rule, that the result came from the reviewed formulary, or that a pharmacist may release it. Map graph status, dosage Expectation, source-bound formulary evidence, and release authority onto the same four layers used here. Stop if one green badge is doing more than one of those jobs.

Experiment acceptance card

• Expected and observed: Read one PASS separately as verdict, evidence trust, and claim capability.
• Failure and recovery: Remove a guard or corrupt evidence; restore it and reread all three axes.
• Proof boundary: Proves a controlled case claim, not release approval.
• Exercise contract: One green case; attack one evidence boundary; deliver three readings; stop when no conclusion exceeds capability.

Chapter summary

A reliable FAIL can show that a business contract was not satisfied. An unbound PASS only shows that one run looked successful. The next chapter applies this rule to two Suites and seven Cases in the starter.

Next: Chapter 24 — Your First Loan Business Verification

Coding Agent: Open the versioned task guide.