Conformance

A document conforms when it validates against the JSON Schema its ocp value selects and breaks none of the error rules below that apply to its version. Warnings do not make a document non-conforming; they point at something a consumer may want to know. A producer conforms when every document it writes conforms, and a consumer conforms when it reads every conforming 0.1, 0.2 and 0.3 document, ignoring what it does not know. The rules cover what JSON Schema cannot express: references between entities, cycles, sums and consistency across fields. Each has a code: an E code is an error, a W code a warning.

The schema, with the meaning its descriptions give each field, and the rules on this page define OCP; the checker does not. loopmath ocp validate implements every numbered rule, and the code in each finding is the one on this page; where the two disagree, the checker has a bug. A requirement stated only in a field description is normative too, but the checker does not test every one, so a clean result does not prove a document meets every description. See What the checker does not test and Validate a document.

Applicability

Under each code is its level and the version that added it. A rule applies to a document whose ocp version is that version or later. A 0.1 document is checked against the 0.1 rules only, even by a 0.3 checker, and a field that a later version added is an unknown field in an earlier document, so it is ignored.

Reading the document

Code	Rule
E001 error, since 0.1	The file can be read and parsed as JSON.
E002 error, since 0.1	The top-level value is an object.
E003 error, since 0.1	`ocp` is present and names a known version (`0.1`, `0.2` or `0.3`). The other rules still run.
E010 error, since 0.1	The document validates against the JSON Schema of its version. One finding per schema error.
E011 error, since 0.1	The checker could load that schema. A checker fault, not a document fault.
W001 warning, since 0.1	Schema validation was skipped because the checker has no JSON Schema library. The numbered rules still ran.

Ids and lists

Code	Rule
E100 error, since 0.1	Node ids are unique.
E101 error, since 0.1	Attempt ids are unique.
E102 error, since 0.1	Group ids are unique.
E103 error, since 0.2	Artifact ids are unique.
E104 error, since 0.1	`nodes`, `edges`, `attempts`, `events`, `groups` and `artifacts` are arrays when present, never `null`.

Run graph

Code	Rule
E110 error, since 0.1	`edge.from` names an existing node.
E111 error, since 0.1	`edge.to` names an existing node.
E115 error, since 0.1	`node.group` names an existing group.
E120 error, since 0.1	`group.parent` names an existing group.
E121 error, since 0.1	Group parent links do not form a cycle.
E122 error, since 0.1	`dep` and `fan_in` edges together form a directed acyclic graph. `spawn`, `launch` and `artifact` edges record lineage, not scheduling, and MAY form cycles.
E160 error, since 0.2	Every edge carries a `tier`, whatever its kind and whoever wrote it.

See Run graph.

Attempts and outcomes

Code	Rule
E112 error, since 0.1	`attempt.node` names an existing node.
E130 error, since 0.1	A terminal attempt’s `outcome.result` equals its `status`.
W131 warning, since 0.1	A terminal attempt has an `outcome`.
W132 warning, since 0.1	Only a terminal attempt has an `outcome`.
W140 warning, since 0.1	`cause.ref` names an existing attempt.
W141 warning, since 0.1	`outcome.via` names an existing node.
E119 error, since 0.2	`origin.launched_by` names another existing attempt.
E161 error, since 0.2	When `origin.launched_by` is set, a `launch` edge runs from the launcher’s node to this attempt’s node.
E165 error, since 0.2	An origin is not both `external: true` and launched by an attempt.

Terminal statuses are done, failed, rejected, canceled, settled_unverified and lost. See Attempts.

Artifacts

Code	Rule
E116 error, since 0.2	An `artifact` edge names an artifact.
E117 error, since 0.2	The artifact an edge names exists.
E118 error, since 0.2	`artifact.producer`, `writers` and `consumers` name existing attempts.
E123 error, since 0.2	An edge’s `from_attempt` and `to_attempt` name existing attempts.
E124 error, since 0.2	`from_attempt` is an attempt at the edge’s `from` node, and `to_attempt` one at its `to` node.
E125 error, since 0.2	An `artifact` edge carries both `from_attempt` and `to_attempt`.
E162 error, since 0.2	`artifact.producer` is `writers[0]`: the producer is the first writer.
E163 error, since 0.2	A known `n_writes` is at least the number of writers, and a known `n_reads` at least the number of consumers. A `null` count is unknown and passes.
E164 error, since 0.2	An artifact edge’s `from_attempt` is the artifact’s producer, and its `to_attempt` is one of its consumers.
E166 error, since 0.2	`writers` is not empty, and no attempt appears twice in `writers` or in `consumers`.
E167 error, since 0.2	`writers` and `consumers` are arrays when present, never `null`.

See Artifacts.

Cost

Code	Rule
E170 error, since 0.2	When `cache_creation_tokens`, `cache_creation_5m_tokens` and `cache_creation_1h_tokens` are all present, the two buckets add up to the total.
E171 error, since 0.2	When `producer.name` names loopmath’s log extractor (`loopmath`, or `dagr` in documents written before its rename, alone or followed by a non-word character, as in `loopmath/graph`), every cost record has `basis: measured`. One exception, from 0.3 and only when `producer.name` is loopmath’s: `basis: allocated` is allowed when `cost.ext["dev.loopmath.logmatch"]` is an object whose `tier` is `heuristic` or whose `shared_session` is `true` or a non-empty object.

See Cost.

Events

Code	Rule
E113 error, since 0.1	`event.node` names an existing node.
E114 error, since 0.1	`event.attempt` names an existing attempt.
W150 warning, since 0.1	Events are in ascending time order.

See Events.

Producer, extensions and vocabulary

Code	Rule
W180 warning, since 0.2	`producer.capabilities` is present.
E180 error, since 0.2	No capability is declared `false` while the document contains that element. From 0.3 this covers `task`, `configuration`, `signals`, `slate` and `receipt` too.
E181 error, since 0.1	No `ext` key uses a retired prefix: bare `dagr.` (write `dev.loopmath.`, or `dev.dagr.` before 0.3) or bare `ocp.` (write `io.orchestrationcontextprotocol.`).
W182 warning, since 0.3	No `ext` key uses `dev.dagr.`, loopmath’s namespace before 0.3. Such keys are still read through 0.4; write `dev.loopmath.`.
W200 warning, since 0.2	A string in an open vocabulary comes from its recommended list. Other values are valid; the warning helps catch typos.

See Document and Extensions.

The observation

These rules are new in 0.3. Each has a passing and a failing example document; see Rule pairs.

Code	Rule
E190 error, since 0.3	`run.configuration.id` equals the canonical id of its workflow and settings. A workflow given by reference is resolved through the reader’s catalog; a reader that cannot resolve it skips this rule and E191. Pair
E191 error, since 0.3	Every top-level piece of the workflow has an object in `configuration.settings` under its id, except a piece that holds a nested workflow and has no role. Pair
E192 error, since 0.3	Piece and artifact ids are unique in one namespace; every edge joins an existing piece and an existing artifact; the edges form no cycle. Nested inline workflows are checked the same way. Pair
E193 error, since 0.3	Every `control.gates` entry is a piece; every `control.repair` key is a gate and every value a piece. Pair
E194 error, since 0.3	The run’s id is among `slate.members`. `task.base_commit` equals `slate.base_commit` when both are present. A preference that names a slate names this run’s slate. A preference’s `winner` is `tie` or one of the preference’s `members`, or of the slate’s members when the preference lists none. Across documents checked together, documents with the same `slate.id` share `task.id` and the base commit (`task.base_commit`, else `slate.base_commit`). Pair
E195 error, since 0.3	A signal’s value fits its kind: a verdict is `accept`, `reject`, `pass`, `fail` or `error`; a score is a number, or `null` when declared and not measured yet; a score with `scale: fraction` lies in [0, 1]; an event’s value is a reference string. `acceptance_rule.score.name` names no verdict or event signal; when `acceptance_rule.score.scale` is `fraction`, its `target` lies in [0, 1]; and `acceptance_rule.requires` names no score or event signal. Pair
W196 warning, since 0.3	Only loopmath writes `run.receipt`. Pair

The cross-file part of E194 can only be checked when a checker reads the slate’s documents together, as loopmath ocp validate does when given several files.

What the checker does not test

A clean result from loopmath ocp validate means the document passed the schema and every numbered rule. It does not prove the document meets every requirement in the field descriptions. The reference checker in loopmath 0.1.0 does not test the following; a consumer that relies on them should check them itself:

Whether a preference’s own members are members of the slate. When a preference lists members, E194 checks its winner against them only.
Whether documents with the same slate.id carry the same slate object. Across files, E194 compares only task.id and the base commit.
Whether a timestamp is a real date and time. The schema checks its shape, so a value such as 2026-99-99T99:99:99+99:99 passes.
The length of strings the schema does not cap, such as task.features values, setting options and ext payloads, so a pass is not a size or privacy filter (Privacy).

OCP 0.4 plans warnings, not errors, for the first three: a reader repairs or ignores such a value with a note, and treats an impossible timestamp as missing. 0.4 also plans a warning for a fraction signal whose own target lies outside [0, 1].

Not checked mechanically

Some requirements cannot be checked from the document alone. A producer is bound by them all the same:

Under metadata_only, no field holds prompt, completion or transcript text (Privacy). A checker cannot tell a short label from a pasted prompt.
basis: "measured" is written only for counts summed from usage records of that attempt (Cost).
A tier is never upgraded without new mechanical evidence (Attempts).
Ids SHOULD stay stable when the same run is written again (Document).

Adding a rule

A new rule arrives in a minor version, through a proposal, with a new code, a line on this page, a passing and a failing example document, and the check in the reference checker.

Specification

The document

The observation

Reference

Conformance

Applicability

Reading the document

Ids and lists

Run graph

Attempts and outcomes

Artifacts

Cost

Events

Producer, extensions and vocabulary

The observation

What the checker does not test

Not checked mechanically

Adding a rule

​Applicability

​Reading the document

​Ids and lists

​Run graph

​Attempts and outcomes

​Artifacts

​Cost

​Events

​Producer, extensions and vocabulary

​The observation

​What the checker does not test

​Not checked mechanically

​Adding a rule

Applicability

Reading the document

Ids and lists

Run graph

Attempts and outcomes

Artifacts

Cost

Events

Producer, extensions and vocabulary

The observation

What the checker does not test

Not checked mechanically

Adding a rule