A Flood Warning System for the Bhote Koshi: What It Would Actually Take

Take the constraint from the hazard itself: a surge on the Bhote Koshi can reach the first settlements in tens of minutes. Every design decision follows from that number. A system that produces a correct alert in thirty minutes is not a slower version of a good system; it is a logging tool. This is what the working version looks like, written as a build note rather than a proposal.

For why the window is that short, and why the trigger is usually upstream of the border, see the explainer on why these valleys keep flooding. The short version: the release happens in terrain nobody downstream can see, the relief is extreme, and the flow arrives as a debris-laden surge rather than a gradual rise.

Sensing: cheap, redundant, and as far upstream as you can maintain

The instinct is to buy one expensive, accurate station. The better spend is several cheap ones spread along the reach. Accuracy matters less than the question being asked, which is not what is the water level to the centimetre but whether the level jumped abnormally in the last few minutes. Ultrasonic or radar level sensors, a pressure transducer as a cross-check, and an accelerometer or geophone to pick up the ground vibration a debris flow produces before the water itself arrives.

• Multiple stations per reach, so one failure does not blind the corridor.
• Solar with several days of battery reserve, sized for monsoon cloud rather than a sunny bench test.
• Cellular as the primary link, with satellite or a LoRa relay as fallback, because coverage in the gorge is uneven rather than uniformly bad.
• A local heartbeat: silence must raise an alarm, not simply produce an absence of one.
• Mounting above the design flood and off the bank, because a gauge washed away during the event it was meant to detect is the standard failure.

Two field constraints shape the hardware more than any specification sheet. Power: a solar panel in a gorge sees a short window of direct sun and weeks of monsoon cloud, so the battery has to carry the station through multi-day overcast at full duty cycle, and the duty cycle rises exactly when the weather is worst. Access: a station three hours' walk from the nearest road gets visited twice a year, so it needs to report its own health continuously and be repairable with parts a technician can carry.

Detection: trigger on rate of change, not on a fixed threshold

A fixed level threshold is the wrong trigger. Monsoon rivers cross high levels routinely, and a threshold tuned to avoid that noise sits too high to catch the surge early. Trigger on rate of rise over a short window, cross-checked against the neighbouring upstream station and, where available, against rainfall. Two independent stations rising steeply within minutes of each other is a far stronger signal than one station crossing a line.

The corollary is that the alerting logic has to run at the edge. A station should be able to raise a local alarm on its own reading, and a small controller at settlement level should be able to act on messages from the stations above it, without either depending on a round trip to a server. Treat the cloud as the place where data is archived, cross-checked and made available to researchers, not as the place where the decision is made. That split, edge decision and central record, is the same pattern behind any software system that has to keep working when the link drops.

In a valley with twenty minutes of warning, the alerting logic has to run at the sensor, not in a cloud region on another continent.

There is a temptation to reach for machine learning at this point. Resist it for the trigger. The dataset of actual surges in any single reach is tiny, and a model trained on a handful of events will be confidently wrong in a novel one. Statistical methods earn their place in the unglamorous middle: filtering sensor noise, detecting drift and silting on a gauge, and flagging stations whose readings have quietly stopped agreeing with their neighbours. That is a maintenance problem dressed as an analytics problem, and it is worth solving because a fleet of field stations degrades silently.

Delivery: assume the phone is asleep

This is where warning systems usually fail. An SMS to a subscriber list reaches whoever registered, whoever has signal, and whoever is awake. None of that is the population at risk at 2am. Delivery has to be layered and at least partly physical.

• Sirens in each settlement, loud enough to wake people, with a distinct pattern for flood that is taught before the season starts.
• Cell broadcast to every handset in the area rather than SMS to a list, where the operator agreement allows it.
• Direct machine-to-machine alerts to hydropower control rooms, highway posts and the dry port, which can act within seconds.
• FM radio and local network relays for people on the road, who are not in any settlement's siren range.
• A single agreed stand-down signal, so people know when it is over without having to ask.

Note what is missing from the top of that list. A mobile app is the last layer, not the first, because it reaches only people who installed it, kept it installed, granted notification permission, and are holding a charged phone with signal. An app is still worth building as the channel for detail, maps, stand-downs and post-event information, but treating it as the warning mechanism is the most common way a well-funded project ends up warning nobody. The trade-offs are the same ones described in what an emergency response app for Nepal actually needs: design for a mid-range Android handset, a weak connection and a cached fallback, or do not bother.

The border problem, stated plainly

The best sensor placement is upstream of the border, and that is not Nepal's to place. Until a data-sharing arrangement exists, the practical fallback is to instrument the northernmost accessible reach densely and accept a shorter window, while treating any upstream information that becomes available as a bonus rather than a dependency. Designing a system whose usefulness depends on a data feed that does not yet exist is how projects stall between the pilot and the handover.

False alarms are a system property, not a bug to eliminate

Set sensitivity so the system will occasionally cry wolf, then manage the consequence rather than the number. That means telling the community up front that a false alarm is the price of a real one, publishing what triggered each alert afterwards, and standing down clearly and quickly. A system tuned to never be wrong is tuned to be late. The generic version of this trade-off, and the rest of the sensing-to-response chain, is covered in how flood early-warning systems work.

The institutional side of the same question is who is permitted to trigger and who is permitted to stand down. In practice a district or municipal authority needs the standing decision written down before the season, because an alert that waits on a phone call to Kathmandu at 2am has already spent its budget. Automatic trigger, human stand-down, is usually the workable arrangement: the machine is allowed to be wrong in the safe direction, and a person is required to declare it over.

The part that decides whether it survives

Warning systems in the region rarely fail at installation. They fail in year three, when the funded pilot ends, a sensor silts up, a SIM stops being paid for and nobody's job description covers the fix. Budget maintenance as a line item from the start, name the institution that owns each device, keep spare parts locally rather than in Kathmandu, and hand over source code, schematics and data formats to whoever will still be there when the grant is not.

• A named owner per station, with a maintenance schedule and a budget attached to it.
• Parts sourced so a replacement is days away rather than a procurement cycle away.
• Open data formats and published APIs, so researchers and the next vendor can both read the archive.
• An annual pre-monsoon drill that tests the sirens and the people, not just the dashboard.
• Recurring costs written into the operating budget of the owning body: SIM data, battery replacement, and the technician's travel.

The running cost of a network like this is modest in absolute terms and awkward institutionally, because it is recurrent and nobody's capital budget covers it. That is a procurement problem rather than a technology problem, and it quietly decides the outcome.

What this is and is not

None of this reduces the flood. It buys minutes and it puts those minutes in the right hands. In a valley where the alternative is finding out when the water arrives, that is a large return on a modest, boring, well-maintained system. The engineering here is not the hard part, and pretending otherwise is how the hard part keeps getting deferred.