From 3,822 Exposed to 190: Building AquaPulse for Water Crises on AWS
We built AquaPulse to go beyond water alerts and answer a harder question: what should a city actually do next? Here’s how live official data, citizen reports, AWS Rekognition, and a deterministic response engine came together — and what broke along the way.
From 3,822 Exposed to 190: Building AquaPulse for Water Crises on AWS
Description: AquaPulse started as a water-risk map. It became a decision system that combines live alerts, citizen reports, local simulations and AWS image analysis to answer a harder question: what should a city actually do next?
A flood alert can tell you that something is wrong.
It usually cannot tell you whether a city should clear a drain, deploy a pump, protect a hospital first, or which combination of actions will reduce the impact the most.
That gap became the reason we built AquaPulse.
During one of our Bengaluru flood scenarios, the system reached a simple but uncomfortable result:
3,822 people exposed.
We gave it different response options.
- Deploy Pump P02 → 2,568 exposed
- Clear Drain D104 → 1,067 exposed
- Clear Drain D104 + deploy Pump P02 → 190 exposed
The hospital that was at risk within about 30 minutes became protected.
That was the moment AquaPulse stopped feeling like another map and started feeling like a decision system.
The problem was not “show me a flood”
Cities already have rainfall maps, weather alerts, flood warnings and dashboards.
The harder questions begin after the alert appears:
Where exactly should we pay attention?
Why is this area becoming risky?
What may happen next?
What should we do first?
Water crises are also not only about too much water. The same city can face flooding during one part of the year and shortages during another.
So we designed AquaPulse around four questions:
- Where is the problem?
- Why is it happening?
- What happens next?
- What should we do?
Everything else in the product grew from those four questions.
Start wide, then go local
At the India level, AquaPulse uses live signals from NDMA and IMD.
The national view is intentionally not pretending to predict street-level flooding everywhere in India.
Its job is simpler:
Which districts need attention right now?
A user can move from India to a state and then to a district to inspect the current situation and the evidence behind it.
The risk layer shown by AquaPulse is our own derived operational view. It is not presented as an official government rating.
That distinction matters.
Once we reach a place where we have enough local information, the product changes from national situational awareness to a deeper local view: the HydroTwin.
The national layer answers where should we look?
The local layer answers what may happen here next?
The hospital made the simulation useful
For our Bengaluru flood scenario, we modelled the crisis forward in time.
At first, we focused on the flood spread itself.
But a changing polygon on a map is not a decision.
The more useful output was a sentence:
Flooding may reach the hospital within about 30 minutes.
That changed how we thought about the interface.
The important part was no longer whether the flood animation looked realistic.
The important part was whether the system could turn that future risk into a response.
Prediction is useful. A response is better.
Once the hospital became at risk, AquaPulse compared the available interventions.
The response engine is deterministic.
We deliberately did not let a language model invent numbers such as exposed population, hospital impact or intervention performance.
Those values come from the scenario engine.
For the flagship scenario:
Response | People exposed |
|---|---|
No intervention | 3,822 |
Pump P02 | 2,568 |
Clear Drain D104 | 1,067 |
D104 + P02 | 190 |
The combined response becomes the winner.
The hospital moves from AT RISK to PROTECTED.
This separation became one of the most important design decisions in AquaPulse:
AI can help interpret evidence, but critical response numbers should come from logic we can test and reproduce.
Official data is not enough
A government feed can tell us about a warning.
It cannot always tell us that a drain is blocked on one road right now.
So we added citizen reports.
A resident can send text and location through WhatsApp.
The production path is:
text
↓Twilio↓n8n↓AquaPulse↓Supabase / PostGIS
We verified this with a real phone.
A message arrived through Twilio, passed through n8n, was validated by AquaPulse and appeared in the citizen-report flow.
A location pin sent afterward was paired with the report instead of becoming a separate duplicate entry.
That sounds simple when written as five arrows.
It was one of the parts of the project that taught us the most.
Twilio taught us the difference between “received” and “usable”
Our first WhatsApp text worked.
Then we sent a photo.
Twilio received the photo message.
AquaPulse received and stored the report.
But when we tried to retrieve the actual media binary from Twilio, the trial account blocked it with an authorization error.
So the correct product state was not:
“AWS Rekognition analysed the WhatsApp image.”
It did not.
The correct state was:
“The WhatsApp report was received, but the Twilio trial account would not let us retrieve the media binary.”
That limitation stays visible.
For image analysis, AquaPulse uses a separate secure upload path that does reach AWS Rekognition.
This may sound like a small distinction, but it represents a larger rule we tried to follow throughout the build:
Do not claim more than the system can prove.
Where AWS fits
We did not want AWS to be a list of logos.
We wanted each service to have one clear job.
The image-analysis path is:
text
Secure image upload↓AWS Lambda↓Amazon Rekognition↓AquaPulse evidence
AWS Lambda
A Lambda function in
ap-south-1 handles the image-analysis request.This gave us a small serverless boundary between the public application and AWS image analysis.
The function runs only when needed, which fit the workload well.
Amazon Rekognition
Rekognition analyses the uploaded image and returns visual labels.
AquaPulse treats those labels as another piece of evidence.
They do not decide whether a flood exists, and they do not generate the final intervention numbers.
During our testing, the Rekognition path usually returned results in roughly one to two seconds.
Amazon CloudWatch
CloudWatch was less visible in the demo and much more useful while debugging.
When an image-analysis request failed, our first question was:
Did Lambda actually run?
CloudWatch let us answer that quickly and separate an application problem from an AWS invocation problem.
IAM
The Lambda execution role only receives the permissions needed for its job.
We did not want the public application to carry broad AWS permissions.
The AWS boundary stays narrow on purpose.
What fought back
The most useful lessons did not come from the parts that worked on the first try.
They came from the places where the architecture stopped matching reality.
1. Bedrock was not available to us
We explored Amazon Bedrock for natural-language explanation features.
Our account could not access the capability we wanted during the hackathon.
At first, we spent time trying to understand whether the issue was account status, model access, region or quota.
Eventually the better decision was to stop treating Bedrock as a dependency.
AquaPulse works without it.
And because Bedrock never became part of the live system, we do not claim that it did.
That decision made the architecture simpler and the demo more reliable.
2. Lambda concurrency taught us not to optimise blindly
During deployment, we tried adding reserved concurrency to the Lambda function.
The deployment rolled back because of the available account-level concurrency limits.
The function itself was fine.
The configuration was the problem.
We removed the unnecessary reservation and kept the actual image-analysis path unchanged.
The lesson was simple:
A setting that sounds safer in theory can make deployment less reliable if you do not understand the limits around it.
3. Putting n8n in the middle changed the trust boundary
Originally, validating a Twilio webhook signature was straightforward.
Then the pipeline became:
text
Twilio → n8n → AquaPulse
That changed an important detail.
Twilio signs the URL it actually calls.
Once n8n became the webhook endpoint, the signed URL was the n8n webhook URL, not the final AquaPulse endpoint.
Forwarding the signature and validating it against the old URL would have been wrong.
We changed the validation path so AquaPulse verifies the forwarded request against the configured n8n webhook URL.
A bad signature is still rejected.
This bug would never appear in a nice dashboard screenshot, but it mattered more than many visible features because it sat directly on the trust boundary of the citizen-report pipeline.
4. Live evidence broke our controlled demo state
At one point, a fresh citizen report arrived while we were running a deterministic flood scenario.
The report was correctly fused into the live evidence system.
Unfortunately, the controlled scenario also picked it up.
The application had not crashed.
The system was actually behaving consistently.
But our repeatable demo was no longer repeatable.
We changed scenario startup so deterministic scenarios begin from a clean snapshot, while new incoming evidence can still appear afterward.
That bug forced us to separate two things we had previously treated as one:
live operational state
and
repeatable scenario state
That separation made the product easier to reason about.
Confidence should increase with evidence, not magically become truth
AquaPulse combines different kinds of evidence.
In one scenario, confidence moves through:
text
52 → 64 → 68 → 76
and reaches CONFIRMED as additional evidence arrives.
The animation is not the interesting part.
The important part is what the system does not assume.
If there is no official signal, AquaPulse does not interpret that as:
“The government says this citizen report is false.”
It means only:
“There is no official signal supporting it yet.”
Missing evidence is not the same as negative evidence.
That distinction became important whenever citizen reports and official sources disagreed or arrived at different times.
The same decision loop has to work when there is too little water
We did not want AquaPulse to become a flood-only project.
In the scarcity scenario, a pipe failure increases the deficit from:
2.5 → 3.7 ML/day
The response logic then prioritises critical facilities such as the hospital.
The visuals change, but the questions do not:
Where is the problem?
Why?
What happens next?
What should we do?
This is why flood and scarcity live inside the same product rather than as two unrelated demos.
The crisis should teach us something
A response system that resets after every emergency felt incomplete.
So AquaPulse also keeps track of repeated infrastructure failures.
After the flood scenario, the system ranks:
#1 D104
#2 P031
under Priority Repairs.
The idea is simple:
text
Crisis↓Response↓Outcome↓Recurring failure↓Repair priority
The best emergency response is useful once.
Finding the infrastructure that keeps causing the emergency can be useful every year.
This is the part of AquaPulse that turns response into prevention.
What runs today
The production system currently includes:
- live NDMA signals
- live IMD signals
- India → state → district drill-down
- scheduled national refresh through n8n
- real WhatsApp text ingestion
- real WhatsApp location pairing
- Supabase/PostGIS persistence
- AWS Lambda
- Amazon Rekognition through secure upload
- Amazon CloudWatch
- deterministic local flood scenarios
- deterministic scarcity scenarios
- Best Response comparison
- Priority Repairs
There are also clear limitations.
We do not claim:
- nationwide street-level HydroTwin coverage
- WhatsApp photo analysis on the Twilio trial
- Amazon Bedrock in production
- an official government AquaPulse risk score
Those boundaries are part of the product, not footnotes we want to hide.
The architecture in one view
AquaPulse has four major paths.
Official signals
text
NDMA + IMD↓National ingestion↓Supabase / PostGIS↓AquaPulse live map
Citizen reports
text
↓Twilio↓n8n↓AquaPulse↓Supabase / PostGIS
Visual evidence
text
Secure upload↓AWS Lambda↓Amazon Rekognition↓AquaPulse evidence
Decision loop
text
Observe↓Verify↓Predict↓Decide↓Act↓Learn↓Prevent
The important part is not that every path uses the same technology.
It is that they eventually meet at the same question:
What action should be taken now?
What I would build next
Three things stand out.
1. More local data
The national layer can scale much further than the current high-resolution local model.
The next step would be bringing detailed drainage, terrain and infrastructure data into more cities.
2. Move beyond the Twilio trial
A full WhatsApp setup would remove the current media-retrieval limitation and let citizen photos continue into the same evidence-analysis pipeline.
3. Test the recommendations with real operators
The current engine can compare deterministic scenarios.
The important next question is whether city teams and water utilities find those recommendations understandable and useful under time pressure.
That requires real users, not another feature.
What we learned
The biggest lesson from AquaPulse was that displaying more data is not the same as helping someone make a decision.
We started with maps.
The product became more useful when we forced every screen to answer one of four questions:
Where?
Why?
What happens next?
What should we do?
The second lesson was to be careful about what each piece of evidence actually proves.
A WhatsApp message being received does not prove its photo was analysed.
A Rekognition label does not prove a flood exists.
A missing official signal does not prove a citizen report is false.
A simulated hospital impact is not the same as a live national forecast.
Keeping those boundaries visible made the project stronger, not weaker.
And the number I will probably remember from the hackathon is:
3,822 → 190.
Not because it made a good animation.
Because it turned a warning into a decision.
Try AquaPulse
Built for the AWS Hackathon 2026.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article