A logbook that shows when a page was torn out

Think of a bound ledger where every entry is sealed with a stamp, and each stamp is made from that entry's contents plus the stamp of the entry before it. Read the book from the front and the stamps line up. Change a word on an old page and its stamp no longer matches what the page now says, and because every later stamp was built on that one, they stop lining up too. You cannot rewrite one page in the middle without the break being obvious to anyone who checks.

Each entry captures a control-plane event: a node being provisioned or terminated, a sign-in, a change to who can reach what on the mesh, a document being ingested or removed, and administrative actions such as inviting a user or changing a role. Every entry notes what happened, who initiated it, and when. It is a record that an event took place, not a copy of the data involved. Raw documents and vectors never leave your nodes, so they are never written here.

The record has two layers of protection. First, the log is append-only: the database itself refuses any attempt to update, delete, or truncate an existing entry, so no application path can rewrite or erase history. Second, each entry carries a SHA-256hash computed from its own contents and the previous entry's hash, forming a chain. That hash is computed by the database as the entry is written, not supplied by the caller, so a client cannot forge it. An integrity check re-walks the chain from the beginning and reports the first entry whose hash no longer agrees, which is what any edit, deletion, insertion, or reordering produces.

The chain is tamper-evident, not tamper-proof. An operator with direct database access and enough privilege can still remove rows or switch off the guards, but they cannot do it invisibly: the chain breaks and verification flags exactly where. To put a copy beyond any single operator's reach, the trail is designed to feed an external write-once sink such as a SIEM.

Writes are also non-blocking, so a user action is never held up waiting on the log. The trade-off is that if the control-plane database is unreachable at the instant of an event, that write is recorded as an error rather than retried, so completeness depends on the database being available. These are deliberate defaults, not a substitute for shipping the record off-box where the strongest retention guarantees live.