Core concepts

OWG describes a production with five node types, wired by named, typed relationships. Every workflow document, however large, is built from these and nothing else.

It helps to think of a production as an organism: five cell types inside one membrane (OMC), connected by a nervous system of typed edges.

The five node types

Participants

Every human, agent, service, or department that can act — each with an identity and a place in a hierarchy.

An agent always carries an operated_by reference (the participant on whose authority it acts) and an organization. So any asset traces back through the agent that produced it to the responsible human and organization. This is the backbone the rest of the model depends on: accountability is structural rather than procedural.

What it enables: zero-trust access, authorship records, traceable approvals, and AI disclosure that falls out of the data rather than being compiled by hand.

Tasks

The work itself — OMC's Task entity made executable.

Where a legacy pipeline hard-codes "call tool X", OWG generalizes the executor as an attribute. A task may run in a cloud service, at an external API endpoint, in a node-graph tool such as ComfyUI, in a desktop application such as Nuke, Houdini, or DaVinci Resolve on an artist's own workstation, in an autonomous agent, or in a human's hands. Treating "runs on cloud GPU", "runs in a DCC on a workstation", and "is a human review gate" as three values of one attribute is what puts AI and traditional work in a single accountable graph, interchangeably.

A task may also carry a subgraph — a nested OWG document — which is how a turnover hands a vendor exactly the context they need and nothing more.

What it enables: scheduling, per-step cost and QC, and human and machine work under one contract.

Assets

Typed, versioned content, each carrying a locator that identifies wherever it physically lives: a cloud bucket, on-premises storage, a SaaS asset manager, a camera card, or a drive in transit.

Assets carry their own governance — content identity (hash, C2PA manifest, URN), rights and clearances, copyright status, approvals, and a preservation policy with fixity records — rather than depending on whichever system happens to hold the bytes.

Critically, the relationship between versions is typed, not merely numbered. See Assets and versioning.

What it enables: lineage, instant rights answers, and archives that satisfy deep-library requirements by construction.

Infrastructure

Cloud compute, GPUs, workstations, on-premises render farms, and SaaS platforms in one topology, described by capability and environment.

Because a task records what it ran_on, cost attribution and multi-cloud portability are properties of the graph. Capability matching also lets an engine place work dynamically instead of relying on hand-routing.

What it enables: scheduling, cost attribution, multi-cloud portability.

Context

The show, sequence, scene, shot, or territory to which work belongs.

Tasks and assets are associated with a context rather than contained in it, because the same asset means different things in different places — a plate is one thing in the cut and another in a territory-specific master.

What it enables: scoping, per-context permissions, and views that match how productions actually think.

The provenance backbone

Beneath all five sits the W3C provenance model, PROV. The mapping is direct:

Every asset can therefore answer "which participant touched me, on whose authority" with no extra tooling, because the answer is simply the graph.

Building on PROV rather than inventing a provenance vocabulary is deliberate: it is a published W3C model with existing tooling, and it is the same choice C2PA made for content credentials.

Two design choices that matter

Definition and run are separate documents

A workflow definition is a static, reusable, versionable template. A run is one execution that references a definition.

This is what lets the same graph render two ways: as a plan before anything starts, and as a live status board while work is under way. It is also what makes a definition reusable across shows — the definition holds no execution state, so nothing needs stripping out before it is used again.

Re-routes and retries create new task attempts under the same run, so a step that failed twice and succeeded on the third try is three attributed activities, not one overwritten record.

Edges come in two kinds

Structural edges — used, produced, performed_by, ran_on, approved, derived_from — fall out of executing the workflow automatically, at zero extra cost. Nobody types them in. They are the by-product of running the work.

Semantic edges — this asset features that character, depicts that scene — require intelligence to produce. In OWG the tool that writes a semantic edge is itself just another task, with an executor and an attributed author, so an inferred relationship carries the same provenance as any other piece of work.

That distinction is why the provenance record does not depend on anyone's diligence. The expensive, interesting metadata is optional and attributed; the accountability metadata is automatic.

Assurance: how sure is this edge?

Because a graph is assembled from many systems and some relationships are inferred rather than declared, every explicit relationship carries an assurance level:

• attested — backed by a verified content credential, such as a C2PA manifest.
• asserted — declared by a system of record, or confirmed by a human.
• inferred — proposed rather than declared, carrying a required confidence score and an identifier for the method that produced it.

So the graph records not just that two things are related, but how certain the relationship is and who or what vouched for it. That is what makes machine-proposed structure safe to accept selectively rather than wholesale — an implementation can apply whatever acceptance policy it judges appropriate, and the record shows what was proposed, by what, and who accepted it.

The same three levels, and the same rule that inferred must carry a score and a method, apply wherever assurance appears. See Relationships and assurance for the payload, and For agents for how to propose responsibly.

Composing the five cells

The same five node types build every structure a production needs:

• Link tasks and you have a workflow.
• Link participants and you have an org and authority chart.
• Link assets and you have asset management with real lineage.
• Link tasks to infrastructure and you have a schedule and a cost model.
• Scope all of it by context and you have per-show, per-territory views over one graph.

A mid-sized post facility generates tens of thousands of tracked edges a year; a studio across several years reaches the billions. What an implementation must be able to answer at that scale is in Persistence requirements.