Building AirTrace (BreatheWise): How I Used AWS and AI to Make Campus Air Quality Smarter
Turning air pollution data into actionable intelligence with Next.js, Node.js, Amazon Bedrock, and AWS Amplify.
Introduction: More Than Just an AQI Dashboard
Air pollution is one of the biggest environmental challenges we face today. We regularly check the Air Quality Index (AQI), especially during periods of severe pollution, but simply knowing the AQI number does not always help us decide what to do next.
Should a college postpone an outdoor sports session? Is there a less polluted route to campus? Would conducting an assembly at a different time reduce students' exposure to poor air quality?
These questions inspired me to build AirTrace (BreatheWise), an AI-powered air-quality intelligence platform designed initially for colleges and universities, with the long-term vision of making it useful for everyone.
Instead of displaying pollution numbers alone, AirTrace aims to turn environmental data into practical recommendations that help students, faculty, and campus administrators make more informed decisions.
Building this project was also a valuable learning experience. I encountered several technical challenges involving AI integration, environmental data processing, system reliability, and cloud deployment. Solving these problems pushed me to apply my knowledge of web development, backend engineering, data processing, and AWS services.
1. The Idea Behind AirTrace
Traditional air-quality applications often focus on displaying AQI readings for a particular city or monitoring station. While this information is useful, it does not necessarily answer the specific questions faced by a college campus.
Different areas of a campus can experience different environmental conditions. A road near heavy traffic may have different pollution levels from a green area within the same institution. Similarly, outdoor activities can be affected by both pollution intensity and the time spent outside.
I wanted to explore how an intelligent system could bridge this gap.
AirTrace focuses on three major goals:
- Understand: Interpret air-quality readings and identify the pollutants contributing to poor conditions.
- Compare: Evaluate alternative commuting routes and potential time slots for outdoor activities.
- Act: Convert environmental information into clear, contextual recommendations.
The initial target audience is colleges and universities. However, the underlying concept can eventually be extended to schools, workplaces, residential communities, and individuals.
2. What Does AirTrace Actually Do?
AirTrace combines environmental data, mathematical analysis, and generative AI to support pollution-aware decision-making.
A. Campus Air-Quality Intelligence
The platform is designed to help college administrators understand environmental conditions across different campus zones.
For example, a university could use AirTrace to evaluate outdoor sports areas, academic courtyards, and campus roads before scheduling activities.
The decision engine can compare available air-quality readings against relevant Indian National Air Quality Index (NAQI) categories and applicable guidance to help classify activities as approved, restricted, or requiring modification.
The intention is to support better decisions rather than rely on a single city-wide AQI value.
B. Clean Commute Route Optimization
AirTrace explores how route selection can account for pollution exposure alongside travel time.
Instead of comparing routes solely by distance, the platform can analyze available route information and corresponding air-quality data to estimate relative exposure.
For example, a longer route might be worth considering if its estimated pollution exposure is meaningfully lower and the additional travel time is acceptable.
The system uses routing information and exposure calculations to make this comparison understandable.
These estimates depend on the quality and spatial resolution of the available environmental data. They are intended for comparative awareness, not as precise measurements of the pollution actually inhaled by an individual.
C. AI-Powered Air Intelligence Assistant
Another important component is the conversational AI assistant.
Users can ask questions about air-quality conditions, outdoor activities, commuting, and campus operations in natural language.
Rather than generating generic responses, the assistant is designed to receive relevant environmental readings and applicable policy information as context.
This helps connect the AI's responses to the available data instead of treating the language model as the source of environmental measurements.
D. Indian NAQI Calculation
AirTrace also incorporates a rule-based approach to calculating air-quality indices from supported pollutant concentrations.
The implementation is designed around the eight pollutants covered by India's National AQI framework:
- PM2.5
- PM10
- Nitrogen dioxide (NO₂)
- Sulphur dioxide (SO₂)
- Carbon monoxide (CO)
- Ozone (O₃)
- Ammonia (NH₃)
- Lead (Pb)
The calculation engine uses pollutant-specific breakpoints and sub-indices, with the overall AQI determined by the highest applicable sub-index when the required data and averaging periods are available.
This deterministic calculation layer is important because regulatory calculations should not depend on an AI model improvising numerical results.
3. Why I Chose AWS for AirTrace
One of the most important technical decisions was integrating AWS into the project.
I wanted to combine modern AI capabilities with a practical web application architecture. Amazon Bedrock provided a way to access foundation models through a managed service, while AWS Amplify offered a deployment path for the frontend.
Amazon Bedrock and Amazon Nova Lite
I integrated Amazon Bedrock into the backend architecture to power the Air Intelligence Assistant using the Amazon Nova Lite foundation model.
The backend uses the AWS SDK for JavaScript v3 and the Bedrock Runtime Converse API to send structured conversational requests to the model.
The general workflow is:
- The user submits a question through the frontend.
- The backend retrieves the relevant environmental data available to the application.
- The backend constructs a context-aware prompt containing the readings and relevant guidance.
- Amazon Bedrock processes the request and generates a contextual response.
- The backend returns the response to the frontend.
An important architectural principle here is that AWS Bedrock generates explanations and recommendations; it does not replace the environmental data sources or the deterministic AQI calculation engine.
This separation makes the system easier to reason about and helps reduce the risk of unsupported AI-generated claims.
AWS Amplify for Frontend Hosting
I chose AWS Amplify Hosting for the Next.js frontend.
The project uses a monorepo structure, with the frontend and backend maintained in separate directories. This creates an additional deployment consideration because the frontend build system must understand the repository structure correctly.
Amplify provides a Git-based deployment workflow that can build the frontend when changes are pushed to the connected repository.
For the frontend to communicate with the backend, the application uses a configurable API endpoint through an environment variable such as
NEXT_PUBLIC_API_URL .This keeps the frontend independent of a hardcoded development URL and makes it easier to switch between local and production environments.
AWS IAM for Access Control
Access to Amazon Bedrock must be controlled through AWS permissions.
The backend requires permission to invoke the selected model in the configured AWS Region. IAM policies can restrict those permissions to the resources and operations the application actually needs.
This is particularly important because AWS credentials should never be exposed in frontend code or committed to a public repository.
4. The Technical Challenges I Encountered
Building AirTrace was not simply about writing features. Several challenges required me to think about system architecture, data correctness, reliability, and deployment.
Challenge 1: Preventing AI Hallucinations
One of the first challenges with a project like AirTrace is that generative AI can produce confident-sounding answers that are not supported by the underlying data.
For an environmental intelligence application, this is a serious concern. An AI assistant should not invent current pollution readings, regulatory thresholds, or claims about the safety of an outdoor activity.
How I approached the problem:
I designed the backend to provide the model with relevant environmental readings and policy context before generating a response.
The application separates deterministic calculations from natural-language explanations. AQI calculations are handled by application code, while the model is used to interpret available information and communicate it in a useful format.
I also designed the prompts to constrain the assistant's role and encourage it to acknowledge missing or outdated data.
This approach does not guarantee zero hallucinations, but it reduces reliance on unsupported model-generated facts and creates a clearer boundary between measured data and AI interpretation.
Challenge 2: Handling Unavailable or Incomplete Environmental Data
Environmental data comes from external providers, and external dependencies can fail.
An API might return incomplete readings, a pollutant value might be missing, or a provider might temporarily become unavailable.
If the application simply crashes whenever an upstream service fails, users lose access to its essential functionality.
How I approached the problem:
I used a layered approach to reliability.
The AQI calculation and decision logic are designed to operate independently of the generative AI layer wherever possible. This means the application can still perform supported rule-based calculations when the AI service is unavailable.
The system also needs to distinguish between missing data, stale readings, and valid current readings. If the information needed for a reliable calculation is unavailable, the application should communicate that limitation rather than manufacture a result.
This taught me an important engineering lesson: a dependable AI application should not make every essential feature dependent on an AI API call.
Challenge 3: Building a Reliable Air-Quality Calculation Engine
Another challenge was translating environmental standards into executable application logic.
AQI calculations are not equivalent to simply averaging all pollutant concentrations. Different pollutants have their own concentration breakpoints, averaging requirements, and sub-index calculations.
A small implementation mistake could produce a misleading result even if the user interface looked correct.
How I approached the problem:
I treated AQI calculation as a deterministic backend responsibility.
The implementation follows pollutant-specific calculation rules and derives the overall index from the applicable sub-indices. I also structured the logic so it could be tested independently of the frontend and the AI assistant.
This makes it easier to test edge cases, verify calculations, and update the implementation when requirements change.
The broader lesson was to use the right tool for each problem: mathematical and regulatory calculations belong in tested code, while generative AI is better suited to explanation and conversational interaction.
Challenge 4: Deploying a Next.js Monorepo on AWS Amplify
The project maintains the frontend and backend in a single Git repository.
Although this simplifies collaboration and version control, it introduces deployment complexity. The frontend build process must use the correct working directory, install the right dependencies, and receive the correct environment variables.
The backend also needs its own runtime, configuration, and deployment target.
How I approached the problem:
I organized the deployment process around the repository's separate application directories.
For the frontend, the important configuration points include:
- Setting the correct monorepo root directory.
- Configuring the build and artifact paths.
- Supplying the production API URL through Amplify environment variables.
- Verifying that the generated frontend can communicate with the deployed backend.
For the backend, the corresponding requirements include configuring its build and start commands, database connection, authentication settings, and AWS permissions.
I also recognized that hosting a Next.js application requires checking which rendering and runtime features the chosen Amplify deployment configuration supports. Not every Next.js feature should be assumed to work without verifying the supported deployment mode.
This experience reinforced the importance of understanding how local development differs from a production cloud environment.
Challenge 5: Managing Secrets and Cloud Permissions
Integrating a managed AI service introduces security responsibilities.
The application needs credentials or an AWS execution identity to access Bedrock. At the same time, the frontend must not expose privileged AWS credentials.
How I approached the problem:
I placed AI requests behind the backend API rather than calling Bedrock directly from browser code.
This keeps the model invocation logic and privileged configuration on the server side. IAM permissions can then be restricted to the required model invocation operations.
Database credentials, authentication secrets, and other sensitive settings are also handled as server-side environment variables.
For a production deployment, these controls should be complemented by request validation, rate limiting, appropriate CORS policies, secure session configuration, and monitoring.
This helped me understand that building a cloud-powered application involves more than connecting services; it also requires controlling how those services are accessed.
5. How My Coding Knowledge Helped Me Solve These Problems
AWS provided managed infrastructure and AI capabilities, but the application still required careful engineering.
My knowledge of JavaScript, TypeScript, Next.js, Node.js, and backend development helped me connect the different components into a single system.
Frontend development: I used Next.js and React to structure the user-facing application and build interfaces for environmental information, route comparisons, and AI interactions.
Backend engineering: Node.js, Express, and TypeScript provided the API layer responsible for processing requests, coordinating external services, applying business logic, and communicating with Amazon Bedrock.
Data processing: I approached AQI calculations and exposure comparisons as explicit computational problems rather than leaving numerical decisions to the language model.
Debugging and testing: I used the separation between individual modules to identify whether a problem originated in data retrieval, application logic, AI integration, or deployment configuration.
Cloud integration: The AWS SDK allowed the backend to communicate with Bedrock programmatically, while Amplify provided the frontend deployment workflow.
The biggest lesson was that a cloud service cannot compensate for poorly designed application logic. AWS becomes much more useful when its capabilities are integrated into a system with clear responsibilities, validation, and error handling.
6. The Architecture Behind AirTrace
At a high level, the system follows this flow:
User Interface → Backend API → Environmental Data and Calculation Engines → AI Service When Needed → Response
The frontend is built with Next.js and deployed through AWS Amplify Hosting.
The Node.js and Express backend handles API requests, environmental processing, and communication with AWS services.
External air-quality and routing providers supply the information needed for environmental analysis and route comparison. The deterministic calculation layer processes the available readings, while Amazon Bedrock generates contextual explanations.
PostgreSQL and Prisma support the application's database layer, including the data required for authentication and persistent application functionality.
This architecture is intended to keep the system modular. Each component has a defined role, making it easier to test, debug, and expand the application as new requirements emerge.
7. What I Learned From Building AirTrace
This project taught me several lessons that go beyond a particular framework or cloud provider.
First, AI needs reliable context. A model is more useful when it receives relevant data and clear instructions rather than being asked to answer questions without sufficient evidence.
Second, deterministic logic still matters. Calculations involving environmental standards should be handled by tested code, not improvised by a generative model.
Third, graceful degradation is an architectural decision. Separating the AI layer from essential calculations helps maintain useful functionality when an external dependency fails.
Fourth, deployment is part of development. Environment variables, monorepo configuration, runtime compatibility, network access, and permissions can all affect whether an application works outside a local machine.
Finally, building a useful product requires thinking beyond the code. The goal is not to add AI simply because it is available. The goal is to solve a real problem in a way that users can understand and trust.
8. What's Next for AirTrace?
AirTrace is initially focused on colleges and universities, but the broader vision is to make pollution-aware decision-making accessible to more people.
Potential future developments include:
- More detailed campus-level environmental monitoring.
- Improved route exposure estimates using higher-resolution data.
- Alerts for significant changes in air quality.
- Better institutional dashboards and activity-planning workflows.
- Expanded coverage for schools, workplaces, and residential communities.
- More extensive validation of the decision engine against official environmental guidance.
- Production monitoring, performance optimization, and stronger data-quality checks.
These developments would help move AirTrace from a campus-focused application toward a broader environmental intelligence platform.
Conclusion
Building AirTrace (BreatheWise) has been an opportunity to bring together web development, backend engineering, environmental data processing, generative AI, and cloud deployment.
Integrating Amazon Bedrock helped me explore how AI can make complex environmental information easier to understand. AWS Amplify provided a path for frontend hosting and deployment, while my coding knowledge helped me structure the backend, implement calculation logic, and work through integration challenges.
The most valuable part of this experience was not simply getting individual technologies to work together. It was learning how to design a system in which AI, deterministic logic, external data, and cloud infrastructure each have a clear purpose.
My vision for AirTrace is simple: move beyond showing people how polluted the air is, and help them understand what they can do with that information.
The project begins with college campuses, but the long-term ambition is to make smarter, pollution-aware decisions possible for everyone.
AirTrace is a work in progress, and its environmental recommendations are intended to support awareness and operational planning rather than replace official public-health guidance or professional medical advice.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article