From Pollution Guidance to a Workable School Day: Building AirWise Schools on AWS
How I built AirWise Schools with Amazon Bedrock, AWS Lambda, DynamoDB and Cognito to turn reviewed pollution restrictions into validated timetables—and track what teachers could actually implement. The article covers the AWS architecture, human approval boundaries, room-unavailability repair, real verification and deployment lessons.
From Pollution Guidance to a Workable School Day: Building AirWise Schools on AWS
Moving a PE lesson indoors sounds simple. Finding a room, a teacher and a free period without disrupting the rest of the school day is not.
I built AirWise Schools during the Bharat Builds Environmental Hacks hackathon to explore that missing step: turning reviewed outdoor restrictions into a workable timetable, then finding out whether teachers could implement it.
The application is deployed on AWS in Sydney (
ap-southeast-2 ). It combines Amazon Bedrock for notice interpretation, a constraint solver running in AWS Lambda, independent validation, explicit administrator approval and persistent teacher reporting.The problem after the pollution warning
A pollution dashboard can tell an administrator what the regional forecast looks like. It cannot tell them where Monday's outdoor lesson should go.
That decision has practical constraints. A room must be available and suitable. A teacher cannot be assigned to two lessons at once. A class cannot attend two activities in the same period. Fixed lessons need to remain fixed.
There is a second problem after approval: plans do not always survive implementation. A replacement room might be locked, or another operational issue might prevent the activity. An administrator needs to see that exception instead of assuming the approved plan happened.
AirWise connects those steps in one workflow. The prototype uses a fictional Greater Noida school, six sections and sample school data. It demonstrates scheduling and reporting; it does not claim measured exposure reduction or health benefits.
The AWS architecture
The frontend is a React application hosted on AWS Amplify Hosting. Amazon Cognito authenticates provisioned administrator and teacher accounts. The frontend sends authenticated requests through Amazon API Gateway to a Python/FastAPI application in AWS Lambda.
Lambda runs the scheduling logic, independent validator and workflow endpoints. Amazon DynamoDB persists plan versions, approvals, acknowledgements and execution reports. Amazon Bedrock Nova Lite interprets pasted notices for administrator review. Amazon S3 holds private deployment artifacts, and Amazon CloudWatch provides runtime logs.
AWS service | Role in AirWise |
|---|---|
AWS Amplify Hosting | Hosts the React interface |
Amazon Cognito | Authenticates provisioned users |
Amazon API Gateway | Exposes the HTTP API |
AWS Lambda | Runs FastAPI, OR-Tools repair and independent validation |
Amazon DynamoDB | Persists workflow versions and teacher reports |
Amazon Bedrock Nova Lite | Proposes restrictions from pasted notices |
Amazon S3 | Stores private deployment ZIPs |
Amazon CloudWatch | Provides runtime logs and troubleshooting evidence |
Boto3, AWS's Python SDK, and the AWS CLI supported integration and deployment. OR-Tools is a separate open-source dependency used for constraint solving.
I chose a serverless architecture to avoid operating a persistent application server during the hackathon. That did not eliminate operational work: package size, authentication, regional permissions, timeouts and concurrency still needed explicit verification.
Bedrock proposes; the administrator decides
The evidence view separates three things: regional forecasts, official advisory passages and pasted notices.
Open-Meteo/CAMS provides regional PM2.5 and PM10 forecasts. Those values are not campus measurements or Indian AQI. Official excerpts retain their source and citation. A pasted notice starts as an unverified document.
Amazon Bedrock Nova Lite helps convert a notice into proposed structured restrictions. Its output is a suggestion for review, not permission to change the school day. An authenticated administrator must confirm the inputs before timetable repair uses them.
This boundary matters. A forecast number does not activate a closure order, and an AI interpretation does not establish legal authority. The application keeps interpretation, confirmation and approval separate.
A real bounded Nova Lite request was verified in the deployed environment. One measured analysis request took 2.392 seconds end to end with 773 input tokens and 197 output tokens. That is one application-level observation, not a general latency benchmark or isolated model inference time.
Lambda turns restrictions into a timetable
The scheduling engine uses OR-Tools CP-SAT. It searches for an alternative under the implemented teacher, room, section and fixed-lesson constraints, with an objective that penalizes disruption.
The model does not write the final timetable. The solver generates it, and separate ordinary-Python validation recomputes the implemented constraints. Approval validates the draft again and checks that its input revision is still current.
In the verified sample repair, the plan contained two period changes, two indoor substitutions and two room moves. All 240 scheduled activities remained accounted for, and the solver returned
OPTIMAL .Those counts describe the whole sample plan. A class-specific comparison shows only that class's changes. They also describe a scheduling result, not evidence that indoor air was cleaner.
The most useful interaction is a simple question: what if the assigned indoor room becomes unavailable?
The administrator excludes that room for the affected day and generates a revised draft. In the verified example, an assignment moved from Reserve studio to Movement studio. Independent validation passed. The previous approval remained separate until the administrator approved the revised version.
This makes the engineering visible: the application responds to an operational constraint rather than merely displaying pollution values.
DynamoDB preserves decisions and implementation
An approved plan is only part of the record. Teachers need to acknowledge its version and report whether an assigned change could be implemented.
AirWise stores acknowledgement separately from execution. A teacher can receive the plan and later report
COULD_NOT_IMPLEMENT . The administrator's Review screen shows that exception against the matching version.Duplicate protection is important here. Retrying a request after a connection problem should not inflate report totals or create another approval. Persistence, duplicate-request handling and permission denials were exercised against real Cognito and DynamoDB services.
Changing room availability creates a new input revision. An old draft cannot simply be approved against newer inputs. That stale-revision check is part of preserving an understandable history of what was reviewed and approved.
The UI also offers English/Hindi message previews and student-hour accounting. Previews can be copied or downloaded; nothing is sent automatically. Metrics distinguish planned substitutions from teacher-reported completion and use declared sample durations and section sizes.
What deployment taught me
Verify native dependencies on the target runtime
Getting the Python API running locally did not prove OR-Tools would run in Lambda. I first deployed a dedicated smoke function and verified an actual solver result on Python 3.12 and x86_64 before moving the full application.
The application package included native dependencies and was large enough that ZIP packaging needed attention. AWS documents a 250 MB uncompressed limit for ZIP-based Lambda deployments, including layers. Checking the extracted size was therefore as important as checking the upload size.
Check permissions in the chosen region
An early deployment attempt in
us-east-1 was explicitly denied by an AWS Organizations service control policy. Sydney preflight checks later passed, and the application was deployed there. I verified the allowed configuration rather than treating an authentication success as proof that every service operation would be permitted.Verify the artifact, not just the filename
S3 uploads repeatedly encountered connection failures. The recovery used preserved ZIPs uploaded through the console, followed by size and full-object checksum comparison. After deployment, Lambda's code SHA-256 was checked against the inspected local package.
That avoided rebuilding or deploying an older file just because it had the expected name.
Logs help distinguish evidence from guesses
One transient HTTP 503 remained unexplained. Historical logs showed a Lambda throttle in the same minute, with concurrency reaching the configured limit of five. However, the failed request could not be conclusively correlated with that throttle.
I documented the evidence instead of claiming a root cause or increasing concurrency speculatively. The interface also supports explicit recovery and safe retries.
What was verified—and what remains
The deployed workflow was exercised through administrator review, validated draft generation, separate approval, teacher acknowledgement, an execution exception and administrator Review. Checks also covered persistence, duplicate protection, permission denials and logout.
For the room-unavailability scenario, changing inputs correctly made the old approval stale. A revised draft passed independent validation, and separate approval restored current status. Local browser checks using labelled offline responses were kept distinct from authenticated hosted verification.
The prototype still has clear limits: single-period activities, no verified local station observations, teacher self-reports rather than independent observation, and local logout rather than global token revocation. Native binary redistribution obligations are documented separately; deployment ZIPs are not published as repository release assets.
Building with Codex
Codex assisted implementation, tests, packaging, debugging and documentation. I directed the requirements and reviewed the work, including the distinction between forecast evidence, administrator decisions and sample-school results.
The most valuable review question was not whether every page existed. It was whether the interface made the decision understandable: what became unavailable, what changed, who approved it and what happened afterward.
A workable plan is the start
AirWise Schools explores a practical role for AWS and AI in environmental software: connect evidence to a constrained operational decision, preserve human approval, and retain feedback about implementation.
The standout moment is not the pollution number. It is the school finding a valid alternative when a room becomes unavailable—and the administrator seeing when even that approved alternative could not be implemented.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article