Digital Fixity Check and Repair¶
Integrity verification — instantiates Reference-State Conservation Intervention
Verifies each stored digital object against a saved cryptographic baseline and repairs any corruption from a known-good copy.
Digital Fixity Check and Repair conserves digital objects by comparing each stored file against a cryptographic fingerprint recorded when the file was known to be good, detecting any silent change, and rewriting a corrupted copy from a verified replica. Its defining move is bit-exact reference: the conservation target is not an appearance or a function but an exact byte sequence, and the checksum is a reference state precise enough that a single flipped bit is provable corruption. Unlike a physical treatment, it is automatable, repeatable, and — when redundancy holds — able to return the object to its reference state exactly, byte for byte.
Example¶
A national broadcaster's preservation archive holds roughly 400,000 digitized program files across aging disk arrays. At ingest, each file was hashed and its SHA-256 checksum stored in a manifest — the reference record against which the file will be judged forever after. A scheduled fixity job re-hashes files on a rolling basis and compares each result to the manifest. Most match. One master file of a decades-old broadcast comes back with a different hash: a few bits have flipped on a failing drive — silent corruption, the kind ordinary use would never notice until the file was played and found glitched.
Because the archive keeps multiple independent copies, the system pulls a replica from a geographically separate store, confirms its hash matches the manifest, and overwrites the corrupted copy. The bytes are restored precisely; a provenance note records the corruption event and the repair. Nothing about the program was reinterpreted or "improved" — the reference state was known exactly, so the fix was exact.
How it works¶
- Fingerprint at ingest. Compute and store a checksum for every object when it is known good; that manifest is the reference the future is measured against.
- Re-verify on a cycle. Periodically recompute hashes and compare, so corruption is caught while good copies still exist to repair from.
- Keep independent redundancy. Hold multiple copies across separate media and locations, so a failure in one is not a failure in all — the classic "3-2-1" discipline.
- Repair, don't reinterpret. On a mismatch, restore the exact bytes from a verified replica; the treatment touches only the damaged copy.
Tuning parameters¶
- Check frequency — how often files are re-verified. More frequent checks shorten the window in which corruption can spread to backups, but cost I/O and compute on large holdings.
- Algorithm strength — the checksum function used. Stronger hashes make undetected collision or tampering vanishingly unlikely; weaker but faster ones suffice for accidental corruption.
- Redundancy depth and geography — how many independent copies, on what media, how far apart. More separation survives bigger disasters but costs storage and sync.
- Repair automation — whether a verified replica overwrites automatically or a human approves first. Automation is fast but can propagate a wrong decision; human-in-the-loop is safer but slower.
When it helps, and when it misleads¶
Its strength is catching silent corruption — the bit rot[n1] that ordinary use and even routine backups never reveal — before it quietly propagates into every copy, and then repairing it to a provable, byte-exact reference. It is cheap, scriptable, and among the few conservation treatments that can be genuinely perfect.
Its failure mode is a narrow definition of "intact." A checksum proves the bits are unchanged; it says nothing about whether they remain meaningful — a file whose format has gone obsolete and unreadable passes every fixity check while being just as lost, a decay that needs migration, not repair. If corruption reaches every copy before a check runs, there is nothing good to restore from; and a checksum computed on an already-corrupt file faithfully preserves the corruption. The guarding discipline is to pair fixity with format-obsolescence monitoring and to hold enough genuinely independent copies that at least one clean one always survives.
How it implements the components¶
Digital Fixity Check and Repair realizes the verify-and-restore slice of the machinery for digital objects:
reference_state_record— the stored checksum manifest is the exact, machine-checkable reference each object is compared against.decay_or_drift_diagnosis— a hash mismatch is the diagnosis: it detects and localizes silent bit-level corruption that no human would see.minimum_effective_treatment— repair overwrites only the damaged copy from a verified replica, changing nothing else.
It works on bits, not on rooms or people: it does not implement the care_owner_and_stewardship_handoff scheduling that assigns and funds ongoing care (that is Monitoring and Retreatment Cadence) or the controlled_access_or_environment that shelters a whole collection (that is Environmental Control Protocol). Like Restoration Protocol it returns an object toward a reference, but automatically and byte-exactly rather than by hand on physical material.
Related¶
- Instantiates: Reference-State Conservation Intervention — supplies the integrity check and exact repair for digital holdings.
- Sibling mechanisms: Restoration Protocol · Monitoring and Retreatment Cadence · Environmental Control Protocol · Before/After Condition Photography · Condition Assessment Survey · Conservation Logbook · Conservation Treatment Plan · Minimal Intervention Review Board · Stabilization Intervention
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Digital Fixity Check and Repair operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it verifies each stored digital object against a saved cryptographic baseline and repairs any corruption from a known-good copy.
Independent corroboration: The frozen evidence defines Digital Fixity Check and Repair as 'Verifies each stored digital object against a saved cryptographic baseline and repairs any corruption from a known-good copy', so its operative form is Assessment, Review & Assurance.
Nearest alternative: Intervention, Treatment & Transformation — Verification against saved hashes produces the assurance finding before known-good copies repair any detected corruption.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Digital preservation cohered periodic checksum fixity checks and repair from verified copies to detect and remediate bit rot.
Related originating lineages:
- Computer Science & Software Engineering — Storage engineering supplied cryptographic hashes, scrubbing, replication, and automated repair.
Review resolution: Digital preservation cohered periodic checksum fixity checks and repair from verified copies to detect and remediate bit rot. Digital preservation made fixity a custodial method, while cryptographic hashing and automated repair supply a material computer-science lineage.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Fixity is the digital-preservation term for the property of a file remaining unchanged over time; bit rot is the slow accumulation of undetected bit-level errors from failing media or transfer faults. Fixity checking is the routine that detects the second to guarantee the first. ↩