The Quiet Amnesia of 'Fixity Checks'

In the world of digital preservation, we speak often of "fixity." The term evokes a comforting solidity, a promise that what we have saved will remain unchanged. We perform fixity checks—comparing cryptographic hashes of files against a trusted record—and if the numbers match, we breathe a sigh of relief. The artifact is intact. The bits are safe from the gnawing decay of bit rot. This process has become a piece of received wisdom, a foundational ritual in the faith of digital permanence. But what if this ritual, for all its technical precision, is quietly fostering a different kind of loss?

The problem is that fixity, as we practice it, is a profoundly narrow form of memory. It is the memory of a machine, concerned only with the exact sequence of ones and zeros. A file can pass a fixity check with flying colors, yet be utterly inaccessible, a digital ghost trapped in a format for which no software remains. It can be the only surviving copy of a document in a proprietary, defunct format, its integrity mathematically perfect but its meaning locked away forever. The file is fixed, but it is also forgotten.

This reveals a crucial gap between data preservation and information preservation. We have become adept at preserving the former, treating digital objects as inert vessels. But information is not inert; it is a relationship between data, software, and context. By focusing so intently on the "bitstream," we risk neglecting the ecosystem required to give those bits life. We are like curators who ensure the paper of a manuscript will not crumble, but have thrown away the only key to the cipher in which it is written. The container is preserved, but the contents have been rendered mute.

The Illusion of Completion

Our reliance on fixity checks can create a dangerous illusion of completion. A file bagged, tagged, and verified can be mentally ticked off the "to-preserve" list. The technical work is done. But preservation is never a binary state of "done" or "not done." It is a continuous process of care, of monitoring not just the file's integrity, but the health of the entire technical environment that supports it. A file that never changes is a file that is slowly dying, falling further and further behind the living, evolving world of technology.

A more holistic approach would be to view preservation as a form of active interpretation. Instead of just checking if a file is the same, we should be constantly asking if it is still usable. This requires supplements to the fixity check: migration to new formats, emulation of old environments, and, most importantly, the preservation of the knowledge—the software, the documentation, the context—needed to understand the data. It's a more demanding task, one that acknowledges that we are preserving not just objects, but capabilities.

Fixity checks are not the problem; our over-reliance on them is. They are a necessary, powerful tool, but they are the beginning of the conversation about authenticity, not the end. True preservation must grapple with the messier, more human questions of meaning and use. It’s not enough to know that the ones and zeros are in the right order. We must ensure that someone, someday, can still read the story they tell. Otherwise, our archives risk becoming vast, impeccably maintained libraries of silence.

Notes & further reading

A few pages I came back to while writing this: