TODS Validate: findings a scheduler can act on
Role: Independent engineer · 2026
I build tods-validate, a beta validator for the Transit Operational Data Standard, the open standard for crew runs, deadheads, and vehicle assignments that rides as an overlay on an agency's GTFS feed. It checks a package against TODS v2.1.0 and reports what is wrong, where, and what good looks like, with the spec section cited behind every finding. No agency adoption or production use is claimed.
Evidence boundary
- Built
- A TODS validator shipped as a CLI, GitHub Action, container image, pre-commit hook, browser playground, and language server
- Observed
- Findings cite TODS v2.1.0 section by section; the browser playground validates locally and uploads no feed data
- Not proved
- Agency adoption, production use, or any endorsement by the standard's maintainers
Selected measures
- current TODS specification version the validator checks against
- v2.1.0
- distribution forms named in the README, from a PyPI CLI to a VS Code client
- 7
- feed files uploaded by the browser playground; validation runs locally
- 0
- status, stated on the first line of the README
- Beta
The Transit Operational Data Standard (opens in a new tab) describes the side of transit that GTFS does not: crew runs, deadheads, vehicle assignments, the non-public service that makes the public schedule run. It began as Cal-ITP's Operational Data Standard and is now maintained with MobilityData. tods-validate (opens in a new tab) checks a TODS package against the current spec, v2.1.0, and reports findings in language a scheduler can act on.
A standard that rides on another standard
TODS works as an overlay: its files point into the agency's GTFS feed by reference. That seam is where feeds rot. A GTFS edit that is perfectly valid on its own can silently orphan the TODS references built on top of it, so the validator checks the seam, not just the package, and reports TODS references broken by GTFS changes.
What is wrong, where, and what good looks like
A finding is written for the person who has to fix the file, not for the person who wrote the spec. Each one says what is wrong, where it is, and what good looks like, and cites the spec section it comes from. Where a fix is mechanical and safe the tool applies it, and the automatic fixes are deliberately conservative.
It runs where the data owner is
- A CLI and a pre-commit hook, for the repository the feed lives in.
- A GitHub Action, so validation runs before a feed is published rather than after.
- A container image, for pipelines that want it pinned.
- A browser playground (opens in a new tab) that validates entirely in the browser. Feed files are not uploaded anywhere.
- A language server. The VS Code client exists and is not in a marketplace, and the README says so.
What it does not claim
- It is not an official validator, and the standard's maintainers have not endorsed it.
- No agency adoption and no production use are claimed.
- Its status is beta, and the first line of the README says so.
The companion piece is GTFS Scorecard, which reads the public layer of the same data the way this checks the operational one: against the document that defines it, with the citation attached.