**Stato attuale (al 2026-09-22): il codice di rollout è implementato e
testato lungo l'intero percorso — genesis → fencing → registry → broker → PEP →
supervision → translator → deployment.** Ogni pacchetto in `src/` porta la
propria suite di test (test unitari/integrazione Go, Python per l'audit e
il tooling di misurazione), e `deploy/selftest/` esegue le guide di
deployment end-to-end (**82 controlli, 0 fallimenti** — una guida che si
discosta dal codice si rompe lì, non dall'operatore). Nessuna PR è aperta
contro questo repository in questo momento — il backlog in corso (T25
degradazione controllata, T38 durabilità del registry bounded-async, T26
misurazione della qualità del translator) è stato tutto mergiato. Due
elementi restano aperti e tracciati deliberatamente, nessuno dei due
blocca il pilot: la traduzione inglese della documentazione francese
rimanente ([#83](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/83),
in corso — la maggior parte di `deploy/` e `docs/` ha già primari in
inglese, vedi "Nota sulla lingua" sopra), e il layer inter-dominio
(spec §13 — rinviato dalla spec stessa, tracciato in
[#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33) così
che "rinviato" resti visibile invece che silenziosamente assente). Ciò che
è deliberatamente **non** qui ancora oltre a questo: i corpora nativi del
translator per-linguaggio (da costituire al pilot, §15 — la pipeline che
li riproduce e ne fa da gate è costruita) e il percorso di escalation
per l'arbitrato umano (brokerd v1 accetta solo il translator
`structured`). Non fare il deploy di `config/` così com'è — ogni file lì
lo dice esplicitamente, vale la pena ripeterlo anche qui. Il protocollo
che questo codice di rollout governa non è nemmeno uno scheletro:
`tbp4.2.1/` include il core funzionante (firmatario HSM, catena di audit
Merkle, motore di policy OPA, test, processo di revisione avversariale)
in-tree tramite git submodule, fissato a un commit specifico — presente
qui senza essere copiato o duplicato.

## Guida alla configurazione — da dove iniziare

Basandosi sulla sequenza di implementazione (§13) e sullo scope del pilot P1 (§13,
§9.1: 1 VLAN server, router Debian, 2 celle, 802.1X, registry centrale,
regressione misurata dell'esperienza utente = 0):

1. **Genesis e chiavi** (§7.2, §3.2) — prima di ogni altra cosa: una
   cerimonia di genesis firmata dal quorum del controller (m-of-n, HSM), ancorata
   out-of-band. [`scripts/genesis/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/scripts/genesis) fornisce il
   tooling per l'epoch-0 (percorso dev incluso); la cerimonia stessa resta
   procedurale, non codice — nulla in questo repo la sostituisce.
2. **Cluster fencing** (§7, §13 step 2) — emissione e rotazione dell'epoch,
   quorum del controller (k-of-n) per azioni di classe W, promozione
   mirror/canary. Richiesto prima di qualsiasi deployment multi-cella, incluso il
   pilot P1 a 2 celle qui sotto — una singola cella può rinviarlo, un pilot no.
   Implementato in [`src/cluster/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/cluster) (tracker dell'epoch a
   singola autorità, quorum, promozione per prova di ricezione — nessuna chiave privata
   detenuta lì) e collegato al broker ([`src/broker/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/broker)).
3. **OPA + registry** — installa OPA, genera `policies/capabilities.json`
   seguendo [`policies/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/policies/README.md) (rimuovi
   `http.send` e `time.now_ns` prima di qualsiasi deployment, mai dopo;
   `validate_determinism.go` e il gate CI di determinismo lo impongono),
   avvialo con `lab/docker-compose.yml` per iterare sulle regole localmente.
   Il manifest attestato e il measured boot (§6.3, §13 step 3) — lo stato
   di una cella deve essere dimostrabile prima che lo siano le sue decisioni — sono implementati
   in [`src/registry/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/registry) insieme al log della cella,
   backpressure e anchoring.
4. **PEP** — il primo perimetro genuinamente governato (§13), implementato in
   [`src/pep/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep): validazione dei token (CWT/COSE, Ed25519),
   anti-replay fail-closed con memoria limitata, modalità degradata per lo stato
   dell'orologio, quote di esecuzione, e il gate plan-as-contract (§4.2, §13 step 4 —
   la sola validazione del token governa una singola azione, non il piano
   multi-step che un operatore firma effettivamente). Leggi
   [`src/pep/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/README.md), e
   [`config/nftables/pep-redirect.nft`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/nftables/pep-redirect.nft)
   per la redirezione di rete lato Debian. **Fai il deploy prima in modalità monitor**
   (log, nessun blocco) — mai `closed` al primo rollout (dottrina
   §5.3); la procedura di cambio di postura è
   [`deploy/monitor-to-closed.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/deploy/monitor-to-closed.md). Per
   PostgreSQL, il PEP in-process a due hook vive in
   [`src/pep/postgres-extension/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/postgres-extension) (§4.4).
5. **NAC in parallelo** — [`config/freeradius/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/freeradius):
   802.1X/EAP-TLS riutilizzando la stessa PKI dell'handshake (§3), fail-closed
   imposto a livello di switch (non solo sul lato RADIUS), nessuna
   VLAN assegnata da RADIUS nella v1. Le suite netns in `lab/tests/` esercitano i
   percorsi fail-closed, MAB/IoT-VLAN e OCSP-remediation.
6. **Host hardening** — [`config/sysctl/99-tbp-hardening.conf`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/sysctl/99-tbp-hardening.conf)
   su ogni macchina che esegue un componente TBP (broker, PEP, registry).
7. **Translator per ultimo** (§13) — una volta che tutto il resto è stabile. Fornito
   in [`src/translator/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/translator): hardening del runtime (non-root,
   cap-drop, seccomp — distinto da `dm-verity`, che protegge
   l'immagine a riposo, non il runtime), la macchina a stati di degradazione
   controllata (solo structured, nessun fallback cloud), e misurazione della qualità
   (`measure.py` riproduce il corpus e fa da gate in CI sulla regressione FNR/FPR,
   `tmetrics` iscrive il risultato come foglia del registry, T26, §4.5) — i
   corpora stessi sono costituiti al pilot, non spediti qui.
8. **Deployment multi-macchina** — [`deploy/apercu.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/deploy/apercu.md)
   è il punto di ingresso (cosa, dove, perché, prerequisiti); sintetizza
   le guide per ruolo (router, cella, server, supervisor) e le loro
   checklist di accettazione per macchina. `deploy/selftest/` **esegue**
   le guide (`bash deploy/selftest/selftest.sh`, 82 controlli,
   fail-closed) — eseguilo prima di toccare una macchina reale.

Ad ogni passo, misura rispetto al friction budget (§9.1) — vedi
[`tests/p1_friction/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/tests/p1_friction) per le soglie esatte e
l'harness eseguibile. Il pilot fallisce se la latenza o il tasso di arbitrato
superano queste soglie, anche se tutto il resto funziona.

## Roadmap: scale di deployment dimensionate correttamente

TBP è un sistema di governance complesso e su scala completa — cluster fencing, quorum,
un supervisor indipendente, un translator irrobustito, un handshake
inter-entità. Non ogni deployment necessita di tutto ciò. Una piccola
impresa con un singolo server che vuole "nessun agente AI agisce senza una ragione
dimostrabile e registrata" non ha bisogno di failover a due celle più di quanto
una rete domestica abbia bisogno di un SOC. Il piano è impacchettare ciò che già
esiste in questo repository in **quattro scale di deployment**, ciascuna un
superinsieme stretto della precedente — stesse primitive ovunque (fail-closed,
foglie solo-hash, monitor prima di closed), più di esse collegate insieme man mano che la scala
cresce, e la postura di sicurezza — e la complessità operativa che essa
comporta — che aumentano di conseguenza:

- **Scala 1 — Singola macchina.** Un host, un perimetro governato: `pepd`
  davanti al servizio, un sidecar OPA locale, un registry `CellLog`
  singolo. Nessun cluster fencing (nulla da recintare con una cella), nessun NAC
  (nulla da ammettere su una rete — è una sola macchina), nessun daemon broker o
  supervisor. La genesis si riduce a una singola coppia di chiavi dell'operatore,
  documentata come tale invece di fingere una cerimonia di quorum che non
  lo è. Complessità operativa più bassa: fai bene le regole OPA, fai il deploy in
  modalità monitor, osserva il friction budget, guadagna `closed`.
- **Scala 2 — Piccolo team / sito singolo.** Una manciata di macchine su una
  LAN dietro un `brokerd`, ancora un registry singolo (nessun fencing ancora —
  una cella autoritativa è ancora sufficiente a questa dimensione), NAC aggiunto
  (`config/freeradius/`, 802.1X allo switch) per ammettere macchine sul
  segmento, host hardening applicato ovunque. Un daemon in più, un sottosistema
  in più, stesso modello di registry della scala 1.
- **Scala 3 — Multi-cella resiliente.** Ciò che è già completamente costruito e
  documentato come deployment pilot P1 sopra: 2+ celle, cluster fencing
  (emissione/rotazione dell'epoch, quorum k-of-n per azioni di classe W,
  promozione mirror/canary), un supervisor indipendente con una console
  read-only, il translator irrobustito con degradazione controllata, la sequenza
  completa di guide in `deploy/` e il suo selftest a 82 controlli. Per organizzazioni
  che non possono tollerare il down di una singola cella, o i cui agenti governati
  giustificano le macchine extra.
- **Scala full — Multi-entità.** L'handshake inter-entità (§3):
  dimostrare policy, continuità della storia e liveness attraverso confini
  organizzativi, non solo attraverso celle della stessa organizzazione —
  federazione tra deployment TBP governati indipendentemente che devono
  fidarsi l'uno dell'altro senza fidarsi l'uno dell'altro. Deliberatamente non avviato
  ancora; tracciato in [#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33)
  (T32) così resta visibile come una fase successiva e distinta invece che
  silenziosamente assente. Questo è genuinamente nuovo lavoro di protocollo, non solo più
  macchine che eseguono ciò che già esiste.

**Onestà su dove ci troviamo**: la scala 3 è consegnata oggi sotto
il nome pilot-P1 usato in tutto questo README. Le scale 1 e 2 non sono
ancora impacchettate come guide proprie — sono raggiungibili oggi facendo il deploy
di un sottoinsieme di ciò che è documentato (salta cluster fencing e NAC per la scala 1,
aggiungi NAC ma mantieni una cella per la scala 2), ma quel percorso non è ancora
scritto, e nulla attualmente impedisce a qualcuno di collegarlo correttamente
da solo, soggetto alla stessa dottrina. La scala full richiede vero nuovo
codice (le tre prove del §3), non solo nuove guide.

### Prossimo lavoro pianificato

Due flussi di lavoro, tracciati come issue separate perché sono diversi
tipi di sforzo:

1. **Guide di deployment per-scala, più tooling admin dimensionato per ciascuna
   scala** ([#86](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/86)).
   Trasformare le scale sopra in `deploy/scale-1.md` /
   `deploy/scale-2.md` — la scala 3 ha già la sua sequenza di guide, è
   `deploy/apercu.md` e le guide per ruolo che sintetizza — è metà
   di questo: un percorso documentato e coperto da selftest per scala invece di
   "la guida del pilot, meno ciò che capisci di dover saltare". L'altra metà
   è il tooling rivolto all'operatore, che oggi è una
   API JSON read-only (`src/supervision/console.go`: `/v1/arbitration`,
   `/v1/epoch`, `/v1/indicators`) più file grezzi e CLI (policy Rego
   modificate a mano, `policies/gen_capabilities.sh` /
   `validate_determinism.go` per validare e rimuovere prima del deploy; il
   registry letto dalla scansione verificata di `ChainWatcher`, esercitato nei test
   e nel selftest ma senza UI di navigazione). Tre strumenti dedicati sono
   pianificati sopra ciò che già esiste, ciascuno dimensionato su ciò di cui una data
   scala ha effettivamente bisogno (un operatore di scala 1 non ha bisogno di viste
   di arbitrato multi-cella; uno di scala 3 sì):
   - una **dashboard di supervisione** sopra la console read-only
     esistente — rivolta all'umano, ancora read-only per costruzione (§7.1 "il
     supervisor vede tutto, non tocca nulla" vale invariato, D81);
   - un **editor di regole/policy** per il bundle OPA Rego — modifica, testa
     contro gli stessi gate di determinismo e rimozione delle capability
     che `validate_determinism.go` già impone, e confronta con ciò che è
     deployato, prima che qualsiasi cosa raggiunga la produzione;
   - un **browser di audit** per il registry — cerca e filtra la storia
     delle foglie (`KindDecision`, `KindTelemetry`, `KindQuorum`, …) con la
     stessa prova di checkpoint verificabile da terze parti che `ChainWatcher` già
     fa programmaticamente, resa leggibile a un auditor umano invece che a
     un'asserzione di test.
2. **Allineamento agli standard — da un modello di policy proprietario a
   uno interoperabile** ([#87](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/87)).
   La tassonomia delle regole di TBP (classi F/I/W/OUT, §5.3),
   la sua audit trail (foglie Merkle-logged solo-hash, §6.2), e il suo
   set di controlli (fail-closed, monitor-before-closed, quorum per
   azioni ad alto rischio) sono oggi specifici di TBP — internamente coerenti
   e testati, ma non mappati su alcun framework esterno che un auditor o un
   regolatore riconoscerebbe già. Il lavoro è identificare a quali
   standard esistenti (ed emergenti) questo si mappa, e dove sono le lacune
   — non assumere che qualcuno di questi si applichi, o che TBP già li soddisfi,
   senza fare prima quella mappatura. Candidati che vale la pena valutare
   come punto di partenza: **ISO/IEC 42001** (standard di sistema di gestione
   dell'AI — il più vicino a un'affermazione di "AI governance"), il **NIST
   AI Risk Management Framework**, gli obblighi di logging e
   supervisione umana dell'**EU AI Act** per sistemi ad alto rischio (§4.1
   foglia-per-decisione e l'arbitrato plan-as-contract del §4.2 sono strutturalmente
   vicini a ciò che chiedono gli Articoli 12/14 — non verificato, richiede una vera
   mappatura, non un'assunzione), **NIST SP 800-207** (Zero Trust
   Architecture — la spec già posiziona TBP rispetto a Zero Trust nel
   §3.3, un confronto formale controllo-per-controllo è il naturale passo
   successivo), e **OSCAL** (il formato machine-readable di controllo/valutazione
   del NIST — un plausibile target di export così che l'audit trail di TBP
   stesso possa alimentare il tooling di compliance standard invece di richiedere un
   lettore su misura). Questo è lavoro di ricerca e specifica prima che di codice:
   il prodotto è una gap analysis e, dove esiste una vera mappatura, o
   codice adattatore o equivalenza documentata — non una riscrittura del motore
   di regole.

## Licenza

Doppia licenza, per sottoalbero:
- **`docs/` e `figs/`**: [CC BY 4.0](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/docs/LICENSE) — liberi di condividere e
  adattare con attribuzione.
- **Tutto il resto** (`config/`, `src/`, `policies/`, `lab/`, `tests/`,
  `deploy/`, `scripts/`, `.github/`): [Apache 2.0](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/LICENSE) — stessa licenza
  del protocollo core in
  [Responsible-Alliance-Protocol](https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol).
  Questo codice è stato a licenza chiusa durante una fase pilota iniziale; quella
  fase è finita — il progetto non è sostenibile costruito da soli, e un
  protocollo di governance la cui stessa dottrina è "mai per fiducia, sempre per
  prova verificabile" non dovrebbe chiedere fiducia sulla propria implementazione.

Vedi [`CONTRIBUTING.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/CONTRIBUTING.md) per come contribuire — codice
incluso ora, non solo documentazione — e le regole da seguire quando
si modifica la spec (normalizzazione della terminologia, citazioni verificate,
changelog).