PythagorasGoal/docs/diary/2026-07-26-skh-partial-entry.md

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".