Open Workflow GraphPre-release
Implementing

Conformance corpus

The reference workflows, what each tier proves, how the regression harness runs them, and the true inventory.

View as markdownMachine-readable source for agents and scripted implementers

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.

ResourceURL
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 -sO

Validate 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_id reference them. Checked in isolation, those references look unresolved. index.json carries project_id on every entry so you can group them.

Inventory

SetCountIn the regression suite
Numbered conformance workflows (W01W14)14Yes
Named project documents8No
Total OWG documents22
OMC-JSON reference datasets2No

On the number. The corpus is planned to extend to W35; W15 onward 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

TierShapeWorkflows
tier-0Atomic — a single taskW01, W02, W03
tier-1Topology — linear chains, conditionals, parallel fan-outW04–W08
tier-2Full production scenarios by domainW09–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:

WorkflowTasksAssetsParticipants
W01–W03121
W04444
W07664
W11774
W1311125
W1410107

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 description prefix (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-):

DocumentWhat it demonstrates
europa-project, helios-projectRegistry-only documents — zero tasks, pure participant and asset registries. Proof that tasks really is optional
helios-concept-devThe only document exercising the full QC re-route vocabulary: on_pass, on_fail, reroute_feedback, max_reroutes
tams-live-sportsThe TAMS binding — a growing asset with QC hanging off it
usd-scene-compositionThe USD binding — composition arcs as typed edges
hybrid-genai-pipelineMixed human and generative work in one graph
europa-sc3-postlockA 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 green

Reporting 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:

LevelMeaningChecked today
L1Valid against the JSON SchemaYes
L2Executable on a profile's declared toolsNo
L3Full provenance captureNo

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:

  1. Start with W01. One task, two assets, one participant — the smallest complete document. Load it, project it, render it.
  2. Add W04. Four tasks, a linear chain, four executor types in one document, and a real retry block.
  3. Add W05. A conditional (when), a human review gate, and fan-in via depends_on: ["edit", "thumbnail_review"].
  4. Add a registry-only document (helios-project) to confirm you handle a document with no tasks.
  5. Then W14, the headline case: ten tasks, LoRA training, two human gates, C2PA signing.
  6. Write your own negative fixtures, since the corpus has none.

Full annotated examples are in Examples.