Scientific Methodology

1. System Overview

This is a near-real-time wildfire detection system designed for monitoring the Northern Arizona (Flagstaff area) region. The system ingests publicly available satellite data from multiple sensors, applies a blockwise probabilistic fusion pipeline, and produces fire alerts with calibrated confidence scores, bootstrap confidence intervals, and quantified location uncertainty. The design philosophy is Bayesian log-odds fusion: every processing module contributes continuous log-likelihood ratios (LLRs) rather than binary decisions, and the only threshold in the entire system is at the final GeoJSON export stage.

The architecture distinguishes three kinds of processing blocks:

• Prior block: A spatiotemporally-varying fire base rate $\ell_{\text{prior}}$, encoding seasonal, geographic, and diurnal fire likelihood in log-odds space.
• Evidence blocks: Modules that observe the scene and produce log-likelihood ratios quantifying how much more (or less) likely fire is given the observation. These include the RF pixel scorer ($\ell_{\text{RF}}$), persistence pattern detector ($\ell_{\text{persist}}$), trajectory analyzer ($\ell_{\text{traj}}$), and cross-satellite checker ($\ell_{\text{GK2A}}$).
• Quality blocks: Modules that assess observation reliability without themselves claiming fire or not-fire. Cloud quality ($q_{\text{cloud}}$) and solar zenith angle quality ($q_{\text{SZA}}$) produce multipliers in $[0,1]$ that dampen trust in the evidence when conditions are poor.

The system ingests satellite data from GOES-West ABI (geostationary, 10-minute cadence), GOES-East ABI (geostationary cross-check), and VIIRS/MODIS (polar-orbiting, via DEA Hotspots and NASA FIRMS). Each frame is processed through quality and evidence blocks in parallel. Results accumulate in a spatiotemporal data cube (rolling 6-hour window), which feeds trajectory analysis for temporal pattern discrimination. All log-likelihood ratios are combined in a single fusion equation that produces a calibrated fire probability $P(\text{fire})$ with bootstrap confidence intervals $[p_{lo}, p_{hi}]$. There are no hard thresholds anywhere in the pipeline — the only decision boundary is at GeoJSON export, where the operational false-positive rate determines the export cutoff.

2. Data Sources & Ingestion

2.1 GOES-West ABI (Advanced Baseline Imager)

GOES-18 (GOES-West) is a geostationary meteorological satellite operated by NOAA, positioned at 137.2°W longitude. Its Advanced Baseline Imager (ABI) provides full-disk observations every 10 minutes, making it the primary data source for continuous fire monitoring over Northern Arizona.

2.2 VIIRS & MODIS (via DEA Hotspots and FIRMS)

The Visible Infrared Imaging Radiometer Suite (VIIRS) and Moderate Resolution Imaging Spectroradiometer (MODIS) are polar-orbiting sensors that provide high-spatial-resolution fire detections. We ingest pre-processed active fire products from two operational services:

VIIRS detections from DEA Hotspots are the primary confirmation mechanism. When a VIIRS detection spatially matches an existing GOES event, it provides independent corroboration at much higher spatial resolution, significantly tightening the location uncertainty estimate.

2.3 LEO Overpass Tracking (TLE-Based)

DEA Hotspots and FIRMS are databases of positive detections. They tell us when a satellite saw a fire, but they are silent about the much more common case: a LEO satellite flew over an active event and saw nothing. This matters for Bayesian closure (Section 8) — a high-quality "satellite saw nothing" observation is strong evidence that an event has cooled off, and ignoring it delays CLOSED status for fires that have already been extinguished.

LEO negative evidence is recorded by two complementary layers:

• Detection-driven (short-term path): src/observations.py::record_leo_observations groups each polled batch into per-overpass clusters by (satellite, instrument, orbit), using DEA's native orbit metadata when available and a time-cluster fallback otherwise. Each cluster owns its own bounding-box footprint and representative obs_time (preferring per-feature pass_end). Events inside a cluster's footprint get a positive observation if any detection in the cluster is within ~5 km of the event centroid; otherwise negative. Stale clusters (older than 60 min relative to wall clock) are dropped to prevent backdating from DEA's 3-day rolling window.
• TLE-driven (scheduled path, opt-in): src/observations.py::record_overpass_observations + src/leo_overpass.py, running as a 5-minute background loop when LEO_OVERPASS_SCANNER_ENABLED=true. Mirrors the analyst-view satellite catalog (Suomi NPP, NOAA-20/21, Terra, Aqua, Sentinel-2A/B, Sentinel-3A/B) to the backend with TLEs cached from CelesTrak. Each cycle propagates every satellite's ground track via pyorbital and walks it as great-circle segments, computing cross-track distance from each active event's centroid to the segment. An event gets one negative LEO observation per distinct pass where the cross-track distance was within the instrument's swath/2 — regardless of whether the polling source returned a detection. Off by default because the scope-vs-value tradeoff is unmeasured: AHI's continuous 10-min clear-sky evidence dominates closure's time-integral, and the scanner adds at most ~5-10% to the negative-LLR budget. Enable only after measuring whether CLOSED decisions actually move with the scanner on.

Landsat 8/9 are tracked in the analyst view but are intentionally excluded from the closure scanner catalog: Landsat's narrow 185 km swath gives inconsistent NSW coverage, and the TIRS instrument currently has no calibrated negative LLR in the closure evidence table — using the VIIRS fallback would over-weight Landsat non-detections. Re-adding Landsat requires calibrated leo_negative_llr values in src/leo_evidence.py.

The TLE-driven path uses the standard cross-track distance formula against each great-circle segment between consecutive sub-satellite points, not a naive point-to-sub-point disk test. At LEO orbital speed (~7 km·s⁻¹) a satellite moves ~210 km along-track between 30 s samples, so a disk test would produce false negatives for narrow-swath instruments whose half-swath is smaller than the along-track sample spacing (e.g. Landsat TIRS at 92.5 km half-swath). The scanner also emits one observation per distinct pass via an entry/exit state machine: a delayed polling cycle covering several real passes yields one entry per pass, not just the closest.

Dedup across the two layers keys on (event, instrument) within a 15-minute window. Since LEO observations are written with obs_source = "LEO:{instrument}", closure (Section 8) recovers the canonical negative LLR by instrument tier using the published sensor performance characteristics.^{[3], [2]}

2.4 Latency Budget

The end-to-end latency from satellite observation to alert display comprises:

1. Satellite to ground station: ~2–3 minutes (RF downlink)
2. Ground processing to cloud mirror: ~5–12 minutes (JMA → NOAA → AWS S3)
3. Our ingestion + detection: <2 seconds (HSD decode + contextual algorithm)
4. Event association + confidence: <100 ms

Total typical latency: 7–15 minutes from satellite observation to portal display. Our processing contributes less than 0.1% of the total latency; the bottleneck is upstream data distribution from JMA through NOAA to AWS.

3. Contextual Fire Detection Algorithm

The core detection algorithm is a contextual anomaly detector adapted from the heritage MODIS active fire algorithm (MOD14)^[2] and the VIIRS 375 m active fire product (VNP14IMG)^[3], with modifications to account for the coarser spatial resolution and geostationary viewing geometry of AHI. The algorithm operates on two spectral bands: Band 7 (3.9 μm, mid-infrared) and Band 14 (11.2 μm, thermal infrared).

3.1 Solar Zenith Angle Computation

The solar zenith angle (SZA) determines whether a pixel is observed under daytime or nighttime conditions, which critically affects the detection thresholds. SZA is computed using the pyorbital library's spherical astronomy routines, which implement standard solar position algorithms based on the astronomical almanac.

3.2 Masking Pipeline

Before detection, pixels are filtered through a multi-layer masking pipeline:

1. Cloud mask: $T_{11.2} < 270\,\text{K}$ — cloud tops are cold in the thermal infrared. Cloud-adjacent pixels (2-pixel buffer via morphological dilation) are also excluded to avoid cloud-edge thermal artifacts.^[2]
2. Water mask: Hybrid of the global-land-mask ocean product and GSHHS (Global Self-consistent Hierarchical High-resolution Shorelines) for inland water bodies. Pre-computed and cached per grid shape.
3. Northern Arizona spatial mask: Bounding box filter restricting processing to the monitoring region.
4. Valid-data check: All float bands must contain finite values (not NaN or Inf).

3.3 Absolute Threshold Detection

Extremely high brightness temperatures indicate unambiguous fire signals that bypass contextual analysis entirely. These are assigned HIGH confidence immediately:

3.4 Candidate Selection

Pixels that are not absolute detections must pass minimum thresholds to become candidates for contextual analysis. These thresholds have been specifically tuned for AHI's coarser resolution:

where $\Delta T = T_{3.9} - T_{11.2}$ is the brightness temperature difference (BTD). The BTD exploits the differential sensitivity of the 3.9 μm and 11.2 μm bands to sub-pixel hot sources: at fire temperatures (600–1200 K), Planck radiance in the MIR increases far more steeply than in the TIR, producing a characteristic positive BTD anomaly even when the fire occupies a tiny fraction of the pixel.

3.5 Background Characterization

The contextual approach compares each candidate pixel against its local background to determine whether it is anomalous. Background statistics are computed using an expanding window strategy:

Key implementation details:

• Expanding windows: If fewer than 25% of pixels in a window are valid background, the algorithm expands to the next larger window size. This handles cloud-edge regions and coastlines.
• Standard deviation floor: $\sigma_{bg}$ is clamped to a minimum of 1.5 K to prevent false positives in highly homogeneous scenes (e.g., uniform desert or water surfaces) where natural $\sigma$ can approach zero.
• Background fire exclusion: Pixels with $T_{3.9} \geq 335\,\text{K}$ and $\Delta T \geq 30\,\text{K}$ (daytime) or $T_{3.9} \geq 300\,\text{K}$ and $\Delta T \geq 10\,\text{K}$ (nighttime) are excluded from background statistics to prevent fire contamination.
• Float64 precision: Variance is computed in float64 to avoid catastrophic cancellation in the $\overline{x^2} - \bar{x}^2$ formula when brightness temperatures are large (~300 K) and variance is small (~1 K).
• Vectorized computation: Background statistics are computed for the entire image simultaneously using scipy.ndimage.uniform_filter convolutions, rather than per-pixel window extraction. This reduces computation time from minutes to <100 ms.

3.6 Contextual Fire Tests

Candidate pixels must pass a battery of contextual tests to be classified as fire. The tests use split sigma multipliers — different significance thresholds for $T_{3.9}$ and $\Delta T$ — following the VNP14IMG ATBD approach:^[3]

3.7 Per-Pixel Confidence Assignment

Pixels that pass contextual tests are assigned confidence levels based on the strength of the anomaly:

Post-detection confidence adjustments:

• Sun glint zone: NOMINAL → LOW if within 12° of specular reflection angle (see Section 11). Fires near water are detected but at reduced confidence.
• Industrial sites: NOMINAL/HIGH → LOW near known thermal sources (power plants, smelters). Fires can start at industrial sites, so detections are preserved but downgraded.
• Persistent false alarm suppression: LOW/NOMINAL detections at data-driven hotspot locations (repetitive false alarms from hot agriculture, arid land) are suppressed. HIGH confidence (absolute threshold) detections are preserved.

4. CUSUM Temporal Fire Detection

The CUSUM (Cumulative Sum) module provides a complementary temporal detection capability that can identify fires too small to trigger the single-frame contextual detector. It maintains a per-pixel statistical model of expected brightness temperature difference (BTD) at each time of day and flags persistent positive anomalies using a dual-rate CUSUM statistic. The approach is inspired by sequential change-point detection theory^[4] adapted for satellite fire detection.^[5]

4.1 Harmonic Kalman Filter Background Model

The expected BTD at each pixel follows a diurnal cycle driven by solar heating. We model this with a 6-parameter harmonic function estimated online via a Kalman filter:

The state vector $\mathbf{x} = [\bar{T},\, a_1,\, b_1,\, a_2,\, b_2,\, \beta]^T$ is updated via the standard Kalman filter equations:

4.2 Dual-Rate CUSUM Decision Rule

The CUSUM statistic accumulates normalized positive residuals to detect persistent anomalies. We run two CUSUM statistics in parallel to catch fires of different sizes:

4.3 Bayesian Fire Confidence

Rather than using a fixed CUSUM threshold, we convert $S_{max}$ to a calibrated fire probability using a Bayesian sigmoid mapping:

BT14 rejection: To suppress false alarms from atmospheric changes that affect both bands simultaneously, detections are attenuated when the 11.2 μm band also shows an anomaly ($3\sigma < \tilde{T}_{11.2} < 6\sigma$). Anomalies exceeding 6σ in $T_{11.2}$ are not rejected, as they may indicate very large fires that produce detectable TIR signals.

5. Trajectory Analysis

Trajectory analysis examines how a candidate pixel's thermal signature evolves over time. This is the key discriminator between real fire ignition (which shows characteristic monotonic warming and BTD growth) and transient false alarms (which tend to be noisy or short-lived). All features are continuous — no binary decisions are made at this stage.

5.1 Spectral Trajectory Features

For each candidate pixel, we query its recent history (typically 2–6 hours of 10-minute observations) from the spatiotemporal data cube and compute:

5.2 Spatial Behavior Features

Spatial features assess whether the thermal anomaly is anchored in space (fire) or drifting (cloud edge, atmospheric artifact):

• Warm neighbor count: Number of pixels within a 7×7 patch with $P(\text{fire}) > 0.3$. Growing count suggests fire spread.
• Area growth: Change in warm pixel count between first and last frames in the lookback window. Positive growth is consistent with fire.
• Centroid drift: Weighted centroid of the thermal anomaly is tracked across frames. The centroid position is computed as: $$(\bar{r}, \bar{c}) = \frac{\sum_{m,n} w_{m,n} \cdot (m, n)}{\sum_{m,n} w_{m,n}}$$ where $w_{m,n} = T_{3.9}(m,n) - \min(T_{3.9})$ within the patch. Large drift (>1 pixel/frame) suggests cloud-edge effects rather than fire.

5.3 Cloud Context Features

Cloud history is critical because many false alarms occur at cloud edges, where differential clearing between 3.9 μm and 11.2 μm bands can mimic fire BTD signatures:

• was_cloudy_recently: Whether any frame in the lookback window was classified as cloud.
• n_cloudy_frames: Count of cloudy frames in recent history.
• frames_since_cloud: Number of clear frames since the last cloud cover — fires that emerge immediately after cloud clearing are suspect.
• Split-window change: Large changes in $(T_{11.2} - T_{10.4})$ indicate atmospheric changes (e.g., humidity shifts), not fire, since fire has negligible split-window signature at AHI resolution.

6. Random Forest Classifier

The primary pixel-level scorer is a Random Forest classifier. It operates on the feature space described in Sections 3 and 5, trained on labeled fire and false-alarm pixels from historical GOES-West ABI observations over Northern Arizona using time-reversed labeling from FIRMS confirmations.

6.1 Feature Engineering

The classifier uses 62 features organized in tiers:

The climatology and baseline tiers were added in the v4 retrain (2026-04-16). They provide pixel-specific "what should this location look like right now?" context that the spatial-background features alone cannot capture, reducing false positives from locations with unusual emissivity or persistent thermal anomalies.

6.2 Training & Validation Strategy

Training uses time-reversed labeling: pixels that were later confirmed as fire by VIIRS are labeled positive in prior AHI frames where they appeared as thermal anomalies. This naturally creates training data from the "hard" period before a fire is obvious.

6.3 Probability Calibration

Raw Random Forest probabilities tend to be poorly calibrated (clustered near 0 and 1). We apply isotonic regression post-hoc calibration^[7] on a disjoint held-out 20% calibration split. The RF is trained on 80% of the data; the isotonic calibrator is then fit on the remaining 20% that the RF never saw during training. This honest separation prevents the calibrator from memorizing the RF's own training-set predictions, which previously compressed the calibrated score distribution into a near-step-function (every raw score above 0.74 mapped to calibrated ≥ 0.93, destroying downstream fusion's ability to discriminate). The v4 calibration fix reduced the fraction of scores pinned at ≥ 0.99 from 8.8% to 0.9% on held-out data.

7. Bayesian Log-Odds Fusion

The fusion engine is the central integration point of the detection pipeline. Rather than cascading binary decisions (detect → confirm → score), every processing module contributes a continuous log-likelihood ratio (LLR) to a single fusion equation. The result is a calibrated fire probability with bootstrap confidence intervals. This section describes the fusion formula, the three block types, and how uncertainty propagates through the system.

7.1 Block Types

The fusion architecture distinguishes three kinds of blocks, each with a distinct mathematical role:

Prior Block

The prior $\ell_{\text{prior}}$ encodes the background fire rate in log-odds space, varying by geographic location, time of day, and season. It is learned from historical fire data and acts as the anchor for the fusion equation — all evidence is accumulated relative to this baseline. In fire-prone areas during peak season, $\ell_{\text{prior}}$ may be modestly positive; in urban or water areas, it is strongly negative.

Evidence Blocks

Evidence blocks observe the scene and produce LLRs quantifying how much more (or less) likely fire is given the observation:

Quality Blocks

Quality blocks assess observation reliability. They produce multipliers $q \in [0, 1]$ that dampen the evidence terms when conditions degrade, without themselves claiming fire or not-fire:

7.2 The Anchored Logistic Combiner

All blocks feed a single fusion equation in log-odds space:

Why log-odds? In log-odds space, independent evidence is additive. This makes the fusion equation a linear model over LLRs, which is both interpretable and computationally trivial. The quality multipliers $q_{\text{cloud}} \cdot q_{\text{SZA}}$ apply as a single scalar gate on the per-frame evidence group, dampening all three per-frame terms equally when observation quality is poor.

7.3 Uncertainty Propagation

The fusion engine does not produce a single point estimate; it produces a probability with a confidence interval derived from bootstrap resampling:

The confidence interval captures uncertainty from two sources: (a) finite training data for the RF and trajectory classifiers, and (b) estimation noise in the quality block parameters (cloud model, SZA ramp). It does not capture model misspecification — if the fusion equation itself is wrong, the CI will not help. However, because the equation is anchored to a learned prior and all terms are calibrated independently, this structural risk is mitigated.

8. Multi-Sensor Fusion & Event Management

All detections — from GOES contextual detection, CUSUM temporal detection, DEA Hotspots, or FIRMS — feed into a shared event store. The fusion system handles deduplication, spatial association, and progressive confidence upgrading.

8.1 Spatial Association (Haversine Distance)

Detections are associated with existing events using the Haversine great-circle distance formula:

A new detection is associated with the nearest active event within a 25 km radius. If no event is within range, a new event is created with PROVISIONAL status. When a detection is associated with an existing event, the event centroid is updated as a running average weighted by detection count.

8.2 Confidence Ladder

Events progress through a rule-based confidence ladder. Confidence only upgrades, never downgrades — once confirmed, an event stays confirmed. Downward transitions (closure and retraction) are handled separately by the Bayesian closure model (Section 8.4).

A temporally distinct pass is defined as a detection separated from the previous one by more than 30 minutes. Multiple detections within a 30-minute window (e.g., several pixels in one AHI frame) count as a single pass. This ensures that promotion requires evidence of persistence across observation cycles, not just spatial extent within one frame.

8.3 Portal Display Labels

The dispatcher portal uses its own satellite-detection labels that describe Embersat's confidence in the detection. These are not public agency alert levels (Advice, Watch and Act, Emergency Warning), which carry legal and operational weight that satellite detection alone cannot justify. Embersat never auto-assigns agency alert levels; those are displayed only when sourced from an actual agency feed match or dispatcher confirmation referencing one.

8.4 Bayesian Closure Model

Event closure uses a time-integrated Bayesian model that accumulates evidence from post-detection observations. Each clear-sky AHI frame or LEO overpass that does not detect fire contributes negative evidence; any re-detection resets the integration window.

where:

• $\eta_{\text{prior}}$ is a fixed log-odds prior that depends on the event's status at the time of last detection (see table below)
• $r = 0.03$ is the evidence accumulation rate
• $f(t)$ is the pipeline's fire probability at each observation time
• $\omega(t)$ is a diurnal weight: 1.0 during the day (solar zenith angle ≤ 80°), 0.7 at night (SZA ≥ 90°), linearly interpolated in between
• $\eta_{\text{FRP}}$ is an optional FRP trend contribution (negative when FRP is declining relative to peak)

The event closes when $P(\text{active}) < \theta_{\text{close}}$ (default 0.1). The distinction between RETRACTED and CLOSED depends on the event's status at the time of closure: PROVISIONAL events are retracted (likely false positives), while events that had reached LIKELY or higher are closed (real fires that have gone out).

9. Location Uncertainty

Every fire event is displayed with an uncertainty circle representing the estimated spatial accuracy of the detection. The uncertainty radius depends on the sensor(s) that contributed to the event and the number of independent detections.

9.1 Sources of Geolocation Error

Uncertainty in fire location arises from several sources:

1. Pixel size: Fire can be anywhere within the sensor pixel. GOES ABI pixels are ~2 km at nadir at Northern Arizona viewing angles (near sub-satellite point). VIIRS I-band pixels are 375 m at nadir.
2. Geometric registration error: Systematic and random errors in satellite attitude and orbit knowledge. GOES-18 ABI has a navigation accuracy of ~0.5–1.0 km (1σ).^[8]
3. Sub-pixel fire location: The fire is typically not at the pixel center. Without sub-pixel retrieval, the fire position uncertainty is approximately the pixel radius.
4. Viewing geometry: Geostationary sensors view at oblique angles, increasing the effective ground footprint. At Northern Arizona latitudes, the GOES-West view zenith angle is relatively small, expanding the pixel by a factor of approximately $1/\cos(\text{VZA})$.

9.2 Uncertainty Calculation

Initial uncertainty is set based on the detecting sensor. When multiple sensors contribute to the same event, the tighter constraint is used:

When a higher-resolution sensor (e.g., VIIRS) constrains a detection originally from GOES, the uncertainty radius is reduced to reflect the tighter localization. Multiple concordant detections further reduce uncertainty following $\sqrt{n}$ scaling:

9.3 Circle Geometry for GeoJSON Export

Uncertainty circles are represented as GeoJSON Polygons using an equirectangular approximation:

10. Cloud Masking

Cloud masking is essential to prevent thermal artifacts at cloud edges from generating false fire detections. Rather than a binary threshold, the system uses a 3-state probabilistic cloud model that classifies each pixel as Clear, Edge, or Opaque and produces a continuous quality score $q_{\text{cloud}} \in [0, 1]$ for the fusion engine.

10.1 Three-State Cloud Classification

The cloud model uses a binned Naive Bayes classifier with four spectral inputs:

Each feature is discretized into learned bins, and class-conditional probabilities are estimated with Dirichlet smoothing ($\alpha = 1$) to handle sparse bins without overfitting:

10.2 Cloud Quality Score

The three-state posterior is collapsed to a single quality score for the fusion engine:

The quality score enters the fusion equation (Section 7) as a multiplicative gate on the per-frame evidence terms. When $q_{\text{cloud}} \approx 0$ (opaque cloud), per-frame evidence is nearly zeroed out but the prior and trajectory terms still contribute. When $q_{\text{cloud}} \approx 1$ (clear sky), evidence passes through at full weight.

10.3 Cloud Adjacency

In addition to the per-pixel cloud quality score, the system computes a spatial context feature: the fraction of neighboring pixels (in a 5×5 window) classified as Edge or Opaque. This neighborhood cloud fraction is included as an input to the RF pixel scorer, allowing the classifier to learn that thermal anomalies surrounded by cloud are less likely to be fire.^[2] Unlike the previous morphological dilation approach (which created a hard buffer zone), this is a soft, learned integration of spatial cloud context.

11. Sun Glint Detection

Specular reflection of sunlight from water surfaces (sun glint) can produce elevated 3.9 μm brightness temperatures that mimic fire signals. The system computes the sun glint angle for each pixel — the angular separation between the satellite viewing direction and the specular reflection direction:

Pixels with $\Theta_{glint} < 12°$ during daytime are flagged as being in the glint zone. Rather than rejecting these pixels outright (which would create detection gaps near water bodies), the system downgrades their confidence from NOMINAL to LOW. This preserves the ability to detect fires near coastlines and rivers, while flagging them for additional scrutiny.

12. GeoJSON Export & OGC Compliance

All fire event data is exported in GeoJSON format following RFC 7946.^[9] Key compliance features:

• Coordinate order: $[\text{longitude}, \text{latitude}]$ per RFC 7946 convention.
• CRS: Always WGS84 (EPSG:4326). No crs member per RFC 7946 (WGS84 is assumed by default).
• Geometry types: All outputs use simple Point geometry for maximum AGOL/QGIS compatibility. Daily reports include an uncertainty_circle property containing the uncertainty polygon as a GeoJSON Polygon object (32 vertices).
• Timing provenance: Each event includes imagery_acquired_utc, data_downloaded_utc, classified_utc, end_to_end_latency_s, and processing_latency_s to enable latency auditing.

Daily reports are generated automatically at 18:00 MST and include all active and historical events for the day.

13. Values at Risk & Residential Proximity

For each detected fire, the system assesses values at risk: residential proximity, critical infrastructure, and community assets within defined distance bands. This information appears in the dispatcher portal alongside detection data, providing operational context for resource allocation decisions.

13.1 Residential Address Layer (G-NAF)

Residential proximity is computed from Australia's Geocoded National Address File (G-NAF), the authoritative geocoded address database maintained by Geoscape and published quarterly on data.gov.au under CC BY 4.0. The February 2026 release contains 15.86 million addresses nationally.

We extract 4,025,394 NSW residential addresses by filtering on three criteria:

1. STATE = NSW (geographic scope)
2. ALIAS_PRINCIPAL = P (principal addresses only, avoiding alias duplicates)
3. MB_CATEGORY_2021 = Residential (ABS mesh block land-use classification, joined via the MB_2021_PID field linking each G-NAF address to its 2021 Census mesh block)

The resulting coordinates are stored as a compressed float32 array (14.9 MB) and loaded into a scipy cKDTree spatial index at startup. The KD-tree operates in an approximate Euclidean coordinate system (latitude scaled by 111 km/deg, longitude scaled by 111 × cos(33°) km/deg, matching mid-NSW latitude) with a 5% safety margin on query radius to account for the planar approximation at NSW's latitude extremes. Candidate points returned by the KD-tree are refined with exact Haversine distances.

Per-fire queries count addresses in three distance bands: <2 km, <5 km, and <10 km. Typical query time is 0.2 ms (sub-millisecond), adding negligible overhead to the detection pipeline.

13.2 Critical Infrastructure & Community Assets

Nine GeoJSON asset layers are indexed using Shapely 2.0 STRtrees for O(log n) spatial queries:

Point assets use Haversine distance; line assets (transmission corridors, pipelines) use nearest-point-on-line distance. Assets are weighted by importance (0–9) and distance band (1.0 within 2 km, 0.7 within 5 km, 0.4 within 10 km).

13.3 Composite VaR Scoring

The composite Values at Risk score (0–9 scale) aggregates five category groups using weighted maximum scores:

The residential score uses a log₁₀ transform of the G-NAF address count within 5 km, scaled to 0–9: a fire with 10 nearby residences scores 2.25, 100 residences scores 4.5, and 10,000+ residences scores 9.0. This provides discrimination across the full range from remote bushland to dense suburban areas. Fire radiative power (FRP) optionally scales the hazard weight.

The composite score maps to priority labels: Critical (≥7.0), High (≥4.5), Moderate (≥2.0), Low (<2.0).

14. Dispatch Alert Review

Before any detection reaches a dispatcher's inbox, it passes through an LLM-based alerter agent that investigates the event using the same data a human would review: the multi-frame pixel timeline, thermal values relative to background, retraction history at the pixel location, current fire weather, infrastructure and population exposure (VaR), and any prior alerts already sent for this event.

14.1 Architecture

The alerter runs as a host-level daemon (event-reviewer.service) that polls the alert queue every 60 seconds. When the in-app characterization cycle promotes an event above the VaR or TTI threshold, a row is enqueued in the agent_alerts table. The daemon claims pending rows, invokes a Claude agent (currently Opus) with bypassPermissions mode and full tool access to the detection database, and captures the agent's structured JSON verdict.

Each evaluation typically requires 11–14 agent turns and 100–210 seconds. The agent uses CLI tools to query per-pixel observation timelines, check retracted-event history within a configurable radius, retrieve fire weather (FFDI, wind, humidity), and compute derived quantities like time-since-last-detection before producing a verdict.

14.2 Decision Factors

The agent produces a structured data_story alongside every verdict, documenting the factors it weighed and their relative influence on the decision. Common decisive factors include:

• Signal trajectory: Is fire probability rising, stable, or collapsed? If the signal has been below detection threshold for multiple consecutive frames, the event is no longer actionable regardless of its historical peak.
• Thermal physics: Is $T_{3.9}$ above or below the spatial background? Pixels colder than their surroundings at 3.9 μm are physically incompatible with combustion. The agent applies this check as a hard negative signal.
• Spread-rate plausibility: Is the characterized spread rate compatible with the observed wind speed and FFDI? Spread rates exceeding 3× the wind speed at low FFDI are flagged as pixel-noise artifacts rather than real propagation.
• Retraction history: How many prior events at this location have been retracted? Chronic false-alarm hotspots (e.g., urban-bushland interfaces, coastal thermal gradients) are suppressed unless the current signal shows qualitative differences from prior false alarms.
• Actionability: Would a dispatcher receiving this alert have a meaningful action to take? A 30-minute-dead event at FFDI 1 with 3 km/h wind does not warrant interrupting a human, even if the fire was real at peak.

14.3 Fatigue Management

The alerter tracks prior alerts for each event and globally. Duplicate alerts for stable fires are suppressed: if a WATCH-level email was sent 2 hours ago and conditions have not materially escalated, the agent declines the re-trigger with explicit reasoning. A per-event cooldown (configurable, default 120 minutes) prevents email storms during extended events. Over the competition window, the system has evaluated over 1,400 alert candidates. Of those, roughly 1 in 12 has been deemed send-worthy. The other 11 are declined with written reasoning retained for audit.

15. Fire Characterization

Once an event is created and tracked, a background characterization loop (every 15 minutes) computes operational metrics that inform the dispatch alert system and the daily report. Characterization is modular: each dimension is a standalone module registered in a module registry.

15.1 Intensity (FRP)

Fire radiative power (FRP) is estimated from the excess $T_{3.9}$ signal above background using the Wooster et al. (2003) method adapted for Himawari AHI geometry. Multiple FRP estimators are available through a module registry (Dozier bi-spectral, MIR-radiance, empirical VIIRS-scale); the production system uses MIR-radiance as the default. FRP is reported as a point estimate with confidence interval derived from the estimator's calibration uncertainty. Intensity classes (low / moderate / high / extreme) are assigned based on the FRP point estimate.

15.2 Spread Rate & Direction

Spread rate is estimated from the weighted centroid displacement between successive AHI frames (10-minute cadence). The centroid is weighted by per-pixel fire probability. Spread direction is the bearing of the displacement vector. Because AHI pixels are ~2 km, the minimum resolvable centroid shift is approximately 200 m per frame (subpixel precision from probability weighting), corresponding to a floor of ~1.2 km/h. Spread rates below this floor are reported as "stationary." Rates exceeding 3× wind speed at the current FFDI are flagged as potentially unreliable (pixel noise rather than real propagation).

15.3 Time-to-Impact (TTI)

Time-to-impact estimates how long until a fire's leading edge reaches a protected asset (school, hospital, fire station, transmission line, residential cluster) given the current spread vector. TTI is computed as $d / v$ where $d$ is the distance from the event centroid to the nearest asset along the spread direction, and $v$ is the observed spread rate. TTI is reported alongside the asset name and category, and drives the urgency classification in the dispatch alerter. TTI estimates inherit the uncertainty of the spread rate; they are suppressed in dispatch alerts when the underlying signal has collapsed (see Section 14.2).

16. Per-Pixel Fire Tracking

Since mid-April 2026, fires are tracked at the pixel level, not just the event-centroid level. Each fire event maintains a registry of individual AHI grid cells (row, col) that have been flagged as fire detections. This pixel registry drives three key behaviors:

1. Per-pixel observations: Every 10-minute AHI frame records an observation for each active fire pixel in each tracked event, regardless of whether fire is re-detected. This produces a continuous timeseries per pixel that the Bayesian closure model (Section 8.4) uses to estimate $P(\text{active})$ per pixel.
2. Per-pixel closure: An event closes only when all of its registered pixels have $P(\text{active}) < \theta_{\text{close}}$. This prevents premature closure when one edge of a multi-pixel fire has gone out while another is still burning.
3. Detection deduplication: The unique constraint on observations is (event_id, obs_datetime, pixel_row, pixel_col), ensuring that each pixel-frame combination is recorded exactly once even when multiple data sources report the same pixel.

Band-gap observations (frames where AHI data is unavailable due to maintenance or incomplete S3 delivery) and LEO-sensor observations (VIIRS, MODIS) use sentinel pixel coordinates (pixel_row=-1, pixel_col=-1) to record event-level evidence without attributing it to a specific AHI grid cell.

17. Known Limitations

1. ABI spatial resolution: At ~2 km pixel size over Northern Arizona, fires smaller than approximately 200–500 m² produce BTD anomalies below the detection noise floor for single-frame contextual detection. The CUSUM temporal detector partially mitigates this by accumulating evidence over multiple frames.
2. Cloud model scope: The 3-state probabilistic cloud model uses four spectral features but does not incorporate visible-band reflectance (unavailable at night) or temporal cloud tracking. Multi-spectral cloud masks (e.g., CLAVR-x) with more input channels may achieve better thin cirrus discrimination. However, the quality-block architecture means cloud classification errors degrade evidence weight rather than causing hard misclassification.
3. Sub-pixel fire characterization: The Dozier bi-spectral inversion for sub-pixel fire area and temperature^[10] has been tested but produces physically plausible solutions for only ~4.5% of AHI fire pixels (Z₁₁ pre-screening per Giglio & Schroeder^[1]). It is documented for future integration as a temporal consistency feature.
4. Location uncertainty model: The $\sqrt{n}$ scaling assumes independent, identically distributed detection errors. In practice, systematic biases (e.g., consistent view angle effects) limit the actual uncertainty reduction. Floor values mitigate this.
5. FIRMS latency: The FIRMS NRT product has ~3 hour latency, making it useful only for retroactive confirmation, not rapid detection. DEA Hotspots (~17 min) is the faster LEO confirmation source.
6. Night detection difficulty: At night, background BTD approaches zero for AHI pixels (no reflected solar in the MIR band), making BTD-based detection less discriminative. The night BT7-only detection path was tested but produced excessive false alarms from coastal and urban thermal anomalies; it is currently disabled pending RF classifier deployment.
7. Absolute BT14 thresholds cannot gate fire detection at geostationary resolution: It is tempting to propose an absolute lower bound on B14 (11.2 μm longwave IR) as a physics floor for fire pixels — e.g., "real fires must have B14 ≥ 305 K." This approach fails at Himawari AHI's 2 km pixel size because fire signal lives in B07 (3.9 μm), not B14. The Planck function at 11 μm has approximately 5,600× weaker temperature sensitivity to fire-temperature hot spots than at 3.9 μm. Dozier sub-pixel radiative transfer^[10] shows that a 1000 K fire occupying 0.01% of a 2 km pixel contributes only ~0.3 K to integrated B14 — well inside sensor noise — while contributing ~4–6 K to integrated B07. A 1 ha fire pushes B14 from 290 K ambient to only ~294 K; a 305 K B14 requires roughly a 4 ha fire, which rejects most early-stage ignitions. Empirically, against a 2.7M-detection production database on 2026-04-14, 95.8% of MONITORING (confirmed-real) events had max(B14) < 305 K, with a median B14 of 287.5 K and range 280–313.7 K. Detection must therefore rely on anomaly-relative features (B07 sigma deviation, BTD sigma deviation, CUSUM z-scores on BTD) and on persistence over multiple frames, not absolute temperature. Contextual Kaufman/Giglio/Maeda algorithms all use B14 strictly as a background reference and cloud mask, never as a detection gate. See docs/detection-knowledge-base.md § "Why BT14 absolute thresholds don't work at AHI 2 km resolution" for the full analysis and Dozier mixed-pixel table.

18. References