Version archive

"What did it say
in March?"

A product lives for years and its passport changes. Any past state has to come back on request.

Retrieval

Ask by date, not by version number.

Whoever is asking knows when something happened. They do not know your version numbering.

Passport versions on a timeline, retrieved by date v1 created v2 disassembly guide added v3 recycled content updated today read passport at 2026-05-14 Returns v2 — the state that was in force on that date — filtered by today's access rules.
Four design choices

Each one had a cheaper option.

Snapshots, not differences

Storing only changes makes every later state depend on every earlier one. One bad link and the rest is quietly wrong. We keep whole states.

Archived in the same write

A separate archiving step can crash between the two, leaving a change live and unrecorded. An archive that skips versions is worthless as evidence.

No versions for non-changes

Saving without editing must not mint a version, so content is hashed and compared.

Today's rules, not that day's

Old versions obey today's entitlements. Freezing that day's rules would let looser settings leak through history forever.

Sealing

Frozen is not the same as unrecorded.

A passport is signed and sealed before it ships, and its declared content stops moving. But the editing that happened before sealing is part of the product's life too — and in most systems it leaves no trace at all.

Here the record starts at the first draft. Creation, every edit, the sealing itself and each later translation are all archived, so the question "when was this figure changed, and to what" always has an answer.

How versions are signed and anchored →

Bring your worst audit question.