FloodLine

Inspiration

When Chennai floods (2015, Michaung in 2023, Fengal in 2024, Ditwah in 2025) phone lines go down and people ask for rescue on WhatsApp, X and Instagram. Volunteer groups read those messages by hand and pass them to boat teams.

Reading about how volunteers handled these floods, one thing stood out to me: they were doing all of it by hand, scrolling through hundreds of forwarded messages, trying to remember which family was already helped. I wanted to build something that takes that memory off their shoulders.

The same problems come up every time: one family is posted ten times, so two boats go to the same house; old requests keep being forwarded after the family is safe; and requests nobody picked up scroll away. In the 2018 Kerala floods, volunteers built keralarescue.in for this, and the state adopted it. FloodLine is a much smaller attempt at the same idea, built for the way requests actually arrive in Chennai: forwarded WhatsApp messages in Tamil, English and Tanglish.

What it does

Volunteers paste messages, one at a time or a whole exported WhatsApp chat, in English, Tamil or Tanglish.
It pulls out the area, phone number, number of people, water level and who is vulnerable (pregnant, needs medical care, baby, elderly, cannot walk). Rules do this instantly and offline; Gemini re-reads each message to catch landmarks ("near Phoenix mall" is Velachery) and loose wording ("old couple" is two people).
Anything Gemini returns that isn't in the original message (a phone number, an area, an address) is not used, and the request shows what was dropped. In a rescue tool, a made-up detail can send a boat to the wrong house.
Messages about the same household are grouped into one request, with the reason shown (same phone number, or same door and street).
Requests are ordered by urgency with points anyone can read: pregnant +40, medical +40, neck-deep water +35, plus waiting time. A volunteer can always overrule the order.
Nothing gets forgotten: a request nobody takes for 45 minutes is flagged, a taken request with no update for 90 minutes is flagged, a later "we are safe" message is flagged, and so is a request people keep forwarding after the rescue, with a ready reply in Tamil and English asking them to stop.
Two volunteers see the same board: when one takes a request, the other sees it immediately. The whole board can be downloaded for a shift handover.
Map, call and WhatsApp buttons, a ready Tamil + English message asking the family if they still need help, phone layout, dark mode. The official helplines (112, 1070, 1077, 1913) are always at the top, because FloodLine is a coordination tool, not an emergency service.

How I built it

Plain JavaScript with no framework, hosted on GitHub Pages; Leaflet and OpenStreetMap for the map. There is no server: messages stay in the volunteer's browser.
Every message and action is stored as an event, and the board is calculated from the list of events. That makes syncing between volunteers, the history of each request, and testing straightforward.
A rule-based reader with 28 flood-prone Chennai localities spelled in English, Tanglish and Tamil script.
Repeat grouping by phone number and by door number + street words, with the reason recorded.
Google Gemini in JSON mode, ten messages per call, falling back to other Flash models when one is busy; a check function compares every field Gemini returns with the original message.
A generator of realistic flood-night messages with known answers, and a minute-by-minute boat simulation that compares today's way of coordinating with FloodLine.
17 unit tests.

Does it help? (results)

I can't test this in a real flood, so I simulated one. The same night is played twice with the same ten boats: once the way volunteer groups work today (read the chat top to bottom, call back, post in the boat group), and once with FloodLine, whose real code reads every message. Averages over 20 simulated nights of 110 households:

Households no boat ever reached: 26.8 → 1.2 (better on all 20 nights)
Boat trips to a family already rescued: 26.7 → 0.4
Critical households (pregnant, medical, baby, neck-deep water) that waited over 3 hours or were never reached: 14.0 → 6.5 (better on 18 nights, worse on 2)
It is not better at everything: the median wait is a little longer (1h 01m → 1h 06m for critical households that were reached), because lower-risk households wait while critical ones go first, and because today's way never reaches about 27 households, who aren't in its median. All assumptions are editable on the Results page.

Reading accuracy on 30 hand-written messages I did not tune the rules on: rules alone get 90.3% of fields right but only 37.5% of head counts; with Gemini and the checks, 98.6% overall and 100% of head counts.

Challenges I ran into

Using AI where a wrong detail sends a boat to the wrong house, so everything it says is checked against the message.
Writing realistic Tamil and Tanglish messages, and a hand-labelled test set, so the accuracy numbers mean something.
Making the comparison with today's way fair, and showing where FloodLine does worse.
Partway through, Google retired the Gemini model I started with for new keys; FloodLine now moves to another current model automatically.

Accomplishments that I'm proud of

Head counts went from 37.5% to 100% with Gemini, without letting it invent a single phone number or place.
In simulation, almost every household gets reached, and boats stop going to families who are already safe.
It works offline, in three languages, on a phone.

What I learned

How to use an AI model where mistakes matter (check everything against the source), how to measure honestly with a held-out test set, and how event logs make a shared, auditable board simple.

Built during the event

All of it, on November 13–14, 2026; no code existed before. Libraries: Leaflet, OpenStreetMap tiles, the Google Gemini API. The practice night and every name and number in it are made up.

A failure case, and how I tested

Failure case: a message with no area name, like "Near Phoenix mall backside streets flooded, old couple stuck in 1st floor". With rules only, it goes on the board as "area not recognised", with no pin and no head count. It is still listed and can be taken, but it ranks lower than it should. Gemini fixes this one because Velachery is in FloodLine's list of localities; a landmark outside the list would still not be recognised.

How I tested:

17 unit tests covering phone formats, areas in three scripts, Tamil and Tanglish messages, telling requests from updates and offers, grouping and not grouping, points, every warning flag, merging two volunteers' boards, rejecting a phone number or area Gemini invented, broken Gemini replies, and that the simulation gives the same result every run.
Measured the reader on generated messages (an easy upper bound) and on the separate hand-written set, with and without Gemini.
The simulation found a real bug: numbers written "+919876543210" with no space were missed. Fixed, with a test.
In the browser: ran the full practice night, opened two windows as two volunteers, checked phone size and dark mode.

What's next

A small server so volunteers on different phones share one board.
Taking requests by SMS for areas without mobile data.
More localities and landmarks, and street-level locations.
Reading Tamil voice notes.
Trying it with a Chennai volunteer group this monsoon.

Try it: https://nethra-r368.github.io/floodline/ · Code: https://github.com/Nethra-R368/floodline

Built With

Updates

Nethra R started this project — Nov 14, 2026 08:42 AM EST

Leave feedback in the comments!