One clear core. Room for the sport.
A versioned contract for fictional fixtures—not a universal racing standard or a production API.
The fixture envelope
| Field | Meaning |
|---|---|
schema_version | Exactly 1.0.0 in the bundled fixtures. |
sample | Exactly true; every record is fictional. |
source | Dataset name, illustrative observation time, and revision. |
event | ID, display name, discipline, scheduled start, and event state. |
classification_status | Not available, provisional, or final—separate from event state. |
results | An array of entry records. A valid array may be empty. |
sport_data | An open object with selected sport-specific concepts. |
Entry records
Each entry includes a string entry_id, a display name, a positive integer or null position, a non-negative numeric or null elapsed_ms, and a documented status. Keep the entry identity separate from names and display numbers.
Entry states in this sample contract are classified, not_started, not_finished, disqualified, and pending. These are illustrative application labels, not a mapping of every provider’s vocabulary.
Time, identity, and missing values
The fixture uses timezone-aware strings for instants and milliseconds for durations. An observation timestamp records a fictional measurement instant; it is not the real time your browser fetched the file. A null is unavailable, not a duration of zero. A position is the supplied fixture classification, not a locally calculated official rank.
The schema validates structure and some simple value constraints. It does not establish event authenticity, sporting correctness, identifier uniqueness across files, or permission to redistribute real results. Those need separate application checks and provider decisions.
What the extension deliberately leaves open
sport_data varies by discipline. The F1 example includes selected lap concepts; the dog-racing example includes trap assignments; the marathon example includes checkpoint distances. These are short educational examples rather than complete sport-specific schemas.
The JSON Schema intentionally allows arbitrary properties inside that extension. Add a separate validated extension contract when your application has real requirements. Do not treat the open object as proof that every provider returns the same fields.
Version changes and corrections
A fixture schema version describes the shape of the record. A source revision describes the particular snapshot. Keep them separate. Changing a result does not necessarily require a new schema version, while renaming a required field can break consumers even when the sporting result is unchanged.
When adapting a real source, preserve its original IDs and status values along with your normalized representation. Unknown source states should remain reviewable instead of silently becoming completed or final.
Your next racing project starts here.
Pick a discipline. Explore the data model. Build something worth following.