Reference Glossary
Fixity check
A checksum-based verification, rooted in archival preservation practice, confirming that a digital file remains 'fixed' — unchanged — over time.
Why it matters in a DAM
Fixity checking comes from the digital preservation and archival world (formalized by bodies like the National Digital Stewardship Alliance) and is the term DAM platforms serving archives, museums, broadcasters, and legal teams adopt for scheduled, documented proof that a file hasn't been altered, as distinct from a one-off technical check at upload. NDSA's Levels of Digital Preservation treat fixity checking as a baseline requirement for any system claiming to be a trustworthy long-term repository, which is why procurement for archival-grade DAM often asks specifically whether fixity is checked and logged, not just whether backups exist.
A worked example
Common mistake
Treating 'fixity check' and 'backup' as interchangeable — a backup can faithfully copy a file that's already corrupted, while a fixity check is what actually detects that the corruption happened in the first place.
Fixity is a term borrowed directly from archival and preservation practice: a digital object has fixity when it stays exactly the same, byte for byte, as the version originally accepted into a repository. A fixity check verifies that by comparing a checksum computed now against one computed at an earlier, trusted point — most commonly at ingest — using algorithms like MD5, SHA-1, or SHA-256.
The National Digital Stewardship Alliance’s Levels of Digital Preservation frame fixity checking as a baseline expectation, not an optional extra, for any system claiming long-term custodial responsibility over digital assets. For a DAM operating in an archival, broadcast, or legal-evidence context, this means fixity checks need to be scheduled, logged, and auditable — a checksum computed once at upload and never revisited doesn’t satisfy what the preservation community means by fixity, because it can’t detect corruption introduced later in the asset’s lifecycle.
Frequently asked
What is a fixity check?
A fixity check is a checksum-based verification, rooted in archival preservation practice, that confirms a digital file remains "fixed"—unchanged—over time. A cryptographic hash is computed for the file and compared against a baseline value recorded at an earlier, trusted point, typically ingest. A mismatch signals bit rot, storage-media failure, or unauthorized alteration, even when the file's size and filename look unchanged.
Where does the term "fixity" come from?
The digital preservation and archival world, formalized by bodies like the National Digital Stewardship Alliance (NDSA), whose Levels of Digital Preservation treat fixity checking as a baseline requirement for a trustworthy long-term repository.
Is a fixity check the same as a backup?
No. A backup faithfully copies a file's current state—including any corruption already present—so a compromised asset can be backed up over and over without anyone noticing. A fixity check doesn't restore anything; it simply compares a stored checksum against a newly computed one and reports a mismatch. Detecting corruption and recovering from it are separate jobs: fixity catches the problem, then a clean backup or prior version restores the file.
What algorithms are used for fixity checks?
Fixity checks typically use cryptographic hash algorithms—MD5, SHA-1, or SHA-256—that map a file's bit data to a fixed-length digest. Even a single altered bit produces a completely different hash, making tampering or corruption easy to spot. The computed digest is compared against a checksum recorded at an earlier, trusted point, most commonly at ingest. SHA-256 is increasingly preferred over MD5 and SHA-1 for stronger collision resistance in archival and legal contexts.
Why do archival, broadcast, or legal-evidence DAM deployments need fixity checks specifically?
Because those contexts need checks that are scheduled, logged, and auditable—a checksum computed once at upload and never revisited doesn't satisfy what the preservation community means by fixity. Broadcast masters and archival collections must survive for decades across storage migrations, where bit rot accumulates silently. Legal-evidence assets add chain-of-custody demands, so a fixity log recording the algorithm, date, and result of each check gives courts or regulators documented proof the file wasn't altered since capture.
What data model defines fixity information?
PREMIS (PREservation Metadata Implementation Strategies) is the data dictionary that defines fixity information as data used to verify an object hasn't been altered in an undocumented or unauthorized way. Within PREMIS, a fixity check is recorded as an event, capturing the checksum value, the algorithm used, and the date the check ran. That structured record is what lets an archive prove, later, exactly when and how each verification took place.
Sources
- The most common checksum algorithms used in digital preservation are MD5, SHA-1, and SHA-256; PREMIS defines fixity information as data used to verify an object hasn't been altered in an undocumented or unauthorized way. checked 2026-08-07 — National Digital Stewardship Alliance (NDSA)