Beyond the AQI Number: Building AirAware India with AI and Google Cloud

Varun Hameer Dutia — Wed, 26 Aug 2026 11:45:38 +0000

AirAware India with AI and Google Cloud

Air quality has become something many of us check almost like the weather. We open an app, search for our city, and see a number:

AQI: 168 — Moderate

But I started thinking about what happens after that.

What does that number actually tell an ordinary person? Which pollutant is contributing most to the current conditions? How different is the air quality between places I regularly travel to? And can all of this environmental data be made easier to understand without expecting users to interpret multiple pollutant readings themselves?

That question became the starting point for AirAware India.

From an AQI Number to Understandable Information

India already has an extensive air-quality monitoring ecosystem. The Central Pollution Control Board (CPCB) publishes air-quality information from monitoring stations across the country, including measurements for pollutants such as PM2.5, PM10, NO₂, SO₂, CO and O₃.

The problem I want to explore isn't the absence of data.

It's the gap between having environmental data and making that data easy to interrogate and understand.

AirAware India is my concept for an AI-powered air-quality intelligence assistant that adds a conversational layer over real environmental measurements.

Instead of only looking at a dashboard, I want users to be able to ask questions such as:

"Why is the air quality poor today?"

"Which pollutant is contributing the most right now?"

"Compare the air quality around my saved locations."

"Explain these readings without all the technical terminology."

The goal isn't to replace existing air-quality platforms. It's to explore whether generative AI can make their underlying information more accessible and useful.

AI Should Explain the Data — Not Invent It

This is probably the most important design decision behind AirAware.

Large language models are excellent at understanding questions and explaining complex information, but environmental measurements should not come from a model's memory.

So if someone asks AirAware about current air quality, I don't want Gemini to guess the answer.

The intended workflow is:

User Question
     ↓
Retrieve Air-Quality Data
     ↓
Validate the Readings
     ↓
Analyse the Data
     ↓
Gemini
     ↓
Human-Readable Explanation

This separates two responsibilities.

The application and its data sources determine what the measurements actually say.

Gemini helps determine how those measurements can be explained to the user.

For example, if particulate matter is driving the air-quality reading at a selected monitoring location, AirAware could highlight the relevant pollutant and explain what the measurement represents in straightforward language.

The underlying number remains grounded in the source data.

Building AirAware on Google Cloud

I'm developing this idea as part of the Gen AI Academy APAC Cohort 3 Ideathon, where the challenge is to create a production-ready AI application using Cloud Run, Firebase and Gemini.

The proposed architecture for AirAware has four main pieces.

Cloud Run

The application will be deployed using Google Cloud Run, providing the backend that connects user requests, environmental data and the AI layer.

Firebase Authentication

AirAware will use Firebase Authentication so users can securely access personalised functionality rather than everyone sharing the same anonymous application state.

Firestore

With Firestore, users will be able to maintain information such as saved locations and relevant application history.

This opens up more interesting interactions.

Instead of repeatedly entering the same locations, a user could eventually ask:

"Compare the air around home and work."

The application already knows which locations they mean.

Gemini

The Gemini API provides the conversational intelligence.

Gemini can understand what the user is asking, work with the data supplied by the application and transform technical information into a clearer explanation.

The distinction is important:

Gemini is the reasoning and communication layer, not the source of the environmental measurements.

Going Beyond Another AQI Dashboard

There are already applications that do an excellent job of displaying air-quality information.

So building another screen containing an AQI number and a coloured circle isn't particularly interesting.

I want AirAware to focus on the questions behind that number.

Why Is My Air Bad?

Instead of only displaying the overall AQI category, the application could present the available pollutant measurements and help users understand which pollutant is most significant in the reported conditions.

Compare My Locations

Users could save places they regularly spend time around and compare the available monitoring data associated with those locations.

For example:

Home       → Hyderabad
Work       → HITEC City
Family     → Secunderabad

A user could then ask:

"How does the air around home compare with work?"

Understand My Air History

Another direction is an air-history view, where stored observations could be analysed to explain how conditions changed over time.

Rather than forcing users to interpret a graph themselves, they could ask:

"What changed this week?"

The statistics would be calculated by the application. Gemini's role would be to explain the result.

Handling Imperfect Real-World Data

One thing I particularly like about this project is that the data isn't artificially clean.

Real-world sensor data can be missing, delayed or abnormal.

That means AirAware needs a validation layer between the external data source and the AI system.

The intended pipeline therefore looks like:

Raw Observation
      ↓
Validation
      ↓
Normalisation
      ↓
Analysis
      ↓
Gemini
      ↓
User

If a reading appears unavailable or unreliable, the application should say so rather than quietly asking the AI to fill in the gap.

For me, this is an important part of building responsible AI applications: knowing when the system doesn't have enough reliable information to answer confidently.

Responsible AI by Design

Air quality also touches health, which creates another important boundary.

AirAware is not intended to diagnose medical conditions or replace professional health advice.

The application should distinguish between explaining environmental information and making individual medical decisions.

I'm planning around a few important principles:

Current environmental values should come from the connected data source, not generated model knowledge.
Measurements should retain information about their location and observation time wherever available.
Missing or abnormal readings should be identified rather than silently interpreted as normal data.
Personal information stored for authenticated users should remain separated between accounts.
Secrets and API credentials should remain on the server side and never be exposed through the client or public repository.

For me, building the safeguards is part of building the product — not something to add after the AI features are finished.

What I'm Building Next

AirAware India is currently moving from concept to prototype.

My next step is validating the available air-quality data and building the first end-to-end workflow:

Sign In
   ↓
Select Location
   ↓
Retrieve Measurements
   ↓
Analyse Data
   ↓
Ask Gemini
   ↓
Receive a Grounded Explanation

From there, I plan to experiment with saved locations, comparisons and historical insights while keeping the first version small enough to remain reliable.

This project is also an opportunity for me to explore a larger question:

Can generative AI make public datasets genuinely easier for people to use, rather than simply generating more information?

That's what I hope to find out while building AirAware India.

More updates and a working prototype soon.

#AccelerateAIwithCloudRun

DEV Community: Varun Hameer Dutia