Dispatch 04 / Engineering
A route change is a state change.
Inside Realvi’s interactive logistics scenario: a real graph calculation, explicit connection states, and a route that stays a proposal until a person approves it.
Realvi / Editorial perspective · 4 min read
Start with something inspectable.
Realvi’s public scenario explains a logistics workflow using a fictional road network with fourteen nodes and sixteen roads. It is an interactive explanation, not the production platform. Its route calculation uses Dijkstra’s algorithm over that displayed graph, so closing a corridor actually changes the available paths. The route is a result of the scenario’s data and constraints, rather than a decorative line drawn to fit the story.
A shorter route can stop being an option.
Measured from the depot in the fictional graph, the original route is 12.1 km. Excluding the bridge node produces a 16.2 km alternative through the southern corridor. Excluding the eastern corridor’s two affected nodes produces a 17.1 km northern alternative. These are illustrative distances from the website’s graph, not operational measurements or a Realvi performance benchmark. The useful question is what changed and which constraints made the original plan unavailable.
Two disconnections. Different consequences.
Losing the external internet uplink is different from a field device losing its connection to the local edge. Realvi’s architecture places maps, routing context, and command in a local environment. External exchange can become unavailable while that local environment remains connected. A disconnected phone, however, cannot receive a new command update until it reconnects; saved context and queued reports are a different capability from live coordination. The website scenario represents those states explicitly. It does not demonstrate service-worker support or a production offline deployment.
The proposed route is not an order.
A disruption puts movement on hold while an alternative is reviewed. The guided scenario makes the distance tradeoff visible before command approval, and movement only resumes after that approval. If conditions change again, the previous approval is no longer enough: the route must be reconsidered against the new state. This is the product principle we want to make understandable. A calculation informs an accountable decision; it does not silently authorize one.
A last-known position needs its limits.
When the scenario’s vehicle disconnects from the local edge, its movement pauses at the last-known position. The display does not pretend that a fresh order arrived or that the delivery completed. When the connection returns, the workflow can continue. That distinction matters in logistics software: a position, route, or observation needs its connection state and age to remain useful. Visible uncertainty is part of the operating picture.
An explanation is a starting point for evaluation.
The scenario ends with a debrief and an explicit replay, so a visitor can follow the whole chain from disruption to decision to delivery. It makes the assumptions visible enough to discuss. Real operational evaluation still needs its own infrastructure, devices, connectivity conditions, data, and acceptance criteria. Realvi is at the MVP stage, and conversations with operators, engineers, and strategic partners help determine what those evaluations should test.
From Realvi’s stated design principles and development direction. Planned capabilities are not claims of deployment.