Skip to main content
Category: Digital Preservation

Dissemination Information Package

Also known as:
Simply put

A Dissemination Information Package (DIP) is the package of content that a user or consumer receives when they request material from a digital archive. It is prepared by the archive from its stored preservation copies and delivered in a form suitable for the user to access and use. In other words, it is the version of archived content packaged for delivery rather than for long-term storage.

Formal definition

Within the OAIS reference model, a Dissemination Information Package (DIP) is the Information Package delivered to the Consumer in response to a request or order for content. It is typically derived from part or all of one or more Archival Information Packages (AIPs), with the relevant data and documentation prepared, formatted, and packaged so that it is ready to be processed by the Consumer's designated Access Software. The DIP should be distinguished from the AIP, which is oriented toward long-term preservation, and from the Submission Information Package (SIP), which is the form in which content is transferred into the archive; the DIP need not be identical in structure or completeness to the AIP from which it is derived, as it is scoped to the access request. This description reflects the OAIS model as represented in the cited evidence and does not cover jurisdiction-specific or repository-specific implementation details beyond that general framework.

Why it matters

The Dissemination Information Package matters because it represents the point at which a digital archive fulfills its purpose: delivering usable content to those who request it. Preservation for its own sake has limited value; the DIP is the mechanism by which preserved material is made accessible and processable by a consumer. Distinguishing the DIP from the Archival Information Package (AIP) it is derived from helps clarify that the copy optimized for long-term preservation is often not the copy best suited for immediate use, and that an archive typically prepares, formats, and packages content specifically for the access request at hand.

Within the OAIS reference model, keeping the DIP conceptually separate from the AIP and the Submission Information Package (SIP) supports clearer thinking about an archive's responsibilities. The DIP need not be identical in structure or completeness to the AIP from which it is derived, since it is scoped to what the consumer has requested and to what the consumer's designated Access Software can process. Recognizing this separation helps organizations avoid conflating storage decisions with delivery decisions, each of which is governed by different requirements.

Because the DIP is derived from preserved copies rather than delivered as the preservation copy itself, its integrity and fidelity depend on the soundness of the underlying AIPs and on the transformation process used to prepare it. Depending on repository policy and the nature of the request, a DIP may present content in a different format than that held in storage, which has implications for how faithfully the delivered content reflects the archived original. The evidence cited here describes the general OAIS framework and does not address jurisdiction-specific or repository-specific implementation details.

Who it's relevant to

Digital preservation specialists
Those responsible for OAIS-aligned repositories work directly with the relationships among SIPs, AIPs, and DIPs. Understanding how a DIP is derived from one or more AIPs and prepared for delivery is central to designing access workflows that serve consumers without compromising preservation copies.
Archivists and repository managers
Archivists managing access to digital holdings need to plan how stored material is transformed into packages that users can retrieve and use. This includes deciding how to prepare data and documentation so that delivered content is ready to be processed by the consumer's designated Access Software.
Records managers overseeing digital archives
Records professionals whose remit extends into long-term digital preservation benefit from the distinction between content held for preservation and content packaged for delivery. Recognizing that a DIP may differ in structure or completeness from its source AIP supports clearer decisions about what is retained versus what is disseminated on request.
System designers and implementers
Those building or configuring repository and access systems need to account for how DIPs are generated on demand and formatted for the access software their consumers use. The DIP concept helps frame the requirements for the access-facing side of a preservation system as distinct from ingest and storage functions.

Inside DIP

Content Information
The core digital object or content being disseminated to a consumer, assembled in a form suitable for delivery in response to a request. In the OAIS reference model, a DIP is the package derived from one or more Archival Information Packages (AIPs) to satisfy a specific access request.
Representation Information (as needed)
Information that enables the consumer to interpret and render the content, though a DIP may include only a subset of what is held in the corresponding AIP, depending on the request and the delivery context.
Packaging tailored to the consumer
The DIP is structured for delivery and use by the requester rather than for long-term preservation. Its composition and completeness typically depend on the nature of the access request and organizational policy, and it need not reproduce the full AIP.
Relationship to other OAIS packages
The DIP is one of three information package types described in the OAIS reference model, alongside the Submission Information Package (SIP) used at ingest and the Archival Information Package (AIP) used for preservation. The DIP is generated for the dissemination or access stage.

Common questions

Answers to the questions practitioners most commonly ask about DIP.

Is a Dissemination Information Package the same as the Archival Information Package (AIP) held in the repository?
No. In the OAIS reference model, the AIP is the package that a repository preserves over the long term, whereas the DIP is the package produced and delivered to a consumer in response to a request. A DIP is typically derived from one or more AIPs, but it is not identical to them. The DIP may contain only a subset of the AIP's content, may present the content in a different form suited to the requester, and need not carry the full preservation-oriented metadata that the AIP retains. Treating the two as interchangeable can obscure the distinction between what is preserved and what is delivered.
Does generating a DIP mean the underlying record has been disposed of or removed from the repository?
No. Producing a DIP is an act of dissemination, not disposition. The repository continues to hold the relevant AIP after a DIP has been generated and delivered. Dissemination and disposition are distinct concepts: dissemination concerns providing access to or delivery of content to a consumer, while disposition concerns the eventual fate of the preserved material, which may include transfer, permanent retention, or destruction depending on organizational policy and applicable requirements. A DIP is generally a derived, delivered form rather than a change to the retained record.
How much of the content and metadata from the AIP should a DIP include?
The appropriate content depends on the purpose of the dissemination and the needs of the consumer, and organizations typically define this through policy. A DIP often includes the content that answers the request together with sufficient descriptive and contextual information for the consumer to understand and use it. Depending on the situation, it may include or exclude certain preservation metadata, provenance details, or technical metadata that are essential within the repository but not required by the requester. Decisions may also be shaped by access controls, privacy obligations, and confidentiality considerations, which vary by jurisdiction and sector.
Should a DIP preserve information that supports the authenticity and integrity of the delivered content?
In many cases it is advisable to include information that allows the consumer to assess the authenticity, reliability, integrity, and usability of the delivered content, such as relevant provenance or contextual metadata. The extent to which this is necessary often depends on how the recipient intends to rely on the material, for example, whether it may be used as evidence. Because a DIP is typically a derived form rather than the authoritative preserved record, organizations should consider, according to their own policies and any applicable requirements, what accompanying information the consumer needs to trust and interpret what they receive.
In what formats should a DIP be produced?
The format of a DIP is generally determined by the needs and capabilities of the intended consumer and by organizational policy, rather than by a single prescribed standard. A DIP may present content in a form more convenient for the requester than the format in which it is preserved, which is one of the reasons it is distinguished from the preserved package. Where format transformation occurs, organizations often consider whether the transformation affects the usability or integrity of the content and whether any accompanying information is needed to explain how the delivered form relates to what is preserved.
How do access controls and privacy obligations affect what is included in a DIP?
Because a DIP is delivered to a consumer, its contents are frequently shaped by access controls, confidentiality requirements, and privacy obligations, which differ across jurisdictions and sectors. In practice this may mean that certain material within an AIP is redacted, withheld, or otherwise limited before dissemination, according to applicable rules and organizational policy. Determining what may be released often involves assessing the requester's entitlements and any legal or regulatory constraints, so the composition of a DIP is not solely a technical matter but also a governance and compliance one.

Common misconceptions

A DIP is the same as the AIP and simply a copy of what is preserved.
A DIP is typically derived from one or more AIPs but is assembled for access and delivery. It may contain only a subset of the AIP's content or representation information, and its form is shaped by the consumer's request rather than by preservation requirements.
Producing a DIP is part of the preservation or retention function.
Within the OAIS framing, the DIP belongs to the access or dissemination stage rather than to preservation. It should be distinguished from the AIP, which supports long-term retention, and from the SIP, which is used at ingest.
A DIP is necessarily the authoritative record itself.
A DIP is a package delivered to satisfy a request and may function as a copy provided for use. Whether the delivered content carries the properties expected of an authoritative record depends on how it is generated and on organizational policy; a disseminated copy is not automatically equivalent to the preserved authoritative version.

Best practices

Generate each DIP in response to a defined access request, and structure its content and packaging to suit the consumer and delivery context rather than defaulting to a full copy of the AIP.
Maintain a clear separation between the DIP, the AIP, and the SIP, ensuring staff understand that the DIP serves dissemination while the AIP serves preservation and the SIP serves ingest.
Document which elements of the corresponding AIP, including any representation information, are included in or omitted from a given DIP, so the scope of what is delivered is transparent.
Where the disseminated content is a copy rather than the authoritative record, make this distinction clear to the requester, in line with organizational policy.
Align DIP generation with any applicable access, privacy, and disclosure obligations, recognizing that these requirements vary by jurisdiction and sector.
Retain traceability between a DIP and the AIP or AIPs from which it was derived, so that disseminated outputs can be related back to the preserved source.