PythagorasGoal/docs/diary/2026-07-26-edge-death.md

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.