# 2026-07-26 — "come faccio a capire se l'edge è morto?" Domanda dell'operatore dopo la misura del decadimento. Scopre un buco: il progetto ha gate di kill **pre-registrati per i candidati** (DVOLSPREAD 24/10, XSR01 23/10, STATARB 27/09) e **nessuno per il book che gira con soldi veri**. La risposta implicita era "si vedrà" — cioè esattamente ciò che il progetto non accetta dai candidati. **Script:** `r0726_edge_death.py` (taratura) + `scripts/live/edge_watch.py` (sorveglianza, cablata in `cron_daily.sh`). **Test:** `tests/test_edge_watch.py` (11). **Book/pesi/config INVARIATI.** --- ## 1. La risposta scomoda: non puoi saperlo in fretta Con Sharpe ~1.6 e vol ~8%, un anno di risultati non distingue nulla. Distribuzione dello Sharpe rolling su 4.000 percorsi bootstrap, con edge **vivo** e con edge **morto** (drift a zero, stessa vol): ``` finestra VIVO (p5..p50..p95) MORTO (p5..p50..p95) sovrapposizione 6m -1.06 1.60 4.15 -3.24 -0.10 2.71 67.8% 12m -0.24 1.62 3.43 -2.20 -0.04 1.99 56.0% 24m 0.34 1.64 2.92 -1.51 -0.02 1.44 34.6% 36m 0.57 1.62 2.68 -1.22 -0.03 1.19 21.1% ``` **A 12 mesi il 56% dei casi "morto" è indistinguibile da uno vivo.** Un anno brutto non è informazione, è rumore. ## 2. La taratura: falsi kill contro velocità *"Sharpe rolling a N mesi scende sotto S almeno una volta in 10 anni"*, con edge **intatto** — cioè quanto spesso la regola ucciderebbe una strategia che funziona: ``` finestra S<-0.5 S<0.0 S<+0.5 6m 100.0% 100.0% 100.0% 12m 80.5% 95.9% 99.5% 24m 14.1% 43.7% 78.8% 36m 1.8% 12.3% 43.2% ``` Con il controllo positivo (edge davvero morto) accanto: | finestra | soglia | falso kill | lo prende | rilevamento mediano | |---|---|---|---|---| | 12m | −0.5 | 80.5% | 100% | 1.1 anni | | 24m | −0.5 | 14.1% | 98.5% | 2.5 anni | | **36m** | **−0.5** | **1.8%** | **90.8%** | **3.8 anni** | **→ CRITERIO A: Sharpe rolling 36 mesi sotto −0.5.** Falso kill 1.8% in 10 anni, riconosce l'edge morto nel 91% dei casi, in **3.8 anni** mediani. ⚠️ **La lentezza non è un difetto della regola: è statistica.** Una versione a 12 mesi ucciderebbe un edge vivo nell'80% dei casi. **Non esiste una versione veloce e onesta.** ## 3. TP01 non si giudica così — e questo è il punto Il leave-one-out del 26/07 ha misurato il contributo hold-out di TP01 **negativo nel 99.1% delle configurazioni d'ancora**. È la firma dell'assicurazione: paga premio negli anni senza incendio. **"Non ha guadagnato" non è evidenza di morte per uno sleeve difensivo** — la sua morte è *non proteggere quando serve*. ``` anno DD buy&hold DD TP01 protezione 2019 56.4% 10.3% 5.5x 2020 59.2% 8.4% 7.0x 2021 52.0% 6.8% 7.6x 2022 68.4% 2.8% 24.2x 2023 22.0% 12.3% 1.8x <- il peggiore, e passa comunque 2024 35.6% 7.1% 5.0x 2025 45.1% 6.8% 6.6x 2026 46.6% 1.4% 34.4x ``` **→ CRITERIO B: in un anno con DD buy&hold > 10%, il DD di TP01 deve restare sotto il 75% di quello.** Storico: **8 anni di sinistro, 8/8 superati**. Negli anni **senza** sinistro il criterio non si valuta: non c'è informazione. Questo criterio è **veloce** dove l'altro è lento — si pronuncia a ogni anno con un crash, che nel campione è ogni anno. ## 4. Cosa succede se scattano Dichiarato ora per non doverlo decidere nel momento sbagliato: * **(A) scatta** → il book **non si spegne da solo**. Si apre una revisione: `weights_tilt_null` + deflated-Sharpe ricalcolato sui dati nuovi. Spegnere è una decisione dell'operatore. * **(B) fallito in due anni di sinistro consecutivi** → TP01 non assicura più, e il suo peso (75%) va rimesso in discussione: proteggere è **l'unico motivo** per cui sta lì. Cablato in `cron_daily.sh`, allerta Telegram, non tocca l'esecuzione. Stato al 2026-07-26: **Sharpe 36m +1.51**, protezione **8/8**. ## 5. Il limite, di nuovo Il criterio A misura se l'edge è morto **dopo** che è morto, con ~4 anni di ritardo. Questo non è riparabile con una regola migliore — è il contenuto informativo dei dati. La difesa vera non è la rilevazione: è che **il piano regge a un edge dimezzato** (misurato: traguardo da 11.6 a 15.8 anni, P(entro 20a) ancora 77%) e che i rischi *veloci* — venue, esecuzione, feed — hanno sorveglianze proprie che scattano in ore. ## 6. Regole trasferibili 1. **Se si pretende un gate di kill dai candidati, se ne deve avere uno per ciò che gira.** L'asimmetria era invisibile finché non è stata nominata. 2. **Un criterio di kill si tara sul nullo e si valida su un controllo positivo** — identico al tripwire di venue costruito lo stesso giorno. "Non è mai scattato" non è una buona notizia finché non si è provato che sa scattare. 3. **Uno sleeve difensivo richiede un criterio DIVERSO**, o lo si uccide per aver fatto il suo mestiere. Il criterio giusto guarda il sinistro, e negli anni senza sinistro **non si valuta**. 4. **Quando la rilevazione è strutturalmente lenta, dirlo e spostare la difesa altrove** invece di accorciare la finestra fino a ottenere una risposta veloce e falsa.