venue: la taratura ri-misurata — «zero falsi allarmi in 8 anni» non descriveva la produzione

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>

docs/diary/2026-08-21-venue-taratura-tre-referenze.md

@@ -0,0 +1,156 @@
+# 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.