Skip to main content
Merv keeps two stores. Artifacts are small, typed documents whose bytes are sealed as evidence at each gate; object storage holds the heavy files — checkpoints, datasets, logs — with pins and expiry. This page says which is which and how each behaves.

​
Artifacts

An artifact is a typed file submitted against a target — an experiment, reflection, claim, review, or attempt — with a role. The roles are plan, report, graph, result (metrics JSON), project_graph, reflection_lens_doc, reflection_doc, and change_spec. Submitting a gated role pins the bytes, so gates and reviewers read immutable content. Resubmitting the same slot replaces it. Markdown with relative image links gets a follow-up upload command per figure. One role is system-authored: exhibit, the metrics view generated from pinned result files at results submission — readable via experiment.exhibit, never replaceable. Local edits don’t count. Only submitted, uploaded bytes are evidence.

​
Object storage

The agent registers an object with its sha256 and size, runs the upload command the brain returns, and the ledger entry becomes available. Objects carry a kind (dataset, model, or other), optional provenance (producing_experiment_id, producing_run, source_uri), and an expiry. The Storage page in the UI lists objects with status, expiry, and provenance; Settings → Storage sets the project’s per-object limit and can disable storage. Candidates for the project champion point at artifacts or storage objects — never Git. Nothing is copied off a sandbox for you — see Sandboxes. The submit-results step of a run is on Running research.