certify

name	certify
description	Compute the terminal verdict and emit the Certificate of Conformance — integrity checks, per-criterion verdicts, residual risk. Use after /verify, or to re-read an existing certificate.

/certify — the assurance case

The deliverable is a structured argument, not a checkmark.

bb certify

Everything below is computed by that command from the evidence file. No language model participates in the decision. That is what makes a certificate reproducible by someone who does not trust us: given the same evidence, bb certify returns the same verdict on any machine.

Your job is to run it, read it honestly, and refuse to soften it.

What it checks, in order

1. Contract integrity — does intent/frozen.json still hash to its signature? A contract that changed mid-run voids everything.
2. Evidence chain — each record carries its predecessor's hash. Editing or deleting one breaks every record after it.
3. Canaries — unsatisfiable criteria were seeded into the run. If the verifier reported one satisfied, the run is VOID.
4. Tamper events — any write that landed on an acceptance artifact. Undisposed events void the run.
5. Per-criterion verdicts — MET requires every case passed at the required evidence tier. Missing evidence is UNVERIFIED, never MET.
6. Terminal verdict.

Reading the verdict out loud

Verdict	What you say
DELIVERED	"Every criterion was independently verified. Here is what was not covered: …" — always finish that sentence
PARTIALLY DELIVERED	Name every unmet and every unverified criterion. Do not lead with the passes
CANNOT DELIVER	A critical criterion is not met. Report it plainly; this is a correct outcome, not a failure of the run
VOID	The instrument failed. Say nothing about the product — a void run carries zero information about whether it works

UNVERIFIED never means "probably fine." It means not checked, and the only honest sentence is "no conclusion should be drawn about this."

Dispositioning

Red findings and tamper events block DELIVERED until dispositioned. Disposition is a human decision, recorded as one:

• fixed — rebuilt and re-verified on a fresh draw
• accepted-with-rationale — the human accepts the risk, and the rationale goes on the certificate
• out-of-scope-per-contract — genuinely outside the frozen scope. Check the out-of-scope list actually says so

Never disposition on the human's behalf.

After a fix

When a case caught a defect and the defect is fixed:

bb retire <case_id>
bb start          # fresh run, fresh draw

The next run draws a different representative from the same equivalence class, so a fix that satisfies only the values that caught it will fail. Do not re-run the retired case alone and call it green — that measures the patch, not the criterion.

Boundary cases are the exception and are not held out. A boundary is exact, it is where off-by-one lives, and it runs identically every time. Retiring one flags it for audit; it does not remove it.

Handing the certificate over

Give the human .blackbox/certificate/<run>.md and read them the residual risk statement verbatim. It is the paragraph they will actually act on; everything else in the certificate exists so that paragraph can be trusted.

Two things it always says, and you must never omit:

• Blackbox verification cannot see hazards that did not manifest — narrow races, unbounded growth, embedded secrets.
• If adjudication ran on the same model family that built the product, its judgment-based verdicts are weaker than its executable ones.