Category: Digital Preservation

Submission Information Package

Also known as:

Simply put

A Submission Information Package (SIP) is the bundle of digital content and accompanying information that a content provider hands over to a digital repository so it can be taken in and preserved. It contains the material to be stored along with the information needed for the repository to process it. The exact form and contents of a SIP are typically agreed between the provider and the repository beforehand.

Formal definition

Within the OAIS reference model, a Submission Information Package (SIP) is an Information Package delivered by a Producer to an OAIS-compliant repository for ingest, where it is used in the construction or update of one or more Archival Information Packages (AIPs). Its form and detailed content are typically negotiated between the Producer and the repository rather than fixed universally. The SIP is distinct from the AIP, which is the package as stored and preserved, and from the Dissemination Information Package (DIP), which is provided to consumers; it may be generated programmatically through pre-ingest tooling depending on the repository's workflow.

Why it matters

The Submission Information Package sits at the boundary between a content provider and a digital repository, and it is at this boundary that many preservation problems either get resolved or get baked in. Because the SIP is the vehicle by which material enters a repository, the completeness and correctness of what it carries directly affects whether the repository can process, understand, and preserve the content over the long term. If the accompanying information needed for ingest is missing or malformed, the repository may be unable to construct a sound archival record from the submission.

A defining characteristic of the SIP is that its form and detailed content are typically negotiated between the Producer and the repository rather than dictated by a universal template. This negotiation matters because it lets both parties agree in advance on what must be delivered and in what structure, reducing the risk of ambiguous or incomplete transfers. Where such agreement is absent or poorly documented, submissions can arrive in inconsistent forms that complicate ingest and undermine the reliability of the resulting archival holdings.

The SIP also matters conceptually because it is distinct from the package as stored and from the package delivered to consumers. Treating the submitted bundle as if it were already the preserved record can obscure the transformations and validation that occur during ingest. Keeping the SIP separate from the AIP and DIP within the OAIS model helps organizations reason clearly about where responsibility passes from provider to repository and about what processing happens at each stage.

Who it's relevant to

Digital preservation practitioners

Those responsible for ingest workflows rely on the SIP concept to define what a Producer must deliver and how the repository will process it into one or more AIPs. Clear expectations for SIP form and content help ensure submissions can be validated and preserved reliably.

Content providers and depositors

Organizations or individuals handing material over to a repository act as Producers in OAIS terms, and they are responsible for delivering a SIP that meets the terms negotiated with the repository. Understanding what the SIP must contain helps them prepare compliant submissions.

Repository and system designers

Those building or configuring OAIS-compliant repositories need to design ingest processes and, where appropriate, pre-ingest tooling that can accept SIPs and use them to construct or update AIPs. This includes accommodating SIPs that may be generated programmatically.

Records and information governance professionals

Practitioners overseeing the transfer of records into preservation systems benefit from understanding the SIP as the point at which responsibility passes from provider to repository, and how it differs from the stored AIP and the consumer-facing DIP.

Inside SIP

Content data object

The digital or digitized information that is the target of preservation, submitted by the producer for ingest into a repository or archival system. This is the payload that the SIP is built to convey.

Preservation Description Information (PDI)

Metadata that supports the long-term preservation of the content, typically encompassing information relating to provenance, context, fixity, and identification. The specific composition of PDI often depends on the preservation model and organizational policy in use.

Packaging Information

The structure or wrapper that binds the content data object and its associated metadata together so they can be transferred as a coherent unit during submission. This is what allows the SIP to be handled as a single logical package on ingest.

Descriptive metadata

Information that aids discovery, identification, and interpretation of the submitted material. Depending on organizational policy, this may be supplied by the producer or generated during ingest.

Submission agreement context

The terms, expectations, and responsibilities agreed between the producer and the receiving repository that govern what the SIP should contain and how it is to be transferred. The precise requirements typically vary by repository and by sector.

Common questions

Answers to the questions practitioners most commonly ask about SIP.

Is a Submission Information Package the same as the archived record itself?

No. A SIP is the package of content and associated information as submitted to a repository for ingest; it is not the form in which content is ultimately preserved or made available. In OAIS terms, a SIP is typically transformed during ingest into an Archival Information Package (AIP), which is the version managed for long-term preservation. The SIP represents the transfer or submission stage, and its structure may differ from the AIP because the repository often reorganizes, supplements, or validates the content before archival storage. Treating the SIP as the definitive archived record conflates the point of submission with the point of preservation.

Does the SIP have to contain complete and final preservation metadata?

Not necessarily. A SIP is defined by what the producer submits, which may be incomplete relative to what the repository ultimately requires. Depending on the submission agreement and the repository's ingest processes, some descriptive, structural, or preservation metadata may be generated, enriched, or validated by the repository during ingest rather than supplied in the SIP. The expectation of completeness depends on organizational policy and the agreement between producer and repository, so a SIP should not be assumed to carry fully finalized metadata by default.

What should be agreed between the producer and the repository before SIPs are submitted?

In many implementations, the producer and repository establish a submission agreement that defines the expected structure, formats, and accompanying information for SIPs. This typically covers matters such as acceptable file formats, required metadata, packaging conventions, validation criteria, and how errors or rejected submissions are handled. The specifics depend on organizational policy, the nature of the content, and any applicable retention or preservation requirements, so the arrangement is best documented rather than assumed.

How is a SIP typically validated during ingest?

Validation during ingest often involves checking that the SIP conforms to the agreed structure and that its contents are as expected. This can include verifying packaging conventions, confirming that required metadata is present, checking file formats against what the repository accepts, and confirming integrity, for example through fixity or checksum checks where these are used. The exact validation steps depend on the repository's ingest processes and the terms of the submission agreement, and outcomes may include acceptance, requests for correction, or rejection.

What happens to a SIP after it has been ingested?

After ingest, the content of a SIP is typically transformed into an Archival Information Package for long-term management, with the repository potentially reorganizing content and supplementing or validating associated information as part of that process. Whether the original SIP is retained after ingest, and for how long, depends on organizational policy and the repository's procedures; some repositories keep submitted packages as evidence of what was transferred, while others do not. This should be addressed explicitly rather than assumed.

How should errors or rejected SIPs be handled?

Handling of errors and rejected submissions is generally defined in advance, often within the submission agreement or the repository's ingest procedures. Depending on those arrangements, a SIP that fails validation may be returned to the producer for correction and resubmission, quarantined pending review, or rejected outright. Clear documentation of these outcomes, along with records of what was submitted, validated, and accepted, supports accountability and helps preserve evidence of the submission process itself.

Common misconceptions

A Submission Information Package is the same thing as the package that is preserved and stored over the long term.

The SIP is the form in which material is submitted for ingest, and it is typically distinct from the package retained for preservation and the package delivered to users. A repository often transforms or restructures a SIP during ingest into a separate preservation-oriented package, so the two should not be conflated.

A SIP is simply a copy of files handed over to an archive.

A SIP is a structured combination of the content together with associated metadata and packaging information, not merely a set of files. The metadata and packaging that accompany the content are what distinguish a submission package from a loose transfer of data, and they support the material's authenticity, integrity, and usability over time.

The exact contents of a SIP are fixed and standardized across all repositories.

What a SIP must contain often depends on the submission agreement, the preservation model in use, and organizational or sector-specific policy. Requirements vary between repositories, so there is generally no single universal specification for its composition.

Best practices

Establish a clear submission agreement with producers that specifies the required content, metadata, and packaging structure before material is transferred, since these requirements typically vary by repository and sector.

Capture fixity and identification information at submission so that the integrity of the content data object can be verified on receipt and monitored thereafter.

Include or generate the descriptive and preservation-related metadata needed to support later authenticity, context, and usability, rather than treating the SIP as a bare transfer of files.

Validate incoming SIPs against the agreed structure and completeness criteria at ingest, and document any discrepancies or transformations applied.

Distinguish clearly in workflow and documentation between the submission package, the package retained for preservation, and any package delivered to users, so that changes made during ingest are transparent and traceable.

Maintain a record of provenance and the submission context for each SIP to support accountability and defensible management of the material across its lifecycle.