# ADAC 1.0 — White Paper **A Self-Describing, Living Archive for the World's Digital Assets** Version: 1.0 | Status: Stable | Date: 2026 Lead Author: John Vaden © 2026 InnoVadens, LLC. All rights reserved. --- > **Abstract** > > The Archival Digital Asset Container (ADAC) is an open specification for packaging, describing, protecting, and preserving digital assets with complete provenance, integrity, and accessibility. This white paper introduces ADAC 1.0 — the first stable release of the core format specification — and the initial family of domain profile extensions that transform a general-purpose archival container into a precision instrument for genealogy, legal document management, and institutional preservation. ADAC is designed as a global standard from its foundations; the U.S. jurisdiction family for the Legal profile is the first validated set of jurisdiction-specific extensions, with additional jurisdictions planned as the ecosystem matures. --- ## §1 Executive Summary The Archival Digital Asset Container (ADAC) is an open specification stewarded by InnoVadens, LLC, and published at [https://adac-standard.com](https://adac-standard.com). ADAC defines a self-describing, ZIP-based archival container that encapsulates master files, derivatives, structured metadata, region annotations, non-destructive edit pipelines, domain profile extensions, provenance history, and cryptographic fixity — all within a single portable artifact. The central insight behind ADAC is that a digital asset divorced from its descriptive context, provenance chain, and integrity proof is an asset at risk. Existing digital preservation approaches store metadata in external databases, sidecar files, or proprietary catalogs — creating fragile dependency chains that break when systems migrate, decommission, or fail. ADAC eliminates this fragility by design. Every ADAC container carries everything needed to understand, verify, and use its contents. No external database is required. No proprietary reader is necessary. Any standard ZIP utility can open the file. ADAC containers are *living archives*. They are designed to be opened, enriched, and re-saved throughout their lifetime without disturbing the original master file. The master file is the only immutable content in the container; its SHA-256 checksum serves as its identity seal. All other metadata — annotations, provenance events, profile extensions — grows additively over time. ADAC 1.0 ships with three domain profile extensions. ADAC-Genealogy 1.0 (Stable) supports structured source citations, person annotations, and Genealogical Proof Standard (GPS) evidence classification for digitized genealogical records. ADAC-Legal 1.0 (Stable) supports matter references, chain-of-custody records, exhibit annotations, and redaction metadata for legal documents, with a validated United States jurisdiction family covering federal common law, Louisiana civil law, and Puerto Rico mixed-tradition practice. ADAC-Preservation 1.0 (Draft) supports structured archival description, accession metadata, and preservation planning aligned with ISAD(G), DACS, and PREMIS conventions. Proof-of-concept implementations include a C# command-line interface (CLI) tool for creating and validating containers, a browser-based Web Validator for visual inspection and conformance checking, and a cloud Storage Adapter for integrating ADAC containers with cloud object storage. The specification is licensed under Creative Commons Attribution–NoDerivatives 4.0 International (CC BY-ND 4.0). Reference implementations are open source. ADAC is designed as a global standard but begins with the U.S. jurisdiction family for its Legal profile extensions; additional jurisdiction families are planned as the ecosystem matures. --- ## §2 Problem Space ### §2.1 The Digital Preservation Crisis Digital assets lose meaning without their descriptive context, provenance, structural relationships, and integrity guarantees. A photograph without its date, location, and subject information is an anonymous image. A legal exhibit without its chain of custody is an unauthenticated document. A census page without its archival citation is an orphaned record. Existing digital preservation approaches scatter this critical context across multiple systems. Descriptive metadata resides in a cataloging database. Technical metadata lives in file system attributes. Provenance records sit in an audit log on a separate server. Structural relationships exist only in the application logic of a particular content management system. When any of these systems is migrated, decommissioned, or lost, the dependency chain breaks and the asset loses part — or all — of its meaning. The result is a slow, persistent crisis. Organizations invest heavily in digitization but fail to preserve the contextual information that makes the digitized asset useful. Decades later, institutions discover collections of files with no reliable way to determine what they contain, where they came from, whether they have been altered, or how they relate to other assets. ### §2.2 The Metadata Fragmentation Problem Metadata is typically stored separately from the asset it describes. A database record points to a file on disk. A sidecar XML file sits alongside the master image. A proprietary catalog maintains an internal index with descriptive fields, keywords, and provenance notes. Each approach creates a dependency: the asset requires an external system to be intelligible. This separation is fragile. Database migrations lose fields. Sidecar files are accidentally deleted or separated from their parent assets during file transfers. Proprietary catalogs lock metadata inside vendor-specific formats that become unreadable when the vendor discontinues the product or changes its data model. Over decades — the timescale relevant to archival preservation — these failures are not exceptional; they are inevitable. The fundamental problem is architectural. When metadata lives outside the asset, the asset is incomplete. ADAC addresses this by placing all metadata inside the container alongside the master file. The container is the complete, self-describing unit of preservation. ### §2.3 The Cross-Domain Challenge Different professional domains require different metadata overlaid on the same underlying archival asset. A digitized census page is simultaneously a genealogical source record, a legal document for inheritance claims, and a cultural heritage artifact for a national archive. Each domain has its own vocabulary, its own required fields, and its own professional standards. No existing format provides a standardized mechanism for additive, domain-specific extensibility. Formats designed for one domain — genealogical GEDCOM files, legal discovery load files, archival METS/PREMIS packages — cannot easily accommodate metadata from another domain without modification or data loss. The result is duplication: the same master file is packaged multiple times in different formats for different audiences, with no guarantee that the copies remain synchronized. ADAC solves this with its profile extension mechanism. Multiple domain profiles coexist in a single container, each adding its own metadata in a namespaced, non-conflicting structure. A reader that does not understand a particular profile simply ignores it — without failure and without data loss. ### §2.4 The Integrity Gap Most digital asset formats lack built-in cryptographic verification. When checksums exist, they are typically external — stored in a separate manifest file, a database field, or a sidecar document. These external checksums are subject to the same fragility as external metadata: they can be lost, separated, or corrupted independently of the asset they protect. In many workflows, checksums are optional or absent entirely. An image file can be silently modified — metadata stripped, pixels altered, resolution changed — with no mechanism to detect the change. For legal, archival, and evidentiary use cases, this is unacceptable. Proving that a document has not been altered since a specific point in time requires cryptographic fixity that is embedded within the container, chained to a provenance log, and optionally attested by digital signatures. ADAC embeds a SHA-256 checksum manifest inside every Archival-conformant container. The provenance log records every event in the container's history as a hash-chained sequence. Signed Archival containers add Cryptographic Message Syntax (CMS) detached signatures, enabling each custody event to be cryptographically attested. --- ## §3 Architecture ### §3.1 Design Principles ADAC 1.0 is built on eight design principles. These principles govern every structural and format decision in the specification. | Principle | Description | |---|---| | **Self-describing** | Every container carries all information needed to understand its contents. No external database, catalog, or application is required to interpret the asset, its metadata, its provenance, or its integrity. | | **ZIP-based** | The container uses the standard ZIP archive format. Any ZIP utility can open an ADAC file. No proprietary reader is required for basic access. | | **Living archive** | Containers are designed to be opened, enriched, and re-saved over their lifetime. Metadata grows; the container evolves. The archive is not a sealed tomb but a living document. | | **Master immutability** | Master files are the only immutable content in the container. Their SHA-256 checksum is their identity seal. All other content — metadata, annotations, derivatives — may be added, updated, or extended. | | **Additive extensibility** | Domain profiles add metadata without modifying core structures. New profiles can be introduced without changing the core specification or affecting existing profiles. | | **Graceful ignorance** | Readers that do not understand a profile or extension skip it without failure. A minimal reader can fully process any ADAC container by ignoring content it does not recognize. | | **Round-trip fidelity** | Implementations MUST preserve all fields they do not explicitly modify. Opening and re-saving a container MUST NOT discard unknown properties, unrecognized profiles, or metadata from other domains. | | **Forward compatibility** | Unknown JSON properties are preserved, not discarded. Future versions of the specification may introduce new fields; existing implementations carry them through without loss. | ### §3.2 The Four-Layer Architecture ADAC organizes container content into four layers. Layer 1 is required for all conformant containers. Layers 2 through 4 are independently optional and additive — each layer enriches the container without modifying lower layers. | Layer | Components | Description | |---|---|---| | **Layer 1 — Core Package** | `manifest.json`, `core.json`, `master/`, `derivatives/` | Identity, descriptive metadata, and artifact files. This is the minimum required content for a Minimal-conformant container. The manifest serves as the root index; core metadata provides Dublin Core-aligned descriptive fields; master files store the original, uncompressed archival assets; derivatives hold regenerable working copies. | | **Layer 2 — Provenance and Integrity** | `provenance/log.json`, `checksums.json` | Chronological event history and SHA-256 fixity for every file in the container. The provenance log records every significant event — creation, annotation, transfer, signature — as a hash-chained sequence. The checksum manifest provides cryptographic fixity verification. Required for Archival conformance. | | **Layer 3 — Enrichment** | `regions/`, `edits/`, `metadata/xmp/` | Region annotations define bounded areas of a master file (pixel rectangles, time segments, coordinate ranges) with linked entities. Edit pipelines store non-destructive JSON operation sequences. XMP sidecars provide interoperability with Adobe and imaging tools. | | **Layer 4 — Domain Profiles** | `metadata/profiles/*.json` | Additive, domain-specific metadata extensions. Each profile file contains a namespaced metadata structure (Genealogy, Legal, Preservation, or custom profiles) that enriches the container without modifying core structures. Linked entities use namespaced keys (e.g., `genealogy:person`, `legal:exhibit`) to avoid conflict when multiple profiles coexist. | ### §3.3 Physical Container Format An ADAC container uses the `.adac` file extension and is a standard ZIP archive conforming to the ZIP File Format Specification [ZIP-APPNOTE]. Master files are stored uncompressed within the archive to preserve bit-level integrity and enable efficient random access. All metadata files use UTF-8 encoded JSON. The directory structure of a fully populated ADAC container is as follows: ``` manifest.json master/ derivatives/ metadata/ core.json structure.json (optional) xmp/ (optional) profiles/ (optional) regions/ (optional) edits/ (optional) provenance/ log.json checksums.json signatures/ (optional) ``` The `manifest.json` file serves as the root index of the container. It declares the ADAC version, the container identifier, and the list of all files contained in the archive. The `metadata/core.json` file provides Dublin Core-aligned descriptive metadata and PREMIS preservation context. The `master/` directory holds original, immutable master files. The `derivatives/` directory holds regenerable working copies. The `provenance/` directory holds the event log and checksum manifest. The `regions/`, `edits/`, `metadata/xmp/`, `metadata/profiles/`, and `signatures/` directories are optional and present only when the container includes the corresponding content. ### §3.4 Conformance Levels ADAC defines three conformance levels. Each level builds on the previous one, adding requirements for increasingly rigorous preservation and evidentiary use. | Conformance Level | Requirements | Suitable For | |---|---|---| | **Minimal** | `manifest.json` + `core.json` + at least one file in `master/` | Simple packaging. Suitable for bundling a digital asset with its descriptive metadata when provenance tracking and cryptographic fixity are not required. | | **Archival** | Minimal requirements + `provenance/log.json` + `checksums.json` | Long-term preservation. Suitable for institutional archives, digital preservation programs, and any use case where provenance history and integrity verification are required. | | **Signed Archival** | Archival requirements + CMS detached signatures in `signatures/` | Evidentiary and legal use. Suitable for legal exhibits, regulatory compliance, chain-of-custody documentation, and any use case where cryptographic attestation of authenticity is required. | --- ## §4 The Format and Profile Model ### §4.1 Core Format Overview The ADAC core specification defines the following components: **Manifest.** The `manifest.json` file is the root index of the container. It declares the ADAC specification version (`adacVersion`), the container's unique identifier, creation and modification timestamps, and a complete inventory of all files in the archive with their relative paths and MIME types. **Core metadata.** The `metadata/core.json` file provides Dublin Core-aligned descriptive fields — title, creator, date, subject, description, rights, and related identifiers — augmented with PREMIS preservation context including format identification, creating application, and original filename. **Master files.** Files in the `master/` directory are the original, unmodified archival assets. They are stored uncompressed within the ZIP archive. Master files are immutable: their SHA-256 checksum, recorded in `checksums.json`, serves as their identity seal. Any modification to a master file invalidates the container's integrity. **Derivatives.** Files in the `derivatives/` directory are regenerable working copies derived from the master — thumbnails, access copies, format conversions, or optimized versions for specific use cases. **Region annotations.** Files in the `regions/` directory define bounded areas of a master file — pixel rectangles on images, time segments in audio or video, or three-dimensional coordinate ranges — with linked entities that attach domain-specific data to spatial regions. **Edit pipelines.** Files in the `edits/` directory store non-destructive edit sequences as ordered JSON operation arrays. Each operation describes a transformation (crop, rotate, adjust levels, apply filter) that can be replayed to reproduce a derivative from the master without altering the master itself. **XMP sidecars.** Files in the `metadata/xmp/` directory provide Extensible Metadata Platform (XMP) metadata for interoperability with Adobe tools and imaging workflows. **Provenance log.** The `provenance/log.json` file records every significant event in the container's history — creation, annotation, metadata update, transfer, signature — as a chronological, hash-chained sequence. Each event entry includes a timestamp, actor, event type, description, and a SHA-256 hash of the previous entry, forming an append-only audit trail. **Checksum manifest.** The `checksums.json` file provides a SHA-256 hash for every file in the container. Implementations use this manifest to verify that no file has been modified, corrupted, or tampered with since the checksums were last computed. ### §4.2 The Profile Extension Mechanism Profiles are the mechanism by which ADAC supports domain-specific metadata without modifying the core specification. The profile extension mechanism operates under the following rules: Profile metadata files reside at `metadata/profiles/.json`. Each profile file includes a wrapper object with three required properties: `profileName` (or `profileId`), which uniquely identifies the profile; `profileVersion`, which declares the profile specification version; and `schemaRef`, which provides a URI reference to the profile's JSON Schema for validation. Profiles are purely additive. A profile MUST NOT redefine, override, or constrain any core-specification field. Profile metadata extends the container; it does not modify the container's core structures. A non-profile-aware reader can open and fully process any ADAC container by ignoring profile files. The core specification guarantees that all information necessary to identify, describe, and verify the asset is available without reading any profile. Profiles add domain-specific enrichment; they do not gate basic access. Multiple profiles coexist in a single container. Each profile uses namespaced linked-entity keys to avoid naming conflicts. For example, a container carrying both a Genealogy and a Legal profile uses `genealogy:person` for person annotations and `legal:exhibit` for exhibit annotations. The namespace prefix ensures that keys from different profiles never collide. ### §4.3 Linked Entities The linked entity mechanism is the bridge between spatial regions of a master file and domain-specific metadata. Each region annotation includes a `linkedEntities` dictionary — a JSON object whose keys are namespace-prefixed type strings (e.g., `genealogy:person`, `legal:exhibit`, `legal:redaction`) and whose values are structured metadata objects defined by the corresponding domain profile. Linked entities attach domain-specific data to precisely defined areas of a master file. For images, these areas are pixel rectangles defined by x, y, width, and height coordinates. For audio and video, these areas are time segments defined by start and end timestamps. For three-dimensional assets, these areas are coordinate ranges in three-dimensional space. This mechanism enables a single master file to carry annotations from multiple domains simultaneously. A region on a census page image might carry a `genealogy:person` entity with a transcribed name and birth date alongside a `legal:exhibit` entity with a Bates number and confidentiality designation — each stored under its own namespaced key, each independently readable by its respective domain tooling. ### §4.4 Jurisdiction Profiles (Legal) The ADAC-Legal profile specification uses a hierarchical jurisdiction profile model to accommodate the diversity of legal traditions and procedural requirements across jurisdictions worldwide. **Base layer.** The ADAC-Legal specification defines jurisdiction-neutral concepts, schema structures, and controlled vocabulary. All jurisdiction profiles inherit from and extend this base layer. The base layer covers matter references, document classification, chain of custody, privilege logging, and production tracking in terms that are meaningful across legal traditions. **Country layer.** Country-specific profiles add jurisdiction-specific values, document types, and procedural terminology. For example, ADAC-Legal-US adds U.S. federal court document types, Federal Rules of Civil Procedure terminology, and common-law-specific controlled vocabulary values. **Subdivision layer.** Subdivision-specific profiles further specialize for unique legal traditions within a country. For example, ADAC-Legal-US-LA adds Louisiana civil law terminology, civil code document types, and notarial archive references. ADAC-Legal-US-PR adds Puerto Rico mixed civil/common law terminology and bilingual document classification support. The naming convention follows ISO 3166 codes: `{country}` for country profiles, `{country}-{subdivision}` for subdivision profiles. The identifier `"us"` denotes the United States; `"us-la"` denotes Louisiana; `"us-pr"` denotes Puerto Rico. > **NOTE** — Only the U.S. jurisdiction family (ADAC-Legal-US, ADAC-Legal-US-LA, ADAC-Legal-US-PR) has been validated and published as of ADAC 1.0. The base ADAC-Legal specification is jurisdiction-neutral and designed to support common law, civil law, mixed, and religious law traditions. Additional jurisdiction profiles (UK, AU, CA, DE, FR, and others) are planned as the ecosystem matures. See §8 Roadmap. --- ## §5 Validated Profile Extensions ### §5.1 ADAC-Genealogy 1.0 (Stable) The ADAC-Genealogy profile is designed for digitized genealogical records — census pages, vital records (birth, marriage, death certificates), church registers, land deeds, immigration manifests, probate records, and military service documents. The profile provides the following capabilities: **Structured source citations.** Each container carries a complete, structured source citation with fields for archival repository, collection title, record group, series, box, folder, microfilm roll and frame numbers, and jurisdiction metadata. Citations follow established genealogical standards and are machine-readable for automated cross-referencing. **Per-region person annotations.** The `genealogy:person` linked entity type provides structured fields for transcribed name components (given, surname, prefix, suffix), transcribed text, confidence scores for each transcription, and legibility assessments. Each annotation ties a specific person's information to a precise spatial region of the digitized record. **Genealogical Proof Standard (GPS) evidence classification.** Annotations support GPS evidence classification — original versus derivative, primary versus secondary information, direct versus indirect evidence — enabling researchers to assess source quality and build proof arguments using professional genealogical methodology. **Cross-source correlation.** The profile supports correlation notes linking annotations across multiple ADAC containers, enabling researchers to build multi-source proof arguments for identity conclusions. **Multi-page record linking.** Records that span multiple pages (multi-page census schedules, multi-page wills, continued register entries) are linked through the container's structure metadata, preserving the logical unity of the record. **GEDCOM and FamilySearch cross-references.** Annotations support external identifier fields for GEDCOM 7.0 individual identifiers and FamilySearch person identifiers, enabling interoperability with existing genealogical software ecosystems. Lead author: John Vaden. ### §5.2 ADAC-Legal 1.0 (Stable) The ADAC-Legal profile is designed for legal documents — exhibits, pleadings, contracts, depositions, court orders, affidavits, discovery productions, and regulatory filings. The profile provides the following capabilities: **Matter references.** Each container carries a structured matter reference with fields for tribunal, jurisdiction, docket or case number, caption, named parties, and matter type. This connects every legal document to its case context. **Document classification.** Documents are classified by type with sequential production numbering (a generalized form of Bates numbering), confidentiality levels (public, confidential, highly confidential, attorneys-eyes-only), and retention policies with scheduled destruction or permanent preservation dates. **Chain of custody.** The profile maintains a chronological chain-of-custody record documenting every handler of the document from initial receipt through archival storage. Each custody entry records the custodian, the date and time of transfer, the purpose, and the handling conditions. **Cryptographic chain of custody.** When combined with ADAC's Signed Archival conformance level, each custody event is attestable via CMS detached signatures. This provides cryptographic proof that a specific custodian held the document at a specific time — a capability essential for evidentiary use. **Legal privilege logging.** The profile supports privilege designations (attorney-client, work product, joint defense) with basis descriptions, privilege holders, and privilege log entry identifiers for regulatory and litigation hold compliance. **Preservation hold notices and production tracking.** Documents can carry preservation hold metadata (hold identifier, issuing authority, scope, effective dates) and production tracking fields (production identifier, producing party, receiving party, production date, production format). **Per-region annotations.** The profile defines three linked entity types for region annotations: `legal:exhibit` for exhibit markings, Bates ranges, and authentication notes; `legal:redaction` for redaction regions with legal authority citations, redacting party, and redaction category; and `legal:privilege` for privilege-protected regions with privilege type and privilege holder. The ADAC-Legal specification is jurisdiction-neutral at its base. Companion jurisdiction profiles provide locale-specific terminology, document types, and procedural vocabulary for specific legal traditions. Lead author: Mark Roman. | Profile | Identifier | Legal Tradition | Status | |---|---|---|---| | ADAC-Legal-US | `"us"` | United States — common law (federal and most states) | Stable | | ADAC-Legal-US-LA | `"us-la"` | Louisiana — civil law tradition within a common law country | Stable | | ADAC-Legal-US-PR | `"us-pr"` | Puerto Rico — mixed civil/common law tradition | Stable | ### §5.3 ADAC-Preservation 1.0 (Draft) The ADAC-Preservation profile is designed for archival institutions, libraries, museums, and digital preservation programs. The profile provides the following capabilities: **Structured archival description.** Metadata fields aligned with the International Standard Archival Description (General) — ISAD(G) — and Describing Archives: A Content Standard (DACS) conventions, including fonds, series, sub-series, file, and item-level description. **Accession and ingest metadata.** Structured records for accession number, accession date, donor information, transfer method, ingest workflow identifier, and ingest validation results. **Custodial history.** A narrative and structured custodial history field documenting the chain of ownership and custody from creation through acquisition by the holding institution. **Arrangement hierarchy.** Metadata describing the position of the asset within the institution's arrangement scheme — collection, record group, series, box, folder — enabling reconstruction of intellectual and physical order. **Preservation planning and risk assessment.** Structured fields for format risk assessment, migration planning, normalization targets, and preservation action records aligned with PREMIS (Preservation Metadata: Implementation Strategies), FADGI (Federal Agencies Digital Guidelines Initiative), and Metamorfoze preservation imaging standards. **Rights and restrictions.** Metadata for intellectual property rights, donor restrictions, access conditions, reproduction permissions, and deaccession or disposition records with authorization and justification fields. **Per-region annotations.** The profile supports region annotations for stamps, seals, marginalia, inscriptions, and condition issues (tears, stains, fading, foxing) — enabling granular documentation of the physical characteristics of the original artifact as captured in the digitized image. The ADAC-Preservation profile is designed to coexist with other profiles. An institutional archive can apply both the Preservation and Genealogy profiles to a digitized vital record, or both the Preservation and Legal profiles to a digitized court document, without conflict. > **NOTE** — ADAC-Preservation 1.0 carries Draft status. Its schema structures are substantively complete but have not yet undergone the formal validation and community review cycle applied to the Genealogy and Legal profiles. Implementers should expect non-breaking refinements before the profile reaches Stable status. --- ## §6 Governance and Stewardship ### §6.1 The ADAC Standards Project The ADAC Standards Project is the public-facing initiative responsible for the development, publication, and maintenance of all ADAC specifications and profile extensions. The project is stewarded by InnoVadens, LLC, which holds copyright and trademark rights to the ADAC specifications, the ADAC name, and the ADAC logo. The project was founded by John Vaden. Only documents published at [https://adac-standard.com/specs/](https://adac-standard.com/specs/) are considered official and normative. Draft documents, working papers, discussion documents, and community proposals published elsewhere do not carry normative authority unless and until they are formally published at the official specification site. ### §6.2 Specification Licensing All ADAC specifications are licensed under Creative Commons Attribution–NoDerivatives 4.0 International (CC BY-ND 4.0). Under this license, any person or organization is free to copy and redistribute the specification in any medium or format for any purpose, including commercial use, provided that: - Appropriate attribution is given to InnoVadens, LLC, as the publisher. - No modifications are made to the specification text. Derivative specifications may not be published under the ADAC name. Implementations may freely reference the specification. Software that implements the ADAC format does not require a license from InnoVadens, LLC. The CC BY-ND 4.0 license applies to the specification documents themselves, not to software that reads or writes ADAC containers. ### §6.3 Code and Implementation Licensing Reference implementations and proof-of-concept tools developed by the ADAC Standards Project are open source. Code repositories are hosted on GitHub under the InnoVadens organization. Each repository declares its specific open-source license in its root directory. ### §6.4 Trademark "ADAC" and the ADAC logo are trademarks of InnoVadens, LLC. Software implementations may state that they "implement the ADAC Specification" or are "ADAC-compatible" provided such statements are accurate and not misleading. Use of the ADAC name in product names, service names, or organization names requires prior written authorization from InnoVadens, LLC. --- ## §7 Use Cases ### §7.1 Institutional Digital Preservation Archives, museums, university libraries, and cultural heritage institutions use ADAC to ingest, describe, and preserve digitized collections with full provenance and fixity guarantees spanning decades. Each digitized asset is packaged with its complete descriptive metadata (Dublin Core-aligned fields in `core.json`), its PREMIS-aligned preservation context, a SHA-256 checksum manifest for integrity verification, and a hash-chained provenance log documenting every event from digitization through archival storage. The self-describing nature of ADAC containers eliminates dependence on external cataloging databases for long-term intelligibility. The standard ZIP-based format ensures no vendor lock-in — any future system can open the container using commodity tools, regardless of the technology landscape at the time of access. ### §7.2 Genealogical Record Preservation Libraries, archives, and family history researchers use ADAC-Genealogy to embed structured source citations, person annotations, and GPS evidence analysis directly into digitized genealogical records. A digitized census page carries its archival citation (repository, collection, microfilm roll, frame number), its person-level annotations with transcribed names and vital data, and its evidence classification (original/derivative, primary/secondary, direct/indirect) — all within the container itself. AI-assisted transcriptions carry confidence scores and legibility assessments, enabling researchers to evaluate transcription reliability. Multi-page record linking preserves the logical structure of records that span multiple pages. GEDCOM 7.0 and FamilySearch cross-reference identifiers enable seamless integration with existing genealogical software platforms. ### §7.3 Legal Document Management Law firms, courts, and compliance teams use ADAC-Legal to embed case references, Bates numbering, chain-of-custody records, and redaction metadata directly into exhibits, pleadings, and contracts. The validated U.S. jurisdiction family provides jurisdiction-specific terminology and document types for federal common law practice, Louisiana civil law practice, and Puerto Rico mixed-tradition practice. Signed Archival conformance enables cryptographic attestation of custody events — each handler's receipt of the document is verifiable through CMS detached signatures. Privilege annotations, preservation hold metadata, and production tracking fields support the full lifecycle of legal document management from initial collection through production and archival retention. ### §7.4 Multi-Profile Coexistence A single ADAC container MAY carry multiple profiles simultaneously. This capability enables cross-domain use cases that would otherwise require duplicating the master file across multiple format-specific packages. Example: A probate document — a digitized last will and testament — carries both an ADAC-Legal profile and an ADAC-Genealogy profile. The Legal profile contributes a matter reference (probate case number, tribunal, jurisdiction), a chain-of-custody record, and a confidentiality designation. The Genealogy profile contributes person annotations with transcribed names and relationships, structured source citations, and GPS evidence classifications. Linked entity keys use distinct namespaces (`legal:exhibit` vs. `genealogy:person`) to prevent conflict. Both profiles are independently readable; a genealogy application ignores the Legal profile, and a legal application ignores the Genealogy profile. ### §7.5 Production Asset Management Film studios and production houses use ADAC to bundle raw footage, audio tracks, edit decision lists, and production metadata into single, verifiable containers for archive and handoff between departments. The non-destructive edit pipeline mechanism stores color grading decisions, audio adjustments, and assembly edits as JSON operation sequences — preserving the original raw assets while documenting every creative decision in a reproducible format. The provenance log records every handoff between departments — camera, editorial, color, sound, visual effects, final assembly — creating an auditable chain of creative custody. The checksum manifest ensures that raw assets arrive at each stage unmodified. --- ## §8 Roadmap ### §8.1 Near-Term (2026–2027) - Advance ADAC-Preservation 1.0 from Draft to Stable status through formal validation and community review. - Develop and validate additional ADAC-Legal jurisdiction profiles — UK, Australia, Canada, and selected EU jurisdictions are under evaluation. - Expand proof-of-concept implementations with additional language bindings (Python, Java, TypeScript) and platform integrations. - Publish implementation guides and conformance test suites for the core specification and all Stable profile extensions. - Engage with standards bodies, archival institutions, and legal technology organizations for feedback, review, and adoption. ### §8.2 Medium-Term (2027–2028) - Explore additional domain profiles based on community demand — medical imaging, engineering drawings, and cultural heritage objects are candidate domains. - Develop interoperability bridges with existing digital preservation systems, including Archivematica, Preservica, and DSpace. - Evaluate formal standardization pathways through ISO, OASIS, or equivalent international standards bodies. - Build out the ADAC validator ecosystem with automated conformance testing for all profiles and jurisdiction extensions. ### §8.3 Long-Term Vision ADAC aspires to become a universally adopted, open archival container format that ensures every digital asset — regardless of domain, jurisdiction, or technology generation — can be fully understood, verified, and preserved using nothing more than the container itself. The long-term vision is a world in which the question "Can we still read this file in fifty years?" is answered not by the survival of a particular software vendor or database server, but by the self-describing completeness of the container that holds it. --- ## §9 Citation and Versioning ### §9.1 How to Cite This Document Vaden, J. (2026). "ADAC 1.0 — White Paper: A Self-Describing, Living Archive for the World's Digital Assets." Version 1.0. InnoVadens, LLC. Available at [https://adac-standard.com](https://adac-standard.com). ### §9.2 How to Cite the ADAC Specifications **Core specification:** "ADAC 1.0 — Archival Digital Asset Container Format Specification." Version 1.0, 2026. InnoVadens, LLC. **Profile specifications:** "[Profile Name] — [Domain] Profile Specification." Version X.Y, 2026. InnoVadens, LLC. Example: "ADAC-Genealogy 1.0 — Genealogical Record Profile Specification." Version 1.0, 2026. InnoVadens, LLC. ### §9.3 Versioning Rules ADAC specifications use MAJOR.MINOR versioning. MAJOR version increments signal breaking changes that may require implementation updates. MINOR version increments signal additive, backward-compatible changes that introduce new optional features without affecting existing implementations. A container marked `adacVersion: "1.x"` MUST be fully readable by any implementation supporting ADAC 1.0. Forward-compatible reading is guaranteed within a major version: a reader built for ADAC 1.0 can process a container marked ADAC 1.3 by preserving unknown properties and ignoring unrecognized optional features. Profile extensions maintain independent version numbers. Each profile declares the minimum core specification version it requires. A profile version increment does not require a core specification version increment. --- ## §10 References ### §10.1 Normative References **[ADAC-CORE]** ADAC 1.0 — Archival Digital Asset Container Format Specification. Version 1.0, 2026. InnoVadens, LLC. **[RFC2119]** Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. **[RFC8174]** Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words," BCP 14, RFC 8174, May 2017. **[JSON-SCHEMA]** Wright, A., Andrews, H., Hutton, B., "JSON Schema: A Media Type for Describing JSON Documents," Draft 2020-12. **[ISO8601]** International Organization for Standardization, "Date and time — Representations for information interchange," ISO 8601:2019. **[DCMI]** Dublin Core Metadata Initiative, "Dublin Core Metadata Element Set, Version 1.1," DCMI Recommendation, 2012. **[PREMIS]** Library of Congress, "PREMIS Data Dictionary for Preservation Metadata," Version 3.0, 2015. ### §10.2 Informative References **[ADAC-GENEALOGY]** ADAC-Genealogy 1.0 — Genealogical Record Profile Specification. Version 1.0, 2026. InnoVadens, LLC. **[ADAC-LEGAL]** ADAC-Legal 1.0 — Legal Document Profile Specification. Version 1.0, 2026. InnoVadens, LLC. **[ADAC-LEGAL-US]** ADAC-Legal-US 1.0 — United States Jurisdiction Profile. Version 1.0, 2026. InnoVadens, LLC. **[ADAC-PRESERVATION]** ADAC-Preservation 1.0 — Preservation Profile Specification. Version 1.0 (Draft), 2026. InnoVadens, LLC. **[ADAC-STYLE]** ADAC Specification Style Guide. Version 1.0, 2026. InnoVadens, LLC. **[ZIP-APPNOTE]** PKWARE, Inc., "ZIP File Format Specification," APPNOTE.TXT, Version 6.3.10. **[XMP]** ISO 16684-1:2019, "Extensible metadata platform (XMP) specification." **[GEDCOM7]** The Church of Jesus Christ of Latter-day Saints, "The FamilySearch GEDCOM Specification," Version 7.0, 2021. --- ## Version History | Version | Date | Summary of Changes | |---|---|---| | 1.0 | 2026 | Initial publication. Covers ADAC 1.0 core specification, three profile extensions (Genealogy, Legal, Preservation), U.S. Legal jurisdiction family, governance, use cases, and roadmap. | --- *© 2026 InnoVadens, LLC. All rights reserved. | ADAC 1.0 White Paper v1.0*