Artifact Store

BMO produces a lot of typed output as it works — run results, workflow plans, eval and shadow captures, patch-proposal diffs, scheduler output, A2A task payloads. The artifact store gives you one read-only place to check what’s there and whether it’s healthy: which artifact families exist, which are empty, degraded, unavailable, or unsupported by design — without reading the artifact bodies themselves.

Reach for it when you want to confirm a run actually emitted its output, or triage why an artifact family looks empty or degraded, but you don’t need (or aren’t allowed) to open the raw contents.

Under the hood, artifact storage stays family-owned: each family (typed run output, workflow plans, run-derived artifacts, eval/shadow captures, patch proposal diffs, scheduler run output, and A2A task payloads) keeps its own capture, mutation, retention, and raw-read policies. The shared artifact-store surface is a metadata-only posture layer over those families.

Inspect Posture

Use these read-only surfaces when you need to know which artifact families are available, empty, degraded, unavailable, or unsupported by design:

Surface	Command or route
CLI	bmo config show-artifacts or bmo config show-artifacts --json
TUI	/artifacts, /artifact-status, sidebar Artifacts
Agent tool	artifact_status
MCP	bmo_get_artifact_posture
HTTP	GET /v1/artifacts/posture

Each surface reports family id, state, bounded counts, reason, drill-in hint, and recent bounded evidence when available. The posture output does not return raw report bodies, prompt snapshots, diff bodies, replay payloads, logs, or rendered HTML.

Source Truth

Typed run output keeps Markdown and JSON emitted through emit_result as the authoritative result. Rendered companions such as HTML reports must be recorded through emit_artifact as workspace-local references. Rendered companions need source-pairing metadata, such as artifact_role=companion plus source_path or provenance, so agents and operators can see that the companion is subordinate to a Markdown or JSON source.

Verifier Submissions

When a run is graded by a verifier, one artifact carries the change under review (typically a patch) and becomes the run’s verifier submission. Agents control which artifact is submitted through emit_artifact metadata roles:

artifact_role	Meaning
submission_candidate	Eligible for submission. Any patch-kind artifact is treated as a candidate even without this role.
verification_input	The explicit submission. Set on exactly one artifact when a run produces multiple candidates.
superseded_submission	A retired candidate, excluded from selection.

Artifacts that set an explicit submission role are required to carry source_path or provenance — emitting one without pairing metadata is rejected — so the selected submission stays traceable. A bare patch with no role is still a candidate, but the pairing metadata is not enforced on it; if you omit it, the selected submission is reported with empty provenance and cannot be traced, so pair it anyway.

The selection outcome surfaces in non-interactive run JSON under verifier_input.status:

verifier_input.status	Meaning
selected	Exactly one submission was chosen (a single candidate or an explicit verification_input); its path, kind, role, and provenance are reported.
ambiguous	Selection could not resolve to one submission — either two or more active candidates remained with no verification_input, or more than one artifact was marked verification_input. The run fails non-retryably. Resolve by marking exactly one intended artifact verification_input and/or the others superseded_submission.
none	Nothing to grade — no candidate was emitted, or every candidate was marked superseded_submission. Keep exactly one active candidate when a submission must be graded.

The posture layer does not add a generic upload or create API. Family-owned write paths remain the only mutation paths, including eval/shadow capture, workflow plan updates, patch proposal diff storage, scheduler run residue, and A2A protocol task artifacts.