OmeaSign in

Docs · Evidence bundles & replay

One file that proves a run happened — checkable with us nowhere in the loop.

An evidence bundle seals a completed run into a single evidence-<run-id>.tar.zst: the verdict stream, the coverage before/after, the kept tests, the traces, and a SHA-256 for every one of them. You can verify it offline; verified ingest can reconstruct the run as a replay. The point is that you never have to trust the agent that produced it — only the artifact, which you can re-hash yourself.

What a bundle contains

omea report <run-dir> packages one completed run directory into a single replayable, shareable artifact. Unzip it and it is just a directory you can read:

manifest.json      bundle format version, run id, repo, commit SHA, tool
                   versions, a SHA-256 content index for every payload file,
                   and an honest missing[] list of what the run did not produce
verdicts.ndjson    the full run output stream, copied byte-for-byte from the
                   run, never re-serialized (schema_version 2)
coverage/          raw before.json + after.json coverage, plus the derived
                   delta.json — the newly-covered lines, line by line
kept-tests/        the kept @playwright/test specs, exactly as recorded
artifacts/         the traces, screenshots, and videos the run produced
README.md          generated, offline-readable verify + replay instructions

manifest.json is the index envelope, so it is the one file not in its own index — everything else is fingerprinted. Optional directories are never fabricated: if a run produced no coverage, no kept tests, or no traces, manifest.json's missing[] records the path and the honest reason instead of shipping an empty stand-in.

Verify it offline

The whole value of the artifact is that it checks out without trusting whoever produced it. Three commands, no account, no network:

omea report <run-dir> [-o <out.tar.zst>]
omea report <bundle>
omea push   <bundle>   # verify, then print the manifest headline

verify re-hashes every payload file and compares it against the manifest's content index. It passes only when two things hold at once: every indexed file is present with a matching SHA-256, and no unindexed file rides along — so nothing unverified can be smuggled in beside the real payload. An authentic bundle reports zero failures and exits 0.

Change a single byte anywhere and the check fails loudly, naming the exact file and both hashes — it never silently renders tampered data:

$ omea report evidence-<run-id>.tar.zst
file corrupt: verdicts.ndjson sha256 expected dc83831def860c197…c817e66 got 6668900cb5593105…265afaf

The integrity idea in one sentence: a SHA-256 is a fingerprint of a file — change one byte and the fingerprint changes completely. The manifest records the fingerprint of the raw before/after coverage (for our own published blog-starter run, 1a17ee23… and 218d7936…), so anyone can re-hash those files and confirm the coverage delta was not edited after the run.

Replay verified evidence

The same bundle drives a visual replay. Evidence-bundle ingest verifies an evidence-*.tar.zst exactly the way omea report does before anything is rendered — a corrupt bundle is refused, not shown — then reconstructs the run at /dashboard/replays/:id: behavior verdicts, diagnostic context, and the run summary, rebuilt from the artifact alone.

Bundle ingestion is currently an API capability rather than a primary dashboard workflow. This page will document the exact CLI push command once it lands and does not describe it as available before then.

Honesty is the contract

Absent data is reported absent

A run that produced no coverage, kept tests, or traces records each absence in missing[] with the reason — the bundle never invents a file to look complete.

Corrupt bundles are refused with reasons

A missing, mismatched, or unindexed file makes the whole bundle corrupt. Verify and dashboard ingest both refuse it and return the precise list of what failed — the same failure strings on both paths.

Read next