What Happens When a Heat-Relief Site Fails? Building CoolWard with AWS SAM Local
How I built a transparent, verification-first heat-relief planning prototype that recomputes local plans when a possible site fails—using React, Python, AWS SAM Local, and Lambda Powertools.
What Happens When a Heat-Relief Site Fails? Building CoolWard with AWS SAM Local
A ward planner has a difficult problem: with a limited budget for shade, drinking water, and rest facilities, where should they investigate first?
The tempting answer is to put pins on a map and call them recommendations. But a mapped park may be closed, inaccessible, unsafe, privately controlled, or unable to provide water and operational support. A possible site is not a verified service.
That gap became the starting point for CoolWard, a local heat-respite planning aid for the Wazirpur–Bharat Nagar pilot. It does not claim that people are protected, that facilities are operational, or that a walk is guaranteed. Instead, it turns a limited planning budget into a transparent, testable field-verification plan.
The first lesson: an impressive number can be misleading
My first optimiser treated OpenStreetMap parks and amenities as baseline heat-relief services. At a 400 m network-distance assumption, the result looked impressive: almost all modelled priority was already covered.
But that was the wrong conclusion.
OpenStreetMap is valuable context, not proof that a place is functioning as a heat-relief service. A park may have no shade at the relevant time, no drinking water, restricted access, or no operational support. So I changed the primary scenario to use zero verified full-service baseline coverage.
That decision made the project more honest and more useful.
Under the validated primary 400 m scenario:
- ₹5 lakh selects one possible site and reaches 58.2% modelled-priority coverage.
- ₹20 lakh selects four possible sites and reaches 97.9%.
- Increasing the budget to ₹35 lakh does not improve that score, so the additional ₹15 lakh remains deliberately unallocated.
That is not a procurement recommendation. It is a modelled planning result based on supplied candidates and stated assumptions.
Building a transparent evidence layer
CoolWard combines several inputs:
- supplied Landsat scenes to derive a relative multi-scene heat-priority score;
- 2024 WorldPop estimates for modelled population context;
- OpenStreetMap context, including roads, parks, toilets, shelters, buildings, and community features;
- a filtered pedestrian network for network-distance planning.
The data pipeline includes validation before planning. One supplied satellite scene was excluded because it did not meet the coverage rule. Private and no-access road segments were removed. Distance, area, and network operations use a projected local CRS rather than degrees.
The result is a map of relative modelled priority, not air temperature, heat exposure, health risk, or intervention impact.
The most important interaction: simulated verification failure
A static map is not enough. Decision-makers need to know what must be checked first.
CoolWard lets the user simulate a possible site failing field verification. The planner excludes that possible site, and the local API recomputes the exact best plan.
This creates two useful outcomes:
- Critical site: excluding Site 02 reduces modelled-priority coverage from 97.9% to 94.3%. It should be prioritised for field verification.
- Replaceable site: excluding Site 01 still allows a replacement plan with 97.9% coverage. It matters, but failure is less damaging to the modelled plan.
This is the core idea behind CoolWard: do not just identify possible sites—identify which assumptions are most important to validate.
Why the network assumption matters
The dashboard lets users compare 300 m, 400 m, and 500 m network-distance assumptions.
At 500 m, the same 97.9% modelled-priority ceiling can be reached with three planning units and ₹15 lakh. At 400 m, the primary conservative scenario needs four units and ₹20 lakh.
The difference is not a promise that someone can safely walk any of those distances. It is a sensitivity check that makes the assumption visible.
The supplied pedestrian network is also fragmented. One demand cell is structurally unreachable from the available candidate set. That could represent a real barrier, an incomplete network map, or both. Either way, it should trigger field investigation rather than be hidden behind a percentage.
Using the AWS open-source serverless stack
CoolWard is built and demonstrated locally with an AWS-compatible serverless architecture:
- AWS SAM CLI builds the application from the included SAM template.
- AWS SAM Local runs the API in Docker.
- The backend is a Python Lambda-compatible handler.
- AWS Lambda Powertools for Python provides structured logs for local requests.
The React dashboard calls the local planning API through SAM Local. When the user changes a budget, changes the network-distance assumption, or simulates a failed verification, the API recomputes the scenario.
I intentionally did not claim a cloud deployment. The project uses the AWS open-source tooling route and does not require paid cloud resources or AWS credentials for the local demonstration.
A performance problem changed the architecture
Early versions of the replanning flow were correct but too slow for a live demo. Every dashboard refresh sent multiple planning requests, repeated solver work, and resent static map layers.
I treated that as a product problem, not just an optimisation problem.
The revised implementation:
- returns all budget tiers in one bulk planning response;
- loads static map layers only once;
- uses an exact bitmask-based maximum-coverage solver;
- computes detailed verification backups only for the active budget;
- locks controls while a verification simulation is active so the comparison cannot become misleading.
The result is an exact local replan in well under a second for the demonstrated scenarios, while preserving deterministic results and auditability.
Why I did not make the decision model “ML-heavy”
I also ran an experimental machine-learning audit using spatial validation. The experiment tested whether map features such as NDVI, green fraction, park distance, building context, and network density could reproduce the satellite-derived heat-priority rank.
The conclusion was important: ML did not improve the decision product enough to justify replacing the transparent score.
A simple linear approach performed better than the more complex gradient-boosting experiment, and NDVI shares source imagery with the target. There is no independent ground-truth air-temperature or health-outcome dataset in this pilot. Using ML as a confident decision engine would have overstated what the data can support.
So CoolWard keeps ML as an experimental audit, not as the basis for site selection.
What I learned
Building CoolWard changed how I think about decision-support systems.
The strongest feature is not a black-box prediction. It is the ability to show assumptions, expose uncertainty, simulate failure, and tell a human team what to verify next.
A model can rank possible locations. It cannot confirm public land, water availability, access, safety, shade quality, or operational capacity. Those require people on the ground.
CoolWard is therefore a starting point for better questions:
- Which possible site should a field team visit first?
- Which missing verification would most change the plan?
- When should additional budget remain unallocated instead of being spent without evidence?
That is the kind of transparency I wanted to build: not an unsupported promise, but a planning decision that can be inspected, challenged, and improved.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article