Preservation
A property, not a feature
In digital preservation, fixity means that a digital object has remained identical to itself between two points in time. It isn’t a software feature: it’s a property you establish, document, and re-check.
The useful claim is never “this file is intact” — nobody can know that in the absolute. It’s: “this file is identical to what it was on 14 March, the date I recorded its checksum.”
How it’s established
You compute a cryptographic checksum of the file — in practice a SHA-256 hash — at the moment it enters the archive. It’s a fixed-length string derived from every byte. Change a single bit and the checksum becomes unrecognisable.
That checksum is stored alongside the inventory. Later you recompute and compare. Two identical values: the file hasn’t changed. Two different values: something happened, and you need to find a sound copy.
Why a backup isn’t enough
A backup faithfully copies whatever it’s given, corruption included. That’s its job, and also its limit: it passes no judgement on what it copies.
Without checksums, you discover the problem the day you open the file — often years later, once every copy has already been overwritten by the damaged version. With checksums, you discover it at the next check, while a sound copy still exists.
What a fixity check must produce
- A date of last successful check, per file.
- An explicit verdict: verified, failed, or unverifiable — never a silence read as success.
- A log of discrepancies found, kept even after repair.
- Usable granularity: knowing “the archive has a problem” doesn’t help; knowing which of 40,000 files moved does.
In practice
- Compute a checksum as each file enters the archive.
- Re-check in regular campaigns, not only after an incident.
- Treat a failed computation as a failure, never as “nothing to report”.
- Update the last-checked date only after a successful audit.
- Keep the log: it’s what documents the collection’s health over time.
Obscura Flow computes checksums at import, runs fixity audits in campaigns, and only updates the timestamp after a successful check — a failure stays visible instead of being erased by the next pass.