Changelog

Every entry here corresponds to a schema artifact at its own permanent URL — see 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.

Added: broadcast-newsroom profile (draft, v0.1) — the first profile to use the mechanism above, binding the Story Object Model (SOM) 1.0 onto OWG's context, asset, and relationship registries. Its registry_extensions are published at /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.

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, Run records → Fan-out attempts, and the failure-handling best practices.

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.

Why now: the existing guidance 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, Tasks and executors, and Run records for its complete surface — this changelog begins tracking forward from here rather than reconstructing v0.9's own history retroactively.