AquaPrior: Missing Evidence Is Not Missing Need — Building Water Intelligence with AWS

How I built AquaPrior with AWS Lambda and Amazon S3 to turn 712,931 historical Hyderabad water tanker bookings into explainable investigation priorities - without ignoring areas where groundwater evidence is missing.
MARINGANTI SRIHITHA

Published Oct 11, 2026
Last modified Oct 11, 2026
712,931 water tanker bookings. 295 sections. Only 23 could be included in our combined groundwater-based ranking.
When I started building AquaPrior, I thought the biggest challenge would be figuring out which areas of Hyderabad needed attention first.
But the data led me to a different question.
Of the 295 tanker sections in our dataset, 218 recorded at least 100 bookings. Yet only 23 had the matched groundwater evidence needed for our combined ranking.
What about the other 195?
They hadn't disappeared from the city. They simply didn't have enough verified groundwater evidence for the same assessment.
I didn't want those sections to disappear from the application either.
That decision became the idea behind AquaPrior:
Missing evidence is not missing need.
AquaPrior is an AWS-backed water investigation-prioritization platform I built as part of Environmental Hacks 2026, the second event of the AWS Bharat Builds Tour, under Track 02: Heat and Water.
It brings together historical tanker demand, available groundwater evidence, and an explainable ranking workflow to help answer a practical question:
When investigation resources are limited, where should we start — and what should we verify next?
﻿
1. The Problem: A City Has Data, but Decisions Still Need ContextWater tankers are a familiar sight in Hyderabad.
Seeing how much people can depend on tanker water made me curious about the bigger picture. Individual bookings are recorded, but how can those records help us understand where further investigation may be valuable?
Imagine a team responsible for examining water-related concerns across hundreds of areas.
The team has enough resources to investigate only five sections.
Which five should come first?
The simplest approach would be to sort every section by its number of tanker bookings.
But that doesn't tell the whole story.
Tanker demand is one useful signal. Groundwater observations may provide another. The problem is that groundwater evidence isn't available with the same geographic coverage everywhere.
I wanted AquaPrior to make those differences visible rather than hiding them behind a single score.
The goal wasn't to build another dashboard that simply displays numbers.
It was to turn available evidence into a practical, transparent investigation workflow.
2. The Data: 712,931 Bookings, 295 Sections, and a Coverage GapAquaPrior analyzes two historical datasets:
Tanker booking records: June–August 2026
Groundwater observations: September 2–October 2, 2026
Data sources and attribution:
The analysis uses historical water tanker booking data and groundwater monitoring observations.
Water tanker data: Hyderabad Metropolitan Water Supply and Sewerage Board (HMWSSB), published through OpenCity —  https://data.opencity.in/dataset/hyderabad-water-supply-through-tankers-data 
Groundwater monitoring data: Telangana Ground Water Department, available through the National Water Data Portal —  https://nwdp.nwic.gov.in/dataset/ground-water-level-telemetry-daily-telangana-gw 
The datasets were processed for AquaPrior's exploratory analysis. The investigation scores and verification categories are project-derived outputs, not official government classifications.
The processed tanker data contains 712,931 bookings across 295 sections.
I applied a minimum threshold of 100 bookings per section to focus the investigation workflow.
This produced 218 demand-eligible sections.
However, after matching the available groundwater evidence, only 23 sections could be included in the combined ranking.
That left 195 demand-eligible sections without sufficient matched groundwater evidence.
The remaining 77 sections were below the booking threshold.
This wasn't a small missing-data problem. It affected most of the demand-eligible sections.
I realized that a ranking covering only 23 sections could be useful, but it would also be incomplete.
So AquaPrior separates the problem into two workflows:
Priority Planner: Rank the 23 assessed sections using both demand and groundwater evidence.
Verification Queue: Keep the other 195 demand-eligible sections visible and identify where further evidence collection should begin.
That separation is one of the most important decisions in the entire project.
﻿
3. How AquaPrior WorksAquaPrior has four main experiences: Explore Map, Priority Planner, Verification Queue, and Methodology.
Explore Map: Seeing the Assessed GeographyThe Explore Map uses React Leaflet and OpenStreetMap to display approximate locations of the 23 assessed sections.
Users can explore the map, select markers, and inspect information associated with each assessed area.
I wanted the map to be useful without implying that every section in Hyderabad had been assessed.
The geographic display represents the areas supported by the current matched evidence, not complete citywide groundwater coverage.
﻿
Priority Planner: What If We Can Investigate Only Five Areas?This is the part of AquaPrior that turns a ranking into a decision-support tool.
Suppose an investigation team can examine only five sections.
The user sets the capacity slider to 5.
The frontend sends a request to the AWS-backed ranking API, and the planner displays the five highest-ranked assessed sections.
If the team can examine 12 areas instead, the user changes the capacity to 12 and receives an expanded selection.
The interesting part isn't just changing the number.
It's understanding why a section appears in the ranking.
AquaPrior combines two normalized scores:
Priority Score = (0.60 × Tanker Demand Score) + (0.40 × Groundwater Evidence Score)
For example, Madhapur has:
The calculation is:
(0.60 × 80.11) + (0.40 × 47.07) = 66.89
The 60/40 weighting is a transparent prototype design choice. It isn't a scientifically validated probability of water scarcity.
Users can open the “Why?” explanation to examine the evidence behind an area's ranking, including its component scores and available groundwater context.
I wanted the application to answer more than “Which area is first?”
It should also help answer “Why is this area here?”
﻿
﻿
Verification Queue: Making Missing Evidence VisibleThis is the feature I'm most proud of.
The combined ranking includes 23 assessed sections, but 195 other demand-eligible sections lack sufficient matched groundwater evidence.
Assigning them the same combined score would require assumptions the available data couldn't support.
Ignoring them would create another problem: areas with recorded demand could become invisible simply because the evidence was incomplete.
The Verification Queue gives them a separate place in the workflow.
It organizes these 195 sections using recorded tanker demand:
The highest-demand 20% enter Verify First, the next 30% enter Verify Next, and the remainder enter Routine.
These labels indicate where evidence verification should be prioritized. They are not confirmed water-shortage classifications.
The purpose is to identify where location matching, groundwater observations, or field verification could improve the next assessment.
This feature represents AquaPrior's central principle:
Missing groundwater evidence should create a reason to investigate further, not a reason to assume there is no need.
﻿
Methodology: Explain the Decision, Not Just the ResultI wanted users to understand how the application reaches its recommendations.
The Methodology page explains the data coverage, scoring approach, groundwater evidence, and decision workflow.
It also describes how nearby groundwater stations are considered using 3 km and 5 km comparisons.
Station distance matters because a groundwater observation at one location cannot automatically describe conditions across an entire section.
Coverage limitations, station proximity, and disagreement between observations can all affect how the evidence should be interpreted.
AquaPrior follows a simple investigation process:
Understand demand → Examine groundwater evidence → Calculate investigation priority → Decide what to verify.
The application organizes information to support decisions. It doesn't replace field investigation or local expertise.
4. Building AquaPrior with AWS: From a CSV to a Working APIOne of my main technical goals was to make AquaPrior a working cloud-backed application.
I didn't want the Priority Planner to be a static list that only looked interactive.
I wanted the frontend to request results from a real backend.
The Technology StackWhat Actually Happens When the Capacity Changes?Here's the real data flow implemented in AquaPrior.
Step 1: The user selects an investigation capacity
For example, the user moves the Priority Planner slider to 5.
The React frontend makes an HTTPS request to the AWS Lambda Function URL with the parameter:
 ?capacity=5 
Step 2: AWS Lambda retrieves the processed dataset from Amazon S3
The Lambda function is written in Python and uses  boto3 , the AWS SDK for Python.
The processed ranking data is stored in an S3 object:
 data/final_priority_scores.csv 
The function retrieves it using:
It reads the CSV content and converts it into records using Python's CSV utilities.
This means the ranking API reads its processed data from Amazon S3 when handling a request.
Step 3: Lambda validates the capacity
The function reads the  capacity  query parameter.
If the value is missing or invalid, the function defaults to 10.
It also constrains the value to the supported range of 1 to 23.
In Python, that logic is:
Step 4: Lambda filters, sorts, and selects the results
The CSV already contains the calculated priority scores and supporting evidence.
The 60/40 calculation is performed during offline dataset preparation, not recalculated by Lambda for every request.
Lambda filters out records without valid priority scores, sorts the assessed sections by priority score in descending order, and selects the requested number.
The ranking operation uses:
The function then returns the highest-ranked sections up to the selected capacity.
Step 5: Lambda returns explainable JSON
The response contains more than a section name and score.
It includes the section rank, booking count, demand score, groundwater score, nearby-station information, coverage indicators, and other supporting evidence.
The React frontend uses this response to update the Priority Planner.
The Lambda response includes a CORS header for browser access and handles unexpected processing errors with an error response.
Why I Chose S3 and LambdaAmazon S3 provides a straightforward place to store the processed CSV dataset used by the API.
AWS Lambda fits the request-driven ranking workflow. The function retrieves the data, applies the requested capacity, and returns a structured result without requiring me to operate a continuously running application server.
Lambda Function URL gives the frontend a direct HTTPS endpoint, without adding a separate API Gateway layer to this prototype.
The frontend itself is deployed on Vercel.
Together, these components create a clear architecture:
React frontend → Lambda Function URL → AWS Lambda → Amazon S3 → Lambda JSON response → Updated Priority Planner
This was an important milestone for the project: the ranking interface wasn't simply displaying hardcoded results. It was communicating with an AWS-hosted backend that retrieved the processed dataset and selected results for the user.
One trade-off of this design is that Lambda retrieves and parses the processed CSV from S3 for each ranking request, rather than keeping the results in a database or cache. This keeps the prototype simple and makes the stored CSV the source for the API's ranking results, although a larger production system would need additional performance, access-control, and scaling considerations.
﻿
5. What Challenged Me MostChallenge 1: Defining What the Ranking Actually MeansInitially, sorting areas by tanker demand seemed like the obvious approach.
But tanker bookings represent recorded service demand, not a complete diagnosis of water availability.
Groundwater observations provide another signal, but they come with their own limitations.
I had to define what the final number could responsibly represent.
That's why AquaPrior uses the term relative investigation priority, rather than presenting the score as a water-shortage prediction.
Challenge 2: Discovering the 195-Section Evidence GapThis was the moment that changed the product.
After applying the demand threshold, 218 sections remained eligible.
But only 23 had enough matched groundwater evidence for the combined ranking.
I could have continued with a 23-section dashboard.
Instead, I added the Verification Queue so that the other 195 sections would remain part of the decision-making process.
It changed AquaPrior from a simple ranking interface into a more complete investigation workflow.
Challenge 3: Making the Results ExplainableA ranking score can look precise without being meaningful to the person reading it.
I wanted users to see the evidence behind the number.
That led to the 60/40 scoring explanation, the “Why?” details, and the Methodology page.
The goal was to make the system easier to question, understand, and improve.
Challenge 4: Making the AWS Integration Work End to EndA working frontend wasn't enough.
The planner needed to communicate with a backend, retrieve the stored dataset, and return results in a format the interface could use.
I connected React to an AWS Lambda Function URL and used  boto3  to retrieve the processed ranking CSV from S3.
The Lambda function validates the capacity, sorts the scores, and returns the selected sections as JSON.
One lesson I took from this was that a small, focused AWS architecture can still support a meaningful application.
The goal wasn't to use as many cloud services as possible.
It was to use the right services for the actual workflow.
6. What AquaPrior Can and Cannot ConcludeAquaPrior is an exploratory decision-support prototype, not a real-time water-shortage forecasting system.
Three limitations are especially important.
Different observation periods: The tanker booking data covers June–August 2026, while the groundwater evidence covers September 2–October 2, 2026. The periods don't overlap, so the combined analysis cannot establish causation.
Incomplete evidence coverage: Only 23 sections enter the current combined ranking. The other 195 demand-eligible sections need better groundwater evidence or geographic verification.
Relative scoring: The priority score compares assessed sections using chosen indicators and weights. It isn't a probability of scarcity or a confirmed diagnosis.
I believe making these limitations visible is part of building a useful environmental application.
A tool should help people understand what the data supports — and where more evidence is still needed.
7. What I Would Improve NextAquaPrior is a starting point.
The next improvements I would prioritize are:
Better geographic matching and groundwater verification for the 195 queued sections.
More recent and better-aligned tanker and groundwater observations.
Sensitivity testing to understand how different scoring weights affect the rankings.
Feedback from water-resource professionals on whether the workflow supports real investigation planning.
I'd also like to make the application more useful to people who aren't familiar with technical environmental datasets.
The long-term goal is to make evidence easier to explore and investigation priorities easier to explain.
8. The Biggest Lesson I LearnedWhen I began building AquaPrior, I expected the most important result to be a ranked list of Hyderabad's tanker sections.
But looking back, the part I'm most proud of isn't the scoring formula or the map.
It's the decision not to ignore the 195 sections with incomplete evidence.
Those sections still had recorded tanker demand. The lack of matched groundwater information didn't make that demand disappear.
Building AquaPrior taught me that environmental technology isn't only about turning data into answers.
It's also about recognizing uncertainty, showing the reasoning behind decisions, and knowing when more evidence is needed.
Amazon S3 and AWS Lambda helped me turn the processed dataset into a working cloud-backed application.
But the principle behind the product is even simpler:
Don't confuse missing information with missing need.
Prioritize. Examine. Verify.
Because missing evidence is not missing need.
﻿
Explore AquaPriorLive application:  https://aqua-prior.vercel.app/ 
GitHub repository:  https://github.com/Srihitha-M/AquaPrior 
Hackathon:  https://www.wemakedevs.org/aws/env 
AWS Lambda documentation:  https://docs.aws.amazon.com/lambda/ 
Amazon S3 documentation:  https://docs.aws.amazon.com/s3/ 
AquaPrior was independently designed and built by me under the name "Living Waters" for AWS Bharat Builds — Environmental Hacks 2026, Track 02: Heat and Water.