HeatWatch

• 

  HeatWave ML Flow

Inspiration

Heat kills more people than any other weather event, and it kills the same people over and over: older adults, living alone, without reliable air conditioning. Europe's 2026 heat season produced more than 1,300 excess deaths, 88% of them elderly people found alone in private homes. Germany recorded an estimated 11,900 heat-related deaths through July 2026, most among people 75 and older. The UK reported 1,504 heat-associated deaths in summer 2025, concentrated in the 85+ group. South Korea's 2026 heat season showed the same pattern: deaths heavily clustered among the 80+ cohort, many occurring at home. By 2050, more than 200 million additional adults 65 and older will be living somewhere peak temperatures routinely cross dangerous thresholds. This isn't a one-off tragedy. It's a growing, predictable pattern.

What struck us most was a story from the 2021 Pacific Northwest heat dome: multiple isolated residents were found only after a worried family member started a welfare check on their own, days after anyone had last heard from them. The advice communities already give is correct — check on your elderly neighbors during a heat wave. But that advice has no owner. Meals-on-Wheels routes, 211 wellness-check lines, "ask a neighbor" networks — all real, all well-intentioned, all entirely manual. Nobody is assigned to check, so nobody confirms it happened. The gap wasn't a lack of people who cared. It was the absence of a system.

What it does

HeatWatch is a coordination layer that sits on top of the check-in networks communities already have. Households complete a short risk profile once — age, whether they live alone, mobility limitations, AC reliability, medications that affect heat tolerance, an emergency contact. When a heat alert fires, HeatWatch combines that profile with the alert's severity to generate a prioritized, explainable check-in list for volunteer coordinators — not a black-box score, but a plain-language reason a volunteer can trust and double-check. Each check-in comes with a short, personalized script tailored to that household's specific risk factors. If a check-in isn't confirmed within a set window, HeatWatch escalates automatically: first to the household's own emergency contact, then flags for a human decision on contacting a local non-emergency line if that contact doesn't respond either. A human always makes the final call — HeatWatch coordinates and reminds; it never contacts emergency services on its own.

This closes a gap that existing tools don't. Daily check-in apps like Snug Safety detect a missed self-check-in but don't rank households against each other or personalize outreach. Phone-based welfare services like Australia's Telecross REDi provide valuable human contact but rely on static, pre-registered lists with no dynamic prioritization driven by both risk profile and today's actual conditions. Neither gives a volunteer coordinator with limited hours an answer to the only question that matters: who do I check on first?

How we built it

HeatWatch is architected as a five-node ML prompt engineering workflow rather than one big prompt, following a few hard rules: ground every fact in real data (household intake or a public weather API), never let the model invent a risk factor; give every LLM call exactly one job, so each step is easy to evaluate and improve on its own; require plain-language reasoning behind every ranking, never a bare score; and put a human in the loop at every consequential decision, especially escalation.

The chain runs: household intake (human input) → risk-severity reasoning (LLM, rubric-anchored) → heat alert trigger (automated, from a weather API) → checklist and script generation (LLM, chained from node 2's output) → check-in and escalation decision (human action, LLM-assisted drafting only). We didn't stop at documenting this on paper — we built a working version as a React artifact that calls the real Claude API live for the reasoning and script-generation steps, running side by side against a naive single combined prompt on the same household, so the difference is something you can watch happen rather than take our word for.

Challenges we ran into

Reconciling real-world data was harder than expected — Germany's, the UK's, and Europe's heat-mortality figures come from different studies, timeframes, and methodologies, and we had to be careful not to imply a false apples-to-apples comparison just because the numbers sat next to each other.

Getting the priority-reasoning prompt right took several passes. Our first attempts produced well-reasoned but inconsistent output — every household sounded urgent in isolation, with no shared scale a coordinator could actually sort by. We had to explicitly anchor the prompt to a rubric rather than open-ended judgment, which is also the exact failure mode our single-prompt comparison now demonstrates.

The escalation node was the one we agonized over most. It's the highest-stakes point in the whole system, and it was tempting to let it be smarter and more autonomous. We deliberately kept it conservative instead: the model may draft a message, but a human decides every time whether to send it or escalate further.

We also had a late scope change to navigate — an extended deadline, a one-project-one-track submission rule, and a pivot from a dual Ideathon/ML Prompt Engineering effort to focusing entirely on ML Prompt Engineering. That meant setting aside a nearly-finished business pitch to put the remaining time into making the workflow real instead of just well-documented.

Accomplishments that we're proud of

Turning this from a documented workflow into working software during the hackathon itself, so every output in our demo is genuine model output, not scripted text. Building an explicit, node-by-node case for why HeatWatch beats what already exists, instead of just asserting originality. Getting the risk-reasoning step to produce explanations a volunteer can actually sanity-check against reality. And designing the escalation path to be safety-conscious by construction — not because we added a disclaimer, but because the architecture makes an unsupervised emergency contact structurally impossible.

What we learned

Prompt chaining isn't a nice-to-have for a task like this — it's the difference between a coordinator who can act and one who's handed a stack of similarly-worded, equally-urgent-sounding essays with no way to tell who needs help first. We also learned how much of "safety" in an applied AI system comes down to deliberately not automating the highest-stakes decision, even when it would have been easy to. A good chunk of our early ideas turned out to already be well-served by existing products — the useful work wasn't the first idea, it was going back and specifically hunting for the gap nobody had filled yet. And real, current data makes a pitch sharper, but it also demands more care: numbers from different sources aren't interchangeable just because they describe the same crisis.

What's next for HeatWatch

The same profile-plus-alert architecture extends with minimal changes to cold snaps, wildfire smoke days, and flood warnings. We want unconfirmed high-priority check-ins to route directly into existing municipal 211/311 wellness-check systems instead of relying solely on volunteer networks, and we want to scale partner-by-partner, city by city, since no household needs anything beyond a one-time profile to join. Longer-term, with explicit consent, we'd like to incorporate passive signals — smart thermostat or utility data — to keep prioritization current without asking anyone to update their profile every season. And practically: the live demo we built proves the reasoning works. The next layer is a real backend, live weather API integration, and persistent household records to take HeatWatch from prototype to pilot-ready.

Built With

• claude
• weather