Building EcoPulse: AI-Powered Waste Reporting on AWS for Cleaner Cities

Designing an event-driven environmental intelligence platform with Amazon S3, Amazon EventBridge, Amazon SQS, CloudWatch, and multimodal AI.
Gurukant Patil

Published Oct 11, 2026
Last modified Oct 12, 2026
1. The problem: a waste report is only the beginningA citizen sees waste dumped beside a road, takes a photograph, and submits a report. But what happens next?
Someone must review the evidence, determine whether the report needs action, identify the location, track its status, and verify what happened afterward. Without a traceable workflow, a photograph can remain just another complaint in a queue.
This is the gap EcoPulse is designed to address.
EcoPulse is a community-driven environmental reporting platform that combines citizen submissions, AI-assisted waste assessment, geospatial context, community incentives, and municipal follow-up. Its goal is to make environmental incidents easier to report, assess, track, and review.
The challenge is not simply detecting waste in a photograph. It is connecting that assessment to a persistent record and a process that people can trust.
2. Why this matters in IndiaThe scale of India's municipal waste-management challenge makes reliable local reporting particularly relevant.
According to the Ministry of Housing and Urban Affairs, urban areas generated 162,162 tonnes of municipal solid waste per day, of which 131,837 tonnes per day was reported as processed in January 2026. The Ministry also reported that waste processing had increased from 16% in 2014 to 81% in 2026.
In May 2026, the Ministry reported that 65% of 26 crore metric tonnes of legacy waste across 2,482 dumpsites had been remediated. Its review also emphasized source segregation, accountability, and digital monitoring.
Sources:
 Ministry of Housing and Urban Affairs — Achievements and Status of SBM-U, 29 January 2026 
 Ministry of Housing and Urban Affairs — National Review of SBM-U 2.0, 20 May 2026 
These national figures establish the scale of the problem; they do not measure EcoPulse's impact. EcoPulse focuses on a more local question: can a reported environmental incident be documented, assessed, and followed through with greater transparency?
3. The product: from citizen submission to reviewable recordEcoPulse brings together three important parts of the workflow:
Citizen reporting: residents submit photographs and location information about waste accumulation and other environmental concerns.
AI-assisted assessment: the platform presents a visual assessment of waste categories and a descriptive summary.
Operational tracking: reports have statuses that help distinguish submissions awaiting review from reports that are being processed, analyzed, verified, or resolved.
The platform also includes community-oriented features such as EcoPoints and cleanup missions. These are intended to encourage participation, while maintaining a distinction between automated analysis and decisions that require human judgment.
The architectural principle is simple: the app presents the report, the database maintains its state, and AI assists with assessment rather than acting as the final authority.
4. Storing evidence with Amazon S3Photographs are central to environmental reporting. They also introduce practical concerns: file size, access control, storage durability, and the need to associate each image with a report.
EcoPulse uses an Amazon S3 bucket named  ecopulse-evidence-dev , with evidence objects organized under the  reports/evidence/  prefix in the observed AWS Console.
The S3 Console screenshot captured during development showed 28 objects in that prefix. The object listing included files of different sizes, although the inspected object was only 33 bytes. That small object should not be treated as proof of a valid image upload; a full-size image object must be inspected separately.
﻿
Figure 1. The EcoPulse evidence bucket and its  reports/evidence/  object prefix in the AWS Management Console.
For a production-oriented workflow, the backend should issue short-lived presigned upload URLs instead of exposing long-lived AWS credentials to mobile clients. After the upload, the backend should verify that the expected object exists and persist the storage reference against the report.
The intended flow is:
The client requests an upload URL.
The backend authorizes the request and generates a time-limited URL.
The client uploads the file to S3.
The backend verifies the uploaded object.
The evidence reference is saved with the report in PostgreSQL.
The object listing demonstrates that objects exist in S3. It does not, on its own, establish that every step of this sequence has been verified or that the bucket's access and encryption settings have been independently audited.
5. PostgreSQL: keeping reports and AI observations structuredObject storage and relational data serve different purposes. S3 stores the evidence bytes; PostgreSQL stores the records needed to connect that evidence to reports, analysis, and operational status.
EcoPulse uses Neon-hosted PostgreSQL. During development, the database console showed report records with statuses such as  SUBMITTED ,  PROCESSING ,  ANALYZED ,  VERIFIED ,  REVIEW_REQUIRED , and  RESOLVED .
The schema inspection also exposed fields in the  ai_observations  table including:
 event_id 
 model_provider 
 model_name 
 waste_type 
 secondary_waste_types 
 severity 
The  agent_runs  table contains execution records with input and output references, metadata, and error fields.
﻿
Figure 2. Report records in the EcoPulse PostgreSQL database, illustrating the structured status model.
﻿
Figure 3. Schema fields used to represent AI observations, including provider, model, waste type, and severity.
These screenshots demonstrate that the database contains report records and that the inspected schema includes fields for AI observations and agent execution. A further end-to-end query is needed to establish that a particular mobile report, its S3 object, and its AI observation all reference the same underlying record.
That relationship matters. A system becomes easier to debug and audit when every assessment can be traced back to the evidence and report that produced it.
6. AI-assisted waste assessment in the mobile appEcoPulse's mobile report-detail screen shows an assessment for report  ECO-23EE97E .
The screen displays detected categories including garbage bags, plastic packaging, discarded containers, and debris. It also presents a short description of the scene and an AI confidence value of 98%.
﻿
Figure 4. The report-detail interface displays waste categories, a textual assessment, and the confidence value returned or presented by the application.
This interface illustrates how AI can make a citizen report easier to interpret. Rather than requiring every user to describe a scene using a predefined technical vocabulary, the system can present a human-readable summary alongside the report.
However, the displayed confidence value should be interpreted carefully. A screenshot establishes what the application displays; it does not independently establish how that score was calculated, whether it is calibrated, or whether the underlying inference was produced by a particular model.
For that reason, the AI output should be treated as an assessment to support review, not as definitive proof of a hazard or a substitute for field verification.
7. Human review remains part of the workflowAutomated classification and operational decisions are different responsibilities.
An AI model may identify possible waste categories, describe a scene, or estimate severity. It should not automatically be treated as authority to penalize residents, deduct community points, reject a report, or dispatch a contractor.
EcoPulse's intended workflow keeps the assessment separate from the decision:
A citizen submits evidence.
The platform stores the report and its associated references.
AI assists with visual assessment.
The system records the analysis and current status.
A human reviewer can assess the evidence before consequential action is taken.
The report's status can be updated as the incident progresses.
This separation is particularly important in a community incentive system. False detections, duplicate reports, unclear photographs, and changes in the scene can all affect the interpretation of an incident.
The platform should preserve evidence and make uncertainty visible rather than treating every model output as ground truth.
8. The intended event-driven AWS architectureThe broader EcoPulse architecture is designed to separate evidence ingestion from slower downstream processing.
The intended flow is:
Mobile app → Fastify API → Amazon S3 → event publication → Amazon EventBridge → Amazon SQS → processing worker → AI assessment → PostgreSQL
Each component has a distinct responsibility:
Amazon S3 stores evidence files.
Amazon EventBridge routes application events to configured targets.
Amazon SQS buffers processing requests so that ingestion and analysis do not have to happen in the same request.
A dead-letter queue (DLQ) can isolate messages that repeatedly fail processing.
The worker performs downstream processing and invokes the configured AI provider.
PostgreSQL stores report state and analysis records.
Amazon CloudWatch can provide logs, metrics, and operational visibility when configured and connected to the running services.
This architecture can improve resilience because a temporary processing failure does not have to invalidate the original report.
The implementation must still be verified against the deployed environment. Terraform definitions and application code are not equivalent to a live event bus, queue, worker, or monitoring pipeline. A real end-to-end test must establish that an uploaded object generates the expected event, reaches the queue, is processed, and results in a persisted database record.
9. EcoPulse in Action: Product DemoThe following walkthrough demonstrates EcoPulse in action, showing how citizens can report environmental issues and how the platform presents AI-assisted assessments and tracks reports for review.
Watch the demo to see the product workflow and the current state of the implementation.
﻿
10. Reliability and traceabilityAn environmental reporting system should be able to answer more than whether an API returned HTTP 200.
For a given report, it should eventually be possible to answer:
Was the evidence upload completed?
Which object was stored?
Was the processing request published?
Did a worker receive and process the event?
Which AI provider and model were used?
Was the analysis saved?
If processing failed, what happened to the message?
Was the report subsequently reviewed or resolved?
These questions suggest several implementation requirements:
Idempotency. Repeated events should not create duplicate analysis records or award duplicate points.
Bounded retries. Transient failures can be retried, but repeated failures must become visible instead of continuing indefinitely.
Failure isolation. Messages that cannot be processed should be routed to a configured DLQ when the queue policy and consumer behavior support that path.
Correlated logs. Evidence IDs, report IDs, and processing IDs should be carried through the workflow so a single report can be investigated across services.
Explicit status transitions. The user interface should distinguish a report that has been submitted from one whose analysis has completed or whose cleanup has been verified.
These are design and verification goals. They should be described as confirmed behavior only after the corresponding tests have been run.
11. What the current evidence establishesThe development screenshots provide a useful snapshot of the system:
The AWS Console shows an S3 evidence bucket and its object listing.
The mobile application displays a waste report and an AI-assisted assessment.
The PostgreSQL console shows report records, operational statuses, and agent-run records.
The inspected schema includes fields intended to store AI observation metadata.
The evidence does not yet establish a complete trace from the exact mobile report through S3, EventBridge, SQS, the worker, the model provider, and the final PostgreSQL record. Nor does it establish that every infrastructure component is deployed or that all failure paths have been tested.
The next verification milestone is to select one report and trace it end to end. That test should record the report identifier, confirm the actual S3 object and its size, identify the provider and model used for inference, retrieve the persisted observation, and inspect the corresponding processing logs.
A second test should deliberately trigger a safe processing failure and verify the actual retry and dead-letter behavior.
This approach separates three levels of confidence:
Code-level evidence: the implementation and configuration exist.
Integration evidence: automated or local tests exercise the relevant components together.
Live AWS evidence: the deployed services execute the workflow successfully in the target environment.
Keeping those levels separate makes the results easier for another engineer to reproduce.
12. What comes nextThe next phase of EcoPulse is not simply adding more services. It is improving the quality of the evidence and the reliability of the workflow.
The priorities are:
Verify real image uploads and object metadata in S3.
Trace a single report through persisted database records.
Verify the actual inference provider and model used.
Test event delivery, retries, and dead-letter handling.
Correlate CloudWatch logs and metrics with real processing requests.
Evaluate the human-review process and measure operational outcomes during a pilot.
Only after a real pilot should EcoPulse make claims about faster cleanup, improved civic participation, reduced dumping, or environmental impact. Those outcomes require measurements rather than architecture diagrams or screenshots alone.
ConclusionEcoPulse began with a practical question: how can a citizen's observation of waste become something a municipal team can assess and act upon?
The platform brings together citizen reporting, evidence storage, AI-assisted assessment, structured records, and operational tracking. The development evidence shows important pieces of that foundation, while the next engineering step is to verify the complete workflow and its failure behavior in the deployed environment.
The broader lesson is that AI for civic infrastructure should not stop at producing a prediction. It should preserve the evidence, make the result traceable, expose uncertainty, and support accountable human decisions.
That is the direction EcoPulse is working toward: not just detecting possible waste, but building a workflow in which reports can be tracked, reviewed, and ultimately connected to verified action.
Project Resources
Explore EcoPulse and its implementation:
Application:  Open EcoPulse 
Video walkthrough:  Watch the EcoPulse demo 
Source code:  Explore the GitHub repository 
ReferencesMinistry of Housing and Urban Affairs, Government of India.  Achievements and Status of SBM-U — 29 January 2026 .
Ministry of Housing and Urban Affairs, Government of India.  National Review Meeting for Swachh Bharat Mission-Urban 2.0 — 20 May 2026 .