WF-9 · Macro + ML
Feature point-in-time con release lag, robust z-score rolling, Global Economy Pulse, modelli Ridge/Elastic Net/Huber/PCA+Ridge/gradient boosting/random forest e selezione prequentiale.
Percorso progressivo
Dal risultato visibile all’implementazione.
Ogni livello aggiunge dettaglio senza richiedere di ricominciare: si può entrare dal punto più adatto e proseguire verso il livello successivo.
Metodi aggiunti al laboratorio
World Economy Engine ed Etna Sentinel: due famiglie di calcolo diverse.
WF-9 · Regimi e grafo
Gaussian Mixture a tre stati con fit causale; NetworkX per il grafo strutturale e propagazione smorzata. Bootstrap, intervalli conformal e graph ablation governano l'evidenza.
WF-10 · Modello fisico semplificato
Avvezione cinematica oraria del vento a 700/500 hPa, distanza Haversine verso asset di trasporto e classi di allineamento. Non è un modello di cenere o concentrazione.
WF-10 · ML, RPA e gate
Isolation Forest descrive soltanto l'anomalia del contesto vento; GitHub Actions, source gate VONA, deduplicazione e AT Protocol/XRPC realizzano l'orchestrazione fail-closed.
Pacchetti: WF-9 usa NumPy, pandas, scikit-learn, NetworkX, SciPy, Matplotlib, SQLite, PyYAML, requests, ReportLab/openpyxl. WF-10 usa pandas, NumPy, scikit-learn, Matplotlib, Pillow, BeautifulSoup, pypdf, pydantic, requests e integrazione Bluesky.
WF11–WF21 · estensione del laboratorio
Chimica, energia, sensor fusion, comfort climatico, comunicazione, mobilità e operabilità marittima: nuovi metodi implementati.
La matrice tecnica sottostante resta la fonte compatta di confronto; queste schede rendono leggibili i nuovi repository e rimandano ai dossier completi.
WF-11 · Hydrogen Route Observatory
Confronta SMR grigio, SMR+CCS ed elettrolisi con prezzi energetici pubblici/configurati, bilanci chimici, boundary emissivi e soglie di break-even.
Metodo: calcolo deterministico; Current Variable Cost e LCOH; break-even con stato interpretativo
Apri dossier tecnicoWF-12 · Ammonia & Fertilizer Chain
Propaga il costo del gas nella catena NH₃→urea e mantiene separati calcolo fisico, nowcast e forecast M+1 verificabile.
Metodo: catena NH₃/urea deterministica + Ridge/Gradient Boosting per forecast M+1
Apri dossier tecnicoWF-13 · Italy Variable Renewable Forecast
Prevede il giorno civile D+1 Europe/Rome per solare, eolico e VRE totale, normalizzando per capacità e archiviando vintage point-in-time.
Metodo: Gradient Boosting su capacity factor; intervalli empirici
Apri dossier tecnicoWF-14 · Process Sentinel
Rileva anomalie e guasti su un processo chimico dinamico generico usando un benchmark di dati sintetici (dati simulati) congelato di 28 giorni, truth separata e un ensemble drift-aware PCA + residui di processo.
Metodo: ensemble drift-aware: PCA T²/Q ad alta specificità + residui bilancio vapore, raffreddamento e reazione + CUSUM lento sul residuo vapore; Isolation Forest/autoencoder come comparatori; classifier fault
Apri dossier tecnicoWF-15 · Virtual Analyzer
Soft sensor sperimentale su dati sintetici (dati simulati): stima la qualità di prodotto fra due analisi di laboratorio con ritardo, rumore, controlli point-in-time, OOD e astensione misurabile.
Metodo: Linear, PLS, Ridge, Random Forest, Gradient Boosting; Isolation Forest OOD
Apri dossier tecnicoWF-16 · Energy & Steam Optimizer
Ottimizza una rete vapore HP/MP/LP modellata con domanda utility basata su dati sintetici (dati simulati) e prezzi reali/configurati di gas, elettricità e CO₂, contro una reference dispatch policy congelata.
Metodo: HiGHS LP e MILP; dispatch e perturb/re-opt
Apri dossier tecnicoWF-17 · Etna Fusion Lab
Fonde tremore, sismicità, segnali termici e storia degli eventi con pesi corretti per qualità; separa l’Activity Nowcast 1h/6h dal forecast VONA ash-positive 1d/5d e conserva un ledger prospettico verificabile.
Metodo: fusione con pesi quality-adjusted; Activity Index/banda; probabilità escalation 1h/6h abilitate solo dopo sufficiente evidenza riconciliata; forecast VONA riusa gate Hawkes/modality validato
Apri dossier tecnicoWF-18 · Climate Comfort Hours
Trasforma previsioni Open-Meteo a 72 ore in una mappa oraria comparativa del comfort outdoor per 27 città, con focus fisso su Siracusa, rotazione delle città e criticità dominanti esplicite.
Metodo: score euristico 0–100 con penalità trasparenti; priorità semantica per temporale, neve, pioggia, caldo, freddo, vento, nebbia, afa, comfort; best contiguous window
Apri dossier tecnicoWF-19 · Lab Intelligence Community
Workflow editoriale bilingue che presenta il laboratorio, mette in rotazione i progetti, spiega metodo e controlli e propone domande alla community senza inventare risultati scientifici.
Metodo: selezione deterministica di template, lingua, campagna e spotlight; nessun modello generativo nella composizione del testo
Apri dossier tecnicoWF-20 · The Public Service Run
Workflow educativo che confronta percorsi traffic-aware e finestre di partenza per scenari di pendolarismo nel servizio pubblico, combinando routing, meteo, calibrazione storica, Random Forest dopo warm-up e incertezza P10/P50/P90.
Metodo: baseline API → correzione bias con 1–49 campioni → Random Forest da 50 campioni; P10/P50/P90, probabilità on-time e scelta della partenza più tarda che supera soglia e gate pessimista
Apri dossier tecnicoWF-21 · Port Operability · NYC Ferry
Workflow di ricerca che prova ad anticipare, da 1 a 5 giorni, quando le condizioni meteo-marine possono rendere critica l’operabilità degli approdi NYC Ferry di Rockaway e Bay Ridge. Combina GFS e GEFS-Wave, stati LOW/WATCH/HIGH, controlli fail-closed e verifica successiva con evidenze ufficiali NYC Ferry.
Metodo: runtime scientifico congelato; Rockaway usa champion marine-core con challenger e controllo in shadow, Bay Ridge mantiene la policy v0.9.8; l’output pubblico espone stati LOW/WATCH/HIGH, non probabilità o soglie
Apri dossier tecnicoPrima della matrice tecnica
Cinque domande per valutare un workflow in modo rigoroso.
- I dati erano realmente disponibili quando è stato prodotto il risultato?
- Il sistema è confrontato con un metodo più semplice?
- L’errore e l’incertezza sono misurati?
- Il comportamento cambia nel tempo?
- Il risultato può essere ricostruito?
Point-in-time
Una previsione fatta lunedì non può usare un dato pubblicato martedì.
Baseline
Un modello complesso va confrontato con una regola semplice, per esempio “domani sarà simile a oggi”.
Calibrazione
Se molti eventi ricevono il 70% di probabilità, nel lungo periodo circa sette su dieci dovrebbero verificarsi.
Data drift
Un modello può perdere affidabilità quando cambiano dati, contesto o relazioni.
Ablation
Si rimuove una fonte o una variabile per verificare se contribuisce davvero.
Failure mode
Si descrive prima come il sistema può sbagliare, bloccarsi o risultare fuorviante.
Metodi dei workflow WF-1 – WF-8
Regole, indicatori e modelli statistici: come sono costruiti i workflow da WF-1 a WF-8.
I primi workflow del laboratorio coprono meteo, mercati energetici e finanziari, osservazione satellitare e generazione di contenuti. Le schede seguenti riportano dati, inferenza e stack di ciascuno; la matrice più sotto aggiunge validazione e condizioni di fallimento.
WF-1 · Weather automation
previsioni multi-città; escursione, vento, umidità, pioggia, pressione. Indice rule-based con contributi limitati.
Stack: Python, pandas, Open-Meteo, Pillow/Matplotlib
WF-2 · The New Margin
futures energetici, FX, lag e rolling; KPI crack 3-2-1. Modelli ad albero e forecast multi-orizzonte.
Stack: pandas, scikit-learn/XGBoost, Parquet, report HTML
WF-3 · Market Overview
serie cross-asset, rendimenti, volatilità, breadth e spread. Regime, classificatore direzionale, Isolation Forest, indice composito.
Stack: yfinance, pandas, scikit-learn, Chart.js
WF-4 · AI Supply Chain
basket della filiera AI, z-score, network e parametri di simulazione. Indice composito, outlook 30 giorni, bootstrap, network analytics.
Stack: NumPy/pandas, scikit-learn, NetworkX, Matplotlib
WF-5 · Satellite
evento GVP, gate INGV, sismi, FIRMS, venti 700/500 hPa. Advezione lagrangiana, MLP di regime, DBSCAN e anomaly score opzionale.
Stack: requests/httpx, BeautifulSoup, pypdf, Pydantic, scikit-learn, PyTorch opzionale
WF-6 · Termometro della crisi energetica
Brent, TTF, volatilità, spread, tassi, fertilizzanti e shipping/proxy; z-score e confidence. Indice pesato 0–100, EWM, ridge forecast e state machine.
Stack: pandas, SciPy, scikit-learn, statsmodels, SQLite, Jinja2/ReportLab
WF-7 · Etna Forecast
eventi INGV, sismicità FDSN, FIRMS, tremore e nuvole; feature point-in-time e censura. LightGBM per modalità, baseline climatologia/persistenza/Hawkes, blend e modality gate.
Stack: pandas, PyArrow, SciPy, scikit-learn, LightGBM, pypdf, ObsPy opzionale
WF-8 · Bluesky multi-fonte
feed RSS/API, registro fonti, gruppi di indipendenza, testo e metadati di provenienza. Sentiment e classificazione tema/entità/evento, similarità lessicale, event cluster o confronto tematico, templating facts-only.
Stack: requests, transformers, PyTorch, pandas/NumPy, Pillow, regex, AT Protocol/XRPC, GitHub Actions
Mappa architetturale
Dieci livelli separano fonte, inferenza e pubblicazione.
Data engineering
Correttezza del dato prima della complessità del modello.
Tempo e point-in-time
- separazione tra timestamp della fonte, acquisizione, run e pubblicazione;
- normalizzazione UTC con timezone locale solo nella presentazione;
- feature costruite usando esclusivamente dati disponibili alla data di previsione;
- as-of join e lag espliciti per ridurre leakage.
Contratto e lineage
- schema e unità attese per ogni adapter;
- identificativo della fonte e URL di provenienza;
- versione del parser e fingerprint numerico;
- stato della cache e motivazione dei fallback.
Dati mancanti
- distinzione tra zero osservato e informazione assente;
- missing masks quando il modello deve conoscere la copertura;
- graceful degradation solo se semanticamente sicura;
- fail-closed per gate ufficiali o fonti critiche.
Persistenza
- CSV/JSON/Parquet in base a audit, volume e compatibilità;
- scritture atomiche e nomi deterministici;
- storico ex ante distinto dagli esiti maturati;
- stato anti-duplicazione separato dagli artifact temporanei.
Ecosistema software
Framework, librerie e protocolli per livello architetturale.
Data layer
pandas, NumPy, SciPy, PyArrow, Pydantic, SQLite, JSON, CSV e Parquet supportano normalizzazione, tipi, timestamp, snapshot e audit.
Model layer
scikit-learn, LightGBM, XGBoost, statsmodels, PyTorch opzionale e NetworkX coprono classificazione, regressione, anomalie, clustering, bootstrap e grafi.
Source layer
requests, httpx, pandas-datareader, Beautiful Soup, lxml, pypdf, yfinance e ObsPy opzionale integrano API, pagine, PDF e serie pubbliche con retry e timeout.
Presentation layer
Matplotlib, Pillow, Chart.js, Jinja2, ReportLab, openpyxl, HTML5, CSS e JavaScript producono card accessibili, dashboard e gallerie responsive.
Automation layer
GitHub Actions, cron, workflow_dispatch, pytest, Ruff, uv e Hatch orchestrano run, test, packaging e artifact.
Publishing layer
AT Protocol/XRPC, TID, Bluesky, Cloudflare Pages e Worker gestiscono post standalone, sito statico e routing linguistico.
Pattern implementativi
Quattro contratti riducono l’ambiguità del runtime.
Adapter contract
fetch(source_date) -> RawPayload
parse(payload) -> TypedRecord
validate(record) -> QualityReportAcquisizione, parsing e controllo restano separati e testabili.
Outcome state
PUBLISHED | DRY_RUN
SKIPPED | BLOCKED
DEGRADED | FAILEDUn run verde non viene confuso con una pubblicazione effettiva.
Point-in-time
feature_time <= prediction_time
source_time <= run_cutoff
outcome_time > prediction_timeTimestamp e lag espliciti riducono leakage e look-ahead.
Idempotency key
key = hash(event_id,
source_time,
language,
content_version)Fingerprint e record key deterministici rendono sicuro il retry.
MLOps e osservabilità
Il ciclo di vita include dati, modello, esecuzione e pubblicazione.
Versionamento
- Git per codice, configurazioni e documentazione;
- versione del package e release contract;
- hash dei dati e della card;
- record ex ante separati dagli esiti maturati.
Riproducibilità
pyproject.tomle lockfile;- fixture offline e seed dove applicabile;
- snapshot di input e configurazioni;
- artifact scaricabili dal run.
Osservabilità
run_summary.jsone provenance;- timestamp di fonte, run e pubblicazione;
- URI dei record e stato persistente;
- messaggi espliciti per skip, block e degraded.
Evoluzione possibile
- container OCI/Docker e registry;
- DVC o MLflow per lineage sperimentale;
- OpenTelemetry e Prometheus/Grafana;
- FastAPI per servizi controllati.
NON ANCORA PRESENTATO COME IMPLEMENTATO
Model risk e validazione
Il modello complesso deve battere una baseline pertinente fuori campione.
| Area | Implementazione attesa | Errore evitato | Evidenza |
|---|---|---|---|
| Split temporale | train/validation/test ordinati, gap o purge quando necessario | look-ahead e contaminazione | date e numerosità dei fold |
| Baseline | naïve, climatologia, persistenza o modello semplice | skill apparente senza valore incrementale | metrica modello − baseline |
| Calibrazione | Brier, reliability curve, coverage o error bands | probabilità eccessivamente sicure | campione maturato e periodo |
| Ablation | rimozione di gruppi di feature o modalità | complessità non giustificata | delta metriche e stabilità |
| Robustezza | bootstrap, period analysis, sensitivity | risultato dipendente da pochi episodi | intervalli e worst period |
| Drift | monitoraggio di distribuzioni, errori e copertura | modello obsoleto non rilevato | serie storica e soglie |
Software e runtime
Affidabilità operativa come parte del risultato.
Modularità
Adapter, processing, modelling, rendering e publishing rimangono separati e testabili. Le configurazioni non sono disperse nel codice.
Idempotenza
Event ID, data-fonte, fingerprint e hash visuali impediscono doppi post e riuso involontario di card precedenti.
State machine
Gli esiti distinguono pubblicato, dry-run, saltato, bloccato e fallito; un run verde non equivale necessariamente a un post.
CI/CD
Lint, test unitari, test di integrazione offline, contratti strutturali e artifact precedono l’esecuzione schedulata.
Secrets e sicurezza
Credenziali in environment protetti, permessi minimi, redazione dei log e separazione tra staging e produzione.
Osservabilità
run_summary.json, provenance, versioni, timestamp e URI pubblicati consentono diagnosi e audit.
Matrice dei workflow
Metodi implementati e criteri specifici.
| WF | Dati e feature | Inferenza | Validazione | Stack caratterizzante | Failure mode |
|---|---|---|---|---|---|
| WF-1 | previsioni multi-città; escursione, vento, umidità, pioggia, pressione | indice rule-based con contributi limitati | controlli di coerenza e analisi di sensibilità; nessuna validazione clinica | Python, pandas, Open-Meteo, Pillow/Matplotlib | interpretare un indice educativo come previsione individuale |
| WF-2 | futures energetici, FX, lag e rolling; KPI crack 3-2-1 | modelli ad albero e forecast multi-orizzonte | split temporali, baseline, MAE/bias, bootstrap degli errori | pandas, scikit-learn/XGBoost, Parquet, report HTML | proxy di margine incompleto e relazioni instabili |
| WF-3 | serie cross-asset, rendimenti, volatilità, breadth e spread | regime, classificatore direzionale, Isolation Forest, indice composito | walk-forward, confronto baseline, stabilità per periodo | yfinance, pandas, scikit-learn, Chart.js | semplificazione di shock e dipendenze non stazionarie |
| WF-4 | basket della filiera AI, z-score, network e parametri di simulazione | indice composito, outlook 30 giorni, bootstrap, network analytics | model-vs-naïve, errori maturati e stabilità dei basket | NumPy/pandas, scikit-learn, NetworkX, Matplotlib | proxy finanziari non equivalenti a capacità industriale reale |
| WF-5 | evento GVP, gate INGV, sismi, FIRMS, venti 700/500 hPa | advezione lagrangiana, MLP di regime, DBSCAN e anomaly score opzionale | test sintetici, freshness gate, duplicate guard, fail-closed ufficiale | requests/httpx, BeautifulSoup, pypdf, Pydantic, scikit-learn, PyTorch opzionale | traiettoria del vento scambiata per concentrazione o hazard |
| WF-6 | Brent, TTF, volatilità, spread, tassi, fertilizzanti e shipping/proxy; z-score e confidence | indice pesato 0–100, EWM, ridge forecast e state machine | walk-forward OOS, Dynamic vs Static, sottoperiodi, stress window e risk analytics | pandas, SciPy, scikit-learn, statsmodels, SQLite, Jinja2/ReportLab | proxy di mercato scambiati per disponibilità fisica o segnale operativo |
| WF-7 | eventi INGV, sismicità FDSN, FIRMS, tremore e nuvole; feature point-in-time e censura | LightGBM per modalità, baseline climatologia/persistenza/Hawkes, blend e modality gate | purged walk-forward, embargo, holdout, Brier, calibrazione e scorecard maturata | pandas, PyArrow, SciPy, scikit-learn, LightGBM, pypdf, ObsPy opzionale | probabilità educativa scambiata per allerta; modalità incomplete non dichiarate |
| WF-8 | feed RSS/API, registro fonti, gruppi di indipendenza, testo e metadati di provenienza | sentiment e classificazione tema/entità/evento, similarità lessicale, event cluster o confronto tematico, templating facts-only | gate fonti, soglia di overlap 5-grammi, comunicabilità, idempotenza, verifica PDS/AppView e ricevute di audit | requests, transformers, PyTorch, pandas/NumPy, Pillow, regex, AT Protocol/XRPC, GitHub Actions | fonti non indipendenti o non ammesse, contenuto generico, riuso eccessivo, mancata pubblicazione di una lingua |
| WF-9 | World Bank WDI, FRED e OECD; lag di rilascio, lag/differenze/rolling, robust z-score, componenti del Global Pulse e feature propagate sul grafo | Ridge, Elastic Net, Huber, PCA+Ridge, HistGradientBoosting, Random Forest; ensemble robusto; GMM a 3 regimi; scenari con propagazione grafo smorzata | expanding backtest con purge gap, selezione prequentiale, baseline naive, bootstrap di skill, intervalli conformal 90%, ablation del grafo e audit anti-leakage/vintage | Python, NumPy, pandas, scikit-learn, NetworkX, SciPy, Matplotlib, SQLite, PyYAML, requests, ReportLab/openpyxl | confondere un grafo di ipotesi con causalità provata; revisioni macro, pochi OOS, break strutturali o forecast sperimentali interpretati come consiglio |
| WF-10 | INGV VONA, vento Open-Meteo 700/500 hPa, FIRMS e GIBS VIIRS; geometrie di aeroporti/strade/ferrovie/porti e provenance | avvezione cinematica oraria 12h, distanza Haversine e classi di allineamento; Isolation Forest sul contesto del vento; relay VONA rule-based | test unitari/end-to-end, data-quality e disclosure gates, deduplicazione/idempotenza, fail-closed su stato ufficiale incerto/positivo e history immutabile | Python, pandas, NumPy, scikit-learn, Matplotlib, Pillow, BeautifulSoup, pypdf, pydantic, requests, GitHub Actions, AT Protocol/XRPC | interpretare direzione/prossimità come plume, concentrazione, impatto o probabilità di disservizio; latenza o indisponibilità delle fonti |
| WF-11 | TTF EEX→BFE con gate di qualità e provenance, prezzo day-ahead per bidding zone italiana con catena Energy-Charts→euenergy/ENTSO-E, EUA e scenario di grid carbon intensity; parametri SMR/CCS/elettrolisi tipizzati HHV/LHV | calcolo deterministico; Current Variable Cost e LCOH; break-even con stato interpretativo | invarianti fisici/dimensionali, sourcing coerente, lineage, replay da snapshot | Python, NumPy, pandas, SciPy, Matplotlib, SQLite, PyYAML | confondere scenario PPA o boundary emissivi diversi con quotazioni/osservazioni reali |
| WF-12 | TTF, World Bank Pink Sheet, FX BCE, lag/stagionalità; HHV/LHV esplicito | catena NH₃/urea deterministica + Ridge/Gradient Boosting per forecast M+1 | walk-forward, persistenza, stagionalità, gas-only, baseline fisica, MAE/RMSE/bias/coverage/skill | Python, pandas, scikit-learn, SQLite, Matplotlib | confondere prezzo benchmark globale con costo europeo o nowcast con forecast |
| WF-13 | Terna Public API primaria e ENTSO-E fallback per generazione/capacità osservate; senza credenziali, proxy Open-Meteo non pubblicabile con vento a 100 m per nodi dichiarati, curva di potenza locale prima della media pesata, ECMWF D+1; lag 1/24/168h, stagionalità, clear-sky | Gradient Boosting su capacity factor; intervalli empirici | split temporale e persistenza; proxy separato da actual e mai maturato come forecast reale; baseline prospettica ENTSO-E A69 quando disponibile; nMAE/RMSE/bias/coverage/skill | Python, pandas, scikit-learn, requests, SQLite, Matplotlib | confondere proxy meteo/capacità con generazione osservata, vintage non archiviati o crescita capacità interpretata come skill |
| WF-14 | sensori multivariati CSTR generico, rumore, missing data, guasti step/drift/intermittent | ensemble drift-aware: PCA T²/Q ad alta specificità + residui bilancio vapore, raffreddamento e reazione + CUSUM lento sul residuo vapore; Isolation Forest/autoencoder come comparatori; classifier fault | parametri fissati su simulazione di sviluppo separata; stesso benchmark basato su dati sintetici (dati simulati) congelato di 28 giorni; event recall, missed rate, episodi di falso allarme/24h, delay P50/P90, confronto con ensemble v1.4.16 e anti-leakage | Python, NumPy, pandas, scikit-learn, SQLite, Matplotlib | prestazioni valide solo per il simulatore; residui di processo specifici del banco prova e classifier non calibrato richiedono validazione prima del trasferimento a impianto reale |
| WF-15 | sensori processo + laboratorio ritardato con rumore/QC | Linear, PLS, Ridge, Random Forest, Gradient Boosting; Isolation Forest OOD | RMSE/MAE/bias/coverage, skill vs ultimo lab, split-conformal e truth-vs-lab; risk-coverage solo diagnostico | Python, pandas, scikit-learn, SQLite, Matplotlib | leakage dal valore vero o soft sensor che risponde fuori dominio |
| WF-16 | domanda vapore basata su dati sintetici (dati simulati), capacità/efficienze, TTF EEX, prezzo day-ahead per bidding zone italiana Energy-Charts con licenza verificata, EUA | HiGHS LP e MILP; dispatch e perturb/re-opt | fattibilità, bilanci, ottimalità, tempo soluzione, stabilità, reference policy | Python, SciPy HiGHS, NumPy, pandas, SQLite, Matplotlib | chiamare duali MILP i valori marginali o presentare saving simulato come risparmio reale |
| WF-17 | FDSN/sismicità, FIRMS/termico, cloud data, tremore multi-stazione opzionale, event history; freshness, completezza e qualità per modalità | fusione con pesi quality-adjusted; Activity Index/banda; probabilità escalation 1h/6h abilitate solo dopo sufficiente evidenza riconciliata; forecast VONA riusa gate Hawkes/modality validato | ledger immutabile delle emissioni, reconciliation sidecar, calibrazione prospettica, hysteresis/cooldown e learner adattivo soltanto in shadow prima dei gate | Python, pandas/NumPy, SciPy/scikit-learn, Matplotlib/Pillow, FDSN/HTTP, GitHub Actions, AT Protocol | confondere activity nowcast con previsione eruttiva o VONA ash-positive; degradazione/assenza sensori e campioni insufficienti per calibrare escalation |
| WF-18 | Open-Meteo forecast e marine: temperatura percepita/aria, UR, punto di rugiada, precipitazioni, neve, vento/raffiche/direzione, WMO code, radiazione e onde per città costiere | score euristico 0–100 con penalità trasparenti; priorità semantica per temporale, neve, pioggia, caldo, freddo, vento, nebbia, afa, comfort; best contiguous window | validazione indipendente città/giorno, batch→cache recente→retry singolo, celle grigie su missing, pubblicazione solo con 4 città core e almeno 80% del paniere | Python, requests, pytz, Pillow, GitHub Actions, AT Protocol/Bluesky | interpretare lo score come rischio clinico, meteoropatia, allerta ufficiale o comfort indoor; microclima e variabili personali non sono modellati |
| WF-19 | Registry canonico dei workflow del sito, cache/fallback JSON, mappa campagne, cycle key deterministica, calendario Europe/Rome e contatori pubblici Bluesky | selezione deterministica di template, lingua, campagna e spotlight; nessun modello generativo nella composizione del testo | validazione slot e blackout, limite settimanale, deduplicazione, diff revisionabile e gate fail-closed su schedule, policy e credenziali | Python 3.11+, YAML/JSON, Pillow, GitHub Actions, AT Protocol/Bluesky | registry obsoleto, slot non riconosciuto o claim non supportato; fallback dichiarati e blocco della pubblicazione riducono la propagazione dell'errore |
| WF-20 | Google Routes API v2: durate traffic-aware/statiche, alternative, distanza e geometria; Open-Meteo orario; tempo locale; ruolo/scenario; storico del proxy ETA vicino alla partenza | baseline API → correzione bias con 1–49 campioni → Random Forest da 50 campioni; P10/P50/P90, probabilità on-time e scelta della partenza più tarda che supera soglia e gate pessimista | MAE, RMSE, MAPE, errore assoluto mediano/p90, coverage P10–P90, top-1 departure accuracy, departure regret e stato esplicito del warm-up | Python, Google Routes API v2, Open-Meteo, scikit-learn RandomForest, pandas/NumPy, Pillow/Matplotlib, GitHub Actions, AT Protocol/Bluesky | il traffico API e il proxy ETA non sono GPS ground truth; chiusure, incidenti, semplificazione dei turni e meteo a scala urbana possono non essere rappresentati |
| WF-21 | GFS atmosferico 12Z e GEFS-Wave operational c00 sullo stesso issue, orizzonti D+1…D+5; vento, pressione, precipitazione e variabili marine/onda; evidenze outcome da NYC Ferry GTFS-Realtime, con 511NY opzionale come corroborazione | runtime scientifico congelato; Rockaway usa champion marine-core con challenger e controllo in shadow, Bay Ridge mantiene la policy v0.9.8; l’output pubblico espone stati LOW/WATCH/HIGH, non probabilità o soglie | previsioni immutabili verificate a D+1 e D+7; metriche prospettiche su episode recall, lead time, alert burden su giorni verificati disponibili, horizon coverage e calibrazione riservata; UNKNOWN escluso dai denominatori | Python, pandas/NumPy, scikit-learn, GFS, GEFS-Wave, NYC Ferry GTFS/GTFS-Realtime, 511NY opzionale, GitHub Actions, Pillow/Matplotlib, AT Protocol/Bluesky | fonti incomplete o non allineate, eventi non meteorologici, cambi di servizio o di infrastruttura, distribution shift e scarsità di episodi; il sistema deve degradare a UNKNOWN/HOLD invece di dedurre un falso all-clear |
Valutazione accademica e tecnica
Domande utili per una revisione indipendente.
- La data di origine di ogni dato è ricostruibile?
- Le feature rispettano la disponibilità point-in-time?
- La baseline è appropriata al problema?
- Gli iperparametri sono selezionati senza contaminare il test?
- Il campione di esiti maturati è sufficiente?
- Le metriche includono denominatore e periodo?
- I dati mancanti causano blocco o degradazione esplicita?
- I risultati sono riproducibili da configurazione e versione?
- I failure mode sono testati o solo descritti?
- La pubblicazione è idempotente e auditabile?
- La licenza delle fonti consente il riuso previsto?
- È chiaro cosa è implementato e cosa è estensione di ricerca?
Osservazioni tecniche o proposte di verifica
Segnalazioni su metodologia, test, riproducibilità e possibili esperimenti sono benvenute.
Metodo multi-fonte per Bluesky
Componenti tecniche del workflow WF-8.
Source policy e copyright
- registro domini con source_class, risk_tier e reuse_mode;
- solo fatti comunicabili e immagini renderizzate localmente;
- gate anti-riuso con controllo di overlap su 5-grammi.
NLP e confronto
- classificazione di sentiment, tema, entità ed evento;
- allineamento fra fonti tramite similarità lessicale e firme di dominio;
- distinzione esplicita tra event cluster e confronto tematico.
Templating e pubblicazione
- template facts-only per titolo, takeaway, “perché conta” e lente tecnica;
- post root separati per italiano e inglese;
- facets verso le fonti, nessun
reply_to, immagini multiple per post.
Pacchetti usati
- requests per raccolta feed e API;
- transformers e torch per l’arricchimento NLP;
- Pillow, matplotlib, pandas, numpy, regex per rendering, dati e limiti Bluesky.