A file can survive for decades and still lose the evidence that explains what it is, where it came from, what happened to it and whether anyone is allowed to use it.
Digital preservation therefore has to preserve more than content. It has to preserve the history of custody and intervention that makes the content intelligible and trustworthy.
Preservation metadata is the structured information a repository needs to manage digital materials over time: identifiers, technical characteristics, fixity, preservation events, agents, rights, relationships, provenance and other evidence needed to maintain usability and accountability.
This article sits beneath How Metadata Works, How Archives Work and How Digital Fixity Works. Metadata owns description broadly. Archives own custody and provenance. Fixity owns bit-level continuity. Preservation metadata connects those pieces into one maintainable evidence record.
1. Descriptive Metadata Helps You Find the Object; Preservation Metadata Helps You Keep It
Title, creator, subject and date are valuable descriptive fields. They help discovery.
Preservation needs additional questions answered: What file format is this? What checksum was recorded? Which software created or transformed it? Has it been migrated? Who authorised that action? Which rights allow preservation copying? What previous version did it derive from? Which representation belongs to the same intellectual object?
That is a different metadata job. It turns preservation from a sequence of undocumented interventions into an auditable chain.
2. PREMIS Is the Major International Preservation-Metadata Standard
The PREMIS Preservation Metadata Maintenance Activity, maintained by the Library of Congress, provides an international data dictionary for supporting long-term usability of digital objects.
PREMIS Version 3 organises its data model around four core entities: Objects, Events, Agents and Rights. Those four nouns form a powerful preservation sentence:
What object was affected, what happened, who or what performed the action, and under what rights or permissions?
3. Objects Carry Technical and Identity State
A preservation Object may be represented at several levels, including files and bitstreams. Metadata can record identifiers, format information, size, fixity, significant properties, relationships and storage-related state.
That matters because one “digital item” can contain many component files: a website, software package, audiovisual work, database export or compound document. Preservation metadata needs to know which parts belong together and which level each fact describes.
4. Events Turn Preservation Into a Timeline
A preservation event is something that happened to or was checked against an object.
- ingest;
- fixity check;
- virus scan;
- format identification;
- migration;
- normalisation;
- replication;
- validation;
- restoration;
- deletion under authorised policy.
Recording event date, outcome, detail and linked agent allows the repository to reconstruct the object’s preservation history rather than merely observe its current state.
5. Agents Make Responsibility Visible
An Agent can be a person, organisation or software process.
If a migration was performed by a particular tool version, that tool matters. If a curator approved a preservation action, that decision matters. If an external provider supplied a checksum, the source of that assertion matters.
Preservation evidence becomes stronger when actions can be connected to accountable agents instead of appearing as unexplained state changes.
6. Rights Determine Which Preservation Actions Are Lawful
Digital preservation often requires copying, migration, format conversion, emulation and controlled access.
The repository therefore needs to know what rights, licences, donor agreements, statutory permissions or policy constraints apply. A technically possible preservation action can still be legally or contractually restricted.
Rights metadata turns permission from institutional memory into structured state.
7. Relationships Preserve Version and Derivation History
A migrated PDF may derive from an older word-processing file. A preservation master may generate an access copy. An updated dataset may supersede an earlier release.
If those relationships disappear, future users can mistake derivative files for originals or lose the route back to the preserved source.
The relationship graph should answer: what came from what, and why?
8. Preservation Metadata Is Evidence About Preservation, Not Decoration Around It
It is easy to collect fields because a standard says they exist. The better question is whether the metadata supports a future preservation decision.
Can the repository prove which version was deposited? Can it tell whether a file changed unexpectedly? Can it explain why a migration occurred? Can it reproduce the action? Can it show which rights allowed the action? Can it identify the object after a storage migration?
If the metadata cannot support those questions, the preservation record may be formally populated and operationally weak.
9. Metadata Must Survive the Same Time Horizon as the Object
Preservation metadata stored only inside one vendor database can become a new point of failure.
Repositories need exportable, documented and maintainable representations of preservation state so platform migration does not erase the evidence accumulated by the old platform.
This connects directly to How Metadata Works | Schema Evolution.
10. Preservation Metadata Can Be Generated Automatically — But Not Entirely
Software can identify file formats, calculate checksums, record event timestamps and capture tool versions automatically.
Human judgement is still needed for significance, rights, collection policy, authenticity claims, unusual transformations and whether a preservation action was successful in the ways that matter.
Automation is strongest where the event is machine-observable. Governance remains necessary where meaning and institutional responsibility enter.
11. Preservation Metadata Should Distinguish Assertion From Observation
“File format identified as PDF/A” can be an automated tool result. “This is the authoritative final version” may be a curator or producer assertion. “Migration preserved layout acceptably” may be a validation judgment.
Those claims should not be flattened into identical metadata fields. Provenance of the assertion matters.
12. Worked Example: Migrating an Obsolete Document
A repository holds a word-processing file whose original software is becoming difficult to run.
The preservation record can capture the original object identifier and checksum, source format, migration tool and version, event date, target format, validation outcome, responsible agent, significant properties tested and relationship between original and derivative.
Years later, another archivist can understand not merely that two files exist, but why both exist and which role each one plays.
13. Worked Example: A Digital Photograph
A TIFF preservation master is ingested with embedded technical metadata. The repository records checksum, size, format identification, colour profile, ingest event and acquisition rights.
An access JPEG is later generated. The relationship metadata says the JPEG is derived from the TIFF for access. The repository does not let the convenient access copy silently become the preservation source.
14. Worked Example: A Website Capture
A web archive is not one file in the everyday sense. It can contain many responses, timestamps, headers and dependencies.
Preservation metadata needs to represent capture context and package relationships so the future repository can distinguish the archived representation from the live site that once produced it.
15. Worked Example: eduKate Publication Editions
Wintour House treats a published work as more than a mutable WordPress page. A stable edition relationship can record title, canonical URL, publication date, source packet, correction state and later re-editions.
Preservation metadata extends that logic into long-term custody: which export represents which edition, what was verified at deposit, and what transformations occurred afterward.
16. Failure Mode: Metadata Without Events
A repository can know the current format and checksum while knowing nothing about how that state was reached.
That is a snapshot without a history. Preservation needs both current state and transition record.
17. Failure Mode: Events Without Outcome
“Migration ran” is weaker than “migration ran, produced these files, passed these checks, failed these checks, and was approved under this policy.”
Preservation events should capture enough outcome state to support future trust and diagnosis.
18. A Preservation-Metadata Checklist
- Assign stable identifiers to preserved objects.
- Record technical characteristics and format information.
- Record fixity and validation evidence.
- Capture preservation events with date, detail and outcome.
- Identify the agents responsible for important actions.
- Record rights that permit or constrain preservation and access.
- Preserve derivation, version and component relationships.
- Distinguish machine observation from human assertion.
- Keep metadata exportable beyond one software platform.
- Version metadata schemas and preserve their interpretation.
19. Read the Mechanism Forward, Backward and Sideways
Forward: object → ingest → preservation events → agents and rights → changing technical state → future access. Backward: start from a questionable object and reconstruct every important preservation intervention. Sideways: compare archivist, systems engineer, rights owner and future researcher. Each needs a different part of the same preservation record.
20. The Civilisation Lesson
Digital memory does not survive through files alone. It survives through files plus the evidence required to interpret the files and trust the interventions that kept them alive.
Preservation metadata is the memory of preservation itself: the record that lets tomorrow understand what today did to keep the object usable.
Continue through How Metadata Works, How Digital Fixity Works and the How X Works hub. Next: representation information — what future users need to know before preserved bits can become intelligible information again.