# Changelog

> What changed in each version of the specification, and when.

Every entry here corresponds to a schema artifact at its own permanent URL — see [Schema identity](/specification#schema-identity). A document that declares an older `owg_version` keeps validating against that version's schema; nothing here is retroactive.

## v0.92 — 2026-09-14

**Added:** an optional `profiles` object on `context`, `asset`, and `relationships[]` (additive) — a third profile kind alongside domain and vendor profiles, reserving one namespaced key per registry object so a profile can carry structured data on these registries, not only on `task.tool`. See [Profiles → Registry extension profiles](/profiles#registry-extension-profiles).

**Added:** `broadcast-newsroom` profile (draft, v0.1) — the first profile to use the mechanism above, binding the [Story Object Model](https://storyobjectmodel.com/) (SOM) 1.0 onto OWG's context, asset, and relationship registries. Its `registry_extensions` are published at [/schemas/profiles/broadcast-newsroom/v0.1.json](/schemas/profiles/broadcast-newsroom/v0.1.json).

**Why now:** SOM 1.0 publishes newsroom-specific structure, story lifecycle, evidential sourcing tiers, compliance-gated routing, that core has no reason to carry, by the same test that kept BBC TAMS's own domain detail out of core in v0.91: a field meaningless to a VFX or physical-production document doesn't belong where every implementer has to skip past it. The gap this closes is narrower than it sounds — most of SOM binds onto core unchanged (`delivery.media_available` already fits `asset.storage`; the `factual-news` disclosure-gate and editorial-signoff machinery already existed). What was missing was a place for the rest to live without widening core for everyone.

**Compatibility:** fully additive. Every v0.91 document is a valid v0.92 document unchanged. `profiles` is a new optional key on three registries; nothing existing was renamed, removed, or given a new required field.

**Not yet done:** the validator does not yet resolve a document's declared `profiles[]` against a registry-extension profile's schema and check the corresponding `.profiles.<id>` subtrees. Until that lands, this mechanism is schema-valid but not conformance-checked past L1 — see [Profiles → Conformance levels](/profiles#conformance-levels).

## v0.91 — 2026-09-05

**Added:** `task.fan_out` — repeat a task (and its `subgraph`, if it has one) over a list, concurrently up to a stated `max_concurrency`, with a `tolerated_failure_percentage` or `tolerated_failure_count` so the task can be treated as succeeded despite some instances failing. See [Fan-out](/tasks#fan-out-v091), [Run records → Fan-out attempts](/runs#fan-out-attempts), and the [failure-handling best practices](/failure-handling).

**Added:** validator rule `OWG_FANOUT_TOLERANCE_CONFLICT` — a `fan_out` declaring both tolerance fields at once is a validation error, not an ambiguity resolved silently at run time. See [Validation](/validation).

**Why now:** the [existing guidance](/implementation-considerations#fanning-work-out-over-a-collection) for repeating work — generate one task per item — holds up well into the tens of items, and stays the right default there. It stops holding at hundreds: a document isn't meaningfully reviewed at that size, and "did enough of them succeed" needs an answer the engine can check, not one a person derives from reading every row. The motivating case was several hundred concurrent instances of the same generation subgraph, run live, where a single unrelated instance failing had no business taking the other 499 down with it.

**Compatibility:** fully additive. Every v0.9 document is a valid v0.91 document unchanged — nothing was renamed, removed, or given new required fields. `fan_out` is v0.91-only: declaring it on a document whose `owg_version` is `"0.9"` is a validation error (the field is additive to the *schema*, not retroactively legal on documents targeting the version before it existed).

## v0.9 — draft

The version this documentation describes prior to v0.91. See [Document structure](/specification), [Tasks and executors](/tasks), and [Run records](/runs) for its complete surface — this changelog begins tracking forward from here rather than reconstructing v0.9's own history retroactively.