HeatGuard

Inspiration

The HeatGuard challenge highlights the difficulty of protecting vulnerable communities during periods of urban heat. Environmental readings can show current conditions, but a community coordinator also needs to decide where limited outreach resources would be most useful.

HeatGuard SG focuses on the question, "If three outreach teams are available this afternoon, which neighbourhoods should they prioritise, and why?"

Proposed solution

I propose a planning tool for Active Ageing Centre and community outreach coordinators. It will combine official heat observations with aggregate senior population data and the locations of potential community support facilities.

The main screen will show current heat conditions, an explained neighbourhood priority ranking and data freshness. A coordinator will be able to select the number of available teams and compare suggested deployment locations against an allocation based on heat alone.

The simulator will estimate coverage under explicit service-radius assumptions. Facility locations will represent potential outreach nodes unless their services and availability have been verified.

Planned implementation

I plan to ingest NEA WBGT and air-temperature observations into Databricks Delta tables, alongside public population and geographic datasets. Python and SQL transformations will clean observations, check freshness and align geographic units. Gold tables will supply the app with area priorities and their explanations.

A small forecasting experiment will predict station WBGT 60 minutes ahead. I will track experiments in MLflow and compare predictions against a persistence baseline using chronological held-out data. The operational priority score will remain transparent, with documented policy weights separate from the learned environmental forecast.

A Databricks App will provide the main operator interface. A supporting AI/BI dashboard will expose historical trends and evaluation results.

What the research has clarified

The proposal distinguishes environmental heat observations from community vulnerability and available response resources. Each requires different evidence. Older population statistics can provide structural context, while facility coordinates alone cannot establish cooling provision or staffing capacity.

The first build milestone will therefore test data access and geographic compatibility before expanding the interface or model.

Anticipated challenges

Weather stations do not measure conditions in every neighbourhood or flat. HeatGuard will show the source station and clearly label estimated area exposure. Missing or stale observations will appear as unknown rather than low risk.

Population and boundary datasets may refer to different years or geographic units. I will document source dates and validate joins. Forecast quality and simulated coverage improvements remain outcomes to measure during the build.

Intended impact

HeatGuard aims to help coordinators understand where outreach may be most useful and explain their allocation decisions. Evaluation will measure forecast error, simulated coverage under equal resource constraints and whether a potential operator can interpret the recommendations.

The project will use aggregate public data for neighbourhood planning. It will not infer individual medical risk or claim that simulated coverage establishes prevented illness.

Current stage and next steps

As a solo participant, I will first build a small deployed workflow with two live feeds and one demographic dataset, then add the forecasting experiment and allocation simulator during the mentored sprint.

Built With

• data.gov.sg
• databricks
• mlflow
• python
• sql