Open Workflow GraphPre-release
Introduction

Overview

What the Open Workflow Graph is, the problem it solves, and how it relates to the standards already in your pipeline.

View as markdownMachine-readable source for agents and scripted implementers

The Open Workflow Graph (OWG) is a portable, vendor-neutral way to describe a media production workflow as data rather than as a diagram or a folder convention. An OWG document is a JSON file. It says what work happens, in what order, who or what performs it, which assets it consumes and produces, and where it runs — precisely enough that an engine can execute it and a query can audit it afterwards.

OWG is built on MovieLabs' Ontology for Media Creation (OMC). OMC supplies the vocabulary — the agreed names and relationships for assets, tasks, participants, and the contexts that give them meaning. OWG adds an execution and governance layer expressed in that vocabulary: a way to run on the ontology, hand pieces of a workflow across company lines, and answer questions about what happened. The layering is strict and one-directional:

  • OMC defines what things are.
  • OWG defines how work moves between them.
  • An implementation is one way to operate the result. Several are possible, and the specification favours none of them.

Nothing above the foundation redefines anything below it. An OWG document is OMC-conformant data with additional structure on top.

Status: v0.92, draft. OWG is an open specification published by Entertainment Technologists Inc., not a ratified industry standard. The schema, validator, and conformance corpus are open (Apache-2.0 code, CC-BY documentation).

v0.92 is the current version. The number reaches 1.0 once there is enough implementation experience behind the specification to promise compatibility — promising stability before anyone has built against a specification is how standards acquire mistakes they cannot remove. Pin the schema you validate against, and see Versioning and stability for how much movement to expect where.

The problem

Every studio, broadcaster, post house, and VFX vendor runs on the same quiet fiction: that the workflow exists somewhere in precise, shared, structured form. It does not.

  • It exists as tribal knowledge, redrawn from memory for each production and lost when the person holding it leaves.
  • It exists as a whiteboard sketch — often the single most accurate workflow document in the building — until the room is cleared.
  • It exists piecemeal inside tools: the production tracker knows the tasks, the asset manager knows the files, the render manager knows the jobs, and none of the three knows about the other two.

The consequence is that every hand-off is an act of faith. A comp returns to conform with no structured record of which artist touched it, on what plate, through how many rounds; it is reconciled by filename and hope.

This problem predates generative AI by decades and would be worth solving if not one AI tool existed in the pipeline. What AI changes is the price of never having solved it: it multiplies the volume and speed of work moving through exactly those gaps, and it introduces a participant — the autonomous agent — with no tribal memory to fall back on.

It also removes the last safeguard. Every one of those informal workflow records at least implied that a person had thought the plan through. Once workflows are generated rather than written, that stops being true, and the industry needs a way to establish that a plan is sound, bounded, and accountable before it runs, without a human reading each one. That argument is set out in full in Agentic workflows and certainty.

What OWG adds

A workflow expressed as an OWG document can be:

  • Saved and versioned like any other production asset, and reused across shows.
  • Shared with a vendor as a scoped subgraph rather than re-explained on a call.
  • Edited and reviewed collaboratively, with each change a recorded event.
  • Validated against a published schema before anything executes.
  • Executed by an engine, emitting provenance as a side effect rather than as an extra chore.
  • Written by an agent in the same format a human would use — and checked before it runs.

That last point is the one that matters most as pipelines fill with autonomous tools. An agent-authored workflow is only useful if you can trust it enough to execute; OWG makes that a matter of schema validation, named authority, honest confidence scores, and declared ceilings rather than of faith. See Agentic workflows and certainty for why that matters, then Validation and For agents for how it works.

A first look

The smallest useful OWG document is two tasks and a dependency between them:

{
  "owg_version": "0.92",
  "id": "transcode-to-webm",
  "description": "Normalize a source file, then encode WebM for web delivery",

  "participants": [
    { "id": "transcode_svc", "kind": "service" }
  ],
  "assets": [
    { "id": "source_mov", "role": "source", "type": "video" },
    { "id": "normalized_mp4", "role": "intermediate", "type": "video",
      "version_relation": "representation", "predecessor": "source_mov",
      "produced_by": "ingest" },
    { "id": "delivery_webm", "role": "delivery", "type": "video",
      "version_relation": "representation", "predecessor": "normalized_mp4",
      "produced_by": "web_delivery" }
  ],
  "tasks": [
    {
      "id": "ingest",
      "executor": { "type": "service", "ref": "transcode" },
      "ai_role": "none",
      "performed_by": "transcode_svc",
      "used": ["source_mov"],
      "produced": ["normalized_mp4"],
      "failure_mode": "HALT"
    },
    {
      "id": "web_delivery",
      "executor": { "type": "service", "ref": "transcode" },
      "ai_role": "none",
      "performed_by": "transcode_svc",
      "depends_on": ["ingest"],
      "used": ["normalized_mp4"],
      "produced": ["delivery_webm"],
      "failure_mode": "CONTINUE"
    }
  ]
}

Two things are doing the real work here. used and produced are the lineage — they make this a graph rather than a list, and they fall out of describing the work rather than being recorded separately. version_relation says how each output relates to its input: both hops are representation, a format change of the same content, not a revision of it.

Every larger workflow in this documentation — multi-vendor turnovers, live sports ingest, camera-to-consumer delivery with AI disclosure — is the same primitive composed at scale: a task, an executor, a used edge, a produced edge, an attributed participant.

Continue to the Quickstart to write and validate one, or Core concepts for the model behind it.

How OWG relates to other standards

OWG holds one disciplined rule: it references the asset-level objects of adjacent standards; it never absorbs their internals. A workflow graph that tried to mirror every scene primitive or every media segment would inherit the scale and semantics of other domains and collapse under them.

Each neighbouring standard owns a plane, and OWG occupies the one they each deliberately leave outside their scope:

PlaneWhat it holdsOwned by
Essence / timerangeThe bytes, addressed by identity and timeBBC TAMS
Spatial / compositionWhat a scene contains, how assets composeOpenUSD
Editorial / timeThe ordered cut — which timeranges, in what sequenceOpenTimelineIO
Creation-time markingSigned content credentials at the point of capture or generationC2PA
Governance / executionWhich versions exist, who made them, from what, under what authorityOWG, in OMC's vocabulary

Full field-level mappings are in Standards bindings.