Fixity & integrity

Fixity is the property of a digital object being fixed - unchanged - over time, and integrity is the assurance that it has not been altered, whether by accident (bit rot, failed transfers, disk faults) or by tampering. Without fixity checking you cannot honestly claim a record is authentic, because you have no way to detect silent corruption. Fixity turns "we think it's the same" into "we can prove it's the same".

The mechanism is the cryptographic checksum or hash: a fixed-length fingerprint computed from the bytes of a file. Change a single bit and the hash changes completely. Record the hash at ingest, store it in the preservation metadata, and re-compute it on a schedule to confirm the file still matches.

Algorithms and where hashes live

• MD5 and SHA-1 are still widely used for detecting accidental corruption, but are cryptographically broken; prefer SHA-256 (or SHA-512) where tamper-resistance matters.
• Store checksums in PREMIS fixity metadata, and package them with transfers using BagIt manifests (manifest-sha256.txt) so integrity can be verified on arrival.
• Keep more than one copy of the checksum record itself - a hash you cannot trust is no better than none.

Fixity as an ongoing process

• Verify on ingest, on every transfer or migration, and on a recurring audit schedule.
• Hold multiple independent copies so a failed check can be repaired from a good copy, not just detected.
• Log every fixity check as a PREMIS event - including the passes, not only the failures - to build the evidential trail.

Key takeaways

• Fixity checking with checksums is how you detect corruption and prove authenticity.
• Prefer SHA-256 for tamper-resistance; carry checksums in PREMIS and BagIt manifests.
• Fixity is a recurring process backed by multiple copies, with every check logged - so errors can be healed, not just noticed.