Version history
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 week. Clavitor doesn't work that way. Every change writes a new revision. Nothing is ever overwritten.
The idea in one minute
A credential in Clavitor isn't a row you edit — it's a stack of revisions. Update a password and the vault adds a new version on top; it never touches the old one. Reading a credential always returns the latest version — exactly the value you expect — while every version before it stays intact, in order, for the life of the vault.
A delete works the same way: it doesn't erase, it writes one final revision that marks the entry 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's built this way
When every edit destroys the thing before it, whole classes of question can't be answered. Immutability answers them by construction:
- "What was the password during the incident window?" A rotated secret usually vanishes the instant it's replaced. Here it's still in the vault, at its version, with the timestamp that proves it.
- "Did anyone change this, and when?" Every revision is a fact on the record, not a log you hope someone kept.
- "Was this credential really removed?" The tombstone proves the removal happened, and when.
The honest trade-off: history costs storage, and it is deliberately not selectively erasable — that's the property, not a bug. What that means for you →
In this section
- How revisions work — the model, in plain terms
- Viewing past versions — open an entry's history
- Deleting & tombstones — what "delete" means here
- Limits, honestly — what this costs and can't do
- How it works — the design, minus the secrets