Last updated: 2026-07-16
This document describes the user value GTFS Scorecard will test next. The
infrastructure and operating gates are in roadmap.md. The
immediate delivery order is in feature-roadmap.md.
The primary users remain:
- A transit manager who inherited a GTFS export and needs to know what to ask their vendor or staff to change.
- A program liaison preparing for an agency check-in who needs a short, respectful action queue and evidence that an agreed change reached the feed.
A secondary user is a GTFS consumer deciding whether enough feeds publish a feature, such as wheelchair information or rider-facing translations, to justify product work. That decision needs row-level evidence and an honest geographic denominator; it does not need a new grade.
Riders and community advocates can read the same published facts through the rider-facing summaries. Private workflow and owner information does not belong on those surfaces.
The scorecard already turns validator output into a grade, plain-language findings, and prioritized fixes. The next job is narrower and more useful:
Carry one accepted action from an alert to a comparable recheck of the intended published feed, then preserve a reproducible closure receipt.
This is a claim about published-data change. It is not proof of a rider outcome, vendor causality, compliance, or certification.
- Findings are framed as fixes. Absence of realtime is neutral, never a zero.
- No public leaderboard or individual percentile. Cross-feed evidence requires aligned feed identity and measurement contracts.
- MobilityData's canonical validator remains the rule engine. The scorecard does not become a validator, editor, or feed host.
- Accessibility data stays prominent.
- Owner and ticket details are private by default. Public evidence is limited to what participants may share.
- A closure fails closed when feed identity or comparability is uncertain.
- Plain language, fast pages, mobile use, and open source remain baseline.
The service tracks more than 1,300 curated feed records, with numeric latest scores published for more than 1,100 of them. The public status page reports the exact current configured and published counts. It publishes per-agency grades, prioritized fixes, trends, provenance, finding clearances, board packets, and call-prep views. Program rollups cover most U.S. states and named cohorts. Alerts, webhooks, and liaison digests support repeat use.
The distribution surface includes a versioned read API, Parquet data, a read-only MCP server, badges, and a reusable GitHub Action. The site also offers self-serve submission, local pre-publish checks, request-backed one-off scoring, notice-to-fix guidance, detected-tool profiles, and procurement language.
These capabilities support discovery, triage, and evidence. A cleared finding without accepted ownership still does not establish a verified remediation.
The consumer feature finder now has a primary-navigation entry, language-aware
translations.txt filters, CSV export, and the same row contract in
api/v1/features.json. The interface states that the corpus is not a census.
The European GTFS evidence and beta gate are in
global-expansion.md.
Run a 90-day concierge pilot with one support-program liaison and two feed maintainers or vendors. Create at least six requests and test the complete workflow:
- Preserve exact before evidence for the intended feed and finding.
- Confirm an accepted owner or responsible role in the participant's existing work channel.
- Send a concrete request with a recheck condition.
- Recheck newly published bytes from the same feed identity.
- Issue a receipt only when the evidence remains comparable.
Product work during the pilot is limited to gaps a real request exposes. Likely small additions include a private request manifest, a participant-safe receipt view, or a better handoff template. The pilot does not justify a new ticket system or a broad workflow dashboard.
Consumer feedback may trigger bounded maintenance on the existing finder when the response is additive, ungraded, and uses the current artifact pipeline. It does not waive the identity, license, localization, or regional-coverage gates.
The pilot passes with three verified closures across two participant
organizations, zero false closures, reproducible evidence, and no more than
twenty minutes of hands-on support per request by the third cycle. The complete
gate is in roadmap.md.
Only after the pilot passes:
- Publish an open closure-receipt schema and deterministic verifier.
- Give agencies a portable quality passport for their verified feed identity and permissioned closure history.
- Rank repair guidance by observed results instead of author confidence.
- Automate one existing handoff channel selected from pilot evidence.
- Add a procurement acceptance record for contracted feed changes.
- Extend program views with aggregate remediation evidence when cohorts are comparable and privacy thresholds are met.
Success means a participant can repeat the workflow with less facilitation and still produce a valid receipt. Usage of the scorecard alone is not enough.
- Vendor and program learning: after enough comparable closures exist to report a pattern without ranking individual organizations.
- Verified self-management: after manual claims and corrections create a measured operating burden.
- Regional instances and guidance: after a named program commits to local review and ongoing operation.
- European GTFS beta: after the reviewed cohort meets the source, license,
identity, freshness, and country-spread gate in
global-expansion.md. - Full interface localization: after a named language steward owns human review and the pseudolocale, RTL, and locale-acceptance gates.
- Broader curation: after a local steward owns source and regional context.
- Deeper realtime maturity: after a program names the support decision the sampling will inform and funds a bounded collection plan.
- Research use of the longitudinal record: after privacy, licensing, and citation requirements are settled.
| Disposition | Product work |
|---|---|
| Shipped baseline | Scorecards, finding clearances, alerts, program views, knowledge base, API, data exports, MCP, badges, Marketplace Action, onboarding, and pre-publish checks. |
| Active now | Participant recruitment, six concierge requests, exact-feed rechecks, and audited closure receipts. |
| Maintenance | Alert tuning, source curation, consumer feature measurement, accessibility, security, release health, and bounded reliability work. |
| Demand-gated | Hosted one-off capacity, self-management, regional instances, European GTFS curation, full localization, deeper realtime, and research products. |
| Cut or parked | General editor or host, second validator, public rankings, public feed archive, cross-agency realtime archive, replacement ticketing, consumer-app scraping, and multimodal platform expansion. |
- A grade is not a compliance determination or certification.
- A finding that disappeared is not a verified remediation unless it is linked to accepted work and a comparable recheck.
- A published-data fix does not prove a rider outcome.
- A small set of closures does not establish vendor performance.
- Corpus size does not make the registry a census of a country or region.
- A European GTFS beta would not cover NeTEx-only transport data or all European public transport.
The product earns its next phase by proving closure, not by adding another surface to the existing scorecard.