PAVIMENTO-LEVA (§72): il pavimento non licenzia taglia, 0/16 — e corregge §71
Domanda dell'operatore: "possiamo usare quanto conosciamo del pavimento per studiare una strategia". L'inverso di COLLAR01: non "quanto DD mi risparmia il pavimento a taglia fissa" (perdeva contro il de-levering) ma "quanta TAGLIA mi autorizza a DD fisso" — l'unica cosa che il de-levering non puo' comprare (cambia la FORMA, non la proporzione), e la grandezza su cui vive il tetto di leva del progetto (n·frac·scala·sl <= 0,50 => 1,67x). RISULTATO: 0/16. La sola put a premio reale PEGGIORA il maxDD in 16/16 celle (FORTE 51,83% -> 55,4-75,8%; LARGO 71,94% -> 74,8-81,7%), quindi k_f = 1,000 ovunque: niente da licenziare. Monotono nella protezione: piu' la put e' vicina, peggio va — il bleed del premio E' il drawdown. 🚨 CORREGGE §71 (stesso giorno). Stamattina A1 diceva "il pavimento funziona davvero". E' il COLLAR a ridurre il DD, non il pavimento: a premio zero la put lo riduce (51,83 -> 36,76, il controllo), a premio reale lo peggiora => tutto il beneficio e' mangiato dal premio, e oltre. Nel collar la riduzione viene dal TETTO: il suo premio compensa il bleed, e cappare l'upside abbassa il picco da cui il DD si misura — un picco piu' basso, non protezione. Premio di pareggio: 36-79% del reale; il DVOL sta 1,32x sopra la RV, quindi un prezzo equo (~76%) sfiora il pareggio nelle celle migliori e lo manca nelle altre. Il motivo di §46 (beta) non si applica — a beta 1,0 la put paga davvero — ma il verdetto di §46, "il maxDD SALE", si riproduce per un motivo diverso. Corretti il diario di §71 (titolo e A1), RESULTS, memoria. IL MECCANISMO (B2), trasferibile: i drawdown di BTC sono GRIND. maxDD FORTE 2021-07-20 -> 2022-05-06 = 290 giorni; LARGO fino al 2023-10-16 = 818. Una put a 7-14g copre UNA finestra; il DD che conta dura 20-60 finestre; la put scade OTM ogni settimana (para nel 0-9% dei cicli) mentre il premio sanguina. Non protegge nemmeno la finestra peggiore: 14g FORTE -22,9% nudo -> -23,6% col pavimento. Su BTC il pavimento compra protezione contro la cosa sbagliata. LA LICENZA DEL DISASTER-SL E' DI CARTA (B3), scritto prima che sia comodo: con la put a 5d/14g a 21,9% dallo spot, sostituire sl con quella distanza darebbe 2,28x. Ma l'invariante limita UN episodio, la put limita UNA finestra, e il massimo su finestre consecutive non e' limitato da nulla: 1 finestra -23,6% (coperta), 8 finestre -33,6% (non coperte) => a 2,28x un grind di 112 giorni costerebbe il 77% dell'equity. disaster_sl_pct NON si sostituisce con la distanza di un pavimento. Aggiunto a CLAUDE.md §3. GATED SULL'IV (B4) — la copertura dinamica che §46 non aveva provato: put ON solo sotto il 25°/50° pctl di DVOL/RV. Migliora molto (FORTE +3,8% -> +8,4%) ma resta sotto la base (+10,04%) e il DD resta >=. L'incollatura ignora lo spread delle transizioni A FAVORE del gated: perde a maggior ragione. Quattro attese a priori (B1-B4) scritte prima, tutte confermate. NON MISURATO, dichiarato: nessun DSR (cade al primo gate); nessuna lente reale; nessun pavimento a scadenza lunga (30-90g, che coprirebbe piu' finestre di grind) perche' l'operatore ha vincolato a <=15 giorni — e' l'unica variante che B2 lascia aperta, e sta fuori dal vincolo. Libro, pesi, cron, config INVARIATI. Nessun ordine. Test 25/25 sui filoni. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -17,7 +17,7 @@ chi la riapre deve battere il motivo, non ripetere la misura.
|
||||
| `docs/memory/40-produzione-e-deploy.md` | esecutore, tripwire, monitor, libro di bordo, PRIIPs/UCITS | tocchi cio' che gira con soldi veri |
|
||||
| `docs/memory/50-dati-e-feed.md` | difetti del dato trovati e riparati, catena opzioni | tocchi i feed |
|
||||
| `docs/memory/60-metodo-e-gate.md` | i gate codificati in `altlib.py` | valuti un candidato |
|
||||
| `docs/research/RESULTS-0822.md` | registro per filone §1-71 | vuoi il dettaglio di un filone |
|
||||
| `docs/research/RESULTS-0822.md` | registro per filone §1-72 | vuoi il dettaglio di un filone |
|
||||
| `docs/diary/` (123 voci) | la sessione originale, per data | vuoi il contesto completo |
|
||||
|
||||
---
|
||||
@@ -173,7 +173,10 @@ sempre, bit-exact** (T7, `max|diff| = 0.0`) — `config/live.json` **non e' stat
|
||||
tetto nello stesso file della chiave sarebbe un lucchetto con la chiave attaccata: il gradino a 1,50
|
||||
richiede una modifica di codice, quindi una review); il tetto e' **sul PRODOTTO**
|
||||
`n_asset · frac · scala` e l'invariante del disaster-SL e' `n_asset · frac · scala · disaster_sl_pct
|
||||
≤ 0,50` (la guardia che morde per **prima**: da' scala ≤ 1,67x e scatta se qualcuno allarga lo stop);
|
||||
≤ 0,50` (la guardia che morde per **prima**: da' scala ≤ 1,67x e scatta se qualcuno allarga lo stop —
|
||||
🚨 e **`disaster_sl_pct` NON si sostituisce con la distanza di un pavimento di put**: darebbe 2,28x
|
||||
sulla carta, ma la put limita UNA finestra e i drawdown di BTC sono grind di 290-818 giorni, su 8
|
||||
finestre −33,6% → 77% dell'equity a 2,28x. Misurato in §72, scritto qui prima che sia comodo);
|
||||
una scala fuori scaletta o fuori tetto **NON viene tagliata** — `book_execute` si ferma, non invia e
|
||||
allerta (`ScalaNonAutorizzata`); e **la scala vive solo sul percorso fidato** (equity reale
|
||||
illeggibile ⇒ 1,00, cosi' "il fallback non e' piu' permissivo" e' vero per costruzione).
|
||||
|
||||
Reference in New Issue
Block a user