How version history works

You don't need this page to use Clavitor. It's here because the design is worth understanding, and because "trust us" is not a security model.

Append-only by construction

Each entry has one stable identity and a version number. An update is an insert of the next version — never a rewrite of an existing one. The normal write path has no way to overwrite a revision; the latest state is simply the highest version present. Immutability isn't a policy someone has to remember to follow — it's the shape of the storage.

Reading returns the latest

A read selects the highest version for an entry. Two edits that race can't silently clobber each other: the second to land is rejected as a conflict rather than overwriting the first, so no update is ever lost or applied twice without you knowing.

A delete is a revision

Deletion adds a final tombstone revision. Nothing is removed; the entry simply stops resolving to a value. The history — including the fact and time of deletion — stays.

Usage is recorded without rewriting history

When a credential is confirmed working after a successful login, that confirmation is noted on the current revision. It marks use, not a change of content — so it doesn't fabricate a new version in your history. This one carefully-scoped exception is logged in your audit trail like everything else.

Confirmed on the other side

Clavitor runs read replicas on the far side of the planet. Because revisions are append-only, keeping a replica current is just "send everything past what it already has," and a revision is only considered safe once the replica confirms it landed — no revision is quietly assumed to have replicated.

Tamper-evident, end to end

Every revision carries an integrity check. If a stored revision is altered outside the normal path, Clavitor shows it as failed rather than rendering it as if it were authentic — in your history view, a tampered revision reads [integrity check failed], never a silent wrong answer.

> What's deliberately not on this page: how fields are encrypted, how integrity is keyed, and the internal shapes of storage and replication. Those are implementation. Publishing the recipe helps an attacker more than it helps you — the property is public; the mechanism stays in.