The Standard

Status of this draft

Draft 0.1 describes OAE as its own standard, with a path from EPUB, and proposes two parts, at different stages:

• Part A, Rights and permissions, is a proposal for discussion. The data model is new and has no implementations yet. Its examples are fictional.
• Part B, Versioning and version check, records a model already in use. The A&A AI SafeStep™ guidebooks publish their frozen versions, latest redirect and version-check record this way, and those are the source of every Part B example.

Points not yet settled are collected under Open questions.

Terms

• Rights holder: a person or organization that holds rights in a work, such as an author, an estate or a publisher, or an agent acting for them.
• Use: a specific thing done with a work’s content, such as AI questions and answers, a summary or a translation.
• Grant: one rights holder’s (or several rights holders’) specific permission for one use, with its scope, territory, term and attribution.
• Permissions record: a public JSON document listing an edition’s grants.
• Reading system: any app, device, website or service that presents an edition to a reader.
• Adaptive edition: an edition that publishes a permissions record and is issued in numbered versions, each kept at a permanent address with a version-check record.
• Key: the short, stable identifier for an edition, for example ollama.
• Content version, format version, verification date: see B5.

From EPUB to OAE

OAE is its own standard. It carries forward many features familiar from the latest EPUB 3.x, adds new capabilities for AI-enabled and immersive experiences, and aims to offer a clean path from EPUB to OAE.

EPUB® 3 is a W3C standard, developed and maintained by the W3C Publishing Maintenance Working Group. OAE is an independent organization in formation. It is not affiliated with W3C, and nothing on this site implies W3C endorsement.

Current EPUB 3.x status

As listed on W3C’s publication history pages, checked 8 October 2026.

Familiar features OAE carries forward

• Packaging: a single-file container, as in EPUB’s Open Container Format (OCF).
• Metadata: a package document with identifiers, titles, creators, a manifest of resources and a reading order.
• Content: XHTML (and SVG) content styled with CSS.
• Media overlays: text synchronized with prerecorded narration.
• Accessibility metadata, in the spirit of EPUB Accessibility.
• Reflowable and fixed layouts.

A clean migration path Proposed

1. An existing EPUB 3 publication maps into an OAE edition: its container, package metadata, content documents, media overlays and accessibility metadata carry across.
2. The publisher adds the rights-holder permissions record, listing each use the rights holders have specifically permitted.
3. The publisher adds the version record, so the edition has frozen versions, a latest pointer and a version check.
4. The publisher adds any new capability layers, each enabled only where a grant allows it.

Exactly which EPUB features map unchanged, and how an OAE edition is identified, are open questions.

New capabilities OAE adds

Proposed, for discussion. None of these capabilities is yet specified in full.

• Content that adapts to the reader: reading level, language, format and voice, accessibility needs, interactive and immersive layers, and AI help (Adapts to the reader).
• Machine-readable rights-holder permissions for AI and immersive uses (Part A).
• Version and verification records, with a QR version check for printed copies (Part B).
• Provenance and attribution through every version: who created, who authorized, and what changed.
• Permissioned AI interaction layers: questions and answers, summaries, translation and voice, each enabled only when a grant allows it.
• Immersive and interactive experience components, governed by the same permissions.

Adapts to the reader

An adaptive edition is content that truly adapts to the reader. The same work can meet each reader where they are, and rights-holder permissions are what unlock each adaptation: new use models and added value for readers, and new value for rights holders.

Proposed, for discussion. How a reader chooses an adaptation, and how a reading system shows which adaptations are permitted for a given edition, are open questions.

A1. Purpose

Part A gives rights holders one open, machine-readable way to say which uses of their work they have permitted, and gives reading systems one way to check before they act.

• Permission first. Every use requires specific, explicit permission from the rights holders and owners. A use that is not granted is not permitted.
• One use, one grant. Permission for one use never implies permission for another. Summaries do not imply translation; questions and answers do not imply model training.
• Supporting copyright. The record describes permissions that rights holders have given. It never creates a right to use a work.
• Visible to readers. A reader can see who authorized an experience.

A2. The permissions record

Each adaptive edition SHOULD publish a permissions record, proposed at /permissions/<key>.json, served without caching (Cache-Control: no-store) so that a change or withdrawal takes effect at the next check.

A fictional example, for discussion only:

{
  "oae_draft": "0.1",
  "edition": {
    "key": "example-title",
    "title": "Example Title",
    "content_version": "v2-0"
  },
  "rights_holders": [
    { "id": "rh-author",    "name": "A. N. Author",  "role": "author" },
    { "id": "rh-publisher", "name": "Example Press", "role": "publisher" }
  ],
  "default": "deny",
  "grants": [
    {
      "id": "g-001",
      "use": "ai_qa",
      "granted_by": ["rh-author", "rh-publisher"],
      "scope": { "source": "full_text", "answers_must_cite": true,
                 "max_quote_words": 50 },
      "territory": ["US", "CA"],
      "term": { "start": "2026-11-01", "end": "2027-10-31" },
      "attribution": "Answers drawn from Example Title by A. N. Author (Example Press).",
      "status": "active"
    },
    {
      "id": "g-002",
      "use": "translation",
      "granted_by": ["rh-publisher"],
      "scope": { "languages": ["es", "fr"],
                 "method": "machine_with_human_review" },
      "territory": ["WORLD"],
      "term": { "start": "2026-11-01", "end": "2028-10-31" },
      "attribution": "Translated with the permission of Example Press.",
      "status": "active"
    }
  ],
  "not_granted": ["ai_training", "audio_voice", "immersive"],
  "issued": "2026-10-08",
  "contact": "permissions@example.org"
}

• default MUST be "deny". Anything not granted is not permitted.
• rights_holders names every party whose permission the record reflects.
• grants lists each permitted use separately (see A4).
• not_granted is informative: it lets a rights holder state a refusal explicitly. Leaving a use out has the same effect.

A3. Uses

Draft 0.1 proposes this starting vocabulary. Each value in use names exactly one kind of use.

A4. Grant fields

A5. Checking before enabling

Before a reading system turns on any feature that uses an edition’s content, it MUST:

1. Identify the edition by its key and content version.
2. Fetch the edition’s current permissions record.
3. Find a grant whose use matches the feature, whose status is active, whose term includes today, whose territory includes the reader’s location, and whose scope covers what the feature will do.
4. If such a grant exists, enable the feature only within that scope, and show the grant’s attribution.
5. If no grant matches, leave the feature off.

A reading system SHOULD re-check at the start of each reading session and whenever the content version changes, and SHOULD let the reader see which grant an experience relies on.

A6. Change, revocation and provenance

• When a grant ends or is withdrawn, its status changes to withdrawn or it is removed; reading systems disable the feature at their next check.
• Changes to the permissions record SHOULD be dated and logged, in the same spirit as the change logs in B6.
• Readers and reading systems need to know the record was published by, or for, the rights holders it names. How that is verified is an open question.

A7. What this draft is not

A permissions record is a public statement of what rights holders have permitted. It is not a contract, a license or a legal opinion, and it does not replace the agreements between rights holders and the people they work with. Nothing in this draft is legal advice, and how it relates to the law in any particular country is a matter for those parties and their advisers.

B1. Frozen versions

Every content version of an edition is published at its own address, and a published address is never rewritten.

• Each content version MUST have a distinct address that includes the key and the version slug, e.g. /ll/ollama/v1-2/.
• Once published, the content at that address MUST NOT change. Printed copies, citations and catalog records depend on it.
• A new content version MUST be published at a new address. The previous version SHOULD remain available at its own.
• Frozen addresses SHOULD be served with long-lived, immutable caching.

The SafeStep guidebooks mark their frozen paths immutable:

{
  "source": "/:section(ll|followalong)/(.*)/v1-2/(.*)",
  "headers": [{ "key": "Cache-Control",
                "value": "public, max-age=31536000, immutable" }]
}

Version slugs use a hyphen (v1-2) in addresses and a point (“Version 1.2”) in print.

B2. The latest pointer

Each edition MUST offer one address that always leads to its current version: /<path>/<key>/latest.

• The latest pointer MUST be a temporary redirect, never a permanent one, because its target moves with each new version.
• Moving the pointer to a new version SHOULD be a one-line change; it never alters any frozen page.

{ "source": "/ll/:key/latest{/}?",
  "destination": "/ll/:key/v1-2/",
  "permanent": false }

B3. The version-check record

Each edition MUST publish a version-check record at /version-check/<key>.json, and a human-readable page for the same record at /version-check/<key>. Both MUST NOT be cached (Cache-Control: no-store): their only job is to be current.

This is the live record for the SafeStep Ollama guidebook, unchanged:

{
  "key": "ollama",
  "title": "AI SafeStep: Ollama",
  "series": "A&A Lifelong Learner Series",
  "catalog_code": "AA-HT-LL-OLL",
  "current_version": "v1-2",
  "format_version": "format-3",
  "labels_verified": "2026-09-20",
  "current_url": "/ll/ollama/latest",
  "versioned_url": "/ll/ollama/v1-2/",
  "follow_along_url": "/followalong/ll/ollama/v1-2/",
  "changes_since_previous": [
    "AI SafeStep checkpoint restyled: green header strip only, body set for plain reading",
    "Image captions carry the full https address, centred in a one-line strip",
    "Screen callouts replaced by lettered SafeStep marker tags placed beside their target"
  ],
  "is_out_of_date": false
}

You can read it as a page or as JSON.

Fields

Field names are taken from the live record. The required/optional column is a Draft 0.1 proposal.

B4. QR linking

A printed edition carries a QR code so that a reader holding paper can reach the version check in one step.

• The QR code MUST encode the human-readable version-check address for the edition’s key, e.g. https://openadaptiveeditions.org/version-check/ollama.
• The same address MUST be printed in full beside the code, so a reader without a camera can type it.
• The printed page SHOULD state the edition’s version next to the code (“Guidebook version: Version 1.2 · September 2026”), so the reader can compare it with the answer.
• The version-check address MUST keep working for as long as printed copies are in circulation.

B5. Content, format and verification layers

An adaptive edition reports three independent facts about itself:

The verification date is a promise, not a timestamp. In the words of the A&A Image and Caption Standard used by the SafeStep guidebooks: “on that date, a person opened that address and confirmed the picture matches.” A publisher MUST NOT advance the date without that check having happened.

B6. Change logs

• Each version-check record MUST list, in plain language, what changed since the previous version (changes_since_previous).
• Entries SHOULD be written for readers, not developers: what a person holding the old version would notice.
• References that printed copies rely on SHOULD stay stable across versions. The A&A Image and Caption Standard is an example: a replaced image keeps its number, and an added image takes the next free number (cited as “Image 7a”) rather than renumbering the rest.

The current Ollama record lists:

• AI SafeStep checkpoint restyled: green header strip only, body set for plain reading
• Image captions carry the full https address, centred in a one-line strip
• Screen callouts replaced by lettered SafeStep marker tags placed beside their target

B7. Accessibility

• The human-readable version-check page MUST work as plain HTML without scripts, at phone widths, and with assistive technology.
• The page MUST answer in plain words first (“This is the current version”) before any technical detail.
• Status MUST NOT be conveyed by color alone.
• A printed QR code MUST be accompanied by its full address in text, and in digital editions by alternative text, e.g. “QR code linking to the version check page for this guidebook”.
• Images in an edition SHOULD carry alternative text describing what a reader would see, written for someone who cannot see the picture at all.
• Adaptive editions should accommodate differences in language, culture, reading and learning styles, and individual abilities, and build on existing accessibility work rather than replacing it.

C1. Fields

Every permission item carries one state: allowed, ask-first or not-allowed, a one-line plain explanation (explain) and a plain howToAsk line. Status MUST NOT be conveyed by color alone.

C2. Mapping to existing standards

• W3C ODRL Information Model 2.2 and ODRL Vocabulary: allowed maps to an ODRL permission, ask-first to a permission with a consent duty, and not-allowed to a prohibition.
• W3C TDM Reservation Protocol (TDMRep): when ai.training is not allowed, publish tdm-reservation: 1 with a tdm-policy link to the title information record.
• schema.org: license and usageInfo link to the title information page; accessibility uses accessibilityFeature, accessMode and accessibilitySummary from the W3C discoverability vocabulary.
• ONIX for Books: the AI and copying states can be carried as usage constraints (usage type and usage status codelists) in trade metadata. The exact code mapping is an open question.

Open questions

Part A

1. How a reading system verifies that a permissions record was published by, or for, the rights holders it names (signatures, a registry, or both).
2. How to express that a use needs the permission of several rights holders, and which ones.
3. The starting vocabulary of uses (A3) and how new uses are added.
4. How scope details are expressed for each use, in a form both people and software can read.
5. How a reading system determines the reader’s territory, and what it does when it cannot.
6. Whether the permissions record and the version-check record should link to each other (for example a permissions_url field).
7. Relationship to existing rights-expression work and other standards. TBD

Part B

1. Relative or absolute addresses in the version-check record (B3).
2. Encoding the printed version in the QR code (B4).
3. How format-only updates are published without rewriting a frozen page (B5).
4. Full version history in the record (B6).
5. Required versus optional fields, and a formal schema (B3).
6. How a key is registered and kept unique across publishers. TBD
7. Which EPUB 3 features map unchanged into an OAE edition, and how an OAE edition is packaged and identified (see From EPUB to OAE).
8. How Part B records relate to EPUB package metadata (see From EPUB to OAE).

Process

1. The process by which this draft is reviewed and adopted. TBD

Comment on the draft →