research(wave-0822): ORTHO-SCREEN 7/7 scartato (e uno screen largo non puo' passare il proprio DSR); XS-LITE falsifica il muro dei 20k di XS01

This commit is contained in:
Adriano Dal Pastro
2026-08-22 17:12:15 +00:00
parent 14c1a75a7e
commit bd5b634209
6 changed files with 256 additions and 79 deletions
+49
View File
@@ -8,6 +8,8 @@ null de-levering superato + eseguibilita' al capitale dichiarato.
|---|---|---|---|
| 9 | ADAPTIVE-HORIZON | **SCARTATO** | il "vincitore adattivo" ha lookback incollato al bordo il 100% del tempo = TSMOM costante a 20g (corr 1.000, dSh 0.00 in 8/8 anni e 0/12 ancore); isolando le celle davvero adattive -> NEUTRAL, corr→TP01 0.90 = TP01 travestito || 4 | DEALER-GAMMA | **SCARTATO** | la gamba tradeable e' INCOERENTE (BTC non separa, ETH separa al ROVESCIO); cio' che resta e' quasi tutto DVOL (corr 0.66), gia' refutato il 26/06. DSR 0.440 e la cella migliore sta SOTTO il massimo atteso dal rumore |
| 2 | GROWTH-POLICY | **LEAD** (condizione, non data) | il libro gira al **7% di Kelly** e raccoglie il **15%** della crescita massima in log; il gradino eseguibile 1.00x->1.25-1.50x vale 14.7a -> 12.9-11.6a al muro. Ma un solo giorno -10% all'anno porta k* da ~10x a **2x**: non si decide su un conto vero con la lente close-only |
| 12 | ORTHO-SCREEN | **SCARTATO 7/7** | nessuna famiglia arriva a ADDS+DSR; e il motivo e' **aritmetico**: su 168 trial il massimo atteso dal rumore e' Sharpe **1.572**, SOPRA il soffitto direzionale misurato (~1.3) -> uno screen largo su BTC/ETH direzionale **non puo'** passare un DSR, per costruzione |
| 3 | XS-LITE | **SCARTATO** (come sleeve) + **1 soglia pubblicata falsificata** | concentrare XS01 non crea uno sleeve nuovo (corr 0.81-0.96 col canonico, DSR FAIL, de-levering non superato) — ma il muro *"XS01 serve ~$20k"* e' misurato su una diagnostica di TURNOVER: il ribilancio vero smette di passare sotto **~$109 di sleeve (~$730 di book), 27x piu' in basso** |
## Note che sopravvivono ai singoli filoni
@@ -69,3 +71,50 @@ vedono la variabile**. E' per questo che la leva e' l'unica leva del libro mai e
- 📌 **Sottoprodotto da verificare (tocca un'etichetta del libro live):** a `target_vol=20%` la vol
**realizzata** di TP01 e' **12,14%** — il target vale sulla posizione quando c'e', e TP01 e'
long-flat. **L'etichetta sovrastima il rischio preso di ~40%.**
### 12 — ORTHO-SCREEN (r0822_ortho_screen.py, 174 trial: 7 famiglie x 24 + 6 controlli)
📌 **Il risultato piu' riusabile dell'ondata, ed e' metodologico:** il deflated-Sharpe va calcolato
**di screen** (168 trial) e non solo di famiglia (24). Su quel pool il massimo atteso dal puro rumore
e' **Sharpe 1.572**, cioe' **sopra il soffitto direzionale misurato del progetto (~1.3)**.
**Conseguenza: una ricerca a rete larga su un singolo stream direzionale BTC/ETH non puo' passare il
proprio gate — non e' sfortuna, e' aritmetica.** Le ondate future o dichiarano famiglie molto piu'
piccole in anticipo, o cambiano meccanismo (non-direzionale / cross-sectional).
📌 **Per la prima volta nel progetto l'eseguibilita' a $600 non e' il vincolo binding di niente**
(haircut 0.00-0.01 su 7/7): muore tutto molto prima, sull'edge.
- Famiglie: RSKEW (skew realizzata), TACC (accelerazione del trend), VPX (volume-prezzo), XDISP
(dispersione dei 51 alt come timer), XCORR (corr BTC-ETH), XTAIL (dopo shock 3σ), VRAT
(variance-ratio). Miglior DSR di famiglia 0.633, di screen **0.034**. `robust_oos` False 7/7.
- **TACC** e' l'unica ADDS (corr→TP01 0.09) ma il suo uplift hold-out **vive tutto nel 2026** (2025
da solo 0.314) = finestra fortunata. E la domanda della famiglia ha risposta: **e' il LIVELLO,
non l'accelerazione** — la cella scelta si riduce al ritorno a 5 giorni, corr **+0.784** col
momentum di livello.
-**Tre falsificazioni che chiudono spazio:** (1) la mean-reversion **non torna in vita** sotto due
conditioner mai provati (volume, shock 3σ): la selezione in-sample sceglie il ramo di
CONTINUAZIONE in entrambi i casi; (2) la dispersione dei 51 alt come timer di mercato e'
**negativa** (0.899 sulla sola finestra attiva, non e' un artefatto di calendario); (3) RSKEW e'
il ritratto del fitting — **miglior in-sample dello screen (1.281) e peggior hold-out (0.494)**,
col segno OPPOSTO all'a-priori teorico dichiarato.
- ⚠️ **6ª occorrenza del null del de-levering** (VRAT, maxDD 4.4% -> `k*TP01` fa meglio).
- ⚠️ Due candidati hanno l'ancora canonica come **PEGGIORE** delle 8 (TACC, VRAT): la fortuna
d'ancora non ha un verso fisso, e guardare solo il canonico a volte **inventa un danno**.
### 3 — XS-LITE (r0822_xs_lite.py, 26 celle + 120 valutazioni d'ancora)
✅ Repliche **bit-exact** prima di ogni delta: XS01 vs `sleeves._xsec_returns` e XSR01 vs
`basket_from_positions(demean=True)`, entrambe `max|diff| = 0.0`.
📌 **Falsificazione di un numero pubblicato:** il muro *"XS01 serve ~$20k"* non e' un fatto di
Sharpe ma di **turnover** — e a capitale piccolo il min-order salta la **deriva del vol-target**
(|Δw| giornaliero 0.001) che **non porta segnale**, non il ribilancio (|Δw| 0.091-0.157). Capitale
minimo perche' il ribilancio passi: **$109 (k=5) / $86 (k=3) / $64 (k=2)** di sleeve. Stessa lezione
gia' imparata su TP01 nel 2026 ("a $600 il min-order e' gia' la banda ottimale") e **mai applicata a
XS01**. ⚠️ L'agente ha usato **min-order $10 (Hyperliquid)**, non $5 (Deribit) — un audit dedicato
sta verificando i minimi veri del venue.
- Concentrare **non** ripara il rischio #1 di XSR01: XS-LITE regge oltre **50 bps/gamba**, XSR-LITE
muore a **~28 bps a ogni k, pieno incluso**.
- La radice dell'ampiezza **non descrive** XS01: da 10 a 4 gambe si perde il **2%** di Sharpe
mediano-di-fase mentre N_hhi passa 6.9 -> 3.0 (il segnale sta negli **estremi** del ranking; le
gambe 3-5 per lato aggiungono rischio quanto segnale). Il collasso arriva solo a k=1 (41%).
- ⚠️ **Da inseguire — tocca un gate pre-registrato: lo Sharpe 1.82 di XSR01 NON si riproduce oggi.**
Sulla finestra identica a quella di scoperta la lente "paniere" da' **1.75** e la lente "libro" di
`paper_xsr` da' **2.23**; 1.82 non e' nessuna delle due. Spiegazione piu' probabile: `data/raw` e'
gitignored e il cron riscrive i parquet HL ogni notte -> **stesso codice, dati diversi** (identico
allo scoperto del 07/08 su GTAA/TLT). **La decisione del 23/10 poggia su quel numero.**