# 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 ADAC Specification for version 0.9.0-draft.1.

> **Status: Draft**
> This profile is functionally complete but has not yet undergone
> jurisdictional legal review. It is released for evaluation, testing,
> and community feedback. Breaking changes may occur before the 1.0.0
> legal-stable release.

InnoVadens, LLC is the steward of this specification.

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 0.9.0-draft.1 — Draft release for evaluation, testing, and community feedback pending jurisdictional legal review.

# ADAC-Legal v0.9.0 — Legal Document 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.

*This specification defines metadata structures for representing legal documents and their provenance. It does not provide legal advice, does not interpret law, and does not establish legal authority. Users should consult qualified legal professionals for legal guidance.*

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

---

## Abstract

The **ADAC-Legal** profile defines a domain-specific metadata extension for the [ADAC 1.0](../../ADAC/spec/ADAC-Format-Specification.md) container format, designed for the long-term preservation, chain-of-custody tracking, and confidentiality management of legal documents — tribunal exhibits, court filings, contracts, witness statements, judicial orders, sworn instruments, and other records produced or received during legal proceedings. The profile adds matter references, document classification with sequential production numbering and confidentiality levels, chain of custody, retention policies, legal privilege logging, preservation hold notices, production tracking, and per-region exhibit and redaction annotations — all without modifying the core ADAC specification.

This profile is designed to be **jurisdiction-neutral at its base**. It defines the concepts, schema structures, and controlled vocabulary values that are meaningful across major world legal traditions — common law, civil law, mixed, and religious law systems. Jurisdiction-specific terminology, document types, procedural concepts, and regulatory references are defined in companion jurisdiction profile specifications (such as ADAC-Legal-US, ADAC-Legal-UK, ADAC-Legal-DE) and are not part of this document.

---

## Table of Contents

1. [Introduction](#1-introduction)
2. [Conformance](#2-conformance)
3. [Terminology](#3-terminology)
4. [Legal Tradition Compatibility](#4-legal-tradition-compatibility)
5. [Relationship to ADAC](#5-relationship-to-adac)
6. [Container Format](#6-container-format)
7. [Legal Profile — `metadata/profiles/legal.json`](#7-legal-profile)
8. [Jurisdiction Profiles](#8-jurisdiction-profiles)
9. [Matter Reference](#9-matter-reference)
10. [Document Classification](#10-document-classification)
11. [Chain of Custody](#11-chain-of-custody)
12. [Legal Privilege](#12-legal-privilege)
13. [Preservation Holds](#13-preservation-holds)
14. [Production Tracking](#14-production-tracking)
15. [Region Linked Entities](#15-region-linked-entities)
16. [Exhibit Annotation — `legal:exhibit`](#16-exhibit-annotation)
17. [Redaction Annotation — `legal:redaction`](#17-redaction-annotation)
18. [Privilege Annotation — `legal:privilege`](#18-privilege-annotation)
19. [Confidentiality and Access Control](#19-confidentiality-and-access-control)
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

Legal document management demands meticulous tracking of provenance, confidentiality, and evidentiary integrity across every legal tradition. Documents submitted to a tribunal must be numbered and classified. Redactions must be documented with the legal authority that authorized them. Chain of custody must be recorded from the moment a document is received through every transfer, scan, and storage event. Retention obligations must be tracked alongside preservation directives. Legal privilege determinations must be logged. Productions or disclosures must be tracked across multiple counsel and parties.

All of this context must travel with the document — not in a separate database that could become disconnected when systems are migrated, decommissioned, or lost. Worse, in contested proceedings, an opposing party may challenge the authenticity of a digital document and demand evidence that it has not been tampered with since collection. Without a cryptographically verifiable chain of custody, that challenge can be difficult to rebut.

### 1.2 Solution

ADAC-Legal solves this by embedding legal context directly into the archival container alongside the document, leveraging ADAC 1.0's built-in cryptographic features:

- **Matter reference** — matter number, tribunal, jurisdiction, docket identifier, matter caption, and named parties.
- **Document classification** — document type, exhibit or production identifier, filing date, confidentiality level, and sequential production numbering range.
- **Chain of custody** — chronological record of every person or entity that handled the artifact, from receipt through processing and storage, with optional cryptographic attestation at each handoff.
- **Legal privilege** — explicit determinations of legal professional privilege, the basis for those determinations, and any waiver events.
- **Preservation holds** — directives that suspend ordinary retention rules (litigation hold, regulatory hold, audit hold), with issuance dates, scope, and release authority.
- **Production tracking** — records of when and to whom a document was disclosed or produced, including production sets and redaction variants.
- **Retention policy** — retention period, expiration date, disposition action, and hold status.
- **Exhibit, redaction, and privilege annotations** — per-region tags marking specific areas on scanned documents.
- **Cryptographic chain of custody** — when used with ADAC's Signed Archival conformance, every significant custody event is cryptographically attestable; the master file checksum proves the underlying document has not been altered.
- **Jurisdiction profiles** — country-specific and subdivision-specific variants (such as ADAC-Legal-US, ADAC-Legal-UK, ADAC-Legal-DE) that extend the base profile with jurisdiction-appropriate document types, matter types, procedural terminology, and regulatory references.

### 1.3 Design Philosophy

| Principle | Description |
|-----------|-------------|
| **ADAC-native** | ADAC-Legal is a pure ADAC profile extension. No core specification modifications are required. Any ADAC reader can open an ADAC-Legal container. |
| **Jurisdiction-neutral base** | The base specification defines concepts and value sets meaningful across common law, civil law, mixed, and religious law systems. US-specific, UK-specific, and other jurisdiction-specific terms belong in companion jurisdiction profiles, not here. |
| **Legal-first** | Every schema element maps to a concept recognized across major legal traditions: document identity, legal professional privilege, custody of evidence, confidentiality, retention obligations, production to opposing parties. |
| **Non-intrusive** | Non-legal ADAC consumers ignore all legal data. Linked entity values survive round-trip serialization unchanged. |
| **Cryptographically grounded** | For evidentiary use, ADAC-Legal containers SHOULD be Signed Archival ADAC containers. Signatures plus hash-chained provenance plus master immutability together provide cryptographic chain of custody. |
| **Confidentiality-aware** | The confidentiality level classification enables automated access control. ADAC-Legal integrates with ADAC's `accessControl` and `EncryptionDescriptor` mechanisms; the legal profile describes the legal basis, not the enforcement mechanism. |
| **Jurisdiction-aware** | Legal systems vary significantly by country and by subdivision. ADAC-Legal supports jurisdiction profiles that extend the base specification with locale-appropriate terminology, document types, and procedural concepts — without fragmenting the core profile. |
| **Multi-profile** | ADAC-Legal containers can coexist with other profiles (such as ADAC-Genealogy). A succession document could carry both a legal profile (matter metadata, custody chain) and a genealogy profile (person annotations, transcriptions). |
| **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 legal profile file schema (`metadata/profiles/legal.json`)
- Matter reference, tribunal jurisdiction, and party schemas
- Document classification, confidentiality, sequential numbering, and retention policy schemas
- Chain-of-custody event schema and its relationship to the ADAC provenance log
- Legal privilege log and preservation hold notice schemas
- Production and disclosure tracking schema
- Per-region linked entity schemas for exhibit, redaction, and privilege annotations
- Guidance on integrating with ADAC `accessControl`, `EncryptionDescriptor`, and signature mechanisms
- Profile-specific validation rules
- Jurisdiction-neutral well-known value sets for document types, confidentiality levels, matter types, custody actions, redaction reasons, privilege categories, and hold types
- The jurisdiction profile mechanism and naming convention for country-specific and subdivision-specific extensions

This specification does **not** define:

- The content of individual jurisdiction profiles (those are defined by companion specifications such as ADAC-Legal-US and ADAC-Legal-UK)
- Jurisdiction-specific document types, procedural terminology, or regulatory citations (such as US Federal Rules, UK Practice Directions, EU GDPR provisions, or German ZPO references — those belong in jurisdiction profiles)
- The ADAC core container format (see the [ADAC 1.0 Format Specification](../../ADAC/spec/ADAC-Format-Specification.md))
- Application-level APIs, programming interfaces, or dependency injection
- User interface requirements for displaying legal data
- Actual encryption or access control enforcement (ADAC-Legal records intent and authority; enforcement is the responsibility of the consuming system)

### 1.5 Audience

This specification is intended for:

- Software developers implementing legal document management features in ADAC readers and writers
- Legal technologists evaluating the format for disclosure management and document production across jurisdictions
- Compliance officers assessing chain-of-custody and retention policy capabilities
- Litigation support and legal operations teams managing exhibit and production numbering workflows
- Standards bodies evaluating the format for adoption across legal traditions

---

## 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 `legal.json` (case-insensitive).
3. That file is valid JSON containing at least the `profileId`, `profileType`, and `profileVersion` fields, with `profileType` equal to `"legal"` and `profileId` equal to `"urn:adac:profile:legal:v1"`.

### 2.2 Recommended Conformance for Evidentiary Use

For documents intended to serve as evidence in legal proceedings, **Signed Archival** conformance is STRONGLY RECOMMENDED. This provides:

- **Cryptographic chain of custody** through CMS signatures applied at each significant handoff (receipt, scan, production, sealing).
- **Tamper-evident provenance** through ADAC's hash-chained provenance log.
- **Document immutability** verifiable by SHA-256 checksum comparison against the recorded master file hash.

Containers used purely for internal document management (where no opposing party will challenge authenticity) MAY use Archival conformance. Minimal conformance is not recommended for legal document workflows.

### 2.3 Forward Compatibility

Readers MUST tolerate unknown JSON properties in all legal 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

The following terms are defined using jurisdiction-neutral language applicable across major world legal systems. Where a term corresponds to a jurisdiction-specific concept (such as "deposition" in US practice or "Schriftsatz" in German practice), the jurisdiction-neutral equivalent is used here; the jurisdiction-specific term appears in the applicable jurisdiction profile.

| Term | Definition |
|------|------------|
| **ADAC-Legal Container** | An ADAC container that includes a legal profile at `metadata/profiles/legal.json`. Uses the standard `.adac` extension. |
| **Matter** | The legal proceeding, case, transaction, or engagement that the archived document belongs to. Equivalent to "case" (common law), "affaire" (French), "Sache" (German), "asunto" (Spanish). |
| **Tribunal** | Any court, arbitral panel, administrative body, or adjudicative forum before which the matter is conducted. Equivalent to "court" (common law), "tribunal" (civil law), "Gericht" (German). |
| **Matter Reference** | Structured identification of the legal matter — matter number, tribunal, jurisdiction, docket identifier, caption, and parties. |
| **Document Classification** | Metadata describing the document type, exhibit or production identifier, confidentiality level, and sequential numbering range. |
| **Sequential Numbering** | Any sequential per-page or per-document numbering system used to uniquely identify documents in a production or disclosure set. Called "Bates numbering" in US practice; equivalent concepts exist in other jurisdictions under various names. |
| **Confidentiality Level** | The access restriction classification applied to the document (`public`, `confidential`, `legallyPrivileged`, `sealed`, etc.). |
| **Chain of Custody** | A chronological record of every person or entity that handled the artifact, establishing an unbroken evidentiary trail. |
| **Cryptographic Chain of Custody** | A chain of custody where each significant transfer is supported by a CMS signature attesting to the container state at that moment. Provided by ADAC Signed Archival conformance. |
| **Retention Policy** | Rules governing how long the document must be preserved and what happens when the retention period expires. |
| **Preservation Hold** | A directive suspending normal document retention or destruction schedules due to pending or anticipated proceedings, regulatory requirements, or audit obligations. Called "litigation hold" in US practice; equivalent concepts exist in other jurisdictions. |
| **Legal Professional Privilege** | The right to withhold from disclosure communications between a legal adviser and client made for the purpose of giving or receiving legal advice, and related litigation materials. Called "attorney-client privilege" and "work-product privilege" in US practice; "legal professional privilege" in UK practice; "Anwaltsgeheimnis" in German practice; "secret professionnel de l'avocat" in French practice. The underlying concepts, though not identical across jurisdictions, are broadly analogous. |
| **Production** | The act of disclosing documents to an opposing party, regulatory body, or tribunal pursuant to a legal obligation. Called "production" or "disclosure" depending on the jurisdiction and context. |
| **Production Set** | A bundle of documents disclosed together, typically sharing a common sequential number prefix and disclosure date. |
| **Exhibit** | A document or item formally introduced into evidence before a tribunal. |
| **Redaction** | The removal or obscuring of specific content from a document prior to disclosure, with the redacted area documented as to reason and authority. |
| **Jurisdiction Profile** | A country-specific or subdivision-specific variant of ADAC-Legal identified by the `jurisdictionProfile` field (such as `"us"`, `"uk"`, `"de"`). Jurisdiction profiles extend the base ADAC-Legal specification with locale-appropriate document types, matter types, procedural terminology, and regulatory references. |

---

## 4. Legal Tradition Compatibility

ADAC-Legal is designed to be usable across the major families of legal systems in the world. This section documents how the base schema maps to each tradition and identifies where jurisdiction profiles are needed to fill gaps.

### 4.1 Common Law Jurisdictions

Common law jurisdictions (United States, United Kingdom, Australia, Canada outside Québec, Ireland, India, Hong Kong, Singapore, and others) share broadly compatible concepts of pleading, disclosure, privilege, and exhibit management, though with significant procedural differences. The base ADAC-Legal schema aligns most naturally with common law practice. Jurisdiction profiles for specific common law jurisdictions address procedural terminology (for example, "disclosure" vs. "discovery", "claimant" vs. "plaintiff", "barrister vs. solicitor" role distinctions).

### 4.2 Civil Law Jurisdictions

Civil law jurisdictions (France, Germany, Italy, Spain, the Netherlands, Japan, South Korea, most of Latin America, Québec, Louisiana, and others) operate under codified statutes rather than case law precedent. Procedural concepts differ significantly: written pleadings (Schriftsatz, conclusions, escrito) rather than oral advocacy, examining magistrates rather than adversarial pre-trial discovery, and notarial instruments as a common document type. The base ADAC-Legal schema uses neutral field names (`tribunal` rather than "court", `matterCaption` rather than "case caption", `documentingProfessional` rather than "attorney") and neutral value set identifiers to maximize civil law applicability. Jurisdiction profiles for civil law jurisdictions add codified document types and adjust procedural terminology.

### 4.3 Mixed Legal System Jurisdictions

Several jurisdictions blend common law and civil law traditions (Scotland, South Africa, Québec, Louisiana, Puerto Rico, Philippines, Sri Lanka). These jurisdictions often need both common law procedural concepts (oral advocacy, cross-examination) and civil law document types (notarial acts, statutory declarations). Jurisdiction profiles for mixed jurisdictions address this duality explicitly.

### 4.4 Religious and Customary Law Jurisdictions

Some jurisdictions incorporate religious law (Sharia in civil matters in several Middle Eastern and Southeast Asian countries) or customary law. The ADAC-Legal base schema does not attempt to model religious or customary law concepts, which vary too widely to generalize. Jurisdiction profiles for these jurisdictions should add the relevant document types and procedural concepts specific to their legal tradition.

### 4.5 The Jurisdiction-Neutral Principle

When in doubt, ADAC-Legal base value sets use the most widely understood neutral term. Where no neutral term commands broad recognition, the base value set uses a descriptive functional label rather than a jurisdiction-specific term.

**Examples of this principle applied:**

| US-Specific Term | UK Term | Neutral Base Value |
|-----------------|---------|-------------------|
| Deposition | Witness statement (written), Examination (oral) | `"witnessStatement"` / `"examiningStatement"` |
| Brief | Skeleton argument / Written submissions | `"writtenSubmissions"` |
| Pleading | Statement of case | `"statementOfCase"` |
| Motion | Application | `"application"` |
| Subpoena | Witness summons | `"witnessSummons"` |
| Bates number | Production number / disclosure reference | Sequential numbering |
| Attorney-client privilege | Legal professional privilege | `"legalProfessionalPrivilege"` |
| Work-product privilege | Litigation privilege | `"litigationPrivilege"` |

---

## 5. Relationship to ADAC

### 5.1 Extension Mechanisms

ADAC-Legal 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/legal.json` and referenced in the manifest's `metadata.profiles` array. Non-legal readers ignore this file entirely.

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

3. **Provenance events** — Legal applications SHOULD append events to ADAC's hash-chained provenance log when significant legal handling actions occur (custody transfer, redaction applied, privilege determination, hold notice issued, document produced). Recommended event type names: `legalCustodyTransfer`, `legalRedaction`, `legalPrivilegeDetermination`, `legalHoldIssued`, `legalHoldReleased`, and `legalProduction`. These appear in the same chronological hash chain as ADAC's built-in events and inherit the same tamper-evident properties.

### 5.2 Optional ADAC Features Used by This Profile

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

| ADAC Feature | Legal Use Case |
|--------------|----------------|
| **`signatures/`** (CMS detached signatures) | Cryptographic chain of custody. Each significant handoff (receipt, scan, production, sealing) SHOULD result in a new container signature. The signature index records purpose and signer identity. |
| **`accessControl`** (per-master, per-derivative, container-level) | Tagging files with confidentiality and embargo information. The legal profile's `confidentialityLevel` records the legal basis; ADAC's `accessControl` records the operational classification for repository systems. |
| **`EncryptionDescriptor`** | Storing privileged or sealed content as ciphertext when the container is shared outside controlled environments. |
| **Hash-chained provenance log** | Tamper-evident audit trail of all custody transfers, redactions, and productions. The chain hash makes it cryptographically detectable if past events are deleted or altered. |
| **`structure.json`** (paged-document sequences) | Generic page ordering for multi-page documents. Useful for productions where sequential numbering follows page order. |

### 5.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 (structure of regions or bounds)
- 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

---

## 6. Container Format

### 6.1 File Extension

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

ADAC-Legal containers use the standard `.adac` extension. The presence of the legal profile is identified by the `profileType` field inside `metadata/profiles/legal.json`, not by the file 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)
│   │   └── ...
│   └── profiles/                           (REQUIRED for this profile)
│       └── legal.json                      (REQUIRED for this profile)
├── derivatives/                            (OPTIONAL — ADAC)
│   └── ...
├── regions/                                (RECOMMENDED for this profile)
│   ├── master-001.regions.json
│   └── ...
├── edits/                                  (OPTIONAL — ADAC)
│   └── ...
├── provenance/                             (REQUIRED for Archival ADAC)
│   ├── log.json                            (hash-chained events)
│   └── checksums.json
└── signatures/                             (OPTIONAL — RECOMMENDED for evidentiary use)
    ├── index.json
    └── *.p7s
```

### 6.3 Manifest Integration

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

A container MAY include multiple profiles simultaneously. A succession or probate document might carry both a legal profile and a genealogy profile:

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

---

## 7. Legal Profile

**Path**: `metadata/profiles/legal.json`
**Status**: REQUIRED for ADAC-Legal containers

The legal profile is the root metadata file for this extension. It uses the standard ADAC 1.0 profile wrapper (Section 13.2 of the ADAC core specification) to declare its identity, then carries legal-specific content under the `data` field.

### 7.1 Schema

```json
{
  "profileId": "urn:adac:profile:legal:v1",
  "profileType": "legal",
  "profileVersion": "1.0.0",
  "title": "ADAC Legal Profile",
  "schema": "https://adac.example.org/schemas/legal-v1.json",
  "data": {
    "jurisdictionProfile": "uk",
    "matterReference": { ... },
    "classification": { ... },
    "custodyChain": [ ... ],
    "privilegeLog": [ ... ],
    "holdNotices": [ ... ],
    "productions": [ ... ]
  }
}
```

### 7.2 Profile Wrapper Fields

| Field | Type | Required | Value | Description |
|-------|------|----------|-------|-------------|
| `profileId` | `string` | REQUIRED | `"urn:adac:profile:legal:v1"` | URN identifying this specific profile and version. |
| `profileType` | `string` | REQUIRED | `"legal"` | The profile type identifier. MUST be `"legal"`. |
| `profileVersion` | `string` | REQUIRED | `"1.0.0"` for this spec | Semantic version (MAJOR.MINOR.PATCH). |
| `title` | `string` | OPTIONAL | — | Human-readable title for display. |
| `schema` | `string` | OPTIONAL | — | URI of a JSON Schema document that validates the `data` subobject. |
| `data` | `LegalData` | OPTIONAL | — | The legal-specific payload. See Section 7.3. |

### 7.3 LegalData Fields

| Field | Type | Required | Default | Description |
|-------|------|----------|---------|-------------|
| `jurisdictionProfile` | `string` | OPTIONAL | `null` | Identifies a country-specific or subdivision-specific jurisdiction profile (see [Section 8](#8-jurisdiction-profiles)). When absent, only the base ADAC-Legal schema and value sets apply. |
| `matterReference` | `MatterReference` | OPTIONAL | `null` | Legal matter identification (see [Section 9](#9-matter-reference)). |
| `classification` | `DocumentClassification` | OPTIONAL | `null` | Document type, confidentiality, and sequential numbering (see [Section 10](#10-document-classification)). |
| `custodyChain` | `CustodyEntry[]` | OPTIONAL | `null` | Chronological chain-of-custody entries (see [Section 11](#11-chain-of-custody)). |
| `privilegeLog` | `PrivilegeEntry[]` | OPTIONAL | `null` | Legal privilege determinations (see [Section 12](#12-legal-privilege)). |
| `holdNotices` | `HoldNotice[]` | OPTIONAL | `null` | Preservation hold notices (see [Section 13](#13-preservation-holds)). |
| `productions` | `Production[]` | OPTIONAL | `null` | Disclosure and production records (see [Section 14](#14-production-tracking)). |

### 7.4 Forward Compatibility

Unknown JSON properties at any level (within the wrapper or within `data`) MUST be preserved during round-trip serialization.

---

## 8. Jurisdiction Profiles

Legal systems vary dramatically across countries and subdivisions. ADAC-Legal addresses this through **jurisdiction profiles** — named variants that extend the base specification with country-specific or subdivision-specific terminology, well-known value sets, and procedural concepts.

### 8.1 Mechanism

The `jurisdictionProfile` field in the legal profile data identifies which jurisdiction variant applies to this container. When present, it signals to consuming applications that jurisdiction-specific document types, matter types, and procedural concepts MAY appear in the container's metadata.

When `jurisdictionProfile` is absent or `null`, the container uses only the base ADAC-Legal schema and value sets defined in this specification.

### 8.2 Naming Convention

Jurisdiction profile identifiers follow a hierarchical, hyphen-delimited naming convention based on ISO 3166 codes:

```
{country}
{country}-{subdivision}
```

| Identifier | Full Name | Legal Tradition |
|------------|-----------|----------------|
| `"us"` | ADAC-Legal-US | United States — common law (federal and most states) |
| `"uk"` | ADAC-Legal-UK | United Kingdom — common law (England & Wales; Scotland and Northern Ireland may further specialize) |
| `"au"` | ADAC-Legal-AU | Australia — common law |
| `"ca"` | ADAC-Legal-CA | Canada — common law (further specializes to `"ca-qc"` for Québec civil law) |
| `"de"` | ADAC-Legal-DE | Germany — civil law (ZPO procedure) |
| `"fr"` | ADAC-Legal-FR | France — civil law (CPC procedure) |
| `"nl"` | ADAC-Legal-NL | Netherlands — civil law |
| `"es"` | ADAC-Legal-ES | Spain — civil law |
| `"jp"` | ADAC-Legal-JP | Japan — civil law |
| `"sg"` | ADAC-Legal-SG | Singapore — common law |
| `"us-la"` | ADAC-Legal-US-LA | Louisiana, USA — civil law tradition within a common law country |
| `"us-pr"` | ADAC-Legal-US-PR | Puerto Rico — civil law tradition, bilingual system |
| `"ca-qc"` | ADAC-Legal-CA-QC | Québec, Canada — civil law tradition within a common law country |

Additional jurisdiction profiles MAY be defined by companion specifications following this naming convention.

### 8.3 Inheritance Model

Jurisdiction profiles follow an **additive inheritance** model:

1. **Base layer** — The ADAC-Legal specification (this document) defines the core schema and base well-known value sets. Every jurisdiction profile inherits all base fields and values.

2. **Country layer** — A country-level jurisdiction profile (such as `"de"`) MAY add jurisdiction-specific values to existing well-known value sets, define additional linked entity types specific to the jurisdiction, and provide country-specific guidance on populating base fields.

3. **Subdivision layer** — A subdivision-level profile (such as `"us-la"`) inherits from its country layer and MAY further specialize with subdivision-specific document types and terminology.

Jurisdiction profiles MUST NOT remove or redefine base ADAC-Legal fields, remove base well-known values, change the meaning of base fields, or modify the ADAC core specification.

### 8.4 When to Create a Jurisdiction Profile

A jurisdiction profile is warranted when a legal system has **structural differences** that cannot be adequately represented by the base well-known value sets:

| Condition | Example |
|-----------|---------|
| Distinct legal tradition | Louisiana (civil law in a common law country), Québec, Scotland (mixed). |
| Unique document types | Notarial acts (civil law), statutory declarations (UK/AU/CA), Schriftsatz (Germany), huissier-served process (France). |
| Different procedural terminology | "Parish" vs. "county", "pursuer" vs. "claimant" (Scotland), "Schuldner" vs. "defendant". |
| Jurisdiction-specific regulatory framework | GDPR data protection obligations (EU), Civil Procedure Rules (UK), Federal Rules of Civil Procedure (US). |

A jurisdiction profile is **not** warranted for minor terminological preferences that can be handled by free-text fields or custom values in existing value sets.

### 8.5 Interoperability Across Jurisdiction Profiles

- An application that understands only the base ADAC-Legal specification can process any jurisdiction profile container — jurisdiction-specific values appear as ordinary strings in well-known value set fields.
- An application that understands `"ca"` but not `"ca-qc"` can process a Québec container — it will recognize all base and Canadian-level values.
- Cross-jurisdiction document collections (such as a multinational arbitration matter) MAY contain containers with different jurisdiction profiles. Applications SHOULD handle mixed-jurisdiction collections gracefully.

---

## 9. Matter Reference

The matter reference identifies the legal matter or proceeding that the archived document belongs to, enabling retrieval, indexing, and compliance tracking across large document collections. The term "matter" is used in preference to "case" because it accommodates transactional, regulatory, and advisory work alongside contentious proceedings.

### 9.1 Schema

```json
{
  "matterReference": {
    "matterNumber": "2026-LIT-04521",
    "tribunalName": "Commercial Court, King's Bench Division",
    "jurisdiction": {
      "country": "GB",
      "subdivision": "England and Wales"
    },
    "docketIdentifier": null,
    "matterType": "litigation",
    "matterCaption": "Acme Ltd v. Brixton Holdings plc",
    "parties": [
      {
        "name": "Acme Ltd",
        "role": "claimant",
        "legalRepresentative": "Freshfields Bruckhaus Deringer LLP"
      },
      {
        "name": "Brixton Holdings plc",
        "role": "defendant",
        "legalRepresentative": "Clifford Chance LLP"
      }
    ],
    "relatedMatters": [
      {
        "matterNumber": "2025-ARB-00881",
        "relationship": "predecessorOf",
        "containerId": "550e8400-e29b-41d4-a716-446655440099",
        "note": "Arbitration that preceded current court proceedings."
      }
    ]
  }
}
```

### 9.2 Matter Reference Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `matterNumber` | `string` | OPTIONAL | Matter or file number assigned by the tribunal or firm. |
| `tribunalName` | `string` | OPTIONAL | Name of the tribunal (court, arbitral panel, administrative body). |
| `jurisdiction` | `Jurisdiction` | OPTIONAL | Geographic and legal jurisdiction of the matter (see [Section 9.3](#93-jurisdiction)). |
| `docketIdentifier` | `string` | OPTIONAL | Docket or cause number, if distinct from the matter number. |
| `matterType` | `string` | OPTIONAL | Type of legal matter. See [Section 20.3](#203-matter-types) for well-known values. |
| `matterCaption` | `string` | OPTIONAL | Matter caption or title (such as "Acme Ltd v. Brixton Holdings plc"). |
| `parties` | `Party[]` | OPTIONAL | Named parties and their roles. See [Section 9.4](#94-party). |
| `relatedMatters` | `RelatedMatter[]` | OPTIONAL | Other matters related to this one. See [Section 9.5](#95-related-matters). |

### 9.3 Jurisdiction

Describes the geographic and legal jurisdiction of the matter.

```json
{
  "country": "GB",
  "subdivision": "England and Wales",
  "localUnit": "London"
}
```

| Field | Type | Description |
|-------|------|-------------|
| `country` | `string` | The country. ISO 3166-1 alpha-2 code RECOMMENDED (such as `"US"`, `"GB"`, `"DE"`, `"FR"`, `"JP"`). |
| `subdivision` | `string` | State, province, Bundesland, région, or equivalent administrative division. ISO 3166-2 code or free text. |
| `localUnit` | `string` | City, county, Landkreis, département, or equivalent local unit. Free text. |

All fields are OPTIONAL. Populate only the levels relevant to the matter's jurisdiction.

### 9.4 Party

Identifies a named party in the legal matter.

```json
{
  "name": "Acme Ltd",
  "role": "claimant",
  "legalRepresentative": "Freshfields Bruckhaus Deringer LLP"
}
```

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `name` | `string` | REQUIRED | The party's name (individual or entity). |
| `role` | `string` | OPTIONAL | The party's role in the proceedings. Jurisdiction-neutral well-known values: `"claimant"`, `"defendant"`, `"petitioner"`, `"respondent"`, `"appellant"`, `"appellee"`, `"applicant"`, `"intervenor"`, `"thirdParty"`. Jurisdiction profiles MAY add jurisdiction-specific role values. |
| `legalRepresentative` | `string` | OPTIONAL | Name of the law firm, barrister's chambers, Rechtsanwaltskanzlei, cabinet d'avocats, or other legal representative acting for this party. |

### 9.5 Related Matters

Matters are often related to other proceedings — consolidated, severed, appealed, remanded, or part of a multi-party arbitration or regulatory inquiry. The `relatedMatters` array captures these relationships.

```json
{
  "matterNumber": "2025-ARB-00881",
  "relationship": "predecessorOf",
  "containerId": "550e8400-e29b-41d4-a716-446655440099",
  "note": "Arbitration that preceded current court proceedings."
}
```

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `matterNumber` | `string` | REQUIRED | The related matter's reference number. |
| `relationship` | `string` | OPTIONAL | The relationship type. Well-known values: `"consolidatedWith"`, `"severedFrom"`, `"appealOf"`, `"remandFrom"`, `"relatedTo"`, `"successorTo"`, `"predecessorOf"`, `"multiPartyMember"`. |
| `containerId` | `string` | OPTIONAL | UUID of an ADAC container holding records for the related matter. When present, MUST be a valid UUID (RFC 4122) matching the manifest `id` of the referenced container. |
| `note` | `string` | OPTIONAL | Free-text explanation of the relationship. |

---

## 10. Document Classification

Document classification describes the document type, exhibit or production identification, confidentiality level, sequential numbering, and retention policy.

### 10.1 Schema

```json
{
  "classification": {
    "documentType": "courtFiling",
    "exhibitIdentifier": "Claimant's Bundle Tab C",
    "filingDate": "2026-03-15T00:00:00Z",
    "confidentialityLevel": "confidential",
    "sequentialNumberStart": "ACM000123",
    "sequentialNumberEnd": "ACM000125",
    "retentionPolicy": {
      "period": "7 years after matter closure",
      "expiresOn": null,
      "disposition": "review",
      "holdActive": true
    }
  }
}
```

### 10.2 Document Classification Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `documentType` | `string` | OPTIONAL | The document type. See [Section 20.1](#201-document-types) for well-known values. |
| `exhibitIdentifier` | `string` | OPTIONAL | Exhibit identifier, bundle tab reference, or similar formal designation (such as `"Exhibit A"`, `"Claimant's Bundle Tab C"`, `"Anlage K1"`, `"Pièce adverse No. 3"`). |
| `filingDate` | `string` | OPTIONAL | Date the document was filed with the tribunal or received by the firm (ISO-8601). |
| `confidentialityLevel` | `string` | OPTIONAL | Access restriction level. See [Section 20.2](#202-confidentiality-levels) for well-known values. See [Section 19](#19-confidentiality-and-access-control) for the relationship to ADAC's `accessControl` mechanism. |
| `sequentialNumberStart` | `string` | OPTIONAL | Beginning of the sequential production number range (such as `"ACM000123"`, `"SHP-000042"`). This is a jurisdiction-neutral generalization of Bates numbering. |
| `sequentialNumberEnd` | `string` | OPTIONAL | End of the sequential production number range. |
| `retentionPolicy` | `RetentionPolicy` | OPTIONAL | Retention period, disposition, and hold status. |

### 10.3 Retention Policy

Describes the rules governing how long the document must be preserved.

```json
{
  "period": "7 years after matter closure",
  "expiresOn": null,
  "disposition": "review",
  "holdActive": true
}
```

| Field | Type | Required | Default | Description |
|-------|------|----------|---------|-------------|
| `period` | `string` | OPTIONAL | `null` | Human-readable retention period (such as `"7 years"`, `"permanent"`, `"6 years from transaction close"`). |
| `expiresOn` | `string` | OPTIONAL | `null` | ISO-8601 date when the retention period expires. `null` when indefinite or not yet calculated. |
| `disposition` | `string` | OPTIONAL | `null` | Action when the period expires: `"destroy"`, `"review"`, `"archive"`, `"transfer"`. |
| `holdActive` | `boolean` | OPTIONAL | `null` | When `true`, destruction is suspended regardless of the retention period. This is a summary boolean; for tracking multiple overlapping holds use the `holdNotices` array (Section 13). |

### 10.4 Sequential Numbering Notes

Sequential numbering (called "Bates numbering" in US practice and known by various names or conventions in other jurisdictions) is used to uniquely identify every page in a production or disclosure set.

- Sequential numbers are assigned externally during production. ADAC-Legal records the assigned range — it does not generate sequential numbers.
- For a single-page document, `sequentialNumberStart` and `sequentialNumberEnd` SHOULD be the same value.
- A document MAY be numbered differently for different productions. Each numbering belongs in its corresponding `productions[]` entry (Section 14). The `classification` fields reflect the primary or original numbering.

---

## 11. Chain of Custody

The chain of custody provides a chronological, unbroken record of every person or entity that handled the artifact. This documentation is essential for establishing admissibility of evidence and demonstrating that the document was not tampered with between collection and production.

### 11.1 Schema

```json
{
  "custodyChain": [
    {
      "id": "custody-001",
      "action": "received",
      "custodian": "A. Blackwell, Solicitor",
      "timestamp": "2026-03-15T09:00:00Z",
      "organization": "Freshfields Bruckhaus Deringer LLP",
      "signatureRef": "signatures/container-ingest.p7s",
      "notes": "Original contract received from client by hand delivery."
    },
    {
      "id": "custody-002",
      "action": "scanned",
      "custodian": "Litigation Support",
      "timestamp": "2026-03-16T14:30:00Z",
      "organization": "Freshfields Bruckhaus Deringer LLP",
      "notes": "Scanned at 600 DPI, TIFF format, flatbed scanner."
    },
    {
      "id": "custody-003",
      "action": "stored",
      "custodian": "Records Management",
      "timestamp": "2026-03-16T16:00:00Z",
      "organization": "Freshfields Bruckhaus Deringer LLP",
      "signatureRef": "signatures/container-archived.p7s",
      "notes": "Physical original placed in locked document store."
    }
  ]
}
```

### 11.2 Custody Entry Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `id` | `string` | REQUIRED | Unique identifier for this custody entry within the container. |
| `action` | `string` | REQUIRED | The custody action performed. See [Section 20.4](#204-custody-actions) for well-known values. |
| `custodian` | `string` | REQUIRED | Name of the person or entity who performed or received custody. |
| `timestamp` | `string` | REQUIRED | ISO-8601 timestamp of when the action occurred. |
| `organization` | `string` | OPTIONAL | Firm, court office, or organization associated with the custodian. |
| `signatureRef` | `string` | OPTIONAL | Container-relative path to a signature file (in `signatures/`) that cryptographically attests to the container state at the moment of this custody event. References the `file` field in `signatures/index.json`. |
| `notes` | `string` | OPTIONAL | Free-text notes describing the event. |

### 11.3 Cryptographic Chain of Custody

For evidentiary use, ADAC-Legal RECOMMENDS that significant custody events be supported by container signatures:

1. When a significant custody event occurs (receipt, scan, production handoff), the holding party re-saves the container following the ADAC write-order procedure (Section 16.6 of the ADAC core specification).
2. The save includes a new CMS signature in `signatures/`, listed in `signatures/index.json` with a `purpose` value describing the custody event.
3. The new custody entry's `signatureRef` field references the path of the signature file.
4. The signature attests to the state of `manifest.json` and `provenance/checksums.json` at that moment, which transitively attests to every file in the container including the master.

This produces a chain of custody where every link is cryptographically verifiable. An opposing party challenging authenticity can verify each signature against the holding party's certificate chain. Tampering between custody events is detectable as a checksum mismatch or signature failure.

### 11.4 Relationship to ADAC Provenance Log

The chain of custody and the ADAC provenance log (`provenance/log.json`) serve complementary but distinct purposes:

| Aspect | Chain of Custody | Provenance Log |
|--------|------------------|----------------|
| **Records** | Legal handling of the physical or logical document | Technical actions on the ADAC container |
| **Audience** | Legal professionals, tribunals, compliance officers | Software developers, archivists |
| **Examples** | "Received from instructing client", "Produced to opposing solicitors" | `"scan"`, `"import"`, `"derivativeCreated"`, `"save"` |
| **Scope** | May predate container creation | Begins at container creation |
| **Tamper-evidence** | Indirect — relies on container signatures and checksums | Direct — events are linked in a hash chain |

Both SHOULD be populated when applicable. Implementations SHOULD also append a `legalCustodyTransfer` event to the provenance log when adding a custody chain entry, so the legal action appears in the cryptographically chained event log.

### 11.5 Custody Chain Guidelines

- Custody entries SHOULD be in **chronological order** (earliest first).
- Every significant handoff — including internal transfers within the same organization — SHOULD be recorded.
- The `notes` field SHOULD include specifics that support admissibility: receipt references, storage locations, scanner details, witness names.
- When the container is signed at a custody event, the corresponding entry SHOULD include `signatureRef`.

---

## 12. Legal Privilege

Legal privilege (called "attorney-client privilege" and "work-product privilege" in the US, "legal professional privilege" in the UK and Australia, "secret professionnel" in France, "Anwaltsgeheimnis" in Germany) is recognized across major world legal traditions, though its exact scope and sub-categories vary. The privilege log records explicit determinations of privilege, the legal basis for those determinations, and any waiver or disclosure events.

### 12.1 Schema

```json
{
  "privilegeLog": [
    {
      "id": "priv-001",
      "claim": "legalProfessionalPrivilege",
      "basis": "Communication between A. Blackwell (solicitor) and Acme Ltd (client) dated 2026-03-10, seeking legal advice on contract interpretation.",
      "claimedBy": "Freshfields Bruckhaus Deringer LLP",
      "claimedOn": "2026-04-01T10:00:00Z",
      "scope": "fullDocument",
      "waivedOn": null,
      "waiverBasis": null
    }
  ]
}
```

### 12.2 Privilege Log Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `id` | `string` | REQUIRED | Unique identifier for this privilege entry within the container. |
| `claim` | `string` | REQUIRED | The privilege claimed. See [Section 20.5](#205-privilege-categories) for well-known values. |
| `basis` | `string` | OPTIONAL | Free-text description of the factual and legal basis for the privilege claim. |
| `claimedBy` | `string` | OPTIONAL | Person or firm asserting the privilege. |
| `claimedOn` | `string` | OPTIONAL | ISO-8601 timestamp of when the claim was asserted. |
| `scope` | `string` | OPTIONAL | Scope of the claim: `"fullDocument"` (entire document is privileged), `"partialRedacted"` (some areas redacted; see `legal:privilege` annotations on regions), `"metadataOnly"` (metadata only is privileged, document contents are producible). |
| `waivedOn` | `string` | OPTIONAL | ISO-8601 timestamp if the privilege has been waived or lost. |
| `waiverBasis` | `string` | OPTIONAL | Free-text description of the waiver or loss of privilege (voluntary disclosure, court-ordered production, inadvertent disclosure, common interest waiver). |

---

## 13. Preservation Holds

Preservation holds document directives that suspend ordinary retention or destruction schedules. A single document may be subject to multiple overlapping holds (pending litigation, regulatory inquiry, and internal audit simultaneously), which is why `holdNotices` is an array rather than a single boolean.

### 13.1 Schema

```json
{
  "holdNotices": [
    {
      "id": "hold-001",
      "holdType": "litigation",
      "matterReference": "Acme Ltd v. Brixton Holdings plc, 2026-LIT-04521",
      "issuedBy": "A. Blackwell, Solicitor, Freshfields Bruckhaus Deringer LLP",
      "issuedOn": "2026-02-01T00:00:00Z",
      "scope": "All contracts and correspondence with Brixton Holdings plc from 2024-01-01 onward.",
      "releasedOn": null,
      "releaseAuthority": null,
      "notes": "Hold issued upon receipt of claim letter."
    }
  ]
}
```

### 13.2 Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `id` | `string` | REQUIRED | Unique identifier for this hold notice within the container. |
| `holdType` | `string` | REQUIRED | The type of hold. See [Section 20.6](#206-hold-types) for well-known values. |
| `matterReference` | `string` | OPTIONAL | Free-text reference to the matter or proceeding triggering the hold. |
| `issuedBy` | `string` | OPTIONAL | Person or entity who issued the hold notice. |
| `issuedOn` | `string` | OPTIONAL | ISO-8601 timestamp of when the hold was issued. |
| `scope` | `string` | OPTIONAL | Free-text description of the documents covered by the hold. |
| `releasedOn` | `string` | OPTIONAL | ISO-8601 timestamp if the hold has been released. `null` if still active. |
| `releaseAuthority` | `string` | OPTIONAL | Free-text description of who authorized the release and on what basis. |
| `notes` | `string` | OPTIONAL | Free-text notes about the hold. |

### 13.3 Hold Notices and Retention Policy

When any active hold notice exists for a document (`releasedOn` is `null`), destruction MUST NOT occur regardless of the `retentionPolicy.period` or `retentionPolicy.expiresOn` values. The `retentionPolicy.holdActive` boolean is a convenience summary.

Implementations SHOULD set `retentionPolicy.holdActive` to `true` when at least one hold notice has `releasedOn: null`, and to `false` when all holds have been released.

---

## 14. Production Tracking

In legal proceedings, the same document may be disclosed or produced multiple times — to different parties, in different forms (with or without certain redactions), under different production rounds, with different sequential numbering. The `productions` array records these disclosure events.

### 14.1 Schema

```json
{
  "productions": [
    {
      "id": "prod-001",
      "productionSetId": "Acme v. Brixton - Disclosure Set 1",
      "producedOn": "2026-04-15T00:00:00Z",
      "producedBy": "Freshfields Bruckhaus Deringer LLP",
      "producedTo": "Clifford Chance LLP (for Brixton Holdings plc)",
      "sequentialNumberStart": "ACM000123",
      "sequentialNumberEnd": "ACM000125",
      "redactionVariant": "deriv_redacted_001",
      "notes": "First disclosure set. Redacted version produced per Disclosure Protocol Order dated 2026-03-01."
    }
  ]
}
```

### 14.2 Production Entry Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `id` | `string` | REQUIRED | Unique identifier for this production record within the container. |
| `productionSetId` | `string` | OPTIONAL | Identifier of the production set or disclosure batch this document belongs to. |
| `producedOn` | `string` | OPTIONAL | ISO-8601 timestamp of when the production was made. |
| `producedBy` | `string` | OPTIONAL | Person, firm, or organization that produced the document. |
| `producedTo` | `string` | OPTIONAL | Recipient of the production (opposing party, regulatory body, tribunal). |
| `sequentialNumberStart` | `string` | OPTIONAL | Sequential number assigned in this specific production (may differ from `classification.sequentialNumberStart`). |
| `sequentialNumberEnd` | `string` | OPTIONAL | End of the sequential number range for this production. |
| `redactionVariant` | `string` | OPTIONAL | The `id` of the derivative file in the manifest that represents the redacted version produced. `null` if the unredacted master was produced. |
| `notes` | `string` | OPTIONAL | Free-text notes about this production event. |

---

## 15. Region Linked Entities

ADAC-Legal stores per-region legal data in the ADAC region `linkedEntities` dictionary — a JSON object on each region where keys are namespaced strings and values are arbitrary JSON objects.

### 15.1 Linked Entity Keys

| Key | Description |
|-----|-------------|
| `legal:exhibit` | Exhibit identification and marking (see [Section 16](#16-exhibit-annotation)). |
| `legal:redaction` | Redaction reason, authority, and notes (see [Section 17](#17-redaction-annotation)). |
| `legal:privilege` | Per-region privilege annotation for partial-document privilege claims (see [Section 18](#18-privilege-annotation)). |

### 15.2 Round-Trip Safety

Non-legal consumers that read a container and write it back MUST preserve all linked entity data. Because the ADAC core treats `linkedEntities` values as opaque JSON objects, no legal data is lost during round-trip serialization by tools that do not understand the legal namespace.

### 15.3 Multiple Entities per Region

A single region MAY have multiple linked entities simultaneously. For example, a bounding box around a paragraph that is both a privileged communication and has been redacted could have both a `legal:privilege` entity and a `legal:redaction` entity. Legal linked entities coexist with linked entities from other profiles without conflict.

---

## 16. Exhibit Annotation

**Linked Entity Key**: `legal:exhibit`

Exhibit annotations tag a bounding-box region on a scanned document as an exhibit marker, label, or sticker area. This allows applications to locate exhibit tags within multi-page productions programmatically.

### 16.1 Schema

```json
{
  "exhibitId": "Claimant's Bundle Tab C",
  "description": "Signed contract dated 2024-03-15",
  "markedOn": "2026-04-01T10:00:00Z",
  "introducedBy": "Claimant"
}
```

### 16.2 Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `exhibitId` | `string` | REQUIRED | The exhibit identifier (such as `"Exhibit A"`, `"Claimant's Bundle Tab C"`, `"Defense 7"`, `"Anlage K1"`). |
| `description` | `string` | OPTIONAL | Human-readable description of the exhibit. |
| `markedOn` | `string` | OPTIONAL | ISO-8601 timestamp of when the exhibit was marked or admitted. |
| `introducedBy` | `string` | OPTIONAL | The party or representative who introduced the exhibit (such as `"Claimant"`, `"Defence Counsel"`). |

### 16.3 Usage Guidelines

- The `exhibitId` SHOULD match the `classification.exhibitIdentifier` in the profile when the entire document is a single exhibit.
- For documents containing multiple exhibit stickers (such as a deposition transcript with several marked exhibits), each sticker region gets its own `legal:exhibit` entity with a distinct `exhibitId`.
- The `description` SHOULD be sufficient for a reviewer to identify the exhibit without opening the document.

---

## 17. Redaction Annotation

**Linked Entity Key**: `legal:redaction`

Redaction annotations record that a specific region on a scanned document has been redacted, including the reason, legal authority, and the person who authorized the redaction. The annotation does not perform the actual redaction — the visual redaction (black box, white-out, etc.) exists in the stored image or derivative. This metadata records **why** the region was redacted and under whose authority, enabling compliance auditing.

### 17.1 Schema

```json
{
  "reason": "personalData",
  "authority": "Protective Order dated 2026-01-10",
  "authorizedBy": "A. Blackwell, Solicitor",
  "appliedToDerivativeIds": ["deriv_redacted_001"],
  "redactedOn": "2026-04-01T08:30:00Z",
  "notes": "Home address of individual witness — redacted per Protective Order ¶ 4(b)."
}
```

### 17.2 Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `reason` | `string` | REQUIRED | The reason for the redaction. See [Section 20.7](#207-redaction-reasons) for well-known values. |
| `authority` | `string` | OPTIONAL | The legal authority or basis (such as `"Protective Order dated 2026-01-10"`, `"GDPR Art. 17"`, `"CPR r. 31.22"`). |
| `authorizedBy` | `string` | OPTIONAL | Person or entity who authorized the redaction. |
| `appliedToDerivativeIds` | `string[]` | OPTIONAL | Array of derivative file `id` values (from the manifest) on which the visual redaction has been applied. |
| `redactedOn` | `string` | OPTIONAL | ISO-8601 timestamp of when the redaction was applied. |
| `notes` | `string` | OPTIONAL | Free-text notes describing what was redacted. |

### 17.3 Usage Guidelines

- The `reason` field SHOULD use well-known values when applicable to enable automated filtering and compliance reporting.
- The `authority` field SHOULD be specific enough for a reviewer or tribunal to verify the legal basis for the redaction.
- A single document MAY have many redacted regions. Each redacted area gets its own region with its own `legal:redaction` entity.
- Applications SHOULD render redaction annotations as a distinct overlay style (such as black boxes with a "REDACTED" label).

---

## 18. Privilege Annotation

**Linked Entity Key**: `legal:privilege`

Privilege annotations mark specific regions of a document as privileged where the privilege claim does not extend to the entire document (corresponding to `scope: "partialRedacted"` in the `privilegeLog`). This enables per-paragraph or per-section privilege mapping.

### 18.1 Schema

```json
{
  "privilegeLogId": "priv-001",
  "claim": "legalProfessionalPrivilege",
  "notes": "Paragraph 3 contains legal advice from solicitor; remainder of document is producible."
}
```

### 18.2 Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `privilegeLogId` | `string` | OPTIONAL | The `id` of the corresponding `privilegeLog` entry in the profile. Links this region annotation to its privilege determination. |
| `claim` | `string` | REQUIRED | The privilege claim applying to this region. SHOULD match the `claim` value of the referenced `privilegeLog` entry. See [Section 20.5](#205-privilege-categories) for well-known values. |
| `notes` | `string` | OPTIONAL | Free-text explanation of why this specific region is privileged. |

---

## 19. Confidentiality and Access Control

### 19.1 The Two-Layer Model

ADAC-Legal uses a two-layer approach to confidentiality:

1. **Legal classification** (`classification.confidentialityLevel` in the legal profile) — Records the legal designation of the document as a whole. This is informational metadata describing the legal status.

2. **Operational access control** (ADAC's `accessControl` mechanism) — Enforces access at the file level within the container, controlling which parts of the container are readable by different classes of reader.

The legal profile records intent and authority. The ADAC `accessControl` mechanism provides the enforcement hook for consuming systems.

### 19.2 Mapping Confidentiality Levels to Access Control

| Legal Classification | Recommended `accessControl` Action |
|---------------------|-------------------------------------|
| `"public"` | No restriction. |
| `"confidential"` | Restrict to authorized recipients. Tag master and derivatives accordingly. |
| `"legallyPrivileged"` | Restrict to privileged recipients. Consider `EncryptionDescriptor` for containers shared outside counsel. |
| `"sealed"` | Restrict to court-authorized recipients. `EncryptionDescriptor` STRONGLY RECOMMENDED. |
| `"restricted"` | Restrict per specific conditions defined in `notes`. |

### 19.3 Encryption for Privileged Content

When a container containing privileged or sealed content must be transmitted or stored outside controlled environments, the ADAC `EncryptionDescriptor` mechanism provides a way to store the master file as pre-encrypted ciphertext. The legal profile describes the legal basis for confidentiality; the `EncryptionDescriptor` provides the technical means of protecting the content.

---

## 20. Well-Known Value Sets

ADAC-Legal defines controlled vocabularies for several fields. Implementations SHOULD use these well-known values when applicable but MAY use custom values for domain-specific or jurisdiction-specific needs. All values use `camelCase` strings.

The value sets defined in this section are the **base** values available to all ADAC-Legal containers regardless of jurisdiction. Jurisdiction profiles (see [Section 8](#8-jurisdiction-profiles)) MAY extend these value sets with additional jurisdiction-specific values. Jurisdiction profiles MUST NOT remove or redefine base values.

### 20.1 Document Types

Used in `classification.documentType`.

| Value | Description |
|-------|-------------|
| `"exhibit"` | A document formally introduced as evidence before a tribunal. |
| `"courtFiling"` | A document filed with a court or tribunal (petition, complaint, statement of case). |
| `"statementOfCase"` | A pleading or statement of case defining the issues in dispute. |
| `"application"` | An application or motion submitted to the tribunal. |
| `"judicialOrder"` | An order, judgment, or ruling issued by the tribunal. |
| `"correspondence"` | Correspondence between parties, counsel, or the tribunal. |
| `"contract"` | A contract, agreement, or deed. |
| `"testament"` | A will or testamentary instrument. |
| `"witnessStatement"` | A written witness statement or sworn affidavit. |
| `"expertReport"` | An expert witness report or opinion. |
| `"transcript"` | A transcript of oral proceedings (hearing, examination, oral argument). |
| `"writtenSubmissions"` | Written submissions, skeleton arguments, or legal briefs. |
| `"witnessSummons"` | A summons or subpoena compelling testimony or document production. |
| `"notarialAct"` | A notarial act or instrument executed before a notary (civil law jurisdictions). |
| `"regulatoryFiling"` | A document filed with a regulatory body. |
| `"internalMemo"` | An internal memorandum or working document. |

### 20.2 Confidentiality Levels

Used in `classification.confidentialityLevel`.

| Value | Description |
|-------|-------------|
| `"public"` | Public record — no access restrictions. |
| `"confidential"` | Restricted access under a protective order, confidentiality agreement, or professional obligation. |
| `"legallyPrivileged"` | Subject to legal professional privilege — withheld from production unless waived. |
| `"sealed"` | Sealed by tribunal order — access prohibited without court authorization. |
| `"restricted"` | Subject to specific access conditions defined by statute, regulation, or agreement. |

### 20.3 Matter Types

Used in `matterReference.matterType`.

| Value | Description |
|-------|-------------|
| `"litigation"` | Contentious civil or commercial litigation before a court. |
| `"arbitration"` | Arbitration proceedings before an arbitral tribunal. |
| `"mediation"` | Mediation or other alternative dispute resolution. |
| `"transaction"` | Transactional matter (mergers, acquisitions, closings, financing). |
| `"regulatory"` | Regulatory, supervisory, or compliance matter. |
| `"succession"` | Succession, estate administration, or probate. |
| `"familyLaw"` | Family law matter (dissolution, custody, adoption, maintenance). |
| `"criminal"` | Criminal defense or prosecution. |
| `"immigration"` | Immigration or asylum matter. |
| `"realProperty"` | Real property or land matter. |
| `"intellectualProperty"` | Intellectual property matter (patents, trademarks, copyright). |
| `"insolvency"` | Insolvency, bankruptcy, or restructuring proceeding. |
| `"publicLaw"` | Public law, constitutional, or administrative law matter. |
| `"employment"` | Employment or labor matter. |
| `"investigation"` | Internal or regulatory investigation. |
| `"advisory"` | Transactional or advisory engagement without contentious proceedings. |

### 20.4 Custody Actions

Used in `custodyChain[].action`.

| Value | Description |
|-------|-------------|
| `"received"` | Document received from an external source. |
| `"transferred"` | Document transferred to another custodian or organization. |
| `"copied"` | Document copied or duplicated. |
| `"scanned"` | Physical document scanned to digital form. |
| `"stored"` | Document placed into archival or controlled storage. |
| `"retrieved"` | Document retrieved from storage. |
| `"sealed"` | Document sealed by tribunal order. |
| `"produced"` | Document produced or disclosed to an opposing party or tribunal. |
| `"destroyed"` | Document destroyed per retention policy or court order. |
| `"exported"` | Document exported from a document management system. |

### 20.5 Privilege Categories

Used in `privilegeLog[].claim` and `legal:privilege` linked entity `claim`.

| Value | Description |
|-------|-------------|
| `"legalProfessionalPrivilege"` | Legal professional privilege (jurisdiction-neutral base value). Encompasses advice privilege and litigation privilege where the distinction is not made. |
| `"litigationPrivilege"` | Privilege attaching to documents prepared for the dominant purpose of litigation (UK and other common law jurisdictions). |
| `"commonInterestPrivilege"` | Privilege shared among parties with a common legal interest. |
| `"withoutPrejudice"` | Documents or communications made without prejudice to settlement negotiations. |
| `"publicInterestImmunity"` | Immunity from disclosure on grounds of public interest (Crown privilege). |
| `"journalisticPrivilege"` | Privilege protecting journalistic sources. |

NOTE — Jurisdiction-specific privilege categories (such as `"attorneyClientPrivilege"` and `"workProductDoctrine"` in US practice) are defined in the applicable jurisdiction profile.

### 20.6 Hold Types

Used in `holdNotices[].holdType`.

| Value | Description |
|-------|-------------|
| `"litigation"` | Hold issued in connection with pending or anticipated litigation. |
| `"regulatory"` | Hold issued in connection with a regulatory inquiry or investigation. |
| `"audit"` | Hold issued in connection with an internal or external audit. |
| `"governmentInvestigation"` | Hold issued in connection with a government investigation. |
| `"contractual"` | Hold required by a contractual obligation. |
| `"statutory"` | Hold required by statute or regulation. |

### 20.7 Redaction Reasons

Used in redaction annotation `reason`.

| Value | Description |
|-------|-------------|
| `"personalData"` | Personal data or personally identifiable information (PII) protected by applicable data protection law. |
| `"legallyPrivileged"` | Content subject to legal professional privilege. |
| `"commerciallyConfidential"` | Commercially sensitive or proprietary business information. |
| `"tradeSecret"` | Trade secret or confidential technical information. |
| `"tribunalOrder"` | Information redacted pursuant to a tribunal order or direction. |
| `"protectedIdentity"` | Identity of a protected person (minor, witness protection, undercover officer). |
| `"thirdPartyConfidential"` | Confidential information belonging to a third party not a party to the proceedings. |
| `"nationalSecurity"` | Information whose disclosure would harm national security. |
| `"regulatoryRestriction"` | Information restricted by statute or regulatory rule. |

---

## 21. JSON Conventions

All JSON within this profile follows the ADAC 1.0 conventions:

| Convention | Requirement |
|-----------|-------------|
| **Property naming** | `camelCase` |
| **Formatting** | 2-space indented (human-readable) |
| **Null handling** | Null-valued properties SHOULD be omitted |
| **Encoding** | UTF-8 without BOM |
| **Unknown properties** | MUST be preserved during round-trip serialization |
| **Date/time format** | ISO-8601 with UTC offset (e.g., `"2026-04-01T10:00:00Z"`) |
| **Identifiers** | UUID v4 (RFC 4122) RECOMMENDED for `id` fields |
| **Enum values** | `camelCase` strings |

---

## 22. Interoperability

### 22.1 Document Management System Integration

ADAC-Legal containers carry sufficient metadata to integrate with legal document management systems and e-discovery platforms:

- **Sequential numbering** enables page-level identification within production sets.
- **Confidentiality levels** map to privilege designations in review workflows.
- **Document types** correspond to standard classification taxonomies.
- **Redaction annotations** provide audit trails for redacted productions.
- **Matter reference** enables grouping by matter across large collections.

### 22.2 Confidentiality as Metadata

The `confidentialityLevel` field is **informational metadata**, not an enforcement mechanism. ADAC-Legal records the classification; the consuming application or document management system is responsible for enforcing access controls based on that classification. This design keeps the format simple and avoids coupling the specification to any particular access control system.

### 22.3 Profile Coexistence

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

- **Legal + Genealogy** — A succession or probate document with matter metadata, custody chain, and genealogical person annotations.
- **Legal + Preservation** — A legal document in an institutional archive with both matter tracking and archival description.

The profiles coexist without conflict. Linked entity keys use distinct namespaces (`legal:exhibit` vs. `genealogy:person` vs. `archival:description`).

### 22.4 Chain of Custody vs. Provenance Log

The chain of custody (this profile) and the ADAC provenance log (core ADAC) serve complementary purposes. Both SHOULD be populated when applicable. See [Section 11.4](#114-relationship-to-adac-provenance-log) for a detailed comparison.

### 22.5 Jurisdiction Profile Interoperability

Jurisdiction profiles are designed for graceful degradation:

- An application that understands `"us"` but not `"us-la"` can still process a Louisiana container — it will recognize all base and US-level values and treat Louisiana-specific values as custom strings.
- An application that understands only the base ADAC-Legal specification can process any jurisdiction profile container — jurisdiction-specific values appear as ordinary strings in well-known value set fields.
- Cross-jurisdiction document collections (such as a multinational litigation matter) MAY contain containers with different jurisdiction profiles. Applications SHOULD handle mixed-jurisdiction collections gracefully.

---

## 23. Complete Container Example

The following shows a complete ADAC-Legal container for a three-page contract exhibit in a commercial litigation matter.

### 23.1 Container Structure

```
acme-v-brixton-contract-001.adac
├── manifest.json
├── master/
│   ├── master_0001.tif              (Page 1 — signature page, 600 DPI TIFF)
│   ├── master_0002.tif              (Page 2 — terms and conditions)
│   └── master_0003.tif              (Page 3 — schedules)
├── metadata/
│   ├── core.json
│   └── profiles/
│       └── legal.json
├── derivatives/
│   └── deriv_redacted_001.jpg       (Redacted web preview of page 1)
├── regions/
│   └── master-001.regions.json
├── provenance/
│   ├── log.json
│   └── checksums.json
└── signatures/
    ├── index.json
    ├── container-ingest.p7s
    └── container-archived.p7s
```

### 23.2 Legal Profile (`metadata/profiles/legal.json`)

```json
{
  "profileId": "urn:adac:profile:legal:v1",
  "profileType": "legal",
  "profileVersion": "1.0.0",
  "title": "ADAC Legal Profile",
  "data": {
    "jurisdictionProfile": "uk",
    "matterReference": {
      "matterNumber": "2026-LIT-04521",
      "tribunalName": "Commercial Court, King's Bench Division",
      "jurisdiction": {
        "country": "GB",
        "subdivision": "England and Wales"
      },
      "matterType": "litigation",
      "matterCaption": "Acme Ltd v. Brixton Holdings plc",
      "parties": [
        {
          "name": "Acme Ltd",
          "role": "claimant",
          "legalRepresentative": "Freshfields Bruckhaus Deringer LLP"
        },
        {
          "name": "Brixton Holdings plc",
          "role": "defendant",
          "legalRepresentative": "Clifford Chance LLP"
        }
      ]
    },
    "classification": {
      "documentType": "contract",
      "exhibitIdentifier": "Claimant's Bundle Tab C",
      "filingDate": "2026-03-15T00:00:00Z",
      "confidentialityLevel": "confidential",
      "sequentialNumberStart": "ACM000123",
      "sequentialNumberEnd": "ACM000125",
      "retentionPolicy": {
        "period": "7 years after matter closure",
        "disposition": "review",
        "holdActive": true
      }
    },
    "custodyChain": [
      {
        "id": "custody-001",
        "action": "received",
        "custodian": "A. Blackwell, Solicitor",
        "timestamp": "2026-03-15T09:00:00Z",
        "organization": "Freshfields Bruckhaus Deringer LLP",
        "signatureRef": "signatures/container-ingest.p7s",
        "notes": "Original contract received from client by hand delivery."
      },
      {
        "id": "custody-002",
        "action": "scanned",
        "custodian": "Litigation Support",
        "timestamp": "2026-03-16T14:30:00Z",
        "organization": "Freshfields Bruckhaus Deringer LLP",
        "notes": "Scanned at 600 DPI, TIFF format."
      },
      {
        "id": "custody-003",
        "action": "stored",
        "custodian": "Records Management",
        "timestamp": "2026-03-16T16:00:00Z",
        "organization": "Freshfields Bruckhaus Deringer LLP",
        "signatureRef": "signatures/container-archived.p7s",
        "notes": "Physical original placed in locked document store."
      }
    ],
    "privilegeLog": [
      {
        "id": "priv-001",
        "claim": "legalProfessionalPrivilege",
        "basis": "Advice in schedule 3 given by A. Blackwell (solicitor) to Acme Ltd regarding contractual risk.",
        "claimedBy": "Freshfields Bruckhaus Deringer LLP",
        "claimedOn": "2026-04-01T10:00:00Z",
        "scope": "partialRedacted",
        "waivedOn": null,
        "waiverBasis": null
      }
    ],
    "holdNotices": [
      {
        "id": "hold-001",
        "holdType": "litigation",
        "matterReference": "Acme Ltd v. Brixton Holdings plc, 2026-LIT-04521",
        "issuedBy": "A. Blackwell, Solicitor",
        "issuedOn": "2026-02-01T00:00:00Z",
        "scope": "All contracts and correspondence with Brixton Holdings plc from 2024-01-01 onward.",
        "releasedOn": null,
        "releaseAuthority": null,
        "notes": "Hold issued upon receipt of claim letter."
      }
    ],
    "productions": [
      {
        "id": "prod-001",
        "productionSetId": "Acme v. Brixton - Disclosure Set 1",
        "producedOn": "2026-04-15T00:00:00Z",
        "producedBy": "Freshfields Bruckhaus Deringer LLP",
        "producedTo": "Clifford Chance LLP (for Brixton Holdings plc)",
        "sequentialNumberStart": "ACM000123",
        "sequentialNumberEnd": "ACM000125",
        "redactionVariant": "deriv_redacted_001",
        "notes": "Redacted version produced per Disclosure Protocol Order dated 2026-03-01."
      }
    ]
  }
}
```

### 23.3 Region Annotations (`regions/master-001.regions.json`)

```json
{
  "mediaId": "master-001",
  "coordinateSystem": "pixel",
  "width": 4800,
  "height": 6400,
  "regions": [
    {
      "id": "region-001",
      "type": "boundingBox",
      "label": "Exhibit label — Claimant's Bundle Tab C",
      "bounds": {
        "x": 3800.0,
        "y": 100.0,
        "width": 900.0,
        "height": 200.0
      },
      "linkedEntities": {
        "legal:exhibit": {
          "exhibitId": "Claimant's Bundle Tab C",
          "description": "Signed service contract dated 2024-03-15",
          "markedOn": "2026-04-01T10:00:00Z",
          "introducedBy": "Claimant"
        }
      }
    },
    {
      "id": "region-002",
      "type": "boundingBox",
      "label": "Redacted — privileged legal advice",
      "bounds": {
        "x": 2200.0,
        "y": 3400.0,
        "width": 600.0,
        "height": 60.0
      },
      "linkedEntities": {
        "legal:redaction": {
          "reason": "legallyPrivileged",
          "authority": "Legal professional privilege — Freshfields Bruckhaus Deringer LLP",
          "authorizedBy": "A. Blackwell, Solicitor",
          "appliedToDerivativeIds": ["deriv_redacted_001"],
          "redactedOn": "2026-04-01T08:30:00Z",
          "notes": "Legal advice regarding contractual risk — privilege claimed per priv-001."
        },
        "legal:privilege": {
          "privilegeLogId": "priv-001",
          "claim": "legalProfessionalPrivilege",
          "notes": "Schedule 3 advice paragraph."
        }
      }
    },
    {
      "id": "region-003",
      "type": "boundingBox",
      "label": "Signature — Acme Ltd authorized signatory",
      "bounds": {
        "x": 800.0,
        "y": 5800.0,
        "width": 1200.0,
        "height": 300.0
      }
    }
  ]
}
```

---

## 24. Validation

### 24.1 Base Validation

ADAC-Legal containers are validated by the standard ADAC validator. The ADAC validator verifies:

- The manifest references the legal profile correctly (ADAC-050 error if the referenced profile file is missing).
- All region annotation files exist (ADAC-023 error if missing).
- SHA-256 checksums for all files including the legal profile (ADAC-082 on mismatch).

### 24.2 Profile-Specific Validation Rules

| Rule | Severity | Description |
|------|----------|-------------|
| LEG-001 | Error | The profile file's `profileType` is not `"legal"`. |
| LEG-002 | Error | The profile file's `profileId` is not `"urn:adac:profile:legal:v1"`. |
| LEG-010 | Warning | `matterReference.matterNumber` is empty when a matter reference is provided. |
| LEG-011 | Warning | `matterReference.relatedMatters[].containerId` is present but is not a valid UUID (RFC 4122). |
| LEG-020 | Warning | `classification.sequentialNumberStart` is present but `sequentialNumberEnd` is absent (or vice versa). |
| LEG-021 | Warning | `classification.confidentialityLevel` is not in the well-known set. |
| LEG-030 | Warning | `custodyChain[]` entries are not in chronological order by `timestamp`. |
| LEG-031 | Warning | A `custodyChain[]` entry has `action: "destroyed"` but `retentionPolicy.holdActive` is `true`. Destruction is prohibited while a hold is active. |
| LEG-040 | Warning | A `privilegeLog[]` entry has `scope: "partialRedacted"` but no `legal:privilege` linked entity appears in any region of the container. |
| LEG-050 | Warning | A `holdNotice[]` entry has `releasedOn` set but `retentionPolicy.holdActive` is still `true`. |
| LEG-060 | Warning | A `productions[]` entry has a `redactionVariant` value that does not match any derivative `id` in the manifest. |
| LEG-070 | Warning | A `legal:redaction` linked entity `reason` is not in the well-known set. |
| LEG-080 | Info | Container has `classification.confidentialityLevel: "legallyPrivileged"` or `"sealed"` but is not Signed Archival. Signed Archival is RECOMMENDED for privileged or sealed documents. |

### 24.3 Recommended Application-Level Checks

| Check | Description |
|-------|-------------|
| Matter number format | Verify that `matterReference.matterNumber` follows the naming convention of the applicable jurisdiction profile, when `jurisdictionProfile` is set. |
| Sequential number ordering | Verify that `sequentialNumberStart` ≤ `sequentialNumberEnd` when both are present (lexicographic ordering). |
| Custody chain completeness | Verify that custody entries cover the document from first receipt through the most recent action. |
| Exhibit consistency | Verify that `legal:exhibit` annotation `exhibitId` matches `classification.exhibitIdentifier` when both are present. |
| Jurisdiction profile recognition | When `jurisdictionProfile` is present, verify it follows the naming convention and optionally load jurisdiction-specific validation rules. |
| Merkle root validity | Verify that `mutableStateRoot` correctly reflects the current state of the legal profile and all redaction annotations. |

---

## 25. References

### 25.1 Normative References

| Reference | Description |
|-----------|-------------|
| [ADAC 1.0 Format Specification](../../ADAC/spec/ADAC-Format-Specification.md) | The base container format this profile extends. |
| [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. Required format for `containerId` values. |
| [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html) | Date and time representations. Used for all timestamp fields. |
| [IETF BCP 47](https://www.rfc-editor.org/info/bcp47) | Tags for Identifying Languages. |
| [ISO 3166-1](https://www.iso.org/iso-3166-country-codes.html) | Country codes. Used for `jurisdiction.country`. |
| [ISO 3166-2](https://www.iso.org/obp/ui/#iso:code:3166) | Subdivision codes. Used for `jurisdiction.subdivision`. |

### 25.2 Informative References

| Reference | Description |
|-----------|-------------|
| [EDRM (Electronic Discovery Reference Model)](https://edrm.net/) | US industry framework for managing electronic discovery. |
| [Sedona Principles (Third Edition)](https://thesedonaconference.org/) | Best practices for electronic document production in litigation. |
| [GDPR (Regulation (EU) 2016/679)](https://eur-lex.europa.eu/eli/reg/2016/679/oj) | European Union General Data Protection Regulation. Informs `personalData` redaction reason and `regulatory` hold type. |
| [Civil Procedure Rules (UK)](https://www.justice.gov.uk/courts/procedure-rules/civil) | UK procedural rules. Informs UK terminology alignment. |
| [Dublin Core Metadata Element Set](https://www.dublincore.org/specifications/dublin-core/dces/) | Core metadata vocabulary. ADAC core metadata aligns with Dublin Core. |
| [ADAC-Genealogy 1.0 Profile Specification](../../ADAC-Genealogy/spec/ADAC-Genealogy-Profile-Specification.md) | The genealogy profile extension for ADAC. Companion profile that can coexist with the legal profile. |
| [ADAC-Preservation 1.0 Profile Specification](../../ADAC-Preservation/spec/ADAC-Preservation-Profile-Specification.md) | The Preservation profile extension for ADAC. Companion profile for institutional archival management. |
| [ADAC-Legal-US 1.0 Profile Specification](ADAC-Legal-US-Profile-Specification.md) | The United States jurisdiction profile. Defines US-specific document types, privilege doctrine, confidentiality tiers, and field guidance. |
| [ADAC-Legal-US-LA 1.0 Profile Specification](ADAC-Legal-US-LA-Profile-Specification.md) | The Louisiana subdivision jurisdiction profile. Civil law tradition, parish-based jurisdiction, notarial acts. |
| [ADAC-Legal-US-PR 1.0 Profile Specification](ADAC-Legal-US-PR-Profile-Specification.md) | The Puerto Rico subdivision jurisdiction profile. Spanish civil law tradition, bilingual system, *municipio*-based jurisdiction. |

---

## 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.

He is not a legal professional, and ADAC-Legal does not provide legal advice.

## Document History

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