Quality Gates

Quality Gates are BMO’s optional post-draft quality check. BMO generates a candidate answer normally, then a Quality Judge can evaluate that draft against evidence and a rubric before the run is finalized.

Maturity: Advanced operator and maintainer surface. Use it when you need a bounded post-draft or proposal-readiness judgment, not as a replacement for ordinary review or tests.

Quality Gates are not the prompt enhancer. The prompt enhancer adds context before generation; Quality Gates evaluate output after a draft exists.

What problem this solves

Some failures are visible only after a draft exists: unsupported claims, weak plan criteria, missing prompt/recipe hardening, or proposal evidence that is not ready for human review. Quality Gates give BMO a typed, bounded way to judge those outputs and record the decision without handing the judge broad tool authority.

What it does

When enabled, the answer gate can return one of four verdicts:

Verdict	Meaning
`pass`	The draft meets the rubric.
`warn`	The draft has an issue, but can still be shown.
`send_back`	The draft should be revised before final output.
`escalate`	The issue needs operator attention.

The default posture is conservative. The feature is off unless configured, and advisory decisions do not block chat output. Armed send-back retries at most once.

Inspect decisions

Use the compact posture command when you need to know which gates are armed, whether the judge model resolves, and what recent decisions prove:

bmo config show-quality-gates
bmo config show-quality-gates --format=json

The TUI exposes the same shared renderer through /quality-gates (alias: /quality_gates). In-process agents can call quality_gates_posture; MCP clients can call bmo_quality_gates_posture. These readouts are metadata-only: recent entries carry hashed session/run/proposal/finding prefixes and never include prompts, answers, diffs, plan bodies, recipe bodies, or provider secrets.

Open the Agent Debugger:

/debugger

Quality Gate decisions appear as quality_judge_* events in the run timeline. The debugger shows verdict, action, reason, rubric failures, evidence refs, model-family metadata, retry details, and linked workstream finding ids.

The same information is available through the run-ledger API and tools:

GET /v1/agent-runs/{run_id}/events
list_agent_runs
get_agent_run_events

Unavailable judge paths are shown as unavailable, not pass. Runtime policy may fail open for answer and patch-proposal infrastructure failures, but the posture and recent-decision ring keep that state visible.

Manual document checks

You can run explicit checks over plan and prompt/recipe files:

bmo quality-gate check --path docs/plans/example.md
bmo quality-gate check --surface prompt_recipe --path .bmo/recipes/example.yaml

The plan rubric checks acceptance criteria, source grounding, scope boundaries, system-wide impact, validation commands, and open questions.

The prompt/recipe rubric checks output contract, source ownership, tool availability assumptions, artifact destinations, instruction hardening, and a validation or review gate.

This command is manual and opt-in. It does not install hooks and does not block ordinary edits.

Runtime status

The TUI stays quiet for normal pass/advisory outcomes. Runtime activity is shown only for judging in progress, armed send-back, or escalation. Use /quality-gates for current posture and /debugger for the full decision trail.

Agent Debugger - inspect Quality Gate events.
Patch Proposals - code-change proposals can use Quality Gate evidence as a review-readiness signal.
TUI - phases vs runtime activity - how the compact status surface works.
Quality orchestration - server/API fanout and candidate selection, which is separate from Quality Gates.
Configuration - generated config reference.

Implementation details live in the implementation reference: quality-gates.md.