Proof gallery

This gallery separates a conceptual system map from documented scenarios in the docs pipeline: live captures on feature pages (linked below) and live evaluate captures for headless CI, MCP export posture, and workspace claims on this page.

Use it during evaluation to inspect what has been demonstrated and what remains a proposed integration.

Conceptual system map

The diagrams below describe the intended governed synthesis loop. They are editable SVG diagrams, not live captures or proof that all boundaries work together today. The selected local/Cloud Run delegated-work envelope and the held-path recording below are narrower accepted evidence. Broader integrated synthesis and an independent buyer-facing comparison belong to their delivery and evaluation owners.

Both patches pass. Together they skip a role check.

In the conceptual example, one worker adds /exports, calling a shared function that checks the user’s role. Another worker moves that guard into the existing /reports route. Each change passes against the baseline; combined, /exports bypasses the guard. An independent guest-request check exposes the gap.

Diagram: five conceptual scenes show a shared role guard, two independently passing patches, an unguarded exports route in the combined revision, an independent guest-request failure and HOLD pending repair or an unresolved-duty receipt — Open the full-size storyboard. Scroll horizontally, or focus the diagram and use the arrow keys.

This is an illustration, not a completed run. BMO’s proposed loop retains the original requirement while an admitted repair is checked again, or records the unresolved duty. A verified candidate still needs separate publication and terminal closure gates.

Who can decide what?

Diagram: BMO's parent owns source scope, obligations and budget; workers return advisory proposals; independent verification branches to protected publication or HOLD, which returns to the original duty — Open the full-size authority map. Scroll horizontally, or focus the diagram and use the arrow keys.

Workers return proposals to the parent. Stale, failed or canceled work cannot promote itself from local PASS. The independent parent check can also fail or remain unknown: that path returns to HOLD and the retained requirement. Protected publication and the terminal receipt have separate owners and gates.

Governed synthesis evidence map

The diagrams above are a conceptual sketch. SIGNIN-204, below, is a separate historical sign-in fixture. Neither one is a receipt for decision-guided synthesis. This table maps each public claim to the evidence that actually supports it.

Concept on this page	What is established	Where to read it
Storyboard and authority map	Illustration of a proposed loop. Not a live capture and not a passing test of the combined boundaries.	The SVG files linked above.
SIGNIN-204	Archived sign-in fixture: a missing password guard, a failing check, a scoped repair, a passing rerun. Raw console logs are not in the archive.	The pinned revision links in Recorded scenario evidence.
`bmo synthesize` ranking	Declared candidates, observed `failure_loss`, and a Patch Proposal at `ready_for_human`.	Decision-guided software synthesis.
Apply fence	Measured bytes must still match at apply. A changed candidate is refused.	Same guide, section “What apply is allowed to write”.
Parent check after a passing candidate check	The parent obligation stays pending through apply and can then fail without rolling the proposal back.	Same guide, unsuccessful path.
Coordinator acceptance	A provisioned `decide-coordinator-outcome` receipt with an empty residual list. Ordinary `bmo synthesize` does not write it.	Parent outcome.

Bounded operator command

The diagrams above stay conceptual. A separate, implemented command evaluates a specification you write and retains a reviewable proposal:

Decision-guided software synthesis — ranking, proposal, aftercare, and the parent check, with the tests that establish each step.
Change synthesis — bmo synthesize inspect, limits, run, compose, and import-local. Selection does not apply files.
Independent verification — declared checks and parent evidence are different records from a run’s verdict grade.
Parent outcome — bmo protected-admission decide-coordinator-outcome on a provisioned controller. Ordinary local sessions do not record this receipt.
Mutation aftercare — the change-contract ingest after a reserved effect. It is not git auto-checkpoint.

That command path does not execute the storyboard, does not establish autonomous decomposition, and does not establish general software synthesis. A candidate_ready proposal still needs operator accept and apply. Parent acceptance still needs the controller command and an empty residual list.

Recorded scenario evidence

The held-path recording illustrates SIGNIN-204, a bounded deterministic sign-in fixture. Its archived receipt records a missing password guard, the failing check, a scoped repair, the identical passing rerun, and preservation of the adjacent fixture work. It does not establish autonomous decomposition or general software synthesis. It is not a demonstration of decision-guided bmo synthesize selection. The penalty ranking, aftercare, and parent-check failure are on Decision-guided software synthesis. Command syntax stays on Change synthesis.

The following links pin the evidence package to its preserved revision:

Scenario receipt (JSON): exact commands, results, source hashes and log hashes.
Live TUI capture record: captured binary version, source pixels and limits. The capture pair alone does not prove the full edit chronology or adjacent-work preservation.
Archived media manifest and matching archival recording: rendered-output provenance for that archive.
Original fixture and reproduction contract and archived proof and claims guide.

The receipt preserves log hashes, but the raw failure, rerun and integration log files are absent from this archive. Its recorded results can be inspected; the original console output cannot be independently compared here.

The current walkthrough was rendered later. Its bytes do not match these archived manifests. Use the matching archival recording when checking those digests; the archive is historical scenario evidence, not a fresh qualification of the current binary. A receipt connects an outcome to its source and checks; a video is a presentation of that evidence.

Watch the current walkthrough or run your first local session.

Bounded proof slice — fix failing tests

BMO: failing tests, one bmo run, fix in editor and tests pass

Failing tests → one bmo run → fix lands in your editor and tests pass. This is an existing bounded proof slice. The conceptual system map and the recorded walkthrough are separate from this example.

Interactive review and planning

Scenario	Evidence
Staged workflow plan gate	Staged workflow — plan review capture
Arena model comparison	Arena — comparison round capture
Quality gate verdict	Quality gates — judge flow capture

Observability and recovery

Scenario	Evidence
Agent debugger run list	Agent debugger — `/debugger` capture
Run observability summary	Run observability — session summary
Multi-agent workspace claims	Multi-Agent Workflows — claims inspector

Headless and integration (live captures)

These three captures are live tmux PNGs from the real ./bmo binary (provider credentialed via the workspace .env wrapper).

Scenario	Evidence
Headless CI run	Live `bmo run --quiet` log output below
MCP server defaults	Live `/serve-mcp` export status below
Multi-agent workspace claims	Live `/workspace-claims` table below — when setup acquires a hard claim on `internal/db/`, the table shows Total active: 1 and blocking hard: 1 (see Multi-Agent Workflows for hard vs blocking-hard semantics)

The claims shot depends on a credentialed provider setup turn calling the workspace_claim tool; if that turn does not land, the table may show zero active claims even though the inspector surface is live.

Live BMO terminal: non-interactive bmo run --quiet output suitable for CI logs. Pair with sandbox backends when using --auto-approve-tools on shared runners.

Live BMO TUI: /serve-mcp export status — enabled transport, proxy guard mode, and the default read-only exposed_tools set (mutations via opt-in bmo_run).

Live BMO TUI: the /workspace-claims table during parallel agent work — same surface as Multi-Agent Workflows, scoped for the proof gallery.

What a healthy run looks like

In the debugger, a completed solo turn typically shows:

A run row in the session family list
Ordered events: prompt assembly → tool calls → terminal status
No unexplained degraded posture on linked status surfaces

See Agent debugger — healthy run.

Decision-guided software synthesis — evidence-backed lifecycle behind the conceptual map
Change synthesis — command reference for that lifecycle
Why BMO
Decision guide
Performance — latency evidence