The cheapest transit infrastructure in your city is the information layer, and it is broken

Planners and architects spend a great deal of effort on the physical parts of transit access: where the stop goes, how the plaza connects, whether the crossing is safe, how the building meets the street. That work matters and I'm not going to argue otherwise.

But there's a layer sitting on top of all of it that costs almost nothing to fix by comparison, fails constantly, and determines whether the physical investment gets used. It's the data. Whether the stop is where the app says it's, whether the departure time is real, whether the elevator is working right now.

I spent part of this year auditing the quality of published transit data across a large metropolitan region, and the results changed how I think about access.

What the audit found

The gaps weren't where you would expect them. Some of the largest and best-resourced agencies in the region had feeds that were missing, stale, or malformed. These are organizations with substantial technology budgets and competent staff.

That was the surprise. It was not a capability problem. They had the systems and the people. What failed was registration and validation: the unglamorous work of confirming that the data is published where consumers look for it, that it's current, and that it is correct.

Nobody owned that. Publishing the feed sat with one team. Checking it sat with nobody. The people who cared most about it being right were outside the organization entirely, with no channel to report a problem that anyone was obligated to act on.

Why this is an access question, not an IT question

Consider accessibility data specifically, because it's the clearest case.

The standard feeds agencies publish have places for this information: whether a stop is wheelchair accessible, whether a vehicle is, whether an elevator is currently out of service. In practice, those fields are frequently empty, stale, or never validated.

Now think about what that means for a rider who uses a wheelchair. Someone who can't trust the accessibility field doesn't get a degraded trip. They get no trip, because they cannot risk arriving at a stop they can't use and having no way to continue. The uncertainty is the barrier, and it's as effective as a flight of stairs.

You can build a perfectly accessible station and lose most of its value to an unmaintained data field. That's a bad return on a large capital project, and it is invisible on every measure a capital project is judged by.

The failure is silent, which is why it persists

A rider who checks the app, sees nothing useful, and stays home generates no complaint, no ticket, and no data point. From inside the agency, the service looks fine. Ridership is what it's. Nobody filed anything.

This is the property that makes information failures so durable compared to physical ones. A broken escalator produces complaints within the hour. A broken data feed produces silence, and silence reads as satisfaction to every reporting system an agency has.

If you take one thing from this: for every information system that serves the public, ask what a failure looks like from the outside. If the honest answer is "it looks normal," you need a check that runs on a schedule and complains, because no user is going to do it for you.

What this means for people who design places

Three things I would put into practice.

Treat the data about a place as part of the place. When a new station, entrance, or path opens, the moment it exists physically it should also exist correctly in the published feeds, with the same completion checklist as any other item. In practice, this lags by weeks or months, and during that window the thing you built is not findable by anyone using a phone to navigate, which is nearly everyone.

Treat outages as service information. An elevator outage should propagate to riders with the same urgency as a bus detour. For a subset of riders it's exactly as disruptive, and it is currently handled as a maintenance ticket rather than a service alert in most systems I have looked at.

Ask who validates, not who publishes. In any project where an agency commits to providing data, the question that predicts whether it will actually be right is who checks it and on what schedule. If that isn't in the scope, the data will be correct on the day of the ribbon-cutting and degrade from there.

The economics are absurdly favorable

This is what keeps drawing me back to it. Fixing an elevator costs what it costs. Making sure the elevator's status is published accurately costs a small amount of process and someone's name on a checklist.

For a rider deciding whether a trip is possible, those two things are close to equally important, and only one of them is expensive. We spend enormous care on the physical layer and almost none on the layer that tells people the physical layer exists.

That imbalance isn't a technology problem. It's a question of what we consider part of the project, and it's entirely within the power of the people scoping the project to change.