# MDDF Avails

> How OWG governs an MDDF Avails document and Media Manifest as assets tied to the edit they describe, with validation and approval as tasks.

**Status:** buildable on v0.92 for the documents and the workflow around them. The licensing terms inside an Avails document stay opaque to OWG until the [rights binding](/rights-and-clearance) lands.

## What MDDF is

The MovieLabs Digital Distribution Framework (MDDF) is the family of specifications for moving finished content and its business terms from a publisher to a retailer. The [MDDF repository](https://github.com/MovieLabs/mddf) lists the components it supports:

- **Avails**, developed with the Entertainment Merchants Association (EMA), encodes when, where and under what business terms content becomes available: territory, license type and availability windows. It is at [v2.25](https://movielabs.com/md/avails/) (5 December 2025), comes as Excel and XML, and carries EIDR IDs.
- **Media Manifest Core** and **Common Media Manifest** describe the assets that make up a delivery.
- **Media Entertainment Core (MEC)** carries title metadata.
- **Asset Order and Delivery (AOD)** covers ordering and delivery.

MovieLabs publishes a [validator](https://movielabs.com/md/validator/) for these documents and a Java library, `mddf-lib`, that converts between the Excel and XML forms.

## The hook

Each MDDF document is an asset with its own identifier scope. The edit it describes carries its [EIDR IDs](/eidr), and the Avails document is tied to that edit by the task that built it.

```json
{
  "id": "avails_doc",
  "type": "document.avails",
  "content_type": "application/xml",
  "produced_by": "build_avails",
  "identifiers": [
    { "scope": "mddf.avails", "id": "urn:uuid:8d2e6a14-3b57-4f91-a0c3-5e7b1d9f2c68" }
  ],
  "metadata": {
    "x-mddf": { "component": "Avails", "version": "2.25", "format": "xml" }
  }
}
```

| MDDF | OWG |
|---|---|
| An Avails document | an `asset` with scope `mddf.avails` |
| A Media Manifest | an `asset` with scope `mddf.manifest` |
| The title or edit an Avails row describes | the edit `asset`, linked by the building task's `used` edge, carrying `eidr.title` and `eidr.edit` |
| Building the documents | a task with an executor and an attributed participant |
| Schema and content validation | a `qc` task with named `checks` |
| Business-affairs approval of terms | a `review` task, before the `delivery` task |
| Sending to a retailer | a `delivery` task whose `ran_on` infrastructure is the retailer's portal |

Other components, such as the Title List, MEC and AOD, follow the same pattern: a document asset with its own scope.

## Reference workflow

[`mddf-avails-offer.owg.json`](/corpus/mddf-avails-offer.owg.json) — an Avails document and Media Manifest are built for a registered edit, validated, approved by business affairs and sent to a retailer.

```bash
curl -O https://openworkflowgraph.org/corpus/mddf-avails-offer.owg.json
owg-validate mddf-avails-offer.owg.json --json
```

**What to take from it:**

- The `checks` include `eidr_ids_match_edit`. The validation task `used` the edit as well as the documents, so the cross-check has something to check against.
- Approval of the terms precedes sending, as an ordinary `depends_on` edge, and names who approved.
- The offer document is an asset with lineage, so a later question, such as which terms an edit was offered under, is a traversal.

## What stays in MDDF

OWG does not parse Avails rows, compute window overlaps or generate manifests. MovieLabs' validator and library do that, and can serve as the executor for the validation task. The MDDF documents remain the interchange format with retailers.

## Known gaps

- Territory, license type and window are inside the Avails document. To ask the graph *which edits are cleared for France in Q2*, those terms need to be structured nodes. The [rights binding](/rights-and-clearance) proposes that, with the Avails vocabulary supplying the terms.
- `mddf.avails` and `mddf.manifest` are conventions documented here. The schema's list of example scopes does not include them yet.
- OWG does not map the AOD component. It should be assessed with a design partner who orders through it.

See also: [EIDR](/eidr), [IMF](/imf), [Rights and clearance](/rights-and-clearance), [Standards bindings](/standards-bindings).