Docs / Reference / The evidence layer

The evidence layer

Most observability stores records and asks you to trust the vendor that stored them. Mesedi is built so you do not have to: the record is anchored, hour by hour, in a public log Mesedi does not control, and anyone can check it offline with a verifier they built themselves from source.

How it works

Every hour, per tenant, Mesedi builds a Merkle tree over the events ingested in that window and records a checkpoint over its root. Each checkpoint is anchored to Rekor, Sigstore’s public transparency log, and commits to the previous checkpoint’s position in that log. Because the anchor lives in infrastructure outside Mesedi’s control, altering an already-anchored record afterward would require rewriting a public log that thousands of other projects also depend on.

Checkpoints also carry cumulative event counts, which is the detail that makes selective omission visible: a truncated export refutes itself, because the counts in the surviving checkpoints no longer add up to the record presented. Deleting the inconvenient hour does not produce a smaller clean record; it produces a record that fails verification.

Check it yourself

Every verification report Mesedi produces ends with the same four steps, and the second one is deliberately a refusal: do not accept a compiled verifier from Mesedi, because a verdict from a program the audited party handed you is that party asserting again.

  1. Confirm the report is about your file: shasum -a 256 <export.json> must match the Export SHA-256 the report states.
  2. Build the verifier yourself from source: clone github.com/mesedi-ai/mesedi, check out the exact commit named in the report, and go build ./cmd/mesedi-verify.
  3. Run it on the same file: ./mesedi-verify --offline <export.json>. Offline needs no network and is the stronger check; drop the flag to also ask the public log about any checkpoint with no stored proof.
  4. Compare. Any disagreement between your run and the report is a finding, and should be treated as one rather than resolved in Mesedi’s favour.

The boundary, stated plainly

Anchoring proves the record existed by a point in time and was not altered or truncated after anchoring. It does not prove the events were true when they were written. Evidence begins at ingestion: an SDK that never reported an action produced a record that never contained it, and no anchoring can conjure what was never sent. The record_integrity detector covers the adjacent question of whether the record is internally complete, with the same candour about what it cannot see.

Why the restraint matters: an audit trail that can be checked by the counterparty is worth something in a dispute, a post-incident review, or a regulator’s question, in a way that a vendor’s database row is not. An eight-month gap between an agent incident and its discovery by transcript rescan is the failure mode this layer exists to close: the record is committed while it is fresh, and anyone can prove it was not rewritten after the fact.

The verifier, the checkpoint format, and the anchoring code are all in the open MIT repo at mesedi-ai/mesedi, under backend/cmd/mesedi-verify and backend/attest.