Verdict Grades

Verdict grades answer the question every delegation raises: how strong is the evidence that this work was verified? Every run in BMO — a top-level bmo run, an interactive turn, or a spawned sub-agent — terminalizes with a typed grade from a closed vocabulary. The grade is derived from what actually executed, not from what the agent says about its work: a validation command you declared and the agent never ran grades the result unverified, no matter how confident the summary reads.

Grades state evidence strength, never correctness. A proof-graded unit means the strongest declared judge ran and passed; it does not mean the task is right. That distinction is what keeps the grade honest enough to route on.

BMO conforms to the Graded Verdict Custody specification: the grade vocabulary, its ordering, and the derivation rules are asserted against the spec’s canonical registration and conformance fixtures in CI.

Maturity: Grades are admitted on every terminalization path today — child runs, headless runs, server, ACP, gateway, and background dispatch all flow through the same admission seam. The grade record, its decision event, and the run-summary projection are the operator surfaces.

Route fit: use this page to declare verification judges and read the resulting grades. Go to Multi-Agent Workflows for choosing a delegation shape, and Run Observability for the broader run-inspection toolkit.

The grade ladder

Strongest first. Ordering is fixed; nothing an agent writes can reorder it.

Grade	The evidence it names
proof	A kernel-grade check passed (type system, machine-checked property)
known_answer	Output matched a pre-declared expected answer
interop	An independent external system accepted the work
constructed_check	A test or command written for this task ran and passed
review_only	A reviewer looked; nothing executable passed
unverified	No declared judge ran — including “a judge was declared and never executed”

An out-of-vocabulary value ranks below unverified, so a made-up grade can never outrank a real one.

Declare the judge before you delegate

The unit of trust is a declared oracle: a verification command named before the work runs. Two controls declare one:

Headless runs — declare the completion judge on the invocation:

bmo run --quiet \
  --completion-validation-command "go test ./internal/parser" \
  "Fix the tokenizer's handling of nested quotes"

Sub-agents — declare it at the spawn call. Agents delegating with spawn_agent pass validation_command:

{
  "prompt": "Extract the retry logic into internal/backoff and keep tests green",
  "validation_command": "go test ./internal/backoff"
}

In both cases the command’s execution is observed, never assumed. At finalize, BMO resolves the declared command against the run’s persisted transcript:

• The command ran and passed → the unit grades constructed_check.
• The command ran and failed → the judge judged and refused; that is evidence, and the failure is recorded.
• The command never ran → the unit grades unverified. A declared-but-unrun judge is the loudest signal the vocabulary has.
• The agent edited files after the last successful check → the observation resets. A verdict covers the artifact the run actually delivered, so the judgment must postdate the final write.

flowchart LR
  declare["Declare judge
(validation command)"] --> run["Run executes"]
  run --> observe["Transcript observation
at finalize"]
  observe -->|ran + passed| cc["constructed_check"]
  observe -->|ran + failed| failed["recorded failure"]
  observe -->|never ran| unv["unverified"]

What can lower a grade

Derivation applies a fixed set of rank operations; each one applied is retained on the record, so a lowered grade always says why:

• Same-chain cap — an oracle authored inside the same delegation chain as the producer caps at constructed_check, no matter whether the author is an agent or a human: conflict of interest is a relationship between delegation chains, not a property of the author’s species. Work cannot grade itself higher by writing its own judge. The one exemption is a proof whose author is kernel-kind — there the kernel judges, not the author — and every exemption is itself counted.
• Conflict demotion — a declared judge that ran and failed at the same tier as the passing one demotes the grade one tier. The disagreement is derived from the declared set at admission; nothing the producer supplies can switch it on or off. The record keeps the true evidence kind alongside the demoted grade.
• Staleness reversion — the grade binds to the judged content’s identity. Change the content after grading and the effective grade reverts to unverified.

When several declared judges pass at the same top tier, the record folds by MAX: the most favorable surviving outcome wins, and a fold where a tied sibling would have been capped is counted (invocation_tied_uncap) so the pattern stays visible.

A declared judge that ran and failed never lowers the grade by itself — failed evidence is weaker evidence, not negative evidence — but it is never invisible either: the record carries a failed_declared_evidence flag that every surface showing the grade also shows, and each failure is counted.

Reading grades

Non-interactive JSON — every bmo run --quiet summary carries the invocation’s verdict deltas under run_summary.enforcement.verdict:

"verdict": {
  "invocation_ungraded_terminal": 0,
  "invocation_unverified": 1,
  "invocation_degraded": 0,
  "invocation_producer_mint_rejected": 0,
  "invocation_emit_skipped_no_session": 0,
  "invocation_oracle_transcript_unavailable": 0,
  "invocation_oracle_resolved_ran": 0,
  "invocation_unbindable_content_identity": 0,
  "invocation_same_chain_indeterminate": 0,
  "invocation_author_chain_unbound": 0,
  "invocation_failed_declared": 0,
  "invocation_proof_kernel_exempt": 0,
  "invocation_tied_uncap": 0,
  "unbound_terminalization_families": 0
}

Two of these are standing invariants worth alerting on: invocation_ungraded_terminal stays at zero (no run completes ungraded), and unbound_terminalization_families stays at zero (no run-ending path is exempt from admission). A nonzero value in either is a finding, not noise.

Run ledger — each admission is a durable verdict_grade_admission decision event on the run, carrying the effective grade, the declared-oracle count, the unrun count, and the custody identities (who authored the judge, who ran it, who produced the work). Inspect it through the Agent Debugger like any other run event.

When to use it

• You delegate work headlessly or in bulk and need to know, per unit, whether anything executable vouched for it.
• You fan out sub-agents and want the weakest-verified results to surface first instead of hiding behind confident summaries.
• You are wiring CI or scripting around bmo run --quiet and want a machine-readable verification floor per invocation.

Limits

• A grade never claims correctness; it names the strongest evidence that ran.
• The producer cannot mint its own grade: an agent-supplied grade field is rejected at admission and counted.
• Undeclared checks the agent happened to run contribute evidence records, but they never raise the effective grade — only judges declared before delegation count.