# 2026-07-26 — SKH01: gli INGRESSI su barra 230m PARZIALE. Misura dedicata. **Richiesta:** *"fai la misura sugli ingressi con barra parziale"*. **Follow-up dichiarato che chiude** (registrato in CLAUDE.md stamattina, misura T1): > la stessa barra parziale tocca anche gli INGRESSI — `ent[n-1]` puo' venire da un breakout non > confermato a fine barra → se evapora, il book apre e richiude. Su 112 bin campionati: > disaccordo parziale-vs-completa in 1 (~1%), ma con sole 3 entry nel campione la taglia non e' > stimabile … serve una misura dedicata prima di decidere il verso. **Script:** `scripts/research/r0726_skh_partial_entry.py` — **test:** `tests/test_skh_partial_entry.py` (8). **Book, pesi, cron: INVARIATI.** Nessuna decisione di allocazione cambia. --- ## 0. Il fatto meccanico da cui parte tutto `resample_5m(..., origin="epoch")` **non scarta il bin in corso**. Il cron gira a ore piene; una barra SKH01 dura 230 minuti. Quindi a ogni giro il live valuta il segnale su una barra 230m che, in media, e' **completa a meta'**. Il backtest invece valuta solo alle chiusure dei bin. Stamattina ho misurato il lato **uscite** di questo fatto (e ho scoperto che il live esce gia' intra-barra, quindi le uscite erano modellate troppo pessimisticamente). Restava il lato **ingressi**, che e' l'opposto: il live puo' entrare su un breakout che a fine barra **non c'e' piu'**. La domanda non e' "succede?" (succede per costruzione). E' **di che segno e' il saldo**. --- ## 1. Come si misura senza misurare la propria aritmetica Il rischio di questa misura non e' sbagliare un numero: e' costruire una ricostruzione rotta e non accorgersene. `signal_at(obs_ms, ...)` ricostruisce il segnale che il live *avrebbe visto* a un istante arbitrario: storia completa fino a li' + barra parziale, passata per i **veri** `htf_features` / `merge_htf_to_ltf` / `atr` su una finestra di 200 barre HTF. **Due errori catturati in sessione, entrambi del tipo che passa i test se i test sono pigri:** **(a) Self-check vacuo + bug di confine.** La prima versione stampava "BTC 80/80 OK". Era falso su due livelli insieme. `obs_ms // MS_LTF` a un'osservazione *alla chiusura* del bin cadeva nel bin **successivo**, ancora vuoto → aggregato vuoto → `signal_at` ritornava `None` → segnale 0. E il check campionava bin **a caso**: gli ingressi sono ~2% dei bin, quindi confrontava **zeri con zeri** e passava comunque. Le uniche 2 divergenze su ETH erano gli unici 2 bin con un segnale vero — cioe' il campione stava gia' dicendo che era rotto al 100%, non al 2.5%. Fix: `((obs_ms - 1) // MS_LTF) * MS_LTF`, e `selfcheck` riscritta per testare **esplicitamente i bin CON ingresso**. Esito corretto: **120/120 su BTC, 120/120 su ETH**. I "falsi allarmi" sui bin flat (17 BTC / 22 ETH su 400) sono bin dove il segnale c'e' ma il backtest lo sopprime col cap `max_per_day=1` — atteso, non un difetto. > **Regola:** un self-check su eventi rari va campionato **sugli eventi**, non sulla popolazione. > Un check che confronta zeri con zeri ha potenza zero e sembra un successo. **(b) Sovrastima ~20× dei falsi ingressi.** La prima scansione contava **1361** falsi ingressi (204% in piu' dei trade veri, costo stimato −3.03%/anno di sleeve). Numero **sbagliato**: `signal_at` riporta il compositore **grezzo**, mentre il live applica anche il cap `max_per_day=1` e il non-overlap. La spia era nella sezione D della stessa stampa — **305 giorni** con un falso ingresso a fronte di 663 "eventi": con cap 1/giorno non possono essere eventi indipendenti. Riscritta come **macchina a stati sequenziale** fedele al live: i falsi ingressi veri sono **~5/anno/asset**. > **Regola:** un conteggio di eventi su un segnale grezzo non e' un conteggio di **trade**. Prima di > monetizzare un evento, farlo passare per gli stessi filtri che ha il live. --- ## 2. Il risultato Due path identici in tutto (stessi livelli SKH01_V2_DD pct-asimmetrici, stesse uscite intra-barra, stesso cap, stesse fee 0.10% RT) tranne **quando si valuta l'ingresso**: - **LIVE** — segnale valutato a ogni confine orario interno al bin (= cio' che fa il cron oggi); - **BACKTEST** — segnale valutato solo alle chiusure dei bin (= cio' che il backtest assume). | asset | offset | path | equity× | trade | falsi | Sharpe | |---|---:|---|---:|---:|---:|---:| | BTC | 0 | LIVE | 6.58 | 249 | 29 | **1.07** | | BTC | 0 | BACKTEST | 6.28 | 211 | 0 | 1.08 | | ETH | 0 | LIVE | 6.09 | 285 | 39 | **0.95** | | ETH | 0 | BACKTEST | 5.44 | 236 | 0 | 0.91 | | BTC | 230 | LIVE | 27.10 | 254 | 20 | **1.63** | | BTC | 230 | BACKTEST | 8.32 | 226 | 0 | 1.19 | | ETH | 230 | LIVE | 11.47 | 283 | 34 | **1.20** | | ETH | 230 | BACKTEST | 5.08 | 241 | 0 | 0.88 | | BTC | 460 | LIVE | 17.53 | 258 | 18 | **1.44** | | BTC | 460 | BACKTEST | 4.29 | 236 | 0 | 0.85 | | ETH | 460 | LIVE | 72.87 | 281 | 17 | **1.93** | | ETH | 460 | BACKTEST | 6.12 | 253 | 0 | 0.95 | **ΔSharpe (live − backtest): −0.01, +0.04, +0.44, +0.32, +0.59, +0.98 → 6/6 non negativi, mediana +0.38.** ⚠️ **I multipli d'equity NON sono ritorni dello sleeve.** Questo simulatore compone per-trade senza vol-target, senza pesi di book, a nozionale unitario. Servono solo a confrontare due path che differiscono per una cosa sola. La lente onesta qui e' lo **Sharpe** (che non compone), e i multipli sono la sua integrazione su 7 anni. **Split in-sample / hold-out (offset 0, dove ho le serie):** | asset | path | FULL | IS | HOLD | |---|---|---:|---:|---:| | BTC | LIVE | 1.07 | 1.07 | **1.12** | | BTC | BACKTEST | 1.08 | 1.15 | 0.71 | | ETH | LIVE | 0.95 | 0.93 | 1.03 | | ETH | BACKTEST | 0.91 | 0.88 | 1.03 | All'offset 0 il FULL e' un pareggio ma l'hold-out favorisce il live su BTC (**+0.41**) e pareggia su ETH. Coerente col fatto noto che **offset 0 e' l'ancora fortunata del backtest** (93-98° pctl sui 23 offset a priori): e' esattamente l'ancora dove il path canonico ha meno da guadagnare. --- ## 2-bis. I due controlli che il risultato doveva superare Un +0.98 di Sharpe e un 72.87× di equity sono il tipo di numero che va attaccato prima di crederci. **(a) E' concentrato in pochi giorni?** No — e il controllo va nella direzione **opposta** al sospetto: | offset 460 | ret/trade | win rate | top-5 gg = % del log-equity | equity senza i top-5 | |---|---:|---:|---:|---:| | ETH LIVE | +1.878% | 48.6% | **16.7%** | 35.64× | | ETH BACKTEST | +0.946% | 40.6% | **39.5%** | 2.99× | | BTC LIVE | +1.307% | 46.1% | **22.5%** | 9.20× | | BTC BACKTEST | +0.801% | 44.0% | **38.3%** | 2.46× | Togliendo i 5 giorni migliori il divario si **allarga** (ETH 35.6× vs 3.0×). E' il **backtest** il path concentrato (~39% del log-equity in 5 giorni). La differenza vive nella **distribuzione**: ret/trade circa doppio e win rate +8pp (ETH) / +2pp (BTC). **(b) C'e' look-ahead intra-bin?** E' il rischio serio, perche' il self-check valida la ricostruzione solo **a chiusura di bin** — un leak che esistesse solo intra-bin gli sarebbe **invisibile per costruzione**. Test decisivo: ricalcolare ogni osservazione intra-bin con la serie 5m **troncata** alle sole barre gia' chiuse a `obs_ms`. Se il futuro contasse, la risposta cambierebbe. > **BTC 145/145 e ETH 144/144 osservazioni intra-bin: risposta identica dopo il troncamento**, e il > prezzo d'ingresso coincide sempre con l'ultimo close 5m gia' chiuso (241/241). Cablato come test permanente (`test_nessun_lookahead_intra_bin`). --- ## 3. Il meccanismo (perche' vince, e perche' non e' una sorpresa) Sezione B della scansione: quando il segnale c'e' **anche** a fine bin, il live entra in anticipo di **180 minuti mediani** a un prezzo **0.25-0.26% migliore** in media (0.11-0.12% mediano). SKH01 e' un **Donchian breakout**. Aspettare fino a 230 minuti la chiusura del bin significa, sui casi che confermano, **pagare il pezzo di movimento gia' avvenuto**. Il costo di quell'attesa e' sistematico; il beneficio (evitare i breakout che evaporano) e' reale ma raro — **~5 eventi/anno/asset** dopo i filtri del live, perche' il cap `max_per_day=1` e il non-overlap assorbono quasi tutto. E l'effetto si amplifica sui **livelli**, che sono percentuali sull'ingresso (long sl4%/tp10%, short sl2%/tp8%). Entrare 0.26% piu' avanti nella direzione del breakout sposta TP **e** SL dello stesso 0.26% — ma il TP e' a 4-10% e lo SL a 2-4%: la stessa quantita' assoluta vale il **6-13% della distanza dallo SL** contro il 2.6-3.3% della distanza dal TP. Il vantaggio d'ingresso e' quindi **asimmetrico a favore della sopravvivenza del trade**: e' il canale che spiega il win rate piu' alto, non un giorno fortunato. **La cannibalizzazione del cap non morde:** ingressi veri bloccati da un falso ingresso = **2 su BTC (0.6%) e 3 su ETH (0.9%)**. --- ## 4. Verdetto **L'ingresso su barra parziale NON e' un difetto da correggere. Il verso del follow-up e': lasciarlo.** Ma la lettura che conta e' la seconda: > **Il live e il backtest stanno girando due strategie diverse, e la differenza non e' neutra.** Tutti i numeri di SKH01 nel progetto — Sharpe standalone, il peso 25% del book Deribit, l'audit d'ancora del 02/07, la conferma di peso/cadenza del 24/07 — sono calcolati sul path **a chiusura di bin**, che non e' quello che gira. La misura dice che il path reale e' **≥** in 6/6 coppie asset×offset. Insieme alla misura di stamattina sulle uscite (il live esce gia' intra-barra, +0.081 Sharpe FULL di book sottostimato), **il path live di SKH01 e' stato modellato in modo sistematicamente pessimistico su entrambi i lati**. **Cosa NON concludo.** Che "l'ingresso intra-bin e' un miglioramento validato". Non ha passato nessuno dei gate del progetto: e' stato *misurato* sugli stessi 7 anni su cui SKH01 e' stato selezionato e affinato, non e' passato per `study_family_honest` ne' per un deflated-Sharpe, e la taglia varia molto fra ancore (da −0.01 a +0.98). Promuoverlo a meccanismo canonico sarebbe esattamente la selezione-sull'hold-out che il progetto ha gia' codificato come gate. E non serve promuoverlo: **e' gia' cio' che il live fa**. L'azione richiesta e' l'opposta — smettere di trattare il numero del backtest come l'aspettativa del live, e non "riparare" il live per farlo somigliare a un backtest peggiore. **Nessun cambio a book, pesi, cron, config.** --- ## 5. Regole nuove 1. **Un self-check su eventi rari si campiona sugli EVENTI.** Confrontare zeri con zeri ha potenza zero e passa. (Costo: un "80/80 OK" completamente falso.) 2. **Un conteggio di eventi su segnale grezzo non e' un conteggio di trade.** I filtri del live (cap giornaliero, non-overlap) vanno applicati prima di monetizzare qualsiasi evento. (Costo: sovrastima 20× e un costo inventato di −3%/anno di sleeve.) 3. **Quando live e backtest differiscono, misurare il DELTA con machinery identica** — un solo grado di liberta' cambiato — e quotarlo sulla **banda d'ancora**, non su un'ancora sola. All'ancora canonica questo effetto vale ~0; sulla banda vale +0.38 mediano. Su un'ancora sola avrei concluso "irrilevante".