Capture at the edge.
Chain on arrival.
Prove on demand.
Three properties do the work. The interaction is recorded where it happens. The record commits to everything before it. The content can be separated from the proof. Everything else follows from those.
From a keystroke to an attestation.
Why one altered record breaks everything after it.
Each event's hash is computed over its own canonical contents and the hash of the event before it. That single dependency turns a list of rows into evidence.
Canonical, not incidental
The hash is taken over a canonical form with keys in a fixed order, so the same event always produces the same hash however it was serialized. Two independent implementations agree. That is what lets an auditor re-verify with their own code.
Attachments are attested, not embedded
A file's SHA-256 is covered by the event hash, but the bytes live elsewhere. So evidence that a specific file was uploaded survives the file's own deletion. The hash still proves what it was.
Appending is serialized per tenant
Each batch takes the chain head lock once, so concurrent collectors cannot interleave into an ambiguous order. A partially written batch never commits. A gap in the sequence would break verification permanently.
Verification names the break
Re-verification tells apart three things: a record whose content was altered, a link severed by a removal or reorder, and a gap in the sequence. It reports the sequence number and event id for each.
A chain that only checks itself proves less than you think.
An intact chain proves nobody made a careless edit. On its own it does not stop an attacker with database write access from rewriting the whole history, recomputing every hash as they go, and leaving something that verifies perfectly.
Anchoring closes that gap. Chain heads are published periodically to storage outside the database. An attacker rewriting history would have to reach the witness too. If they cannot, the mismatch gives them away.
What the console tells you
An unanchored ledger is reported as self-consistent but unwitnessed, rather than as a green tick. For an evidence tool, overstating the guarantee is about the worst thing you can do.
Delete the content. Keep the proof.
A data-subject erasure and a tamper-evident audit log are usually in direct conflict. Keeping content outside the chain is how that gets resolved.
| Action | Removed | Kept | Chain |
|---|---|---|---|
| Retention sweep | Prompt bodies and file bytes past their period | Event rows, hashes, findings | Intact |
| Subject erasure | All content and files for that person | Event rows proving the interactions happened | Intact |
| Attachment policy: preview only | Original bytes, never stored | Redacted preview, filename, size, hash | Intact |
| Attachment policy: metadata only | All bytes, never stored | Filename, size, SHA-256 | Intact |
Erasure is admin-only. It needs a typed confirmation and a written reason, and it is recorded in the administrative audit trail. The act of deleting evidence is itself evidence.
What you operate.
Control plane
A console and ingest service. Runs on-premises, in your own cloud account, or as a service we operate. See deployment.
PostgreSQL
One database holds the chain, content, blobs and identity graph. Your backups, your encryption at rest, your region.
Collectors
A browser extension deployed by policy, plus whichever server-side collectors match how your teams call models.
External anchor
A small store outside the database for chain heads. Deliberately somewhere your database administrators cannot write.
See it against your own question.
Bring the thing you cannot currently answer. A walkthrough is more useful when it has to survive a real question.