Open Workflow GraphPre-release
Ecosystem

Changelog

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

View as markdownMachine-readable source for agents and scripted implementers

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.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, 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.

Added: run attempts may carry a remote object recording the partner's task id and state. See Run records.

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.

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.

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. See Validation.

Added: version 1.1 of the generative-AI profile, at its own URL, /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.

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 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.

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.