A digital file can look perfectly ordinary on Monday and be damaged by Friday without acquiring a scratch, stain or torn corner.
Digital preservation begins with an uncomfortable fact: computers are extraordinarily good at copying bits, but stored bits are not automatically immortal. Hardware fails. transfer processes truncate files. software writes to the wrong location. human operators replace the wrong object. storage systems return errors. malicious change can occur. A file can also be altered legitimately, creating a new version that must not be confused with the old one.
Digital fixity is the discipline of detecting whether the bitstream that represents a digital object has changed relative to a previously recorded reference state. The usual mechanism is a checksum or cryptographic hash: calculate a compact fingerprint from the file, store that fingerprint separately with trustworthy metadata, then recalculate it later and compare.
This is a specialist branch beneath How Archives Work, How Library Preservation Works and How Digital Libraries Work. The broad owners explain archival custody and long-term access. Fixity owns one narrower question: how does the repository know that the bits it holds now are the same bits it intended to preserve?
1. Fixity Is a Comparison Between Two States
A checksum has meaning only in relation to a reference. Calculate a hash today and it tells you what fingerprint the file has today. Preserve that hash and calculate the file again next year: if the values match under the same algorithm, the repository has strong evidence that the bitstream did not change.
If the values differ, fixity has not told you automatically which copy is correct. It has told you something more basic and extremely important: the current object and the recorded reference state are not identical at the bit level.
2. Checksums Turn a Large File Into a Small Fingerprint
A hash function reads the sequence of bytes and produces a fixed-length output. Change even a small part of the input and the output will usually change dramatically.
This makes hashing efficient for integrity checks. The repository does not need to compare two multi-gigabyte files byte by byte every time. It can compare their stored and newly calculated fingerprints.
The existing How Lossy Works | Hashing article owns the general mechanism of turning an entire message into a fingerprint. Digital fixity owns the archival use of that fingerprint across time.
3. The First Checksum Must Be Created at a Defensible Moment
When should the baseline fingerprint be calculated?
Ideally, fixity information is captured as close as practical to the point at which a trusted transfer or ingest state is established. If a donor or producing system supplies a checksum, the receiving repository can verify the transfer against it. If no external checksum exists, the repository can establish one after successful receipt and validation, then record that moment explicitly.
The timing matters because a checksum cannot prove what happened before it was calculated. If a file was already corrupted when the baseline was created, later matching checks simply prove the corrupted copy stayed stable.
4. Fixity During Transfer Detects Handoff Damage
Digital objects frequently move: creator to archive, workstation to storage, storage tier to storage tier, repository to replica, old hardware to new hardware.
A useful transfer contract is:
calculate before transfer → move the object → calculate after transfer → compare → accept only if the expected state is preserved.
This makes the handoff testable. The movement itself becomes an evidence-producing event rather than an invisible assumption.
5. Scheduled Fixity Checks Detect Change at Rest
A repository that calculates a checksum once and never checks again has recorded a baseline without building a preservation loop.
Repositories therefore perform periodic verification according to risk, scale, storage architecture and institutional policy. The schedule may vary across collections. Highly replicated object storage can expose integrity signals differently from removable media or locally managed disks. Very large collections may use staged or sampled operational strategies while ensuring every object remains within a controlled verification regime.
The National Digital Stewardship Alliance’s 2025 Fixity Survey, published in 2026, shows that fixity practices remain widespread but operationally diverse across institutions. See NDSA’s 2025 Fixity Survey Report announcement.
6. A Fixity Failure Is the Beginning of Diagnosis
When a checksum fails, the repository needs a controlled incident route.
- Quarantine or protect the suspect copy from further automated change.
- Recalculate to exclude transient read or tool error.
- Compare against independent replicas and prior checks.
- Inspect logs for transfer, storage, operator or software events.
- Determine whether the difference was authorised version change or unintended corruption.
- Recover from a known-good replica when one exists.
- Verify the restored object.
- Record the event, cause, action and outcome.
Fixity therefore connects directly to How Fault Detection Works and How Repair Routing Works. A mismatch is a signal. Preservation begins when the institution can turn that signal into bounded recovery.
7. Redundancy Makes Fixity Actionable
A checksum can tell you that the only copy is damaged. It cannot reconstruct missing bits.
Digital preservation therefore pairs integrity checking with redundancy: independent copies, preferably across meaningful failure boundaries. If one copy fails fixity and another independently verified copy remains sound, the repository has a repair path.
This is why “three copies” is not enough if all three share the same storage controller, credentials, building or corruption process. Redundancy must be designed against plausible common causes.
8. Algorithm Choice Is Part of the Preservation Policy
Not every checksum algorithm provides the same collision resistance or security properties. Digital preservation does not always require the same adversarial guarantees as cryptographic authentication, but algorithms should be strong enough for the institution’s threat model and supported over the preservation horizon.
Repositories also need algorithm metadata. A hexadecimal string without the name of the algorithm is not a reproducible integrity claim.
9. Fixity Information Must Be Protected Too
If an attacker or faulty process can alter both the file and the stored checksum, a later comparison can falsely report success.
Fixity records therefore need their own trustworthy custody: controlled metadata, append-only or audited logs where appropriate, replication, permissions and preservation events. Integrity evidence must not be easier to rewrite than the object it is meant to protect.
10. PREMIS Turns Fixity Into Preservation Metadata
The PREMIS Data Dictionary includes fixity information as part of object characteristics and provides a broader model for recording preservation Objects, Events, Agents and Rights.
That matters because a checksum value becomes much more useful when linked to the object, algorithm, event date, responsible agent and preservation action that produced it. See the current PREMIS Preservation Metadata Maintenance Activity.
11. Fixity Is Not Authenticity
This distinction is essential.
If a forged document is ingested and hashed, fixity can later prove that the forged file remained unchanged. It cannot prove the document was genuine when it arrived.
Authenticity depends on identity, provenance, chain of custody, context, recordkeeping controls and evidence about origin. Fixity is one component of that larger claim.
12. Fixity Is Not Usability
A perfectly unchanged file can still become unusable if no software can interpret its format, a required codec disappears, encryption keys are lost, external dependencies vanish or the designated community no longer understands the representation.
This is the deeper digital-preservation lesson: bit preservation is necessary for many objects and insufficient for long-term access.
13. Worked Example: A Born-Digital Photograph
A museum receives a TIFF master from a photographer. At ingest, the repository records a checksum. A second geographically separate copy is created and verified. Six months later, routine fixity checking finds that one replica no longer matches.
The repository compares the second replica, confirms it matches the baseline, restores the damaged copy and records the repair event. The image never had to become visibly broken before the system noticed the risk.
14. Worked Example: A Research Dataset
A dataset contains thousands of CSV and documentation files. The preservation system stores a manifest of checksums for every component.
Years later, one file is replaced accidentally during a manual metadata cleanup. The filename and size look plausible. The checksum differs. Fixity exposes the change immediately and lets the repository decide whether the replacement was authorised or erroneous.
15. Worked Example: eduKate Knowledge Assets
Imagine an exported archive of long-form eduKate articles, source packets and metadata. A preservation copy should not rely only on filenames or timestamps. A fixity manifest can prove whether the exported bitstreams later change during storage or migration.
The public WordPress page remains the web manifestation. The preservation package needs stronger internal evidence about the state that was actually deposited.
16. Failure Mode: Recomputing the Baseline After Corruption
If a mismatch appears and the system automatically replaces the old checksum with the new value, it has erased the evidence of change.
Baseline updates should occur only through an authorised version or preservation event with explicit provenance.
17. Failure Mode: Fixity Theatre
A dashboard can show “100% checksums present” while no one knows whether they are ever reverified, whether failed checks trigger action, or whether the checksum store itself is trustworthy.
The meaningful metric is not checksum possession. It is verified integrity with a tested recovery path.
18. A Digital-Fixity Checklist
- Create fixity information at a defensible ingest or transfer state.
- Record the checksum algorithm with the value.
- Verify immediately after important transfers.
- Schedule repeated checks according to risk and architecture.
- Protect fixity metadata from unauthorised modification.
- Maintain independent known-good copies.
- Define quarantine, diagnosis and repair procedures for mismatches.
- Record every fixity check and preservation action as an event.
- Do not confuse fixity with authenticity or usability.
- Test restoration, not only detection.
19. Read the Mechanism Forward, Backward and Sideways
Forward: trusted object state → checksum → storage → later checksum → comparison → pass or incident → repair → verified return. Backward: start from a corrupted file and ask when the last known-good fixity state existed and which handoff first diverged. Sideways: compare archivist, storage engineer, security owner and future researcher. One sees custody, one sees hardware, one sees tampering risk, and one simply needs the object to remain the object.
20. The Civilisation Lesson
Paper often announces damage visibly. Digital objects can fail silently. That changes the architecture of trust.
A civilisation that moves memory into digital form needs machine-readable ways to notice invisible change before corruption is copied, normalised and mistaken for history. Fixity is one of those quiet mechanisms.
Digital fixity does not prove that a record is true. It proves something more modest and foundational: the preserved bitstream is still the bitstream the repository expected to be preserving.
Continue through How Archives Work, How Library Preservation Works and the master How X Works hub. Next: preservation metadata — how a repository records not only the object, but the evidence of everything preservation did to keep it usable.