Methodology

1 · Input assembly

The pipeline runs from a scheduled GitHub Actions workflow on HazardNet's own runners — no third-party notebook service is in the critical path. For each forecast unit it assembles a 15-channel spatio-temporal tensor from four families of input:

• Radar — Sentinel-1 GRD backscatter (VV and VH), which sees the surface through cloud and is the primary flood signal.
• Optical — Sentinel-2 surface reflectance, reduced to vegetation and water indices (NDVI, NDWI). Cloud cover is the limiting factor and is treated as missing data, not as zero.
• Reanalysis — ERA5-Land fields: 2 m temperature (mean, max, min), dewpoint, soil water content at multiple depths, solar radiation, wind speed.
• Forecast — Open-Meteo deterministic daily weather for the lead-time window (see the horizon caveat in section 4).

2 · Inference

The tensor feeds a 3D depthwise-separable convolutional network that emits two heads: an 8-class softmax over the hazard taxonomy (cold wave, drought, fire, flash flood, flood, heat wave, severe local storm, tropical cyclone) and a continuous severity regression. The same FP32 TFLite bundle that runs on the server runs in a visitor's browser through TensorFlow.js WASM, which is what makes the offline and low-bandwidth experience possible.

3 · Dual-track severity — the honesty mechanism

A single neural network returning a confident-looking number is not enough for an early-warning product, so every output carries a second, formula-based estimate beside it: a rainfall threshold for flood and flash flood, a vegetation-health index for drought, an excess-heat factor for heat wave. The two tracks are published side by side rather than blended. Two limits are stated plainly, and each published record carries the evidence of which one applied to it. In forecasts published before 17 September 2026 the physics track was computed only for the hazard class the model selected, so it could check the model's magnitude but not its choice of hazard, and it could not independently detect a hazard the model had missed; those records are still shown and are stamped with the pipeline version that produced them. From that date the pipeline scores all eight hazard classes from the weather drivers alone and publishes what the physics track picks on its own (physics_top_hazard and the per-class physics_scores), so a hazard the model misses is visible in the data rather than only inferable from a severity gap.

The confidence bin on each record is the model's own certainty in the class it selected; it is not derived from track agreement, so a high confidence is possible while the two tracks disagree. Where they diverge, both values stay visible on the district card. A high model severity against a low physics severity means 'the model sees something the physics estimate does not' — treat it as a question to verify, not as an alarm. Deriving confidence from the two tracks instead of the softmax is a planned change, not a shipped behaviour.

4 · Horizons and lead time

Outlooks are published at 7 and 15 days, both driven by the same deterministic weather-forecast window; Open-Meteo serves at most about 16 deterministic days, so the 15-day outlook inherits that window's uncertainty. They are planning aids for seasonal decisions such as irrigation, planting and stock movement, not storm-specific predictions. A 10/20/30-day horizon set is specified in ADR 0005 but has not been implemented in the pipeline, and the website does not advertise it.

5 · Freshness, staleness and failure

A refresh is attempted hourly; the published result is a committed snapshot that the website can serve even when the API or the pipeline is unavailable (ADR 0008). The platform therefore degrades to 'older data' rather than to 'no data' — and it labels the age of what it is showing. If the pipeline stalls, the snapshot keeps serving until a newer one replaces it, and the site-health probe raises the alarm in CI.

Read the prediction date, not the page-load time. A page that loaded one second ago can still be showing an outlook computed days ago.

6 · What is validated — and what is not

• Validated in CI: the TFLite bundle loads, its sha256 matches Models/VERSION.json, labels and normalisation statistics are present, and the bundle is not served publicly.
• Checked at runtime: freshness of the served snapshot, with a hard failure in the health probe when the data is older than the freshness threshold.
• Cross-checked: model severity versus physics severity for every unit and horizon.
• Not yet validated: forecast skill against observed hazard outcomes. HazardNet does not currently publish a hit rate, false-alarm rate or Brier score against BMD/FFWC records. Until it does, treat severity as a relative prioritisation signal rather than a calibrated probability.

7 · Reproducibility

The pipeline scripts, model bundle manifest, database migrations and ADRs are in the public repository. Forecast archives are published as release artifacts, and the history API exposes past prediction dates for comparison.