VERDETTO: ESEGUIBILE MA INUTILE SU TP01 — nessun cambio al libro.
La domanda mai chiusa: invece di de-luckare il NUMERO, si puo' de-luckare
l'ESECUZIONE (N tranche, N ore, 1/N di size)? Tre risposte:
(i) batte l'ancora MEDIANA: si', di +0,014 di Sharpe FULL. E l'algebra dice
che non puo' fare di piu': la posizione dell'ensemble e' la MEDIA delle
posizioni, il lordo orario e' lineare -> lordo_ens == media dei lordi
(max|dif| 1.4e-17, verificato). Tutto il guadagno e' vol (-1,1%); il
drift si muove di +0,013% = solo fee-netting. Cio' che compra davvero
non e' nella colonna Sharpe: sd(ShFULL) 0,061 -> 0, sd(ShHOLD) 0,112 -> 0.
(ii) batte la CANONICA che gira oggi: NO sull'hold-out (-0,223), SI su FULL
(+0,024) e IS (+0,071). I due numeri non sono due stime della stessa
cosa: +0,44 e' un'estrazione gia' avvenuta (98 pctl di 24), +0,21 e' cio'
che si ottiene senza estrarre. La stima onesta del futuro e' +0,21.
(iii) eseguibile da quale capitale: da TUTTI, gia' a $635.
PREMESSA DEL 02/07 REFUTATA, CONCLUSIONE INTATTA. Il 02/07 boccio' il
tranching perche' "i delta per-ancora (~$1-2) sono sotto il min-order $5".
Ma `book.build_book_order` banda la posizione NETTA e manda UN ordine per
asset per giro: un delta per-ancora non e' mai un ordine. Il tranching non
moltiplica gli ordini per K, e la degenerazione non avviene (retention
0,88-1,06 a $635; a K=24 il path eseguito segue l'ideale MEGLIO che a K=1,
corr 0,9986 vs 0,9954). Cio' che lo boccia e' la taglia dell'effetto, non
l'esecuzione — e la ragione conta, perche' quella vecchia cadrebbe al primo
esecutore che mandasse un ordine per tranche.
FUNDING: canale chiuso per ALGEBRA, non per piccolezza. funding = pos*f e'
lineare in pos -> funding_ens == media esatta (max|dif| = 0). Il rapporto
condizionale 2,25x non si attenua (2,25 -> 2,26 da K=1 a K=24): la
correlazione esposizione-funding vive alla scala del regime, non dell'ora.
DOVE STA IL SEGNALE: SKH01, l'unica ancora a cui il 02/07 non porto' mai
questa domanda. Sulla lente del path che gira, mediana delle 23 fasi ShFULL
0,974 -> ensemble 1,286 (+0,312), maxDD 23,3% -> 16,6%: 20x TP01, perche' i
suoi trade sono DISCRETI (spostare la griglia cambia QUALI trade esistono).
Dentro il libro pesa il 25% e li' non si distingue da zero. 23 e' PRIMO ->
sulla griglia 30m non esiste sotto-ensemble simmetrico.
Contro-intuitivo misurato: tranciando entrambi gli sleeve gli ORDINI salgono
6,5x (197 -> 1283/anno) ma le FEE SCENDONO ($5,76 -> $5,29/anno) — su un
venue a fee proporzionale si paga il nozionale, e mediare 23 fasi trasforma
un +-1,0x che sbatte in una posizione frazionaria. Su un venue a pavimento
fisso il segno si ribalterebbe.
BARRIERA (canale funded): [A7] refutata sulla regola misurabile e con un
meccanismo — il lato binding non e' la barriera (-6%, P(breach) 0-7%) ma il
BERSAGLIO (+10%): meno vol allontana dal traguardo quanto dalla barriera, e
l'ensemble sta al 31 pctl su P(pass). MA la regola che il 22/08 ha misurato
uccidere e' la daily-loss a UN giorno, che close-only non puo' vedere
(cieca, non conservativa). Sul p1 giornaliero — cio' che quella regola legge
— l'ensemble batte il 66% delle configurazioni. Dichiarato come indizio.
COSTO VERO, e non e' negli ordini: 23 ancore su 24 di TP01 richiedono barre
di oggi, cioe' `fresh_5m` — il path che il 26/07 ricade in silenzio sul
certificato e che il 29/07 ha fallito 6 giri su 8. E' l'unica delle tre
obiezioni del 02/07 che sopravvive intatta.
Repliche prima di ogni delta: h=0 == tp01_baseline_daily; guardie di
causalita' su tutte le ancore; `banded()` == `r07.smallcap_net` bit-exact
(0.0e+00, stessi ordini); K=4 == EW di 4 book (2.2e-16 sul daily);
offset 0 == `sleeves._skyhook_returns()` (0.0e+00). I livelli del 02/07 sono
derivati col dato: dichiarato, non nascosto.
Due errori miei catturati e congelati in commento: (a) confrontavo
`turnover_per_year`, che eval_weights ARROTONDA, accanto a una
disuguaglianza stretta -> sembrava violata; (b) i percentili di coda usavano
un solo segno per tre colonne di cui due sono ritorni e una una frequenza ->
stampavo 34 dove il valore vero e' 66, cioe' "peggio della mediana" per un
numero migliore della mediana. E il criterio N_max SATURA (6/6 celle a ogni
capitale): un gate che passa sempre non misura niente, e lo dice il codice.
Book, pesi, ancore, cron, config INVARIATI. Nessuna proposta.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf
Adriano Dal Pastro
58395a594e