# 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](/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`](/corpus/index.json) |
| Any document | `/corpus/<file>` |

```bash
# 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

| 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`; **`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

| 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 `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-`):

| 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](/validation). 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](/validation#error-codes): 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](/validation#error-codes) 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](/profiles#conformance-levels).

## 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](/examples).