Case study

A GTFS feed that stays in conformance on every publish

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.

02

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.

03

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.

04

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.

05

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.

06

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.

07

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.

08

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.

09