Category: Digital Preservation

Archival Information Package

Also known as:

Simply put

An Archival Information Package (AIP) is a bundle that groups a digital object together with the descriptive information and supporting materials needed to preserve it over the long term. Within the OAIS framework, the AIP is the version of an information package that a repository commits to keeping and maintaining into the future. It typically combines the content itself with metadata that helps ensure the material remains understandable and usable.

Formal definition

In the OAIS reference model, the Archival Information Package (AIP) is the information package variant that an archival repository is committed to preserving over the long term. It is constructed around the content data object and bundles that object with the additional information, including descriptive and preservation metadata, needed to sustain the information content once the object is stored in the repository. Implementations may realize the AIP using integrity-checked, self-describing container formats; for example, BagIt bags can serve as OAIS AIPs, and specifications such as E-ARK define AIP formats for archival content transferred to a repository for long-term preservation. The AIP is distinct from other OAIS package variants (such as those used for submission or dissemination), and the specifics of its structure depend on the chosen implementation and standard.

Why it matters

The Archival Information Package sits at the heart of what distinguishes long-term digital preservation from ordinary storage. A digital object saved on its own may become unusable over time as the context needed to interpret it is lost. By bundling the content data object with the descriptive and preservation information required to sustain it, the AIP represents the version of the material that a repository formally commits to perpetuating over the long term. For records professionals, this commitment matters because a record's evidential value depends on its remaining authentic, intact, and understandable well beyond the moment of capture, and the AIP is the structure through which a repository seeks to uphold those properties.

The AIP also clarifies a distinction that is easy to blur: the package an organization receives, the package it preserves, and the package it later delivers to users are not necessarily the same thing. Within the OAIS framework, the AIP is specifically the preservation-oriented variant, separate from those used for submission or dissemination. Treating all three as interchangeable can lead to gaps, for example assuming that a well-formed deposit is the same as a properly preserved holding, or that a convenient access copy carries the full preservation context. Being explicit about the AIP as the committed, long-term form helps preservation programs assign responsibility for integrity and understandability to the right stage of the workflow.

Because the AIP's structure depends on the chosen implementation and standard, its practical significance lies in giving repositories a defensible, documented basis for what they hold. Integrity-checked, self-describing containers allow a repository to demonstrate that content has not been silently altered and that the accompanying information travels with the object rather than being stored separately and at risk of becoming detached.

Who it's relevant to

Digital preservation specialists

Those responsible for long-term retention of digital material work directly with AIPs as the committed preservation form of an object. Understanding how the content data object is bundled with descriptive and preservation metadata, and which container format or specification is in use, is central to their work.

Archivists and repository managers

Staff operating archival repositories need to distinguish the AIP from submission and dissemination variants and to ensure that what the repository commits to perpetuate is properly constructed and stored. Integrity-checked, self-describing packages support their ability to demonstrate that holdings remain intact and understandable.

Records managers overseeing electronic holdings

Records managers concerned with the long-term evidential value of electronic records benefit from understanding the AIP because it is the structure through which the context needed to keep a record authentic, understandable, and usable travels with the content over time, rather than being lost.

Systems and standards implementers

Those selecting or building preservation systems must decide how the AIP will be realized in practice, whether through BagIt bags, E-ARK AIP formats, or another approach. The choice of standard shapes the package's structure and the integrity and self-description guarantees it provides.

Inside AIP

Content Information

The core object being preserved together with the representation information needed to render and interpret it. In the OAIS reference model, an AIP packages the target digital object with the metadata required to make it understandable to a designated user community over the long term.

Preservation Description Information (PDI)

The metadata that supports long-term preservation, typically grouped into provenance, context, reference, and fixity information. Provenance documents the object's origin and custody history, context describes its relationships to other objects, reference provides identifiers, and fixity supports integrity verification.

Packaging Information

The information that binds the content and its associated metadata into a coherent, identifiable unit so it can be stored and retrieved as a whole. This is what distinguishes a package from a loose collection of files.

Descriptive Information

Metadata that supports discovery and access to the package, often held in associated finding aids or catalogues. In OAIS terms this typically supports search and retrieval rather than forming part of the preserved package itself, so the boundary should be noted carefully.

Fixity and Integrity Data

Checksums or similar mechanisms that allow the repository to detect corruption or unauthorized change over time, contributing to the integrity and authenticity of the preserved object.

Common questions

Answers to the questions practitioners most commonly ask about AIP.

Is an Archival Information Package the same thing as the file a user submits for preservation?

No. The AIP is typically distinguished from the package a producer submits, which is often described separately as the Submission Information Package. Within the OAIS reference model, the AIP is the version of the information that the repository actually preserves over the long term, usually after ingest processing that may add or complete the preservation metadata needed to sustain the content. It should also be distinguished from the package delivered to a user in response to a request. The AIP is an internal, preservation-oriented construct, and conflating it with what is submitted or what is disseminated can obscure the transformations that occur between those stages.

Does creating an AIP mean the underlying content is now a preserved record on its own?

Not by itself. An AIP is conceived as a package that binds the content together with the metadata intended to keep it understandable, usable, and trustworthy over time. The content object alone, without that accompanying preservation description, is generally not what the model treats as an AIP. It is worth being careful here: the AIP is a preservation packaging concept rather than a guarantee of a record's evidential value. Whether the preserved information continues to function as an authoritative record depends on how authenticity, integrity, and usability are maintained through ongoing preservation activity, which the AIP structure is meant to support but does not automatically ensure.

What kinds of metadata are typically expected to travel with the content inside an AIP?

The model generally frames the AIP as combining the content with preservation description information that helps a future user or system make sense of it. In broad terms this often includes information supporting identification, provenance and context, fixity or integrity checks, and the representation information needed to render or interpret the content. The precise set depends on the repository's policies, the nature of the material, and the preservation standards adopted. Because implementations vary, it is advisable to define the required metadata explicitly rather than assuming a universal profile applies.

How does an AIP relate to fixity and integrity checking over time?

Fixity information is commonly included within the AIP so that the repository can verify, over the long term, that the preserved content has not been altered or corrupted. Depending on organizational policy, this often supports periodic integrity checking as part of routine preservation activity. The AIP structure provides a place to hold such information, but the assurance it offers depends on the repository actually performing and acting on those checks. Storing fixity data without a process to use it does not, on its own, sustain integrity.

When might an AIP need to be updated or replaced during its retention?

Preservation is generally treated as an ongoing activity rather than a one-time event, so an AIP may need revision over the course of its retention. This can arise when formats risk becoming obsolete, when representation information must be added or corrected, or when metadata is enriched or amended. Depending on the repository's approach, changes may be handled by updating the package or by creating a new version while retaining a record of what was changed. Organizational policy and applicable preservation standards should govern how such changes are managed and documented.

How should the boundary of a single AIP be decided in practice?

Deciding what constitutes one AIP, as opposed to several, is largely a design and policy question rather than a fixed rule. Considerations often include the logical unit of the material being preserved, how it will be described and retrieved, and how disposition or access will be managed. Some implementations package a single item with its metadata, while others aggregate related content. The appropriate boundary depends on the repository's descriptive practices, its systems, and the needs of prospective users, so it is generally advisable to document the packaging rules explicitly and apply them consistently.

Common misconceptions

An AIP is simply a backup copy of a file placed into long-term storage.

An AIP is a structured package that combines the content with the preservation metadata needed to keep it authentic, understandable, and usable over time. A backup preserves bits for recovery but typically lacks the provenance, context, fixity, and representation information that distinguish an AIP within a preservation framework.

The AIP is the same as the package received from a producer or the package delivered to a user.

In the OAIS reference model the AIP is conceptually distinct from the Submission Information Package (SIP) received at ingest and the Dissemination Information Package (DIP) delivered on access. A repository may transform a SIP into one or more AIPs and generate DIPs from AIPs, so treating them as identical can obscure important lifecycle transitions.

Creating an AIP completes the preservation task and no further action is required.

An AIP supports long-term preservation but does not remove the need for ongoing management. Depending on organizational policy, repositories typically monitor fixity, refresh storage, and may migrate or transform content as formats become obsolete, so preservation is an ongoing activity rather than a single packaging event.

Best practices

Package content together with sufficient representation information so the object remains understandable to its designated user community, rather than storing files in isolation.

Capture and maintain Preservation Description Information covering provenance, context, reference, and fixity, since these elements support the authenticity and integrity that distinguish a preserved record from a mere copy.

Keep the AIP conceptually distinct from the submission package received at ingest and the dissemination package produced at access, and document any transformations applied between these stages.

Record fixity values such as checksums at packaging and verify them periodically to detect corruption or unauthorized change over the retention period.

Treat AIP creation as one step within an ongoing preservation lifecycle, planning for storage refreshment and potential format migration as part of continued management.

Align packaging structures and metadata with an established preservation framework such as the OAIS reference model where practicable, adapting to organizational policy and the requirements of the relevant jurisdiction and sector.