The repository shall provide an independent mechanism for verifying the integrity of the repository collection/content.

This is necessary to enable the audit of the integrity of the collection as a whole.

Documentation provided for 4.2.1 through 4.2.4; documented agreements negotiated between the producer and the repository (see 4.1.1-4.1.8); logs of material received and associated action (receipt, action, etc.) dates; logs of periodic checks.

It is the responsibility of the repository to choose the appropriate mechanism for checking the completeness and correctness of its collections. In general, it is likely that a repository that meets all the previous criteria will satisfy this one without needing to demonstrate anything more. As a separate requirement, it demonstrates the importance of being able to audit the integrity of the collection as a whole. For example, if a repository claims to have all e-mail sent or received by The Yoyodyne Corporation between 1985 and 2005, it has been required to show that: – the content it holds came from Yoyodyne’s e-mail servers; – it is all correctly transformed into a preservation format; – each monthly SIP of e-mail has been correctly preserved, including original unique identifiers such as Message-IDs. However, it may still have no way of showing whether this really represents all of Yoyodyne’s email. For example, if there is a three-day period with no messages in the repository, is this because Yoyodyne was shut down for those three days, or because the email was lost before the SIP was constructed? This case could be resolved by the repository’s amending its description of the collection, but other cases may not be so straightforward. A familiar mechanism from the world of traditional materials in libraries and archives is an accessions or acquisitions register that is independent of other catalog metadata. A repository should be able to show, for each item in its accessions register, which AIP(s) contain content from that item. Alternatively, it may need to show that there is no AIP for an item, either because ingest is still in progress, or because the item was rejected for some reason. Conversely, any AIP should be able to be related to an entry in the acquisitions register.

APTrust does an initial fixity check upon ingest and then does ongoing fixity checks every 90 days to ensure that ingested content remains unchanged. Each fixity check is then logged as an APTrust PREMIS Event which is viewable through the WebUI and REST API. (See PREMIS Events).

Documentation about the definition of SIPs and AIPs and how a SIP becomes an AIP can be found here: Definition of AIPs.

Documentation about the ingest process and initial fixity check can be found here: Ingest.

Documentation about ongoing fixity checks can be found here: Fixity Checking.

See also 3.5.1 Contracts or deposit agreements for content for information about the deposit agreement between contributors and APTrust.

Depositors can restore any of the materials they own at any time for inspection. In addition, APTrust randomly restores objects to depositors on a regular schedule so they can verify the completeness and integrity of files and intellectual objects. For more information on that restoration spot tests, see 4.2.7.2 Execute testing process of Content Information of AIPs#Examples Provided.