Adriano Dal Pastro
a1b4416ac0
"Come faccio a capire se l'edge e' morto?" 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 vedra'", cioe' quello che il progetto non accetta dai candidati. LA RISPOSTA SCOMODA: non si puo' sapere in fretta. Sharpe rolling a 12 mesi: il 56% dei casi "edge morto" e' indistinguibile da uno vivo. Un anno brutto e' rumore, non informazione. CRITERIO A (ritorno, book intero): Sharpe rolling 36 mesi sotto -0.5. Tarato sul nullo (edge intatto) -> falso kill 1.8% in 10 anni; controllo positivo (edge morto) -> lo riconosce nel 91% dei casi, rilevamento mediano 3.8 anni. La lentezza non e' un difetto della regola ma statistica: a 12 mesi la stessa regola ucciderebbe un edge VIVO nell'80% dei casi. Non esiste una versione veloce e onesta. CRITERIO B (TP01, che e' DIFENSIVO): serve un criterio diverso perche' il LOO del 26/07 ha misurato il contributo hold-out di TP01 negativo nel 99.1% delle configurazioni d'ancora — firma dell'assicurazione, che paga premio negli anni senza incendio. "Non ha guadagnato" NON e' evidenza di morte. Criterio: in un anno con DD buy&hold > 10%, il DD di TP01 deve restare sotto il 75%. Storico 8 anni di sinistro, 8/8 superati (protezione 1.8x-34.4x). Negli anni SENZA sinistro il criterio non si valuta: non c'e' informazione. Questo criterio e' VELOCE dove l'altro e' lento. COSA SUCCEDE SE SCATTANO (dichiarato ora per non deciderlo nel momento sbagliato): (A) il book NON si spegne da solo -> revisione con weights_tilt_null + deflated-Sharpe sui dati nuovi; spegnere e' decisione dell'operatore. (B) fallito in DUE anni di sinistro consecutivi -> TP01 non assicura piu' e il peso 75% va rimesso in discussione. CABLATO: scripts/live/edge_watch.py in cron_daily.sh, allerta Telegram, non tocca l'esecuzione. Stato oggi: Sharpe 36m +1.51, protezione 8/8. IL LIMITE, DETTO: il criterio A rileva la morte ~4 anni dopo, e non e' riparabile con una regola migliore (e' il contenuto informativo dei dati). La difesa vera e' che il piano regge a un edge dimezzato (11.6 -> 15.8 anni, P(20a) ancora 77%) e che i rischi VELOCI (venue, esecuzione, feed) hanno sorveglianze che scattano in ore. 404 test verdi (+11). Book, pesi, config INVARIATI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
113 lines
5.3 KiB
Markdown
113 lines
5.3 KiB
Markdown
# 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.
|