Fixity and Integrity Checking in Digital Preservation

Digital records do not decay the way paper does. A document on a shelf yellows visibly over decades; a file on a disk can become silently and irreversibly corrupt in an instant, with no outward sign that anything has changed. A single flipped bit, a truncated transfer, a failing storage sector, or a careless edit can alter a record without alerting anyone. Because preservation is fundamentally a promise that a record remains what it was when it entered custody, digital archivists need a way to prove that promise has been kept. That proof is the discipline of fixity.

Fixity is the property of a digital object being fixed, or unchanged, over time. Integrity checking is the active practice of verifying fixity—confirming, at intervals and at key moments in a record’s life, that the bits stored today are identical to the bits that were captured, accessioned, or last validated. Together they form one of the load-bearing pillars of trustworthy digital preservation, supporting the broader records management goals of authenticity, reliability, and usability that standards such as ISO 16175 and ISO 15489 articulate for records held in digital environments.

What Fixity Means and Why It Matters

Fixity addresses a deceptively simple question: is this the same file it was before? For a record to serve as evidence—of a transaction, a decision, a legal right, or a historical fact—a custodian must be able to demonstrate that it has not been altered, whether by accident or by tampering. Fixity does not freeze a record’s meaning or prevent authorized migration; rather, it provides the evidentiary trail that lets an institution detect unauthorized change and respond to it.

The threats fixity guards against are diverse. “Bit rot” describes the gradual physical degradation of storage media. Transmission errors corrupt files as they move across networks or between systems. Hardware and software faults, malicious actors, and ordinary human mistakes all introduce risk. Without fixity verification, none of these may be noticed until the record is needed—at which point recovery may be impossible. This is why the Library of Congress and other digital preservation programs treat fixity as a baseline requirement rather than an optional refinement.

Checksums and Cryptographic Hashes

The workhorse tool of integrity checking is the checksum, most commonly produced by a cryptographic hash function. A hash function reads an entire file and produces a short, fixed-length string—a digest—that acts as a fingerprint. Change even one bit of the file and the resulting digest changes dramatically. To verify fixity, a system recomputes the digest and compares it against the value recorded earlier; a match indicates the file is unchanged, while a mismatch flags corruption or alteration.

Several algorithms are in common use, and the choice involves trade-offs:

• MD5 and SHA-1 are fast and widely supported, but both are cryptographically broken in the sense that an adversary can deliberately craft collisions. They remain serviceable for detecting accidental corruption, which is the most frequent preservation threat.
• SHA-256 and other members of the SHA-2 family are the prevailing recommendation where resistance to intentional tampering matters, and they are now the default in many preservation workflows.

A practical pattern is to store more than one type of checksum, or to record the algorithm alongside the digest, so that future custodians can both verify against the original and migrate to stronger algorithms as cryptographic standards evolve.

Integrity Checking in the Preservation Workflow

Fixity is not a one-time stamp; it is woven through the entire lifecycle of a digital object. Key checkpoints include:

• At capture or ingest. A checksum is generated as early as possible—ideally by the creator or transferring agency—so that fixity can be confirmed the moment the record enters the repository.
• On transfer. Whenever an object moves between systems, storage tiers, or institutions, checksums verify that the copy received matches the copy sent.
• At rest, on a schedule. Repositories periodically recompute checksums for stored objects to catch silent corruption before it spreads to backups.
• On access and migration. Before serving a record to a user or transforming it into a new format, the system confirms the source object is intact, and it generates fresh fixity values for any new derivative.

These events should be captured as preservation metadata. Recording when fixity was checked, which algorithm was used, what value was obtained, and whether the check passed creates an auditable history. Packaging conventions such as the BagIt specification formalize this by bundling content with a manifest of checksums, making fixity portable across systems and verifiable by any recipient.

Fixity, Authenticity, and the Audit Trail

It is important to distinguish fixity from authenticity. Fixity proves that the bits have not changed; authenticity is the broader claim that a record is what it purports to be and was created by who it purports to come from. Fixity is necessary but not sufficient for authenticity, which also depends on provenance, chain of custody, and reliable metadata. A robust integrity-checking regime nonetheless strengthens authenticity by supplying objective, repeatable evidence that custodians have maintained the record faithfully.

This evidentiary value extends into legal and compliance contexts. When records may be produced in litigation or in response to access requests, the ability to show an unbroken fixity record helps demonstrate that evidence has not been altered. Federal records guidance from NARA and recordkeeping standards generally expect agencies to maintain records in a way that preserves their integrity throughout the retention period—an expectation that integrity checking directly operationalizes.

Governance, Tooling, and Trustworthy Repositories

Technology alone does not deliver fixity; governance does. An institution needs documented policy specifying which algorithms it uses, how often it verifies, how many copies it keeps, where those copies live, and—critically—what happens when a check fails. A detected mismatch should trigger a defined response: isolate the affected object, consult an independent copy, restore from a verified backup, and record the incident.

Several principles guide mature programs. Redundancy matters: keeping multiple independent copies, ideally in geographically separated locations, means a corrupted file can be repaired from a known-good replica rather than lost. Independence matters too—fixity values should be stored separately from the objects they describe, so a single failure cannot quietly compromise both. These practices underpin the audit frameworks used to certify trustworthy digital repositories.

Worth noting in the records management landscape is that NARA revoked its longstanding endorsement of the DoD 5015.2 certification regime in 2022, shifting toward the Universal Electronic Records Management Requirements developed through the Federal Electronic Records Modernization Initiative (FERMI). That shift reflects a broader move away from product certification toward functional, principle-based requirements—an approach well suited to fixity, where the goal is not a particular tool but a demonstrable, ongoing capability to prove that records remain unchanged over the long term.