Un satellite diceva che un deposito era sott'acqua. Era l'ombra di una nuvola, e il trigger parametrico era a un clic dal liquidare automaticamente 1,2 milioni di dollari.
Un satellite ha osservato il deposito di Mesa Junction, ha rilevato una macchia scura dove avrebbe dovuto esserci terreno asciutto e ha contrassegnato la posizione come allagata. Una polizza parametrica contro le inondazioni ha interpretato quel trigger come un dato di fatto e ha predisposto la liquidazione automatica di un indennizzo da 1,2 milioni di dollari, senza perito, senza telefonata, senza una seconda verifica. La macchia scura era l'ombra di una nuvola. Sei giorni dopo era scomparsa dalle immagini, e il terreno sottostante non era mai stato bagnato.
Ho costruito esattamente questo caso di proposito, perché è proprio quello che un singolo fotogramma satellitare non potrà mai cogliere. Sono Ashutosh e guido Veriprajna. TriggerProof è una demo che ho creato per dimostrare una tesi precisa: il momento pericoloso nell'assicurazione parametrica contro le inondazioni non è il rilevamento, è la decisione di pagare. Ogni posizione, tassello, idrometro e rapporto sul campo al suo interno è costituito da elementi sintetici e fisicamente fedeli che ho scritto per poter rappresentare le modalità di guasto in modo pulito. Puoi aprirla e provarla tu stesso all'indirizzo veriprajna.com/it/demos/satellite-flood-intelligence-aggiudicare-il-trigger-parametrico-prima-della-liquidazione. Il deposito di Mesa Junction è il punto da cui voglio partire, perché è il caso che mi ha insegnato cosa stessi realmente costruendo.
Quattro elementi diversi scuriscono gli stessi pixel
Non avevo compreso la reale entità del problema finché non mi sono seduto a generare le immagini sintetiche e ho dovuto rendere quattro elementi identici su un unico fotogramma. L'assicurazione parametrica contro le inondazioni ha sostituito il perito liquidatore con un trigger: un satellite dice che una posizione è sott'acqua e il denaro si muove. Il guaio è che su una singola immagine ottica o su un unico passaggio radar, la vera acqua di inondazione, l'ombra di una nuvola, l'ombra radar o del rilievo e un bacino idrico permanente si scuriscono tutti allo stesso modo. Un singolo fotogramma non può distinguerli, perché le informazioni necessarie per separarli non risiedono in un solo fotogramma.
Questo ha ridefinito l'intera demo per me. L'errore catastrofico in questo settore non è l'inondazione che il trigger non rileva. È l'inondazione che il trigger inventa, una sicura liquidazione da 2 milioni di dollari per un'ombra, senza alcuna traccia probatoria per difendere la decisione quando un riassicuratore chiede spiegazioni un anno dopo. TriggerProof non rileva inondazioni e non produce dati satellitari. Prende un trigger che si è già attivato e giudica se debba effettivamente pagare.
Un fotogramma diceva inondazione; il successivo diceva che il terreno non era mai stato bagnato
Ricordo ancora quando ho fatto scorrere la sequenza di acquisizioni di Mesa Junction la prima volta che è stata renderizzata correttamente. L'interfaccia consente di aprire una posizione contrassegnata ed esaminare i fotogrammi di acquisizione uno alla volta, ottico in alto, radar in basso. Nel fotogramma del trigger, la macchia scura è proprio lì, di un verde con segnale d'acqua, esattamente ciò che ha fatto scattare l'allarme. Passi all'acquisizione successiva ed è sparita. Torni indietro e la retrodiffusione radar sotto quella stessa macchia risulta normale in ogni fotogramma, perché il radar ha visto il terreno asciutto dritto attraverso la nuvola per tutto il tempo.
L'ombra si è mossa; l'acqua sarebbe rimasta. Lo si vede solo attraverso il tempo e attraverso più sensori, mai sul singolo fotogramma che ha attivato il trigger.
La fisica non lascia dubbi una volta affiancati i fotogrammi. L'ombra di una nuvola è transitoria e viaggia alla velocità della nuvola, quindi è scura in un'acquisizione e scompare in quella successiva. La vera acqua di inondazione persiste attraverso le acquisizioni e risulta scura all'ottico e bassa al radar contemporaneamente. Due regole codificano esattamente questo: persistenza temporale e concordanza radar-ottica. Su Mesa Junction entrambe restituiscono FAIL, e il classificatore approda a ombra di nuvola con confidenza 1,00. Quegli 1,2 milioni di dollari non avrebbero mai dovuto essere messi in coda.
Decidono le cinque regole, non il modello linguistico
All'inizio ho provato a lasciare questa decisione al modello linguistico, e sono felice di averlo fatto perché ha fallito nel modo più istruttivo possibile. Avevo un agente che leggeva le stesse prove e gli ho chiesto, in sostanza, se la posizione fosse realmente allagata. Su un caso ambiguo mi ha scritto un paragrafo fluido e sicuro argomentando a favore di un'inondazione; si sbagliava, e nulla nel suo tono lasciava presagire che fosse in errore. Quel pomeriggio ha sancito una decisione progettuale che non ho mai più ridiscusso.
Così la decisione risiede in semplice Python, in cinque discriminatori ispezionabili, senza alcun modello nel percorso che muove il denaro. La persistenza temporale (R1) separa un'inondazione dall'ombra transitoria di una nuvola. La concordanza radar-ottica (R2) separa un'inondazione sia dall'ombra di una nuvola che da un'ombra radar. La pendenza DEM (R3) rifiuta l'acqua che dovrebbe ristagnare su terreni ripidi. Una maschera delle acque permanenti (R4) esclude i bacini idrici noti. Il collegamento idrologico (R5) verifica che l'area allagata si connetta effettivamente alla rete di drenaggio. Il verificatore decide; il modello linguistico consiglia soltanto. L'agente consultivo è basato su Pydantic AI, supporta modelli intercambiabili, con predefinito impostato su claude-opus-4-8, e confronta il verdetto della fisica con segnali a terra indipendenti, restituendo corroborates, contradicts o inconclusive. Può essere scavalcato, e quando disattivo la chiave API la demo funziona completamente offline su un fallback deterministico, perché la componente a cui affido una liquidazione non può essere quella che parla con paragrafi sicuri di sé.
Quando la fisica stessa è incerta, il sistema inoltra a revisione invece di tirare a indovinare
Tengo più al caso in cui il sistema dice "Non lo so" che a qualsiasi individuazione netta. Canal Street Hub è quel caso. Le firme ottiche e radar sono al limite, il segnale di inondazione persiste in due fotogrammi su tre, e l'idrometro indipendente non ha mai superato il livello di piena. Le prove sono in aperto conflitto. La confidenza risulta pari a 0,151, ben al di sotto della soglia di automazione di 0,65 che ho calibrato sul dataset etichettato, e l'agente a terra contraddice apertamente la classificazione satellitare.
Il gate della polizza invia quegli 0,8 milioni di dollari a un operatore umano con tutte le prove allegate, contrassegnati come "richiede verifica", invece di lanciare una moneta e chiamarla automazione. Un trigger di inondazione che inoltra i casi realmente ambigui ad alcuni acquirenti appare come il prodotto più debole. Io la vedo all'opposto. È l'unica versione che lascerei operare senza supervisione, perché l'alternativa all'inoltro in questo caso è un azzardo rapido su denaro reale, travestito da decisione.
La cifra del portafoglio su cui continuo a tornare
Continuo a riaprire il portafoglio da otto sedi, perché rende la posta in gioco concreta come nessun caso isolato potrebbe fare. Una tempesta attraversa un portafoglio di otto aree. Il trigger tradizionale a singolo fotogramma scatta su sei di esse e mette in coda 8,0 milioni di dollari in liquidazioni automatiche. TriggerProof giudica il portafoglio: due vere inondazioni confermate e pagate per 4,0 milioni di dollari, tre falsi positivi bloccati (un'ombra di nuvola da 1,2 milioni di dollari, un'ombra radar da 1,0 milioni di dollari, un bacino permanente da 1,0 milioni di dollari) per 3,2 milioni di dollari trattenuti, e l'unico caso ambiguo inoltrato a revisione per 0,8 milioni di dollari.
La metà di quanto il trigger tradizionale avrebbe liquidato, 4,0 milioni su 8,0 milioni di dollari, viene bloccata o trattenuta per verifica. Questo è il dato, e voglio essere preciso sul suo perimetro: si tratta del portafoglio sintetico della demo, otto casi che ho ideato per essere fisicamente fedeli, non un portafoglio di sinistri reali. Il meccanismo è reale e ispezionabile. I sinistri sono simulati affinché possiate osservare il meccanismo all'opera.
Zero decisioni non sicure, e l'avvertenza a cui non intendo rinunciare
Ho eseguito un benchmark vero e proprio perché un portafoglio di otto casi è un aneddoto, non una prova. Il test valuta 60 casi etichettati, spaziando da firme inequivocabili fino a rumori prossimi alla soglia. Il risultato principale non è un punteggio di accuratezza, è un conteggio di sicurezza: zero decisioni automatizzate non sicure, contro le 48 del riferimento a singolo fotogramma che liquida ogni caso segnalato. L'ottanta percento dei casi si risolve automaticamente e il 20% incerto viene inoltrato a revisione. Tra i casi risolti automaticamente, la soppressione dei falsi positivi è di 36 su 36 e il recupero delle inondazioni è di 12 su 12, e ciascuno dei 12 casi realmente ambigui viene inoltrato a un operatore invece di essere deciso in automatico.
L'obiettivo non è mai stato ottenere un punteggio perfetto sul mio set di test. Il punto è che il sistema non prende mai una decisione automatizzata non sicura. Quando non è sicuro, inoltra a revisione.
L'avvertenza accompagna ciascuno di quei numeri, e non permetterò che venga rimossa. Sono misurati su un insieme fisso ed etichettato di 60 casi sintetici e fisicamente fedeli, non costituiscono una garanzia sul mondo reale né un risultato sul campo. Il passo successivo più onesto non è avanzare una pretesa più ambiziosa, ma la validazione su archivi reali come Sen1Floods11 e scene Sentinel dal vivo: questo è il primo risultato che un incarico reale produrrebbe, non qualcosa che questa demo ha realizzato. Dichiararlo apertamente è ciò che mi consente di sostenere con certezza tutti gli altri numeri.
Una liquidazione che non puoi difendere a posteriori è una passività, anche quando era corretta
Non sono partito con l'idea di rendere la traccia probatoria il fulcro di tutto, ma alla fine era la parte su cui ero più certo che un assicuratore potesse davvero contare. Una liquidazione corretta che non puoi ricostruire in seguito è comunque una passività, perché "lo diceva il satellite" non è una difesa che un riassicuratore o un revisore dei conti accetti. Così ogni decisione, sia un pagamento che un blocco, produce un dossier forense: la genealogia dei dati di ogni fotogramma, le prove per ciascuna regola con il valore misurato di ogni discriminatore, il registro di eliminazione dei falsi positivi, il riscontro incrociato indipendente a terra e un hash SHA-256 di provenienza della decisione.
Voglio essere preciso su cosa sia e cosa non sia quell'hash. È un hash del contenuto che rende il record a prova di manomissione, consentendo a chiunque di ricalcolarlo e verificare che la decisione non sia stata alterata a posteriori. Non è una firma digitale PKI, e l'acquisizione satellitare, la pianificazione SAR, i feed da terra e l'integrazione con la piattaforma dei sinistri sono tutti simulati con stub in questa demo, affinché l'intero sistema possa girare sul mio portatile. Ciò che è reale è la struttura del record: per ogni decisione di liquidazione automatica, esattamente quale principio fisico ha rilevato cosa, con quale livello di confidenza, confrontato con quale segnale indipendente.
L'assicurazione parametrica ha fatto un compromesso concreto, rinunciando al perito liquidatore per rendere i pagamenti immediati e incontestabili. Ciò che ha ereditato è un problema di fisica che non può superare su un singolo fotogramma, e il fallimento a cui questo compromesso espone è una liquidazione rapida e sicura per un'ombra. La soluzione duratura risiede al di fuori del modello: regole deterministiche che separano i casi ingannevolmente simili nel tempo e attraverso i sensori, un gate che inoltra il caso ambiguo a una persona e un record che rende ogni decisione difendibile. Un satellite più nitido non risolve un problema di valutazione, e questo è a tutti gli effetti un problema di valutazione.
E se preferite vederlo all'opera piuttosto che leggermi mentre lo descrivo, ecco l'intero sistema in funzione dall'inizio alla fine.
Mesa Junction è il caso a cui continuo a tornare. Solo la seconda acquisizione ha saputo distinguere tra l'ombra e l'inondazione, e il trigger è scattato prima del suo arrivo. Potete scorrere voi stessi quella sequenza di fotogrammi e smentire la liquidazione che credevate dovesse scattare, all'indirizzo veriprajna.com/it/demos/satellite-flood-intelligence-aggiudicare-il-trigger-parametrico-prima-della-liquidazione. La domanda che porrei a chiunque gestisca un portafoglio automatico contro le inondazioni è precisa e puntuale: dei trigger che avete liquidato automaticamente nella scorsa stagione, per quanti potreste ancora dimostrare che si trattava di acqua e non di un'ombra?
