Introduction to version history

Most password managers treat a credential as a single editable record. You change the password; the field is overwritten; the old value is gone forever. That is convenient until the day you need to know what the value used to be — after a breach, during an audit, or when a rotation went wrong and you need the previous key back.

Clavitor takes the opposite stance: it keeps everything.

What "keeps everything" means

Every time you change an entry — a new password, an edited username, an added URL — Clavitor records a new revision. The previous revision isn't touched. Over the life of an entry you build up a complete, ordered history:

• Revision 1 is the entry as first created.
• Each change adds the next revision on top.
• The highest revision is the current value — what you see and use day to day.
• If you delete the entry, a final tombstone revision marks it gone, and the history beneath it stays.

You don't manage this. There are no snapshots to take, no "enable history" switch. It is how the vault stores data, always, for every entry.

What you can do with it

• Look back. Open any entry and view its full history — every past value, with the time each change was made. (Viewing past versions →)
• Prove a timeline. Because nothing is overwritten, the record of what was true on a given date is the data itself, not a log you have to trust.
• Recover context. A credential that was changed by mistake still has its earlier value in the history.

What it is not

It is not a backup you restore from, and it is not a sync feature. It is simply the truth that the vault never throws data away. The honest limits — storage growth, and the fact that history is deliberately not selectively erasable — are covered in Limits.