Put feed quality in the contract.

Sample contract clause

The vendor shall deliver a GTFS Schedule feed that produces zero errors from the current MobilityData canonical GTFS validator; includes a feed_info.txt with a service window covering at least the next 30 days at all times; populates wheelchair_boarding on stops and wheelchair_accessible on trips; and remains downloadable at a stable public URL. These are the criteria of the GTFS Scorecard conformance mark (Valid, Current, Accessible); the agency may verify the feed holds the mark at any time on its public scorecard page, at no cost to either party.

Sample acceptance test

Deliverables need a gate a non-developer can hold. This one is a single command the vendor runs and hands you the output of:

Before acceptance, the vendor shall demonstrate the delivered feed earns at least grade B on the GTFS Scorecard rubric, for example by running `scorecard try <feed-url> --min-grade B` or the equivalent CI check, and shall provide the resulting report to the agency.

The conformance mark on the agency's scorecard page is the ongoing version of the same gate: it appears while the feed is valid, current, and carries accessibility fields, and it disappears when any of those lapses, so a contract can reference it as a standing condition rather than a one-time check.

What each part buys you

• Zero validator errors is the same bar the apps and state programs apply, so your feed loads everywhere riders look.
• A 30-day forward window stops the silent failure where a feed quietly expires and trip planners drop your agency.
• Accessibility fields let a wheelchair user plan a trip at all.
• A stable public URL is the first thing the FTA looks for at NTD time.

Verify it cheaply

You do not need to take the vendor's word for it. Find your agency on this site to see where the feed stands today, add a GTFS Scorecard check to a build so a bad feed fails before it publishes, or paste a feed URL to grade it right now.