Persistence requirements
What an implementation must be able to answer about an OWG graph — stated as required capabilities, not as a prescribed storage design.
OWG specifies a document format, not a database. An OWG document is JSON, and any store that can hold it and answer the queries below is conformant.
This is deliberate and it is a portability guarantee: the specification does not oblige you to adopt anyone's storage design, and it does not privilege any vendor's. Implementations differ, and should.
Required query capabilities
A conformant implementation must be able to answer four classes of question about a stored graph. These are stated as capabilities because they are what interoperability depends on — not as a schema, which is yours to choose.
| Class | The question | Why it is required |
|---|---|---|
| Entity lookup | Give me this asset, task, or participant by id | The floor for any read path |
| Workflow retrieval | Give me this workflow and everything it references | Rendering, hand-off, and export all need a bounded subgraph |
| Lineage traversal | What did this asset come from, transitively? | Impact analysis, rights answers, and AI-disclosure all reduce to this |
| Attribution traversal | Who touched this, and on whose authority? | The accountability claim is void without it |
Two properties matter more than how you achieve them:
- Lineage traversal must be bounded. A caller must be able to cap traversal depth, and the implementation must terminate on cyclic data rather than looping. Structural lineage should be acyclic, but a store cannot assume its inputs were validated.
- Retrieval must be scopeable. A workflow, a context, or a turnover subgraph must be retrievable without reading the whole graph — that is what makes scoped hand-offs enforceable rather than advisory.
Export and portability
Two hard requirements, and the reason the format is worth having at all:
- Export must be lossless. A document exported from a conformant store must validate against the schema and preserve every field it went in with — including
metadata,x-extensions, and identifiers the implementation does not itself use. - Unrecognised identifiers must survive. An implementation must never strip an identifier from
identifiers[]because it did not recognise the scope. This is the single rule that keeps a graph interoperable over time. See Standards bindings.
Together these mean the graph you build is yours: exportable, re-importable elsewhere, and not dependent on the implementation that produced it.
Storage locators, not storage
Assets carry a locator identifying where the bytes physically live — object storage, on-premises storage, a SaaS asset manager, a camera card, a time-addressable store. The governance record travels with the asset node; the content stays where it is.
The consequence worth stating plainly: media never has to move in order to be governed, and a production can span clouds, vendors, and on-premises facilities without the graph caring. An implementation must resolve locators; it must not require content to be centralised first.
Scale expectations
For sizing, not as a requirement: a mid-sized post facility running a few hundred jobs a year generates tens of thousands of tracked edges annually. A studio across several years reaches the billions.
Graph metadata is small relative to media — the node and edge data for a very large estate is a modest database by modern standards, because the bytes live behind locators rather than in the graph. Storage-heavy productions scale the media, not the model. Plan capacity accordingly: your traversal performance is the thing to engineer, not your metadata volume.
What the specification does not prescribe
Left entirely to the implementation, and intentionally so:
- The storage engine — relational, graph-native, document, or a combination.
- The physical schema, indexing strategy, and query formulation.
- Caching, projection, and read-replica architecture.
- Access-control enforcement mechanism (the security model specifies what must be expressible, not how to enforce it).
- Federation and ingestion strategy, including how an implementation relates entities arriving from different systems.
If two implementations both hold the same document, answer the four query classes, and export losslessly, they interoperate. Nothing beyond that is the specification's business.