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

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 and the failure-handling best practices 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
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

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.

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 covers each of these decisions with a recommended approach and the reasoning behind it, and Persistence requirements states the query capabilities an implementation must provide.

Conformance

Three levels, each with a testable definition in Profiles:

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