The repository shall actively monitor the integrity of AIPs.

This is necessary in order to protect the integrity of the archival objects over time.

Fixity information (e.g., checksums) for each ingested digital object/AIP; logs of fixity checks; documentation of how AIPs and Fixity information are kept separate; documentation of how AIPs and accession registers are kept separate.

A repository should have logs that show actions taken to check the integrity of archival objects in order to assure funders, producers, and users—and to allow them to audit/validate—that the repository is taking the necessary steps to ensure the long-term integrity of the digital objects. The repository should also document that integrity checks are carried out on a regular basis, in order to catch any changes in AIPs as soon as possible so that corrective action can be taken as soon as possible. The repository should allow interested parties to verify that this is the case. At present, most repositories deal with this at the level of individual information objects by using a checksum of some form, such as MD5. In this case, the repository should be able, and may want to demonstrate that, the Fixity Information (checksums, and the information that ties them to AIPs) are stored separately or protected separately from the AIPs themselves, so that accidental alteration of the AIP would not also damage the Fixity Information. Also, someone who can maliciously alter an AIP would not likely be able as easily to alter the Fixity Information as well.

Definition of AIP describes how APTrust preserves and maintains the integrity of Content Information and PDI.

After validating the integrity of the SIP during ingest (see Bagging specifications and the Ingest Process flowchart .), APTrust validates the integrity of the AIP using Ongoing Fixity Checks that include updates for administrators and reports of any failed deposits.

Checksum Requirements provides information about fixity checking and ensuring the integrity of the archived digital objects.

The Ingest documentation dictates that submission packages will have to be validated against the Bagging specifications to be considered valid and actionable for ingestion.