Orca

Data files

Everything the build publishes, what each file is for, and how to fetch one record instead of the whole corpus.

Snapshot 2026-09-20, built 2026-09-26, format version 1, commit 019924ac64ee0aa0742b8f02a04488a83633385d. Every JSON file below repeats these four fields and the licence, so a file that travels on its own still says what it is and when it was true.

Licence and attribution

Orca's data is published under the Creative Commons Attribution 4.0 International (CC BY 4.0), SPDX CC-BY-4.0, at https://creativecommons.org/licenses/by/4.0/. Copy it, change it, build on it, commercially or not. Credit Orca and name the snapshot date you used.

Data from Orca (https://qstve.com/orca/), CC BY 4.0. Snapshot 2026-09-20.

Every published JSON file carries that same string at license.attribution, so nothing has to be composed by hand. The full statement, including the rulebooks it does not cover, is in LICENSE-DATA.md.

Reference material about published payment rules. Not legal, compliance or financial advice. Orca cites rulebooks by section and edition and does not reproduce them; rights in the cited documents stay with their authors.

What is published

50 rails hold 1137 records: 777 reason codes and 360 rail facts. Under data/ the build writes 1 rails index, 50 rail files and 1137 record files, one for every record above.

Fetching one record instead of the dump

Paths are predictable and stable. A record's uid is <rail>:<id>; its file is the rail and the id, in that order, under data/records/.

data/rails.json                       every rail, its counts, and the path to its file
data/rails/us-ach.json                every record on US ACH
data/records/us-ach/C01.json          the one record whose uid is us-ach:C01

Start at data/rails.json if you do not know the rail ids: it lists every rail, its counts, and the path to its file. A rail file holds that rail's whole record set. A record file holds one record, unchanged, under a record key, with the licence and snapshot around it. Nothing under data/ is maintained by hand; one run of scripts/build.mjs writes all of it from corpus/, and the build refuses to publish if any of it disagrees with corpus.json.

What changed

The last 20 commits that changed something, 2026-09-21 to 2026-09-26, added 228 records, removed 0 and superseded 0; changed 1 deadlines, 1 actions and 73 meanings; demoted 1 records a trust tier and promoted 129; added, re-read or dropped 229 sources; found 0 newly stale; changed 5 known gap lines; and changed 73 other fields. 0 further commits changed formatting only and count as no change at all. Read from this repository's git history at build time, not from a stored tally; the list is in changes.json.

How a rule change is told from a reformat: the build compares the two versions of a record as parsed JSON, field by field, with whitespace collapsed and key order ignored. Indentation, re-sorted keys and a whitespace-only edit produce nothing and are counted as reformats, never as changes. A field the build does not recognise is still listed, as "other field".

What is not published, and why

No history older than the last few changes, and no "changed since <date>" query. The full history is in the repository's git log, which is where changes.json is read from; this file publishes the recent end of it. Per-record dates are in currency.effective_since, currency.last_verified and each corroboration's checked_on; effective_since is free text, and on many records it says the edition read gives no date, so it is not a timeline. Read each record's currency block.

No query endpoint and no keys. These are static files; fetch what you need. A hosted agent endpoint is a separate open decision.