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 checksum-based verification, rooted in archival preservation practice, confirming that a digital file remains "fixed", unchanged, over time.
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 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.
What algorithms are used for fixity checks?
MD5, SHA-1, or SHA-256, compared against a checksum computed at an earlier, trusted point, most commonly at ingest.
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.
What data model defines fixity information?
PREMIS, which defines fixity information as data used to verify an object hasn't been altered in an undocumented or unauthorized way.
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)