A Complaint Was Marked Resolved. The Dust Was Still There.
How our team built AirWatch, a Mumbai construction-dust accountability platform, and tackled the gap between filing a complaint and verifying its outcome. A practical look at public evidence, reporter permissions, simulated monitoring, and designing a cost-conscious AWS architecture.
A construction-dust complaint can have a perfectly organized timeline and still leave one basic question unanswered: is the dust actually gone?
That question became one of the most interesting problems we faced while building AirWatch for the WeMakeDevs × AWS Environmental Hacks hackathon.
We started with an interactive map of construction projects in Mumbai. We had simulated particulate-matter monitoring, a complaint form, and a municipal review dashboard.
But as the citizen workflow grew, I noticed a problem: if someone in our case desk marked a complaint as resolved, the public interface could make it look like the real-world problem had been fixed.
Those are two different things.
A software record can be closed. Dust can still be blowing across the road.
That distinction changed how we thought about the product.
1. The problem isn't just filing a complaint
Mumbai already has official channels for reporting civic and air-pollution problems. Building another form wasn't enough reason for someone to use AirWatch.
We wanted to address a more specific situation.
Imagine a resident walking past a construction project and noticing fine dust spreading toward a bus stop.
They might have a photograph and know the street name. But they may not know the project details, which municipal ward handles the area, or how to keep track of what happened after reporting it.
And even after receiving a response, they might still see the same problem the following day.
We wanted to connect three things:
- Where: Identify the construction project and relevant BMC ward office.
- What: Preserve the resident's dust complaint and supporting evidence.
- What happened next: Let people document official responses and independently observe whether conditions changed.
The final part is where we spent a lot of our attention.
2. What we built: AirWatch
AirWatch on GitHub is a public, map-first construction-dust reporting and accountability application.
Our initial Mumbai pilot covers four administrative wards: K/East, H/East, L, and S.
The project catalog includes 27 records collected from public sources such as MahaRERA and government infrastructure agencies. Each record includes supporting source information. Some registration records do not independently confirm that construction is currently active, so we preserve that distinction.
Residents can use the map to find projects, submit construction-dust reports with photos and locations, and view moderated public complaints.
The system also provides an internal municipal-style case desk for reviewing reports, assigning work, recording findings and maintaining a timeline.
But AirWatch is not an official BMC service. Internal case-desk activity must never be confused with an actual government acknowledgment or enforcement action.
That requirement influenced the engineering decisions that followed.
3. My part: separating public accountability from private ownership
I worked on the public map's ward information and on the distinction between what any citizen can view and what the original reporter is allowed to manage.
Our first approach exposed much of the same complaint experience to everyone.
It looked transparent, but it introduced a serious question:
If everybody can see a complaint, should everybody be able to change it?
Of course not.
We needed to distinguish three users:
The reporter: Can manage their own submission, add their official complaint reference and provide further evidence.
Another resident: Can read the moderated public record and contribute a separate observation, without editing the original reporter's evidence or reference number.
A reviewer: Can moderate contributions and update the internal AirWatch review process, subject to role-based permissions.
Hiding buttons in React was not enough. The API also had to enforce who owned each submission and which actions a user could take.
Our Express backend uses authenticated, role-protected routes, with the reporting and follow-up logic separated from public read endpoints.
The accountability tests exercise ownership checks, moderated submissions and the protection of private reporter information.
This was an important lesson for me: public transparency is not the same thing as public write access.
4. The accountability loop that doesn't need government adoption
We made another deliberate decision: AirWatch should remain useful even if BMC never logs into our application.
Here is the workflow we designed:
Step 1 — Find and report
A resident chooses a construction project or location and submits a dust complaint, optionally with a photograph.
Step 2 — Prepare an official complaint
AirWatch helps organize the location, description and evidence so the resident can use the relevant official reporting channel.
Step 3 — Record the acknowledgment
If the resident receives an official reference number or reply, they can add it to their case. This is initially citizen-provided evidence, not automatically a verified BMC response.
Step 4 — Return to the location
The resident can add a new observation: dust still present, improvement observed, or additional follow-up evidence.
Step 5 — Build a public evidence history
Moderated updates appear on the public record, while reporter contact details and private information remain protected.
Most importantly, an AirWatch case being marked "Resolved" does not automatically mean an official BMC complaint was resolved or that the site conditions improved.
We keep internal case reviews, official-channel evidence and on-site citizen observations distinct.
That is how we can support accountability without falsely claiming a government integration.
5. Our monitoring system: useful, but deliberately limited
AirWatch also includes simulated construction-site monitoring.
Our system generates demo PM2.5 and PM10 readings and routes them through an existing ingestion and monitoring pipeline.
A FastAPI service contains a Random Forest model that estimates the expected PM10 difference between a construction-site reading and its paired background reading. An adaptive margin helps flag unexpectedly high differences.
We treat those flags as prompts for review.
They do not establish which activity caused pollution, prove that a sensor was manipulated, or determine whether a site violated a regulation.
There is another limitation worth stating clearly: the model was trained using synthetic Delhi data and has not been validated against real Mumbai construction-site instruments.
We therefore label simulated devices and readings in the interface instead of presenting them as a real monitoring network.
In an environmental application, the distinction between demonstration data and measured reality is part of the product's trustworthiness.
6. Designing the AWS architecture around the existing application
Our team already had a working application stack:
Layer | Technology |
|---|---|
Citizen interface | React, Vite, Leaflet |
Application API | Node.js, Express |
Database | PostgreSQL, Prisma |
PM10 assessment | Python, FastAPI, scikit-learn |
Monitoring | Simulated device ingestion and background pairing |
Case management | Role-based municipal workflow and audit events |
We didn't want to rewrite everything into serverless functions just to mention more AWS services.
Instead, the team prepared an AWS architecture using AWS CDK, defining the infrastructure alongside our application code.
The planned responsibilities are:
- AWS Amplify Hosting: Host the React frontend.
- Amazon Lightsail: Run the containerized Express API, FastAPI service, monitoring worker and PostgreSQL database.
- Amazon S3: Store complaint evidence and backups with controlled access.
- Amazon CloudWatch: Collect operational logs and monitor health.
- Amazon SNS: Deliver configured infrastructure alarm notifications.
- AWS Budgets: Track spending and support cost alerts.
The architecture is intentionally modest. For a small pilot, we wanted understandable operations and predictable costs rather than a large set of independently managed cloud services.
AWS CDK also gave us a way to treat infrastructure configuration as testable source code.
Our repository includes CDK stack definitions, infrastructure tests, deployment scripts, and a production-like Docker Compose setup.
What was actually tested?
At the time of preparing this article, the repository documentation reports local production-stack checks and 33 smoke checks, using an S3 stand-in.
That is not the same as verified deployment in an AWS account.
I don't want to describe a cloud deployment as successful until the deployed endpoints, services and end-to-end workflow have been checked.
For now, the supported result is an AWS architecture prepared in code, with local deployment testing. Live AWS operation remains a separate verification step.
This is also why we haven't attached a production uptime or monthly-billing figure to the project.
7. What fought back during development
A public complaint isn't a public account
Our map needs public evidence so residents can understand what is happening nearby. But the reporting system also contains identities, photos and potentially sensitive details.
We had to separate public visibility from permission to modify a report, and protect those boundaries in the backend.
An internal status isn't an official outcome
This was probably the most important product lesson.
A municipal-style review dashboard is useful for demonstrating how officials or NGO reviewers could work with the system.
But unless an agency actually uses it, those actions remain AirWatch review actions.
We introduced separate evidence paths so an internal closure doesn't erase a resident's later observation that the problem persists.
A valid project registration isn't proof of active work today
A government-sourced project record is valuable, but dates and statuses can lag behind what is actually happening on the ground.
Our records therefore need source URLs, verification dates and careful status descriptions.
We shouldn't turn a registration detail into a stronger claim than the evidence supports.
The ML model isn't portable just because its API works
Our model service can be integrated into an application, but that doesn't prove it is accurate for new locations and instruments.
Its synthetic training history and feature requirements remain important limitations.
The saved model artifact is distributed separately from Git, and its Python/scikit-learn version requirements also matter for reproducible serving.
This is a reminder that packaging a model and validating a model are different jobs.
Cloud infrastructure needs tests too
Writing an AWS diagram is straightforward. Making a repeatable deployment is harder.
The team had to account for configuration, persistence, HTTPS, secrets, model artifact loading, logging and the differences between local substitutes and actual cloud services.
Preparing CDK definitions and local smoke checks helped expose those dependencies before an AWS account deployment.
A diagram alone wouldn't have revealed them.
8. What I'd measure in a real Mumbai pilot
We are not claiming that AirWatch has already improved official complaint resolution rates.
That requires actual resident participation, official acknowledgment evidence, and follow-up observations.
The questions I would test first are:
- Can residents correctly identify the site and ward for a dust complaint?
- Do they successfully file through an official channel?
- Can we preserve a trustworthy acknowledgment and follow-up history?
- Can a resident challenge an unsupported closure?
- Do local NGOs or resident groups find these records useful enough to return?
- Can we independently document whether conditions improved?
I'd rather test those questions in a few wards than claim citywide impact from simulated sensor readings.
9. What this project taught me
The surprising part of building AirWatch was that making a map wasn't the difficult conceptual problem.
The harder problem was deciding what the application was allowed to claim.
Who can edit a complaint? What counts as verified evidence? Who actually acknowledged it? Can another resident disagree with the outcome? How do we distinguish a software demonstration from physical measurements?
Those decisions affect API permissions, database records, moderation, interface copy and infrastructure.
They can't be solved with a better-looking dashboard alone.
And that's what I take away from this build: a good civic application should make it easier to act, but it should also make it harder to mistake an unverified claim for a verified outcome.
AirWatch is still a pilot. But its direction is clear: help people move from seeing construction dust to creating a reliable, followable record of what happened next.
Hackathon: WeMakeDevs × AWS Environmental Hacks 2026 — Air Track
AWS tooling: AWS CDK, AWS CLI; planned Amplify Hosting, Lightsail, S3, CloudWatch, SNS and AWS Budgets.
Author: Rajat Srivastav, AirWatch team
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article