# A GTFS feed that stays in conformance on every publish

> How an agency keeps its static GTFS and GTFS-Realtime feeds in conformance by validating every publish against its own archive, refusing failures, and serving only what passed.

The feeds are the rider information. Veodyn checks every publish against the agency's own archive and serves only what passed, so riders stop being the validator.

## The setup

A transit agency publishes a static GTFS archive and a set of GTFS-Realtime feeds: vehicle positions, trip updates, service alerts. Google Maps, Apple Maps, Transit, and the agency's own app and website all read those same files. Whatever the feeds say is what the rider sees. There is no separate rider-information system to fall back on.

The feeds pass a validator when the vendor hands them over. Then the service changes, the schedule is republished, the real-time feed keeps running against the old one, and nobody checks again until a rider asks why the app shows a bus on a trip that no longer exists.

## The data problem

Conformance is a standing condition, not a one-time check. Two things have to stay true at the same time: the static archive has to describe the service actually running, and the real-time feed has to agree with the archive it extends. Every service change puts both at risk, because the archive changes on one schedule and the real-time feed is generated by a different system on another.

When either slips, the symptom is never an error message. It is a departure that never comes, a vehicle shown on a trip the schedule no longer contains, or an app that quietly drops the agency's service because the feed stopped parsing. The agency finds out from complaints, and by then the bad feed has been served for days.

Most agencies validate once, at procurement or at launch. What they need is validation on every publish.

## The Veodyn architecture

Veodyn puts a validator on the publishing path. The agency's own systems feed a node; the node publishes each real-time feed to a public address that rider apps read without a credential; and every publish is checked before it is served. Nothing publishes without the validator answering.

- **Checked against the agency's own archive.** The validator loads the static GTFS the feed is bound to and checks the real-time bytes against it, so a schedule that no longer matches the service surfaces as findings on the next publish instead of in rider complaints.
- **A failed check is refused.** The address keeps serving the last version that passed, with its original timestamp. In last-known-good mode the agency also sets a maximum age, past which the address stops answering rather than serving stale positions.
- **Warnings are kept.** A publish that succeeds with warnings records them in the publish history, so slow drift out of conformance is visible before it becomes an error.
- **The archive is checked on its own.** Before a service change goes live, the same validator service checks the static archive against the canonical rule set, using Veodyn's open-source reimplementation of the MobilityData validator.
- **Freshness is a verdict.** Each capture declares a cadence, and the board shows whether the source is actually keeping it rather than what the source claims about itself.
- **Publishing on a cadence.** An enterprise node republishes on a schedule from every minute upward, and backs off when a publish fails so a broken source does not hammer the address.

The agency keeps its scheduling and dispatch tools. Veodyn takes what they produce, checks it, and serves only what passed.

> **Diagram.** Agency dispatch and scheduling systems feed a Veodyn node whose validator checks every publish against the agency's static GTFS archive before serving a public feed address to rider apps.

## What conformance on every publish gives you

| The capability | What powers it |
| --- | --- |
| **Rider apps never receive a feed that failed** | The validator sits in the publish path; a failed check is refused and the last passing version stays up. |
| **A service change cannot silently break real-time** | Real-time bytes are checked against the agency's own static archive on every publish. |
| **Drift is visible before it is an outage** | Warnings retained in the publish history on successful publishes. |
| **Stale positions never masquerade as live** | Last-known-good mode with a maximum age, past which the address goes dark. |
| **The archive is sound before it ships** | Static validation route running the open-source reimplementation of the canonical rules. |
| **You know which sources are keeping up** | Declared cadences and freshness verdicts per capture. |

## We don't author schedules

Veodyn checks and publishes. It does not build the schedule.

The work of editing a timetable, drawing a route, and producing the archive still belongs to the agency and the scheduling tools it already uses. Veodyn takes what those tools produce, checks it against the rules every consumer applies, checks the real-time feed against that archive, and serves only what passed. The agency keeps its tools. Riders stop being the validator.

## Why the validator is open

The rule set is the canonical one, and the implementation is public. An agency can read the rules its feed is checked against, run the same checks on a vendor's archive during a migration, and hand the report to the vendor without arguing about whose validator is right. Because the public feed address is open, every consumer reads the same checked artifact, so conformance holds at the point of publication rather than being re-litigated by each app.

## See it on your feed

Send us your static archive URL and your real-time endpoints, and we will run the checks and show you the findings. [Book a call](https://cal.veodyn.com/sawinyh/30min).

## More solutions

Other programs Veodyn makes possible, walked end to end. Or browse [all solutions](https://veodyn.com/solutions/).

- [Regional coalition · multimodal - Regional rewards - One rewards program across a dozen operators](https://veodyn.com/case-studies/regional-rewards/)
- [State DOT · traffic management - Statewide traffic ops - One operating picture across every TMC](https://veodyn.com/case-studies/statewide-tmc-hub/)
- [State DOT · transit data - Statewide transit feed - One current GTFS feed for the whole state](https://veodyn.com/case-studies/gtfs-clearinghouse/)
- [Transit agency · procurement - Vendor switch - History and feed address survive the cutover](https://veodyn.com/case-studies/vendor-switch/)
- [Transit agency · federal reporting - NTD pack - Filing and board from one reconciled table](https://veodyn.com/case-studies/ntd-pack/)
- [State DOT · multi-jurisdiction - Local federation - Cities join without giving up their data](https://veodyn.com/case-studies/local-federation/)
- [Grant-funded mobility · continuity - The pilot cliff - Integrations that outlive the grant](https://veodyn.com/case-studies/pilot-cliff/)
- [Regional 511 · rider information - Regional naming - Rider-facing names across every operator](https://veodyn.com/case-studies/regional-naming/)

---

Source: https://veodyn.com/case-studies/gtfs-compliance/
This is the plain-Markdown twin of that page. Every page on this site has one at the same URL with ".md" appended, or by sending `Accept: text/markdown`. Site index: https://veodyn.com/llms.txt