How to read your scorecard

What this checks

Transit apps and trip planners read a file your agency publishes, called a GTFS feed. It lists your stops, routes, and schedule. This tool is scheduled to download that feed once a day, run the canonical validator used across the GTFS ecosystem, and turn the result into a grade and a short list of fixes. The status page shows when that work actually completed. It does not inspect your vehicles or judge your service, only the data file. New to the terms? Jump to the glossary.

The grade blends four things: Correctness (does the data follow the rules), Freshness (is the feed about to expire), Rider experience (are accessibility, fares, and destinations filled in), and Realtime quality (if you publish live arrivals, sometimes called GTFS-RT). If you do not publish realtime, that is fine and does not count against you.

What the grades mean

• A Solid. The feed is current and well filled in.
• B Good, with a few optional fields to add.
• C Working, but with real gaps worth fixing.
• D Several gaps; start with the top fix.
• F Usually the feed has expired or is missing required data, so trip planners may have dropped it. This is the urgent one.

Most small and rural feeds we check land between F and B. A grade is a starting point for a conversation, not a verdict on your agency.

Grade margins and weight sensitivity

Letter grades have edges, and a score can sit right next to one: 89.9 is a B and 90.1 is an A, yet they are nearly the same feed. So every scorecard artifact states its distance to those edges: margin_to_next_band is how many points to the next letter up (“a B, 0.4 points from an A” — null for an A, which has no higher band), and margin_to_lower_band is how far the score sits above the floor of its current band. A small upward margin is encouragement, not a warning: it means the next letter is within reach, often with a single fix.

The category weights behind the score are documented judgment calls, so we also measure their consequences the same way: a current-contract study has not been published yet. When it runs, its headline lands here and the full numbers are published at sensitivity.json.

Methodology sandbox

The grade blends the four categories with fixed weights. Curious how much those weights matter? Move the sliders to reweight the rubric and watch how the aggregate grade distribution changes for the current comparison-eligible cohort. The sandbox never names hypothetical winners or losers. Nothing is saved and no grade on the site changes; this is a what-if you run in your own browser. Feed records without realtime data have that weight spread across the categories they do have, exactly as the published score does.

Loading the live weights and eligible feed scores…

What to do

Start at the top of "Top things to fix." We put the most rider-affecting fix first. If your feed has expired, that will be fix number one, because an expired feed is invisible to riders even while service continues. Each fix says roughly how long it takes. You do not have to do them all; doing the first one and re-publishing is a real win.

If you did not make the feed yourself, the agency or vendor that exports your GTFS is who makes these changes. Hand them the top fix.

What this is not

This is a data-quality lens to help you improve the feed. It is not an official compliance determination from any transit program, and a low grade does not mean your service is bad. See the listing and removal policy for how a listing can be corrected or removed.

Methodology and versions

New checks use scorecard rubric v1.3 on top of the MobilityData gtfs-validator 8.0.1, using portable GTFS fields and published weights. California guidance informed the first profile and remains a local authority for California, not a worldwide compliance standard. The same validator and methodology version used for each stored grade is stamped on its scorecard, so older and current results remain traceable without implying they are directly comparable. The full method, with citations, is in the scoring rubric.

When the rubric changes we log it here with the date it took effect, so a score change is never a silent rule change:

Rubric v1.3 Effective 2026-07-24

The headsign component no longer treats a blank trip_headsign as a defect when every trip on a route follows one closed stop pattern, one shape, and one direction. This corrects a false positive found through maintainer feedback on MRC de Joliette's one-way loop routes. Routes with multiple directions or patterns retain the check, and the guidance no longer tells producers to copy route names into trip_headsign.

Rubric v1.2 Effective 2026-07-13

Realtime quality now assesses only the GTFS-Realtime feed kinds an agency publishes. Unconfigured kinds are neutral, and TripUpdates coverage or VehiclePositions plausibility enters the score only when that kind is configured. Finding points use the same measurable-component denominator as the category score, and a dependent measure drops out when its endpoint produced no successful sample. A fixed-corpus replay projected 15 of 31 partial-feed artifacts changing letter bands; see docs/rubric-impact-1.2.md.

Rubric v1.1 Effective 2026-06-16

The most rider-affecting fix is ranked first, and every grade now carries the validator and rubric version that produced it, so a trend can tell a feed change apart from a methodology change.

Rubric v1.0 Effective 2026-06-11

First published rubric: four weighted categories (Correctness 35%, Freshness 20%, Rider experience 25%, Realtime 20%), A-F grade bands, scored on the MobilityData gtfs-validator and anchored to the California Transit Data Guidelines v4.0.

Glossary

Plain-language definitions for the abbreviations and jargon used across the scorecard. Each term is also defined inline the first time it appears on a page.

GTFS

The standard data file an agency publishes so apps can show its stops, routes, and schedule.

GTFS-RT (GTFS-Realtime)

The live companion to GTFS: real-time trip updates, vehicle positions, and service alerts.

RT

Short for realtime: live arrival and position data, as opposed to the static schedule.

United States terms

These appear only on the site's explicitly U.S.-scoped reporting and equity views.

NTD

The U.S. Federal Transit Administration's reporting system for transit agencies.

FTA

The United States federal agency that funds transit and runs the National Transit Database.

D-10

The annual U.S. NTD form on which an agency certifies its GTFS feed.

ACS

The U.S. Census Bureau survey used for the U.S. equity overlay's poverty and access indicators.

Data and implementation terms

MDB

The Mobility Database, the open catalog of transit feeds the scorecard discovers feeds from.

GBFS

A sibling open spec for shared bikes and scooters, related to but separate from GTFS.

YAML

The plain-text config format used to add an agency in the repository (no YAML needed via the form).

CI

Continuous integration: automated checks that run on every change, including the feed grader.

SHA-256

A fingerprint of the exact feed bytes scored, so a grade is reproducible and citeable.