Il 10 gennaio 2026 nasceva la prima versione del Forecast Engine di Meteo Gesualdo.

Era Eolo 1.0.0 e il suo compito era relativamente semplice: osservare le variazioni di pressione atmosferica e del vento registrate dalla stazione locale e provare a costruire una prima previsione.

Il 5 aprile arrivava invece Ceo 0.5.0, la prima versione sperimentale del sistema KNN.

Poco più di sei mesi dopo, il 15 luglio 2026, l'intera pipeline previsionale di Meteo Gesualdo è stata nuovamente riscritta.

Questa volta, però, non si tratta di una normale evoluzione.

Giano 9.0.0, Perseo 3.0.0, Estia 8.0.0 e Prometeo 6.0.0 rappresentano una nuova generazione del sistema previsionale.

Per capire perché siamo arrivati a una riscrittura così profonda bisogna partire dal componente che ha innescato tutto: il KNN.

Quando PHP ha iniziato a diventare un limite

Le precedenti generazioni del KNN di Meteo Gesualdo erano sviluppate in PHP.

La quinta generazione, Themis 5.2.0, aveva raggiunto un livello di maturità molto superiore rispetto ai primi esperimenti.

Themis utilizzava analoghi meteorologici validati, selezionava situazioni storiche simili, considerava stagionalità, giorno e notte, lead temporale e qualità dello storico.

Nelle ultime versioni era stata introdotta anche una correzione di prossimità capace di utilizzare le validazioni più recenti per riconoscere errori persistenti nelle prime ore di previsione.

Il sistema funzionava.

Ma proprio la sua evoluzione stava evidenziando un limite.

Il problema non era più semplicemente trovare alcuni vicini meteorologici e contare quale fenomeno fosse stato osservato più frequentemente.

Volevamo analizzare separatamente temperatura, umidità, dew point, pressione, vento, raffiche, direzione, pioggia, radiazione solare e indice UV.

Volevamo confrontare gli errori storici tra il valore previsto e quello realmente osservato.

Volevamo attribuire a ogni correzione un'autorità differente in base alla qualità dello storico disponibile.

E soprattutto volevamo elaborare in maniera coerente un'intera traiettoria previsionale di 168 ore.

All'interno dell'architettura utilizzata fino a quel momento, PHP iniziava a limitare fortemente la libertà con cui potevamo sviluppare il nuovo KNN.

L'aumento delle risorse disponibili sul server ha quindi reso possibile una scelta che inizialmente non era prevista: spostare il motore KNN su Python.

L'idea iniziale poteva sembrare semplice.

Prendere Themis e riscriverlo in Python.

Ma è durata poco.

Non volevamo una copia di Themis scritta in un altro linguaggio

Tradurre Themis da PHP a Python avrebbe cambiato il linguaggio, ma non necessariamente il motore.

Avremmo mantenuto la stessa struttura decisionale, gli stessi passaggi principali e molti degli stessi compromessi architetturali.

A quel punto è stata presa una decisione molto più radicale.

Il nuovo KNN sarebbe stato riscritto integralmente da zero.

Nasce così Prometeo 6.0.0.

Prometeo non è una conversione di Themis.

Themis lavorava principalmente cercando analoghi storici utili a confermare o correggere il forecast.

Prometeo parte invece da una domanda differente:

quando Meteo Gesualdo si è trovato in una situazione meteorologica simile, quale errore aveva commesso la previsione?

Il nuovo motore analizza i residui storici, cioè la differenza tra il valore previsto e quello successivamente osservato.

Se in condizioni realmente confrontabili il sistema ha mostrato una tendenza costante a sovrastimare o sottostimare un determinato valore, Prometeo può utilizzare quella memoria per correggere la nuova traiettoria.

Ma non esiste più un unico KNN che osserva tutto insieme.

Un KNN diverso per ogni canale meteorologico

Prometeo 6.0.0 utilizza una nuova architettura multicanale.

Temperatura, umidità, dew point, pressione, vento, raffiche, direzione del vento, pioggia, radiazione solare e indice UV vengono analizzati separatamente.

Anche le probabilità degli eventi principali, le famiglie meteorologiche e i fenomeni secondari dispongono di micro-KNN indipendenti.

La selezione parte da un gruppo globale di situazioni meteorologiche compatibili.

Da questa base ogni canale costruisce poi il proprio vicinato.

Una situazione storica può quindi essere molto utile per correggere la temperatura e contemporaneamente poco significativa per il vento.

Con Themis il vicino rappresentava principalmente una situazione meteorologica analoga.

Con Prometeo la qualità del vicino dipende anche da ciò che stiamo cercando di correggere.

È una differenza fondamentale.

Anche il numero di vicini non viene più trattato come un valore rigido.

Prometeo osserva la distanza meteorologica, il raggio relativo dei campioni e gli eventuali gap tra i risultati per capire dove il gruppo di situazioni realmente confrontabili inizia a perdere coerenza.

Dopo aver analizzato lo storico, il motore calcola l'autorità della possibile correzione.

Supporto disponibile, qualità del vicinato, consistenza degli errori storici, distanza temporale della previsione e fiducia nello storico contribuiscono a stabilire quanto Prometeo possa intervenire.

Lo storico, quindi, non ordina semplicemente al forecast di cambiare.

Deve prima dimostrare di meritare fiducia.

Riscrivere Prometeo ha fatto emergere un altro problema

Durante lo sviluppo del nuovo KNN è diventato evidente che Prometeo avrebbe potuto lavorare al massimo delle proprie possibilità solo ricevendo una pipeline molto più uniforme.

Il vecchio sistema era il risultato di una crescita velocissima.

In pochi mesi Forecast Local, API Forecast, Forecast Engine e KNN erano stati aggiornati numerose volte.

Minerva 8.1.0, Andromeda 2.1.1, Atena 7.2.1 e Themis 5.2.0 erano sistemi maturi e funzionanti, ma erano comunque nati in momenti differenti dell'evoluzione di Meteo Gesualdo.

Continuare ad adattare i quattro componenti al nuovo KNN avrebbe significato introdurre nuovi livelli di conversione e compatibilità.

Esattamente ciò che volevamo evitare.

A quel punto la riscrittura di Prometeo è diventata il punto di partenza per una scelta ancora più grande:

riscrivere l'intera pipeline previsionale.

L'obiettivo era costruire una strada il più possibile lineare dal dato meteorologico alla previsione finale.

Meno passaggi correttivi sovrapposti.

Meno conversioni.

Meno elaborazioni duplicate.

E una struttura più semplice da leggere anche per il server.

Da Minerva 8.1.0 a Giano 9.0.0

Il precedente motore locale, Minerva, aveva rappresentato un enorme passo avanti per Meteo Gesualdo.

Con la versione 8.0.0 erano stati introdotti filtro di Kalman, persistenza, trend fisici e una logica Zambretti evoluta.

Minerva 8.1.0 aveva successivamente integrato l'uso reale della radiazione solare e dell'indice UV, una maggiore conoscenza delle fasi astronomiche e controlli più precisi contro il rumore nella probabilità di pioggia.

Giano 9.0.0 parte da quell'esperienza, ma cambia il ruolo stesso del motore locale.

Giano non prova più semplicemente a produrre segnali locali da consegnare al Forecast Engine.

Costruisce una traiettoria meteorologica locale indipendente fino a 168 ore.

Per farlo utilizza i dati recenti ad alta risoluzione della stazione, lo storico orario locale, i cicli astronomici e una climatologia stagionale specifica di Gesualdo.

Temperatura, umidità, dew point, pressione, vento, precipitazioni, radiazione solare e indice UV vengono fatti evolvere lungo una timeline oraria uniforme.

I gate fisici per pioggia e temporali sono stati nuovamente rivisti e la persistenza meteorologica è stata integrata direttamente nella costruzione della traiettoria.

Rispetto a Minerva, Giano non rappresenta quindi un semplice miglioramento delle soglie.

È un motore locale progettato fin dall'inizio per descrivere l'evoluzione delle successive 168 ore.

Da Andromeda 2.1.1 a Perseo 3.0.0

Anche il motore dedicato alle sorgenti meteorologiche esterne è stato completamente evoluto.

Andromeda 2.1.1 normalizzava i dati Open-Meteo nel linguaggio meteorologico utilizzato da Meteo Gesualdo.

Il nuovo Perseo 3.0.0 costruisce invece una traiettoria esterna uniforme sullo stesso contratto orario utilizzato da Giano.

Perseo continua a utilizzare la previsione deterministica Open-Meteo per i valori meteorologici principali, ma introduce anche DWD ICON EPS come supporto ensemble alla valutazione dell'incertezza.

I due ruoli sono volutamente separati.

La previsione deterministica descrive lo scenario meteorologico.

L'ensemble aiuta il sistema a capire quanto quello scenario sia stabile o incerto.

Questo permette a Perseo di produrre una confidenza più coerente senza mescolare direttamente valori provenienti da modelli con funzioni differenti.

Rispetto ad Andromeda, quindi, Perseo non è più soltanto un normalizzatore di una sorgente esterna.

È il motore incaricato di costruire l'intera traiettoria meteorologica esterna della pipeline.

Da Atena 7.2.1 a Estia 8.0.0

Con Giano e Perseo capaci di produrre due traiettorie compatibili serviva un nuovo centro della pipeline.

Nasce Estia 8.0.0.

La precedente Atena 7.2.1 aveva raggiunto un sistema di fusione molto raffinato.

Gestiva il contributo locale e API, le famiglie meteorologiche, i segnali osservati in tempo reale e numerosi controlli per evitare transizioni meteorologiche poco credibili.

Ma Atena era cresciuta attraverso affinamenti progressivi.

Estia riparte da un principio differente.

Local e API devono prima essere confrontati. Poi fusi. Solo successivamente lo storico può intervenire.

Estia introduce quindi un Merge esplicito tra Giano e Perseo.

Il confronto viene eseguito sui valori fisici, sulle probabilità degli eventi principali, sulle famiglie meteorologiche e sui fenomeni secondari.

Il sistema calcola indicatori di accordo globali e separati per area termica, pressione, vento, pioggia e radiazione.

Le distribuzioni probabilistiche vengono confrontate matematicamente e il peso delle due sorgenti cambia in funzione del lead temporale e della disponibilità reale dei dati.

La direzione del vento viene gestita come un valore circolare e vengono applicati nuovi vincoli fisici a dew point, raffiche, radiazione solare e indice UV.

Estia costruisce il Merge.

Prometeo analizza il risultato attraverso la memoria meteorologica locale.

Infine Estia distribuisce la previsione canonica.

È stata inoltre eliminata una possibile fonte di incoerenza presente nelle architetture precedenti.

La previsione mostrata agli utenti, quella salvata nello storico e quella successivamente validata devono essere la stessa previsione.

Per questo Estia produce viste dedicate a pubblico, snapshot e analisi partendo da un unico risultato canonico.

Una pipeline unica

La nuova generazione può essere riassunta così:

Giano costruisce la traiettoria locale.

Perseo costruisce la traiettoria esterna.

Estia le confronta e crea il Merge.

Prometeo utilizza la memoria meteorologica di Gesualdo per analizzare e correggere la traiettoria.

Estia distribuisce il risultato canonico a sito, app e sistemi di learning.

Ogni componente ha un compito preciso.

Non deve anticipare il lavoro del componente successivo.

Non deve correggere nuovamente qualcosa dopo che il processo decisionale è terminato.

È probabilmente questo il cambiamento più importante dell'intera riscrittura.

La pipeline è diventata una linea molto più chiara.

E una struttura più lineare significa anche meno elaborazioni inutili e un utilizzo più controllato delle risorse del server.

Il livello di precisione più alto raggiunto da Meteo Gesualdo

I primi risultati della nuova pipeline hanno mostrato un salto immediatamente evidente rispetto alla generazione precedente.

Giano e Perseo producono traiettorie molto più strutturate.

Estia riesce a misurare in maniera più chiara dove le due sorgenti concordano e dove, invece, esiste reale incertezza.

Prometeo può analizzare gli errori storici per singolo canale e decidere autonomamente quanta fiducia attribuire alla propria correzione.

Infine, la ricomposizione fisica impedisce che le singole correzioni producano facilmente un insieme di valori meteorologicamente incoerenti.

Per Meteo Gesualdo è il livello di precisione più alto raggiunto fino a oggi.

Ma è importante spiegare cosa intendiamo quando utilizziamo la parola “precisione”.

Una previsione più precisa resta una previsione

Nessun motore meteorologico può conoscere il futuro con certezza assoluta.

Neppure Prometeo.

L'atmosfera è un sistema estremamente complesso e piccoli cambiamenti possono modificare l'evoluzione di un fenomeno.

Questo è particolarmente evidente su scala locale e durante eventi convettivi come i temporali estivi.

Quando diciamo che Meteo Gesualdo ha raggiunto un nuovo livello di precisione non stiamo affermando che ogni previsione sarà corretta.

Significa che il sistema dispone oggi di strumenti molto più raffinati per interpretare i dati disponibili, confrontare scenari differenti, riconoscere i propri errori storici e mantenere la coerenza fisica della previsione finale.

L'obiettivo non è eliminare l'incertezza meteorologica.

L'obiettivo è comprenderla meglio.

Sei mesi che hanno cambiato tutto

Da Eolo 1.0.0 a Estia 8.0.0.

Dal primo KNN sperimentale Ceo 0.5.0 a Prometeo 6.0.0.

Dal primo Forecast Local basato su pressione e vento a Giano 9.0.0, capace di costruire una traiettoria locale di sette giorni.

Tutto questo è avvenuto tra gennaio e luglio 2026.

La velocità con cui Meteo Gesualdo è cresciuto ha inevitabilmente portato a errori, correzioni, esperimenti e strade successivamente abbandonate.

Ma ha anche prodotto l'esperienza necessaria per capire finalmente come volevamo costruire il cuore del progetto.

Potevamo continuare a correggere la generazione precedente.

Abbiamo scelto di fermarci, prendere ciò che avevamo imparato e ricominciare.

Giano. Perseo. Estia. Prometeo.

Quattro nuovi motori.

Una sola pipeline.

E, fino a oggi, il più grande salto generazionale mai realizzato nel sistema previsionale di Meteo Gesualdo.