JSON Schema

The JSON Schema is the primary binding for SPEC §§4–7 (JSON Schema Draft 2020-12). Every SPEC.md example and every conformance vector validates against it. It is synced from the canonical repository at build time.

• Download: openbody.schema.json
• $id: https://openbody.dev/schema/v0.10/openbody.schema.json
• Source of truth: schema/openbody.schema.json

What it validates

The root $ref is a oneOf over the addressable record kinds, discriminated by recordType:

tombstone, Measurement, Program, Session, Block, Exercise, WorkUnit, ThresholdProfile, StatusPeriod

plus the shared $defs for value objects — including Target, scalarOrTarget, TargetWithRamp, scalarOrTargetWithRamp (the load.value/Intensity.value superset that adds the ramp branch), Load, EffortLoad, Intensity, Progression, phasePattern, Descriptors, modifiers, outcome, ExerciseRef, Participant, sides, link, mediaItem, extension, provenance, envelope, prescription, performance, Rep, and the primitives (fixedPoint, number, id, timestamp).

Open registry-backed tokens (§5.9) are typed string; genuinely closed enums are constrained to their value set.

The schema validates STRUCTURE — not every rule

Several rules are context-dependent or normalization-level and are enforced by a conforming implementation, not the schema. From the schema’s own NOTE:

• top-level records MUST carry id + subject, while inlined children may inherit them (§7.1/§7.2);
• a tombstone (status: deleted) is exempt from all required fields except id/recordType/status (§7.1);
• a Measurement MUST carry type, startTime, endTime, with unit conditionally required by value kind (§4.1);
• a Session carries at most one of blocks｜exercises｜workUnits (§5.3);
• a WorkUnit’s exerciseRef is mutually exclusive with an enclosing Exercise (§5.5);
• scoring↔metric agreement (§5.5); sets only in a planned prescription (§5.5);
• algorithm required when method is algorithm (recommended, not required, when only derivedFrom is present) (§7.4);
• and the §8.3 shorthand equivalences (two encodings of the same meaning MUST NOT be treated as different data).

Validate wire records, not the canonical form the conformance suite’s equivalence method produces (that is a comparison artifact of the test tooling, not the binding).

Using it

In the reference implementation, validate(record) runs this schema via ajv plus a semantic pass covering several of the context-dependent rules above (e.g. §5.2 Program phase cross-checks, §5.5 scoring↔metric agreement and the sets/performance mutual exclusion, §5.12 Load.unit conditionality, §7.5 tombstone strictness). See Getting started. Rules the pass does not cover remain the implementer’s responsibility. The canonicalization algorithm is not among them: per SPEC §8.3 an implementation is judged by its inputs and outputs against the published vectors — the test tooling and reference implementation implement the algorithm as the equivalence oracle, and you are not required to.