Nigrani — AI-Powered Pollution Complaint Verification and Routing
Nigrani is an AI-powered platform designed to make pollution complaints in Delhi-NCR more accountable. It helps verify citizen-submitted photographic evidence, identify potential violations based on AQI and GRAP rules, route complaints to the appropriate civic agency, identify nearby schools and hospitals that may be exposed to pollution, and verify whether reported issues have actually been resolved.
From Pollution Complaints to Verified Action: Building Nigrani with AWS Strands Agents
What if reporting pollution were only the beginning—and AI could help verify the evidence, identify the responsible agency, and check whether the problem was actually resolved?
Every winter, air pollution becomes an urgent concern across Delhi-NCR. Citizens see construction dust, open waste burning, and other potential violations. They take photographs, report problems, and hope something changes.
But reporting an incident and resolving it are two different things.
A complaint can be routed to the wrong department. Multiple citizens can report the same incident. A photograph may not provide enough evidence to establish what happened. And when an authority marks a complaint as resolved, how do we know the underlying problem has actually disappeared?
These questions inspired Nigrani, an AI-powered pollution complaint verification, routing, and auditing prototype built for the WeMakeDevs × AWS Environmental Hacks.
Our goal was simple: build a system that helps transform pollution reports into structured, evidence-backed incidents that are easier to prioritize, route, and verify.
1. The problem: A complaint needs more than a submission button
A conventional complaint workflow generally starts when a citizen submits a description, photograph, and location.
However, an actionable complaint needs answers to several additional questions:
- Evidence: Does the photograph contain useful location or timestamp metadata? Is additional verification needed?
- Classification: What kind of pollution incident does the evidence suggest?
- Regulatory context: Does the reported activity potentially violate the applicable pollution-control restrictions?
- Jurisdiction: Which civic agency is responsible for the reported location?
- Public exposure: Could wind conditions carry pollution toward a nearby school or hospital?
- Resolution: Does the evidence submitted after intervention actually demonstrate that the problem has been fixed?
Nigrani approaches this as a verification and accountability problem rather than simply another reporting interface.
It is designed to complement existing complaint channels, not replace official reporting systems or act as an authority on regulatory enforcement.
2. Why I chose AWS Strands Agents
One of the most interesting engineering decisions in Nigrani was using the AWS Strands Agents SDK, an open-source framework for building AI agents.
An ordinary AI-powered application might send a prompt to a model and display the response. But a complaint-verification workflow needs more than a single generated answer. It must combine evidence, contextual data, deterministic rules, and a structured incident record.
Strands Agents gives developers a framework for building model-driven workflows that can interact with tools.
In Nigrani, the complaint agent is designed to inspect submitted photographic evidence and support incident classification and verification. Its workflow connects AI reasoning with application tools that provide relevant context.
The important architectural principle is that the model should not have to invent every answer itself.
For example, deciding which agency covers a location is better handled by an explicit jurisdiction lookup than by asking a language model to guess. Similarly, calculating exposure using wind direction and distance should rely on application logic and input data.
My key takeaway: AI should interpret uncertain evidence, while deterministic code should handle rules that can be calculated or checked directly.
3. Inside the Nigrani architecture
Nigrani combines a Python backend, a Strands-based complaint agent, deterministic verification logic, external environmental data, and configurable storage.
Here is the conceptual flow:
Citizen report → Evidence checks → AI-assisted classification → Contextual analysis → Incident storage → Verification and audit
Step 1: Collect and inspect the evidence
A report contains a photograph, GPS coordinates, and a short description.
Before relying on AI, Nigrani checks available image metadata, including GPS and timestamp information. These checks can flag inconsistencies or missing metadata for further review.
Metadata alone cannot prove that an image is genuine or current. It is one source of evidence, not a guarantee of authenticity.
Step 2: Classify the incident
When a supported model provider is configured, the Strands-based agent can analyze the submitted image and produce a structured assessment, including a likely incident category, confidence, priority, and contextual summary.
If the model is unavailable, Nigrani can return an explicit manual-classification status rather than fabricate a verdict.
This fallback matters because an environmental monitoring tool should communicate uncertainty instead of silently treating an unverified complaint as confirmed.
Step 3: Apply contextual rules
Nigrani uses application logic to enrich the report:
- GRAP evaluation: Compares the incident category against encoded restrictions and the configured regional AQI/GRAP context.
- Jurisdiction mapping: Uses a curated locality dataset to identify a candidate responsible agency.
- Exposure scoring: Uses wind information and nearby school or hospital locations to estimate which sensitive sites may be downwind.
- Duplicate detection: Identifies potentially overlapping open complaints so repeated reports can be consolidated.
These functions do not all require an LLM. Keeping them in deterministic Python logic makes their assumptions easier to inspect, test, and improve.
The current locality model is a prototype, and its jurisdiction and GRAP rules should not be mistaken for an authoritative government enforcement system.
Step 4: Store and track the incident
Nigrani includes configurable storage adapters:
- Amazon S3 for complaint photographs.
- Amazon DynamoDB for structured incident records.
- Local disk and JSON-based fallbacks for development when the corresponding cloud configuration is absent.
This design lets the application be developed and tested without requiring a live AWS resource for every feature.
Step 5: Verify the claimed resolution
The most important part of the workflow happens after a complaint is submitted.
When an officer provides an after-photo, Nigrani is designed to compare it with the original evidence. If verification confirms that the same location is represented and the reported issue is gone, the incident can be marked resolved. If the issue remains, it can be reopened. Ambiguous evidence can require further review.
This creates a more meaningful distinction between a complaint being marked resolved and a complaint being supported by evidence of resolution.
The agent assists with that decision; it does not replace human oversight.
4. Where AWS fits into the solution
AWS is part of the project's AI-agent and cloud-integration architecture.
AWS Strands Agents SDK — the open-source foundation
Strands provides the agent framework used for the complaint-verification workflow. It helps connect model-driven reasoning with tools that retrieve contextual data and execute application logic.
Its value in this project is not merely generating text. It provides a structure for an AI workflow that must interact with evidence and application capabilities.
Amazon Bedrock — managed foundation models
Nigrani supports Amazon Bedrock as a model-provider option for image-based complaint analysis.
With the appropriate model access, AWS credentials, region, and model configuration, the agent can use a compatible model through Bedrock.
This creates a path toward managed model inference without requiring the application to manage the underlying model infrastructure itself.
Amazon S3 — evidence storage
Photographs are important to the complaint lifecycle because the original report and subsequent resolution evidence need to be associated with an incident.
Nigrani includes an S3-backed photo-storage adapter. When a bucket and credentials are configured, the application can use S3; otherwise, its development fallback stores photographs locally.
Amazon DynamoDB — structured incident storage
Incident records contain information such as category, location, status, priority, verification details, and resolution state.
Nigrani includes a DynamoDB-backed storage adapter for these records, with a JSON-file fallback when cloud storage is not configured.
The same application architecture can therefore support local testing and a cloud-backed deployment without making every developer dependent on a live AWS account.
Implementation note: Bedrock, S3, and DynamoDB are configurable integrations. Their presence in the code does not by itself establish that all three are active in the currently deployed demo. Actual cloud use depends on the relevant credentials, configuration, and deployment.
5. Designing for failure instead of pretending it will not happen
A useful lesson from building Nigrani was that AI systems need explicit failure paths.
What happens if a model provider is unavailable? What if a photograph has no GPS metadata? What if a complaint is ambiguous? What if an officer's after-photo does not establish that the problem has been resolved?
These are not unusual edge cases. They are normal conditions in systems that deal with imperfect real-world evidence.
Nigrani addresses these situations through several design choices:
Graceful degradation: The core workflow can operate without every optional AWS integration. AI-dependent classification can fall back to manual review, and storage can fall back to local files.
Deterministic checks: Metadata checks, jurisdiction lookup, rule evaluation, and duplicate detection reduce the need to ask a model to make every decision.
Explicit uncertainty: An unavailable model should produce an unavailable or manual-review status, not a fabricated classification.
Testable logic: The repository includes tests for geometry, evidence metadata calculations, duplicate clustering, and fallback behavior.
These choices do not make the prototype production-ready, but they provide a more responsible foundation for further development.
6. What I would improve before production
Nigrani is a prototype, and I would not present it as a fully deployed government-grade enforcement platform.
There are several areas I would address next:
- Authoritative geographic data: Replace the curated locality model with verified, maintained civic jurisdiction boundaries.
- Better evidence evaluation: Test image verification against a labeled dataset containing genuine incidents, ambiguous photographs, and misleading submissions.
- Security and privacy: Add appropriate authentication, authorization, retention policies, and secure access to sensitive location and photographic data.
- Cloud deployment: Configure and validate the AWS integrations in a dedicated environment, with least-privilege IAM permissions and appropriate logging.
- Operational reliability: Add monitoring, failure alerts, retry handling, and evaluation of model accuracy and latency.
- Human oversight: Require accountable human review for consequential decisions, disputed evidence, and official enforcement actions.
I would also evaluate the system on measurable outcomes, including classification accuracy, duplicate-detection precision, incorrect agency assignments, verification error rates, and processing latency.
These measurements would help determine whether the system actually improves complaint handling rather than merely automating more steps.
7. What building Nigrani taught me
Building Nigrani changed how I think about practical AI applications.
The most valuable use of an agent is not necessarily to make the entire system autonomous. It is to handle ambiguous tasks while relying on deterministic tools for facts that can be checked and rules that can be tested.
I also learned that fallbacks are a core part of the architecture. A workflow that clearly communicates uncertainty is more useful than one that produces a confident answer regardless of whether its dependencies are available.
Finally, cloud integration should solve a concrete engineering problem. S3 and DynamoDB serve distinct storage needs, while Bedrock provides a managed model-inference path. Strands Agents connects these capabilities to an application workflow.
For environmental monitoring, that combination offers a promising direction: systems that help people organize evidence, prioritize incidents, and verify outcomes without pretending that AI alone can establish the truth.
Conclusion: From reports to accountability
Pollution is a complex public problem, and software cannot solve it by itself. But better evidence handling and complaint verification can help make the response process more transparent.
Nigrani explores how AWS Strands Agents, configurable Amazon Bedrock integration, S3-backed evidence storage, DynamoDB-backed incident records, and deterministic Python logic can work together toward that goal.
The principle behind the project is straightforward:
A complaint should not be considered the end of the process. It should be the beginning of a verifiable path toward action.
I built Nigrani as a prototype, and there is still significant work to do before it could be used for official decisions. My next step is to strengthen its data quality, evaluate its verification accuracy, and validate the AWS-backed workflow under realistic conditions.
I'd love to hear from other builders: How would you design an AI-agent system that must make decisions from imperfect real-world evidence while remaining transparent, testable, and accountable?
Explore the project
- Live demo: https://nigrani-jet.vercel.app/#/
- Source code: https://github.com/aryank2212/nigrani
- Strands Agents: https://github.com/strands-agents/sdk-python
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article