[Fase 2e] Wildfire: challenger ML (RF/XGBoost) con feature FIRMS + FWI, CV spaziale e promotion gate

[gzileni]

Contesto

Il piano wildfire prevede un motore V1 deterministico (FWI, #61) con fattori statici (#62). Come per le frane, la V1 resta champion e un challenger ML la sfida sul backtest — la pipeline esiste già tutta: feature store con CV spaziale a blocchi, MLflow, promotion gate operator-driven, shadow executor che non muta mai lo stato. Questa issue definisce il challenger incendi riusando quella infrastruttura, con le feature FIRMS/FWI.

Algoritmi candidati (letteratura mediterranea, in ordine di priorità):

1. Random Forest / XGBoost — costantemente i migliori nella wildfire susceptibility mediterranea; SHAP già in stack per la spiegabilità del breakdown.
2. Regressione logistica — baseline obbligatoria per il gate (come Caine per le frane).
3. MaxEnt — riferimento per dati presence-only; in pratica RF con background sampling ben fatto lo eguaglia: usarlo come confronto metodologico, non come dipendenza nuova.
4. ConvLSTM / U-Net spaziotemporali — esplicitamente fuori scope (V2+): costo/complessità non giustificati prima che il challenger tabellare batta la V1.

Design

1. Feature (estensione CANONICAL_FEATURES, gruppo nuovo fire.*)

• Statiche: fire.density_hist (da archivio FIRMS), fire.fuel_class_norm, fire.wui_proximity_norm (da [Fase 2b] Wildfire: fattori statici (CORINE fuel, WUI), workflow MAF e backtest su perimetri EFFIS #62), riuso slope_deg.
• Dinamiche (replay offline, come le feature pioggia CERRA): fire.fwi, fire.isi, fire.dc al giorno di valutazione (da [Fase 2a] Wildfire: motore FWI (Fire Weather Index) puro + wildfire.yaml #61: stato ricorsivo ricostruibile via fwi-backfill), rain.rain_30d_mm riusata.
• Enricher dedicato stile rain_features.enrich_rain_features (idempotente: aggiorna solo righe senza blocco fire); proiezione serve-time in ml_engine._bundle_to_feature_row per la parità train/serve; feature mancanti ⇒ 0.0 (comportamento esistente).
• Nomi aggiunti in coda a CANONICAL_FEATURES per non invalidare i run frana esistenti — oppure, se il refactor [Fase 1] Refactor hazard-agnostic: hazard_type, registry dei motori, YAML per hazard #57 introduce feature-list per hazard, lista separata wildfire: decidere lì, questa issue si adegua.

2. Training e labels

• Positivi: fire_events clusterizzati dagli hotspot FIRMS ([Fase 2d] Wildfire: archivio storico FIRMS (2000–oggi) — densità per cella e truth set per backtest/ML #66); campionamento case-control per le pseudo-assenze (stesso schema frane: stessa cella in giorni senza fuoco + celle mai bruciate, bilanciamento in YAML).
• CV spaziale a blocchi obbligatoria (round-robin sui blocchi in gradi, split_block assegnato all'estrazione) — nessuno split casuale, il leakage spaziale negli incendi è severo (ricorrenza sulle stesse celle).
• Stagionalità: valutare anche uno split temporale bloccato (train ≤ anno X, test > X) come sanity check accanto alla CV spaziale.

3. Gate e shadow (regole invariate)

• Metriche: AUC-PR, Brier + hit rate / FAR / lead time sul backtest wildfire di [Fase 2b] Wildfire: fattori statici (CORINE fuel, WUI), workflow MAF e backtest su perimetri EFFIS #62; il challenger deve battere la baseline FWI-only (motore V1 di [Fase 2a] Wildfire: motore FWI (Fire Weather Index) puro + wildfire.yaml #61) su tutti i floor.
• Promozione solo manuale (mlflow models transition-stage); shadow scrive in model_runs con hazard_type='wildfire' (colonna da [Fase 1] Refactor hazard-agnostic: hazard_type, registry dei motori, YAML per hazard #57), mai su cell_results/alert.

Acceptance criteria

• Estrazione feature idempotente; matrice di training riproducibile (stessi input ⇒ stesso SHA della matrice).
• Report MLflow con confronto RF/XGBoost/logistica vs baseline FWI-only sulla stessa partizione CV.
• SHAP summary per il modello candidato (top feature con segno atteso: FWI, fuel, densità storica).
• Shadow wildfire attivo senza impatto sugli assessment champion (test di non-mutazione).
• make check verde.

Dipendenze e relazioni

• Dipende da: [Fase 1] Refactor hazard-agnostic: hazard_type, registry dei motori, YAML per hazard #57 (hazard_type nel feature store / model_runs), [Fase 2a] Wildfire: motore FWI (Fire Weather Index) puro + wildfire.yaml #61 (FWI + backfill), [Fase 2b] Wildfire: fattori statici (CORINE fuel, WUI), workflow MAF e backtest su perimetri EFFIS #62 (fattori statici + backtest), [Fase 2c] Wildfire: integrazione NASA FIRMS — ingest hotspot NRT e trigger event-driven #65 e [Fase 2d] Wildfire: archivio storico FIRMS (2000–oggi) — densità per cella e truth set per backtest/ML #66 (labels e densità storica).

Riferimenti

• Pipeline esistente: src/limen/ml/ (feature_store, dataset.CANONICAL_FEATURES, train._check_promotion, shadow_challenger).
• Letteratura: rassegne su ML per wildfire susceptibility nel Mediterraneo (RF/XGBoost vs MaxEnt vs logistica); Van Wagner (1987) per il FWI.

[gzileni]

Correzione: EFFIS non richiede accreditamento

La conclusione scritta qui era sbagliata, e me ne assumo la responsabilità: il 403 che avevo osservato era la risposta a una richiesta malformata, non un rifiuto di autorizzazione.

maps.effis.emergency.copernicus.eu è un MapServer, e il nostro client gli parlava dialetto GeoServer. Tre errori insieme, ognuno dei quali basta a produrre silenzio:

	avevamo	corretto	come falliva
path	/gwis/ows	/gwis	va in timeout, non 404
layer	effis:ba.fires	nrt.ba.poly	MapServer chiude la connessione a metà risposta
filtro date	CQL_FILTER	filtro locale	parametro proprietario GeoServer: ignorato in silenzio

Corretto in #98 (merge 6725dba). Verificato: WMS GetCapabilities risponde 200 con 220 KB, nrt.ba.poly restituisce GeoJSON senza credenziali, e la storia completa di un'AOI è una risposta sola (Basilicata: 515 perimetri 2012-2026, 305 KB).

Per questa issue: il truth set per il challenger ML c'''è. Misurato sulla Basilicata con il motore deterministico attuale, come baseline che il challenger deve battere:

stagione	celle bruciate	hit rate	tasso di base	discriminazione	preavviso
2024	51	100 %	27.7 %	3.61×	52.2 h
2025	224	79.0 %	43.4 %	1.82×	59.0 h

Nota metodologica per chi imposterà il confronto: l'''hit rate da solo non è un criterio. Un modello che dichiara pericolo alto tutti i giorni d'''estate lo massimizza senza discriminare. Il rapporto con il tasso di base è la metrica da battere, e il FAR va misurato sull'''intera griglia — cosa che questo replay non fa, perché guarda solo le celle che hanno bruciato.