# Copyright and License

© 2026 InnoVadens, LLC. All rights reserved.

This specification is licensed under the Creative Commons Attribution–NoDerivatives 4.0 International License (CC BY‑ND 4.0).

You are free to copy and redistribute this document in any medium or format, provided that you:
- Attribute the work to InnoVadens, LLC, and
- Do not remix, transform, or build upon the material.

No modifications of this specification may be distributed. Implementations may reference this specification, but derivative specifications or altered versions may not be published under the ADAC name or imply ADAC endorsement.

A copy of the license is available at: https://creativecommons.org/licenses/by-nd/4.0/

# Status of This Document

This document defines the authoritative ADAC Specification for version 1.0.

InnoVadens, LLC is the steward of this specification. Only documents published at https://adac-standard.com/specs/ are considered official and normative.

This specification may be referenced by third‑party software, libraries, and services. However, no external party may publish modified versions of this specification or claim compatibility beyond what is explicitly defined in the normative text.

Normative requirements in this document use the keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY as defined in RFC 2119.

# Trademark Notice

“ADAC” and the ADAC logo are trademarks of InnoVadens, LLC.
Use of the ADAC name in derivative specifications, competing standards, or modified versions of this document is prohibited.

Software implementations may state that they “implement the ADAC Specification” provided such statements are accurate and not misleading.

# Revision History

Version 1.0.0 — Initial publication.

# ADAC-Preservation v1.0.0 — Archival Description Profile Specification

**Editor & Steward**  
John Vaden  
Genealogist and Technical Workflow Contributor  
InnoVadens, LLC — Cedar Lake, Michigan, USA  

**Contributors**  
AI-assisted drafting and refinement  
Community feedback (ongoing)  

**Status**  
This document is maintained by InnoVadens, LLC as the official steward of the ADAC Standard.

John Vaden has decades of experience in genealogical research and in contributing to standards, workflows, and data practices across analyst and software development teams. He serves as the editor and steward of the ADAC Standard. InnoVadens, LLC is the legal steward of ADAC.

**Version**: v1.0.0
**Status**: Stable
**Copyright**: © 2026 InnoVadens, LLC. All rights reserved.
**Date**: 2026
**Base Profile**: [ADAC 1.0 — Archival Digital Asset Container](../../ADAC/spec/ADAC-Format-Specification.md)

---

## Abstract

The **ADAC-Preservation** profile defines a domain-specific metadata extension for the [ADAC 1.0](../../ADAC/spec/ADAC-Format-Specification.md) container format, designed for archival institutions, libraries, museums, and digital preservation programs. The profile adds structured archival description following ISAD(G) and DACS conventions, accession and ingest records, archival arrangement hierarchy (fonds → series → file → item), preservation planning and risk assessment metadata aligned with PREMIS, digitization workflow records compliant with FADGI and Metamorfoze quality standards, donor and rights management metadata, deaccession and disposition records, and per-region annotations for stamps, seals, marginalia, and condition issues — all without modifying the core ADAC specification.

This profile addresses ADAC's founding use case: the long-term preservation, description, and management of digital surrogates and born-digital materials by professional archival institutions. It is designed for use alongside other ADAC profiles — a container holding a scanned 1870 census page might carry both this archival profile (describing its position in the collection, its preservation status, and its donor restrictions) and the ADAC-Genealogy profile (describing the people named on it and supporting genealogical research).

---

## Table of Contents

1. [Introduction](#1-introduction)
2. [Conformance](#2-conformance)
3. [Terminology](#3-terminology)
4. [Relationship to ADAC](#4-relationship-to-adac)
5. [Relationship to Other Standards](#5-relationship-to-other-standards)
6. [Container Format](#6-container-format)
7. [Archival Profile — `metadata/profiles/archival.json`](#7-archival-profile)
8. [Accession Record](#8-accession-record)
9. [Archival Description](#9-archival-description)
10. [Arrangement Hierarchy](#10-arrangement-hierarchy)
11. [Custodial History](#11-custodial-history)
12. [Preservation Metadata](#12-preservation-metadata)
13. [Digitization Workflow](#13-digitization-workflow)
14. [Rights and Access](#14-rights-and-access)
15. [Deaccession Record](#15-deaccession-record)
16. [Region Linked Entities](#16-region-linked-entities)
17. [Description Annotation — `archival:description`](#17-description-annotation)
18. [Condition Annotation — `archival:condition`](#18-condition-annotation)
19. [Marking Annotation — `archival:marking`](#19-marking-annotation)
20. [Well-Known Value Sets](#20-well-known-value-sets)
21. [JSON Conventions](#21-json-conventions)
22. [Interoperability](#22-interoperability)
23. [Complete Container Example](#23-complete-container-example)
24. [Validation](#24-validation)
25. [References](#25-references)
26. [Version History](#26-version-history)

---

## 1. Introduction

### 1.1 Problem Statement

Archival institutions — national archives, university special collections, historical societies, religious archives, corporate archives, museum archives, government records repositories — share a set of professional concerns that the jurisdiction-neutral ADAC core specification supports at the structural level but does not address at the descriptive level:

- **Archival arrangement.** Collections are organized according to the principle of provenance and original order, producing a hierarchical structure (fonds → series → sub-series → file → item) that needs to be expressed in the metadata. A digital surrogate is not just an isolated item; it has a position within an arrangement scheme, and that position carries meaning.
- **Archival description.** Professional archival description follows international and national standards — ISAD(G), DACS, RAD (Canada), MAD (UK) — that define a multi-level descriptive vocabulary far richer than Dublin Core. Scope and content notes, biographical histories of creators, administrative histories, processing notes, and finding aid references all need to be captured.
- **Custodial history and chain of ownership.** Archives care about who created the materials, who held them between creation and accession, and how they came to the holding repository. This is distinct from the chain of custody used in legal evidence — it spans years or centuries and may be reconstructed from circumstantial evidence.
- **Accessioning and processing.** When an archive receives materials, a formal accessioning process records the donor or transferring institution, the deed of gift or transfer agreement, the accession date, the appraisal decision, and the processing status. Processing itself (arrangement, description, rehousing) is a tracked activity with its own metadata requirements.
- **Preservation planning.** Long-term preservation requires ongoing assessment: format risk, file integrity, environmental conditions, migration history, preservation level. The PREMIS data dictionary defines the international standard vocabulary for this work.
- **Digitization workflow.** Digital surrogates are produced through controlled processes that capture detailed metadata: project identification, scanning parameters, color management, quality control, and conformance to imaging standards (FADGI Star ratings, Metamorfoze guidelines, ISO 19264).
- **Complex rights management.** Archival rights extend far beyond personal privacy. Donor agreements may impose specific restrictions, copyright status varies (public domain, in-copyright, orphan work), statutory obligations apply (data protection, freedom of information, classification levels), and reproduction rights may be separate from access rights.
- **Deaccession.** Archives occasionally remove materials from their collections — a careful, documented process with significant professional and ethical dimensions. The decision, the authority, and the disposition all need to be recorded permanently.

The genealogy and legal profiles each address one community of users. ADAC-Preservation addresses the institutions that hold the materials those communities use.

### 1.2 Solution

ADAC-Preservation solves this by embedding professional archival description and preservation management metadata directly into the archival container alongside the digital object:

- **Accession record** — donor or source, deed of gift reference, accession number, accession date, appraisal decision, processing status.
- **Archival description** — title, scope and content note, biographical or administrative history of the creator, dates of creation and accumulation, extent, language of materials, finding aid references.
- **Arrangement hierarchy** — explicit position within fonds → series → sub-series → file → item, with collection-level and series-level identifiers.
- **Custodial history** — chronological record of ownership and custody from creation through accession to the present.
- **Preservation metadata** — preservation level, format identification and risk assessment, fixity verification history, migration events, environmental requirements (PREMIS-aligned).
- **Digitization workflow** — capture device and operator, color management profile, quality conformance level (FADGI, Metamorfoze, ISO 19264), post-processing operations, quality control review.
- **Rights and access** — copyright status, donor restrictions, statutory restrictions, reproduction rights, access conditions, embargo periods.
- **Deaccession record** — authorization, reason, recipient or disposition method, supporting documentation.
- **Per-region annotations** — descriptive observations (stamps, seals, marginalia), condition issues, and physical markings that an archivist or conservator would record.

### 1.3 Design Philosophy

| Principle | Description |
|-----------|-------------|
| **ADAC-native** | A pure ADAC profile extension. No core specification modifications. Any ADAC reader can open an ADAC-Preservation container. |
| **Standards-aligned** | Field names and value sets align with established archival standards (PREMIS, ISAD(G), DACS, Dublin Core Terms) wherever possible to enable interoperability with existing archival management systems and aggregators. |
| **Multi-level description** | Supports the multi-level archival description model — a single container can carry collection-level, series-level, and item-level metadata simultaneously, reflecting where it sits in the arrangement hierarchy. |
| **Preservation-first** | Inherits ADAC's master immutability and signed archival conformance, then layers PREMIS-aligned preservation event tracking on top. |
| **Institutionally aware** | Every record can identify the holding institution, the responsible archivist, and the policy framework under which decisions were made. |
| **Interoperable with archival ecosystems** | Designed to round-trip with EAD finding aids, ArchivesSpace and AtoM collection management systems, IIIF image delivery, and OAI-PMH harvesting workflows. |
| **Multi-profile coexistence** | Designed to coexist with ADAC-Genealogy, ADAC-Legal, and other domain profiles in the same container. The archival profile manages the object as a holding; other profiles enrich it for their specific user communities. |
| **Forward-compatible** | All JSON structures tolerate unknown properties. Future profile versions can add fields without breaking existing readers. |

### 1.4 Scope

This specification defines the archival profile file schema (`metadata/profiles/archival.json`); accession record schema; archival description schema (ISAD(G) and DACS aligned); arrangement hierarchy schema; custodial history schema; preservation metadata schema (PREMIS aligned); digitization workflow schema (FADGI and Metamorfoze aligned); rights and access management schema; deaccession record schema; per-region linked entity schemas for description, condition, and marking annotations; well-known value sets for material types, preservation levels, format risk levels, restriction types, processing status, FADGI star ratings, and condition assessments; profile-specific validation rules; and guidance on integrating with EAD, ArchivesSpace, AtoM, IIIF, and OAI-PMH workflows.

This specification does **not** define the ADAC core container format (see [ADAC 1.0](../../ADAC/spec/ADAC-Format-Specification.md)); the EAD, ArchivesSpace, AtoM, IIIF, or OAI-PMH specifications themselves; institution-specific workflow rules or policies; or application-level APIs, user interfaces, or storage system integration mechanisms.

### 1.5 Audience

This specification is intended for software developers implementing archival features in ADAC readers and writers; archivists, librarians, and museum professionals evaluating ADAC for digital preservation programs; digital preservation professionals managing OAIS-compliant repositories; vendors developing collection management systems, digital asset management systems, and digitization workflow tools; and standards bodies evaluating ADAC for adoption alongside or in place of existing archival packaging formats.

---

## 2. Conformance

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119).

### 2.1 Profile Conformance

An ADAC container conforms to this profile specification when:

1. It is a valid ADAC 1.0 container at any conformance level (Minimal, Archival, or Signed Archival).
2. It contains a file at a path listed in the manifest's `metadata.profiles` array whose filename portion matches `archival.json` (case-insensitive).
3. That file is valid JSON containing at least the `profileId`, `profileType`, and `profileVersion` fields, with `profileType` equal to `"archival"` and `profileId` equal to `"urn:adac:profile:archival:v1"`.

Note on terminology: The word "Archival" is used in two distinct senses in the ADAC ecosystem. ADAC core defines an "Archival" conformance level (a container with hash-chained provenance and full checksums). This specification defines the "ADAC-Preservation" profile (a domain-specific metadata extension for archival institutions). They are independent concerns: an ADAC-Preservation container MAY be at any conformance level, though Archival or Signed Archival is RECOMMENDED.

### 2.2 Recommended Conformance for Institutional Use

For long-term preservation in professional archival settings, **Signed Archival** ADAC conformance is RECOMMENDED. This provides cryptographic chain of custody from ingest through every preservation event, hash-chained provenance for tamper-evident audit trails, and master file immutability verified by SHA-256 checksums against the recorded baseline.

Containers used for working access copies, derivatives intended for public delivery, or items still in pre-accessioning workflow MAY use Archival or Minimal conformance.

### 2.3 Forward Compatibility

Readers MUST tolerate unknown JSON properties in all archival profile structures. Unknown properties MUST be preserved during round-trip serialization. Writers that cannot preserve unknown fields MUST set the manifest's `roundTripFidelity` to `"degraded"` and append a `fidelityLoss` provenance event, in accordance with ADAC 1.0 Section 6.2.

---

## 3. Terminology

| Term | Definition |
|------|------------|
| **ADAC-Preservation Container** | An ADAC container that includes an archival profile at `metadata/profiles/archival.json`. Uses the standard `.adac` extension. |
| **Accession** | The formal process by which a repository takes legal and physical custody of materials, and the materials themselves. |
| **Archival Description** | Structured metadata describing the content, context, and structure of archival materials following established descriptive standards (ISAD(G), DACS, etc.). |
| **Fonds** | The whole of the records, regardless of form or medium, organically created or accumulated and used by a particular person, family, or organization in the course of that creator's activities and functions. The highest level of archival arrangement. |
| **Series** | Documents arranged in accordance with a filing system or maintained as a unit because they relate to a particular subject or function, result from the same activity, have a particular form, or because of some other relationship arising out of their creation, receipt, or use. |
| **Custodial History** | The chronological record of ownership and physical custody of materials from creation through accession. Distinct from chain of custody in the legal evidence sense. |
| **Preservation Level** | The tier of preservation commitment a repository has made to a digital object — bit-level preservation, full preservation with format migration, content preservation, or access copy only. |
| **PREMIS** | Preservation Metadata: Implementation Strategies — the international data dictionary for preservation metadata, maintained by the Library of Congress. |
| **ISAD(G)** | International Standard Archival Description (General) — the international standard for multi-level archival description, maintained by the International Council on Archives. |
| **DACS** | Describing Archives: A Content Standard — the US implementation of archival descriptive standards, maintained by the Society of American Archivists. |
| **EAD** | Encoded Archival Description — the XML standard for finding aids, maintained by the Library of Congress and the Society of American Archivists. |
| **FADGI** | Federal Agencies Digital Guidelines Initiative — US guidelines for digitization quality, defining four star levels for image quality. |
| **Metamorfoze** | Dutch national digitization quality guidelines, widely adopted in European preservation programs. |
| **Deed of Gift** | A legal document transferring ownership of materials from a donor to a repository, typically specifying any retained rights or restrictions. |
| **Finding Aid** | A document describing an archival collection, providing the contextual and structural information needed to use the materials. |
| **Deaccession** | The formal process of removing materials from a repository's collection, including disposition (return to donor, transfer to another repository, destruction). |
| **Surrogate** | A digital reproduction of an analog original, used in place of the original for access purposes. |
| **Born Digital** | Materials originally created in digital form, as distinguished from digital surrogates of analog originals. |
| **Holding Repository** | The institution that physically and legally holds the materials. |

---

## 4. Relationship to ADAC

### 4.1 Extension Mechanisms

ADAC-Preservation extends ADAC through three primary mechanisms defined by the ADAC 1.0 specification:

1. **Profile file** — A self-describing JSON file placed at `metadata/profiles/archival.json` and referenced in the manifest's `metadata.profiles` array. Non-archival readers ignore this file entirely.

2. **Linked entities** — Per-region JSON objects stored in the `linkedEntities` dictionary on each region, keyed by namespaced strings (`archival:description`, `archival:condition`, `archival:marking`). Non-archival readers preserve these values unchanged during round-trip serialization.

3. **Provenance events** — Archival applications SHOULD append events to ADAC's hash-chained provenance log when significant archival actions occur (accession, processing, preservation event, format migration, fixity check, deaccession). Recommended event types include `archivalAccession`, `archivalProcessing`, `archivalPreservationAction`, `archivalFixityCheck`, `archivalFormatMigration`, and `archivalDeaccession`. These appear in the same chronological hash chain as ADAC's built-in events and inherit the same tamper-evident properties.

### 4.2 Optional ADAC Features Used by This Profile

ADAC-Preservation makes substantial use of ADAC 1.0 optional features:

| ADAC Feature | Archival Use Case |
|--------------|-------------------|
| **`signatures/`** (CMS detached signatures) | Cryptographic chain of custody from accession through every preservation event. Each significant action (accession, processing complete, preservation migration, deaccession) SHOULD produce a new container signature. |
| **`accessControl`** (per-master, per-derivative, container-level) | Operational confidentiality and embargo information used by repository systems. The archival profile's `rights` records the legal basis; ADAC's `accessControl` records the operational classification. |
| **`EncryptionDescriptor`** | Storing restricted or sensitive content as ciphertext when the container is shared outside controlled environments (donor-restricted materials, classified content, personal data). |
| **Hash-chained provenance log** | Tamper-evident audit trail of all preservation actions, fixity checks, and format migrations. Critical for OAIS-compliant repositories where preservation history must be auditable. |
| **`structure.json`** (paged-document sequences) | Page ordering for multi-page items (correspondence with multiple pages, bound volumes, photograph series). Captures intellectual reading order distinct from physical arrangement. |
| **Master file immutability** | The single most important ADAC feature for archival use. Master files are immutable from ingest forward; checksum mismatches indicate corruption or unauthorized alteration. |

### 4.3 What This Profile Does NOT Modify

- The ADAC container format (ZIP structure)
- The manifest schema (`manifest.json`)
- The core metadata schema (`metadata/core.json`)
- The region annotation schema
- The edit pipeline schema
- The provenance log schema or hash-chain mechanism
- The checksum manifest schema or fixity computation
- The signature mechanism or signature index schema
- Any ADAC validation rules or error codes

---

## 5. Relationship to Other Standards

ADAC-Preservation is designed to coexist with and complement, rather than replace, established archival standards. This section documents the relationships.

### 5.1 OAIS (ISO 14721)

The Open Archival Information System reference model defines the conceptual framework for digital preservation systems. ADAC-Preservation aligns with OAIS as follows:

| OAIS Concept | ADAC-Preservation Mechanism |
|--------------|------------------------|
| Submission Information Package (SIP) | An ADAC container at ingest, before accessioning is complete |
| Archival Information Package (AIP) | A signed ADAC-Preservation container with completed accession record and full preservation metadata |
| Dissemination Information Package (DIP) | A derivative-focused ADAC container or a non-ADAC delivery format generated from the AIP |
| Content Information | Master files plus archival description |
| Preservation Description Information | The archival profile's preservation metadata, custodial history, and rights information |
| Provenance | Custodial history + ADAC hash-chained provenance log |
| Reference | Accession number, catalog identifiers, finding aid references |
| Fixity | ADAC checksums, preservation fixity check history |
| Context | Arrangement hierarchy, biographical/administrative history of creator |

### 5.2 PREMIS

The Preservation Metadata: Implementation Strategies data dictionary is the international standard for preservation metadata. ADAC-Preservation's preservation metadata schema (Section 12) is designed to express PREMIS concepts:

- PREMIS Object → ADAC master/derivative file
- PREMIS Event → ADAC provenance event (with `archival*` event types)
- PREMIS Agent → ADAC provenance event `actor` field + archival profile institution fields
- PREMIS Rights → ADAC-Preservation `rights` section
- PREMIS Environment → ADAC-Preservation `preservation.environment`

A future companion specification may define a strict PREMIS round-trip mapping for institutions that need formal PREMIS XML interchange.

### 5.3 ISAD(G) and DACS

The ADAC-Preservation `description` section uses field names aligned with ISAD(G) (the international standard) and DACS (the US implementation). The major ISAD(G) elements all have corresponding fields in the archival description schema (Section 9). DACS-specific extensions can be carried through descriptive notes fields or future jurisdiction-specific archival sub-profiles.

### 5.4 EAD

Encoded Archival Description is the XML standard for finding aids. EAD operates at the collection level, while ADAC-Preservation operates at the container (typically item or file) level. The two are complementary:

- EAD finding aids describe the whole collection and its arrangement.
- ADAC-Preservation containers describe individual items with reference back to the EAD finding aid.
- The `description.findingAidReference` field captures the link.

A repository can publish its finding aids in EAD and its individual digitized items as ADAC-Preservation containers, with each container's `arrangement` section identifying its position in the EAD-described hierarchy.

### 5.5 Dublin Core and Dublin Core Terms

ADAC core metadata aligns with Dublin Core. ADAC-Preservation extends this with archival-specific descriptive elements that have corresponding Dublin Core Terms (DCT) properties where applicable. Section 9 documents the alignment.

### 5.6 IIIF

The International Image Interoperability Framework is the standard for image delivery. IIIF Image API serves images; IIIF Presentation API describes how images are arranged into intellectual units (a book, a manuscript, a photograph series). ADAC-Preservation containers can be the source of truth for IIIF presentations:

- IIIF manifests can be generated from ADAC-Preservation container metadata.
- IIIF canvas labels can come from `archival:description` annotations.
- IIIF-served derivatives reference the master files held in the ADAC container.

### 5.7 OAI-PMH

The Open Archives Initiative Protocol for Metadata Harvesting allows repositories to share metadata with aggregators (DPLA, Europeana, Trove). ADAC-Preservation metadata can be exposed via OAI-PMH in Dublin Core, EAD, or other formats by mapping from the archival profile fields.

---

## 6. Container Format

### 6.1 File Extension

| Property | Value |
|----------|-------|
| **File extension** | `.adac` |
| **MIME type** | `application/vnd.adac.container` |

ADAC-Preservation containers use the standard `.adac` extension.

### 6.2 Directory Structure

```
<container>.adac
├── manifest.json                           (REQUIRED — ADAC)
├── master/                                 (REQUIRED — ADAC)
│   └── master_0001.tif
├── metadata/                               (REQUIRED — ADAC)
│   ├── core.json                           (REQUIRED — ADAC)
│   ├── structure.json                      (OPTIONAL — ADAC)
│   ├── xmp/                                (OPTIONAL — ADAC)
│   │   └── master_0001.xmp
│   └── profiles/                           (REQUIRED for this profile)
│       └── archival.json                   (REQUIRED for this profile)
├── derivatives/                            (RECOMMENDED for access copies)
│   ├── deriv_thumbnail_001.jpg
│   ├── deriv_preview_001.jpg
│   └── deriv_iiif_001.jp2
├── regions/                                (OPTIONAL)
│   └── master-001.regions.json
├── edits/                                  (OPTIONAL)
│   └── master-001.edits.json
├── provenance/                             (REQUIRED for Archival ADAC)
│   ├── log.json                            (hash-chained events)
│   └── checksums.json
└── signatures/                             (RECOMMENDED for institutional use)
    ├── index.json
    ├── container-accession.p7s
    └── container-processed.p7s
```

### 6.3 Manifest Integration

```json
{
  "metadata": {
    "core": "metadata/core.json",
    "profiles": [
      "metadata/profiles/archival.json"
    ],
    "provenanceLog": "provenance/log.json",
    "checksums": "provenance/checksums.json",
    "signatures": "signatures/index.json"
  }
}
```

A container MAY include multiple profiles. A scanned census page held by a national archive could carry both an archival profile and a genealogy profile:

```json
{
  "metadata": {
    "core": "metadata/core.json",
    "profiles": [
      "metadata/profiles/archival.json",
      "metadata/profiles/genealogy.json"
    ]
  }
}
```

---

## 7. Archival Profile

**Path**: `metadata/profiles/archival.json`
**Status**: REQUIRED for ADAC-Preservation containers

The archival profile is the root metadata file for this extension. It uses the standard ADAC 1.0 profile wrapper to declare its identity, then carries archival-specific content under the `data` field.

### 7.1 Schema

```json
{
  "profileId": "urn:adac:profile:archival:v1",
  "profileType": "archival",
  "profileVersion": "1.0.0",
  "title": "ADAC Archival Profile",
  "schema": "https://adac.example.org/schemas/archival-v1.json",
  "data": {
    "accession": { ... },
    "description": { ... },
    "arrangement": { ... },
    "custodialHistory": [ ... ],
    "preservation": { ... },
    "digitization": { ... },
    "rights": { ... },
    "deaccession": null
  }
}
```

### 7.2 Profile Wrapper Fields

| Field | Type | Required | Value | Description |
|-------|------|----------|-------|-------------|
| `profileId` | `string` | REQUIRED | `"urn:adac:profile:archival:v1"` | URN identifying this profile and version. |
| `profileType` | `string` | REQUIRED | `"archival"` | The profile type identifier. |
| `profileVersion` | `string` | REQUIRED | `"1.0.0"` for this spec | Semantic version. |
| `title` | `string` | OPTIONAL | — | Human-readable title for display. |
| `schema` | `string` | OPTIONAL | — | URI of a JSON Schema document validating the `data` subobject. |
| `data` | `ArchivalData` | OPTIONAL | — | The archival-specific payload. |

### 7.3 ArchivalData Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `accession` | `AccessionRecord` | OPTIONAL | The accession record for this item or collection (Section 8). |
| `description` | `ArchivalDescription` | OPTIONAL | ISAD(G)/DACS-aligned descriptive metadata (Section 9). |
| `arrangement` | `ArrangementHierarchy` | OPTIONAL | Position within the collection arrangement scheme (Section 10). |
| `custodialHistory` | `CustodyEvent[]` | OPTIONAL | Chronological custodial history from creation to accession (Section 11). |
| `preservation` | `PreservationMetadata` | OPTIONAL | PREMIS-aligned preservation planning and assessment (Section 12). |
| `digitization` | `DigitizationRecord` | OPTIONAL | Digitization workflow record (Section 13). |
| `rights` | `RightsInformation` | OPTIONAL | Rights and access management metadata (Section 14). |
| `deaccession` | `DeaccessionRecord` | OPTIONAL | Deaccession record if the item has been deaccessioned (Section 15). |

---

## 8. Accession Record

The accession record documents the formal process by which the holding repository took custody of the materials.

### 8.1 Schema

```json
{
  "accession": {
    "accessionNumber": "2026.042",
    "accessionDate": "2026-03-15T00:00:00Z",
    "holdingRepository": {
      "name": "Licking County Historical Society",
      "identifier": "OCLC:LCHS-OH",
      "address": "Newark, Ohio, United States"
    },
    "donor": {
      "name": "Estate of Mary E. Smith",
      "donorType": "estate",
      "address": "Newark, Ohio, United States"
    },
    "transferAgreement": {
      "agreementType": "deedOfGift",
      "agreementDate": "2026-02-20T00:00:00Z",
      "agreementReference": "Deed of Gift, file 2026-DOG-042",
      "termsSummary": "Unrestricted gift; donor retains no rights or restrictions."
    },
    "appraisalDecision": {
      "decision": "accepted",
      "appraisedBy": "J. Anderson, Head Archivist",
      "appraisalDate": "2026-02-15T00:00:00Z",
      "appraisalNotes": "Genealogically significant Smith family papers, 1850-1920. Includes original census transcripts and photographs."
    },
    "processingStatus": "fullyProcessed",
    "processingNotes": "Arranged at item level, described, and digitized. Finding aid published 2026-04-30."
  }
}
```

### 8.2 Accession Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `accessionNumber` | `string` | REQUIRED | The accession number assigned by the holding repository. Format is repository-specific. |
| `accessionDate` | `string` | OPTIONAL | ISO-8601 date the accession was formally completed. |
| `holdingRepository` | `Repository` | OPTIONAL | The institution that holds the materials. See Section 8.3. |
| `donor` | `Donor` | OPTIONAL | The donor or transferring entity. See Section 8.4. |
| `transferAgreement` | `TransferAgreement` | OPTIONAL | The legal instrument governing the transfer. See Section 8.5. |
| `appraisalDecision` | `AppraisalDecision` | OPTIONAL | The professional appraisal decision. See Section 8.6. |
| `processingStatus` | `string` | OPTIONAL | Current processing status. See Section 20.1 for well-known values. |
| `processingNotes` | `string` | OPTIONAL | Free-text processing notes. |

### 8.3 Repository

| Field | Type | Description |
|-------|------|-------------|
| `name` | `string` | The repository name. |
| `identifier` | `string` | A standardized identifier (OCLC symbol, MARC organization code, ISIL, ROR ID). Format: `<authority>:<value>`. |
| `address` | `string` | Free-text address. |

### 8.4 Donor

| Field | Type | Description |
|-------|------|-------------|
| `name` | `string` | The donor name (individual, family, organization, estate, or transferring institution). |
| `donorType` | `string` | Type of donor. Well-known values: `"individual"`, `"family"`, `"organization"`, `"estate"`, `"institution"`, `"government"`, `"unknown"`. |
| `address` | `string` | Free-text address (may be omitted for privacy). |

### 8.5 Transfer Agreement

| Field | Type | Description |
|-------|------|-------------|
| `agreementType` | `string` | Type of legal instrument. Well-known values: `"deedOfGift"`, `"purchaseAgreement"`, `"transferAgreement"`, `"loanAgreement"`, `"will"`, `"copyrightAssignment"`, `"none"` (for materials of unknown legal status). |
| `agreementDate` | `string` | ISO-8601 date of the agreement. |
| `agreementReference` | `string` | Repository reference to the physical or electronic agreement document. |
| `termsSummary` | `string` | Free-text summary of any restrictions, retained rights, or conditions. Detailed restrictions belong in the `rights` section. |

### 8.6 Appraisal Decision

| Field | Type | Description |
|-------|------|-------------|
| `decision` | `string` | The decision. Well-known values: `"accepted"`, `"acceptedConditional"`, `"declined"`, `"deferred"`. |
| `appraisedBy` | `string` | Name of the responsible archivist. |
| `appraisalDate` | `string` | ISO-8601 date of the appraisal. |
| `appraisalNotes` | `string` | Free-text appraisal rationale. |

---

## 9. Archival Description

The archival description provides ISAD(G)/DACS-aligned descriptive metadata. Field names use camelCase but the semantics align with the international standards.

### 9.1 Schema

```json
{
  "description": {
    "title": "Smith Family Papers, 1850-1920",
    "levelOfDescription": "fonds",
    "creator": {
      "name": "Smith, John, 1828-1901",
      "creatorType": "person",
      "biographicalHistory": "John Smith was a farmer in Newark, Licking County, Ohio. Born in Pennsylvania in 1828, he married Mary Jones in 1851 and farmed in Licking County until his death in 1901."
    },
    "datesOfCreation": {
      "startDate": "1850",
      "endDate": "1920",
      "datesNote": "Bulk dates 1865-1900"
    },
    "extent": {
      "physicalExtent": "3 boxes (1.5 linear feet)",
      "digitalExtent": "247 files (4.2 GB)"
    },
    "scopeAndContent": "Papers of the Smith family of Newark, Ohio, including correspondence, business records, photographs, and genealogical research materials. Particularly strong in documenting agricultural practices in central Ohio in the late 19th century.",
    "languageOfMaterials": ["en"],
    "physicalCharacteristics": "Some letters show fading ink; one photograph album has detached pages.",
    "findingAidReference": {
      "system": "ArchivesSpace",
      "identifier": "as:resource:42",
      "url": "https://archives.lchs.example.org/repositories/2/resources/42"
    },
    "relatedMaterials": [
      {
        "relationship": "complementary",
        "description": "John Smith Civil War service records, held by the National Archives, Record Group 94."
      }
    ]
  }
}
```

### 9.2 Description Fields

| Field | Type | ISAD(G) | DC Terms | Description |
|-------|------|---------|----------|-------------|
| `title` | `string` | 3.1.2 | dct:title | Title of the unit of description. |
| `levelOfDescription` | `string` | 3.1.4 | — | Level in the arrangement hierarchy (Section 20.2). |
| `creator` | `Creator` | 3.2.1 | dct:creator | The creator of the materials. See Section 9.3. |
| `datesOfCreation` | `Dates` | 3.1.3 | dct:created | Dates of creation and accumulation. See Section 9.4. |
| `extent` | `Extent` | 3.1.5 | dct:extent | Physical and digital extent. See Section 9.5. |
| `scopeAndContent` | `string` | 3.3.1 | dct:description | Scope and content note. |
| `languageOfMaterials` | `string[]` | 3.4.3 | dct:language | Languages of the content. IETF BCP 47 codes. |
| `physicalCharacteristics` | `string` | 3.4.1 | dct:format | Physical characteristics and technical requirements affecting use. |
| `findingAidReference` | `FindingAidReference` | 3.4.5 | dct:hasPart | Reference to a finding aid that describes this material. See Section 9.6. |
| `relatedMaterials` | `RelatedMaterial[]` | 3.5.3 | dct:related | Related materials held elsewhere. See Section 9.7. |

### 9.3 Creator

| Field | Type | Description |
|-------|------|-------------|
| `name` | `string` | The creator name in authority form (e.g., `"Smith, John, 1828-1901"`). |
| `creatorType` | `string` | Type. Well-known values: `"person"`, `"family"`, `"corporateBody"`, `"government"`, `"unknown"`. |
| `biographicalHistory` | `string` | Biographical sketch (for persons/families) or administrative history (for organizations). ISAD(G) 3.2.2. |
| `authorityRecordReference` | `string` | Optional reference to an authority record (e.g., LCNAF, VIAF, ULAN identifier). |

### 9.4 Dates

| Field | Type | Description |
|-------|------|-------------|
| `startDate` | `string` | ISO-8601 or partial date marking the beginning. Free text accepted for uncertain dates. |
| `endDate` | `string` | ISO-8601 or partial date marking the end. |
| `datesNote` | `string` | Free-text note (bulk dates, predominant dates, qualifying remarks). |

### 9.5 Extent

| Field | Type | Description |
|-------|------|-------------|
| `physicalExtent` | `string` | Physical extent of the original (e.g., `"3 boxes (1.5 linear feet)"`, `"1 photograph"`, `"42 pages"`). |
| `digitalExtent` | `string` | Digital extent of the surrogate or born-digital material (e.g., `"247 files (4.2 GB)"`). |

### 9.6 Finding Aid Reference

| Field | Type | Description |
|-------|------|-------------|
| `system` | `string` | The finding aid system. Well-known values: `"EAD"`, `"ArchivesSpace"`, `"AtoM"`, `"CollectiveAccess"`, `"ContentDM"`, `"local"`. |
| `identifier` | `string` | The finding aid identifier within the system. |
| `url` | `string` | Optional URL to the finding aid. |

### 9.7 Related Material

| Field | Type | Description |
|-------|------|-------------|
| `relationship` | `string` | Type of relationship. Well-known values: `"complementary"`, `"separated"`, `"derivedFrom"`, `"original"`, `"copyOf"`, `"continuationOf"`. |
| `description` | `string` | Free-text description of the related material and its location. |

---

## 10. Arrangement Hierarchy

The arrangement hierarchy expresses where this container's content sits within the larger archival arrangement. ISAD(G) defines a multi-level descriptive model with up to seven levels; ADAC-Preservation supports the most commonly used levels and allows custom levels for institutions that need them.

### 10.1 Schema

```json
{
  "arrangement": {
    "fondsIdentifier": "MS-1234",
    "fondsTitle": "Smith Family Papers",
    "seriesIdentifier": "MS-1234.3",
    "seriesTitle": "Photographs and Visual Materials",
    "fileIdentifier": "MS-1234.3.7",
    "fileTitle": "Family Photograph Album, ca. 1880",
    "itemIdentifier": "MS-1234.3.7.42",
    "itemTitle": "Photograph: Smith Family at Reunion, 1885",
    "physicalLocation": {
      "container": "Box 3",
      "folder": "Folder 7",
      "shelf": "Stack Range 4-A"
    },
    "originalOrder": "Maintained from donor arrangement.",
    "customLevels": null
  }
}
```

### 10.2 Arrangement Fields

The hierarchical identifiers SHOULD form a parent-prefix path (each child identifier extends the parent's). Repositories that use a different identifier scheme MAY use any consistent format.

| Field | Type | Description |
|-------|------|-------------|
| `fondsIdentifier` | `string` | Identifier of the fonds. |
| `fondsTitle` | `string` | Title of the fonds. |
| `seriesIdentifier` | `string` | Identifier of the series within the fonds. |
| `seriesTitle` | `string` | Title of the series. |
| `subSeriesIdentifier` | `string` | Identifier of the sub-series, if applicable. |
| `subSeriesTitle` | `string` | Title of the sub-series. |
| `fileIdentifier` | `string` | Identifier of the file (folder/group of items). |
| `fileTitle` | `string` | Title of the file. |
| `itemIdentifier` | `string` | Identifier of this specific item. |
| `itemTitle` | `string` | Title of this specific item. |
| `physicalLocation` | `PhysicalLocation` | Physical storage location. See Section 10.3. |
| `originalOrder` | `string` | Free-text note on whether original order was maintained. ISAD(G) 3.3.4. |
| `customLevels` | `CustomLevel[]` | Additional intermediate levels for repositories using non-standard hierarchies. |

### 10.3 Physical Location

| Field | Type | Description |
|-------|------|-------------|
| `container` | `string` | Box, drawer, or container reference. |
| `folder` | `string` | Folder or sub-container reference. |
| `shelf` | `string` | Shelf, stack range, or location identifier. |

### 10.4 Custom Levels

For repositories using more than the standard fonds/series/file/item hierarchy:

```json
{
  "customLevels": [
    { "levelName": "subFonds", "identifier": "MS-1234.A", "title": "Personal Papers", "parentLevel": "fonds" }
  ]
}
```

---

## 11. Custodial History

The custodial history records the chronological chain of ownership and physical custody from creation through accession to the present holding repository. This is distinct from the chain of custody used in legal evidence — it spans years or centuries, may be reconstructed from circumstantial evidence, and need not be cryptographically attested at every step.

### 11.1 Schema

```json
{
  "custodialHistory": [
    {
      "id": "custody-001",
      "custodian": "John Smith",
      "custodianType": "person",
      "startDate": "1850",
      "endDate": "1901",
      "evidenceBasis": "Created and held by John Smith during his lifetime per family records.",
      "notes": "Original creator and custodian."
    },
    {
      "id": "custody-002",
      "custodian": "Mary E. Smith (granddaughter)",
      "custodianType": "person",
      "startDate": "1901",
      "endDate": "2025",
      "evidenceBasis": "Inherited through three generations of the Smith family per family oral history and probate records.",
      "notes": "Materials kept in family attic in Newark, Ohio."
    },
    {
      "id": "custody-003",
      "custodian": "Estate of Mary E. Smith",
      "custodianType": "estate",
      "startDate": "2025-11-15",
      "endDate": "2026-03-15",
      "evidenceBasis": "Estate administration records.",
      "notes": "Materials held by estate executor pending donation."
    },
    {
      "id": "custody-004",
      "custodian": "Licking County Historical Society",
      "custodianType": "institution",
      "startDate": "2026-03-15",
      "endDate": null,
      "evidenceBasis": "Deed of Gift, file 2026-DOG-042.",
      "notes": "Current holding repository."
    }
  ]
}
```

### 11.2 Custody Event Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `id` | `string` | REQUIRED | Unique identifier within this container. |
| `custodian` | `string` | REQUIRED | The person, family, organization, or institution that held the materials. |
| `custodianType` | `string` | OPTIONAL | Type of custodian. Well-known values: `"person"`, `"family"`, `"organization"`, `"estate"`, `"institution"`, `"government"`, `"unknown"`. |
| `startDate` | `string` | OPTIONAL | ISO-8601 or partial date when custody began. Free text accepted for uncertain dates. |
| `endDate` | `string` | OPTIONAL | ISO-8601 or partial date when custody ended. `null` for current custodian. |
| `evidenceBasis` | `string` | OPTIONAL | Free-text basis for the custodial assertion (probate records, oral history, accession records, inscription, etc.). |
| `notes` | `string` | OPTIONAL | Free-text notes about the custody period. |

### 11.3 Relationship to ADAC Provenance Log

Custodial history records pre-digital and pre-accession custody. The ADAC provenance log records technical events on the digital container from creation forward. They are complementary:

| Aspect | Custodial History | Provenance Log |
|--------|------------------|----------------|
| Time scope | May span centuries | Begins at digital container creation |
| Subject | Physical materials and digital files | Digital container only |
| Evidence | Reconstructed from records, oral history, inscriptions | Direct system events |
| Tamper-evidence | Indirect — relies on the institution's record-keeping | Direct — hash-chained |

Both SHOULD be populated when applicable. The accession event itself SHOULD appear in the provenance log as `archivalAccession` and in custody history as the start of the holding repository's custody.

---

## 12. Preservation Metadata

The preservation metadata section captures PREMIS-aligned preservation planning, format risk assessment, fixity history, and migration tracking.

### 12.1 Schema

```json
{
  "preservation": {
    "preservationLevel": "fullPreservation",
    "preservationLevelRationale": "Genealogically and historically significant materials; institutional commitment to long-term preservation.",
    "preservationLevelDateAssigned": "2026-03-20T00:00:00Z",
    "formatAssessment": {
      "primaryFormat": {
        "formatName": "TIFF",
        "formatVersion": "6.0",
        "formatRegistryReference": "PRONOM:fmt/353",
        "riskLevel": "low",
        "riskAssessmentDate": "2026-03-20T00:00:00Z",
        "riskAssessmentNotes": "Uncompressed TIFF is a stable archival format. No migration planned."
      },
      "derivativeFormats": [
        {
          "formatName": "JPEG",
          "formatVersion": "1.02",
          "formatRegistryReference": "PRONOM:fmt/43",
          "riskLevel": "low",
          "purpose": "access"
        },
        {
          "formatName": "JPEG 2000",
          "formatVersion": "Part 1 (ISO/IEC 15444-1)",
          "formatRegistryReference": "PRONOM:fmt/151",
          "riskLevel": "low",
          "purpose": "iiifDelivery"
        }
      ]
    },
    "fixityHistory": [
      {
        "id": "fixity-001",
        "checkDate": "2026-03-16T15:00:00Z",
        "checkType": "ingestVerification",
        "result": "verified",
        "checker": "ingest-system v2.4.0"
      },
      {
        "id": "fixity-002",
        "checkDate": "2026-09-20T03:15:00Z",
        "checkType": "scheduledAudit",
        "result": "verified",
        "checker": "fixity-audit-system"
      }
    ],
    "migrationHistory": [],
    "environment": {
      "softwareEnvironment": "Original capture: SilverFast 9 with Epson Scan 2 driver",
      "hardwareEnvironment": "Original capture: Epson Expression 12000XL flatbed scanner"
    },
    "preservationPolicy": {
      "policyReference": "LCHS Digital Preservation Policy v3.2",
      "policyUrl": "https://archives.lchs.example.org/policies/preservation",
      "policyDate": "2025-11-01"
    }
  }
}
```

### 12.2 Preservation Fields

| Field | Type | Description |
|-------|------|-------------|
| `preservationLevel` | `string` | The preservation tier. See Section 20.3 for well-known values. |
| `preservationLevelRationale` | `string` | Free-text justification for the assigned preservation level. |
| `preservationLevelDateAssigned` | `string` | ISO-8601 date the preservation level was assigned. |
| `formatAssessment` | `FormatAssessment` | Format identification and risk assessment. See Section 12.3. |
| `fixityHistory` | `FixityCheck[]` | Historical fixity check events. See Section 12.4. |
| `migrationHistory` | `MigrationEvent[]` | Format migration events. See Section 12.5. |
| `environment` | `Environment` | Technical environment information (PREMIS Environment). See Section 12.6. |
| `preservationPolicy` | `PolicyReference` | Reference to the institution's preservation policy. |

### 12.3 Format Assessment

The format assessment uses PRONOM format identifiers where available. PRONOM is the National Archives (UK) registry of file formats and is the de facto standard for format identification in digital preservation.

| Field | Type | Description |
|-------|------|-------------|
| `primaryFormat` | `Format` | Format of the master file(s). |
| `derivativeFormats` | `Format[]` | Formats of derivative files. |

Each `Format` object contains:

| Field | Type | Description |
|-------|------|-------------|
| `formatName` | `string` | Format name (e.g., `"TIFF"`, `"JPEG"`, `"PDF/A"`). |
| `formatVersion` | `string` | Format version. |
| `formatRegistryReference` | `string` | Format identifier in a registry. Recommended format: `"PRONOM:<id>"`. Other registries may be used. |
| `riskLevel` | `string` | Format risk level. Well-known values: `"low"`, `"medium"`, `"high"`, `"critical"`. See Section 20.4. |
| `riskAssessmentDate` | `string` | ISO-8601 date of the risk assessment. |
| `riskAssessmentNotes` | `string` | Free-text rationale for the risk level. |
| `migrationPlanned` | `boolean` | Whether a migration is planned. Defaults to `false`. |
| `migrationTargetFormat` | `string` | If migration is planned, the target format. |
| `purpose` | `string` | For derivatives: intended use (e.g., `"access"`, `"thumbnail"`, `"iiifDelivery"`, `"print"`, `"backup"`). |

### 12.4 Fixity Check

Each fixity check records a verification event. Note that ADAC core's checksums.json provides the cryptographic baseline; fixity history records ongoing verification activity over time.

| Field | Type | Description |
|-------|------|-------------|
| `id` | `string` | Unique identifier within this container. |
| `checkDate` | `string` | ISO-8601 timestamp of the check. |
| `checkType` | `string` | Type of check. Well-known values: `"ingestVerification"`, `"scheduledAudit"`, `"manualVerification"`, `"preMigration"`, `"postMigration"`, `"transferVerification"`. |
| `result` | `string` | Result. Well-known values: `"verified"`, `"failed"`, `"partial"`. |
| `checker` | `string` | The system or person performing the check. |
| `notes` | `string` | Free-text notes (especially required for failures). |

When a fixity check is performed, an event of type `archivalFixityCheck` SHOULD also be appended to the provenance log.

### 12.5 Migration Event

Records format migrations performed on master files. Note: Master file *content* is immutable in ADAC; a migration produces a new master file (added to the container) while the original remains unchanged.

| Field | Type | Description |
|-------|------|-------------|
| `id` | `string` | Unique identifier. |
| `migrationDate` | `string` | ISO-8601 date of the migration. |
| `sourceMasterId` | `string` | The master file identifier of the source. |
| `targetMasterId` | `string` | The master file identifier of the migration target (which has been added to the container). |
| `sourceFormat` | `string` | Source format name. |
| `targetFormat` | `string` | Target format name. |
| `migrationTool` | `string` | Software used for the migration, with version. |
| `migrationRationale` | `string` | Free-text reason for the migration. |
| `qualityValidation` | `string` | Free-text description of how migration quality was validated. |

When a migration is performed, an event of type `archivalFormatMigration` MUST be appended to the provenance log.

### 12.6 Environment

Captures the technical environment information relevant to interpreting the file (PREMIS Environment).

| Field | Type | Description |
|-------|------|-------------|
| `softwareEnvironment` | `string` | Free-text description of software dependencies (rendering software, originating application). |
| `hardwareEnvironment` | `string` | Free-text description of hardware dependencies (capture device, playback hardware). |
| `dependencyNotes` | `string` | Free-text notes on rendering, accessing, or interpreting the file. |

---

## 13. Digitization Workflow

The digitization workflow record captures the production of the digital surrogate from an analog original. For born-digital materials, this section is omitted.

### 13.1 Schema

```json
{
  "digitization": {
    "digitizationProject": {
      "projectName": "Smith Family Papers Digitization Project",
      "projectIdentifier": "LCHS-DIG-2026-007",
      "fundingSource": "Ohio Humanities Council Grant 2025-OH-042"
    },
    "digitizedBy": "K. Patel, Digitization Technician",
    "digitizationDate": "2026-03-18T14:00:00Z",
    "captureDevice": {
      "deviceType": "flatbedScanner",
      "manufacturer": "Epson",
      "model": "Expression 12000XL",
      "softwareName": "SilverFast 9",
      "softwareVersion": "9.0.2"
    },
    "captureSettings": {
      "resolutionDpi": 600,
      "bitDepth": 24,
      "colorMode": "rgb",
      "fileFormat": "TIFF",
      "compression": "none",
      "iccProfile": "Adobe RGB (1998)"
    },
    "qualityStandard": {
      "framework": "FADGI",
      "level": "fourStar",
      "conformanceVerified": true,
      "verificationDate": "2026-03-19T10:00:00Z"
    },
    "physicalPreparation": "Original photograph cleaned with soft brush; no rebinding required.",
    "postProcessing": [
      {
        "operation": "deskew",
        "parameters": "Auto-deskew, -0.4 degree correction",
        "performedBy": "K. Patel"
      },
      {
        "operation": "colorCorrection",
        "parameters": "ICC profile applied; no manual color adjustment",
        "performedBy": "K. Patel"
      }
    ],
    "qualityControl": {
      "qcReviewer": "M. Johnson, Lead Digitization Specialist",
      "qcDate": "2026-03-19T15:00:00Z",
      "qcResult": "passed",
      "qcNotes": "Image meets FADGI 4-star requirements. All metadata complete."
    }
  }
}
```

### 13.2 Digitization Fields

| Field | Type | Description |
|-------|------|-------------|
| `digitizationProject` | `Project` | Project context. |
| `digitizedBy` | `string` | Name and role of the digitization operator. |
| `digitizationDate` | `string` | ISO-8601 timestamp of digitization. |
| `captureDevice` | `CaptureDevice` | The capture device used. |
| `captureSettings` | `CaptureSettings` | Technical capture parameters. |
| `qualityStandard` | `QualityStandard` | Digitization quality standard conformance. |
| `physicalPreparation` | `string` | Free-text description of any physical preparation of the original. |
| `postProcessing` | `PostProcessingOperation[]` | Post-capture processing operations applied to the master. |
| `qualityControl` | `QualityControl` | Quality control review record. |

### 13.3 Quality Standard

The `framework` field identifies the digitization quality framework used. Well-known values: `"FADGI"` (US Federal Agencies Digital Guidelines Initiative), `"Metamorfoze"` (Dutch national guidelines), `"ISO19264"` (international standard for image quality assessment), `"local"` (institution-specific standard).

For FADGI: `level` is one of `"oneStar"`, `"twoStar"`, `"threeStar"`, `"fourStar"`. For Metamorfoze: `level` is one of `"metamorfozeStrict"`, `"metamorfoze"`, `"metamorfozeLight"`, `"metamorfozeExtraLight"`. For ISO 19264: `level` is the relevant ISO compliance level.

---

## 14. Rights and Access

Comprehensive rights and access metadata. Distinct from ADAC core's `accessControl` (which records the operational classification for repository systems), this section records the legal and donor-imposed basis for any restrictions.

### 14.1 Schema

```json
{
  "rights": {
    "copyrightStatus": "publicDomain",
    "copyrightStatusBasis": "Materials created before 1929; in public domain in the United States.",
    "copyrightHolder": null,
    "copyrightExpiryDate": null,
    "donorRestrictions": [],
    "statutoryRestrictions": [
      {
        "id": "stat-001",
        "restrictionType": "personalData",
        "restrictionBasis": "Some materials contain personal information about living descendants of John Smith.",
        "restrictionScope": "Specific items containing identifying information about living persons (see item-level descriptions).",
        "restrictionExpiry": null,
        "exceptionConditions": "Access permitted with redaction of identifying information."
      }
    ],
    "accessConditions": "Open for research without restriction. Some items containing personal information about living persons require redaction prior to reproduction.",
    "reproductionRights": "Reproduction and publication permitted; attribution to Licking County Historical Society requested.",
    "rightsContact": "archivist@lchs.example.org",
    "rightsStatementUri": "https://rightsstatements.org/page/NoC-US/1.0/"
  }
}
```

### 14.2 Rights Fields

| Field | Type | Description |
|-------|------|-------------|
| `copyrightStatus` | `string` | Copyright status. See Section 20.5 for well-known values. |
| `copyrightStatusBasis` | `string` | Free-text basis for the copyright determination. |
| `copyrightHolder` | `string` | Name of the copyright holder (if known and applicable). |
| `copyrightExpiryDate` | `string` | ISO-8601 date when copyright expires (for in-copyright materials). |
| `donorRestrictions` | `Restriction[]` | Restrictions imposed by the donor. |
| `statutoryRestrictions` | `Restriction[]` | Restrictions imposed by statute (data protection, classification, etc.). |
| `accessConditions` | `string` | Free-text summary of access conditions. ISAD(G) 3.4.1. |
| `reproductionRights` | `string` | Free-text statement of reproduction rights. |
| `rightsContact` | `string` | Contact for rights inquiries (email or office). |
| `rightsStatementUri` | `string` | URI of a standardized rights statement (e.g., from rightsstatements.org or Creative Commons). |

### 14.3 Restriction

| Field | Type | Description |
|-------|------|-------------|
| `id` | `string` | Unique identifier within this container. |
| `restrictionType` | `string` | Type of restriction. See Section 20.6 for well-known values. |
| `restrictionBasis` | `string` | Free-text basis for the restriction (donor agreement, statute, court order). |
| `restrictionScope` | `string` | Free-text description of what the restriction covers. |
| `restrictionExpiry` | `string` | ISO-8601 date the restriction expires, or `null` if indefinite. |
| `exceptionConditions` | `string` | Free-text description of conditions under which access is permitted despite the restriction. |

### 14.4 Relationship to ADAC `accessControl`

The legal/donor basis for restrictions is recorded here in the `rights` section. The operational classification used by repository systems (which audiences can access, embargo dates) is recorded in ADAC core's `accessControl` (manifest, master, or derivative level). Both should be consistent.

---

## 15. Deaccession Record

The deaccession record is present only when materials have been formally deaccessioned. Deaccession is a serious professional decision that requires documentation; this section provides the structure for that documentation.

### 15.1 Schema

```json
{
  "deaccession": {
    "deaccessionDate": "2030-05-15T00:00:00Z",
    "deaccessionAuthority": "LCHS Board of Trustees, Resolution 2030-15",
    "deaccessionReason": "outOfScope",
    "deaccessionRationale": "Materials determined to fall outside the LCHS collecting scope upon comprehensive collection review.",
    "disposition": "transferred",
    "dispositionRecipient": "Ohio Historical Society",
    "dispositionDate": "2030-06-01T00:00:00Z",
    "dispositionDocumentation": "Transfer agreement OHS-LCHS-2030-008",
    "approvedBy": "J. Anderson, Head Archivist; LCHS Board of Trustees",
    "containerRetainedAsRecord": true
  }
}
```

### 15.2 Deaccession Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `deaccessionDate` | `string` | REQUIRED | ISO-8601 date of formal deaccession. |
| `deaccessionAuthority` | `string` | REQUIRED | Authority approving the deaccession (board resolution, director's authorization). |
| `deaccessionReason` | `string` | OPTIONAL | Reason. Well-known values: `"outOfScope"`, `"duplicate"`, `"poorCondition"`, `"legalRequirement"`, `"donorReturn"`, `"resourceConstraints"`. |
| `deaccessionRationale` | `string` | OPTIONAL | Free-text rationale. |
| `disposition` | `string` | OPTIONAL | Disposition method. Well-known values: `"transferred"`, `"returned"`, `"sold"`, `"destroyed"`, `"unknown"`. |
| `dispositionRecipient` | `string` | OPTIONAL | Recipient (institution, donor, purchaser). |
| `dispositionDate` | `string` | OPTIONAL | ISO-8601 date of disposition. |
| `dispositionDocumentation` | `string` | OPTIONAL | Reference to disposition documentation. |
| `approvedBy` | `string` | OPTIONAL | Name(s) of approving authority(ies). |
| `containerRetainedAsRecord` | `boolean` | OPTIONAL | Whether the ADAC container is retained as a record of the deaccession. Often `true` even when the physical materials are removed. |

When deaccession occurs, an `archivalDeaccession` event MUST be appended to the provenance log.

---

## 16. Region Linked Entities

ADAC-Preservation stores per-region archival data in the ADAC region `linkedEntities` dictionary. These annotations enable archivists and conservators to record observations on specific areas of the digital surrogate.

### 16.1 Linked Entity Keys

| Key | Description |
|-----|-------------|
| `archival:description` | Descriptive observations about a specific area (Section 17). |
| `archival:condition` | Condition assessment for a specific area (Section 18). |
| `archival:marking` | Stamps, seals, signatures, marginalia, and other physical markings (Section 19). |

### 16.2 Round-Trip Safety

Non-archival consumers that read a container and write it back MUST preserve all linked entity data unchanged.

### 16.3 Multiple Entities per Region and Multi-Profile Coexistence

A single region MAY have multiple archival linked entities simultaneously (a single region might be both a stamp marking and a damaged area). Archival linked entities also coexist with linked entities from other profiles. A region marking the area where a person's name appears in a census might carry both `archival:condition` (faded ink) and `genealogy:person` (the identified individual) entities.

---

## 17. Description Annotation

**Linked Entity Key**: `archival:description`

Description annotations record archivist observations about specific regions of the digital surrogate.

### 17.1 Schema

```json
{
  "descriptionType": "captionOrLabel",
  "descriptionText": "Photograph caption written on lower margin in blue ink: 'Smith Family Reunion, July 4, 1885'",
  "language": "en",
  "transcribedBy": "K. Patel",
  "transcribedOn": "2026-03-20T11:00:00Z",
  "notes": "Caption appears to be in John Smith's handwriting based on comparison with letters in the same fonds."
}
```

### 17.2 Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `descriptionType` | `string` | REQUIRED | Type of description. Well-known values: `"captionOrLabel"`, `"annotation"`, `"marginalia"`, `"inscription"`, `"identifyingFeature"`, `"contextualNote"`. |
| `descriptionText` | `string` | REQUIRED | The textual content of the description or transcription. |
| `language` | `string` | OPTIONAL | Language of the text (IETF BCP 47 tag). |
| `transcribedBy` | `string` | OPTIONAL | Person or system that produced the transcription. |
| `transcribedOn` | `string` | OPTIONAL | ISO-8601 timestamp of transcription. |
| `notes` | `string` | OPTIONAL | Free-text archivist observations. |

---

## 18. Condition Annotation

**Linked Entity Key**: `archival:condition`

Condition annotations record observations about the physical condition of specific regions of the original, as visible in the digital surrogate. These observations may inform preservation planning and conservation decisions.

### 18.1 Schema

```json
{
  "conditionType": "fading",
  "severity": "moderate",
  "stable": true,
  "observedBy": "K. Patel",
  "observedOn": "2026-03-18T14:00:00Z",
  "conservationRecommendation": "Monitor; no immediate intervention required.",
  "notes": "Ink has faded but text remains legible. Common condition for iron gall ink of this era."
}
```

### 18.2 Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `conditionType` | `string` | REQUIRED | Type of condition issue. See Section 20.7 for well-known values. |
| `severity` | `string` | OPTIONAL | Severity. Well-known values: `"minor"`, `"moderate"`, `"severe"`, `"critical"`. |
| `stable` | `boolean` | OPTIONAL | Whether the condition is stable or actively deteriorating. |
| `observedBy` | `string` | OPTIONAL | Person who recorded the observation. |
| `observedOn` | `string` | OPTIONAL | ISO-8601 timestamp of the observation. |
| `conservationRecommendation` | `string` | OPTIONAL | Free-text conservation recommendation. |
| `notes` | `string` | OPTIONAL | Free-text observation notes. |

---

## 19. Marking Annotation

**Linked Entity Key**: `archival:marking`

Marking annotations record physical markings on the original — stamps, seals, signatures, ownership marks, library plates, accession numbers, accession stamps. These markings often carry archival significance independent of the document's primary content.

### 19.1 Schema

```json
{
  "markingType": "ownershipStamp",
  "markingText": "PROPERTY OF JOHN SMITH",
  "markingDescription": "Rectangular ink stamp, purple, approximately 3cm x 1cm.",
  "markingDate": "circa 1880",
  "markingMaker": "John Smith",
  "significance": "Ownership mark indicating original possession by John Smith.",
  "notes": null
}
```

### 19.2 Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `markingType` | `string` | REQUIRED | Type of marking. Well-known values: `"signature"`, `"ownershipStamp"`, `"libraryStamp"`, `"accessionStamp"`, `"seal"`, `"watermark"`, `"bookplate"`, `"emboss"`, `"chop"`, `"notation"`. |
| `markingText` | `string` | OPTIONAL | Text content of the marking, if textual. |
| `markingDescription` | `string` | OPTIONAL | Free-text description of the marking's appearance. |
| `markingDate` | `string` | OPTIONAL | Date of the marking, if known. May be free text for uncertain dates. |
| `markingMaker` | `string` | OPTIONAL | Person, family, organization, or institution that made the mark. |
| `significance` | `string` | OPTIONAL | Free-text explanation of the marking's significance. |
| `notes` | `string` | OPTIONAL | Free-text additional notes. |

---

## 20. Well-Known Value Sets

ADAC-Preservation defines controlled vocabularies for several fields. Implementations SHOULD use these well-known values when applicable but MAY use custom values for domain-specific needs. All values are camelCase strings unless otherwise noted.

### 20.1 Processing Status

Used in `accession.processingStatus`.

| Value | Description |
|-------|-------------|
| `"unprocessed"` | Materials accessioned but not yet arranged or described. |
| `"minimallyProcessed"` | Basic arrangement and collection-level description complete. |
| `"partiallyProcessed"` | Some series or files arranged and described; work continuing. |
| `"fullyProcessed"` | Complete arrangement, item-level description where appropriate, finding aid published. |
| `"reprocessing"` | Previously processed materials currently being reprocessed (re-arrangement, re-description). |

### 20.2 Level of Description

Used in `description.levelOfDescription`. Aligned with ISAD(G) levels.

| Value | Description |
|-------|-------------|
| `"fonds"` | The whole of the records of a creator. The highest level. |
| `"subFonds"` | A subdivision of a fonds (used for personal papers within an institutional fonds, etc.). |
| `"series"` | Documents arranged as a unit because of common subject, function, or form. |
| `"subSeries"` | A subdivision of a series. |
| `"file"` | A grouping of documents (folder, dossier). |
| `"item"` | The smallest indivisible archival unit (single document, single photograph). |
| `"collection"` | An artificial assembly (used for materials assembled by the repository rather than naturally accumulated by a creator). |

### 20.3 Preservation Level

Used in `preservation.preservationLevel`.

| Value | Description |
|-------|-------------|
| `"fullPreservation"` | Full preservation commitment including format migration. The repository commits to preserving the intellectual content indefinitely, including periodic format migrations to current formats. |
| `"bitLevelPreservation"` | The repository commits to preserving the bit stream unchanged but does not commit to format migration. The original file will be preserved; rendering is not guaranteed. |
| `"contentPreservation"` | The repository commits to preserving the intellectual content but reserves the right to migrate or transform the format as needed. |
| `"accessOnly"` | Materials are held for current access only without long-term preservation commitment. |
| `"transitional"` | Preservation level not yet determined; under review. |

### 20.4 Format Risk Level

Used in `preservation.formatAssessment.*.riskLevel`.

| Value | Description |
|-------|-------------|
| `"low"` | Format is stable, well-supported, with multiple implementations. No migration anticipated. |
| `"medium"` | Format is supported but shows signs of risk (declining vendor support, limited implementations, niche use). Migration may be considered. |
| `"high"` | Format is at significant risk of obsolescence. Migration planning recommended. |
| `"critical"` | Format is obsolete or imminently obsolete. Migration urgent. |

### 20.5 Copyright Status

Used in `rights.copyrightStatus`.

| Value | Description |
|-------|-------------|
| `"publicDomain"` | Materials are in the public domain (creator's rights have expired, or never existed, or were dedicated to the public domain). |
| `"inCopyright"` | Materials are protected by copyright; rights belong to identified holder. |
| `"inCopyrightOrphan"` | Materials are protected by copyright but the rights holder cannot be identified or located despite a diligent search. |
| `"licensedOpen"` | Materials are protected by copyright but licensed under an open license (Creative Commons, etc.). |
| `"copyrightUndetermined"` | Copyright status has not been determined. |
| `"copyrightAssigned"` | Copyright has been assigned to the holding repository. |

### 20.6 Restriction Type

Used in `rights.donorRestrictions[].restrictionType` and `rights.statutoryRestrictions[].restrictionType`.

| Value | Description |
|-------|-------------|
| `"none"` | No restriction. |
| `"personalData"` | Restriction based on personal data protection (GDPR, CCPA, state data protection laws). |
| `"medicalPrivacy"` | Restriction based on medical/health privacy law. |
| `"minorProtection"` | Restriction protecting minor children's identifying information. |
| `"donorRequested"` | Restriction at the donor's request (e.g., embargo period, restricted to family members). |
| `"sealed"` | Court-sealed materials. |
| `"classified"` | National security classified materials. |
| `"timeEmbargo"` | Time-limited embargo (will lift on a specific date). |
| `"physicalConditionFragile"` | Access restricted due to fragility of original; access via surrogate only. |
| `"culturallySensitive"` | Restriction based on cultural sensitivity (e.g., sacred or ceremonial materials, materials subject to NAGPRA in the US, indigenous protocols). |
| `"copyrightRestricted"` | Use restricted by copyright holder requirements. |
| `"administrativeReview"` | Restriction pending administrative review. |

### 20.7 Condition Types

Used in `archival:condition.conditionType`.

| Value | Description |
|-------|-------------|
| `"fading"` | Faded ink, print, or color. |
| `"foxing"` | Brown spots from oxidation. |
| `"tear"` | Physical tear. |
| `"loss"` | Material loss (missing area). |
| `"stain"` | Staining (water, food, ink). |
| `"mold"` | Mold or mildew. |
| `"insectDamage"` | Damage from insects. |
| `"fireDamage"` | Fire or smoke damage. |
| `"waterDamage"` | Water damage causing warping or staining. |
| `"bleedThrough"` | Ink bleeding through from reverse side. |
| `"creasing"` | Creasing or folding damage. |
| `"adhesiveResidue"` | Residue from old adhesives or repairs. |
| `"previousRepair"` | Visible previous conservation repair. |
| `"acidification"` | Paper acidification, brittleness. |
| `"emulsionDamage"` | Photographic emulsion damage (cracking, lifting). |
| `"silverMirroring"` | Silver mirroring on photographic prints. |
| `"bindingDamage"` | Damage to binding (loose pages, broken spine). |

---

## 21. JSON Conventions

All JSON within this profile follows the ADAC 1.0 conventions: camelCase property naming, indented formatting, null-valued properties SHOULD be omitted, UTF-8 encoding without BOM, unknown properties MUST be preserved during round-trip serialization, ISO-8601 date/time format, RFC 4122 lowercase hexadecimal UUID format.

---

## 22. Interoperability

### 22.1 EAD (Encoded Archival Description)

ADAC-Preservation containers describe individual items or files; EAD finding aids describe whole collections. The two are complementary. The `description.findingAidReference.system: "EAD"` identifier links a container back to the EAD finding aid that describes its broader context. Repositories can publish finding aids in EAD and individual digitized items as ADAC-Preservation containers, with consistent identifiers across both.

### 22.2 ArchivesSpace and AtoM

ArchivesSpace and AtoM are the two most widely used open-source archival collection management systems. Both can serve as the source of authoritative descriptive metadata. ADAC-Preservation containers can be generated from these systems, with the `description.findingAidReference` linking back. Updates to the descriptive metadata in the source system can be re-synchronized to the ADAC container through round-trip workflows.

### 22.3 PREMIS

ADAC-Preservation's preservation metadata aligns with PREMIS concepts (Section 5.2). For institutions requiring formal PREMIS XML output (for example, for OAIS audit purposes), a PREMIS export can be generated from the ADAC container's archival profile and provenance log. A future companion specification may define a normative PREMIS round-trip mapping.

### 22.4 IIIF (International Image Interoperability Framework)

ADAC-Preservation containers can serve as the canonical source for IIIF presentations. The container holds the master files and authoritative metadata; IIIF Presentation API manifests are generated from the archival profile and master file references. Image API requests can be served from container derivatives (typically JPEG 2000 in the `derivatives/` directory). Canvas labels and annotations can be derived from `archival:description` and `archival:marking` linked entities.

### 22.5 OAI-PMH and Aggregator Harvesting

The Open Archives Initiative Protocol for Metadata Harvesting allows repositories to expose metadata to aggregators (DPLA, Europeana, Trove, NLA Trove). ADAC-Preservation metadata can be mapped to Dublin Core (the OAI-PMH base format) or richer formats (EAD, MODS) for harvesting. Mapping guidance:

| ADAC-Preservation Field | Dublin Core Element |
|--------------------|---------------------|
| `description.title` | `dc:title` |
| `description.creator.name` | `dc:creator` |
| `description.scopeAndContent` | `dc:description` |
| `description.datesOfCreation` | `dc:date` |
| `description.languageOfMaterials` | `dc:language` |
| `accession.holdingRepository.name` | `dc:publisher` (in DPLA convention) |
| `rights.rightsStatementUri` | `dc:rights` |
| `description.relatedMaterials[].description` | `dc:relation` |

### 22.6 Profile Coexistence

ADAC-Preservation containers MAY include additional profiles. Common combinations:

- **Archival + Genealogy** — A scanned census page held in a historical society collection, with archival management metadata and genealogical research metadata for the same item.
- **Archival + Legal** — Court records held in a state archive, with archival description and legal-case context.
- **Archival + (future) Medical** — Historical medical records of significance to medical history research.

The profiles coexist without conflict. Linked entity keys use distinct namespaces (`archival:description` vs. `genealogy:person` vs. `legal:exhibit`). The archival profile manages the object as a holding; other profiles enrich it for specific user communities.

### 22.7 Custodial History vs. Provenance Log

The custodial history and the ADAC provenance log serve complementary purposes (Section 11.3). Both SHOULD be populated when applicable.

---

## 23. Complete Container Example

The following shows a complete Signed Archival ADAC-Preservation container for a single photograph from the Smith Family Papers held by the Licking County Historical Society.

### 23.1 Container Structure

```
smith-family-photo-1885.adac
├── manifest.json
├── master/
│   └── master_0001.tif              (Master scan, 600 DPI TIFF, 178 MB)
├── metadata/
│   ├── core.json
│   ├── structure.json
│   └── profiles/
│       ├── archival.json
│       └── genealogy.json
├── derivatives/
│   ├── deriv_thumbnail_001.jpg      (200x200 thumbnail)
│   ├── deriv_preview_001.jpg        (800x600 preview)
│   └── deriv_iiif_001.jp2           (IIIF delivery copy, JPEG 2000)
├── regions/
│   └── master-001.regions.json      (Marked regions for caption, family members, condition)
├── provenance/
│   ├── log.json                     (hash-chained events)
│   └── checksums.json
└── signatures/
    ├── index.json
    ├── container-accession.p7s      (Signed at accession)
    └── container-processed.p7s      (Signed when processing complete)
```

### 23.2 Archival Profile (`metadata/profiles/archival.json`)

```json
{
  "profileId": "urn:adac:profile:archival:v1",
  "profileType": "archival",
  "profileVersion": "1.0.0",
  "title": "ADAC Archival Profile",
  "data": {
    "accession": {
      "accessionNumber": "2026.042",
      "accessionDate": "2026-03-15T00:00:00Z",
      "holdingRepository": {
        "name": "Licking County Historical Society",
        "identifier": "OCLC:LCHS-OH",
        "address": "Newark, Ohio, United States"
      },
      "donor": {
        "name": "Estate of Mary E. Smith",
        "donorType": "estate",
        "address": "Newark, Ohio, United States"
      },
      "transferAgreement": {
        "agreementType": "deedOfGift",
        "agreementDate": "2026-02-20T00:00:00Z",
        "agreementReference": "Deed of Gift, file 2026-DOG-042",
        "termsSummary": "Unrestricted gift; donor retains no rights or restrictions."
      },
      "appraisalDecision": {
        "decision": "accepted",
        "appraisedBy": "J. Anderson, Head Archivist",
        "appraisalDate": "2026-02-15T00:00:00Z",
        "appraisalNotes": "Genealogically significant Smith family papers, 1850-1920. Includes original census transcripts and photographs."
      },
      "processingStatus": "fullyProcessed",
      "processingNotes": "Arranged at item level, described, and digitized. Finding aid published 2026-04-30."
    },
    "description": {
      "title": "Photograph: Smith Family at Reunion, July 4, 1885",
      "levelOfDescription": "item",
      "creator": {
        "name": "Unknown photographer",
        "creatorType": "person"
      },
      "datesOfCreation": {
        "startDate": "1885-07-04",
        "endDate": "1885-07-04"
      },
      "extent": {
        "physicalExtent": "1 albumen print (16 cm x 22 cm)",
        "digitalExtent": "1 file (178 MB TIFF + derivatives)"
      },
      "scopeAndContent": "Group portrait of the extended Smith family taken at the family farm in Newark, Licking County, Ohio, during a Fourth of July reunion in 1885. Subjects include John Smith (head of family), his wife Mary Jones Smith, their children, and various relatives.",
      "languageOfMaterials": ["en"],
      "physicalCharacteristics": "Albumen print mounted on card stock. Some fading visible in highlights. Caption written in ink on lower margin.",
      "findingAidReference": {
        "system": "ArchivesSpace",
        "identifier": "as:resource:42",
        "url": "https://archives.lchs.example.org/repositories/2/resources/42"
      }
    },
    "arrangement": {
      "fondsIdentifier": "MS-1234",
      "fondsTitle": "Smith Family Papers",
      "seriesIdentifier": "MS-1234.3",
      "seriesTitle": "Photographs and Visual Materials",
      "fileIdentifier": "MS-1234.3.7",
      "fileTitle": "Family Photograph Album, ca. 1880",
      "itemIdentifier": "MS-1234.3.7.42",
      "itemTitle": "Photograph: Smith Family at Reunion, 1885",
      "physicalLocation": {
        "container": "Box 3",
        "folder": "Folder 7",
        "shelf": "Stack Range 4-A"
      }
    },
    "custodialHistory": [
      {
        "id": "custody-001",
        "custodian": "John Smith and family",
        "custodianType": "family",
        "startDate": "1885",
        "endDate": "2025",
        "evidenceBasis": "Family possession through three generations per family records and inscriptions on photograph album."
      },
      {
        "id": "custody-002",
        "custodian": "Estate of Mary E. Smith",
        "custodianType": "estate",
        "startDate": "2025-11-15",
        "endDate": "2026-03-15",
        "evidenceBasis": "Estate administration records."
      },
      {
        "id": "custody-003",
        "custodian": "Licking County Historical Society",
        "custodianType": "institution",
        "startDate": "2026-03-15",
        "endDate": null,
        "evidenceBasis": "Deed of Gift, file 2026-DOG-042."
      }
    ],
    "preservation": {
      "preservationLevel": "fullPreservation",
      "preservationLevelRationale": "Genealogically and historically significant photograph; institutional commitment to long-term preservation.",
      "preservationLevelDateAssigned": "2026-03-20T00:00:00Z",
      "formatAssessment": {
        "primaryFormat": {
          "formatName": "TIFF",
          "formatVersion": "6.0",
          "formatRegistryReference": "PRONOM:fmt/353",
          "riskLevel": "low",
          "riskAssessmentDate": "2026-03-20T00:00:00Z",
          "riskAssessmentNotes": "Uncompressed TIFF is a stable archival format."
        },
        "derivativeFormats": [
          {
            "formatName": "JPEG",
            "formatVersion": "1.02",
            "formatRegistryReference": "PRONOM:fmt/43",
            "riskLevel": "low",
            "purpose": "access"
          },
          {
            "formatName": "JPEG 2000",
            "formatVersion": "Part 1",
            "formatRegistryReference": "PRONOM:fmt/151",
            "riskLevel": "low",
            "purpose": "iiifDelivery"
          }
        ]
      },
      "fixityHistory": [
        {
          "id": "fixity-001",
          "checkDate": "2026-03-16T15:00:00Z",
          "checkType": "ingestVerification",
          "result": "verified",
          "checker": "ingest-system v2.4.0"
        }
      ],
      "preservationPolicy": {
        "policyReference": "LCHS Digital Preservation Policy v3.2",
        "policyUrl": "https://archives.lchs.example.org/policies/preservation",
        "policyDate": "2025-11-01"
      }
    },
    "digitization": {
      "digitizationProject": {
        "projectName": "Smith Family Papers Digitization Project",
        "projectIdentifier": "LCHS-DIG-2026-007",
        "fundingSource": "Ohio Humanities Council Grant 2025-OH-042"
      },
      "digitizedBy": "K. Patel, Digitization Technician",
      "digitizationDate": "2026-03-18T14:00:00Z",
      "captureDevice": {
        "deviceType": "flatbedScanner",
        "manufacturer": "Epson",
        "model": "Expression 12000XL",
        "softwareName": "SilverFast 9",
        "softwareVersion": "9.0.2"
      },
      "captureSettings": {
        "resolutionDpi": 600,
        "bitDepth": 24,
        "colorMode": "rgb",
        "fileFormat": "TIFF",
        "compression": "none",
        "iccProfile": "Adobe RGB (1998)"
      },
      "qualityStandard": {
        "framework": "FADGI",
        "level": "fourStar",
        "conformanceVerified": true,
        "verificationDate": "2026-03-19T10:00:00Z"
      },
      "qualityControl": {
        "qcReviewer": "M. Johnson, Lead Digitization Specialist",
        "qcDate": "2026-03-19T15:00:00Z",
        "qcResult": "passed"
      }
    },
    "rights": {
      "copyrightStatus": "publicDomain",
      "copyrightStatusBasis": "Photograph created in 1885; in public domain in the United States.",
      "donorRestrictions": [],
      "statutoryRestrictions": [],
      "accessConditions": "Open for research and reproduction without restriction.",
      "reproductionRights": "Reproduction and publication permitted; attribution to Licking County Historical Society requested.",
      "rightsContact": "archivist@lchs.example.org",
      "rightsStatementUri": "https://rightsstatements.org/page/NoC-US/1.0/"
    }
  }
}
```

### 23.3 Region Annotations (Excerpt)

```json
{
  "mediaId": "master-001",
  "coordinateSystem": "pixel",
  "width": 5200,
  "height": 7000,
  "regions": [
    {
      "id": "region-001",
      "type": "boundingBox",
      "label": "Photograph caption",
      "bounds": { "x": 200.0, "y": 6500.0, "width": 4800.0, "height": 200.0 },
      "linkedEntities": {
        "archival:description": {
          "descriptionType": "captionOrLabel",
          "descriptionText": "Smith Family Reunion, July 4, 1885",
          "language": "en",
          "transcribedBy": "K. Patel",
          "transcribedOn": "2026-03-20T11:00:00Z",
          "notes": "Caption in ink, likely written by John Smith based on handwriting comparison."
        }
      }
    },
    {
      "id": "region-002",
      "type": "boundingBox",
      "label": "John Smith — head of household, center back row",
      "bounds": { "x": 2300.0, "y": 1800.0, "width": 600.0, "height": 800.0 },
      "linkedEntities": {
        "archival:description": {
          "descriptionType": "identifyingFeature",
          "descriptionText": "Identified as John Smith (1828-1901) based on comparison with other photographs in the fonds and family identification.",
          "transcribedBy": "K. Patel"
        },
        "genealogy:person": {
          "givenName": "John",
          "surname": "Smith",
          "birthDate": "1828",
          "deathDate": "1901",
          "relationshipToHead": "Self",
          "isLiving": false
        }
      }
    },
    {
      "id": "region-003",
      "type": "boundingBox",
      "label": "Faded area — upper right corner",
      "bounds": { "x": 4400.0, "y": 200.0, "width": 600.0, "height": 600.0 },
      "linkedEntities": {
        "archival:condition": {
          "conditionType": "fading",
          "severity": "moderate",
          "stable": true,
          "observedBy": "K. Patel",
          "observedOn": "2026-03-18T14:00:00Z",
          "conservationRecommendation": "Monitor; no immediate intervention.",
          "notes": "Albumen print fading typical for this era. Faces still legible."
        }
      }
    }
  ]
}
```

---

## 24. Validation

### 24.1 Base Validation

ADAC-Preservation containers are validated by the standard ADAC validator. Standard ADAC error codes apply (ADAC-050, ADAC-051, ADAC-022, ADAC-082, ADAC-083, ADAC-062, ADAC-063, ADAC-091).

### 24.2 Profile-Specific Validation Rules

The following rules are specific to ADAC-Preservation containers.

| Rule | Severity | Description |
|------|----------|-------------|
| ARCH-001 | Error | The profile file's `profileType` is not `"archival"`. |
| ARCH-002 | Error | The profile file's `profileId` is not `"urn:adac:profile:archival:v1"`. |
| ARCH-010 | Warning | `accession.accessionNumber` is empty when an accession record is provided. |
| ARCH-011 | Warning | `accession.accessionDate` is later than the container's `createdOn` timestamp in the manifest. |
| ARCH-020 | Warning | `description.levelOfDescription` is not in the well-known set. |
| ARCH-021 | Warning | `description.creator` is missing when `description.title` is present. |
| ARCH-030 | Warning | `arrangement` hierarchical identifiers do not form a parent-prefix path (e.g., `seriesIdentifier` does not start with `fondsIdentifier`). |
| ARCH-040 | Warning | `custodialHistory[]` entries overlap in date or have gaps without `evidenceBasis` notes. |
| ARCH-050 | Warning | `preservation.preservationLevel` is `"fullPreservation"` but the container is not Archival or Signed Archival conformance. |
| ARCH-051 | Warning | `preservation.formatAssessment.primaryFormat.riskLevel` is `"high"` or `"critical"` but no migration is planned. |
| ARCH-052 | Warning | `preservation.fixityHistory[]` does not contain at least one entry of type `"ingestVerification"`. |
| ARCH-060 | Warning | `digitization` is present but `digitization.qualityControl.qcResult` is missing. |
| ARCH-061 | Warning | `digitization.qualityStandard.framework` is `"FADGI"` but `level` is not one of the four FADGI star values. |
| ARCH-070 | Warning | `rights.copyrightStatus` is `"inCopyright"` but `rights.copyrightHolder` is empty. |
| ARCH-071 | Warning | `rights.statutoryRestrictions[]` references a restriction with no `restrictionExpiry` and no `exceptionConditions` (the materials are effectively permanently restricted with no defined access path). |
| ARCH-080 | Warning | `deaccession` is present but no `archivalDeaccession` event appears in the provenance log. |
| ARCH-090 | Info | Container has `preservation.preservationLevel: "fullPreservation"` but is not Signed Archival. Signed Archival is RECOMMENDED for full preservation commitments. |

### 24.3 Application-Level Semantic Validation

Beyond the rules above, deeper semantic validation (verifying that custodial history is continuous, that PRONOM identifiers are valid, that ICC profiles are recognized) is the responsibility of the consuming application.

---

## 25. References

### 25.1 Normative References

| Reference | Description |
|-----------|-------------|
| [ADAC 1.0 Format Specification](../../ADAC/spec/ADAC-Format-Specification.md) | The base container format. |
| [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) | Key words for use in RFCs to Indicate Requirement Levels. |
| [RFC 4122](https://www.rfc-editor.org/rfc/rfc4122) | UUID URN Namespace. |
| [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html) | Date and time representations. |
| [IETF BCP 47](https://www.rfc-editor.org/info/bcp47) | Tags for Identifying Languages. |

### 25.2 Informative References — Standards

| Reference | Description |
|-----------|-------------|
| [PREMIS Data Dictionary](https://www.loc.gov/standards/premis/) | Preservation Metadata: Implementation Strategies, maintained by the Library of Congress. |
| [ISAD(G)](https://www.ica.org/en/isadg-general-international-standard-archival-description-second-edition) | International Standard Archival Description (General), 2nd ed., maintained by the International Council on Archives. |
| [DACS](https://saa-ts-dacs.github.io/) | Describing Archives: A Content Standard, maintained by the Society of American Archivists. |
| [EAD](https://www.loc.gov/ead/) | Encoded Archival Description, maintained by the Library of Congress and the Society of American Archivists. |
| [OAIS / ISO 14721](https://www.iso.org/standard/57284.html) | Open Archival Information System Reference Model. |
| [ISO 15489](https://www.iso.org/standard/62542.html) | Records management. |
| [Dublin Core Metadata Element Set](https://www.dublincore.org/specifications/dublin-core/dces/) | Core metadata vocabulary. |
| [Dublin Core Terms](https://www.dublincore.org/specifications/dublin-core/dcmi-terms/) | Extended Dublin Core terms. |

### 25.3 Informative References — Digitization Quality

| Reference | Description |
|-----------|-------------|
| [FADGI Technical Guidelines](https://www.digitizationguidelines.gov/guidelines/) | Federal Agencies Digital Guidelines Initiative — US digitization quality framework. |
| [Metamorfoze Preservation Imaging Guidelines](https://www.metamorfoze.nl/english/digitization) | Dutch national digitization quality guidelines. |
| [ISO 19264](https://www.iso.org/standard/64221.html) | Photography — Archiving systems — Image quality analysis. |

### 25.4 Informative References — Format Registries and Tools

| Reference | Description |
|-----------|-------------|
| [PRONOM](https://www.nationalarchives.gov.uk/pronom/) | The National Archives (UK) registry of file formats. The de facto standard for format identification. |
| [DROID](https://www.nationalarchives.gov.uk/information-management/manage-information/preserving-digital-records/droid/) | Digital Record Object Identification — file format identification tool from the UK National Archives. |
| [JHOVE](https://jhove.openpreservation.org/) | JSTOR/Harvard Object Validation Environment — file format identification and validation. |

### 25.5 Informative References — Delivery and Aggregation

| Reference | Description |
|-----------|-------------|
| [IIIF](https://iiif.io/) | International Image Interoperability Framework. |
| [OAI-PMH](https://www.openarchives.org/pmh/) | Open Archives Initiative Protocol for Metadata Harvesting. |
| [rightsstatements.org](https://rightsstatements.org/) | Standardized rights statements developed by Europeana and DPLA. |

### 25.6 Informative References — Collection Management Systems

| Reference | Description |
|-----------|-------------|
| [ArchivesSpace](https://archivesspace.org/) | Open-source archival collection management system. |
| [AtoM (Access to Memory)](https://www.accesstomemory.org/) | Open-source archival description and access platform. |

### 25.7 Informative References — Companion ADAC Profiles

| Reference | Description |
|-----------|-------------|
| [ADAC-Genealogy 1.0 Profile Specification](../../ADAC-Genealogy/spec/ADAC-Genealogy-Profile-Specification.md) | Genealogy profile — frequently coexists with archival profile. |
| [ADAC-Legal 1.0 Profile Specification](ADAC-Legal-Profile-Specification.md) | Legal profile — for archival materials with legal significance. |

---

## About the Editor

ADAC is edited and maintained by **John Vaden**, a genealogist and technical workflow contributor with decades of experience in genealogical research and in shaping data practices and process standards across analyst and software development teams. His work on ADAC emphasizes clarity, interoperability, and practical implementation for genealogists, developers, and archival practitioners. InnoVadens, LLC serves as the legal steward of the ADAC Standard.

## Document History

- v1.0 — Initial release by Editor (John Vaden); AI-assisted drafting and refinement