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

Abstract

The ADAC-Legal profile defines a domain-specific metadata extension for the ADAC 1.0 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
2. Conformance
3. Terminology
4. Relationship to ADAC
5. Container Format
6. Legal Profile — metadata/profiles/legal.json
7. Jurisdiction Profiles
8. Case Reference
9. Document Classification
10. Chain of Custody
11. Region Linked Entities
12. Exhibit Annotation — legal:exhibit
13. Redaction Annotation — legal:redaction
14. Well-Known Value Sets
15. JSON Conventions
16. Interoperability
17. Complete Container Example
18. Validation
19. References
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

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)

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

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

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

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

{
  "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:

{
  "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

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

6.2 Fields

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.

{
  "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.

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:

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

{
  "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

8.3 Jurisdiction

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

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

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.

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

9. Document Classification

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

9.1 Schema

{
  "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

9.3 Retention Policy

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

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

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

{
  "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

10.3 Relationship to ADAC Provenance Log

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

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

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

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

12.2 Fields

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

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

13.2 Fields

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

14.2 Confidentiality Levels

Used in classification.confidentialityLevel.

14.3 Matter Types

Used in caseReference.matterType.

14.4 Custody Actions

Used in custodyChain[].action.

14.5 Redaction Reasons

Used in redaction annotation reason.

15. JSON Conventions

All JSON within this profile follows the ADAC 1.0 conventions:

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 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)

{
  "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)

{
  "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

19. References

19.1 Normative References

19.2 Informative References

20. Version History