There is a moment, every match night, when the train platform is the most dangerous place in the city. Sixty thousand people have just stood up, the venue is releasing the closest cohort first, and the platform (which fits 200, holds 280 in a pinch, and crushes at 320) is staring at a wave it cannot absorb. The dangerous moment is the one nobody is coordinating.
We don't have a transport-hub pilot running yet. This post is about how we'd design the seam if a venue operator and a transit operator agreed to scope one together.
01 · THE DEPLOYMENT WE'D TAKE TO A TRANSIT INTERFACEThe deployment we'd take to a transit interface
The deployment is not a stadium deployment and it is not a transit deployment: it is the seam between them. A single edge sensor at the platform's pedestrian throat, one at each major escalator, and an upstream sensor at the venue's concourse exit. Counts are anonymous, the model runs on-chip, and the seam itself is two protocols: an outbound feed (the venue's release rate) and an inbound feed (the platform's live load and the operator's next-service ETA).
What that would buy you, operationally:
- Live platform load, in real numbers, refreshed every second.
- Venue-side throttle on the concourse gate state, governed by the load.
- Operator coordination on the train cadence, so the throttle releases at the right moment.
02 · THE DECISION THE SYSTEM WOULD MAKEThe decision the system would make
The decision is a queue-and-release decision. If the platform is at 86% and the next train is three minutes away, holding 60 people at the concourse exit for ninety seconds is the safest possible thing to do. If the platform is at 40%, hold no one. If the platform is at 96%, hold more and message the queue with the wait.
The trick is to do it without telling 60 people they are being held. The trick is to do it by routing one foot-bridge to an alternate exit, by colour-coding the digital signs so the easy route looks easier than the hard route. The throttle is a steering decision, not a stopping decision. The platform supervisor doesn't see a queue forming; they see a curve that didn't spike.
03 · WHAT THE OPERATOR SIDE WOULD GIVE BACKWhat the operator side would give back
The transport operator's side of the seam is the easy half, as most metropolitan transit operators in Australia and Europe already produce platform counts and they already publish next-service ETAs. The platform-side feed is a single number per minute, refreshed by the operator's own platform sensors. We don't sense it; we just consume it. The venue side produces a single number per minute back: projected release rate over the next two minutes, in people per minute, by exit.
Two numbers, both anonymous, both already in production at the venue and the operator. The protocol between them is a JSON object, signed, sent every ten seconds. The protocol does not carry identity. There is no identity to carry.
04 · A WORKED MINUTEA worked minute
A hypothetical t+02:30 of a post-match egress. Platform 2 at 86%. Next train at 03:00 of egress time. The seam would compute:
- Holding capacity remaining on the platform: ~28 people.
- Projected venue release toward Platform 2 in the next 60 seconds: ~140 people.
- Throttle: hold 60 at concourse exit for 90s; redirect 50 to the alternate concourse (cleaner foot-bridge).
- Outbound message to the operator: "Holding 60. Releasing 110 over t+02:30 - t+03:30."
At t+03:00 the train arrives, platform clears to 38%, holds release. Concourse back to full release rate. Nobody on the platform feels held. Nobody on the train feels rushed.
05 · WHAT YOU ACTUALLY NEED FOR THIS TO WORKWhat you actually need for this to work
Three things would make this seam viable:
- Counts the operator already produces. Most metropolitan transit operators have them.
- A venue-side platform that can throttle. The gate-state and digital-signage layer, drive-able by a single API call.
- A privacy posture both sides can sign. The reason it works is that nothing identity-bearing ever crosses the seam.
06 · WHY THE ARCHITECTURE MATTERSWhy the architecture matters
The seam would work because the architecture refuses the wrong question. The venue isn't tracking attendees onto trains. The operator isn't tracking passengers back to events. Each side counts what it is allowed to count, exchanges the totals over a public protocol, and the system between them makes a routing decision out of two numbers.
That is the entire story. The privacy answer isn't a policy clause; it is the protocol's data model. There is nothing to leak because nothing identity-bearing is ever produced.
07 · WE'RE LOOKING FOR THE FIRST TRANSPORT-HUB PILOTWe're looking for the first transport-hub pilot
If you operate a venue or a major transit interface and the wave from one to the other is the most fragile part of your night, talk to us about a pilot.