Adriano Dal Pastro
fac9978d87
B1 (memoria) + B2 (misura). Il 19/08 stava solo in un diario e in un commit: la
sessione che ha cambiato il tripwire di venue, la tabella _CONTRACT e le referenze
non era in CLAUDE.md — 2a occorrenza dopo edge_watch, e riguarda di nuovo qualcosa
che gira con soldi veri. Ora c'e', insieme al debito che dichiarava.
B2: il debito era «la taratura non e' ri-misurata a tre referenze». Ri-misurandola
(scripts/research/r0821_venue_refs.py, riusa dislocation/episodes/zero_fp_frontier
di r0726) il problema non era dove ci si aspettava.
1. «Zero falsi allarmi in 8 anni» veniva dal consenso Coinbase+Bitstamp+BITFINEX
dello script di ricerca; il sorvegliante live gira su Coinbase+Bitstamp. Due
liste di referenze in due posti diversi, e nessun test poteva accorgersene.
Sull'insieme reale i falsi allarmi sono 1: 2020-03-13 07:00-10:00 UTC, 4 ore a
-418 bps di picco su BTC = il crash COVID, cioe' proprio l'evento che CLAUDE.md
elencava come esempio di cio' su cui NON scattava. La firma che lo dimostra: le
"65.043 ore BTC" citate in memoria sono esattamente le ore utili del set con
bitfinex; sul set reale sono 69.633.
2. Kraken non lo ripara: su 8 anni porta un mese. Il tetto ~700 candele
dell'endpoint pubblico e' stato ri-verificato oggi sulla rete (704 barre su
70.286 richieste = 1,00%), non creduto da un commento del 26/07.
3. Perche' spariva a 3 referenze, ed e' il punto trasferibile: con bitfinex dentro
1 delle 4 ore diventa BLIND, lo streak si azzera e l'episodio non esiste — ma la
dislocazione e' ancora li' (mediana -343 bps). Lo zero non veniva da un consenso
piu' accurato, veniva da un'ora buttata (ore utilizzabili 93,4% vs 100,0%).
4. La direzione dichiarata il 19/08 ("piu' BLIND, allerta di meno") e' confermata ma
la sua taglia dipende dal venue, non dal numero tre: confronto appaiato sulle
stesse ore, con bitfinex -13,91 pp di ore utilizzabili, con kraken +0,00 pp.
5. Controllo positivo intatto: Bitfinex 2018-19, 22 episodi, il piu' lungo 2.324h,
picco 1.136 bps = 11,4x la soglia.
DECISIONE: (100 bps, 4h) NON si tocca, ma la giustificazione cambia. 1 falso allarme
in 8 anni costa 0,031%/anno di equity attesa contro il 100% che un vero positivo
evita (ogni p plausibile e' 16-160x sopra il break-even); alzare a 150 bps per
ripristinare lo zero porterebbe il margine su FTX da 3,0x a 2,0x, sotto la gamba (b)
del criterio dichiarato prima di guardare i dati. La memoria si contraddiceva da
sola — «zero falsi allarmi» al punto (2), «a 1 ogni 8 anni serve p > 0,031%» al
punto (4) — e la meta' giusta era quella dell'economia.
Congelato il MECCANISMO, non il numero: tests/test_venue_watch.py 35 -> 37, due test
puri (lo spread max-min e' monotono nel numero di referenze; una sola ora BLIND
spezza lo streak, con un caso di controllo che DEVE scattare).
Soglie, book, pesi, config, cron: INVARIATI. Suite 621 verdi, 1 rosso noto
(test_gtaa_band_gate, altro asse). Diario: docs/diary/2026-08-21-venue-taratura-*.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
8.6 KiB
2026-08-21 — «Zero falsi allarmi in 8 anni» non descriveva il sistema che gira
Richiesta: "analizza e fai B1 e B2" — B1: portare in memoria operativa la sessione del 19/08, che stava solo nel diario e nel commit. B2: ri-misurare la taratura del tripwire di venue dopo l'aggiunta della terza referenza, debito dichiarato quel giorno e mai chiuso.
Toccati: scripts/research/r0821_venue_refs.py (nuovo), tests/test_venue_watch.py (35 → 37),
CLAUDE.md. Book, pesi, config/live.json, THRESHOLD_BPS, PERSIST_HOURS: INVARIATI.
0. Il debito, come era stato dichiarato
Il 19/08 e' stata aggiunta Kraken come terza referenza, perche' Coinbase ha comprato Deribit e una referenza che e' la casa madre non misura piu' se Deribit scolla dal mondo. Il diario fu onesto sul limite: «"Zero falsi allarmi in 8 anni" e' stato misurato con l'insieme di referenze di allora … quel numero non e' stato ri-misurato», e dichiarava la sola direzione dell'errore — con la mediana di tre il consenso e' piu' robusto e lo spread max-min si allarga, quindi si va piu' spesso in BLIND, che e' lo stato morbido: il modo di sbagliare e' «allerta di meno».
La direzione era giusta. Ma ri-misurando salta fuori un fatto piu' grosso, che non era nel verso previsto perche' non riguardava la modifica del 19/08 ma la taratura originale.
1. Il fatto che struttura tutto: la profondita' delle referenze
| asset | venue | barre | da | a |
|---|---|---|---|---|
| BTC | coinbase | 69.643 | 2018-08-14 | 2026-07-26 |
| BTC | bitstamp | 69.663 | 2018-08-14 | 2026-07-26 |
| BTC | bitfinex | 33.000 | 2018-08-14 | 2022-05-21 |
| BTC | kraken | 702 | 2026-06-26 | 2026-07-26 |
| ETH | coinbase | 64.554 | 2019-03-14 | 2026-07-26 |
| ETH | bitstamp | 64.572 | 2019-03-14 | 2026-07-26 |
| ETH | bitfinex | 0 | — | — |
| ETH | kraken | 702 | 2026-06-26 | 2026-07-26 |
Il tetto di Kraken e' stato ri-verificato oggi sulla rete, non creduto da un commento del 26/07:
chieste 70.286 ore, ricevute 704 (l'1,00% del richiesto). L'endpoint OHLC pubblico ritorna le
ultime ~700 candele qualunque since.
Conseguenza: la taratura a 8 anni con Kraken dentro non e' ottenibile. Non per pigrizia — per struttura della fonte. E non e' un problema per il sorvegliante live, a cui servono le ultime ore.
2. Il falso allarme che c'era, e che nessuno aveva visto
Frontiera a zero falsi allarmi, per insieme di referenze, punto in produzione (100 bps, 4h):
| insieme | asset | ore utili | non-BLIND | soglia minima a 4h | falsi allarmi a (100, 4h) |
|---|---|---|---|---|---|
| LIVE-pre (CB+BS) | BTC | 69.633 | 100,0% | 150 bps | 1 |
| ETH | 64.541 | 100,0% | 100 bps | 0 | |
| CALIB (CB+BS+BF) | BTC | 65.043 | 93,4% | 75 bps | 0 |
| ETH | 64.541 | 100,0% | 100 bps | 0 | |
| LIVE-post (CB+BS+KR) | BTC | 69.633 | 100,0% | 150 bps | 1 |
| ETH | 64.541 | 100,0% | 100 bps | 0 |
Due cose in questa tabella.
(a) «Zero falsi allarmi in 8 anni» non ha mai descritto la configurazione in produzione. Quel
numero viene dalla riga CALIB, che ha bitfinex nel consenso — e il sorvegliante live non l'ha mai
avuta. Il 65.043 e' la firma: e' esattamente il numero di ore che CLAUDE.md cita al punto (1) del
bullet VENUE WATCH. Sul consenso reale le ore sono 69.633 e i falsi allarmi sono 1.
(b) Aggiungere Kraken non lo ripara, perche' su 8 anni Kraken porta un mese: LIVE-post e LIVE-pre danno numeri identici sulla storia lunga.
Il falso allarme e':
2020-03-13 07:00 -> 10:00 UTC 4 ore picco -418,7 bps segno -1
Il crash COVID. Cioe' proprio l'evento che la memoria elencava come esempio di cio' su cui il tripwire non scattava: «zero falsi allarmi inclusi crash COVID 2020-03, maggio 2021, LUNA e novembre 2022».
3. Perche' spariva a tre referenze — e perche' non e' una buona notizia
Nella stessa finestra, con bitfinex nel consenso, 1 delle 4 ore diventa BLIND (utilizzabili
75%) → il run si spezza, non arriva mai a 4 ore consecutive, l'episodio non esiste. Ma la
dislocazione e' ancora li': mediana −343 bps su quelle ore.
⚠️ Lo zero non veniva da un consenso piu' accurato, veniva da un'ora buttata. «Zero falsi allarmi» puo' voler dire piu' preciso oppure piu' cieco, e le due si distinguono solo guardando la quota di ore utilizzabili — che nella riga CALIB e' 93,4% contro il 100,0% delle altre.
Congelato in due test puri (tests/test_venue_watch.py), perche' e' il meccanismo e non il numero
a essere trasferibile:
test_una_terza_referenza_non_puo_aumentare_le_ore_utilizzabili— lo spread max-min e' monotono nel numero di referenze, quindi «piu' referenze» non e' gratis: sposta verso BLIND;test_una_sola_ora_BLIND_spezza_lo_streak_e_impedisce_l_allarme— con un caso di controllo che DEVE scattare, altrimenti il test non proverebbe nulla.
4. La direzione dichiarata il 19/08 e' confermata, e la sua TAGLIA dipende dal venue
Confronto appaiato (stesse ore, mai due campioni diversi):
| ore | non-BLIND 2 ref | 3 ref | Δ | |scarto| mediano, differenza appaiata | |
|---|---|---|---|---|---|
| BTC + bitfinex | 33.000 | 99,95% | 86,04% | −13,91 pp | −0,04 bps |
| BTC + kraken | 702 | 100,00% | 100,00% | +0,00 pp | −0,04 bps |
| ETH + kraken | 702 | 100,00% | 100,00% | +0,00 pp | +0,03 bps |
«Piu' referenze → piu' BLIND» e' vero, ma con Bitfinex costa 14 punti di ore utilizzabili e con Kraken zero. Non e' una proprieta' del numero tre: e' una proprieta' di quanto la terza referenza e' d'accordo con le altre. Bitfinex nel 2018-2022 era il venue con i problemi bancari — metterlo nel consenso e' metterci dentro il rumore che il controllo positivo usa come segnale.
5. Controllo positivo: intatto
Bitfinex 2018-19 come bersaglio, consenso Coinbase+Bitstamp: 22 episodi, il piu' lungo 2.324 ore, picco 1.136 bps = 11,4x la soglia. Il rilevatore vede i casi veri.
6. Decisione: la soglia NON si tocca, ma la giustificazione cambia
Il criterio dichiarato in anticipo il 26/07 aveva tre gambe: (a) zero falsi allarmi in 8 anni, (b) margine ≥3x sul caso storico piu' debole (FTX ~300 bps) → soglia ≤100 bps, (c) minima latenza. La gamba (a) non e' soddisfatta dalla configurazione reale. Le altre due reggono, e l'economia del 26/07 risolve da sola:
- 1 falso allarme in 8 anni = 0,125/anno × 0,248% di costo = 0,031%/anno di equity attesa,
contro il 100% che un vero positivo evita → break-even a
p > 0,031%, e ognipplausibile (0,5-5%) e' 16-160 volte sopra; - alzare a 150 bps per ripristinare lo zero porterebbe il margine su FTX da 3,0x a 2,0x, sotto il vincolo (b) dichiarato prima di guardare i dati.
Quindi (100 bps, 4h) resta, ma perche' un falso allarme ogni 8 anni e' economico, non perche' non ce ne siano. E il numero da citare e' 1 in 8 anni — che e', ironicamente, proprio l'esempio che il punto (4) del bullet usava per il break-even: la memoria si contraddiceva da sola e la meta' giusta era quella dell'economia.
7. Cio' che resta aperto
- La terza referenza non e' validabile sulla storia. Kraken e' verificata su un mese e su quel mese non cambia nulla. Se serve una validazione lunga, va cercata una fonte che pagini davvero (il tetto ~700 e' dell'endpoint pubblico, non di ccxt).
- Il Rulebook Deribit del 12/08 non lo sorveglia nessuno (ADL, perdita socializzata, emergency powers, conti dormienti) — invariato dal 19/08.
MAINT_GRACE_HOURS = 2presume gli annunci invece di leggerli. Non e' teorico: duelocked=truein quattro giorni (18/08 ~4h, 21/08 ~1h).
REGOLE
- Un numero di taratura va etichettato con la CONFIGURAZIONE su cui e' stato misurato, non solo con la finestra. «Zero falsi allarmi in 8 anni» era vero e inutile: descriveva un consenso che la produzione non ha mai avuto, e nessun test poteva accorgersene perche' i due percorsi (ricerca e live) tenevano la lista delle referenze in due posti diversi.
- Uno "zero" si legge sempre accanto alla quota di campione utilizzabile. Meno falsi allarmi perche' si vede meglio e meno perche' si vede di meno hanno lo stesso valore stampato e valore opposto.
- Quando due affermazioni della stessa memoria si contraddicono (qui «zero falsi allarmi» e «a 1 ogni 8 anni serve p > 0,031%»), la contraddizione e' un'informazione: una delle due e' stata scritta guardando i dati.
- Il debito dichiarato il 19/08 era corretto ma sottodimensionato: diceva «il numero non e' ri-misurato» e il numero era sbagliato prima della modifica che lo aveva fatto dichiarare.