Conformance corpus
The reference workflows, what each tier proves, how the regression harness runs them, and the true inventory.
The conformance corpus is a body of reference workflows that runs as a regression suite. Its purpose is to keep implementations honest: once a workflow is green, it stays green.
Download them
Every document is published as a real file. They are the same documents the regression suite runs, so each has passed all four validation passes — use them as reference data, as fixtures for your own implementation, or as worked examples to read.
| Resource | URL |
|---|---|
| Machine-readable index | /corpus/index.json |
| Any document | /corpus/<file> |
# What is in the corpus, with task and asset counts
curl https://openworkflowgraph.org/corpus/index.json
# A single conformance workflow
curl https://openworkflowgraph.org/corpus/W01.owg.json
# The whole set
curl -s https://openworkflowgraph.org/corpus/index.json \
| jq -r '.documents[].url' | xargs -n1 curl -sOValidate the project documents together, not one at a time. The named project documents use the multi-document registry pattern: a registry document holds the shared participants, organizations, infrastructure and contexts, and the workflow documents sharing its
project_idreference them. Checked in isolation, those references look unresolved.index.jsoncarriesproject_idon every entry so you can group them.
Inventory
| Set | Count | In the regression suite |
|---|---|---|
Numbered conformance workflows (W01–W14) | 14 | Yes |
| Named project documents | 8 | No |
| Total OWG documents | 22 | — |
| OMC-JSON reference datasets | 2 | No |
On the number. The corpus is planned to extend to
W35;W15onward are not yet encoded, because they need applications and on-set hardware that broader coverage will require. The figure to cite today is 14 — the numbered, tiered documents that run as a suite. Use 22 if you mean every OWG document in the corpus, including the named project documents.
Tiers
| Tier | Shape | Workflows |
|---|---|---|
| tier-0 | Atomic — a single task | W01, W02, W03 |
| tier-1 | Topology — linear chains, conditionals, parallel fan-out | W04–W08 |
| tier-2 | Full production scenarios by domain | W09–W14 |
Tier-2 covers live sports (W09), sports graphics (W10), news QC (W11), VFX and DI (W12), AI dubbing (W13), and generative VFX (W14, the headline case).
Complexity climbs as intended:
| Workflow | Tasks | Assets | Participants |
|---|---|---|---|
| W01–W03 | 1 | 2 | 1 |
| W04 | 4 | 4 | 4 |
| W07 | 6 | 6 | 4 |
| W11 | 7 | 7 | 4 |
| W13 | 11 | 12 | 5 |
| W14 | 10 | 10 | 7 |
Naming is W<NN>.owg.json, zero-padded, with the number global rather than per-tier — tier-1 starts at W04, not W01.
Tier boundaries are a convention of the corpus rather than a normative part of the specification — they organise coverage, and nothing in the schema depends on them. Each document carries its tier in its
descriptionprefix (T0 Atomic,T1 Linear Chain,T2 Sports Live).
Project documents
Eight further documents exercise features the numbered tiers do not, and are worth reading even though CI skips them (the harness only scans directories beginning tier-):
| Document | What it demonstrates |
|---|---|
europa-project, helios-project | Registry-only documents — zero tasks, pure participant and asset registries. Proof that tasks really is optional |
helios-concept-dev | The only document exercising the full QC re-route vocabulary: on_pass, on_fail, reroute_feedback, max_reroutes |
tams-live-sports | The TAMS binding — a growing asset with QC hanging off it |
usd-scene-composition | The USD binding — composition arcs as typed edges |
hybrid-genai-pipeline | Mixed human and generative work in one graph |
europa-sc3-postlock | A post-lock scenario |
All eight validate against v0.9. The registry-only pair are worth running early if you are building a reader — a document with no tasks is legal, and code that assumes otherwise fails on them.
Running the corpus
The corpus is intended to be run as a regression suite: every document in it must validate, and once a document is green it stays green. That is the whole discipline — a corpus that is not run is documentation, not conformance.
A conformant test run reports, per document, whether it passed each validation pass. A summary looks like:
OWG conformance corpus — 14 document(s)
✓ W01 structural:✓ referential:✓ graph:✓ expression:✓
✓ W02 structural:✓ referential:✓ graph:✓ expression:✓
…
✓ W14 structural:✓ referential:✓ graph:✓ expression:✓
14/14 greenReporting per pass rather than a single pass/fail matters: a document that clears the structural pass but not the referential one tells you something specific about your validator, and a single boolean hides it.
The corpus does not test rejection
Worth stating plainly, because it is the corpus's main limitation: every document in it is expected to pass. There are no negative fixtures — no documents that are supposed to be rejected, and no per-document expectation metadata.
So the corpus demonstrates that a valid document is accepted. It says nothing about whether an invalid one is caught, and a validator that accepted everything would score 14/14.
If you are building a conformant implementation, write your own invalid fixtures.
At minimum, cover one case per error code: a cycle, a dangling
reference, a duplicate id, an unknown property, an unresolvable expression reference, a
type-mismatched comparison, an authority cycle, and a COMPENSATE without a target. That
set is what actually tells you your validator works.
A shared negative corpus is a natural candidate for community contribution, and the error-code table is the checklist it should cover.
Conformance levels
Profiles declare a level of L1, L2, or L3:
| Level | Meaning | Checked today |
|---|---|---|
| L1 | Valid against the JSON Schema | Yes |
| L2 | Executable on a profile's declared tools | No |
| L3 | Full provenance capture | No |
Only L1 is verified by any tooling today. There is no profile-conformance checking and no provenance checking in the implementation. See Profiles.
Using the corpus as an implementer
A practical sequence:
- Start with W01. One task, two assets, one participant — the smallest complete document. Load it, project it, render it.
- Add W04. Four tasks, a linear chain, four executor types in one document, and a real
retryblock. - Add W05. A conditional (
when), a human review gate, and fan-in viadepends_on: ["edit", "thumbnail_review"]. - Add a registry-only document (
helios-project) to confirm you handle a document with no tasks. - Then W14, the headline case: ten tasks, LoRA training, two human gates, C2PA signing.
- Write your own negative fixtures, since the corpus has none.
Full annotated examples are in Examples.