Standards bindings

The single most important design decision in OWG is not in the schema; it is a rule about what the schema must not contain:

OWG references the asset-level objects and identifiers of adjacent standards. It never absorbs their internals.

A workflow graph that tried to mirror every media segment, every scene primitive, and every timeline event would inherit the scale and semantics of three other domains and collapse under them. Instead, each neighbouring standard keeps owning its plane, and OWG occupies the plane they each deliberately place outside their own scope.

This is why the composite is complementary rather than overlapping: each standard's own scope document explicitly excludes the others' concerns.

The planes

Four mechanisms

Every binding uses the same four mechanisms. Learning them once is enough to bind a standard that is not yet mapped.

1. Identifier pass-through

Following MovieLabs' best practice for OMC-conformant systems, OWG never strips an incoming identifier, even one it does not itself use. An asset arriving with another system's identifier keeps it, stored in the asset's identifiers array alongside its scope.

{
  "id": "plate_0140",
  "type": "video",
  "identifiers": [
    { "scope": "tams.source",   "id": "0f7e...-a91c" },
    { "scope": "usd.assetInfo", "id": "asset://hero_prop/v23" },
    { "scope": "frameio.id",    "id": "b2c8e9f1" },
    { "scope": "c2pa",          "id": "urn:uuid:9e21..." }
  ]
}

Any system requesting the entity gets the full identifier set back. Preserved identifiers are not merely good manners — they are the highest-confidence signal available for relating objects that arrive from different systems.

Documented scopes: tams.source, usd.assetInfo, frameio.id, c2pa, urn. The list is extensible; the scope string identifies the issuing system.

2. Declared assurance on every cross-system edge

Relating an entity in one system to an entity in another is sometimes certain and often not. Is this scene file the same asset as that stored source? Sometimes a shared identifier settles it; sometimes only a judgement call can.

OWG does not specify how an implementation reaches that judgement. It specifies that the answer must carry its own assurance into the graph:

So the graph records not just that two things are related but how certain the relationship is and who or what vouched for it. Acceptance is recorded too, which means the graph's own provenance rules apply to the graph's own construction.

Matching technique and acceptance policy are implementation concerns, deliberately outside this specification. Two conformant implementations may relate the same two systems with different confidence and different methods; what interoperates is the record they leave. The required fields are in Relationships.

3. Overlay, not migration

A conformant implementation can build a graph over the systems a production already runs, rather than requiring them to be replaced. The specification's contribution to that is narrow and important: a connector reads a standard's native construct and turns it into a typed edge, computing nothing the standard already computes. Composition algebra, time resolution, and playback stay exactly where they are.

No production adopts a graph by re-entering its data — and nothing in OWG requires it to. How a given implementation performs ingestion is its own business.

4. Security as a property of the node

Because a task's subgraph scopes a vendor turnover to only the nodes it needs, and because a task carries its own validity window, access to any asset is bounded in both scope and time without a separate access-control system to configure and keep in sync. See Security model.

The bindings

Each binding has a specific hook that already exists in the neighbouring standard — which is what makes this pattern engineering rather than analogy.

OMC — the vocabulary, not a neighbour

OMC is not adjacent to OWG; it is the language OWG is written in. The mapping is an identity rather than a translation. OWG inherits OMC's entity model and relationship vocabulary directly, and inbound OMC instances are validated against the OMC schema before anything enters a graph.

Edge correspondences to OMC v3.0:

Tracking a moving target. OMC v3.0 is still being finalised; v2.8 is the last stable release. MovieLabs issued the first preliminary v3.0 release on 2026-08-05, with further releases scheduled for September (video pipeline, transforms, colour spaces, infrastructure classes) and December (asset function/structure correspondence tables, relationship tables). Note in particular that there is no Shot entity in OMC v3.0 — the video pipeline from production scene through editorial shots and sequences arrives in the September release, so no Shot mapping should be reintroduced before then.

OpenUSD — composition arcs become typed edges

USD composes a scene from reusable pieces and deliberately leaves version, approval, and rights questions to someone else. OWG is that someone.

The hook: USD ships a purpose-built assetInfo metadata slot on every published asset, so OMC identifiers ride there today with no schema change. The reference, payload, and sublayer arcs that already exist in a stage file become typed edges a connector reads rather than infers.

{
  "id": "shot_0140_assembly",
  "composes": [
    { "component": "hero_prop_v23", "arc_type": "reference",
      "prim_path": "/World/Set/Hero", "variant_selection": "lod=high" },
    { "component": "env_backlot_v4", "arc_type": "payload",
      "prim_path": "/World/Env" }
  ]
}

Arc types: reference, payload, sublayer, inherit, specialize, variant.

Critically, the graph never descends below the published-asset boundary. Prim paths appear only as opaque edge properties — OWG does not parse or interpret them. That boundary is the whole discipline in one sentence.

What this enables: because the graph governs the referenced pieces, it answers what neither an asset manager nor a tracker can — which shots reference Hero v23, and if we retire it, which shots break and need re-approval. In a conventional pipeline that question is answered by querying scene files, tribal memory, and a supervisor's best guess. Here it is a graph traversal, and the approval history of every component comes attached, because approvals are structural edges.

BBC TAMS — growing assets and opaque timeranges

A live feed is a flow still being appended: an asset that is growing, with QC and highlight tasks hanging off it in near real time.

The hook: TAMS's own addressing is a source UUID plus a timerange. Two systems referencing overlapping timeranges of the same source can be related deterministically rather than guessed at, and OWG can track a feed still being captured without mirroring a single segment.

{
  "id": "match_feed_live",
  "type": "video",
  "state": "growing",
  "storage": {
    "provider": "tams",
    "timerange": "[1500:0_1620:0)"
  },
  "identifiers": [{ "scope": "tams.source", "id": "0f7e...-a91c" }]
}

Two rules make this work:

• The timerange string is stored opaquely. OWG does not parse or interpret time. The half-open [s:ns_s:ns) syntax is TAMS's, and resolving it to bytes is TAMS's job.
• While an asset's state is growing, its identity is the TAMS source UUID rather than a content hash, and the producing ingest task stays open. When the referenced range closes, fixity is computed over the now-bounded range and the state advances.

A highlight is therefore a bounded timerange of the source: no copy, no transcode, lineage intact across the live seam. This carries the governance model from file-based work into live sports and news, using the storage layer the broadcaster already deployed.

A deliberate non-goal. The mapping between International Atomic Time and SMPTE timecode is an unresolved industry-wide problem. OWG does not attempt to solve it and defers to essence-layer tooling.

OpenTimelineIO — the timeline as a governed asset

A timeline is an asset whose clips are edges to other assets, each with a source timerange.

The hook: OTIO travels. Its adapters already convert CMX 3600 EDLs, Avid AAF, Final Cut Pro XML, and ALE, so one OWG-to-OTIO binding covers the editorial ecosystem including the proprietary formats. Its open metadata dictionary is a ready two-way slot for the same identifiers used everywhere else in the graph.

What this enables is editorial's oldest question, answered per clip: does the current cut contain the latest approved version of everything? One comp is stale — version 3 is in the cut, version 4 was approved after the edit was saved. The reconform becomes one action and one record: a task, attributed, timestamped, from v3 to v4, on the approving supervisor's authority, and the timeline advances by a typed revision.

The conform stops being reconciliation-by-filename. A related benefit: reviewers with permission can stream a proxy assembly of the cut — guaranteed current — while the underlying assets never leave their store and were never within the reviewers' reach at all.

C2PA — the attested tier

C2PA content credentials supply the attested assurance level directly. A verified manifest is the strongest statement the graph can hold about an asset's identity and origin.

The layering is worth stating precisely, because these three are often conflated:

• C2PA is the creation-time marking layer.
• The EU AI Act icon set is the publication-time labelling layer.
• OWG is the production-time tracking layer between them — the lineage produced as a side effect of running the work.

Generated assets should carry content credentials; the generative-AI profile states this as a recommendation.

SOM — the narrative plane

A story is what a newsroom's tools have been missing a shared description of: not the footage, not the rundown position, but what the desk currently believes is true, and who has cleared what to go out where.

The hook: SOM's own Link entity already has no identity beyond its endpoints. It connects an asset to a destination and carries a mutable compliance gate — exactly a relationship's shape, not a registry's. A Telling references that link, not the asset directly, so the graph never needs a "which outlet, under what clearance" field bolted onto the asset itself.

{
  "relationships": [
    {
      "id": "rel_link_e1",
      "relation": "routed_to",
      "from": { "kind": "asset", "id": "a1" },
      "to":   { "kind": "infrastructure", "id": "dest_breakfast_bulletin" },
      "assurance": "asserted",
      "profiles": {
        "broadcast-newsroom": { "gate_status": "CLEARED", "link_id": "018f3a2e-...-e1" }
      }
    }
  ]
}

What this enables: a claim later confirmed or withdrawn changes gate status on the edge, not on the asset. The same footage can be cleared for one outlet and held from another at the same moment, without two copies of the asset existing anywhere — and a downstream query ("which tellings used a since-withdrawn link?") is a graph traversal, not a cross-system reconciliation.

A deliberate non-goal. OWG does not model SOM's editorial vocabulary — story phases, evidential sourcing tiers, assertion review states — in core. It lives entirely in the broadcast-newsroom profile (see Profiles → Registry extension profiles), the newest of the four mechanisms above, added specifically because this binding needed it: SOM's delivery messages fit asset.storage unchanged, but its editorial state fits nowhere in core without widening it for every implementer, broadcast or not.

Extending the pattern

The recipe should extend cleanly to standards not covered here — ACES colour transforms and MaterialX look graphs among them — because each already exposes:

1. Its own native composition or reference construct, which becomes a typed edge.
2. Its own extension slot for an external identifier, which carries OMC identifiers both ways.

Binding a new standard is a connector to build, not a rearchitecture.

One rule governs the boundary: leave every computation the standard already performs where it is. Only when a referenced operation is itself work — a generative transition, a colour transform — does it get promoted to a task with an executor and an attributed author.

Known limitations

Stated plainly, because interoperation claims deserve scepticism:

• The mappings above are implemented at the schema and connector level. Deeper integrations — a governance-graph-backed asset resolver for USD, bidirectional write-back to federated systems, full growing-asset semantics for TAMS — require real engineering and, in some cases, design partners.
• The value of interoperation is a network effect the model does not control. An OWG record is most valuable once the neighbouring standards' tools emit and consume the mapped identifiers, and OMC adoption in production remains thinner than in specification.
• Connectors are a standing maintenance liability, not a one-time build. Every source system brings its own entity-resolution and event-ordering quirks.

None of these undermines the central claim. They scope it.