# ADAC-Legal 1.0 — Legal Document Profile Format Specification

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

---

## Abstract

The **ADAC-Legal** profile defines a domain-specific metadata extension for the [ADAC 1.0](../../Adac/Docs/ADAC-Format-Specification.md) container format, designed for the long-term preservation, chain-of-custody tracking, and confidentiality management of legal documents — exhibits, pleadings, contracts, depositions, court orders, affidavits, and other records produced or received during legal proceedings. The profile adds case references, document classification with Bates numbering and confidentiality levels, chain of custody, retention policies, and per-region exhibit and redaction annotations — all without modifying the core ADAC specification.

---

## Table of Contents

1. [Introduction](#1-introduction)
2. [Conformance](#2-conformance)
3. [Terminology](#3-terminology)
4. [Relationship to ADAC](#4-relationship-to-adac)
5. [Container Format](#5-container-format)
6. [Legal Profile — `metadata/profiles/legal.json`](#6-legal-profile)
7. [Jurisdiction Profiles](#7-jurisdiction-profiles)
8. [Case Reference](#8-case-reference)
9. [Document Classification](#9-document-classification)
10. [Chain of Custody](#10-chain-of-custody)
11. [Region Linked Entities](#11-region-linked-entities)
12. [Exhibit Annotation — `legal:exhibit`](#12-exhibit-annotation)
13. [Redaction Annotation — `legal:redaction`](#13-redaction-annotation)
14. [Well-Known Value Sets](#14-well-known-value-sets)
15. [JSON Conventions](#15-json-conventions)
16. [Interoperability](#16-interoperability)
17. [Complete Container Example](#17-complete-container-example)
18. [Validation](#18-validation)
19. [References](#19-references)
20. [Version History](#20-version-history)

---

## 1. Introduction

### 1.1 Problem Statement

Legal document management demands meticulous tracking of provenance, confidentiality, and evidentiary integrity. Exhibits must be numbered, classified, and marked. 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 policies must be tracked alongside litigation hold status. And all of this context must travel with the document — not in a separate database that could become disconnected.

Existing approaches store legal metadata in document management systems, review platforms, or proprietary databases — creating dependencies on specific vendor systems and risking metadata loss during migrations.

### 1.2 Solution

ADAC-Legal solves this by embedding legal context directly into the archival container alongside the scanned document:

- **Case reference** — case number, court, jurisdiction, docket number, case caption, and named parties.
- **Document classification** — document type, exhibit number, filing date, confidentiality level, and Bates numbering range.
- **Chain of custody** — chronological record of every person or entity that handled the artifact, from receipt through scanning and storage.
- **Retention policy** — retention period, expiration date, disposition action, and litigation hold status.
- **Exhibit annotations** — per-region tags marking specific areas on scanned documents as exhibit stickers or labels.
- **Redaction annotations** — per-region metadata recording that specific areas have been redacted, including the reason, legal authority, and authorizing person.
- **Jurisdiction profiles** — country-specific and subdivision-specific variants (e.g., ADAC-Legal-US, ADAC-Legal-UK, ADAC-Legal-US-LA) that extend the base profile with jurisdiction-appropriate document types, matter types, and procedural terminology.

### 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. |
| **Legal-first** | Every schema element maps to a concept central to legal document management and e-discovery: Bates numbering, privilege classifications, chain of custody, protective orders, redaction standards. |
| **Non-intrusive** | Non-legal ADAC consumers ignore all legal data. Linked entity values survive round-trip serialization unchanged. |
| **Confidentiality-aware** | The confidentiality level classification (`public`, `confidential`, `privileged`, `sealed`) enables automated access control — though enforcement is the consuming application's responsibility, not the format's. |
| **Jurisdiction-aware** | Legal systems vary significantly by country and even by subdivision. ADAC-Legal supports jurisdiction profiles that extend the base specification with country-specific or subdivision-specific terminology, document types, and procedural concepts — without fragmenting the core profile. |
| **Multi-profile** | ADAC-Legal containers can coexist with other profiles (e.g., ADAC-Genealogy). A probate document could carry both a legal profile (case 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`)
- Case reference, jurisdiction, and party schemas
- Document classification, confidentiality, Bates numbering, and retention policy schemas
- Chain-of-custody event schema
- Per-region linked entity schemas for exhibit and redaction annotations
- Well-known value sets for document types, confidentiality levels, matter types, custody actions, and redaction reasons
- 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, e.g., ADAC-Legal-US, ADAC-Legal-UK)

- The ADAC core container format (see the [ADAC 1.0 Format Specification](../../Adac/Docs/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

### 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 e-discovery and document production
- Compliance officers assessing chain-of-custody and retention policy capabilities
- Standards bodies evaluating the format for adoption

---

## 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 (Minimal or Archival conformance).
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 `profileVersion` and `profileType` fields, with `profileType` equal to `"legal"`.

### 2.2 Forward Compatibility

Readers MUST tolerate unknown JSON properties in all legal profile structures. Unknown properties MUST be preserved during round-trip serialization.

---

## 3. Terminology

| Term | Definition |
|------|------------|
| **ADAC-Legal Container** | An ADAC container that includes a legal profile at `metadata/profiles/legal.json`. Uses the standard `.adac` extension. |
| **Case Reference** | Structured identification of the legal matter — case number, court, jurisdiction, docket, caption, and parties. |
| **Document Classification** | Metadata describing the document type, exhibit number, confidentiality level, and Bates range. |
| **Bates Numbering** | The industry-standard method for sequentially numbering every page in a legal document production. |
| **Confidentiality Level** | The access restriction classification applied to the document (`public`, `confidential`, `privileged`, `sealed`, etc.). |
| **Chain of Custody** | A chronological record of every person or entity that handled the artifact, establishing an unbroken evidentiary trail. |
| **Retention Policy** | Rules governing how long the document must be preserved and what happens when the retention period expires. |
| **Litigation Hold** | A directive suspending normal document destruction schedules due to pending or anticipated litigation. |
| **Exhibit Annotation** | Per-region metadata tagging a specific area on a scanned document as an exhibit marker or label. Linked entity key: `legal:exhibit`. |
| **Redaction Annotation** | Per-region metadata recording that a specific area has been redacted, including the reason and legal authority. Linked entity key: `legal:redaction`. |
| **Jurisdiction Profile** | A country-specific or subdivision-specific variant of ADAC-Legal identified by the `jurisdictionProfile` field (e.g., `"us"`, `"uk"`, `"us-la"`). Jurisdiction profiles extend the base ADAC-Legal specification with locale-appropriate document types, matter types, and procedural concepts. |
| **Protective Order** | A court order restricting disclosure of confidential information produced during litigation. |

---

## 4. Relationship to ADAC

### 4.1 Extension Mechanisms

ADAC-Legal extends ADAC through two 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`). Non-legal readers preserve these values unchanged during round-trip serialization.

### 4.2 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 or checksum manifest schemas
- ❌ Any ADAC validation rules or error codes

---

## 5. Container Format

### 5.1 File Extension

| Property | Value |
|----------|-------|
| **File extension** | `.adac` |

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. This avoids extension proliferation and keeps the format unified.

### 5.2 Directory Structure

```
<container>.adac
├── manifest.json                           (REQUIRED — ADAC)
├── master/                                 (REQUIRED — ADAC)
│   ├── master_0001.tif
│   └── ...
├── metadata/                               (REQUIRED — ADAC)
│   ├── core.json                           (REQUIRED — 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/                             (RECOMMENDED — ADAC)
    ├── log.json
    └── checksums.json
```

### 5.3 Manifest Integration

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

A container MAY include multiple profiles simultaneously:

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

---

## 6. 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 aggregates case reference, document classification, and chain of custody. Per-region data (exhibit annotations, redaction annotations) is stored separately in each region's `linkedEntities` dictionary.

### 6.1 Schema

```json
{
  "profileVersion": "1.0",
  "profileType": "legal",
  "jurisdictionProfile": "us",
  "caseReference": { ... },
  "classification": { ... },
  "custodyChain": [ ... ]
}
```

### 6.2 Fields

| Field | Type | Required | Default | Description |
|-------|------|----------|---------|-------------|
| `profileVersion` | `string` | REQUIRED | `"1.0"` | The profile schema version. |
| `profileType` | `string` | REQUIRED | `"legal"` | The profile type identifier. MUST be `"legal"`. |
| `jurisdictionProfile` | `string` | OPTIONAL | `null` | Identifies a country-specific or subdivision-specific jurisdiction profile (see [Section 7](#7-jurisdiction-profiles)). When absent, only the base ADAC-Legal schema and value sets apply. |
| `caseReference` | `CaseReference` | OPTIONAL | `null` | Legal matter identification (see [Section 8](#8-case-reference)). |
| `classification` | `DocumentClassification` | OPTIONAL | `null` | Document type, confidentiality, and Bates range (see [Section 9](#9-document-classification)). |
| `custodyChain` | `CustodyEntry[]` | OPTIONAL | `null` | Chronological chain-of-custody entries (see [Section 10](#10-chain-of-custody)). |

### 6.3 Forward Compatibility

Unknown JSON properties MUST be preserved during round-trip serialization. This ensures that future profile versions can add fields without breaking existing readers.

---

## 7. Jurisdiction Profiles

Legal systems vary dramatically across countries and, in some cases, across subdivisions within a country. The United States follows the common law tradition, but Louisiana operates under a civil law system derived from the Napoleonic Code. The United Kingdom has distinct legal traditions in England & Wales, Scotland, and Northern Ireland. Civil law jurisdictions (France, Germany, Japan) use fundamentally different procedural terminology, document types, and court structures than common law jurisdictions.

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.

### 7.1 Mechanism

The `jurisdictionProfile` field in the legal profile root 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.

```json
{
  "profileVersion": "1.0",
  "profileType": "legal",
  "jurisdictionProfile": "us",
  "caseReference": { ... },
  "classification": { ... },
  "custodyChain": [ ... ]
}
```

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

### 7.2 Naming Convention

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

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

The `jurisdictionProfile` field stores only the variable portion — the `legal-` prefix is implied by the profile type.

| Identifier | Full Name | Rationale |
|------------|-----------|----------|
| `"us"` | ADAC-Legal-US | United States federal legal system. Covers federal courts, common law tradition, Federal Rules of Civil Procedure. |
| `"uk"` | ADAC-Legal-UK | United Kingdom. May further specialize into `"uk-eng"` (England & Wales), `"uk-sct"` (Scotland), `"uk-nir"` (Northern Ireland). |
| `"us-la"` | ADAC-Legal-US-LA | Louisiana. Civil law tradition derived from the Napoleonic Code; distinct terminology (e.g., "parish" instead of "county", "successions" instead of "probate"). |
| `"us-pr"` | ADAC-Legal-US-PR | Puerto Rico. Civil law tradition derived from the Spanish Civil Code; bilingual (Spanish/English) legal system; *municipio*-based jurisdiction; distinct court structure (*Tribunal de Primera Instancia*). |
| `"de"` | ADAC-Legal-DE | Germany. Civil law system with distinct court hierarchy and procedural terminology. |
| `"fr"` | ADAC-Legal-FR | France. Civil law system, Napoleonic Code tradition. |
| `"ca"` | ADAC-Legal-CA | Canada. May further specialize into `"ca-qc"` (Québec, civil law) vs. `"ca-on"` (Ontario, common law). |

### 7.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 (e.g., `"us"`) MAY:
   - Add country-specific well-known values to existing value sets (e.g., U.S.-specific document types like `"rule30b6Deposition"`).
   - Define new fields within the existing schema structures using the forward-compatibility mechanism (unknown properties are preserved).
   - Provide country-specific guidance on how base fields should be populated.

3. **Subdivision layer** — A subdivision-level jurisdiction profile (e.g., `"us-la"`) inherits from its country layer and MAY further specialize. Louisiana, for example, would add civil-law-specific document types (`"successionProceeding"`, `"notarialAct"`) and adjust terminology.

Jurisdiction profiles MUST NOT:

- ❌ Remove or redefine base ADAC-Legal fields
- ❌ Remove base well-known values
- ❌ Change the meaning of base fields
- ❌ Modify the ADAC core specification

### 7.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 (civil law in a common law country), Scotland (mixed system in a common law country). |
| Unique document types | Notarial acts (civil law), statutory declarations (UK), Schriftsatz (Germany). |
| Different court hierarchy | Germany's four-tier court system; UK's distinction between solicitors and barristers. |
| Different procedural terminology | "Parish" vs. "county", "succession" vs. "probate", "pursuer" vs. "plaintiff" (Scotland). |
| Jurisdiction-specific retention rules | GDPR data retention requirements (EU), state-specific statute of limitations rules (U.S.). |

A jurisdiction profile is **not** warranted for minor terminological preferences that can be handled by free-text fields (e.g., `caption`, `notes`) or custom values in existing value sets.

### 7.5 Relationship Between Base and Jurisdiction Profiles

A container with `"jurisdictionProfile": "us-la"` is simultaneously:

- A valid **ADAC-Legal** container (base profile)
- A valid **ADAC-Legal-US** container (country layer)
- A valid **ADAC-Legal-US-LA** container (subdivision layer)

An application that understands only the base ADAC-Legal specification can still read and process the container — it will simply ignore jurisdiction-specific values it does not recognize (they appear as ordinary strings in well-known value set fields). This preserves the forward-compatibility guarantee.

### 7.6 Jurisdiction Profile Specifications

Each jurisdiction profile is defined in a companion specification document. These documents define:

- The jurisdiction profile identifier and its scope
- Additional well-known values for document types, matter types, confidentiality levels, custody actions, and redaction reasons
- Jurisdiction-specific guidance on populating base fields
- Any additional linked entity types specific to the jurisdiction
- Examples showing jurisdiction-specific usage

Jurisdiction profile specifications are published separately from this base specification and follow the same versioning and conformance conventions.

---

## 8. Case Reference

The case reference identifies the legal matter or case that the archived document belongs to, enabling retrieval, indexing, and compliance tracking across large document collections.

### 8.1 Schema

```json
{
  "caseReference": {
    "caseNumber": "2025-CV-04521",
    "courtName": "U.S. District Court, Southern District of New York",
    "jurisdiction": {
      "country": "US",
      "state": "New York",
      "county": "New York"
    },
    "docketNumber": null,
    "matterType": "litigation",
    "caption": "Smith v. Jones Corp.",
    "parties": [
      { "name": "John Smith", "role": "plaintiff" },
      { "name": "Jones Corp.", "role": "defendant" }
    ]
  }
}
```

### 8.2 Case Reference Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `caseNumber` | `string` | OPTIONAL | Case or matter number assigned by the court or firm. |
| `courtName` | `string` | OPTIONAL | Name of the court or tribunal. |
| `jurisdiction` | `Jurisdiction` | OPTIONAL | Geographic jurisdiction of the matter (see [Section 8.3](#83-jurisdiction)). |
| `docketNumber` | `string` | OPTIONAL | Docket number, if different from the case number. |
| `matterType` | `string` | OPTIONAL | Type of legal matter. See [Section 14.3](#143-matter-types) for well-known values. |
| `caption` | `string` | OPTIONAL | Case caption or title (e.g., "Smith v. Jones"). |
| `parties` | `Party[]` | OPTIONAL | Named parties and their roles. |

### 8.3 Jurisdiction

Describes the geographic jurisdiction of the legal matter, from broadest to most specific.

```json
{
  "country": "US",
  "state": "New York",
  "county": "New York"
}
```

| Field | Type | Description |
|-------|------|-------------|
| `country` | `string` | The country. |
| `state` | `string` | The state, province, or equivalent administrative division. |
| `county` | `string` | The county, parish, or equivalent subdivision. |

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

### 8.4 Party

Identifies a named party in the legal matter.

```json
{
  "name": "John Smith",
  "role": "plaintiff"
}
```

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `name` | `string` | REQUIRED | The party's name (individual or entity). |
| `role` | `string` | OPTIONAL | The party's role (e.g., `"plaintiff"`, `"defendant"`, `"petitioner"`, `"respondent"`, `"appellant"`, `"appellee"`, `"intervenor"`). |

---

## 9. Document Classification

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

### 9.1 Schema

```json
{
  "classification": {
    "documentType": "exhibit",
    "exhibitNumber": "Plaintiff's 42",
    "filingDate": "2025-03-15T00:00:00Z",
    "confidentialityLevel": "confidential",
    "batesRangeStart": "SMITH000123",
    "batesRangeEnd": "SMITH000125",
    "retentionPolicy": {
      "period": "7 years after case closure",
      "expiresOn": null,
      "disposition": "destroy",
      "litigationHold": true
    }
  }
}
```

### 9.2 Document Classification Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `documentType` | `string` | OPTIONAL | The document type. See [Section 14.1](#141-document-types) for well-known values. |
| `exhibitNumber` | `string` | OPTIONAL | Exhibit number or identifier (e.g., `"Plaintiff's 42"`, `"Exhibit A"`). |
| `filingDate` | `string` | OPTIONAL | Date the document was filed with the court or received by the firm (ISO-8601). |
| `confidentialityLevel` | `string` | OPTIONAL | Access restriction level. See [Section 14.2](#142-confidentiality-levels) for well-known values. |
| `batesRangeStart` | `string` | OPTIONAL | Beginning of the Bates number range (e.g., `"SMITH000123"`). |
| `batesRangeEnd` | `string` | OPTIONAL | End of the Bates number range (e.g., `"SMITH000125"`). |
| `retentionPolicy` | `RetentionPolicy` | OPTIONAL | Retention period, disposition, and litigation hold status. |

### 9.3 Retention Policy

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

```json
{
  "period": "7 years after case closure",
  "expiresOn": null,
  "disposition": "destroy",
  "litigationHold": true
}
```

| Field | Type | Required | Default | Description |
|-------|------|----------|---------|-------------|
| `period` | `string` | OPTIONAL | `null` | Human-readable retention period (e.g., `"7 years"`, `"permanent"`, `"until case closure + 6 years"`). |
| `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 (e.g., `"destroy"`, `"review"`, `"archive"`, `"transfer"`). |
| `litigationHold` | `boolean` | OPTIONAL | `null` | When `true`, destruction is suspended regardless of the retention period. |

### 9.4 Bates Numbering Usage Notes

- Bates numbers are assigned externally during document production. ADAC-Legal records the assigned range — it does not generate Bates numbers.
- For a single-page document, `batesRangeStart` and `batesRangeEnd` SHOULD be the same value.
- For multi-master containers, the Bates range spans all masters (e.g., a 3-page exhibit with masters `master_0001.tif` through `master_0003.tif` would have `"SMITH000123"` through `"SMITH000125"`).

---

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

### 10.1 Schema

```json
{
  "custodyChain": [
    {
      "action": "received",
      "custodian": "Jane Doe, Esq.",
      "timestamp": "2025-03-15T09:00:00Z",
      "organization": "Smith & Associates LLP",
      "notes": "Original received via certified mail, tracking #1Z999AA10123456784."
    },
    {
      "action": "scanned",
      "custodian": "Litigation Support",
      "timestamp": "2025-03-16T14:30:00Z",
      "organization": "Smith & Associates LLP",
      "notes": "Scanned at 600 DPI, TIFF format, flatbed scanner."
    },
    {
      "action": "stored",
      "custodian": "Records Management",
      "timestamp": "2025-03-16T16:00:00Z",
      "organization": "Smith & Associates LLP",
      "notes": "Physical original placed in locked evidence cabinet, Room 401."
    }
  ]
}
```

### 10.2 Custody Entry Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `action` | `string` | REQUIRED | The custody action performed. See [Section 14.4](#144-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 or organization associated with the custodian. |
| `notes` | `string` | OPTIONAL | Free-text notes describing the event. |

### 10.3 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 artifact | Technical actions on the ADAC container |
| **Audience** | Legal professionals, courts, compliance officers | Software developers, archivists |
| **Examples** | "Received from opposing counsel", "Stored in evidence locker" | `"scan"`, `"import"`, `"derivativeCreated"` |
| **Scope** | May predate container creation | Begins at container creation |
| **Fixity Impact** | **Critical Master Failure** indicates an evidentiary breach of the original. | **State Inconsistency** indicates a technical save failure of metadata. |

Both SHOULD be populated when applicable. Neither replaces the other.

### 10.4 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: tracking numbers, storage locations, scanner models, witness names.

---

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

### 11.1 Linked Entity Keys

| Key | Description |
|-----|-------------|
| `legal:exhibit` | Exhibit identification and marking (see [Section 12](#12-exhibit-annotation)). |
| `legal:redaction` | Redaction reason, authority, and notes (see [Section 13](#13-redaction-annotation)). |

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

### 11.3 Multiple Entities per Region

A single region MAY have multiple linked entities simultaneously. For example, a bounding box around an exhibit sticker on a document could have:

- A `legal:exhibit` entity identifying it as "Plaintiff's Exhibit 42"
- A genealogy `genealogy:transcription` entity with the text on the sticker

Legal linked entities coexist with linked entities from other profiles without conflict.

---

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

### 12.1 Schema

```json
{
  "exhibitId": "Plaintiff's 42",
  "description": "Signed contract dated 2024-03-15",
  "markedOn": "2025-04-01T10:00:00Z",
  "introducedBy": "Plaintiff"
}
```

### 12.2 Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `exhibitId` | `string` | REQUIRED | The exhibit number or letter (e.g., `"Exhibit A"`, `"Plaintiff's 42"`, `"Defense 7"`). |
| `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 attorney who introduced the exhibit (e.g., `"Plaintiff"`, `"Defense Counsel"`). |

### 12.3 Usage Guidelines

- The `exhibitId` SHOULD match the `classification.exhibitNumber` in the profile when the entire document is a single exhibit.
- For documents containing multiple exhibit stickers (e.g., 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.

---

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

### 13.1 Schema

```json
{
  "reason": "pii",
  "authority": "Protective Order dated 2025-01-10",
  "authorizedBy": "Jane Doe, Esq.",
  "notes": "Social Security number of minor child"
}
```

### 13.2 Fields

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `reason` | `string` | REQUIRED | The reason for the redaction. See [Section 14.5](#145-redaction-reasons) for well-known values. |
| `authority` | `string` | OPTIONAL | The legal authority or basis (e.g., `"Protective Order dated 2025-01-10"`, `"HIPAA §164.502"`, `"Fed. R. Civ. P. 26(c)"`). |
| `authorizedBy` | `string` | OPTIONAL | Person or entity who authorized the redaction. |
| `notes` | `string` | OPTIONAL | Free-text notes describing what was redacted. |

### 13.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 judge to verify the legal basis for the redaction.
- A single document MAY have many redacted regions (e.g., all Social Security numbers, all minor names). Each redacted area gets its own region with its own `legal:redaction` entity.
- Applications SHOULD render redaction annotations as a distinct overlay style (e.g., black boxes with a "REDACTED" label).

---

## 14. 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 needs. All values are lowercase 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 7](#7-jurisdiction-profiles)) MAY extend these value sets with additional jurisdiction-specific values. Jurisdiction profiles MUST NOT remove or redefine base values.

### 14.1 Document Types

Used in `classification.documentType`.

| Value | Description |
|-------|-------------|
| `"exhibit"` | A trial or hearing exhibit. |
| `"pleading"` | A pleading filed with the court. |
| `"motion"` | A motion submitted to the court. |
| `"order"` | A court order or ruling. |
| `"correspondence"` | Correspondence between parties or counsel. |
| `"contract"` | A contract or agreement. |
| `"will"` | A last will and testament. |
| `"deed"` | A property deed or title instrument. |
| `"deposition"` | A sworn deposition transcript. |
| `"affidavit"` | A sworn affidavit. |
| `"subpoena"` | A subpoena compelling testimony or document production. |
| `"brief"` | A legal brief or memorandum of law. |
| `"transcript"` | A court or hearing transcript. |

### 14.2 Confidentiality Levels

Used in `classification.confidentialityLevel`.

| Value | Description |
|-------|-------------|
| `"public"` | Public record — no access restrictions. |
| `"confidential"` | Restricted access under a protective order or agreement. |
| `"privilegedAttorneyClient"` | Attorney-client privileged communication. |
| `"privilegedWorkProduct"` | Attorney work-product privilege. |
| `"sealed"` | Sealed by court order — access prohibited. |
| `"restricted"` | Subject to specific access conditions. |

### 14.3 Matter Types

Used in `caseReference.matterType`.

| Value | Description |
|-------|-------------|
| `"litigation"` | Civil or commercial litigation. |
| `"transaction"` | Transactional matter (mergers, acquisitions, closings). |
| `"regulatory"` | Regulatory or compliance matter. |
| `"probate"` | Probate or estate administration. |
| `"familyLaw"` | Family law matter (divorce, custody, adoption). |
| `"criminal"` | Criminal defense or prosecution. |
| `"immigration"` | Immigration matter. |
| `"realEstate"` | Real estate or property matter. |
| `"intellectualProperty"` | Patent, trademark, or copyright matter. |
| `"bankruptcy"` | Bankruptcy or insolvency proceeding. |

### 14.4 Custody Actions

Used in `custodyChain[].action`.

| Value | Description |
|-------|-------------|
| `"received"` | Document received from an external source. |
| `"transferred"` | Document transferred to another custodian. |
| `"copied"` | Document copied or duplicated. |
| `"scanned"` | Physical document scanned to digital form. |
| `"stored"` | Document placed into archival storage. |
| `"retrieved"` | Document retrieved from storage. |
| `"sealed"` | Document sealed by court order. |
| `"destroyed"` | Document destroyed per retention policy. |

### 14.5 Redaction Reasons

Used in redaction annotation `reason`.

| Value | Description |
|-------|-------------|
| `"pii"` | Personally identifiable information (SSN, DOB, etc.). |
| `"attorneyClientPrivilege"` | Attorney-client privileged content. |
| `"workProductPrivilege"` | Attorney work-product content. |
| `"tradeSecret"` | Trade secret or proprietary business information. |
| `"courtOrder"` | Information sealed by court order. |
| `"medicalInformation"` | Medical or health information (HIPAA). |
| `"minorInformation"` | Minor's identifying information. |
| `"financialInformation"` | Financial account numbers. |

---

## 15. JSON Conventions

All JSON within this profile follows the ADAC 1.0 conventions:

| Convention | Requirement |
|-----------|-------------|
| **Property naming** | camelCase |
| **Formatting** | 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 |

---

## 16. Interoperability

### 16.1 E-Discovery Platform Integration

ADAC-Legal containers carry sufficient metadata to integrate with e-discovery review platforms:

- **Bates 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.

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

### 16.3 Profile Coexistence

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

- **Legal + Genealogy** — A probate document with case metadata, custody chain, and genealogical person annotations.
- **Legal + Legal** — Not applicable (only one legal profile per container), but a container MAY coexist with any number of other domain profiles.

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

### 16.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 10.3](#103-relationship-to-adac-provenance-log) for a detailed comparison.

### 16.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 U.S.-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 (e.g., a multinational litigation matter) MAY contain containers with different jurisdiction profiles. Applications SHOULD handle mixed-jurisdiction collections gracefully.

The `jurisdictionProfile` field enables applications to:

- Load jurisdiction-specific value sets and validation rules.
- Render jurisdiction-appropriate labels in user interfaces (e.g., "Parish" instead of "County" for Louisiana).
- Apply jurisdiction-specific retention and compliance rules.
- Filter or group documents by jurisdiction in review workflows.

---

## 17. Complete Container Example

The following shows a complete ADAC-Legal container for a three-page exhibit in a civil litigation matter:

### 17.1 Container Structure

```
smith-v-jones-exhibit-42.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_0001.jpg               (Web preview of page 1)
├── regions/
│   └── master-001.regions.json
└── provenance/
    ├── log.json
    └── checksums.json
```

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

```json
{
  "profileVersion": "1.0",
  "profileType": "legal",
  "jurisdictionProfile": "us",
  "caseReference": {
    "caseNumber": "2025-CV-04521",
    "courtName": "U.S. District Court, Southern District of New York",
    "jurisdiction": {
      "country": "US",
      "state": "New York",
      "county": "New York"
    },
    "matterType": "litigation",
    "caption": "Smith v. Jones Corp.",
    "parties": [
      { "name": "John Smith", "role": "plaintiff" },
      { "name": "Jones Corp.", "role": "defendant" }
    ]
  },
  "classification": {
    "documentType": "exhibit",
    "exhibitNumber": "Plaintiff's 42",
    "filingDate": "2025-03-15T00:00:00Z",
    "confidentialityLevel": "confidential",
    "batesRangeStart": "SMITH000123",
    "batesRangeEnd": "SMITH000125",
    "retentionPolicy": {
      "period": "7 years after case closure",
      "disposition": "destroy",
      "litigationHold": true
    }
  },
  "custodyChain": [
    {
      "action": "received",
      "custodian": "Jane Doe, Esq.",
      "timestamp": "2025-03-15T09:00:00Z",
      "organization": "Smith & Associates LLP",
      "notes": "Original contract received from client via certified mail."
    },
    {
      "action": "scanned",
      "custodian": "Litigation Support",
      "timestamp": "2025-03-16T14:30:00Z",
      "organization": "Smith & Associates LLP",
      "notes": "Scanned at 600 DPI, TIFF format."
    },
    {
      "action": "stored",
      "custodian": "Records Management",
      "timestamp": "2025-03-16T16:00:00Z",
      "organization": "Smith & Associates LLP",
      "notes": "Physical original placed in locked evidence cabinet, Room 401."
    }
  ]
}
```

### 17.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 Sticker",
      "bounds": {
        "x": 3800.0,
        "y": 100.0,
        "width": 900.0,
        "height": 200.0
      },
      "linkedEntities": {
        "legal:exhibit": {
          "exhibitId": "Plaintiff's 42",
          "description": "Signed contract dated 2024-03-15",
          "markedOn": "2025-04-01T10:00:00Z",
          "introducedBy": "Plaintiff"
        }
      }
    },
    {
      "id": "region-002",
      "type": "boundingBox",
      "label": "Redacted — SSN",
      "bounds": {
        "x": 2200.0,
        "y": 3400.0,
        "width": 600.0,
        "height": 60.0
      },
      "linkedEntities": {
        "legal:redaction": {
          "reason": "pii",
          "authority": "Protective Order dated 2025-01-10",
          "authorizedBy": "Jane Doe, Esq.",
          "notes": "Social Security number of minor child"
        }
      }
    },
    {
      "id": "region-003",
      "type": "boundingBox",
      "label": "Signature — John Smith",
      "bounds": {
        "x": 800.0,
        "y": 5800.0,
        "width": 1200.0,
        "height": 300.0
      }
    }
  ]
}
```

---

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

### 18.1 Profile-Specific Validation

This specification does **not** define additional validation error codes. Profile-level semantic validation is the responsibility of the consuming application.

### 18.2 Recommended Application-Level Checks

| Check | Description |
|-------|-------------|
| Case number presence | Verify that `caseReference.caseNumber` is non-empty when a case reference is provided. |
| Bates range ordering | Verify that `batesRangeStart` ≤ `batesRangeEnd` when both are present. |
| Custody chain ordering | Verify that custody entries are in chronological order by `timestamp`. |
| Litigation hold consistency | Warn when `retentionPolicy.litigationHold` is `true` but `disposition` is `"destroy"` (destruction is suspended by the hold). |
| Redaction reason validity | Verify that `reason` uses one of the well-known values. |
| Confidentiality level validity | Verify that `confidentialityLevel` uses one of the well-known values. |
| Exhibit number consistency | Verify that exhibit annotation `exhibitId` matches `classification.exhibitNumber` when both are present. |
| Jurisdiction profile recognition | When `jurisdictionProfile` is present, verify it follows the naming convention (`{country}` or `{country}-{subdivision}`) and optionally load jurisdiction-specific validation rules. |
| Merkle Root Validation | Verify that the `mutableStateRoot` correctly reflects the current state of the legal profile and all redaction annotations. |

---

## 19. References

### 19.1 Normative References

| Reference | Description |
|-----------|-------------|
| [ADAC 1.0 Format Specification](../../Adac/Docs/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. |

### 19.2 Informative References

| Reference | Description |
|-----------|-------------|
| [Federal Rules of Civil Procedure](https://www.uscourts.gov/rules-policies/current-rules-practice-procedure) | U.S. federal civil litigation rules. Informs e-discovery, protective order, and redaction concepts. |
| [EDRM (Electronic Discovery Reference Model)](https://edrm.net/) | Industry framework for managing electronic discovery. |
| [Sedona Principles](https://thesedonaconference.org/) | Best practices for electronic document production in litigation. |
| [HIPAA Privacy Rule (45 CFR §164.502)](https://www.hhs.gov/hipaa/for-professionals/privacy/) | Health information privacy rules. Informs the `medicalInformation` redaction reason. |
| [ISO 3166](https://www.iso.org/iso-3166-country-codes.html) | Country codes and subdivision codes. Informs the jurisdiction profile naming convention. |
| [ADAC-Genealogy 1.0 Format Specification](../../AdacGenealogy/Docs/ADAC-Genealogy-Format-Specification.md) | The genealogy profile extension for ADAC. Companion profile that can coexist with the legal profile. |
| [ADAC-Legal-US 1.0 Format Specification](ADAC-Legal-US-Format-Specification.md) | The United States jurisdiction profile for ADAC-Legal. Defines US-specific document types, matter types, confidentiality tiers, custody actions, redaction reasons, and field guidance. |
| [ADAC-Legal-US-LA 1.0 Format Specification](ADAC-Legal-US-LA-Format-Specification.md) | The Louisiana subdivision jurisdiction profile. Civil law tradition, parish-based jurisdiction, notarial acts, successions. |
| [ADAC-Legal-US-PR 1.0 Format Specification](ADAC-Legal-US-PR-Format-Specification.md) | The Puerto Rico subdivision jurisdiction profile. Spanish civil law tradition, bilingual system, *municipio*-based jurisdiction. |

---

## 20. Version History

| Version | Date | Description |
|---------|------|-------------|
| 1.0 | 2026 | Initial release. Case reference, document classification, Bates numbering, confidentiality levels, chain of custody, retention policies, exhibit annotations, redaction annotations, well-known value sets for document types, confidentiality levels, matter types, custody actions, and redaction reasons. |