An archive does not preserve a file by placing it in a folder. It preserves an information package: the content plus the evidence and context needed to keep that content intelligible, identifiable and trustworthy.
The Open Archival Information System reference model gives this idea a precise architecture. A producer submits information to an archive. The archive transforms that submission into an Archival Information Package, or AIP, suitable for long-term preservation. Later, it can produce a Dissemination Information Package, or DIP, for a consumer.
The current OAIS reference model is CCSDS 650.0-M-3, published in December 2024. See CCSDS 650.0-M-3.
This article sits beneath How Archives Work, How Preservation Metadata Works and How Representation Information Works. The narrow question is: how does a repository keep the preserved content and the information needed to preserve it from drifting apart?
1. Submission, Preservation and Dissemination Are Different Jobs
OAIS separates three package roles.
- Submission Information Package (SIP): the information delivered by a Producer to the archive.
- Archival Information Package (AIP): the package the archive preserves.
- Dissemination Information Package (DIP): the information delivered from the archive to a Consumer.
The three may contain overlapping content and need not be identical. The submission may be incomplete for preservation. The preserved package may contain metadata and technical context the producer never supplied. The access package may contain only the subset and format appropriate to the user.
2. The AIP Is a Logical Package, Not Necessarily One ZIP File
“Package” can sound like one physical container. OAIS is more abstract.
An AIP is an information model. Its components can be stored across databases, object stores and metadata systems as long as the repository preserves the relationships needed to reconstruct the package reliably.
A ZIP, BagIt bag or repository-specific container can implement part of the packaging, but the standard concept is larger than any one file format.
3. Content Information Is More Than the Raw Data Object
OAIS distinguishes the Data Object from the Representation Information needed to understand it.
Together, they form Content Information: the thing the archive has committed to preserve as meaningful information rather than uninterpreted bits.
For a CSV dataset, the bytes are not enough. The content may also require a schema, units, codebook and other Representation Information. The previous How Representation Information Works article owns that layer.
4. Preservation Description Information Explains Why the Content Can Be Trusted and Managed
The AIP also carries Preservation Description Information, or PDI.
Conceptually, PDI includes information supporting provenance, context, reference, fixity and access-rights understanding. These categories help the archive answer:
- Where did this come from?
- How does it relate to other information?
- How is it identified?
- Has it changed unexpectedly?
- Which access constraints apply?
That is why an AIP is much stronger than “the file plus a title.”
5. Packaging Information Binds the Components
The archive also needs a way to delimit or bind the Content Information and PDI as one package.
Packaging Information provides that relationship. A Package Description helps discovery and identification of the package.
The distinction matters because information can be stored separately while remaining one preserved archival unit through explicit relationships.
6. Ingest Is Where a SIP Becomes Preservation-Ready
A producer may submit files, metadata and a transfer manifest. The archive verifies receipt, checks completeness, validates files, calculates fixity, identifies formats, adds repository identifiers and captures rights or provenance information.
The archive may also normalise structure or create additional preservation metadata.
Only after those controls can the repository say that it has a preservation package it knows how to manage.
7. AIP Identity Must Survive Internal Reorganisation
Storage paths can change. database tables can be migrated. object stores can be replaced. AIP identity should not disappear because the internal implementation changes.
This is where persistent identifiers, package manifests and preservation metadata work together.
See How Persistent Identifiers Work.
8. One Intellectual Work Can Have Several AIPs
A dataset can have several preserved versions. A website can be captured repeatedly. A software object can have platform-specific packages. A publication can receive corrected editions.
The archive therefore needs to distinguish work identity, version identity and package identity.
Without those distinctions, version history can collapse into one mutable object whose past states become unrecoverable.
9. AIPs Can Be Updated Through Controlled Preservation Action
Preservation does not mean the package can never change.
A format migration can create a new representation. metadata can be corrected. new Representation Information can be added. fixity events accumulate.
The key is controlled succession: preserve what changed, why it changed, which prior state existed and which new state is now authoritative for preservation.
10. A DIP Is Built for the Consumer, Not Necessarily the Archive
The archive may preserve a large, complex AIP while delivering a much simpler DIP.
A researcher might receive a selection of files plus user-facing metadata. A public visitor might receive a JPEG derived from a TIFF master. A machine client might receive structured JSON.
Access should not force the preservation package itself to become the public interface.
11. Package Validation Tests Relationships, Not Only Files
Every file can be individually valid while the package is broken.
A manifest can point to the wrong component. metadata can refer to the wrong version. a derivative can lose its link to the source. a rights record can be missing.
AIP validation therefore asks whether the package relationships still reconstruct the intended archival object.
12. Worked Example: Research Dataset
A university receives a research project containing CSV data, Python code, questionnaires, a data dictionary and a README.
The AIP can preserve the data files, code and documentation as Content Information, together with fixity, provenance, rights, ingest events, identifiers and package relationships. The future researcher can reconstruct not only the numbers, but the context that made the numbers meaningful.
13. Worked Example: Digitised Photograph
A museum creates a TIFF preservation master from a physical photograph and a smaller JPEG for access.
The preserved package can bind the master image to capture metadata, source-object identifier, colour information, checksum, rights, digitisation event and later derivatives. The public DIP may contain only the JPEG and descriptive metadata.
14. Worked Example: Website Archive
A web archive capture contains many network responses and timestamps.
The AIP needs to preserve enough capture and packaging context that those responses can be understood as one archival event rather than thousands of unrelated files.
15. Worked Example: eduKate Wintour Edition
A preserved eduKate publication edition could include article export, metadata, source ledger, canonical-owner record, internal-link map, publication date, fixity manifest and correction state.
The live WordPress page remains the web manifestation. The archival package preserves the edition as a reconstructable knowledge object.
16. Failure Mode: The Package Is a Bag of Files
If component relationships, versions and provenance are absent, future users may be unable to tell which files belong together or which one is authoritative.
Physical co-location is not enough. The semantic package must be explicit.
17. Failure Mode: The Package Depends on One Repository Database
If the preservation relationships exist only in undocumented application tables, platform replacement can destroy package meaning while leaving all stored files intact.
18. An AIP Checklist
- Define what information object the archive is preserving.
- Separate producer submission from preservation package.
- Bind Data Objects to necessary Representation Information.
- Preserve provenance, context, reference, fixity and access-rights information.
- Maintain explicit packaging relationships.
- Assign stable package identity.
- Version changes and preservation actions.
- Validate package-level relationships, not only individual files.
- Generate consumer-facing DIPs without weakening the preservation package.
- Ensure the AIP can survive migration away from the current repository platform.
19. Read the Mechanism Forward, Backward and Sideways
Forward: producer submission → ingest controls → Content Information + PDI → archival package → preservation actions → dissemination package. Backward: start from an access copy and trace it back to the preserved package and source evidence. Sideways: compare producer, archivist, repository engineer and consumer. Each sees a different package role while depending on continuity between them.
20. The Civilisation Lesson
Long-term memory fails when content becomes detached from context. Archival information packages are one architecture for preventing that separation.
An archival package is not a container around a file. It is the maintained relationship between content, meaning, provenance, integrity and custody that lets the file remain a usable record across time.
Continue through How Preservation Metadata Works, How Representation Information Works and the How X Works hub. Next: file format migration — how a repository changes representation while proving that the significant properties required by the preservation contract survived.