Satellite Flood Intelligence · Assicurazione parametrica
La copertura alluvionale parametrica liquida automaticamente l'indennizzo quando un satellite indica che una località è allagata. Tuttavia, un singolo fotogramma ottico o radar non può distinguere l'acqua di inondazione dall'ombra di una nuvola, dall'ombra del radar o del terreno, o da un bacino idrico permanente, poiché tutte e quattro scuriscono gli stessi pixel. TriggerProof assume il trigger già attivato come dato e dimostra se debba pagare: un verificatore fisico deterministico a cinque regole decide, un LLM si limita a consigliare, i casi incerti vengono inoltrati a un perito umano invece di essere liquidati automaticamente e ogni decisione lascia un dossier forense. Gli agenti consigliano, il codice decide.
$4.0M su $8.0M
Liquidazioni in coda automatica trattenute o bloccate in attesa di prova (3 falsi trigger soppressi, 1 inoltrato a revisione). Gli altri $4.0M liquidati su 2 alluvioni confermate
Scenario di portafoglio sintetico a 8 AOI della demo
0 non sicure
Decisioni automatizzate non sicure rispetto alle 48 della baseline a singolo fotogramma, che liquida ogni caso segnalato
Benchmark sintetico etichettato su 60 casi
100% / 100%
Soppressione dei falsi positivi (36/36) e recall delle alluvioni (12/12) tra l'80 per cento dei casi risolti automaticamente
Benchmark sintetico etichettato su 60 casi
Una demo eseguibile del meccanismo di aggiudicazione. Il verificatore e il policy gate funzionano interamente in puro Python senza alcuna chiave API; solo l'agente consultivo di controllo incrociato può chiamare un modello, e non decide mai la liquidazione. Ogni tessera satellitare, area di interesse e segnale a terra è sintetico e fisicamente fedele, non sono dati reali di Sentinel o di assicuratori.
L'assicurazione parametrica contro le alluvioni ha sostituito il perito liquidatore con un trigger satellitare per rendere istantanee le liquidazioni. Il trigger ha però ereditato un problema fisico al di là del quale non può vedere.
Quando un trigger si attiva, viene sbloccato un pagamento di milioni senza alcun perito sul posto. Il punto di forza è la rapidità e l'assenza di controversie. L'esposizione risiede nel fatto che si chiede a un singolo fotogramma — una lettura NDWI o MNDWI su un'immagine ottica o un singolo passaggio SAR — di decidere se il terreno sia effettivamente sott'acqua. Spesso non è in grado di farlo. L'ombra di una nuvola scurisce una scena ottica esattamente dove lo farebbe un'inondazione. L'ombra del radar o del terreno riduce il backscatter SAR allo stesso modo dell'acqua stagnante reale. Un bacino idrico permanente viene letto come acqua perché è acqua, semplicemente non è acqua nuova.
La vera modalità di fallimento del trigger non è quindi l'alluvione non rilevata. È il falso positivo formulato con certezza: una liquidazione attivata da un'ombra, erogata prima che chiunque possa verificare e senza alcun registro che consenta a un riassicuratore o a un auditor di verificare la decisione a posteriori. Questa è la forma più onerosa di rischio di base: pagare su un trigger che non è mai stato un danno reale; ed è la debolezza strutturale intrinseca di un portafoglio alluvionale parametrico, non un raro caso limite.
Una singola immagine migliore non risolve questo problema. Né lo fa un modello più intelligente a cui venga chiesto di valutare lo stesso fotogramma isolato. Distinguere l'acqua di inondazione dai suoi tre sosia è una questione di come una firma si comporta nel tempo e tra sensori diversi, e se la decisione possa essere difesa a posteriori. Questi sono i due divari che ci siamo prefissati di colmare, e nessuno dei due risiede all'interno di un modello di rilevamento.
La pipeline riceve un trigger attivato e restituisce PAY, DENY o ESCALATE. La decisione risiede in codice trasparente e ispezionabile, mai in un modello.
TriggerProof non rileva alluvioni. Aggiudica un trigger che è già scattato. Ciascun trigger attivato viene sottoposto a un verificatore fisico a cinque regole, confrontato con segnali a terra indipendenti da parte di un agente consultivo, e quindi instradato da un policy gate che ne dispone il pagamento (PAY), il rifiuto (DENY) o l'inoltro a un perito umano (ESCALATE). Alla fine, ogni caso produce un dossier forense.
Il verificatore a cinque regole è scritto in puro Python senza alcun modello nel loop. Emette una classificazione e un punteggio di confidenza, ed è il componente che stabilisce se un trigger corrisponda a un'alluvione reale. È ispezionabile e riproducibile: eseguendolo nuovamente sullo stesso caso si ottengono lo stesso verdetto e le medesime letture per ogni regola, consentendo a un riassicuratore o a un auditor di verificare la decisione anziché accettarla sulla fiducia.
Un Contextual Cross-Reference Agent, basato su Pydantic AI e con impostazione predefinita su claude-opus-4-8, confronta il verdetto fisico con segnali a terra indipendenti come idrometri fluviali, precipitazioni e relazioni sul campo, restituendo corroborates, contradicts o inconclusive. Consente l'intercambiabilità dei provider e dispone di un fallback deterministico per consentire alla demo di funzionare completamente offline. Fornisce pareri consultivi e può essere smentito. Non decide mai la liquidazione.
| Regola | Discriminatore | Cosa separa |
|---|---|---|
| R1 | Persistenza temporale | Un'alluvione persiste attraverso le acquisizioni; l'ombra di una nuvola è transitoria e scompare nel fotogramma successivo. |
| R2 | Concordanza ottico-SAR | Un'alluvione è scura nell'ottico e bassa nel SAR; l'ombra di una nuvola è scura nell'ottico ma normale nel SAR; l'ombra radar è bassa nel SAR ma luminosa nell'ottico. |
| R3 | Pendenza DEM | L'acqua non può ristagnare su terreni ripidi, il che segnala distorsioni da layover e ombre del terreno. |
| R4 | Maschera delle acque permanenti | I bacini idrici e i laghi noti vengono esclusi, intercettando i falsi trigger causati da bacini preesistenti. |
| R5 | Collegamento idrologico | Un'alluvione reale si connette alla rete di drenaggio; una macchia scura isolata no. |
Il policy gate rende le soglie visibili e verificabili dagli auditor. Se l'agente contraddice la fisica, o se la confidenza scende al di sotto della soglia di automazione calibrata di 0.65, il caso viene inoltrato a un perito umano contrassegnato come 'richiede prova' (needs proof), senza mai essere deciso automaticamente. In caso contrario, una classificazione di alluvione viene liquidata (PAY) e qualsiasi classe non alluvionale viene rifiutata (DENY). Il valore duraturo risiede nel verificatore e nel gate, non in un rilevatore più sofisticato: persino un classificatore a singolo fotogramma perfetto non è comunque in grado di inoltrare il caso ambiguo né di consegnare a un riassicuratore un registro difendibile. Questi sono compiti di governance e, per progettazione, si collocano all'esterno del modello di rilevamento.
Ogni dato riportato di seguito è il risultato riproducibile dell'infrastruttura deterministica della demo, calcolato a runtime. Ogni area di interesse, idrometro fluviale e relazione sul campo è sintetica e fisicamente fedele. Non viene utilizzata alcuna scena reale Sentinel, località, assicuratore o sinistro.
Una tempesta attraversa un portafoglio di 8 aree di interesse. Il trigger tradizionale a singolo fotogramma è scattato su 6 di esse, mettendo in coda 8.0 milioni di dollari USA di liquidazioni automatiche. Nulla in questa vista distingue un'alluvione reale da un'ombra o da un bacino idrico, perché un singolo fotogramma non può farlo. Ogni riga attivata sta per essere elaborata attraverso le fasi di verifica, controllo incrociato e policy gate.
TriggerProof aggiudica il portafoglio. Conferma 2 alluvioni reali da liquidare per 4.0 milioni di dollari USA, sopprime 3 falsi trigger trattenendo 3.2 milioni (un'ombra di nuvola da 1.2 milioni, un'ombra radar da 1.0 milioni e un bacino idrico permanente da 1.0 milioni) e inoltra 1 caso limite da 0.8 milioni a un perito umano. Degli 8.0 milioni che il trigger tradizionale avrebbe liquidato automaticamente, 4.0 milioni vengono bloccati o trattenuti in attesa di prova, e ogni decisione include un dossier forense, portando la copertura delle evidenze al 100 per cento.
Apriamo AOI-B, Mesa Junction Depot, e scorriamo i fotogrammi di acquisizione. La macchia scura ottica che ha fatto scattare il trigger compare solo nel fotogramma del trigger ed è scomparsa nell'acquisizione successiva, mentre il backscatter SAR è rimasto normale per tutto il tempo. Il radar ha visto terreno asciutto attraverso la nuvola. Il verificatore la classifica come ombra di nuvola (cloud shadow) con confidenza 1.00 e rifiuta la liquidazione di 1.2 milioni di dollari USA. L'ombra si è mossa; l'acqua di una vera inondazione sarebbe rimasta.
La medesima sequenza temporale su AOI-A, Rio Verde Terminal, mostra l'opposto. La firma dell'acqua persiste in ogni fotogramma di acquisizione sia nell'ottico che nel SAR, il terreno è sufficientemente pianeggiante da consentire il ristagno dell'acqua, la regione è collegata alla rete di drenaggio e l'idrometro fluviale indipendente corrobora i dati. Il verificatore la classifica come alluvione (flood) con confidenza 0.99 e liquida il trigger da 2.0 milioni di dollari USA. Il meccanismo non è orientato al rifiuto; è orientato alla prova, e qui la prova è presente.
AOI-F, Canal Street Hub, è il caso che la fisica non può risolvere. La firma è al limite, la confidenza del verificatore si attesta a 0.15 e l'idrometro fluviale indipendente non ha mai superato il livello di piena, quindi le evidenze a terra sono in contrasto con il trigger. Poiché la confidenza è inferiore alla soglia di automazione di 0.65, il policy gate inoltra il caso da 0.8 milioni di dollari USA a un perito umano con allegato il quadro probatorio completo, anziché azzardare una decisione automatica. Inoltrare il caso ambiguo è la caratteristica fondante del sistema, non un suo fallimento.
Ogni verdetto genera un dossier forense del trigger alluvionale. Contiene le evidenze regola per regola per tutti e cinque i discriminatori con i relativi valori misurati ed esiti positivi o negativi, un registro di eliminazione dei falsi positivi, il verdetto di controllo incrociato contestuale, la data lineage per ciascuna acquisizione simulata e un hash di provenienza SHA-256 della decisione. Per precisione sull'ambito, l'hash SHA-256 è un hash di contenuto a prova di manomissione, non una firma digitale PKI, e le immagini sono sintetiche. Ciò che il dossier dimostra è che la decisione è documentata anziché semplicemente asserita.
Il singolo portafoglio non è un risultato fortuito. Su un benchmark fisso di 60 casi sintetici etichettati, da firme evidenti a rumore vicino alla soglia, TriggerProof prende 0 decisioni automatizzate non sicure rispetto alle 48 della baseline a singolo fotogramma, che liquida ogni caso segnalato. Risolve automaticamente l'80 per cento dei casi e ne inoltra a revisione il 20 per cento; tra i casi risolti automaticamente, sopprime 36 falsi trigger su 36 e liquida 12 alluvioni reali su 12. La dichiarazione è volutamente circoscritta: su questo set etichettato il sistema non prende mai una decisione automatizzata non sicura, poiché inoltra a revisione quando la fisica è incerta.
È il livello di aggiudicazione e governance tra un trigger attivato e la liquidazione, non un prodotto di dati satellitari né un rilevatore di alluvioni.
| Aspetto | Il solo trigger a singolo fotogramma | Questo livello di aggiudicazione |
|---|---|---|
| Un'ombra di nuvola, un'ombra radar o un bacino idrico | Liquidato come alluvione; tutte e quattro le condizioni scuriscono gli stessi pixel | Rifiutato da cinque regole fisiche deterministiche nel tempo e tra sensori |
| Un caso realmente ambiguo | Liquidato automaticamente sulla base di un segnale casuale come un lancio di moneta | Inoltrato a un perito umano al di sotto della soglia di confidenza di 0.65, con le evidenze allegate |
| Perché un trigger è stato liquidato o rifiutato | Nessun registro oltre al flag di attivazione | Un dossier forense: evidenze per regola, registro di eliminazione, provenienza SHA-256 |
| Chi prende la decisione di liquidazione | Una soglia di pixel su un singolo fotogramma | Python deterministico; l'LLM consiglia e può essere smentito |
| Rischio di base da falsi trigger | Sostenuto integralmente su ogni falso allarme che segnala | 0 decisioni automatizzate non sicure rispetto a 48 sul benchmark etichettato di 60 casi |
| Lock-in di modelli e fornitori | Vincolato all'output di un singolo rilevatore | Il verificatore funziona offline; l'agente consultivo è intercambiabile tra provider |
Perché un trigger a singolo fotogramma non può distinguere l'acqua di inondazione dall'ombra di una nuvola, dall'ombra del radar o del terreno, o da un bacino idrico permanente, e tutti e tre si scuriscono allo stesso modo. Quando una liquidazione scatta su tale valutazione, un 'probabilmente allagato' non è sufficiente e non vi è alcuna traccia probatoria per difendere la scelta a posteriori. TriggerProof assume il trigger attivato come dato e lo aggiudica in PAY, DENY o ESCALATE mediante fisica deterministica. Sul portafoglio sintetico a 8 AOI della demo, ciò blocca o trattiene 4.0 milioni di dollari USA su 8.0 milioni di liquidazioni in coda automatica.
Solo per i casi che sono realmente ambigui. Sul benchmark etichettato di 60 casi, TriggerProof risolve automaticamente l'80 per cento e inoltra a revisione il 20 per cento, garantendo che le alluvioni evidenti vengano comunque liquidate all'istante e che solo i casi limite o contraddittori vengano instradati a una persona, con l'intero fascicolo probatorio già allegato. Questo è il compromesso: una liquidazione automatica rapida rimane rapida, mentre il caso che altrimenti sarebbe un falso positivo conclamato viene affidato a un essere umano anziché a un'errata decisione da 0.8 milioni di dollari USA.
Nessuna. Ciascuna tessera, area di interesse, idrometro fluviale, lettura delle precipitazioni e relazione sul campo nella demo è sintetica e fisicamente fedele, e non esiste alcuna scena reale Sentinel, località reale, assicuratore reale o sinistro reale. I connettori per l'acquisizione satellitare, il tasking SAR, i feed dei segnali a terra e l'integrazione con le piattaforme sinistri sono basati su stub. La validazione sul campo rispetto ad archivi reali come Sen1Floods11 o a un portafoglio Sentinel attivo è il primo deliverable di un progetto operativo, non una pretesa avanzata da questa demo.
Una singola immagine a più alta risoluzione non è comunque in grado di distinguere da sola un'alluvione da un'ombra o da un bacino idrico, poiché il problema è temporale e multi-sensoriale, non di risoluzione. TriggerProof non rileva alluvioni e non produce dati satellitari. Aggiudica un trigger già scattato verificando la persistenza attraverso le acquisizioni, la concordanza tra SAR e ottico, la pendenza del terreno, la maschera delle acque permanenti e la connessione idrologica. Il valore duraturo è il livello di governance che circonda la decisione, motivo per cui non diventa obsoleto con il progredire dei modelli di rilevamento.
Un dossier forense, non un semplice punteggio. Ciascuna decisione produce le evidenze per ogni regola per tutti e cinque i discriminatori con i rispettivi valori misurati ed esiti positivi o negativi, un registro di eliminazione dei falsi positivi, il controllo incrociato indipendente a terra, la data lineage satellitare e un hash di provenienza SHA-256 della decisione. È esportabile in formato JSON e HTML stampabile, consentendo a un perito, a un riassicuratore o a un auditor di comprendere con precisione perché un caso sia stato liquidato, rifiutato o trattenuto in attesa di prova.
Fanno riferimento a un set fisso ed etichettato di 60 casi sintetici e fisicamente fedeli che spaziano da firme evidenti a rumore vicino alla soglia, non a una garanzia sul campo o in ambiente aperto. Su tale set TriggerProof compie 0 decisioni automatizzate non sicure contro le 48 della baseline a fotogramma singolo, e tra i casi risolti automaticamente sopprime 36 falsi trigger su 36 e liquida 12 alluvioni reali su 12. Il punto non è un punteggio perfetto, ma il fatto che il sistema non prende mai una decisione automatizzata non sicura, poiché inoltra a revisione quando la fisica è incerta.
No. Il verificatore deterministico e il policy gate sono in puro Python e funzionano completamente offline senza alcuna chiave API, pertanto la decisione di liquidazione non dipende mai dalla disponibilità di un modello. L'agente consultivo è basato su Pydantic AI ed è intercambiabile tra diversi provider come Anthropic, OpenAI, Gemini e Ollama, con impostazione predefinita su claude-opus-4-8 e fallback deterministico. L'acquisizione satellitare e l'integrazione dei sinistri sono progettate come adattatori, consentendo al livello di integrarsi sui sensori e sulle piattaforme che già utilizzate.
La ricerca alla base di questa demo: l'architettura, la progettazione della verifica e il blueprint aziendale.
Soluzione completa
Esplora la soluzione Satellite Flood Intelligence for Parametric Insurance →Sopprimete i falsi trigger mediante la fisica, inoltrate quelli incerti a una persona e create un fascicolo difendibile per ogni decisione.
Se il vostro team gestisce un portafoglio di trigger alluvionali automatici e sta cercando di mantenere pagamenti rapidi senza risarcire le ombre, vorremmo confrontarci su dove tracciate il confine tra una decisione automatica e una umana. È una linea di demarcazione complessa e stiamo continuando a perfezionare la nostra.