B4 AIP preservation (JGG)

B4.1 Repository must have specifications of how the AIPs are stored down to the bit level.

Supporting Text

The repository must specify the format (with representation information down to the bit level) of each AIP component and must specify how the separate components are packaged together.

This is necessary in order to ensure that the information can be extracted from the AIP over the long-term.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement Documentation of the format of AIPs;

EAST and DEDSL descriptions of the data components; <br. BA 16April2009 - There are spacing and bold issues here. I also think EAST and DEDSL are specific to the space discipline and not of general understanding. Other examples should be listed such as: "the repository's internal of designated community's standard AIP storage standards; system processing logs; validation and verification records."

DG 20090418: EAST and DEDSL can be applied to many types of data. However additional examples would be useful

Discussion
A description of the format (Representation Information in OAIS terms) must be available for each AIP and must be appropriately linked to the AIP. Often, repositories are tempted to describe AIP content only down to a level where a program will then be used to convert the information to a form understandable to their Designated Communities. However, if those programs ever fail to operate, then the information would be lost in all the AIPs that relied on that program.

B4.1.1 Repository must preserve the Content Information of AIPs.

Supporting Text
The repository must be able to demonstrate that the AIPs faithfully reflect the information was captured during ingest and that any subsequent or future planned transformations will continue to preserve all the Significant Properties of the Content Information. This is necessary because it is the fundamental mission of a repository to preserve the Content Information for its Designated Communities.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Preservation workflow procedure documentation;

workflow procedure documentation;

Preservation Policy documents specifying treatment of AIPs and under what circumstances they may ever be deleted;

Ability to demonstrate the sequence of conversions for an AIP for any particular digital object or group of objects ingested;

Documentation linking ingested objects and the current AIPs.

Discussion
One approach to this requirement assumes that the repository has a policy specifying that AIPs cannot be deleted at any time. This particularly simple and robust implementation preserves links between what was originally ingested, as well as new versions that have been transformed or changed in any way. Depending upon implementation, these newer objects may be completely new AIPs or merely updated AIPs. Either way, persistent links between the ingested object and the AIP should be maintained.

B4.1.2 Repository must actively monitor the integrity of AIPs.

Supporting Text
In OAIS terminology, this means that the repository must have Fixity Information for AIPs and must make some use of it. This is necessary in order to protect the integrity of the archival objects over time.

A repository should have logs that show actions taken to check the integrity of archival objects. This is necessary 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.
[JGG Note: I think this should be in the introduction to this document]

This is necessary to ensure that AIPs have not been changed. documentation that integrity checks are carried out on a regular basis and to allow interested parties to verify that this is the case.
DG 20090418 - the "documentation that integrity checks are carried out " should probably be "by being able to produce proof that that integrity checks are carried out"

AIP integrity also needs to be monitored at a higher level, ensuring that all AIPs that should exist actually do exist, and that the repository does not possess AIPs it is not meant to. This is necessary to ensure that the repository has not lost any AIPs and that any AIPs that are in the repository meet the criteria and standards expected of the repository.

A repository should have logs that show actions taken to check the integrity of the repository as a whole. This is necessary to document that integrity checks are carried out on a regular basis and to allow interested parties to verify that this is the case.

This is necessary in order to validate the integrity of the repository as a whole.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
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.

.
Discussion
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 must be ablemay 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 toas easily alter the Fixity Information as well.

B4.2 Repository must have contemporaneous records of actions and administration processes that are relevant to storage and preservation of the AIPs.

Supporting Text
The repository must create records of actions associated with archival storage and must create those records on or about the time of the actions to which they refer. This is necessary in order to ensure documentation is not omitted or erroneous or of questionable authenticity.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Written documentation of decisions and/or action taken;

Preservation metadata logged, stored, and linked to pertinent digital objects.

Discussion
The records may be automated or may be written by individuals, depending on the nature of the actions described. Where community or international standards are used, the repository must demonstrate that all relevant actions are appropriately performed.

B4.2.1 Repository must have specifications for all actions taken on AIPs.

Supporting Text

The repository must have written documentation describing all actions that can be performed against an AIP. This is necessary in order to ensure that any actions performed against an AIP do not alter the AIP information in a manner unacceptable to its Designated Communities.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Written documentation describing all actions that can be performed against an AIP.

Discussion

This documentation is normally created during design of the repository. It should detail the normal handling of AIPs, all actions that can be performed against the AIP, including success and failure conditions and details of how these processes can be monitored.

B4.2.2 Repository demonstrates that any actions taken on AIPs were compliant with the specification of those actions

Supporting Text

The repository must have documentation that all actions taken against an AIP are the actions allowed and documented in the design of the archive. This is necessary in order to ensure that any actions performed against an AIP do not alter the AIP information in a manner unacceptable to its Designated Communities.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Preservation metadata logged, stored, and linked to pertinent digital objects and documentation of that action;

Procedural audits of repository showing that all actions conform to the documented processes.

Discussion

Successful preservation of information in the archive is strongly linked to following established and documented procedures to complete any actions that affect the repository data. The more often “special handling” of repository data and the more often this “special handling” is not overseen in a consistent manner, the more likely that the repository held data will be compromised. When procedures are regularly followed, any deviation from procedures that would be likely to cause an alteration in the data will more likely be noticed or if not noticed may be more likely able to be corrected or the timing and likely change could be identified in the future.