Un sistema di monitoraggio visivo per incendi boschivi e confondenti vulcanici, guidato da dati pubblici, per la Sicilia / l'Etna

Un'architettura detector-first, con veto VLM e corroborazione multi-feed, valutata con onestà operativa

Autore: Mark Ludwikowski <markl02us@yahoo.com> Deliverable: ADRIZ → INGV (Istituto Nazionale di Geofisica e Vulcanologia), monitoraggio visivo dell'Etna Baseline di valutazione congelata: commit 4d1b0cca79bf396e99b9a49e8477ae3a36ecfd33 (4d1b0cc), branch master Finestra di verifica (UTC): 2026-06-29 ~02:31 → ~02:56 Etichette di classificazione operativa usate ovunque: LIVE_OPERATIONAL · LIVE_STALE · STAGED_NOT_LIVE · RESEARCH_ONLY · PLANNED · BROKEN_OR_BLOCKED · UNKNOWN_NEEDS_VERIFICATION

Disciplina probatoria (vincolante). Ogni affermazione quantitativa in questa tesi è riconducibile a un artefatto probatorio di Fase 1 committato in flank_wildfire/reports/thesis/. Nessun numero è inventato o attenuato. Dove l'evidenza è incompleta il testo lo dichiara esplicitamente, circoscrive l'affermazione o etichetta la metrica come UNKNOWN. Non si sostiene che il sistema risolva la rilevazione precoce degli incendi boschivi in generale; è un'architettura riproducibile e supportata da evidenze per il monitoraggio ambientale multi-sorgente, riportata con metriche detector-solo-contro-due-stadi, intervalli di confidenza, latenza, comportamento dei falsi positivi e dei falsi negativi, e modalità di guasto esplicite.

Sommario (Abstract)

L'Etna è uno degli ambienti più impegnativi al mondo per la rilevazione di incendi boschivi basata su telecamere: fianchi vegetati e popolati che bruciano realmente si trovano direttamente sotto un vulcano persistentemente attivo, i cui pennacchi di degassamento, colonne di cenere, incandescenza lavica ed eiezioni stromboliane sono confondenti visivi costanti, e la cui sommità è abitualmente oscurata da nubi meteorologiche e bagliore crepuscolare. Questo lavoro presenta e valuta ADRIZ, un sistema di monitoraggio visivo guidato da dati pubblici per il contesto Etna / Sicilia che combina quattro componenti: (i) una parete di telecamere che acquisisce molteplici sorgenti pubbliche di webcam e video istituzionali con una cadenza di 75 secondi a modello residente e reportistica onesta dello stato di salute per singola sorgente; (ii) un detector YOLO11s congelato (pesi sha256 c0a3d0ead257…cf0a20) che genera candidati per fotogramma; (iii) un veto semantico Qwen3-VL a livello di ritaglio (qwen3-vl-32b, temperatura 0.0) invocato solo sui ritagli caldi/luminosi instradati dal detector, reso sicuro per il recall di notte da un override durevole di corroborazione satellitare; e (iv) una plancia di dati pubblici a 64 feed con classificazione operativa dell'obsolescenza più uno strato di corroborazione satellitare/meteorologica/geospaziale per-classe (WF36).

Su una valutazione held-out e controllata per fughe di dati (RESEARCH_ONLY, n ridotto), il sistema a due stadi ha mantenuto il tasso di falso allarme vulcanico all'8.1% (5/62, CI Wilson al 95% [3.5–17.5%]) rispetto al 9.7% del detector da solo, preservando al contempo il 94.4% di recall diurno per incendi boschivi genuinamente visibili (17/18, CI al 95% [74.2–99.0%]). L'effetto misurato del veto è stato strettamente monodirezionale (McNemar b=2, c=0, p esatto=0.50, non significativo a questa numerosità campionaria): ha rimosso esattamente un falso allarme da artefatto del sensore e un fotogramma diurno borderline di luci a terra, e non ha migliorato alcuna decisione su incendio genuino. Di notte il veto inizialmente vetava due veri incendi di vegetazione la cui fiamma è single-frame indistinguibile dall'incandescenza lavica; una durevole guardia di sicurezza notturna ora trattiene il veto vulcanico su qualsiasi rilevazione notturna di classe incendio non corroborata (facendola emergere come uncertain_night anziché scartarla), portando il conteggio dei falsi negativi notturni silenti su incendio vero da 2 a 0 lasciando invariati i numeri diurni e il tasso di falso allarme vulcanico. Una traccia separatamente riportata di due-diligence quantistica ha rilevato, sulla stessa attività Etna vulcanico-contro-incendio, che i classificatori quantistici simulati sono battuti da baseline classiche appaiate con intervalli di confidenza che escludono lo zero (Q-kernel −0.099 [−0.161, −0.038]) — un risultato negativo pulito e pubblicabile, con l'unica genuina novità (inversione della sorgente vulcanica come QUBO) preservata come linea di ricerca, senza uso di hardware quantistico. Riportiamo il sistema con piena classificazione operativa, identifichiamo le limitazioni onestamente (3 telecamere su 5 online alla verifica, sette feed obsoleti, code di latenza non strumentate, dispatch degli allarmi staged-off) ed esponiamo le prossime direzioni di sviluppo: domain adaptation, fusione IR/termica, event tracking MTG-FCI e un VLM incendio/vulcano fine-tunato.

Capitolo 1 — Motivazione e problema

1.1 Rilevazione precoce degli incendi boschivi e il budget di falsi allarmi

La rilevazione precoce del fumo tramite telecamere fisse è una linea consolidata e operativamente preziosa. Govil et al. [1] hanno dimostrato, sulla rete di telecamere HPWREN / AlertWildfire della California meridionale, un sistema di deep learning che scansiona centinaia di telecamere ogni minuto e rileva il fumo tipicamente entro circa quindici minuti dall'innesco con meno di un falso positivo per telecamera al giorno. Quel risultato inquadra il problema che questo lavoro eredita: il valore della rilevazione non deriva dal recall da solo ma dal recall sotto un rigoroso budget di falsi allarmi. Un sistema di monitoraggio che lancia allarmi di continuo è operativamente inutile a prescindere dalla sua sensibilità, perché i revisori umani smettono di fidarsene. Dewangan et al. [2] (FIgLib / SmokeyNet) e il benchmark PyroNear-2025 [3] hanno stabilito che la rilevazione single-frame da telecamera satura sui confondenti e che l'attività resta difficile attraverso i domini delle telecamere — il che è esattamente il motivo per cui questo lavoro stratifica un veto semantico e una corroborazione multi-sorgente sopra un detector veloce, invece di affidarsi al detector da solo.

1.2 La Sicilia e l'Etna come ambiente di monitoraggio difficile

La Sicilia vive una severa stagione di incendi boschivi mediterranea; il suo territorio vegetato, inclusi i fianchi inferiori e medi popolati dell'Etna, brucia realmente. Il destinatario di questo sistema è l'INGV, l'istituto nazionale italiano di geofisica e vulcanologia, il cui interesse di monitoraggio dell'Etna copre sia l'attività vulcanica sia il rischio di incendio sui fianchi dell'edificio. La difficoltà definitoria è la co-localizzazione: un incendio di vegetazione sul fianco dell'Etna e l'attività termica e dei pennacchi del vulcano stesso occupano le stesse telecamere, gli stessi pixel satellitari e spesso lo stesso fotogramma.

1.3 Confondenti vulcanici e meteorologici

L'insieme dei confondenti all'Etna è insolitamente ricco e avversariale:

• Pennacchi vulcanici e degassamento — degassamento sommitale bianco/blu persistente e pennacchi di vapore fumarolico che, in un singolo fotogramma di telecamera, somigliano a colonne di fumo da incendio boschivo.
• Pennacchi di cenere e colonne eruttive — colonne episodiche e più scure che possono essere scambiate per fumo denso da incendio boschivo.
• Incandescenza lavica, fontane di lava, esplosioni stromboliane, eiezioni incandescenti — sorgenti termiche rosse/arancioni luminescenti la cui apparenza single-frame è quasi identica a una linea di fiamma di un incendio di vegetazione notturno. Questo è il singolo confondente più difficile del sistema e la fonte del suo unico residuo reale di recall (Capitolo 6).
• Nube e nebbia/foschia meteorologica che oscurano la sommità, e bagliore di tramonto/crepuscolo che dipinge luce calda, color fuoco, sull'edificio.
• Artefatti del sensore e della lente — striature verticali, lens flare e riflessi che un detector può racchiudere in un box come fiamma.

WARP [12] ha rilevato che sia i detector di incendi boschivi CNN sia quelli transformer non riescono a distinguere chiazze simili a nubi dal fumo reale sotto perturbazione avversariale locale; l'Etna fornisce naturalmente quell'insieme di confondenti avversariali, ogni giorno. Un sistema per questo ambiente deve quindi essere progettato attorno alla disambiguazione incendio-contro-vulcanico, non attorno alla rilevazione generica del fumo.

1.4 La necessità di un sistema multi-sorgente, a feed pubblici, a basso costo

Nessun singolo sensore risolve il problema dei confondenti. Una telecamera vede un pennacchio ma non può distinguere il fumo dal vapore alla sommità; un prodotto termico satellitare vede il calore ma a un pixel molto più grossolano della regione di interesse della telecamera e non può distinguere un incendio di fianco dalla lava di cratere quando il calore è sul cratere; un sensore di gas o una retrieval di SO₂ supporta una lettura "vulcanica" ma è una colonna atmosferica grossolana, non una prova dell'evento a livello di pixel. L'architettura che questa tesi valuta tratta quindi il problema come un sistema di sorgenti di dati pubblici indipendenti — rilevazione di candidati da telecamera, ragionamento semantico VLM e corroborazione satellitare/meteorologica/geospaziale — costruito interamente da feed pubblici e calcolo commodity a basso costo (un detector su workstation locale più inferenza VLM serverless remota; non si assume hardware edge, Hailo o DGX). Il contributo è l'integrazione riproducibile e operativamente onesta di queste sorgenti, con ogni componente classificato secondo il suo vero stato operativo.

Capitolo 2 — Lavori correlati

Questo capitolo colloca ogni scelta progettuale nella letteratura attuale e verificata. Ogni riferimento è stato confermato come esistente contro arXiv, l'editore, IEEE/ScienceDirect o l'indice papers di Hugging Face prima della citazione; tutti i 35 riferimenti sono VERIFIED (i due a maggior posta in gioco, SmokeBench [7] e FCI-FireDyn [26], sono stati indipendentemente ri-confermati a campione). I numeri tra parentesi quadre indicizzano la sezione Bibliografia.

2.1 Fondamenti della rilevazione di incendi boschivi / fumo basata su telecamere

La linea della parete di telecamere è definita da Govil et al. [1] (HPWREN/AlertWildfire, rilevazione in ~15 minuti, <1 FP/telecamera/giorno), Dewangan et al. [2] (le ~25.000 immagini etichettate di fumo da telecamera fissa di FIgLib e la CNN spaziotemporale SmokeyNet che sfrutta l'informazione fotogramma-a-fotogramma) e il benchmark PyroNear-2025 [3] (un dataset di telecamere geograficamente diversificato e ottenuto da web scraping, ~150k annotazioni su 640 incendi boschivi, che mostra come l'attività resti difficile attraverso i domini). Questi definiscono il compito dello stadio detector — generazione di candidati per fotogramma sotto un rigoroso budget di falsi allarmi — e motivano gli strati temporali e multi-sorgente aggiunti sopra.

2.2 Detector in stile YOLO e sfidanti transformer

Il detector incumbent è un modello single-stage di classe YOLO11s scelto per inferenza in tempo reale a modello residente. I detector più recenti sono trattati come direzioni future, non come requisiti: YOLOv12 [4] (centrato sull'attenzione, Area-Attention/R-ELAN, mAP migliorato a latenza comparabile ma con costi di instabilità in training/throughput su CPU); RT-DETR [5] (il primo detection transformer in tempo reale end-to-end e NMS-free, CVPR 2024); e per la generazione di candidati a vocabolario aperto, Grounding DINO 1.5 [6], in particolare la variante Edge ottimizzata per TensorRT (~75 FPS). La proprietà NMS-free di RT-DETR e la rilevazione open-set promptabile da testo di Grounding DINO Edge sono i due percorsi di upgrade più rilevanti per una parete di telecamere che deve aggiungere classi di confondenti senza riaddestramento completo.

2.3 VLM / MLLM per il fumo da incendio boschivo — forti semanticamente, deboli come localizzatori primari

Questa è la base probatoria centrale per la scelta detector-first + veto VLM. SmokeBench [7] (Qi, Li, Barnes; WACV 2026) valuta gli MLLM (Qwen2.5-VL, InternVL3, GPT-4o, Gemini-2.5 Pro, Grounding DINO, Idefics2, Unified-IO 2) su classificazione, localizzazione e rilevazione del fumo; il suo risultato principale è che i modelli possono spesso classificare il fumo di grande area ma faticano tutti con una localizzazione accurata, specialmente allo stadio precoce, con prestazioni fortemente legate al volume del fumo. I benchmark VLM di osservazione della Terra corroborano lo schema: GPT-4V-su-EO ("bravo a fare didascalie, scarso a contare") [8] e GEOBench-VLM [9] mostrano entrambi forte conoscenza di scena a risposta aperta ma scarsa localizzazione/conteggio spaziale (GPT-4o ~40% sui quesiti a scelta multipla di GEOBench-VLM, ~2× il caso). Questo supporta direttamente l'uso di un VLM non come localizzatore primario ma come veto semantico di secondo stadio su ritagli già localizzati — il regime in cui gli MLLM sono forti.

2.4 Detector-first + veto VLM contro monitoraggio VLM-only

Nessun singolo paper canonico nomina "detector-first + veto VLM per telecamere antincendio"; l'affermazione è supportata da evidenze verificate convergenti e ciò è dichiarato onestamente invece di attribuirlo a una fonte inventata. SmokeBench [7] e i benchmark EO-VLM [8,9] stabiliscono la debolezza di localizzazione dei VLM; la linea dei detector da telecamera [1,2,3] stabilisce che i detector single-stage veloci localizzano bene ma lanciano troppi allarmi sui confondenti. FireCLIP [10] è l'evidenza diretta più vicina al fatto che uno stadio vision-language aggiunga valore specificamente come discriminatore di falsi allarmi (fumo di cucina, emissioni industriali), riportando un miglioramento zero-shot ≥12.45% e una migliore generalizzazione regionale tramite prompt tuning. La decomposizione a due stadi — detector veloce per recall/localizzazione, VLM per precisione/veto semantico — è esattamente ciò che la valutazione WF25 (Capitolo 5) verifica empiricamente.

2.5 La progettazione dei prompt come componente di sistema valutato

FireCLIP [10] dimostra il prompt tuning come il meccanismo che fornisce i suoi guadagni su falsi allarmi e generalizzazione; TuneVLSeg [11] confronta il prompt-tuning testuale/visivo/multimodale sotto domain shift (i prompt testuali degradano sotto grande shift, il visual prompting è un primo tentativo competitivo ed economico); WARP [12] mostra che la progettazione adiacente a prompt/soglia controlla il punto operativo recall-contro-falsi-allarmi. Di conseguenza, i prompt del veto Qwen3-VL in questo lavoro sono versionati e congelati (Capitolo 3, model_prompt_freeze.json) e riportati come una variabile testata, non come un ripensamento.

2.6 Domain adaptation per reti di telecamere

Identificata come un probabile pilastro centrale del prossimo sviluppo. Fonti verificate: il detector di fumo UDA con allineamento multilivello delle feature MCAF [13]; EDIF [14] per la rilevazione cross-dominio potenziata del fumo da incendio boschivo con feature domain-invariant; uno studio UDA da sintetico-a-reale sulla rete AlertWildfire [15]; e Pesonen et al. [16] sulla supervisione zero-shot da foundation model per addestrare piccoli segmentatori da telecamera in tempo reale a partire da etichette box. Ogni telecamera ADRIZ (INGV, Windy, EtnaWalk) è un dominio visivo distinto (illuminazione, angolo, meteo, lo sfondo del pennacchio dell'Etna), il che circoscrive il piano di adattamento del Capitolo 7.

2.7 Robustezza e test avversariali / hard-negative

WARP [12] (Ide & Yang) è il primo framework model-agnostic per la robustezza avversariale dei modelli di rilevazione di incendi boschivi, iniettando rumore globale (gaussiano) e locale (patch PNG di nube); i transformer hanno mostrato >70% di degrado della precisione sotto rumore globale, e sia i modelli CNN sia i transformer non sono riusciti a distinguere chiazze simili a nubi dal fumo reale sotto attacchi locali. Questo è il modello per la batteria di hard-negative dell'appendice sui guasti (Capitolo 6) e la motivazione diretta dalla letteratura per il veto VLM + corroborazione satellitare come mitigazioni.

2.8 Fusione IR / termica (capacità futura)

Fonti verificate di fusione RGB-termica: un dataset multi-scenario da UAV RGB-Termico per incendi boschivi e relativo modello di fusione [17]; il modello di fusione RGB-T target-aware MCDet [18]; un metodo di rilevazione di fiamma visibile+infrarosso-termico [19]; e a livello VLM WildFireVQA [20], un grande benchmark VQA radiometrico-termico che rileva come l'RGB resti la modalità singola più forte per gli attuali MLLM mentre il contesto termico recuperato aiuta i modelli più forti. L'IR è direttamente rilevante per l'ambiguità lava-contro-fiamma dell'Etna, ma WildFireVQA mantiene onesta l'affermazione: il termico è un guadagno contestuale, non una modalità risolta per i VLM.

2.9 Tracciamento e segmentazione temporale di pennacchi con optical-flow

Per la coerenza temporale del moto del fumo e la segmentazione della crescita del pennacchio: un detector spaziotemporale di fumo precoce a bag-of-features che usa l'istogramma dell'optical flow orientato sfruttando la convezione termica verso l'alto [21]; rilevazione video spaziotemporale/a texture dinamica del fumo da incendio boschivo [22]; e per la segmentazione moderna, SAM 2 [23] (segmentazione video promptabile con memoria in streaming) più uno studio SAM2 specifico per il fuoco [24] (Box+MP migliore, mIoU ~0.64). La coerenza temporale è la mitigazione futura più promettente per il residuo incendio-notturno↔lava (la lava è stabile; l'incendio boschivo tremola e si propaga).

2.10 Corroborazione satellitare ed event tracking geostazionario (MTG-FCI)

La base geostazionaria dello strato di corroborazione. MTG-FCI rileva gli incendi ~4 h prima di SEVIRI, ~2 h prima di MODIS, e trova ~5× più pixel di fuoco attivo di SEVIRI [25]; l'algoritmo FCI-FireDyn / Fire-Event-Tracker [26] (Paugam et al., 2026) cluster spazio-temporalmente gli hotspot FCI a cadenza di 10 minuti per derivare mappe di arrivo del fuoco, tasso di propagazione ed evoluzione dell'area bruciata, validato su incendi del Sud Europa 2024–2025; uno studio di fattibilità [27] esplora la rilevazione non supervisionata di incendi boschivi da MTG-FCI. L'insistenza della direttiva sul fatto che FCI sia trattato come dato di event-tracking / candidato precoce, non come ground truth perfetta è qui fondata: il punto di forza di FCI è l'evoluzione temporale e la tempistica precoce, mentre il suo pixel di ~1–2 km lo rende troppo grossolano come ground truth a livello di evento da telecamera — esattamente l'etichettatura "supporta / troppo grossolano" che WF36 applica.

2.11 Corroborazione puntuale: FIRMS VIIRS/MODIS e Sentinel-3 SLSTR

Schroeder et al. [28] è l'algoritmo canonico di fuoco attivo VIIRS a 375 m alla base di NASA FIRMS; Xu & Wooster [29] descrivono il prodotto operativo SLSTR diurno di fuoco attivo / FRP con intercomparazione globale a MODIS/VIIRS/Landsat (prodotto diurno operativo da marzo 2022), basandosi sul lavoro algoritmico pre-lancio [30]. Questi forniscono i limiti di rilevazione pubblicati che giustificano la logica di corroborazione asimmetrica in WF36: un hotspot termico vicino a un candidato da telecamera eleva la confidenza, mentre l'assenza è trattata come non-disconfermante (il fumo precoce sub-pixel è sotto la soglia di rilevazione satellitare).

2.12 Sentinel-5P/TROPOMI e CAMS come evidenza contestuale di gas/pennacchio

Theys et al. [31] (degassamento globale di SO₂ vulcanico da TROPOMI), uno studio SO₂ specifico per Stromboli in Italia [32], e l'ATBD della retrieval SO₂ TROPOMI [33] ancorano lo strato di contesto gassoso. Il SO₂ TROPOMI supporta una classificazione di "degassamento vulcanico" ma la sua impronta grossolana e la cadenza degli overpass lo rendono contesto di supporto, mai prova dell'evento da telecamera a livello di pixel — l'etichettatura precisa che WF36 impone. CAMS/GFAS svolge il ruolo analogo di aerosol/emissione; TROPOMI è citato come l'àncora verificata e la prova a livello di evento specifica di CAMS è segnalata come solo-contesto.

2.13 Affidabilità operativa dei feed di dati e classificazione dell'obsolescenza

Questo è un contributo ingegneristico/operativo piuttosto che un risultato accademico, e ciò è dichiarato onestamente: è fondato sulla documentazione ufficiale — la documentazione di prodotto/latenza di NASA FIRMS [34] e la documentazione degli strumenti MTG di EUMETSAT [35] — che definisce le cadenze upstream rispetto alle quali sono derivate le soglie di obsolescenza. Il monitor di salute dei feed del sistema classifica ogni feed operativamente, con una guardia di risposta-degradata che assicura che un upstream degradato non possa spacciarsi per "live-con-zero".

Capitolo 3 — Architettura del sistema

Stato delle affermazioni di questo capitolo: ogni componente è etichettato con il suo stato operativo verificato da operational_state_verification.md e system_performance_spec.md, ri-verificato dall'evidenza corrente nella finestra 2026-06-29 02:31–02:56 UTC al commit 4d1b0cc.

3.1 Panoramica

ADRIZ è una pipeline a quattro strati:

  Sorgenti pubbliche di telecamere (5 configurate)
        │  ciclo a modello residente di 75 s
        ▼
  [Stadio 1]  detector YOLO11s  (congelato, sha256 c0a3d0ea…)
        │  box candidati per fotogramma, head a 19 classi
        ├── classi PASS_THROUGH (fumo / cenere / degassamento) ──────────┐
        │                                                                │
        └── classi ROUTE (lava / incandescenza / fiamma) ──► ritaglio caldo/luminoso
                                                                │
        ▼                                                       ▼
  [Stadio 2]  veto Qwen3-VL a livello di ritaglio (qwen3-vl-32b, temp 0.0)
        │  WILDFIRE | VOLCANIC | NEITHER   (+ override NIGHT-SAFETY)
        ▼
  [Stadio 3]  corroborazione multi-feed WF36  (FIRMS / SLSTR / FCI / SEVIRI / TROPOMI / CAMS)
        │  sul-cratere = vulcanico;  FIRMS fresco fuori-cratere = supporto indipendente all'incendio
        ▼
  [Stadio 4]  tassonomia degli allarmi + plancia salute-feed (64 feed) + dashboard bilingue

Il detector e il VLM girano live nel task pianificato EtnaCameraWall; la plancia dei feed si aggiorna ogni ora tramite EtnaFeedsRefresh. Entrambi i task erano Running alla verifica (schtasks /query @ 02:32 UTC). Stato: LIVE_OPERATIONAL per la pipeline in esecuzione; il dispatch degli allarmi è STAGED_NOT_LIVE (Sezione 3.8).

3.2 La plancia di dati pubblici a 64 feed e il monitoraggio della salute dei feed

La plancia dei data-feed inventaria 64 sorgenti pubbliche. Alla verifica (curl https://adr-etna-ingv.pages.dev/data/feeds.json @ 2026-06-29T02:31:33Z, HTTP 200), un riconteggio indipendente delle 64 voci a livello di gruppo ha corrisposto esattamente al riepilogo pubblicato:

Due garanzie ingegneristiche rendono questa una rivendicazione operativa difendibile piuttosto che un conteggio di vanità:

• Tassonomia onesta. I 7 feed stale e i 10 catalogued non sono dati live e non sono mai descritti come tali; la logica di corroborazione tratta un feed più vecchio della soglia di 24 h come nessuna evidenza corrente, mai come contraddizione.
• Guardia di degrado overpass (LIVE_OPERATIONAL). osm_roads_rail.py (L64–72, commit 4d1b0cc, originariamente 398e94d) applica una guardia di plausibilità: un conteggio strade vuoto/zero è segnalato stale con validated_pull=False, così che una risposta Overpass degradata non possa spacciarsi per live-con-uno-zero-fasullo. La lettura live corrente è 23.379 strade / 341 ferrovie → status=live.

Un valore numerico live rappresentativo è il Fire Weather Index: l'analisi FWI giornaliera EFFIS più recente (CEMS EWDS GEFF 4.1) alla cella di vetta dell'Etna era 13.06 (moderato) alle 02:31:33Z. Avvertenza onesta sulla latenza: l'analisi giornaliera GEFF 4.1 comporta ~3–4 giorni di latenza, quindi questa è l'analisi giornaliera più recente, non una lettura istantanea.

I sette feed obsoleti alla verifica sono fatti emergere come guasti, non nascosti (tabella completa nel Capitolo 6 / failure_appendix.md §8): cams_gfas_fire (archivio indietro di 208 giorni), effis_active_fire (guasto backend Oracle WFS di EFFIS, si auto-ripristina), era5_land (~5 giorni di latenza di produzione, obsoleto per progettazione), gwis (guasto backend Oracle WFS di JRC), ingv_oe_bulletin (nessun item Etna nell'RSS GVP di questa settimana), meteostat (ritardo dell'archivio bulk), opensky_adsb (rate-limit anonimo HTTP 429).

3.3 Acquisizione delle telecamere — inclusa la realtà multi-sorgente

Cinque sorgenti di telecamere sono configurate (/api/cams sources[] @ 2026-06-29T02:44:37Z): il mosaico INGV EtnaTVChn (garr.tv PeerTube HLS), tre webcam Windy (Milo East 9.1 km, Trecastagni 16.8 km, Catania Jonio 26.8 km dalla sommità) e lo stream live YouTube EtnaWalk. La parete esegue un ciclo a modello residente di 75 secondi (cadence_s:75, confermato sia in /api/cams sia nell'artefatto del publisher locale cameras_wall.json).

Avvertenza onesta multi-sorgente (la parete di telecamere non è "5 telecamere live"). Al timestamp di verifica solo 3 delle 5 sorgenti erano online (n_online:3) — le tre telecamere Windy (tutte CLEAR, DAY_RGB). Il mosaico INGV EtnaTVChn e lo stream EtnaWalk erano OFFLINE (online=False, badge OFFLINE). La parete riporta OFFLINE onestamente invece di servire un fotogramma congelato. Il fraseggio in tutta la tesi è quindi circoscritto a "5 sorgenti di telecamere configurate, 3 online al timestamp di verifica," mai "5 telecamere live". Stato: LIVE_OPERATIONAL (3/5 online); le due sorgenti OFFLINE sono un sotto-componente LIVE_STALE segnalato onestamente.

La rilevazione della salute delle telecamere è essa stessa una funzionalità LIVE_OPERATIONAL: per ogni sorgente online:false / badge OFFLINE è emesso veridicamente (multi_cam_service.py L251–261), e un watchdog di fotogramma obsoleto/congelato impone una guardia basata sull'età (STALE_FRAME_MAX_S = 1800 s). Un controllo per-fotogramma a perceptual-hash di fotogrammi identici (per intercettare una telecamera recente ma congelata) non è ancora implementato ed è in coda nella roadmap. L'endpoint /api/cams ha inoltre mostrato reset TLS transitori (due fetch su tre) durante la verifica prima di riuscire; il cameras_wall.json pubblicato localmente ha corroborato lo stesso contenuto. Questo è registrato come una segnalazione di monitoraggio (Capitolo 6), non come uno stop bloccante.

3.4 Il detector — YOLO11s congelato, provenienza esatta

Il detector di Stadio 1 è congelato per la tesi (decisione WF19 KEEP-INCUMBENT):

Il loop del detector a modello residente (multi_cam_task.py, PID 31700, ~308 MB residenti) era in esecuzione alla verifica. La head a 19 classi emette cinque bucket rilevanti per incendio/vulcanico; si noti che data.yaml mostra nc:5, che è stale — la head operativa è a 19 classi, confermata contro i pesi e service/config.py CLASS_NAMES. Stato: LIVE_OPERATIONAL.

Crucialmente, la classe del detector è usata per instradare:

• PASS_THROUGH (mai inviato al VLM in Config A): wildfire_smoke, ash_plume, forced_ashladen_degassing, fumarolic_steam, passive_degassing_steam. Il fumo è passato attraverso per preservare il recall degli incendi boschivi — un pennacchio grigio e distante non è rovente e non deve mai essere vetabile.
• ROUTE verso VLM: wildfire_flame, active_lava_flow, incandescent_ejecta, lava_fountain, lava_incandescence, strombolian_explosion. Le classi calde/luminose sono esattamente dove risiede la disambiguazione lava-contro-fiamma.

3.5 Veto Qwen3-VL a livello di ritaglio — modello, prompt e impostazioni esatti

Il veto di Stadio 2 è la configurazione esatta e congelata registrata in model_prompt_freeze.json (nessun risultato della tesi fa riferimento a "Qwen-VL" genericamente):

Due prompt sono congelati. Il CROP_PROMPT (disambiguazione caldo/luminoso, veto primario) istruisce esplicitamente il modello "Do NOT assume it is volcanic just because Etna is a volcano — vegetation wildfires occur on Etna's flanks," e forza una scelta uno-di-tre WILDFIRE / VOLCANIC / NEITHER (l'ultima copre bagliore di tramonto, nube illuminata dal sole, luci artificiali, lens flare, riflesso, artefatto del sensore). Il SMOKE_PROMPT (degassamento-contro-pennacchio, usato per fumo ambiguo grande/sommitale) distingue una colonna di incendio boschivo più densa e più bruna/grigia che si leva da terreno vegetato da un pennacchio di degassamento bianco/blu radicato al cratere e da nube/foschia diffusa estesa al cielo. Il testo esatto verbatim di entrambi i prompt è in model_prompt_freeze.json (vlm_prompt_exact_text_CROP_PROMPT, vlm_prompt_exact_text_SMOKE_PROMPT).

Il VLM è invocato solo su ritagli caldi/luminosi instradati dal detector: misurato a ~0.151 chiamate/fotogramma sul set held-out e 0 su fotogrammi quieti (vlm_call_rate), corroborato live da vlm_calls_this_cycle: 0 su un ciclo quieto. Questa è l'unica figura di prestazione sicura da classificare LIVE_OPERATIONAL per il tasso stesso. Stato: LIVE_OPERATIONAL (detector + crop-veto girano live in EtnaCameraWall; le metriche WF25 sono RESEARCH_ONLY).

3.6 L'override di corroborazione NIGHT-SAFETY

L'elemento progettuale più conseguente del veto VLM è il suo override di sicurezza notturna, una guardia durevole (non un caso isolato) in service/crop_veto.py + service/config.py. Esiste perché il prompt di contesto vulcanico che dà al sistema il suo basso tasso di falso allarme vulcanico è esattamente ciò che mis-instrada un incendio di vegetazione notturno luminoso — la cui fiamma è single-frame indistinguibile dall'incandescenza lavica — verso VOLCANIC.

Regola come implementata. Quando una rilevazione di classe incendio (wildfire_flame / wildfire_smoke) è instradata e il verdetto VLM la SOPPRIMEREBBE (VOLCANIC o NEITHER):

• Diurno (media grigia del pannello > NIGHT_PANEL_MEAN_MAX = 12): invariato — il recall diurno era già preservato; la confusione con la lava è un problema notturno.
• Notturno/termico (media grigia del pannello ≤ 12): la soppressione vulcanica è onorata solo se esiste una corroborazione vulcanica indipendente coerente con la bocca — FIRMS-SLSTR/FRP sul-cratere/prossimale-alla-sommità (firms_corroborated), oppure il ritaglio caldo si trova dentro la ROI sommitale (inside_summit_roi), riutilizzando la logica sul-cratere di WF36. In assenza di tale corroborazione l'allarme non è scartato silenziosamente: è declassato a uno stato WILDFIRE_UNCERTAIN_NIGHT / needs_review comunque fatto emergere (alert feed + tile).

Un vero incendio notturno fuori-cratere non può quindi mai essere cancellato dal VLM da solo. L'effetto ri-valutato è quantificato nel Capitolo 5: falso negativo notturno silente su incendio vero 2 → 0, diurno e FA vulcanica invariati. Stato: logica della guardia LIVE_OPERATIONAL (nel servizio live); la ri-valutazione WF25 che ne dimostra l'effetto è RESEARCH_ONLY.

3.7 Corroborazione multi-feed WF36

Lo Stadio 3 colloca un candidato in un contesto indipendente tramite service/corroboration.py (corroborate_decision, gate_alerts, _volcanic_scene), valutato contro uno snapshot live dei feed (snapshot_utc 2026-06-29T02:56:39Z). La logica di corroborazione implementa regole per le cinque classi del detector genuinamente corroborabili:

1. Fumo / fiamma da incendio boschivo. Prende firms_near_summit_km (minimo di VIIRS/MODIS freschi). Un hit nell'anello CRATER_KM(3) < near ≤ NEAR_SUMMIT_KM(15) → corroborato (segnale di incendio indipendente). Un hit ≤3 km è trattato come il vulcano stesso → non una conferma di incendio. >15 km o nessun FIRMS fresco → non corroborato; un granulo FRP fresco senza valore co-localizzato contribuisce solo con la recenza del granulo (supporta). Assunzione portante: FIRMS sul-cratere è vulcanico, non incendio — FIRMS non può distinguere la lava da un incendio sul cratere stesso. Poiché FIRMS/SLSTR hanno latenza dell'ordine delle ore, un vero incendio precoce sarà di routine non corroborato (allerta precoce camera-only), quindi il sistema deve lanciare l'allarme su alta confidenza detector+VLM in quella finestra invece di attendere il satellite.
2. Lava / incandescenza. FIRMS fresco sul-cratere (≤3 km), altrimenti FRP fresco, altrimenti copertura FCI fresca → corroborato come VOLCANIC con explains_volcanic=True, che sopprime qualsiasi allarme di incendio per la stessa scena.
3. Pennacchio di cenere vulcanica. Valore AOD CAMS fresco → corroborato; altrimenti copertura SEVIRI fresca → corroborato (contesto cenere/finestra-IR). Questo è il verdetto corroborato più debole nel modulo: l'esistenza della copertura SEVIRI non è evidenza che un pennacchio sia presente, quindi il fraseggio thesis-safe è "contesto cenere disponibile (copertura geostazionaria)," non "pennacchio di cenere confermato".
4. Vapore / degassamento vulcanico. SO₂ TROPOMI fresco ≥ 5e-4 mol/m², altrimenti SO₂ CAMS fresco ≥ 5e-5 kg/m², altrimenti granulo EMIT fresco → corroborato. La regola e le soglie sono reali, ma nel ciclo di verifica nessun valore di SO₂ era utilizzabile (media summit-box TROPOMI nulla + CAMS stale), quindi il degassamento era non corroborato in questo ciclo — correttamente.

Gli esempi svolti in wf36_corroboration_matrix.md §3 sono l'output effettivo di python service/corroboration.py contro lo snapshot live. In quel ciclo, firms_near_summit_km = 0.4 km (sul-cratere): lava_incandescence è stato corroborato VOLCANIC, mentre wildfire_flame/wildfire_smoke sono stati correttamente mantenuti come non corroborati (l'hit a 0.4 km è il termico del cratere dell'Etna stesso, non un incendio indipendente — esattamente la trappola che WF36 esiste per evitare).

L'onesta suddivisione 5-corroborabili / 8-STAGED. Otto classi di Gate-C sono target di corroborazione STAGED_NOT_LIVE, non rilevazione o corroborazione live, e la tesi non deve implicare altrimenti: nube meteorologica, bagliore/sole/riflesso e fotogramma nero/congelato/obsoleto sono solo etichette di contesto del detector (non lanciano mai allarmi e non hanno ramo di corroborazione); nebbia/foschia, fumo industriale, polvere/cava, artefatto della telecamera e ignoto non sono affatto classi del detector. Per fumo industriale e polvere, i dati OSM industriale/energia e strade/ferrovie sono sulla plancia ma non collegati a corroboration.py — sono colonne disponibili-ma-non-collegate, non una corroborazione che la tesi possa rivendicare. Stato: LIVE_OPERATIONAL per le cinque classi supportate da regole (con i loro qualificatori a livello di ciclo); STAGED_NOT_LIVE per le altre otto.

3.8 Tassonomia degli allarmi, revisione umana e la dashboard bilingue

Gli allarmi sono deduplicati spazialmente (IoU 0.4) con un cooldown per-classe/posizione di 1800 s; i fotogrammi più vecchi di 1800 s e i feed più vecchi di 24 h sono trattati come obsoleti. La superficie di output è una dashboard interna/di anteprima di auto-valutazione che porta esplicitamente un banner "Not a public product". Il dispatch automatico di allarmi pubblici è STAGED_NOT_LIVE: il dispatch via email era disattivato (alert_email.enabled=false) alla verifica, e il workflow di revisione human-in-loop non è ancora una pipeline operativa live. Ciò è dichiarato esplicitamente: non si sostiene che il sistema operi una pipeline di allerta.

La dashboard è completamente bilingue (italiano di default, toggle inglese) con lingua rilevata dal browser e persistenza su localStorage. La parità delle chiavi di traduzione è esatta: i dizionari en: e it: in public/i18n.js contengono ciascuno esattamente 240 chiavi (240/240). La qualità della traduzione per singola stringa non è stata auditata separatamente; la rivendicazione LIVE_OPERATIONAL è la parità del conteggio delle chiavi. Stato: LIVE_OPERATIONAL (UI bilingue); STAGED_NOT_LIVE (dispatch allarmi / human-in-loop).

Capitolo 4 — Dataset e progettazione della valutazione

Classificazione operativa di tutte le metriche dei Capitoli 4/5: RESEARCH_ONLY (valutazione offline held-out; n ridotto segnalato ovunque). La prestazione di sistema principale è un benchmark held-out, non una misurazione di dispatch di allarmi live.

4.1 Set held-out

Sono usati due set held-out disgiunti, entrambi solo fotogrammi reali:

• Set di falso allarme (FA) vulcanico, n = 62. Fotogrammi vulcanici confermati da bollettino da MarkL02/ingv-etna-camera-historical, tutti ground-truth-negativi per incendio boschivo (degassamento sommitale, cenere, bagliore lavico, attività stromboliana, nube, bagliore/tramonto, neve). Sono i confondenti su cui il sistema non deve lanciare allarme.
• Set di recall diurno, n = 18 (con un'alternativa n = 20). Fotogrammi di incendio da telecamera, genuinamente visibili, allarmati dal detector, da dataset di sorgenti pulite — D-Fire (annotato con box) più Roboflow/HPWREN/web — usati per misurare che il veto non distrugge il recall. I dati delle sequenze Pyronear sono riportati separatamente e mai mescolati.

Definizione di confusione al punto operativo: GT-negativo = i 62 fotogrammi vulcanici; GT-positivo = i 18 fotogrammi di incendio da telecamera genuinamente visibili diurni (il denominatore conservativo).

4.2 Il denominatore di recall diurno (entrambi riportati, riconciliazione onesta)

Il valore principale esclude conservativamente l'intera categoria del residuo notte↔lava di quattro fotogrammi dal denominatore diurno → n = 18, 94.4% (17/18), corrispondente al WF25_system_scoring committato. Sotto Config A solo 2 di quei 4 fotogrammi notturni sono effettivamente persi (07871, 07875); gli altri 2 (07723, 07773) passano e lanciano allarme. Escludendo solo i 2 fotogrammi genuinamente persi si ottiene l'alternativa n = 20, 95.0% (19/20), CI [76.4–99.1%]. Entrambi sono divulgati; il valore principale usa il conservativo 17/18.

4.3 Controlli no-leakage

• Fuga di pHash: 0 collisioni tra il set vulcanico esterno e le immagini di addestramento del detector v1b (eval_external_v1b.json). Avvertenza onesta: le immagini di train di v1b vivono off-repo (workspace DGX/RunPod), quindi il diff train↔held-out è preso su provenienza documentata; i 62 fotogrammi held-out sono indipendentemente confermati internamente distinti (62 pHash univoci). Per chiuderla completamente, la lista di collisioni train↔held-out (attesa vuota) dovrebbe essere committata.
• Cache VLM deterministica (temperatura 0). Ogni verdetto di ritaglio instradato è letto dalla cache a temperatura-0 committata (reports/crop_veto_outputs/te_crop_level_cpu_configA.json). Lo scoring WF25 ha speso 0 nuove chiamate VLM, uno stub è stato collegato per sollevare un'eccezione su qualsiasi cache miss (nessuna è avvenuta), e 245/245 decisioni per fotogramma hanno corrisposto bit-per-bit al risultato Config A memorizzato. Il determinismo è circoscritto alla build qwen3-vl-32b servita (la temperatura 0 ha dato oscillazione ±0 su tre ripetizioni di query fresche), non garantito in perpetuo se il modello servito cambia.
• Gestione della contaminazione. Due fotogrammi di contaminazione non-camera (un ritaglio pancromatico Landsat-8 a falsi colori e un dipinto) sono stati correttamente rigettati dal VLM e sono esclusi dal denominatore di recall invece di essere contati come veri mancati incendi (CONTAM_016, CONTAM_017).

4.4 Tassonomia e confondenti

La valutazione è costruita attorno alla tassonomia dei confondenti incendio/vulcanico: fumo e fiamma da incendio boschivo (positivi), contro cenere vulcanica, lava/incandescenza, stromboliano, degassamento/vapore, più nube meteorologica, nebbia/foschia, bagliore/tramonto, neve, artefatto del sensore/lente. È esportata una libreria rappresentativa di hard-negative (Capitolo 6), con hard-negative web (polvere, nebbia, fumo industriale, bagliore) elencati per copertura di categoria anche dove le immagini vivono off-repo (percorsi lasciati vuoti, non fabbricati).

Capitolo 5 — Risultati

Tutte le metriche del Capitolo 5 sono RESEARCH_ONLY (offline held-out, n ridotto), riprodotte solo da cache dagli artefatti post-guardia-notturna. Il detector è congelato; i verdetti VLM sono letture di cache deterministiche a temperatura-0.

5.1 La tabella WF25 Gate-A completa (detector-solo contro due-stadi)

La specifica di prestazione completa per il sistema a due stadi in produzione — detector → veto Qwen3-VL a livello di ritaglio, Config A (pass-through del fumo) — misurata end-to-end sugli stessi fotogrammi reali held-out, con CI Wilson al 95%:

Nota di lettura sui denominatori per-classe. Un fotogramma può portare sia un box di fumo sia un box di fiamma, quindi i conteggi di classe (17 fumo + 10 fiamma) superano i 18 fotogrammi diurni univoci. La singola perdita di recall diurno (dfire_AoF07872) è un box di fiamma (luci-a-terra di insediamento), motivo per cui il recall di fiamma mostra −10 pp mentre il recall di fumo è intatto.

Nota di lettura sulle code di latenza. p90/p99 non sono stati calcolati separatamente; la cache committata memorizza p50/p95/max del detector-CPU (243.6 / 334.5 / 1876.5 ms). p90 ≈ 310 ms per interpolazione; p99 ≈ la coda-massima (il max di 1876 ms è un singolo outlier GC/IO). Queste stime di coda e il tasso di successo di cattura del fotogramma sono UNKNOWN_NEEDS_VERIFICATION e in coda nella roadmap. Media CPU end-to-end ≈ 426 ms/fotogramma (media detector + 0.151 × media VLM); un fotogramma con un ritaglio instradato ≈ 1756 ms p95; i fotogrammi quieti aggiungono 0.

5.2 Riproduzione e no-leakage (ri-confermati)

Riproduci: python service/thesis_wf25_scorecard.py.

5.3 Confusione del cambio appaiato (detector-solo → due-stadi) e McNemar

Set FA vulcanico (n=62, GT-negativo):

Set di recall (GT-positivo):

McNemar (esatto, bilaterale) sull'intero set di decisioni appaiate (62 vulcanici + 18 fotogrammi di recall diurno): discordanti b (det-solo allarme, due-stadi nessun-allarme) = 2; discordanti c (det-solo nessun-allarme, due-stadi allarme) = 0; p esatto bilaterale = 0.50 — non significativo. Tutte le coppie discordanti sono monodirezionali (b>0, c=0): il veto solo ed esclusivamente rimuove allarmi, non ne aggiunge mai uno. Il suo intero effetto misurato su questo set held-out è la rimozione di 2 allarmi — 1 FP da artefatto-del-sensore vulcanico e 1 fotogramma diurno borderline di luci-a-terra.

5.4 Risultato in chiaro (come richiesto dalla direttiva)

Su questo set held-out il veto Qwen3-VL cambia esattamente 2 di 80 decisioni appaiate, entrambe rimozioni. Sopprime 1 falso allarme vulcanico da artefatto-del-sensore (9243ab: 6/62 → 5/62 FA) e scarta 1 fotogramma diurno borderline di luci-a-terra (dfire_AoF07872: 18/18 → 17/18 recall). Non migliora precisione o recall su alcun caso genuino di fumo o fiamma, non crea alcun nuovo falso allarme, e non raggiunge lo 0% di FA vulcanica — i 5 sopravvissuti sono fumo di degassamento sommitale che passa attraverso per progettazione. Il valore onesto e misurato del veto è la rimozione di un falso allarme da artefatto; su ogni decisione di incendio-genuino e degassamento-genuino lascia il detector invariato. Una riduzione di FA maggiore (8.1% → 3.2%) è disponibile solo instradando anche il fumo (Config B), al costo di instradare i fotogrammi di contaminazione e di incorrere in 2 ulteriori perdite di recall notturno per lava; il precedente veto su fotogramma intero raggiungeva lo 0% di FA ma costava ~20.8% di recall. Config A è il default raccomandato.

5.5 Preservazione del recall (Gate B) e la ri-valutazione di sicurezza notturna

Domanda di Gate-B: il VLM veta mai un vero caso di fumo/fiamma da incendio boschivo?

• Incendio diurno genuinamente visibile: NO — la preservazione del recall TIENE. Il VLM veta 0 veri fotogrammi diurni di fumo/fiamma. L'unico veto diurno (dfire_AoF07872) è luci-a-terra di insediamento, non un incendio.
• Notte (PRIMA della guardia): SÌ — 2 veri fotogrammi di incendio di vegetazione sono stati vetati VOLCANIC (dfire_AoF07871 @0.818, dfire_AoF07875 @0.878). Per apparenza single-frame la loro fiamma è quasi identica all'incandescenza lavica, e il VLM innescato sul vulcano ha propeso per VOLCANIC.
• Notte (DOPO la guardia): NESSUN FN silente — il residuo è MITIGATO. Entrambi i fotogrammi sono rilevati a media grigia del pannello 3.0 / 3.2 (ben sotto la soglia di 12), fuori-cratere, senza FIRMS → la guardia scatta → ciascuno è fatto emergere come uncertain_night / needs_review invece di essere scartato.

Risultato ri-valutato (stessa cache a temperatura-0, 0 nuove chiamate VLM):

La FA vulcanica è dimostrabilmente invariata: 0 dei 62 fotogrammi vulcanici sono abbastanza scuri (tutti diurni luminosi, media > 12) da far scattare la guardia notturna, quindi la guardia strutturalmente non può toccare i 5 sopravvissuti di degassamento diurno. Il veto è di conseguenza un veto sicuro per il recall di notte tramite l'override di corroborazione — uno strato di precisione consultivo diurno E un veto notturno che è gated dalla corroborazione così da non poter mai produrre un falso negativo notturno silente fuori-cratere. (Riproduci: python service/rescore_wf25_night_guard.py.)

Limite di falsi negativi: FN diurno su incendio-vero introdotto dal VLM = 0 (il limite superiore di Wilson sull'1/18 FN diurno osservato — un fotogramma non-incendio — è 25.8%, che il piccolo campione non può restringere).

5.6 Matrice di corroborazione per-classe WF36 (la suddivisione 5-corroborabili / 8-STAGED)

Legenda delle celle: ✔ conferma · ◐ supporta · ✗ contraddice · – non disponibile · ∅ non-applicabile · ⏳ obsoleto · ≈ troppo-grossolano. (Chiavi della colonna-sorgente come in wf36_corroboration_matrix.md §1.)

Genuinamente corroborabili adesso (5): fumo da incendio, fiamma da incendio (regole LIVE; non corroborate in questo ciclo — FIRMS sul-cratere a 0.4 km, correttamente non una conferma di incendio), lava/incandescenza (corroborata VOLCANIC in questo ciclo), pennacchio di cenere vulcanica (corroborato solo via copertura SEVIRI — debole/contestuale, l'AOD CAMS era stale), vapore/degassamento vulcanico (regola LIVE; non corroborato in questo ciclo — TROPOMI nullo + CAMS stale + valore sotto la soglia elevata). STAGED_NOT_LIVE (8): nube meteorologica, bagliore, fotogramma congelato (solo etichette di contesto), nebbia/foschia, fumo industriale, polvere, artefatto telecamera, ignoto (nessuna regola / nessuna classe detector). Secondo il controllo hard-stop §8 della direttiva, non è richiesto alcun over-claim e nessun hard-stop è attivato, a condizione che la tesi restringa le rivendicazioni di corroborazione alle cinque classi supportate da regole con i loro qualificatori a livello di ciclo ed etichetti le altre otto come STAGED — cosa che fa.

5.7 Snapshot della specifica operativa (Gate E)

Righe chiave LIVE_OPERATIONAL (tabella completa in system_performance_spec.md): 5 telecamere configurate / 3 online; cadenza 75 s; trigger VLM = solo ritagli caldi/luminosi instradati; 64 feed (46 live / 7 stale / 10 catalogued / 1 key-pending / 0 error); FWI 13.06 moderato; EtnaFeedsRefresh orario Running; dedup IoU 0.4 / cooldown 1800 s; parità bilingue 240/240; salute telecamere OFFLINE onesta; guardia di degrado Overpass attiva. STAGED_NOT_LIVE: revisione-umana / dispatch allarmi-email. UNKNOWN_NEEDS_VERIFICATION: tasso di successo di cattura del fotogramma; latenza p90/p99.

5.8 Valutazione quantistica (due-diligence al limite della ricerca — negativo onesto)

Classificazione operativa: RESEARCH_ONLY. SOLO SIMULAZIONE — nessuna QPU è stata contattata, la chiave IBM Quantum non è stata letta. Tutto il calcolo è stato CPU locale leggera (simulazione statevector di ≤4 qubit, ~46 s di wall). Una vittoria quantistica è asserita solo dove un CI di differenza appaiata esclude lo zero.

Un benchmark quantistico-contro-classico fresco e su dati reali è stato eseguito direttamente sull'attività INGV: discriminare eventi di anomalia termica VOLCANIC contro WILDFIRE vicino all'Etna — il problema dei fianchi popolati che la stessa letteratura dell'INGV definisce spettralmente difficile. Dati: 33 eventi vulcanici dell'edificio etneo (oracolo settimanale di stato GVP/INGV + FRP FIRMS) e 404 eventi di incendio di fianco vegetato (fuoco attivo FIRMS reale nell'anello ≤25 km), n = 437, 182 gruppi di data, GroupKFold per data (con guardia anti-leakage). Il regime difficile near-field intrinseco usa solo magnitudine termica / molteplicità FIRMS (log_frp_max, log_frp_sum, log_firms_count, n_firms_sensors), senza geometria e senza proxy di disponibilità-sorgente (che correlano perfettamente con la classe per costruzione e sono rimossi). Con 4 feature = 4 qubit, la mappa quantistica vede il segnale completo con nessuna perdita di informazione da PCA — la base più equa possibile.

AUC out-of-fold (raggruppato-per-data, n=437):

Delta AUC appaiati (quantistico − classico, bootstrap CI 95%):

Interpretazione onesta. Questo è un negativo pulito, supportato da CI e pubblicabile: sulle stesse feature reali e sullo stesso split con guardia anti-leakage, il kernel di fedeltà quantistico (0.837) è battuto dall'RBF-SVM classico appaiato (0.936) di −0.099 [−0.161, −0.038]; il VQC (0.702) è il modello peggiore testato. In particolare la perdita non è un artefatto di troncamento dimensionale — con solo 4 feature la mappa a 4 qubit vede il segnale completo — è la disallineatura encoding/geometria-del-kernel e il soffitto di generalizzazione del VQC in sé. Poiché la simulazione statevector è esatta, il verdetto di classificazione non migliorerà su hardware reale (il rumore del dispositivo può solo nuocere). Lo strumento giusto per questa attività di classificazione è classico.

L'unica genuina novità (preservata come linea di ricerca, non come rivendicazione operativa): la formulazione dell'inversione della sorgente di deformazione vulcanica (Mogi/Okada) come problema QUBO/Ising. Su una geometria GNSS dell'Etna sintetica-realistica, la variante multi-sorgente / di selezione-del-modello risolta tramite simulated annealing raggiunge l'ottimo esatto il 100% [89–100%] dove il Levenberg–Marquardt multi-start si intrappola al 60% e greedy/OMP allo 0%. Avvertenza onesta: questa vittoria è condivisa da un campionatore classico di simulated-annealing — è un successo di formulazione-QUBO, non un vantaggio di hardware quantistico. Le mappature Mogi-sorgente-singola-QUBO e Dozier-sub-pixel-come-QAOA sono, per quanto ne sappiamo, prime nella letteratura (in attesa di conferma peer). Verdetto quantistico complessivo: vale la pena valutare e vale la pena formulare, ma sulle attività di classificazione che effettivamente fanno girare il monitor non aggiunge valore operativo — il classico vince con CI che escludono lo zero. Il gate QPU resta BLOCKED in attesa di approvazione esplicita; nessun hardware quantistico è stato usato in alcun luogo. (Riproduci: python quantum_disambiguator.py, ~46 s, solo simulazione statevector.)

Capitolo 6 — Modalità di guasto e limitazioni

Questo capitolo è esaustivo per progettazione (Gate F). Il manifesto leggibile dalla macchina è failure_case_manifest.csv (38 righe); 24 fotogrammi sorgente + 24 miniature sono esportati in failure_crops/. Build di sola-lettura: il multi_cam_service live non è stato disturbato.

6.1 Il residuo incendio-notturno↔lava (l'unica vera perdita di recall su incendio)

Due fotogrammi sono le uniche vere perdite di recall su incendio nella Config A in produzione, riportati separatamente ed esclusi dal denominatore diurno:

Una linea di fiamma di incendio di vegetazione notturno luminoso e l'incandescenza lavica non sono separabili dall'apparenza single-frame; il prompt di contesto vulcanico che dà al sistema la sua bassa FA vulcanica è esattamente ciò che mis-instrada questi due. Questo è mitigato, non risolto. La guardia di sicurezza notturna (Capitolo 3.6 / 5.5) converte questi da falsi-negativi silenti in allarmi uncertain_night fatti emergere (FN silente notturno 2 → 0), ma l'ambiguità single-frame sottostante rimane. Prossimi passi raccomandati (lavori futuri, non rivendicati operativi): persistenza temporale multi-frame (la lava è stabile; l'incendio boschivo tremola e si propaga) e un override duro di co-localizzazione notturna FIRMS/SLSTR. Config B incorre in 2 ulteriori perdite notturne per lava (AoF07723, AoF07773; FNB_010, FNB_011) — il prezzo documentato del recall per spingere la FA vulcanica dall'8.1% al 3.2%, e il motivo per cui Config A è il default.

6.2 Il veto borderline delle luci-cittadine

FN_008 (dfire_pos_AoF07872, wildfire_flame @0.858/0.713 → NEITHER, "artificial ground lights, likely from settlement") è il singolo fotogramma che muove il recall diurno dal 100% al 94.4% (17/18). È un rigetto plausibilmente-corretto di luci di insediamento/a-terra distanti, contato conservativamente come una perdita di recall così che il valore principale non sia gonfiato. Ritaglio: failure_crops/FN_008.jpg.

6.3 I cinque falsi allarmi vulcanici sopravvissuti

Il veto Config-A sopprime esattamente un FP vulcanico (FP_003 / 9243ab, artefatto-del-sensore/lens-flare racchiuso in box come fiamma, VLM ha deciso NEITHER, 9.7% → 8.1%). I 5 sopravvissuti (FP_001, FP_002, FP_004, FP_005, FP_006) sono vapore di degassamento passivo sommitale / nube / cenere mal-racchiusi in box come wildfire_smoke; i ritagli di classe-fumo passano attraverso per progettazione (è ciò che preserva il recall degli incendi boschivi), quindi il veto non può sopprimerli in Config A. Tutti e sei i fotogrammi sorgente sono esportati (failure_crops/FP_001.jpg … FP_006.jpg).

6.4 Perdite del precedente veto a livello di fotogramma (motivazione del design a livello di ritaglio)

Il precedente veto su fotogramma intero raggiungeva 0/62 di FA vulcanica ma distruggeva ~20.8% del recall di incendio genuinamente visibile (FRAMEVETO_012–015: fumo debole all'orizzonte distante HPWREN/Roboflow chiamato "haze/cloud" dal prompt su fotogramma intero a contesto vulcanico). La Config A a livello di ritaglio in produzione recupera ognuno di essi — un pennacchio grigio e distante non è rovente, non è mai instradato al VLM, e non può mai essere vetato. Mantenuto come l'onesto limite-superiore di modalità di guasto dell'architettura alternativa.

6.5 Hard-negative rappresentativi

Libreria di confondenti vulcanici (fotogrammi reali esportati): HN_018 vapore/degassamento, HN_019 pennacchio di cenere, HN_020 bagliore lavico, HN_021 stromboliano, HN_022 oscuramento da nube, HN_023 bagliore/tramonto, HN_024 copertura nevosa. Gli hard-negative web (polvere, nebbia, fumo industriale, bagliore, altro; HNWEB_025–029) portano percorsi di fotogramma vuoti perché le immagini vivono sul pod di valutazione, non in questo checkout — dichiarato come fatto, non fabbricato. Le categorie con 0 istanze esportabili localmente (fumo industriale, polvere, artefatto-da-compressione) sono dichiarate come tali invece di essere inventate.

6.6 Segnalazioni di onestà e limitazioni note (consolidate)

• Telecamere: 3 di 5 online alla verifica. INGV EtnaTVChn ed EtnaWalk erano OFFLINE; il sistema riporta OFFLINE onestamente. Nessuna rivendicazione di "5 telecamere live".
• 7 feed obsoleti (Capitolo 3.2 / failure_appendix.md §8) sono esclusi da qualsiasi conteggio "live" e trattati come no-evidence dalla corroborazione. I 10 catalogued + 1 key-pending feed non sono live.
• La latenza p90 / p99 e il tasso di successo di cattura del fotogramma sono UNKNOWN_NEEDS_VERIFICATION — non strumentati; esistono solo p50/p95/max del detector-CPU. Sono in coda nella roadmap; la tesi cita p95/max come i limiti disponibili.
• Il dispatch via email degli allarmi è STAGED_NOT_LIVE (ALERT_EMAIL_ENABLED=0); la dashboard è interna/anteprima ("Not a public product"); la revisione human-in-loop non è un workflow live.
• Reset TLS transitori su /api/cams osservati (2 di 3 fetch; recuperati al retry, publisher locale ha corroborato). Un item di monitoraggio, non uno stop bloccante.
• Il VLM è uno strato di precisione consultivo, reso sicuro per il recall di notte dall'override di corroborazione — non è un detector generale di fumo precoce (coerente con SmokeBench [7]).
• 8 classi di corroborazione STAGED non devono essere rivendicate come rilevate o corroborate.
• CI a n ridotto. n=62 (FA) e n=18 (recall diurno) danno ampie CI Wilson; il McNemar è sotto-potenziato (2 coppie discordanti). Ogni stima puntuale è direzionale; l'unico beneficio confermato del veto (1 FP da artefatto) è entro il rumore della CI. La tesi non sovra-rivendica un miglioramento di FP a livello di sistema.
• La fuga è registrata come 0 ma la lista di collisioni train↔held-out non è committata (immagini di train off-repo); chiuderla completamente è un item della roadmap.
• top_p non fissato nel payload della richiesta VLM (default del server) — una lacuna di riproducibilità da chiudere.
• Il determinismo è circoscritto alla build qwen3-vl-32b servita, non garantito in perpetuo.
• 0 incidenti di fotogramma-congelato e 0 di contraddizione-satellitare sono stati osservati nel set held-out (FROZEN_037, SATCON_038); nessuno è inventato. La condizione notturna dark-RGB è gestita come un vero negativo di scena-quieta, non mal-letta come un guasto di congelamento.

Capitolo 7 — Lavori futuri

Ogni voce qui è PLANNED finché non ha evidenza di salute live; nulla è descritto come operativo. La baseline della tesi resta congelata a 4d1b0cc / ingv_v1b_best.pt / qwen3-vl-32b temp 0.0 — i nuovi modelli sono sfidanti, non sostituzioni della baseline. Nessun hardware edge/Hailo/DGX è assunto (target sala-operativa: detector CPU/GPU auto, VLM serverless remoto).

7.1 Fase 0–2 settimane — chiudere le lacune di Fase-1 e irrobustire il congelamento

Strumentare il tasso di successo di cattura del fotogramma (contatore rolling online/offline per-sorgente + età-fotogramma, sostituendo lo "3 di 5 online" puntuale); calcolare la latenza p90/p99 dagli array per-fotogramma esistenti inclusa la coda VLM del ritaglio instradato, separatamente per CPU e GPU; fissare top_p nella richiesta VLM; irrobustire /api/cams con una probe di retry/salute e un fallback con timbro di freschezza a cameras_wall.json; aggiungere una guardia per-fotogramma di fotogrammi-consecutivi-identici-via-pHash (intercettare una telecamera congelata-ma-recente); bloccare il fraseggio STAGED di WF36.

7.2 Fase 1 mese — rigore della valutazione

Allargare i set held-out (più fotogrammi vulcanici confermati da bollettino e più fotogrammi diurni di incendio da sorgenti pulite; mantenere la fuga-di-pHash a zero e la separazione delle sequenze Pyronear); committare la lista di collisioni train↔held-out; eseguire la batteria di robustezza hard-negative in stile WARP [12] (rumore gaussiano, compressione JPEG, sfocatura, chiazze simili a nubi, nebbia/foschia, bagliore, pioggia-su-lente, sovrimpressioni di timestamp, fotogrammi neri/congelati) e riportare le curve di degrado del detector + due-stadi.

7.3 Fase 3 mesi — domain adaptation e sfidanti di segmentazione

La domain adaptation [13,14,15,16] è il prossimo pilastro centrale: raccogliere fotogrammi non etichettati da ogni telecamera live, estrarre i positivi del detector + i disaccordi detector–VLM + i veti VLM, far revisionare a un umano un piccolo set difficile, addestrare con UDA/self-training, e testare su episodi held-out di telecamera/data/meteo/vulcanici, difendendosi dalla deriva catastrofica dei falsi positivi. Sfidanti detector/segmentazione (RESEARCH_ONLY): YOLO11/YOLO12 [4], RT-DETR [5], Grounding DINO 1.5/Edge [6], maschere di pennacchio video SAM 2 [23,24], coerenza-di-moto-del-fumo via optical-flow [21,22], mascheratura cielo/terreno — confrontati con lo YOLO11s congelato, non sostituiti in. Studio del prompt-come-componente-valutato [10,11]: misurare il tradeoff recall-contro-FA attraverso le varianti di prompt CROP/SMOKE, in stile SmokeBench [7].

7.4 Fase 6 mesi — VLM fine-tunato, fusione IR/termica, event tracking FCI

VLM Etna/incendio fine-tunato [20]: fine-tunare un modello in stile Qwen2.5/Qwen3-VL su ritagli Etna degassamento-contro-incendio-contro-nube, mantenendo il 32B congelato come baseline della tesi. Fusione IR/termica [17,18,19,20]: fusione RGB+IR, rilevazione termica/notturna, discriminazione fuoco/lava/calore-industriale, corroborazione satellitare-termica — attaccando direttamente il residuo incendio-notturno↔lava. Event tracking MTG-FCI [25,26,27]: spostare FCI da corroborazione solo-copertura a estrazione di fuoco-pixel in stile FireDyn, tasso-di-propagazione, evoluzione FRP e mappe di arrivo del fuoco, trattando FCI come dato di candidato-precoce + event-tracking, non come ground truth perfetta. Dashboard di active-learning + volano di dati: il detector lancia → candidati, i disaccordi VLM → esempi difficili, le decisioni umane → etichette, la corroborazione satellitare → etichette deboli, i bollettini INGV → etichette vulcaniche, i fotogrammi obsoleti/congelati → etichette di salute-telecamera.

7.5 Solo-ricerca (nessuna data committata)

Limiti di localizzazione del fumo precoce da VLM/MLLM (mantenere detector-first + veto VLM secondo l'evidenza corrente [7]); prompt tuning multimodale in stile FireCLIP [10]; SO₂ TROPOMI + CAMS come evidenza solo-contestuale [31,32,33]; studio di sensibilità FCI-contro-SEVIRI [25] e caratterizzazione del fuoco attivo SLSTR [29,30]; espansione del dataset multi-stagione attraverso shift di illuminazione/meteo/angolo/episodio; progettazione del protocollo operativo di allerta human-in-loop (attualmente STAGED) prima di qualsiasi rivendicazione rivolta al pubblico; e la linea di ricerca inversione-della-sorgente-vulcanica-come-QUBO (Capitolo 5.8) — un filone di ricerca parallelo, QPU BLOCKED.

Bibliografia

Stato di verifica: tutti i 35 riferimenti VERIFIED (paper/fonte confermati esistenti via arXiv / editore / IEEE / ScienceDirect / indice papers di Hugging Face, con titolo e autori corrispondenti); [34] e [35] sono documentazione ufficiale (verificata, non-paper), citati deliberatamente per il concetto operativo di affidabilità-dei-feed.

1. Govil, K.; Welch, M.L.; Ball, J.T.; Pennypacker, C.R. (2020). Preliminary Results from a Wildfire Detection System Using Deep Learning on Remote Camera Images. Remote Sensing 12(1):166. https://doi.org/10.3390/rs12010166
2. Dewangan, A.; Pande, Y.; Braun, H.-W.; Vernon, F.; Perez, I.; Altintas, I.; Cottrell, G.W.; Nguyen, M.H. (2021). FIgLib & SmokeyNet: Dataset and Deep Learning Model for Real-Time Wildland Fire Smoke Detection. arXiv:2112.08598. https://arxiv.org/abs/2112.08598
3. Lostanlen, M.; Veith, F.; Buc, C.; Barriere, V. (2024). Constructing a Real-World Benchmark for Early Wildfire Detection (PyroNear-2025 Dataset). arXiv:2402.05349. https://arxiv.org/abs/2402.05349
4. Tian, Y.; Ye, Q.; Doermann, D. (2025). YOLOv12: Attention-Centric Real-Time Object Detectors. arXiv:2502.12524 (NeurIPS 2025). https://arxiv.org/abs/2502.12524
5. Zhao, Y.; Lv, W.; Xu, S.; et al. (2024). DETRs Beat YOLOs on Real-time Object Detection (RT-DETR). CVPR 2024; arXiv:2304.08069. https://arxiv.org/abs/2304.08069
6. Ren, T.; et al. / IDEA-Research (2024). Grounding DINO 1.5: Advance the "Edge" of Open-Set Object Detection. arXiv:2405.10300. https://arxiv.org/abs/2405.10300
7. Qi, T.; Li, W.; Barnes, N. (2025). SmokeBench: Evaluating Multimodal Large Language Models for Wildfire Smoke Detection. WACV 2026; arXiv:2512.11215. https://arxiv.org/abs/2512.11215
8. Zhang, C.; Wang, S. (2024). Good at captioning, bad at counting: Benchmarking GPT-4V on Earth observation data. arXiv:2401.17600. https://arxiv.org/abs/2401.17600
9. Danish, M.S.; Munir, M.A.; Shah, S.R.A.; Kuckreja, K.; Khan, F.S.; Fraccaro, P.; Lacoste, A.; Khan, S. (2024). GEOBench-VLM: Benchmarking Vision-Language Models for Geospatial Tasks. arXiv:2411.19325. https://arxiv.org/abs/2411.19325
10. FireCLIP: Enhancing Forest Fire Detection with Multimodal Prompt Tuning and Vision-Language Understanding. Fire (MDPI) 8(6):237, 2025. https://www.mdpi.com/2571-6255/8/6/237
11. Adhikari, R.; Thapaliya, S.; Dhakal, M.; Khanal, B. (2024). TuneVLSeg: Prompt Tuning Benchmark for Vision-Language Segmentation Models. arXiv:2410.05239. https://arxiv.org/abs/2410.05239
12. Ide, R.; Yang, L. (2024/2025). Adversarial Robustness for Deep Learning-based Wildfire Detection Models (WARP). arXiv:2412.20006; Fire (MDPI) 8(2):50. https://arxiv.org/abs/2412.20006
13. Multilevel feature cooperative alignment and fusion for unsupervised domain adaptation smoke detection. Frontiers in Physics 11:1136021, 2023. https://www.frontiersin.org/articles/10.3389/fphy.2023.1136021/full
14. EDIF: boosting unsupervised cross-domain forest fire smoke detection with enhanced domain-invariant features. Geomatics, Natural Hazards and Risk, 2025. https://www.tandfonline.com/doi/full/10.1080/19475705.2025.2556144
15. Generative AI for Enhanced Wildfire Detection: Bridging the Synthetic-Real Domain Gap. arXiv:2511.16617, 2025. https://arxiv.org/abs/2511.16617
16. Pesonen, J.; Hakala, T.; Karjalainen, V.; Koivumäki, N.; Markelin, L.; Raita-Hakola, A.-M.; Suomalainen, J.; Pölönen, I.; et al. (2024). Detecting Wildfires on UAVs with Real-time Segmentation Trained by Larger Teacher Models. arXiv:2408.10843. https://arxiv.org/abs/2408.10843
17. A UAV-Based Multi-Scenario RGB-Thermal Dataset and Fusion Model for Enhanced Forest Fire Detection. Remote Sensing 17(15):2593, 2025. https://www.mdpi.com/2072-4292/17/15/2593
18. MCDet: Target-Aware Fusion for RGB-T Fire Detection. Forests 16(7):1088, 2025. https://www.mdpi.com/1999-4907/16/7/1088
19. A Study on Flame Detection Method Combining Visible Light and Thermal Infrared Multimodal Images. Fire Technology, 2024. https://link.springer.com/article/10.1007/s10694-024-01676-9
20. Habibpour, M.; Alipour Talemi, N.; Spodnik, J.; Khoury, C.J.; Afghah, F. (2026). WildFireVQA: A Large-Scale Radiometric Thermal VQA Benchmark for Aerial Wildfire Monitoring. arXiv:2604.20190. https://arxiv.org/abs/2604.20190
21. Yuan, F. (2014). Spatiotemporal bag-of-features for early wildfire smoke detection (HOOF temporal feature). Image and Vision Computing 32(1):24–33. https://doi.org/10.1016/j.imavis.2013.08.001
22. Zhao, Y.; et al. (2015). Forest Fire Smoke Video Detection Using Spatiotemporal and Dynamic Texture Features. Journal of Electrical and Computer Engineering 2015:706187. https://onlinelibrary.wiley.com/doi/10.1155/2015/706187
23. Ravi, N.; Gabeur, V.; Hu, Y.-T.; Hu, R.; Ryali, C.; Ma, T.; Khedr, H.; et al. (2024). SAM 2: Segment Anything in Images and Videos. arXiv:2408.00714. https://arxiv.org/abs/2408.00714
24. Ugwu, E.U.; Xinming, Z. (2025). Promptable Fire Segmentation: Unleashing SAM2's Potential for Real-Time Mobile Deployment with Strategic Bounding Box Guidance. arXiv:2510.21782. https://arxiv.org/abs/2510.21782
25. Major improvements in spaceborne early fire detection and small-fire FRP retrieval with the Meteosat Third Generation Flexible Combined Imager. Science of Remote Sensing, 2026. https://www.sciencedirect.com/science/article/pii/S2666017226000040
26. Paugam, R.; Filippi, J.-B.; Benali, A.; Gomes, J.; Xu, W.; Dutra, E.; Andre, F.; Boulanger, D.; Retornard, V.; Meraner, A.; Harvie, J.; Penot, V.; Denjean, C. (2026). Leveraging MTG-FCI fire observations for event-based fire behavior monitoring (FCI-FireDyn / Fire Event Tracker). arXiv:2606.06016. https://arxiv.org/abs/2606.06016
27. Unsupervised Wildfire Detection Using Multispectral MTG-FCI Data: A Feasibility Study. Journal of Imaging 12(6):229, 2026. https://doi.org/10.3390/jimaging12060229
28. Schroeder, W.; Oliva, P.; Giglio, L.; Csiszar, I.A. (2014). The New VIIRS 375 m active fire detection data product: Algorithm description and initial assessment. Remote Sensing of Environment 143:85–96. https://doi.org/10.1016/j.rse.2013.12.008
29. Xu, W.; Wooster, M.J. (2023). Sentinel-3 SLSTR Active Fire (AF) Detection and FRP Daytime Product — Algorithm Description and Global Intercomparison to MODIS, VIIRS and Landsat AF Data. Science of Remote Sensing 7:100087. https://www.sciencedirect.com/science/article/pii/S2666017223000123
30. Wooster, M.J.; Xu, W.; Nightingale, T. (2012). Sentinel-3 SLSTR active fire detection and FRP product: pre-launch algorithm development and performance evaluation using MODIS and ASTER datasets. Remote Sensing of Environment 120:236–254. https://doi.org/10.1016/j.rse.2011.09.033
31. Theys, N.; Hedelt, P.; De Smedt, I.; Lerot, C.; Yu, H.; Vlietinck, J.; Pedergnana, M.; et al. (2019). Global monitoring of volcanic SO2 degassing with unprecedented resolution from TROPOMI onboard Sentinel-5 Precursor. Scientific Reports 9:2643. https://www.nature.com/articles/s41598-019-39279-y
32. Exploiting Sentinel-5P TROPOMI and Ground Sensor Data for the Detection of Volcanic SO2 Plumes and Activity in 2018–2021 at Stromboli, Italy. Sensors 21(21):6991, 2021. https://www.mdpi.com/1424-8220/21/21/6991
33. Theys, N.; et al. Sulfur dioxide retrievals from TROPOMI onboard Sentinel-5 Precursor: Algorithm Theoretical Basis. Atmospheric Measurement Techniques. https://amt.copernicus.org/articles/10/119/2017/
34. NASA FIRMS — Fire Information for Resource Management System: product and latency documentation (VIIRS/MODIS active fire). NASA Earthdata. https://www.earthdata.nasa.gov/data/tools/firms/faq
35. EUMETSAT — Meteosat Third Generation Instruments (FCI) documentation. https://www.eumetsat.int/meteosat-third-generation-instruments

Appendici

Appendice A — Riepilogo del registro probatorio

Ogni affermazione principale è riconducibile a thesis_evidence_ledger.csv (claim_id, operational_status, evidence_path, commit, command/query, timestamp, metric, CI, limitation, thesis-safe wording). Riepilogo delle 16 righe del registro:

Appendice B — Appendice sui guasti e riferimenti ai ritagli

failure_case_manifest.csv (38 righe); failure_crops/ (24 fotogrammi sorgente + 24 miniature). Ritagli illustrativi chiave: residuo incendio-notturno↔lava FN_007.jpg, FN_009.jpg; luci-cittadine borderline FN_008.jpg; FA vulcanica sopravvissuta FP_001.jpg … FP_006.jpg (FP_003 = l'unico artefatto-del-sensore vetato); perdite notturne solo-Config-B FNB_010.jpg, FNB_011.jpg; perdite del precedente veto a livello di fotogramma FRAMEVETO_012–015.jpg; libreria di confondenti vulcanici HN_018 … HN_024; contaminazione CONTAM_016 (satellite a falsi colori), CONTAM_017 (dipinto) — entrambi correttamente rigettati dal VLM ed esclusi dal denominatore di recall. Gli hard-negative web HNWEB_025–029 portano percorsi vuoti (immagini off-repo, dichiarato non fabbricato). Originali dei ritagli vetati: crops/VETOED_dfire_pos_AoF07871_…_VOLCANIC.jpg, …AoF07875_…_VOLCANIC.jpg, …AoF07872_…crop0/crop1_NEITHER.jpg.

Appendice C — Manifesto di congelamento del modello e dei prompt

Manifesto completo: model_prompt_freeze.json (commit 4d1b0cc, congelato 2026-06-29T02:45:00Z). Detector: YOLO11s a 19 classi, models/ingv_v1b_best.pt, sha256 c0a3d0ead257d318e70bec3bb84feaec7b99e9e3d55b132fc5f1ffd405cf0a20, 19.261.267 byte, imgsz 960, conf 0.25, pad ritaglio 0.25 / max 768 px, dedup IoU 0.4, cooldown 1800 s. VLM: qwen3-vl-32b, endpoint OpenAI-compatibile serverless Model-Vault RunPod, routing a livello di ritaglio, temperatura 0.0, max_tokens 120, top_p server-default, retry 3 / backoff 8.0 s / timeout 180 s, ritaglio immagine lato-lungo ≤768 px JPEG q88 base64. Due prompt congelati (CROP_PROMPT veto primario, SMOKE_PROMPT degassamento-contro-pennacchio) con testo verbatim nel manifesto; output JSON-stretto {label, confidence, reason} con fallback PARSE_FAIL. Cache: temp-0 deterministica per-ritaglio (reports/crop_veto_outputs/te_crop_level_cpu_configA.json). Hardware: workstation OFFICE locale (CPU/GPU auto) + VLM serverless remoto; nessun DGX, nessun PHOENIX prod, nessun edge/Hailo assunto.

Appendice D — Matrice di corroborazione completa

Matrice per-classe completa, regola implementata per-classe + esempio svolto sui feed live correnti + avvertenza onesta: wf36_corroboration_matrix.md (implementazione service/corroboration.py @ 4d1b0cc, snapshot feed 2026-06-29T02:56:39Z). Cinque classi supportate da regole (fumo da incendio, fiamma da incendio, lava/incandescenza, pennacchio di cenere, vapore/degassamento) con qualificatori a livello di ciclo; otto classi STAGED (nube, bagliore, fotogramma congelato, nebbia/foschia, fumo industriale, polvere, artefatto telecamera, ignoto). Regola di freschezza: i feed più vecchi di FEED_MAX_AGE_H = 24 h sono trattati come nessuna evidenza corrente (non corroborati, mai contraddetti). Riproduci: ETNA_FEEDS_OUT=../etna_dashboard/feeds/out python corroboration.py.

Preparato per il deliverable INGV. Baseline congelata commit 4d1b0cc. Ogni numero citato è riconducibile a un artefatto probatorio di Fase 1 committato in flank_wildfire/reports/thesis/. Il sistema è riportato come un'architettura di monitoraggio multi-sorgente supportata da evidenze con classificazione operativa esplicita, intervalli di confidenza e modalità di guasto; non si sostiene che risolva la rilevazione precoce degli incendi boschivi in generale.