# 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.93 — draft, published for review 2026-10-27 First drafted 2026-10-07 with cross-organization agents. Widened on 2026-10-27 with IPTC labels on assets and version 1.1 of the generative-AI profile. Both parts are listed below. ### Cross-organization agents (A2A) **Added:** `a2a` as a value of `task.executor.type` — the task is delegated to another party's agent over the [Agent2Agent protocol](/a2a), with `executor.ref` naming the skill on that agent's Agent Card. **Added:** `participant.agent_card` — where a remote agent publishes its card. Valid on kind `agent` only. **Added:** `task.delegation` `{ by, scope, expires_at }` — who handed the task across and the scope it carries. Scope may only narrow along a chain. See [Participants and authority](/participants-and-authority#agents-in-other-organizations-v093). **Added:** run attempts may carry a `remote` object recording the partner's task id and state. See [Run records](/runs#remote-attempts). **Added:** validator rules `OWG_A2A_PERFORMER_REQUIRED`, `OWG_A2A_PERFORMER_KIND`, `OWG_A2A_NO_AGENT_CARD`, `OWG_A2A_UNACCOUNTABLE`, `OWG_AGENT_CARD_KIND`, `OWG_DELEGATION_SELF` and `OWG_DELEGATION_WIDENS`. See [Validation](/validation#error-codes). **Why now:** A2A reached v1.0 in April 2026 and is built into the major cloud agent platforms, so work will cross organizations agent to agent. The protocol carries the task; it does not say what the task means, who may ask for it, or what happened across the whole chain. OWG already said all three for turnovers, which is why the change is small: each use case was written as a document and validated as both v0.92 and v0.93, and only the three fields above were needed. ### IPTC labels and the generative-AI profile 1.1 **Added:** `asset.iptc`, an optional object saying how the asset came to be in IPTC terms: - `DigitalSourceType`: one of the current IPTC NewsCodes, as the full URI; - `AISystemUsed`, `AISystemVersionUsed`, `AIPromptInformation` and `AIPromptWriterName`. Keys are the IPTC XMP names. Retired codes are rejected, and `x-` extensions are allowed. It replaces the v0.92 convention of placing the same object under `metadata.iptc`. See [IPTC](/iptc). **Added:** validator rule `OWG_IPTC_AI_MISMATCH`. It flags an asset whose Digital Source Type contradicts the `ai_role` of the task that produced it: - a generative task whose output claims no AI; - a `none` or `assistive` task whose output claims generative AI. An unset `ai_role` is left to [compliance rule R1](/compliance#the-baseline-rule-pack). See [Validation](/validation#error-codes). **Added:** version 1.1 of the generative-AI profile, at its own URL, [/schemas/profiles/generative-ai/v1.1.json](/schemas/profiles/generative-ai/v1.1.json). Version 1.0 is unchanged at `/schemas/profiles/generative-ai/v0.9.json`. For `comfyui_graph` it adds: - the graph inline (`graph`) or by reference (`graph_ref`). 1.0 required `graph` while describing `graph_ref` as the alternative. - typed `loras[]`, `passes[]`, `controls[]` and `size`; - asset roles for generation inputs (`init_image`, `mask`, `control_image`, `reference_image`); - the identifier scopes `comfyui.model`, `comfyui.input` and `comfyui.output`; - the subgraph format `comfyui.api_prompt`; - seven recording rules. Example descriptions no longer name vendors. See [ComfyUI](/comfyui). **Why now:** a production needs to say, per asset, whether AI made or changed it, and other systems already have a word for that: IPTC's Digital Source Type, which C2PA, IPTC photo and video metadata, and JPEG Trust all carry. Writing it as a free-form convention left it unreadable to a validator, so the record could disagree with itself unnoticed. Two test runs written by ComfyUI itself showed what a generation record has to get right; the article [Recording a ComfyUI run](/recording-comfyui-runs) walks through them. ### Fixes and compatibility **Fixed:** the reference validator now checks a `"0.92"` document against the v0.92 schema; it had been falling through to v0.9. **Compatibility:** fully additive. Every v0.92 document is a valid v0.93 document unchanged, and every generative-AI 1.0 document is valid under 1.1. A v0.92 document that carries `metadata.iptc` moves the object up one level to `iptc` when it declares v0.93. ## 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.` 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.