Most routing systems treat the road network as a static graph. Nodes, edges, weights. You load the map data, run the optimization, generate routes. The assumption baked into this architecture is that the graph is reliable, that an edge present at planning time will still be present at execution time. For a significant portion of logistics operations, that assumption holds most of the time.
When it breaks, it breaks badly. A route plan built on a graph that no longer matches the physical network does not degrade gracefully. The vehicle gets to the closed road and the dispatcher gets a call. Everything downstream is wrong.
The Representation Problem
The first challenge in modeling real-time disruptions is representational, not algorithmic. A road closure is not a binary state. It can be fully impassable, passable with restrictions (weight limits, single-lane alternating traffic, reduced speed), or passable with uncertainty (reports of standing water but no confirmed closure). Each of these states has different implications for routing decisions, and collapsing them all into "open" or "closed" loses information that matters.
A more useful representation treats road segments as having a traversability score with an associated confidence interval and a decay rate. The traversability score represents current estimated passability (0 to 1, or a more granular functional classification). The confidence interval represents how certain the system is about that score based on the recency and source quality of the underlying data. The decay rate represents how quickly that confidence degrades in the absence of new information.
A segment confirmed as closed by a driver report two hours ago has high confidence in its closure status. A segment last updated via map data six hours ago with no driver feedback during an active weather event has low confidence in whatever status the map shows. A routing system that can distinguish between these two cases makes materially better decisions than one that treats both as equivalent "closed" or "open" designations.
Data Sources and Their Reliability Profiles
Real-time road network modeling requires data from multiple sources because no single source has sufficient coverage, latency, and reliability across all conditions. The sources each have different reliability profiles depending on the disruption type.
Traffic API feeds (commercial navigation data providers) offer high frequency updates but tend to underperform on low-traffic secondary roads, which are often the most critical alternatives when primary corridors close. They also have structural latency in disaster scenarios because the underlying probe vehicle data disappears when traffic disappears, which happens during evacuations and severe weather. An empty road looks like either "no congestion" or "no data," and the system cannot easily distinguish between the two.
Telematics data from your own fleet, where available, is high-quality but geographically sparse. Your drivers confirm conditions on segments they actually traverse, which means you get dense information about your active routes and essentially no information about roads you are considering as alternatives. This is the opposite of what you need when planning reroutings.
Government and agency feeds (DOT road closure notifications, emergency management status updates) are authoritative but low-latency. A state DOT may take two hours to formalize a closure that has been physically blocked for longer. In a fast-moving flood scenario, that lag is operationally significant.
Manual check-in data from field teams or local contacts is high-latency and low-volume but can be the most accurate source for conditions in degraded network zones where other data sources have gone quiet. In humanitarian logistics contexts, radio check-in systems from local partner organizations often serve as the primary ground truth feed when standard navigation data becomes unreliable.
Fusion and Conflict Resolution
The hardest part of the engineering problem is not ingesting these sources individually but fusing them coherently when they conflict. A traffic API showing a road as open while a field team reports it closed creates a conflict that the system has to resolve, because applying the wrong resolution to a dispatched vehicle causes a real operational failure.
A reasonable conflict resolution approach weights sources by their reliability profile for the specific disruption type and conditions. Traffic APIs are weighted higher for routine congestion events and lower for weather-driven closures. Field reports are weighted higher in crisis scenarios and lower in normal operations where the report may be stale or anecdotal. The recency of each report is a multiplier on the base weight.
Where sources conflict without resolution, the routing system should propagate uncertainty into the route plan rather than resolving it arbitrarily. A route that depends on a segment with contested status should be flagged as having elevated execution risk. The dispatcher gets that route with a note, not a false confidence that the route is clear.
Re-Optimization Triggers and Cost
Continuous re-optimization sounds appealing but has real computational and operational costs. If the routing engine re-plans every active route every time any road segment changes status, it generates a stream of updated routes that dispatchers cannot process and drivers cannot practically execute. A driver 10 minutes into a 45-minute delivery segment does not benefit from a new route that optimizes from their planned starting point.
The practical approach is to define re-optimization triggers based on impact thresholds. A change to a road segment triggers re-optimization for a route only if the segment is on that route's planned path, if there is sufficient remaining execution time to make the new route actionable, and if the route quality difference between the current plan and the re-optimized plan exceeds a minimum threshold. Small quality improvements do not justify the operational friction of a mid-execution route change.
For humanitarian operations where vehicles are not yet dispatched and the planning horizon covers the next six to eight hours, more aggressive re-optimization is appropriate because the plans have not been committed to execution yet. The cost of replanning is low relative to the cost of executing a plan against a network that has changed significantly since the plan was made.
What the System Cannot Know
There is a class of road disruption that no data source handles well: the very recent event. A bridge that failed in the last hour, a landslide that happened while vehicles were already en route, a flash flood that turned a passable road into an impassable one between planning and execution. These events create a gap between the model and the physical world that no amount of data source fusion eliminates entirely.
The appropriate response to this is not to pretend the gap does not exist, but to design the system so that the gap surface area is minimized. A vehicle that encounters an unmodeled closure needs a rapid path to updating the system state (driver report triggers an immediate segment status update), and the system needs to propagate that update to other routes that depend on the same segment. The latency between the first driver encountering a closure and all other planned routes being updated is the operational exposure window.
Minimizing that window is one of the specific design goals we focused on at Gallatin. When a driver reports an impassable segment, that update propagates to all affected active routes in the planning system within seconds, not the next planning cycle. The dispatchers for those affected routes see the conflict immediately and can make rerouting decisions with current information. It does not solve the problem of unexpected closures, but it limits how long the system runs on a wrong assumption.
Real-time road modeling is fundamentally about managing uncertainty, not eliminating it. The routes that come out of a well-built system carry honest uncertainty estimates, not false precision. That is a better foundation for operational decisions than a confident-looking plan built on stale data.
