Evidence that survives the vendor

The record that outlives its vendor

Every enterprise engagement this practice runs ends at the same question: two years from now, with the vendor gone and the team changed, can this decision be reconstructed. For an agent stack the same question is the audit layer, and its answer is a record designed to survive the system that produced it. The layer’s general shape, action-ledger/1, is being drawn from a running instance — a newsroom format, chronicle/1, whose every factual claim carries the sealed record it rests on — because a general audit format is better designed from a working thing than from a specification written in the abstract.

The property that makes a record survive its vendor is that it depends on nothing the vendor uniquely holds. Each action carries a receipt — the record it produced or consumed, at that record’s own home, with its digest — and a reader checks the receipt against the source rather than against the vendor’s copy. When the vendor disappears, the receipts and their sources remain, and the record is still checkable.

A citation is a link, never a copy

The first refusal is that a citation is a link, never a copy. A receipt points at the evidence at its home; it never embeds it. This matters because copying cannot manufacture corroboration: if a record embedded the evidence it cited, a system could produce two byte-identical copies and count them as two witnesses. Pointing at the source means one source is one source, however many records cite it. The trust layer enforces the same rule one level down — a witness whose basis is byte-identical to the performer’s own evidence is one source counted twice — and it is the same rule for the same reason.

Verification is computed, never asserted

The second refusal: a record may not store its own verdict. Fields like verified, proven or true-of are refused by name. Whether a receipt holds is recomputed by the reader against the fetched source; silence is unverified, never verified, and an unreadable source is unread, never zero. This is the difference between a record that says it is true and one a stranger can check is true, and only the second is worth keeping. A human consecrates before anything publishes — an agent drafts, a person signs, and a consent an agent could grant itself would be no consent at all.

Append-only, and a correction that supersedes

The log is append-only, and the seal is derived over the canonical form of the record with the digest removed — so a record that asserts its own digest is refused, an edited row no longer holds, and a replayed digest is refused. A correction is not an edit; it is a new entry that supersedes the one it corrects, naming it and carrying a reason. Nothing is deleted and nothing is quietly changed, which is precisely the property a regulated firm needs from an audit trail and precisely the property a mutable log cannot offer.

The notary leaf reveals a time and a kind, and nothing else

The audit layer feeds a public transparency log, and the design of that leaf is where a firm should look hardest. A leaf is content-free by construction: it is a hash over a non-identifying projection — the record’s own opaque digest, the outcome’s kind, and the time it was sealed — and never over identifying content. A reader learns that an outcome of some kind was sealed at some time, and nothing about who. An identifier drawn from a small, enumerable space — an email, a phone number — is not made safe by hashing it, because a hash of a small-space value is a reversible identifier; so the leaf uses a fresh random handle with no relationship to any real value.

The honest state of that log today is worth stating plainly, because it is how this practice treats every figure: the notary source is local-first, so the server holds no introductions and the served log is empty until a consent-gated publish path supplies real ones. An empty transparency log that says it is empty is more trustworthy than a full one you cannot check — and a practice that operated the earlier generation of public ledgers is exactly the one that should insist on the difference.

• The lab’s view (planned)FlashyLabs is preparing an engineering companion to this piece at https://flashylabs.com/insights/evidence-that-survives-the-vendor — planned, not yet published.
• The studio’s view (planned)The 4 Ventures thesis desk is preparing an investor-lens companion at https://4.ventures/thesis/evidence-that-survives-the-vendor — planned, not yet published.