Seal of Reliability

How it is calculated

The Seal of Reliability is made up of six criteria. This page documents the process that informed this definition, how each feed is evaluated when it's added to the Mobility Database, and the exact rules behind each criterion. This includes what triggers a pass or a violation, and how grace periods work.

Methodology

The six criteria were selected based on three research sources.

Consultation

Interviews with consuming applications identified the most common reliability pitfalls they encounter with GTFS Schedule data.

Real-world data

Analysis of feeds across the Mobility Database revealed patterns in how feeds fail, how often, and when they get fixed.

GTFS Best Practices

The criteria reflect recommendations from the GTFS Best Practices, grounding the Seal in the community's own standards.

Official

A feed is Official when MobilityData has confirmed it is authorized by the transit agency. This means it is published by, or on behalf of, the agency itself. MobilityData assesses this based on the domain of the producer URL, the feed submission contributor's personal information, the agency's website, and the feed_info.txt file. This determination is made manually and does not change based on automated checks.

Unlike the other five criteria, Official status is not subject to the six-month probation.

Stable

The Mobility Database evaluates stability based on the producer URL. A feed is considered Stable when:

  • The same URL has served the feed without redirects for at least six months

  • The URL appears to be permanent, meaning it does not look like a temporary file path with dates, times or seasons

Available

Once per day, the Mobility Database attempts to download the feed from its producer URL. A fetch is considered successful when the response returns an HTTP response in the 200 range.

Compliant

Each time the feed is downloaded, it is run through the Official GTFS Schedule Validator. A feed is Compliant when the validation report shows zero errors. Warnings and info notices do not affect compliance.

The Validator checks conformance with the GTFS specification's “must” requirements. A single error will trigger a violation.

Fresh: Rolling 7 days of coverage

Each day the feed is downloaded, the Mobility Database looks at the last date of service coverage in the feed's calendar.txt and calendar_dates.txt. That date must be at least 7 days after the download date. This ensures riders and downstream applications always have at least a full week of service data available.

Examples

Fetched Aug 6, 2026
Pass

Last service: Aug 20 (14 days ahead)

Last service date is Aug 20: 14 days ahead. Above the 7-day minimum.
Fetched Aug 6, 2026
Fail

Last service: Aug 10 (4 days ahead)

Last service date is Aug 10: only 4 days ahead. Below the 7-day minimum. Violation triggered.

Fresh: Continuous coverage

Feeds are expected to maintain a continuous, up-to-date service calendar with no gaps between versions, and a service window of two years or less.

No gaps between datasets

Service coverage must be continuous across consecutive feed versions. A gap occurs when a new version's first service date falls more than one day after the previous version's last service date. If v1 ends Aug 31, v2 must begin no later than Sept 1. A Sept 2 start is a violation.

Two-year service window

The total span of service dates in a dataset must not exceed two years. Feeds covering more than two years ahead are considered to contain stale, unreliable future data.

How feed_info.txt affects the calculation

When a feed includes feed_info.txt, producers can declare an official start and end date for their feed. MobilityData treats this as a declaration of intent. The presence of this file changes what counts as a gap violation.

Without feed_info.txt

  • calendar.txt and calendar_dates.txt are the only source of truth

  • Any gap in calendar data between consecutive datasets is a violation

  • A service window over two years is a violation

With feed_info.txt

  • A declared date range over two years is a violation

  • A gap in both the declared range and the calendar data is a violation

  • A calendar gap alone — when the declared range in feed_info.txt is continuous — is not a violation

Scenarios

Continuous, no gaps
Pass

Calendar data

Three consecutive datasets with no gaps and a total service window under two years.

Gap between datasets
Fail

Calendar data

Service ends Apr 14 in v1, but v2 does not begin until May 15. One-month gap triggers a violation.

Calendar gap, declared range continuous
Pass
feed_info.txt present

Calendar data

Declared range from feed_info.txt

Calendar data has a gap between Apr 15 and May 14. But feed_info.txt declares an unbroken range of Jan 15 to Aug 14. Calendar gap alone is not enough to trigger a violation.

Gap in both calendar and declared range
Fail
feed_info.txt present

Calendar data

Declared range from feed_info.txt

Both calendar data and feed_info.txt show a gap between Apr 15 and May 14. Both conditions present — violation triggered.

How the Seal is earned over time

Phase 1

Feed added

Evaluated immediately against all criteria

Phase 2

Probation

6 months per criterion (except Official), from the first day each is satisfied

Phase 3

Seal earned

Grace periods now apply

When a feed is added to the Mobility Database, it is evaluated against every criterion. For each criterion (except Official), a six-month probation starts from the first day it is satisfied, not the day the feed was added. All five criteria must each complete their six-month probation before the Seal is awarded.

Stable requires six months of uninterrupted URL history, so no newly added feed can satisfy Stable until it has been in the database for at least six months.

MobilityData evaluates feeds over time to help ensure consistent trustworthiness. Some feeds may have met the Seal's criteria before being added to the Mobility Database, but the evaluation focuses on what can be measured from the date of addition.

When the clock starts

CriterionProbation starts from…

Stable

First day the URL is added to the Mobility Database, provided MobilityData has not flagged it with is_producer_url_unstable=true. A flagged URL remains in a failing state even after six months have elapsed, since the URL appears to be temporary.

Available

First successful daily download with an HTTP response in the 200 range

Compliant

First validation report with 0 errors

Fresh: Rolling 7 days of coverage

First daily fetch where the last service date from calendar.txt and calendar_dates.txt extends at least 7 days ahead

Fresh: Continuous coverage

First dataset version with no gap between consecutive datasets and a service window of two years or less, from a mix of feed_info.txt and calendar data