The story begins with a VoIP (Voice over Internet Protocol) call. A driver reports a blocked road. A section of the network has just become unusable, and somewhere in a control room, an operator needs to respond. The passengers on the 10 vehicles that are scheduled to pass the blocked street in the next two hours, approaching vehicles do not know it yet. The displays at the bus stops still show the original schedule. The passenger apps still point to a stop that will be closed in minutes.
What happens next depends entirely on the architecture sitting behind that control room screen.
Gijs ter Horst, Chief Commercial Officer at Ximedes, has spent years building and refining the systems that handle this moment. His view is direct. "The real story here is what needs to happen after a disruption, and how the system architecture makes that possible or impossible."
While the public conversation around public transport technology tends to focus on artificial intelligence as the headline, the harder, more consequential problem is the plumbing, the data flows, and the decision architecture. The loop that connects a driver's observation to a passenger's phone in under fifteen minutes.
Disruptions are unavoidable. What operators can control is how fast and how clearly they respond. In Amsterdam, and a growing number of other regions, that response is governed by specific requirements set by the authorities. Information must arrive within fifteen minutes, covering the cause and expected duration. Information must also be consistent across all channels: app, website, vehicle displays, and stops, and reach passengers before they arrive at an affected stop, not after they've already waited.
These are not aspirational targets. When expectations go unmet, trust erodes fast, and the Public Transport Operator risks a fine. A blank display or conflicting information signals a system that is not in control. Meeting this standard requires a system that was designed to meet it.
Colonel John Boyd's OODA loop, Observe, Orient, Decide, Act, was built for military decision-making under pressure. Adapted for public transport, it becomes OODAI, with a fifth step: Inform. In transit, informing passengers is not a follow-up to the operational response. It is part of it, and it must happen simultaneously.
The loop must complete within fifteen minutes. When it does, the disruption has been handled, and passengers know exactly what changed.
The Ximedes ITCS receives a continuous stream of data from on-board computers in every vehicle, driver identity, line, position, and status, maintaining a live digital twin of the network. Any deviation, delay, or driver report registers immediately as something the system can act on.
The system filters the noise. Not every anomaly requires a response. By highlighting genuine issues and stripping out background chatter, it allows the operator to concentrate attention where it matters.
Figure 1: Orient by selecting the bus line that is affected by the disruption
The decision interface offers defined choices: cancel the trip, shorten it, or create a diversion. Each carries different implications, cancellation is fast but strands passengers; shortening preserves partial service; a diversion keeps the route running but requires the operator to plot an alternative path using tools that factor in vehicle specifications and road constraints.
The operator makes the call. "The human hits save. That's intentional." AI sits within this workflow as one layer; it can draft display text or surface options, but it does not govern the decision. "AI is a relatively small part in a larger story."
Figure 2: Marking the affected part of the line and making a decision on how to handle the disruption.
When the operator confirms, the architecture splits into two simultaneous data flows.
Consistency is either met here or it is not met at all. The architecture must synchronise these outputs by design.
Figure 3: The ITCS system suggests a plausible deviation that can be changed by the operator if needed.
Legacy systems were not built for this speed. Their information flows are siloed: operations, passenger information, and driver communications all handled separately, sharing data slowly and incompletely. The gaps between them become visible to passengers at exactly the moments that matter most.
Modern systems treat the full OODA loop as a single architectural requirement. Board computers, the ITCS, and passenger-facing channels function as one connected system. The standards that enable this, NeTEx, VDV 452, ITxPT, exist precisely to ensure coherence across vendors and platforms. PTAs gain real-time service monitoring. Operators reduce control room pressure. Drivers receive clear instructions. Passengers get consistent information everywhere they look.
The fifteen-minute target is the measurable output of all of this, not a product of effort alone, but of a system built to deliver it.