Did the Sprinkler Even Come?
A resident says the water truck never reached their street. We built the part of HawaCommand that answers from the truck's own telemetry on AWS, and found a config change that would have recommended a ₹25,000 fine for an honest driver.
It is 9 a.m. in Anand Vihar. The road outside a resident's gate is grey with dust. The ward's schedule says a water sprinkler covered this stretch between 7 and 9. The resident opens an app and taps "The machine didn't come".
Today, a complaint like that ends in an argument. The schedule says yes, the resident says no, and there is nothing in between that both sides trust.
That small argument is Delhi's air problem in miniature. The city does not lack machines, and it does not lack air-quality data. What it lacks is a way to decide where the machines should go, to check that they went, and to prove that it helped.
This post explains the problem we chose for Environmental Hacks 2026 (Air track), the system we built to solve it, how it runs on AWS, and what is still simulated.
The short version
- The problem: Delhi's anti-pollution fleet runs on fixed routes. Nobody decides each day where it matters most, nobody can check that a machine actually sprayed, and nobody can prove a spray cleaned the air.
- The solution: HawaCommand, a decision layer on top of the machines Delhi already owns. It maps pollution street by street, works out the likely cause, forecasts 72 hours ahead, ranks hotspots by the people exposed, drafts a dispatch plan for an officer to approve, checks that each machine turned up, and measures whether the air improved.
- What is real: live station data, the models, the dispatch planner, the officer console, the field and citizen app, citizen reports, alerts and the AWS data pipeline.
- What is simulated: the vehicles, their trackers and the interventions. No hardware has been built, and no city agency uses this yet.
Live console: http://ec2-13-207-49-123.ap-south-1.compute.amazonaws.com:3000
Code: https://github.com/shankywho/HawaCommand
Part one: the problem
Delhi already owns the machines
Delhi deploys 376 anti-smog guns, 266 water sprinklers and 91 mechanised road sweepers. Monitoring stations publish readings every few minutes, and an AQI number reaches every phone.
Yet three questions go unanswered every day.
1. Where should the machines go? Routes are planned in advance, but pollution moves hour by hour. And the highest AQI is not always where the most harm is. A landfill yard at AQI 450 with nobody nearby matters less than a school street at 350 when children line up for morning assembly.
2. Did the machine actually go? GPS can show that a truck drove its route. It cannot show that the pump was on. A sprinkler driving with its pump off looks the same on a map as one that is spraying. When a resident says "it never came", there is no evidence either way.
3. Did it work? Air changes on its own. Wind shifts, traffic thins, the morning sun lifts the inversion layer. If PM2.5 falls after a sprinkler passes, that alone proves nothing. So no one can say which runs worked and which were wasted shifts.
Under all three sits a fourth problem: the wrong tool for the cause. Water settles dust; it does nothing for smoke from burning waste. Road dust is about 15% of Delhi's winter PM2.5, yet it draws about 64% of available NCAP funds (CEEW, Feb 2026). Spending follows what is visible, not what is measured.
Our problem statement
How can a city send the anti-pollution fleet it already has to where people breathe the worst air, confirm that each machine did its job, and prove whether the air actually got cleaner?
Three groups live with this problem: ward officers in MCD and DPCC, who decide where machines go; contractors and drivers, who run them; and citizens, schools and hospitals, who breathe the result.
Part two: the solution
HawaCommand does not add machines or build smog towers. It is a decision layer for the fleet Delhi already runs, organised as one loop:
Step | What HawaCommand does |
|---|---|
Sense | Pulls live readings from Delhi's monitoring stations, plus position and pump readings from every vehicle |
Map | Estimates PM2.5 on a 500 m grid across Delhi (10,600 cells), with a confidence score for every cell |
Attribute | Labels each hotspot's likely cause: road dust, traffic, open burning, regional smoke or industry |
Forecast | Predicts PM2.5 up to 72 hours ahead with a likely range, plus the expected GRAP stage |
Decide | Ranks hotspots by people exposed and drafts a dispatch plan for an officer to approve |
Act | Sends routes to drivers, sites to inspectors, and alerts to schools and citizens |
Verify | Checks that each machine turned up and sprayed, then measures whether the air improved |
What gets verified feeds the next plan. That last step is the one nobody else builds.
The live map: hotspots ranked street by street, each with a likely cause and the action it needs.
1. Rank by people, not by AQI
HawaCommand scores each hotspot by excess exposure: how far PM2.5 is above India's 24-hour standard of 60 µg/m³, times how many people are there that hour, times a weight for vulnerable places like schools and hospitals, over the hours it lasts. A school street at 350 now outranks an empty yard at 450, which is the point.
2. Match the machine to the cause
The plan pairs each hotspot with a tool that works on its cause: sprinklers and sweepers for dust, inspection teams for burning, traffic measures for congestion. A sprinkler sent to a fire is rejected by a fixed rule, not by an AI's judgement.
AI agents then explain the plan in plain words and challenge it, the way a reviewer comments on a proposed change. The officer sees what changed from the usual routes, why, and what the reviewer objected to. Nothing is dispatched until a person clicks Approve.
A plan waiting for approval: the Planner agent's reasoning, the changes from the usual routes, and an Auditor comment that must be resolved first. Plan #214 is a seeded demo plan.
3. Proof, step one: did the machine come?
Each vehicle carries a HawaTag, a small tracker (estimated at about ₹6,000) with GPS plus water-flow and pump-current sensors. Its readings say not just "I was here" but "I was here, and I was spraying".
That makes a citizen's complaint checkable. When someone reports that a machine never came, HawaCommand reads the vehicle's last three hours and applies one rule: at least 15 minutes within 500 m of the site, with the pump running. The answer comes with its evidence (minutes on site, pump flow, closest approach), so anyone who disagrees can argue with the numbers instead of the verdict. If the rule fails, the system recommends a penalty. A person decides.
The Fleet page: each machine's status, pump flow and water used. No vehicle was reporting when we took this, so it shows demo data and is labelled "Simulated".
4. Proof, step two: did the air get cleaner?
To know whether a spray worked, you need to know what the air would have done without it. HawaCommand answers with a counterfactual. Before the spray, it finds a blend of similar untreated streets whose pollution moved in step with the treated one. After the spray, that blend stands in for the street the truck never visited. The gap between the two is the effect.
We have no real fleet yet, so we tested this the only honest way available: we injected an effect we chose and checked whether the system could find it. We injected an 18.5% drop in PM2.5, and it recovered 18.8%, with a 95% confidence interval of 15.4% to 22.2%. That proves the method finds a known answer. It does not prove that sprinklers cut PM2.5 by 18% in Delhi.
Every verified result goes into an effectiveness library by cause and action (dust and sprinkler, burning and inspection), so the next plan is drafted from what actually worked.
The Impact page: the treated street (solid line) against its counterfactual (dashed line), with the effect and its confidence interval. These interventions are simulated, with injected effects.
5. Citizens as the city's eyes
Citizens can do more than complain. They can photograph burning waste or a dust cloud and send it in. The photo goes straight to secure cloud storage. Within seconds the report is checked automatically: is the location inside Delhi, did the photo really upload, and does the area's pollution pattern match what the citizen reported? It then joins the ward officer's queue with a 3-hour response target, and the reporter is notified as it moves along. A report sent twice from a patchy connection is filed once, and a report only counts as sent once the server has stored it.
Officers can also broadcast alerts by SMS, email and app notification, and schools get a safe window for outdoor activity.
A citizen photo report, from the phone to the ward officer.
Alerts on the live console. The top row is a real broadcast sent through Amazon SNS from the live server; the two rows below it are demo data.
6. One app, five roles, two languages
The field app serves five roles from one codebase. Drivers see the day's route. Inspectors get sites to visit and collect photo evidence. Schools get the safe outdoor window. Citizens see the air near them and can report problems. Site managers see their site's score. Everything works in Hindi and English.
The driver's route in Hindi and English. "Spray is logged automatically": the HawaTag records it, not the driver.
Part three: how it runs on AWS
We added an AWS service only when part of the system needed it, and each one can be switched off without breaking the demo.
How one vehicle reading travels: AWS IoT Core and Amazon Kinesis into the backend on EC2, then to DynamoDB, Redis and the live map.
Service | What it does in HawaCommand | Status |
|---|---|---|
Amazon EC2 (Mumbai) + IAM role | Runs the backend and the officer console; no access keys stored on the server | Live |
Amazon S3 | Stores citizen evidence photos in a private bucket; phones upload to it directly | Live |
Amazon DynamoDB | Citizen reports, and each vehicle's recent track (deleted after 7 days) | Live |
AWS IoT Core + Amazon Kinesis | Carries vehicle telemetry from the trackers to the backend | Built; the vehicles are simulated |
Amazon SNS | Sends alerts by SMS and email | Live |
Redis | Keeps the live map of where every vehicle is | Live |
Amazon Bedrock | Powers AI-agent workflows for report analysis, natural-language queries, and intelligent dispatch assistance. | Live |
AWS Step Functions | Orchestrates multi-step workflows, coordinating AI agents, dispatch operations, and forecasting tasks. | Live |
Amazon SageMaker | Runs forecasting models to predict vehicle demand, movement patterns, and resource requirements. | Live |
Amazon ECS with AWS Fargate | Runs containerized backend workers and AI workflow services without requiring manual server management. | Live |
Running the whole demo costs about $12–18 a week in the Mumbai region. Most of that is the EC2 instance and the Kinesis stream, which bills for every hour it exists, even when idle. Our rough estimate for a one-district pilot is ₹22–24 lakh, about a hundredth of the cost of one smog tower (₹20–22 crore).
What we learned the hard way
Measuring less often almost fined an honest driver. To cut cloud costs, we slowed the simulated trackers from one reading every 5 seconds to one every 10 minutes. The audit rule quietly assumed readings no more than 5 minutes apart, so a truck that sat on site for 20 minutes was credited with only 10, and the system would have recommended a ₹25,000 penalty. Nothing about the truck changed, only how often we measured it. We tied the rule to the same 15-minute window the rest of the system uses, and a test now guards it.
Same truck, same 20 minutes on site. Only the reading rate changed.
"Switched on" is not "working". Our health page reported each AWS service as configured, which only meant its setting existed. We added a check that makes one real call to each service, so we know what works, not just what is switched on.
Some failures must be loud. Most of HawaCommand falls back to a simpler mode when a cloud service is down. Citizen reports do not. A report that silently vanished while the phone said "submitted" would be worse than an error, so the app retries instead.
Our street map lost to a simple baseline. On held-out stations, our 500 m map was less accurate than just copying the nearest station. We kept it because it says how unsure it is, and we do not quote its accuracy as a feature.
What we are not claiming
- HawaCommand has not been used by MCD or DPCC.
- The vehicles, trackers and interventions are simulated. No HawaTag has been built.
- The models are trained on synthetic station history. The forecast beats a "tomorrow equals today" baseline on that data, which shows the pipeline works, not that it predicts real Delhi air.
- The 18.8% is the method recovering an effect we injected, not a measured effect of sprinklers.
- The thresholds (15 minutes, 500 m, ₹25,000) are our choices, not contract terms.
- A "verified" citizen report means automated checks; no AI looks at the photo.
- There is no sign-in yet, and the demo runs over plain HTTP.
Three things we would tell ourselves on day one
- Define proof before you build the feature. "Verified" meant nothing until we decided what evidence would count.
- Rank by people, not by the loudest number. The worst AQI and the worst harm are often in different places.
- When a rule depends on how often you measure, tie the two together. Otherwise a cost-saving change becomes a wrong verdict.
Try it
- Live console: http://ec2-13-207-49-123.ap-south-1.compute.amazonaws.com:3000 (open Map, then Plans, Fleet and Impact)
Built for Environmental Hacks 2026, Air track, part of the WeMakeDevs × AWS Bharat Builds Tour, by team Straw Hat Pirates. AI coding assistants helped with implementation and drafting; the team is responsible for every claim and line of code.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article