Plan and prepare
Select a small folder of finished archive files and make a separate working copy before experimenting with preservation tools. A checksum is a calculated value for a file's bytes. Comparing a later calculation with a trusted earlier value can reveal a change, but it does not tell you whether the original information was true.
Use a reputable checksum tool that supports a current algorithm such as SHA-256 and a clear export format. Record the algorithm, file paths, values, calculation date, and tool used. Keep the resulting manifest outside the set of files being measured, or explicitly exclude it, so the manifest does not try to describe its own changing contents.
Use a clear process
Preserve the baseline manifest with the archive and keep a separate protected copy. If someone can replace both a file and its only recorded checksum, the comparison loses much of its value. Access controls and independent copies complement checksums; a checksum by itself is not proof of authorship or permission.
Run a comparison immediately after copying the archive to another storage device. Verify that the report covers the intended files and identifies missing or extra items as well as changed values. Do not treat a green result for ten files as assurance about a folder containing hundreds of unchecked files.
Worked example
Imagine a folder contains fifty scanned newsletters and a catalog. After organizing the filenames, you calculate a baseline for those fifty-one files and save a manifest outside the measured folder. You then copy the folder to a backup device and run a comparison there. The report should identify the same fifty-one paths and matching values. If it checks only fifty files, investigate the missing catalog even if every reported value matches. Completeness is part of the question: a successful comparison of the wrong selection does not establish the integrity of the intended collection.
Decisions and exceptions
Write a short procedure describing exactly which folder is checked, which files are intentionally excluded, where the manifest is saved, and how the result is recorded. Include an example of a successful report and a deliberately altered practice file so another custodian can recognize a failure. Keep the tool's own instructions available, and use clear names for baseline and later reports. Avoid replacing the trusted manifest automatically after every run, because doing so can erase the evidence needed to distinguish an expected change from an unexplained one.
Check and improve
Decide how deliberate updates enter the archive. An edited catalog may need a new baseline while unchanged newsletter images keep their existing history. Record the reason, date, and responsible person when accepting a new version. For important collections, have another authorized person review the change before the earlier baseline is superseded. Store the manifest and maintenance log in the same independent backup planning process as the collection. Checksums are one check among several: combine them with a usable catalog, access controls, backup copies, and occasional reading tests to establish what is present and whether people can use it.
Solo and community application
Alone, begin with a few important records and keep the instructions alongside the manifest. A community team can have one person run the check and another review the report and scope. Use a practice copy to learn what an intentionally changed file looks like in the results.
Reference guidance
The Library of Congress explains fixity as checking whether digital objects have changed or degraded. This baseline workflow is an implementation suggestion. Schedule repeat checks and record their outcomes, while also opening sample files: unchanged bytes can still belong to an unreadable or obsolete format.