What this page is. An honest log of PHOENIX's own processing-time observations against the same SEVIRI / VIIRS / MODIS / SLSTR / VVF / ANSA feeds that everyone else also uses. Every number here is something we observed about our own pipeline, not a comparative claim about anyone else's. The feeds we name are not competitors — they are the indispensable ground truth that makes PHOENIX possible. Without FIRMS, EUMETSAT, the Vigili del Fuoco, and ANSA, PHOENIX has nothing to verify against.
Free, geostationary thermal feeds like SEVIRI (15-min cadence) sit unread for hours in most operational pipelines. Algorithmic processing of those feeds — sub-pixel temperature retrieval, temporal pattern learning, spatial neighbourhood context — may reduce the delay between sensor acquisition and human-actionable signal. We are running a 5-week field test in Sicily to find out whether this matters or not. The numbers below are what we have measured so far.
/event/<key> with full defensibility evidence.| Outcome family | PHOENIX-clustered first | Comparator-clustered first | PHOENIX first % |
|---|---|---|---|
| confirmed_burnscar | 1892 | 281 | 87% |
| confirmed_sar_change | 150 | 45 | 77% |
| confirmed_vvf | 29 | 147 | 16% |
Burn-scar and SAR-change confirmations skew PHOENIX-first because those methods are retrospective verifications of a fire that has already happened — by the time Sentinel-2 / Sentinel-1 passes overhead, PHOENIX's SEVIRI-derived candidate cluster has already been written to our DB. That's structural, not a quality claim about PHOENIX vs Sentinel. VVF (Vigili del Fuoco) cases skew the other way because firefighters standing next to the fire phone in the report before any satellite ever sees it — that is the natural floor and a strength of the operational human system, not a weakness of any satellite feed.
| Outcome | Events |
|---|---|
| comparator strictly earlier | 2 |
| PHOENIX strictly earlier | 8 |
Race-strict requires the comparator to have been physically capable of observing this fire (within revisit + cloud-cover constraints). The sample is small because most events do not yet have a capable comparator overhead within the matching window. Conclusions about minute-level lead require many more measurements; we will not make any until n > 100.
| Comparator | n matches | Avg gap vs sensed (min) | Avg gap vs reported (min) | PHOENIX earlier in our reconciler |
|---|---|---|---|---|
| firms_viirs_noaa21 | 4 | 22.1 | 186.6 | 4 |
| mtg_af_l2 | 2 | 17.9 | 39.3 | 2 |
| firms_viirs_snpp | 2 | 13.8 | 131.8 | 2 |
| firms_viirs_noaa20 | 2 | 8.8 | 136.9 | 2 |
"Sensed" = comparator's sensor-acquisition timestamp. "Reported" = comparator's public feed publish timestamp. The reported-gap is often dominated by upstream feed-processing delays that have nothing to do with the underlying sensor or operator — for example, FIRMS publishes VIIRS hits with a 30-90 min processing lag that the satellite operator doesn't control. We measure both because both matter to a downstream consumer.
Every event PHOENIX surfaces has a full evidence record at
/event/<event_key>. That page shows: every model score
(transformer, ensemble, calibrated), N1 adaptive-clustering tier, N3
SAR-silence refutation, the full list of corroborating sources and their
timestamps, race-strict timing context including whether a capable
comparator was overhead, the calibration version + sample size used to
produce the displayed probability, and the t72h / t14d / t45d outcome
chain as it evolved. We do not surface a number on this site without a
clickable trail to the evidence behind it.
GET /api/sole_reporter — live JSON of all events currently in
sole_reporter_alert='active'. Each entry includes a
defense_url pointing to the per-event evidence page. Use this
only for exploratory work; treat every entry as a candidate pending
comparator corroboration, not as a confirmed fire.
[email protected] — corrections will be filed publicly
within 48 hours.