The essential answer
A checksum is a compact value computed from file data and useful for checking whether the bytes match an earlier reference. It helps detect change; it does not judge whether the original content was correct or meaningful. Library of Congress guidance describes fixity checks as a way to identify file alterations. The important distinction is between unchanged data and useful information. A file can remain unchanged while containing an error, lacking context, or requiring software that is no longer available.
How to reason about it
Think of a fixity comparison as a very specific question: does this object's data match the reference used for comparison? Its value depends on the reference and on how the comparison is interpreted. A mismatch prompts investigation because a change may be intentional or unintended. A match supports continuity of bytes relative to that reference, rather than the truth of a document's assertions. This distinction becomes especially important when an archive also performs transformations. An intentional conversion creates a different file, so expecting its checksum to match the original would misunderstand the operation. The two versions need a recorded relationship. By keeping byte continuity, version history, and semantic quality separate, a reader can understand what each check contributes without asking one mechanism to establish everything.
ILLUSTRATIVE · NOT A REPORTED RESULT
An example to work through
Assume a fictional table incorrectly labels a distance column as minutes. The archive computes a reference checksum and later obtains a matching value. The check supports that the archived bytes match the reference; it does not correct the unit label. Now assume an authorized editor fixes the label. The file changes, so a different checksum is expected. The archive should explain the correction and preserve the relevant version relationship. This example uses no real hash values and makes no claim about a particular algorithm. It illustrates why detecting change and judging change are distinct tasks.
Where interpretation fails
Avoid saying checksum passed, therefore the archive is valid. The check has a narrower meaning. Also avoid treating every mismatch as corruption before examining authorized changes and reference history. A useful status message states what was compared and whether the comparison established a match.
The next decision
Use fixity evidence to assess byte continuity, then evaluate readability, completeness, and meaning separately. When a mismatch occurs, investigate its cause and version history. When a match occurs, retain the exact scope of the conclusion rather than treating it as proof of authenticity or correctness.
Sources & context
These sources support the concepts noted below. Our synthetic examples and research framing are educational interpretation; they are not findings from these organizations or validation of our ventures.
- Digital Preservation Practices ↗
LOC guidance explains fixity checks and detecting file alterations.
Source check: Official guidance opened; fixity passage reviewed.
Educational research context, not a validated device specification or clinical protocol. Read our editorial and correction policy.