Case study
An NTD pack assembled from the systems of record
Four numbers, four systems, assembled by hand twice a month. Veodyn builds the pack once from the systems of record, reconciles it against a month already filed, and keeps the rows behind every number.
The setup
Every month the agency owes the National Transit Database four numbers by mode and type of service: unlinked passenger trips, vehicle revenue miles, vehicle revenue hours, and vehicles operated in maximum service. Then it owes the board the same story in a different shape.
The numbers live in four systems. Boardings come from the APC units or the farebox. Revenue miles and hours come from scheduling or CAD. Peak vehicles come from dispatch. Routes, trips, and service days come from the published schedule. An analyst pulls each one by hand, into a spreadsheet, once for the filing and once for the board.
The data problem
The four systems do not agree, and the spreadsheet hides why. A mileage figure taken off the odometer includes deadhead, which revenue miles exclude. A mode is coded one way in the vendor's schema and another way in the filing. Someone adjusted a cell two years ago and nothing else knows.
The board deck and the filing drift apart because they were assembled twice. And when a reviewer asks for the rows behind a number filed eighteen months ago, the source table has since been purged, the spreadsheet has been overwritten, and the analyst who built it has moved on.
The Veodyn architecture
Veodyn assembles the pack once, from the systems of record, into one board and one table the filing is read off.
- One query per measure, with its definition written down. Each of UPT, VRM, VRH, and VOMS is a saved query against the system that counts it, named for the measure and the source, with what is included and excluded in its description. Which flag decides revenue service is written where the next analyst will find it.
- One composed table. The four queries join into a single month-by-mode table without copying any SQL. A month where one system was late shows as a gap, not as a silently dropped row.
- The scheduled half read off the archive. Routes operated, trips scheduled, and the days each pattern ran come from the GTFS archive the agency already publishes, so the service figures and the rider's app come from the same file.
- Reconciled against a filed month. The pack is run against a period already filed and compared line by line before anyone relies on it. Every difference has a named cause: deadhead in the mileage, a mode coded differently, a spreadsheet adjustment.
- Evidence that does not expire. Historical capture keeps the rows behind each month in the agency's own warehouse under a capture timestamp, with retention set to keep them, so a filed number can be reproduced in front of a reviewer.
- One governed report. The board's version is composed from the same queries, its numbers frozen at month end and reviewed before release.
The counting equipment, the scheduling system, and the filing itself stay where they are. The assembly stops being a monthly rebuild.
What the pack gives you
| The capability | What powers it |
|---|---|
| The board and the filing agree | Both read the same composed table from the same saved queries |
| Every number has a written definition | One query per measure, definition and system of record in its description |
| Differences from last year's filing have a named cause | Reconciliation against a filed month, line by line |
| A filed number can be reproduced on request | Captured rows under a timestamp, retention set to keep |
| Service figures match the published schedule | The scheduled half is read off the GTFS archive itself |
| The month closes once | Scheduled queries, a frozen report, review before release |
We don't file
Veodyn produces the numbers and the evidence behind them. It does not submit anything.
There is no upload to the reporting system and no form. Someone at the agency still enters the figures, and the counting equipment is still certified and sampled the way the reporting rules require, on the vehicle and in the sampling plan. What changes is that the figures arrive assembled, defined, reconciled, and backed by rows the agency can point at.
Why the warehouse is yours
The pack is a set of saved queries and a warehouse table, both in the agency's own deployment. A new analyst reads the definitions off the queries instead of reverse-engineering a spreadsheet. A reviewer gets the rows, not a screenshot. And when the counting vendor changes, the queries point at the new source and the history stays in the same tables.
See it on your numbers
Send us last year's filed month and the names of the systems it came from, and we will show you the pack reproducing it. Book a call.
More solutions
Other programs Veodyn makes possible, walked end to end. Or browse all solutions.
- Regional coalition · multimodalRegional rewardsOne rewards program across a dozen operators
- State DOT · traffic managementStatewide traffic opsOne operating picture across every TMC
- State DOT · transit dataStatewide transit feedOne current GTFS feed for the whole state
- Transit agency · feed complianceGTFS complianceEvery publish validated, only what passed is served
- Transit agency · procurementVendor switchHistory and feed address survive the cutover
- State DOT · multi-jurisdictionLocal federationCities join without giving up their data
- Grant-funded mobility · continuityThe pilot cliffIntegrations that outlive the grant
- Regional 511 · rider informationRegional namingRider-facing names across every operator