The essential answer
In an illustrative migration of 100 files, three initial source-check failures must be resolved before conversion. Of the remaining 97, two fail the stated content validation, leaving 95 accepted outputs. New-format outputs normally have different bytes and therefore different checksums from their sources. The correct test is not source-hash equals output-hash; it is verified source integrity, documented conversion, validated retained content, and a new baseline for each accepted output.
How to reason about it
Fixity asks whether an object has changed relative to a trusted baseline. Migration intentionally changes an object's encoding, so it requires a different comparison from an unchanged copy. A provenance record connects source identifier, original checksum, conversion tool and version, parameters, output identifier, new checksum, and validation outcome. Content validation should target the properties that matter for the collection, such as page count, image appearance, searchable text, timing, or structural metadata. A matching checksum can establish byte-level continuity to the baseline, subject to the hash assumptions, but does not establish that the original file was complete or meaningful. The official NDSA guidance supplies the fixity concept; the workflow counts and acceptance rules in this example are original teaching choices.
ILLUSTRATIVE · NOT A REPORTED RESULT
An example to work through
Begin with 100 illustrative source files and their trusted checksum manifest. Recompute source checksums: 97 match and 3 do not. Hold the 3 mismatches for investigation rather than silently converting them. Convert the 97 verified files into a new format while retaining their originals. Suppose the declared validation checks find 95 acceptable outputs and 2 failures. Accepted migration yield relative to the verified sources is 95/97=97.94 percent; relative to the original intake it is 95/100=95 percent. Record both denominators to avoid disguising the held files. Compute fresh checksums for the 95 accepted outputs and verify those same hashes after transfer to destination storage. If one destination copy differs, there are 94 currently verified destination copies and one transfer exception; the accepted conversion count remains 95. The counts track different workflow states. Resolve the transfer exception from a verified output and recheck it instead of changing the baseline to match corrupted bytes.
Where interpretation fails
Replacing the stored checksum whenever a mismatch appears destroys the evidence the check was intended to preserve. Another error is treating a successful format conversion as proof that layout, metadata, or content survived. A converter can exit successfully while producing an incomplete or semantically altered output.
The next decision
Accept an output only after the predeclared integrity and content checks pass, and retain exceptions as explicit states. For this illustration, 95 files passed migration validation, with destination verification tracked separately. Keep original objects and conversion records so future reviewers can distinguish intentional transformation from accidental change.
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.
- NDSA: What is Fixity, and When Should I Be Checking It? ↗
Fixity checks compare digital content against an established baseline.
Source check: Official report opening sections reviewed
Educational research context, not a validated device specification or clinical protocol. Read our editorial and correction policy.