Yesterday’s Plan, Today’s Air: Building SmokeShield’s Morning Verification Workflow on AWS
Environmental conditions can change overnight, but school activity plans often remain unchanged. Learn how SmokeShield combines satellite fire observations, weather evidence, and AWS serverless services to help schools review decisions, handle missing data, and keep human approval at the center.
Introduction
At 6:30 in the morning, a school principal faces a practical question: Is yesterday’s outdoor activity plan still supported by this morning’s evidence?
An environmental dashboard can show measurements and observations, but people still need to interpret them, compare alternatives, and decide what to do. A plan made the previous evening may need another review when conditions change overnight—or when important data is unavailable.
That is the problem I set out to explore with SmokeShield, an environmental decision-support prototype built for the Air track of the WeMakeDevs × AWS Bharat Builds Tour 2026.
SmokeShield’s goal is not to declare an environment safe or unsafe. It is to make the reasoning behind an operational decision more visible, repeatable, and easier for a human to review.
The workflow: From observation to a reviewed decision
SmokeShield organizes the process into seven steps:
Observe → Forecast → Plan → Human Approval → Morning Verify → Act → Verify Outcome
The workflow connects environmental evidence with an actual operational choice. For example, a school may consider moving an assembly indoors, delaying an outdoor activity, or keeping a more cautious schedule while waiting for better information.
The important distinction is that SmokeShield is more than a data display. It helps the operator compare a proposed plan against available evidence and understand why a review may be necessary.
PlanGuard: Rechecking yesterday’s decision
The central feature is PlanGuard, a morning verification workflow that compares an approved plan snapshot with a fresh assessment.
Instead of silently replacing the original plan, PlanGuard produces one of four decision states:
- VERIFIED: Available evidence supports the existing plan under the prototype’s defined rules.
- WATCH: Conditions have changed enough to recommend a review.
- ESCALATED: The assessment indicates a material deterioration and proposes a revised plan for human approval.
- DATA_GAP: Critical evidence is missing or stale, so the system cannot confidently reassess the plan.
These states are decision-support outputs—not guarantees of safety or validated predictions of smoke exposure.
PlanGuard also follows a conservative rule: an apparent improvement in conditions does not automatically remove an existing precaution. A worsening assessment can prompt a revised proposal, but a person remains responsible for approving the change.
Why evidence quality matters
SmokeShield is designed to make data limitations visible rather than hide them behind a confident-looking status.
Its prototype integrates two important evidence sources:
- NASA FIRMS: Satellite-based active-fire and thermal-anomaly observations that can help identify potential fire activity.
- Open-Meteo: Weather information that can provide context for interpreting environmental conditions.
There are important limitations. A satellite fire detection does not prove that a crop fire is occurring, nor does it establish that smoke has reached a particular school. Weather information can add context, but it is not a direct measurement of a smoke plume at the school.
Local air-quality data is not configured in the current prototype. SmokeShield therefore identifies that evidence as unavailable rather than inventing an AQI reading.
The interface uses the concept of a potential smoke-influence corridor or window. It should be understood as modeled context, not a direct plume measurement.
When a critical source is stale, missing, or unavailable, the system should communicate the limitation and preserve a conservative precaution instead of treating missing data as evidence that conditions are safe.
Comparing alternatives before acting
Environmental decisions are rarely limited to a single yes-or-no answer. An operator may have several practical options:
- Keep the current schedule.
- Delay an outdoor activity.
- Move an activity indoors.
- Request another review because the evidence is incomplete.
SmokeShield’s Plan Studio helps explore alternative schedules and compare their implications within the prototype. The purpose is to make trade-offs more explicit so the operator has useful information before approving a plan.
The application also includes deterministic replay scenarios for examining how the workflow behaves when conditions remain unchanged, deteriorate, improve, or become difficult to assess because evidence is stale.
Replay scenarios are repeatable demonstrations of application logic. They are not proof of real-world forecasting accuracy.
The AWS architecture
SmokeShield uses AWS serverless components for its backend. The deployed resources verified for this project include an Amazon API Gateway HTTP API, an AWS Lambda assessment function, and an Amazon DynamoDB state table.
The architecture is designed to separate the user interface from the assessment API and the persistence layer.
The main backend components are:
- Amazon API Gateway: Provides the HTTP API entry point for backend requests.
- AWS Lambda: Runs assessment logic without requiring a continuously running application server.
- Amazon DynamoDB: Stores application state using a managed NoSQL database.
The repository also contains AWS SAM infrastructure definitions and supporting configuration for services such as Amazon Cognito, AWS Systems Manager Parameter Store, and Amazon EventBridge. These should be described as deployed or active only where the current AWS environment confirms that status. A service appearing in an infrastructure template does not, by itself, prove that it has been deployed or configured.
AWS SAM makes the infrastructure definition repeatable and keeps the application's backend resources documented alongside its source code.
Making decisions auditable
A recommendation is more useful when a person can understand why it was produced.
SmokeShield includes an Evidence Audit view that connects evidence records with the Air Corridor map. This lets a reviewer move from an evidence item to its corresponding map context rather than treating the map and evidence log as unrelated screens.
The prototype also includes a Decision Receipt that can be copied or downloaded as a text record. It is intended to capture the decision context, evidence freshness, trigger rules, relevant identifiers, limitations, alternatives, and approval status available to the application.
This supports reviewability; it should not be mistaken for an independently certified audit trail or a guarantee that every data source is live.
Challenges and lessons learned
1. Missing data must be a first-class state
A missing air-quality reading should not be replaced with a guessed value. Explicitly representing unavailable or stale evidence makes the limitations of a recommendation easier to understand.
2. Recommendations and approvals are different things
A system can identify a reason to review a plan without being authorized to make the operational decision. Keeping human approval separate from the recommendation is an essential part of this prototype’s workflow.
3. A map is not the same as a measurement
Satellite detections and weather context can help identify areas worth reviewing, but they cannot independently confirm smoke exposure at a specific location. The interface needs to communicate this distinction clearly.
4. Repeatable scenarios make behavior easier to test
Deterministic replay scenarios help demonstrate expected state transitions and examine cases that may be difficult to reproduce during a live demonstration. They must remain clearly distinguished from live environmental data.
5. Deployment is part of the engineering work
Connecting a frontend to a serverless backend involves more than writing Lambda code. API routes, authentication, environment variables, configuration, permissions, and deployment status all affect whether the complete application works as intended.
What comes next
The next steps for SmokeShield include validating the deployed API end to end, completing and verifying the authentication and frontend integration, configuring a reliable local air-quality source, and evaluating the decision rules against appropriate real-world data.
Any future operational use would also require careful validation with domain experts and the people responsible for school safety. The current project is a decision-support prototype, not a certified environmental monitoring or emergency-response system.
Conclusion
SmokeShield explores a practical idea: don’t just monitor the air—help people review what they should do when the evidence changes.
By combining environmental context, plan comparison, explicit data-quality states, conservative defaults, and human approval, the project aims to make changing conditions easier to reason about.
AWS serverless services provide the backend foundation, while PlanGuard provides the central workflow: compare yesterday’s plan with today’s evidence, explain what changed, and give the responsible person a clear next step.
The broader lesson is that useful environmental software should not only communicate what it knows. It should also make clear what it does not know—and leave consequential decisions in human hands.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article