4.2.8 Verify each AIP for completeness and correctness
The repository shall verify each AIP for completeness and correctness at the point it is created.
|4.2.8 Verify each AIP for completeness and correctness|
|Status||Ready for review|
|Compliance Rating||Fully compliant|
This is necessary in order to ensure that what is maintained over the long term is as it should be and can be traced to the information provided by the Producers.
Examples for Meeting the Requirement
Description of the procedure that verifies completeness and correctness of the AIPs; logs of the procedure.
The repository should be sure that the AIPs it creates are as they are expected to be by checking them against the associated definition for each AIP or class of AIP (see 4.2.1) and the description of how AIPs are constructed from SIPs (see 4.2.2). If the repository has a standard process to verify SIPs for both completeness and correctness and a demonstrably correct process for transforming SIPs into AIPs, then it simply needs to demonstrate that the initial checks were carried out successfully and that the transformation process was carried out without indicating errors. On the other hand repositories that must create unique processes for many of their AIPs will also need to generate unique methods for validating the completeness and correctness of AIPs. This may include performing tests of some sort on the content of the AIP that can be compared with tests on the SIP. Such tests might be simple (counting the number of records in a file, or performing some simple statistical measure), but they might be complex. Documentation should describe how the completeness and correctness of AIPs is ensured, starting with receipt from the producer and continuing through AIP creation and supporting long-term preservation. Example approaches include the use of checksums, testing that checksums are still correct at various points during ingest and preservation, logs that such checks have been made, and any special tests that may be required for a particular AIP instance or class.
APTrust verifies that each AIP, once created, matches the SIP it was created from during the ingest process. This is done through a fixity check upon ingest, the results of which are stored as an APTrust PREMIS Event. Information on the ingest process and initial checksums can be found here on the Ingest page.