JAL-SETU: A Transparent Water-Access Planner for Delhi, Built on AWS
When water runs short, who gets the tanker first, and why? JAL-SETU ranks household needs with an open formula, plans real truck routes with Amazon Location, and keeps every limit of the data visible.
Live demo: https://main.deemkw95tpvmo.amplifyapp.com/ · Code: https://github.com/mysterio-Apoorva/JalSetu
Built for the Bharat Builds Tour with AWS Builder Center, in the Heat and Water track.
The problem we kept coming back to
In a city like Delhi, a dry tap is not an emergency that happens once. For many households it is a recurring part of summer. When piped supply fails, people call a helpline, wait, and hope a tanker turns up.
Two questions are hard to answer from the outside:
- Who was prioritised, and why? A household with an infant and a 70-year-old, seven days without water, looks the same on a call list as one that called louder.
- Did the water actually reach the right people? Knowing where a tanker is on a map is not the same as knowing it served the households that needed it most.
We did not try to replace the Delhi Jal Board or pretend to run real tankers. We asked a smaller question: can we make the reasoning behind water prioritisation visible, reproducible and honest about its limits?
JAL-SETU (जल-सेतु, "water bridge") is our answer.
What JAL-SETU does
A resident signs up, verifies their email, and then:
- Finds a destination by address, by clicking the map, or by entering coordinates.
- Sees recent weather and the local population density, with the data source and date shown next to each number.
- Picks a Jal Kendra (water distribution centre) and gets the fastest provider-estimated truck route to their location.
- Reports outage days and how many infants and elders live in the household, and receives a priority score from 0 to 100.
- Confirms a simulated trip with a six-digit code sent by email.
Real, simulated, and not claimed
This is the part we care about most. Hackathon demos often blur the line between what is real and what is mocked. We made that line a feature.
Part | What it is |
|---|---|
Accounts and email verification | Real, with Amazon Cognito |
Search and truck routes | Real results from Amazon Location (HERE), no straight-line fallback |
Weather | Real recent model output from Open-Meteo, shown with dates |
Population density | WorldPop 2025 modelled estimate, not a live census |
Priority score | A published formula, not a trained model |
Trip confirmation code | Real email through Amazon SES |
Tanker delivery | Simulated. Real litres delivered stay at zero |
The pilot is independently developed. It is not an official booking service, and reporting a need does not reserve a tanker.
The architecture
The whole backend is serverless:
- Amplify Hosting serves the React and Leaflet web app over HTTPS.
- Amazon Cognito handles sign-up, verification and role groups. Public registration only grants Citizen access.
- API Gateway verifies the JWT, enforces exact-origin CORS and throttles requests.
- AWS Lambda runs six handlers. Every rule is enforced on the server, never in the browser.
- DynamoDB stores reports, cached source data and simulation state, with encryption and point-in-time recovery.
- Amazon Location Service powers address search and truck routing.
- Amazon SES sends the trip-confirmation codes.
- Amazon Bedrock (Nova Lite) supports operational triage and a dispatcher copilot.
- SQS FIFO, Step Functions and EventBridge form the operational pipeline for dispatch and verification.
- S3 holds encrypted evidence, and CloudWatch and X-Ray give us logs and traces.
Design decisions we are proud of
1. The server owns the route origin. The API accepts a centre ID and resolves its coordinates itself. A browser cannot send its own starting point, so nobody can quietly change where a route begins.
2. "Optimal" means exactly what it says. Amazon Location is called with truck travel mode and the fastest-route option. That gives the provider's fastest estimated route. It does not promise the shortest distance, future traffic, or a perfect fleet schedule, and the UI says so.
3. The priority score is a formula, not a black box. Every household gets the same transparent calculation, rounded once to an integer.
Factor | Max points |
|---|---|
Days without water | 30 |
Consecutive dry days | 15 |
Heat (7-day mean temperature) | 10 |
Infants in household | 15 |
Elders in household | 20 |
Population density | 10 |
For example, 7 outage days, 6 dry days, 32.5°C, 1 infant, 2 elders and 15,000 people per km² give 15 + 3 + 5 + 3 + 8 + 5 = 39. These weights are pilot policy, not official drought criteria, and we say that clearly. Anyone can inspect them and argue with them, which is the point.
4. Bedrock helps, but never decides alone. Nova Lite triages complaints and explains the current snapshot to dispatchers. Its output is validated before any state change, and a model reply alone never dispatches a vehicle. The score residents see comes from the formula above, not from the model.
5. OTPs done carefully. Codes expire after ten minutes, allow five wrong attempts, and have a one-minute resend cooldown. Only a hash is stored, the code is never returned by the API, and the recipient always comes from the verified identity, never from the browser.
How we tested it
We ran 67 backend regression tests and 9 production-browser checks, plus lint, build, infrastructure-template and production-bundle checks. A separate deployed-service probe returned a 17.6 km truck route from the Vasant Kunj tanker station to a test point in Delhi, with about 400 geometry points and a roughly 39-minute estimate.
Mocked tests do not prove that a provider is available, so we kept live probes separate. We also did not claim inbox delivery of OTP emails while the SES sender was still being verified.
What we learned
- Honest limits build trust. Labelling simulated data made reviewers more confident, not less.
- Constrain the model. Letting an LLM explain, while a formula and server-side rules decide, kept the system predictable.
- Serverless fits this problem. Demand spikes in summer and is quiet otherwise. Paying per request suited a pilot with uneven traffic.
- Be specific about your data. Every number in the UI carries its source and date.
What comes next
To move beyond a pilot, JAL-SETU needs exact pins for three more Jal Kendras, verified wards and depots, real fleet capacity, confirmed staff and driver accounts, an accepted priority policy with age-distribution data, and supervised physical deliveries to validate GPS, photos and resident confirmation together.
Try it and tell us what you think
We built JAL-SETU because "who gets water first" should not be a mystery. If you work on public services, civic tech or serverless systems, we would love your feedback in the comments.
Built by Rishit Goswami Jha and Apoorva Kumar .
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article