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>
157 lines
8.6 KiB
Markdown
157 lines
8.6 KiB
Markdown
# 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 ogni `p` plausibile
|
||
(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 = 2` presume gli annunci invece di leggerli.** Non e' teorico: due
|
||
`locked=true` in 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.
|