Immutable vault
Nothing is ever overwritten.
Every other vault edits in place. Change a password and the old one is gone — no record it ever existed, no way to prove what was true last Tuesday. Clavitor doesn't overwrite. Every change writes a new revision. The history stays. The record is complete.
Append-only, all the way down.
A credential in Clavitor is not a row you edit. It is a stack of revisions. Update a password and the vault inserts a new version — it never touches the old one. The latest revision is the current value; every revision before it is still there, intact, in order.
01 — Write
A new revision, every time
Each update is an INSERT, never an UPDATE. The entry keeps one stable identity; the version number climbs. Reading a credential returns the highest version — the same value you'd expect — while every prior version stays exactly as it was written.
02 — Keep
History for the life of the vault
Old revisions are retained for as long as the vault exists. Rotation history, the value before the breach, the field as it stood on any date — none of it is discarded. The past is not a log you hope someone kept. It is the data itself.
03 — Delete
A tombstone, not an erasure
Deleting a credential writes one more revision that marks it gone. The entry stops resolving — but the record that it existed, and when it was removed, remains. A delete you can prove is worth more than a delete that leaves no trace.
Why it matters
The questions a mutable vault can't answer.
When every edit destroys the thing before it, whole classes of question become unanswerable. Immutability answers them by construction.
"What was the key on the day of the incident?"
A rotated secret usually vanishes the moment it's replaced. Here, the value that was live during the window is still in the vault, at its version, with the timestamp that proves it. Forensics stops being archaeology.
"Who changed this, and what did it say before?"
Every update, delete, scope change, and agent change writes an audit event linked to the new revision. The history and the record of who made it are the same story, told two ways — and neither can be quietly rewound. See the tamper-evident audit trail →
"Can we just undo that?"
A bad rotation, a fat-fingered edit, a compromised agent that overwrote a field — when nothing is destroyed, recovering the prior value is reading an earlier version, not restoring a backup and hoping it's recent enough.
"Did anything change while we weren't looking?"
It can't change silently. There is no in-place mutation to miss. The current state is a revision with a number, an author, and a timestamp — and so is every state that came before it.
One principle, the whole vault.
Immutability isn't a feature bolted onto credentials. It is how every record in Clavitor is built. Your entries, the audit log, the wrapped key records, the very content of these pages — all append-only, all the same way. There is nowhere in the system where the truth gets overwritten.
Replicated without conflict
Because a revision is written once and never altered, copying it to the other side of the planet is trivial: a forward-only cursor with an explicit acknowledgment when the row lands. No edit to reconcile, no conflict to resolve, no "which copy is right." Append-only data has exactly one history.
Ciphertext, kept — not plaintext, leaked
Retained history is encrypted at rest, exactly like the live value, with keys that never reach our servers. Keeping the past costs you nothing in exposure: a stolen disk holds old ciphertext and new ciphertext, both equally unreadable. How the encryption works →
The one exception
We document the single place we stamp in place.
Honesty is part of the design. There is exactly one field that is written in place rather than as a new revision: verified_at, the marker that records when a credential last worked. It is usage metadata, not a content change — so it updates the latest revision directly, and every stamp is itself audit-logged. We tell you about it here because an undocumented exception is the thing that makes an immutability claim hollow. This is the only one.
Deletion, done right.
Append-only does not mean you can never be forgotten. It means forgetting is deliberate, complete, and on the record. Per-revision tombstones handle the everyday case. When a real erasure is required — a GDPR request, an account close — the deletion is whole-vault and irreversible, run as a deliberate operation, never a silent per-field overwrite. You are never quietly edited; when you're removed, you're removed on purpose and in full.
An honest vault keeps its history.
Immutability is half the story. The other half is the record of who touched what — chained, witnessed, and provable.