# Versioning and stability

> What v0.92 defines, how the specification versions, where it deliberately leaves room to extend, and what that means for building against it.

This page tells you what you can rely on. It covers what v0.92 defines, how stable each part is, and where the specification deliberately leaves room — so you can build against it with a clear picture of what will and will not move. See the [changelog](/changelog) for the version history itself.

## What v0.92 defines

v0.92 is v0.91 plus one addition — an optional `profiles` object on `context`, `asset`, and `relationships[]`, letting a profile carry structured, namespaced data directly on these registries rather than only on `task.tool`. Every v0.91 document remains valid; nothing was changed or removed. See [Profiles → Registry extension profiles](/profiles#registry-extension-profiles).

v0.91 was v0.9 plus one addition — `task.fan_out`, for repeating a task (and its subgraph) over a list with bounded concurrency and a tolerated-failure threshold, rather than one instance's failure aborting every instance depending on it. See [Fan-out](/tasks#fan-out-v091) and the [failure-handling best practices](/failure-handling) for when to reach for it instead of generating tasks or using `failure_mode: CONTINUE`.

The specification is complete for the workflows it describes. Its settled surface:

**The model**

- Five entity types — organizations, participants, infrastructure, assets, contexts — plus the tasks that connect them, with OMC's relationship vocabulary.
- A W3C PROV backbone: tasks are activities, assets are entities, participants are agents.
- Structural provenance edges (`used`, `produced`, `performed_by`, `ran_on`) as the authoritative lineage record.
- Typed version relations: `revision`, `variant`, `derivation`, `representation`, `alternative`.
- Three assurance levels, with `confidence` and `method` required on `inferred`.

**The document**

- One document class, with `owg_version` and `id` as the only required fields.
- `params` for run-time parameter injection.
- `governance` ceilings — re-route limits, spend limits, and the disclosure gate.
- Closed objects throughout, with `metadata`, `x-` prefixes, and (v0.92) a namespaced `profiles` object as extension points.

**The behaviour**

- Executors as an attribute, spanning human, service, agent, application, and generative work.
- Failure modes, compensation, retry with backoff, and gate routing with re-route ceilings.
- Bounded-concurrency fan-out over a list, with a tolerated-failure threshold (v0.91).
- Formal grammars for `$.` references and `when` expressions, with a defined run-state vocabulary.
- Four ordered validation passes and a complete error-code set.
- Subgraphs for nesting and for scoped hand-offs, with a specified turnover document shape.
- Run documents recording per-attempt status, cost, and actual infrastructure.
- Three testable conformance levels, and a baseline compliance rule pack.
- Bindings to OMC, OpenUSD, BBC TAMS, OpenTimelineIO, C2PA, and SOM — by reference, never by absorption.

## Stability by area

v0.92 is a draft version: the number reaches 1.0 when the specification has enough implementation experience behind it to promise compatibility. That is a deliberate sequencing choice — promising stability before anyone has built against a specification is how standards acquire mistakes they cannot remove.

Meanwhile, this is how much movement to expect:

| Area | Stability |
|---|---|
| Entity model, PROV mapping, version relations | **Stable.** Changing these would change what OWG is |
| Provenance edges, assurance levels | **Stable** |
| Document shape, required fields, `params`, `governance` | **Stable** |
| Reference and `when` grammars | **Stable.** Small and complete by design |
| Validation passes and error codes | **Stable.** Codes may be added; existing ones will not change meaning |
| Enum values (executor types, states, task types) | **Additive.** Expect new values, not removed ones |
| `identifiers[]` scopes, storage providers, relation predicates | **Open sets.** Designed to grow |
| Standards bindings | **Additive.** New bindings follow the existing pattern |
| Compliance rule identifiers | **Additive.** Fields are stable; the rule set grows |
| `subgraph`, nesting limits, turnover documents | **Stable.** Format discriminator, parameter interface, depth limit, and turnover shape are specified |
| Run documents | **Stable.** See [Run records](/runs) |
| Conformance level definitions (L1/L2/L3) | **Stable.** Each is defined testably |
| Compliance baseline rules R1–R6 | **Stable.** Packs may add and tighten, never remove |
| JSON-LD context coverage | **Additive.** Complete for v0.9 fields; grows with the schema |
| `fan_out` (v0.91) | **Additive, and new.** The two tolerance fields (`tolerated_failure_percentage`, `tolerated_failure_count`) are the part most likely to gain siblings — e.g. a per-tag tolerance — as real fan-outs surface cases this first cut does not cover |
| `profiles` on `context`/`asset`/`relationships[]` (v0.92) | **Additive, and new — and not yet validator-enforced.** The slot is stable; whether and how the validator resolves a named profile's `registry_extensions` against it is still open. See [Profiles → Registry extension profiles](/profiles#registry-extension-profiles) |

**Practical guidance:** pin the schema you validate against. Additive change is safe to ignore until you want it; pinning means you decide when to adopt it.

## Where the specification leaves room

Three extension mechanisms exist so that the core can stay small without becoming limiting. Using them is the intended path, not a workaround.

**Profiles** carry domain and vendor vocabulary. Two kinds: tool names, billing tiers, device types, and check identifiers for `task.tool`; and, since v0.92, structured data on `context`, `asset`, and `relationships[]` via the namespaced `profiles` object — used, for instance, by the `broadcast-newsroom` profile binding the Story Object Model. If you want a new value for `tool` or `billing.tier`, or a field meaningful only to one domain, it belongs in a profile, and profiles version independently of the core. See [Profiles](/profiles).

**`metadata`** is a freeform object on the document and on every entity. Anything you need to carry that the specification does not define goes here, and it survives round-trip untouched.

**`x-` prefixed keys** sit alongside specified fields for vendor extensions that want to be visible rather than nested in `metadata`.

**Open sets** — `identifiers[]` scopes, storage providers, relation predicates, participant and organization roles, task types, asset types — are strings rather than enums precisely so you can use a value the specification has not anticipated without waiting for a release.

What does **not** belong in an extension: anything the core already expresses. Duplicating a structural edge, or carrying a version relationship in `metadata` rather than in `version_relation`, produces a document that validates and interoperates poorly.

## Decisions left to implementations

The specification defines the format and what it must record. A set of decisions belongs to the systems built on it — storage design, federation strategy, matching technique, acceptance policy, enforcement mechanism, and confidence calibration.

That boundary is what makes the format portable: two implementations can differ substantially and still exchange documents losslessly. [Implementation considerations](/implementation-considerations) covers each of these decisions with a recommended approach and the reasoning behind it, and [Persistence requirements](/persistence) states the query capabilities an implementation must provide.

## Conformance

Three levels, each with a testable definition in [Profiles](/profiles#conformance-levels):

| Level | Needs | Tests |
|---|---|---|
| **L1** | The document | All four validation passes succeed |
| **L2** | The document plus its resolved profiles | Every `tool` is declared, and its inputs and outputs satisfy the declaration |
| **L3** | A [run document](/runs) | Every succeeded attempt records `performed_by`, `ran_on`, produced assets with identity and assurance, and a terminating authority chain |

A definition cannot be L3-conformant — only an execution can. State which level you mean; "OWG-conformant" alone is ambiguous.

The [conformance corpus](/conformance) exercises L1. It contains only documents expected to pass, so it demonstrates acceptance rather than correct rejection; write negative fixtures alongside it.

## Reading this documentation

Where these pages describe behaviour, they describe **what the specification requires** — not what any particular implementation currently does. When you rely on a validator, engine, or store you did not write, establish its actual coverage before treating a clean result as a guarantee.