HeatGuard

Inspiration

Every Gulf state protects outdoor labourers with a fixed-calendar midday work ban: Saudi Arabia 12:00 to 15:00, the UAE 12:30 to 15:00, Qatar 10:00 to 15:30, each running roughly mid-June to mid-September. A calendar cannot sense weather, and it gets this wrong in both directions. Replaying the committed Dubai weather archive, we found extreme heat arriving a full month before the 2025 UAE ban began. The season peak hit 46.5°C, with 12 unprotected danger hours on a single focus day in mid-May. The same archive shows 1,237 danger hours across the season that the ban never covers at all, simply because they fall outside its fixed window.

It is also unprovable in either direction. A contractor who did deliver water, rest, and shade on a dangerous day outside the ban window has no way to demonstrate that to an inspector, a lender, or a court. The intervention that actually works, the ILO and La Isla Network water-rest-shade protocol shown to cut acute kidney injury by roughly 94%, does not fail on the science. It fails on responsiveness and verifiability. We wanted to build the tool that closes both gaps at once.

What it does

HeatGuard is an adaptive, WBGT-driven work-rest-hydration scheduler that replaces the calendar with a live physiological read of the site. Every hour, for every site, it outputs exactly one signal: WORK, REST IN SHADE, DRINK NOW, or STOP. Each signal comes with a work/rest minute split, a hydration target in cups per hour, and a plain-language reason a supervisor can act on without interpreting any weather data themselves.

Under the hood, three layers run for every decision, and the most conservative one wins:

Screening. Wet-Bulb Globe Temperature is estimated via the Liljegren algorithm, or taken directly from a supervisor's own meter reading when one is available, then checked against ACGIH TLV/AL step tables using exact lookup rather than interpolation, so the numbers match what an inspector already recognizes. Acclimatization. A NIOSH-based ramp holds newly arrived, unacclimatized workers to roughly 3°C stricter thresholds than veterans in identical conditions, since the first days on site carry the highest risk. Physiology. The ISO 7933 predicted-heat-strain model computes sweat loss, water requirement, and maximum safe continuous exposure.

Every decision is written to a SHA-256 hash-chained audit record that is append-only, tamper-evident, and exportable per site and season, so a contractor can finally prove what a calendar ban never could. A supervisor dashboard layers a live signal, a WBGT gauge, an adaptive-versus-calendar timeline, an acclimatization tracker, and season-level impact and ROI figures on top of the same engine. A Gradient Boosting model trained on synthetic physiological profiles adds an advisory personal-risk overlay, flagging individually vulnerable workers for extra shade rest, without ever being allowed to override the regulatory signal underneath it. A fully local, citation-first retrieval system also lets a supervisor or auditor ask questions against the actual GCC regulatory text, such as UAE Ministerial Resolution No. 44, and get back an answer traceable to a real clause instead of a hallucinated summary.

How we built it

The core is a single deterministic Python engine. Given the same inputs, it always produces the same signal. Five different surfaces sit on top of it: a FastAPI backend, a Vite and React dashboard, a CLI, a Streamlit validation app, and a set of Jupyter notebooks used to validate the science against published tables. The engine uses pythermalcomfort for the Liljegren outdoor WBGT estimate, implements the ACGIH TLV/AL screening tables and ISO 7933 PHS hydration model directly against the standards text, and layers a NIOSH acclimatization ramp on top. Weather data comes from live Gulf meteorology feeds plus ERA5 reanalysis data for historical replay and testing.

The ML personal-risk layer is a scikit-learn Gradient Boosting model trained offline on synthetic physiological profiles covering age, weight, and comorbidities against WBGT. It is deliberately kept outside the regulatory decision path and covered by a non-interference test, so it can flag risk without ever being able to change a signal. The policy assistant is a fully local TF-IDF retrieval system indexed over the actual GCC legal text, chosen specifically so answers stay traceable to a real citation rather than a generative model's best guess.

We built the whole thing in a single 24-hour sprint, using Claude Code for the core build, OpenCode for review, and Cursor for additional iteration, going from a blank repo to a working engine, API, and dashboard in one day.

Challenges we ran into

The hardest problem was that there is essentially no open-source outcome data for heat-related occupational illness in the Gulf specifically. The epidemiology we could ground the model in, including AKI incidence and the La Isla intervention effect size, comes from transferred international studies rather than the region we are actually targeting. We had to be explicit in the product about which numbers are directly measured and which are transferred assumptions, instead of blurring the two together.

The physics side had its own challenge. ISO 7933's predicted-heat-strain model is a genuinely complex standard, and getting WBGT estimation, the acclimatization ramp, and the PHS hydration model to agree with each other, and with the published step tables an inspector would actually check against, took real care. We made an early architectural decision that the most conservative of the three limits always wins, specifically so a looser layer could never accidentally override a stricter one.

Accomplishments that we're proud of

We are proud that four people who had not built together before turned into a working team inside 24 hours. More specifically, we are proud that what came out of that sprint was not a demo hardcoded to one scenario. It is one deterministic engine, validated against the published ACGIH and ISO tables, feeding five real interfaces including a production FastAPI service and a live React dashboard. It placed third in the Health in Climate AI hackathon and earned us a fast track into an accelerator, which tells us the judges saw the same thing we did: this is closer to a real product than a hackathon prototype.

What we learned

We learned how much of building trustworthy AI for safety decisions is an architecture problem rather than a model problem. The discipline of always taking the most conservative of three independent limits, and of keeping the ML personalization layer strictly advisory and non-interfering with the regulatory signal, mattered more to the credibility of the system than any single algorithm choice. We also learned a great deal, quickly, about building with Claude Code and OpenCode in tandem, going from idea to a working prototype with real government standards embedded correctly in under a day.

What's next for HeatGuard

The immediate next step is to pitch our project to accelerators. That's where the prototype becomes pilot-capable. Our roadmap is already scoped for it: a real trust boundary so the platform can safely hold a customer's data, a durable and independently verifiable compliance ledger in place of today's in-memory reconstruction, a 72-hour forecast across all seven registered sites instead of two days on four, and a standards engine separated out into its own auditable package. None of that touches the underlying science. It's the work that turns a hackathon build into something a contractor can actually run.

Longer term, two directions.

Geographic: the Gulf's fixed-calendar ban is not a Gulf-specific failure, it's a pattern. California's Central Valley, the US Southwest, Southern Europe, and South and Southeast Asia protect outdoor labour with similarly blunt or nonexistent rules. Swap in the local standards tables and the engine generalises directly.

Hazard scope: the same architecture, a live environmental signal, a published threshold, an advisory layer that flags risk without ever overriding the regulatory signal, and a verifiable record of protective action, isn't heat-specific. Air pollution and flood risk fit the same shape.

The direction we're most excited about is what the compliance ledger becomes at scale. Every hour HeatGuard runs at a pilot site is a verifiable record of when live conditions demanded protection the calendar didn't require, and when the calendar idled a crew that was safe to work. Aggregated across sites and seasons, that's not just one contractor's audit trail. It's the evidence a regulator would need to move from a fixed-calendar ban to a condition-based trigger, the direction Qatar's existing heat-index rule already points toward. We built this to make one contractor's compliance defensible. The next version makes the policy itself provably better.

Built With

• claude
• cursor
• html5
• opencode
• python
• typescript