Designing a Highway Incident Alert System for Nepali Conditions

Suppose a landslide blocks a highway, or a crash closes a lane on a blind bend. The drivers who most need to know are the ones already on that road, often in a valley with one bar of signal, on a handset that is several Android versions behind. Any alert system that assumes a modern phone on a good connection has designed for the wrong user.

The prize is worth stating clearly, because it is not glamorous. Nobody is preventing the original crash with a message. What a working alert system prevents is the second event: the queue that forms on a blind curve, the vehicle that arrives at a washed-out section at night, the ambulance stuck behind traffic that could have been held two kilometres back. Those are the outcomes to design for, and they are achievable with fairly ordinary technology.

Start from the worst connection, not the best

The design constraint that matters is intermittency. Coverage on Nepali highways is not uniformly bad, it is uneven: fine at a town, gone in a gorge, back at the next ridge. A system built around that reality queues messages and delivers them at the next window, rather than assuming a live socket.

• SMS remains the only channel that reaches every handset, and it should be the floor, not the ceiling.
• A lightweight app can cache the corridor ahead while signal exists, so the alert is already on the device before it is needed.
• Roadside signage still outperforms every digital channel at the moment of decision.
• Radio traffic bulletins reach long-distance drivers who will never install anything.
• Transport operators and their dispatchers are a channel in their own right, and one message to a depot can reach twenty drivers.

There is a second implication of intermittency that people miss. If a driver's phone reconnects twenty minutes after an alert was issued, they should receive it only if it is still relevant. A queued message about a blockage that has since cleared is worse than no message: it teaches the recipient that the channel is stale. Every alert therefore needs an expiry time and a superseding update, and the delivery layer has to check both before it hands over a message that has been waiting.

Who is allowed to raise an alert

This is the question that sinks most such projects. If anyone can report, the feed fills with noise and stops being trusted. If only a central office can report, alerts arrive after the queue has already formed. The workable middle is tiered: verified reporters such as traffic posts and transport operators can publish immediately, public reports are visible but marked unconfirmed, and confirmation upgrades them.

Corroboration does most of the work in that middle tier. Three independent public reports of the same blockage within a few minutes and within a short distance of each other is a much stronger signal than one, and the rule can be written down and audited rather than left to a moderator's judgement at 3am. Publish the confidence level with the alert. Drivers can handle "unconfirmed report of a blockage near X" perfectly well; what they cannot handle is a system that presents rumours and verified closures in identical language.

Language and literacy

An alert that arrives in English on a Nepali highway has failed. Messages need Nepali as the default, with the option of other widely spoken languages on specific corridors, and they need to be short enough to be understood at a glance by someone who is driving. Icons and a fixed sentence structure beat free text.

A fixed structure has a second benefit beyond comprehension. If every alert follows the same template, location first, then what happened, then what to do, the message can be generated from structured fields rather than typed, which means it can be produced in several languages at once and rendered as an SMS, an app notification and a radio script from the same source. It also keeps it inside a single SMS segment. Devanagari text is encoded as UCS-2, which allows roughly 70 characters per segment against 160 for Latin script, so a Nepali alert has far less room than people assume and long messages fragment and arrive out of order.

If the driver has to read carefully, the message is already too long.

Targeting: who gets the message

Sending every alert to every subscriber is the fastest way to have the alerts ignored. A driver in Biratnagar does not need a notification about a blockage on the Prithvi Highway. Targeting can be done three ways, and a real system uses more than one: by declared route, where a driver or operator subscribes to a corridor; by cell coverage area, where the operator broadcasts to handsets currently attached to towers along an affected stretch; and by device location, where the app knows the driver is on that road. The first requires no permissions and works on any phone. The second requires an operator agreement and reaches everyone. The third is the most precise and the least available, since it depends on installs and on a background location permission many users will decline, for good reason. If you do build the app, budget for it as a real mobile product with battery discipline and offline caching, not as a wrapper around a web page.

Measuring whether it works

The temptation is to report installs and message volume. The useful measures are different: how long between an incident occurring and the first alert going out, what share of alerts turn out to be accurate, and whether traffic actually redistributes after a message. Those numbers are harder to collect and are the only ones worth reporting.

Detection latency is the one to watch most closely, because it is where the system either earns its place or does not. It breaks down into the time from the incident to somebody noticing, from noticing to reporting, from reporting to verification, and from verification to delivery. Only the last two are software. If the first two dominate, which they usually do, the honest conclusion is that the project needs more reporters on the road rather than a better app, and saying so is more useful than shipping a faster backend.

Accuracy has to be published, not just measured. A visible log of every alert issued, whether it was later confirmed, and when it was stood down is the only thing that builds trust in a channel like this, and it is also the thing that makes the false alarm rate a managed number rather than an embarrassment. The same argument applies to flood warning, where a system tuned never to be wrong is a system tuned to be late, as set out in what a Bhote Koshi warning system would actually take.

What it depends on underneath

An alert system is only as good as its location data. Alerts referencing place names inherit every ambiguity described in Nepal's road crash data problem: the same bend under four spellings, chainage that was renumbered, a landmark that only locals know. Alerts need coordinates and a segment reference, which means the underlying road network has to be identified consistently before the messaging layer is worth building.

It also overlaps with emergency dispatch without being the same system. An incident alert tells other road users to avoid a place; a dispatch system sends help to it. They share a location model and very little else, and the design assumptions for the second are covered in what an emergency response app for Nepal actually needs. Trying to build one product that does both is a common and expensive mistake, because the users, the latency requirements and the failure modes are all different.

A realistic first version

One corridor. Verified reporters only. SMS plus a public web page. A published accuracy log. If that earns trust on a single highway, expanding it is a deployment problem rather than a design gamble. The engineering effort here is genuinely small, which we would say of any offline-first system of this shape, and it is the operating agreement with the people who report incidents that determines whether it lives past the pilot.