##  [Fixity Checking](/fixity-checking-0) 

 Definition

The routine process of calculating and comparing stored fixity values (e.g., cryptographic hashes or checksums) for a digital object's bitstream over time to detect unintended changes to its stored representation.

 

 

 

 

 

 





## Principle

Principle

A matching stored fixity value implies the current bitstream equals the recorded bitstream at the time the value was produced; a mismatch implies the bitstream has changed since that recording, triggering investigation or remediation.

 

 

 

 

 





## Demonstration

Demonstration

Illustrative scenario → An archive schedules nightly checksum verification. Recognition: a scheduled job reports a checksum mismatch for an ingested file. Action: staff retrieve the recorded fixity manifest, compare versions, consult backup copies, and restore or quarantine the affected copy. Consequence: corruption or unauthorized modification is detected early and addressed before broader dissemination.

 

 

 

 

## Misapplication

Misapplication

Mistaken interpretation: treating a matching checksum as proof of authenticity, provenance, or semantic integrity. Error: fixity attests only to byte‑level identity relative to a recorded value; it does not establish origin, intent, or correctness of content.

 

 

 

 

 





## Consequence

Consequence

Fixity checking provides a low‑cost, automatable mechanism for detecting bitstream change and supporting integrity monitoring; it cannot by itself prove authenticity, nor can it detect format‑level semantic degradation or authorized in‑place transformations unless those are recorded.

 

 

 

 

## Reversal

Reversal

For file formats that serialize non‑deterministically (embed timestamps, reorder metadata), raw checksums will vary even for semantically equivalent content; normalization or format-aware hashing is required for meaningful comparison.

 

 

 

 

 





## Boundary

Boundary

Clearly within: bitstream integrity verification for preserved files, containers, and storage replicas. Boundary case: compound objects where container metadata changes but payload is stable. Clearly outside: claims about intellectual provenance, semantic accuracy, or format validity that require additional evidence.

 

 

 

 

 





## Semantic Tension

Semantic Tension

Integrity Checking ↔ Format Variability — strict bitwise fixity emphasizes exactness, while many preservation operations and formats produce acceptable semantic equivalence without bitwise identity.

 

 

 

 

 





## Synthesis

Synthesis

Fixity checking is a necessary operational signal for preservation workflows—an objective, automatable detector of change—but it must be combined with provenance, format, and contextual controls to support claims about authenticity or long‑term preservation.