**Aktueller Stand (Stand 2026-09-22): Der Rollout-Code ist implementiert und
getestet entlang des gesamten Pfads — Genesis → Fencing → Registry → Broker → PEP →
Supervision → Translator → Deployment.** Jedes `src/`-Paket bringt seine
eigene Testsuite mit (Go-Unit-/Integrationstests, Python für das Audit- und
Mess-Tooling), und `deploy/selftest/` führt die Deployment-
Anleitungen end-to-end aus (**82 Kontrollen, 0 Fehler** — eine Anleitung, die vom
Code abweicht, bricht dort, nicht beim Operator). Aktuell ist kein PR gegen dieses
Repository offen — der Backlog, der in Arbeit war (T25 kontrollierte
Degradation, T38 begrenzte asynchrone Registry-Haltbarkeit, T26 Translator-
Qualitätsmessung), ist vollständig gemergt. Zwei Punkte bleiben offen und werden
bewusst verfolgt, keiner blockiert den Pilot: die englische Übersetzung der
verbleibenden französischen Dokumentation ([#83](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/83),
in Arbeit — der Großteil von `deploy/` und `docs/` hat bereits englische
Primärfassungen, siehe „Hinweis zur Sprache" oben), und die Inter-Domain-Schicht
(Spec §13 — durch die Spec selbst zurückgestellt, verfolgt in
[#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33), damit
„zurückgestellt" sichtbar bleibt statt stillschweigend zu fehlen). Was darüber hinaus
bewusst **noch nicht** hier ist: die nativen sprachspezifischen
Translator-Korpora (die beim Pilot gebildet werden, §15 — die Pipeline,
die sie abspielt und darauf gated, ist gebaut) und der Pfad zur
menschlichen Schlichtungseskalation (brokerd v1 akzeptiert nur den `structured`-Translator).
`config/` nicht unverändert deployen — jede Datei dort sagt das explizit,
es lohnt sich, das auch hier zu wiederholen. Das Protokoll, gegen das dieser Rollout-Code
steuert, ist ebenfalls kein Skelett: `tbp4.2.1/` vendort den funktionierenden Kern (HSM-
Signer, Merkle-Audit-Kette, OPA-Policy-Engine, Tests, adversarialer Review-
Prozess) in-tree via Git-Submodul, an einen bestimmten Commit gepinnt — hier
vorhanden, ohne kopiert oder dupliziert zu werden.

## Konfigurationsleitfaden — wo anfangen

Basierend auf der Implementierungsreihenfolge (§13) und dem Pilot-P1-Umfang (§13,
§9.1: 1 Server-VLAN, Debian-Router, 2 Zellen, 802.1X, zentrale Registry,
gemessene User-Experience-Regression = 0):

1. **Genesis und Schlüssel** (§7.2, §3.2) — vor allem anderen: eine Genesis-
   Zeremonie, signiert durch das Controller-Quorum (m-of-n, HSM), out-of-band
   verankert. [`scripts/genesis/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/scripts/genesis) stellt das
   Epoch-0-Tooling bereit (Dev-Pfad inklusive); die Zeremonie selbst bleibt
   prozedural, nicht Code — nichts in diesem Repo ersetzt sie.
2. **Cluster-Fencing** (§7, §13 Schritt 2) — Epoch-Ausstellung und -Rotation,
   Controller-Quorum (k-of-n) für Klasse-W-Aktionen, Mirror/Canary-
   Promotion. Erforderlich vor jedem Multi-Zellen-Deployment, einschließlich des
   2-Zellen-P1-Piloten unten — eine einzelne Zelle kann das aufschieben, ein Pilot nicht.
   Implementiert in [`src/cluster/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/cluster) (Single-Authority-Epoch-
   Tracker, Quorum, Promotion durch Empfangsnachweis — dort wird kein privater Schlüssel
   gehalten) und in den Broker verdrahtet ([`src/broker/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/broker)).
3. **OPA + Registry** — OPA installieren, `policies/capabilities.json`
   gemäß [`policies/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/policies/README.md) generieren (`http.send`
   und `time.now_ns` vor jedem Deployment entfernen, niemals danach;
   `validate_determinism.go` und das Determinismus-CI-Gate erzwingen dies),
   mit `lab/docker-compose.yml` starten, um Regeln lokal zu iterieren.
   Das attestierte Manifest und der gemessene Boot (§6.3, §13 Schritt 3) — der
   eigene Zustand einer Zelle muss beweisbar sein, bevor ihre Entscheidungen es sind — sind
   in [`src/registry/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/registry) implementiert, zusammen mit dem Zellen-Log,
   Backpressure und Verankerung.
4. **PEP** — der erste genuin gesteuerte Perimeter (§13), implementiert in
   [`src/pep/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep): Token-Validierung (CWT/COSE, Ed25519),
   speicherbegrenztes fail-closed Anti-Replay, Clock-Status-Degraded-Modus,
   Ausführungsquoten und das Plan-as-Contract-Gate (§4.2, §13 Schritt 4 —
   Token-Validierung allein steuert eine einzelne Aktion, nicht den mehrstufigen
   Plan, den ein Operator tatsächlich signiert). Lies
   [`src/pep/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/README.md) und
   [`config/nftables/pep-redirect.nft`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/nftables/pep-redirect.nft)
   für die Debian-seitige Netzwerkumleitung. **Zuerst im Monitor-Modus deployen**
   (loggen, nicht blockieren) — niemals `closed` beim ersten Rollout (Doktrin
   §5.3); das Verfahren zum Umschalten der Posture ist
   [`deploy/monitor-to-closed.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/deploy/monitor-to-closed.md). Für
   PostgreSQL lebt der In-Process-Zwei-Hook-PEP in
   [`src/pep/postgres-extension/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/postgres-extension) (§4.4).
5. **NAC parallel** — [`config/freeradius/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/freeradius):
   802.1X/EAP-TLS unter Wiederverwendung derselben PKI wie der Handshake (§3), fail-closed
   auf Switch-Ebene erzwungen (nicht nur auf der RADIUS-Seite), kein
   RADIUS-zugewiesenes VLAN in v1. Die `lab/tests/`-netns-Suiten üben die
   Fail-Closed-, MAB/IoT-VLAN- und OCSP-Remediation-Pfade.
6. **Host-Härtung** — [`config/sysctl/99-tbp-hardening.conf`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/sysctl/99-tbp-hardening.conf)
   auf jeder Maschine, die eine TBP-Komponente ausführt (Broker, PEP, Registry).
7. **Translator zuletzt** (§13) — sobald alles andere stabil ist. Geliefert
   in [`src/translator/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/translator): Runtime-Härtung (non-root,
   cap-drop, seccomp — verschieden von `dm-verity`, das das Image at rest schützt,
   nicht die Runtime), die Controlled-Degradation-State-
   Machine (nur structured, kein Cloud-Fallback) und Qualitätsmessung
   (`measure.py` spielt das Korpus ab und gated CI auf FNR/FPR-Regression,
   `tmetrics` schreibt das Ergebnis als Registry-Leaf ein, T26, §4.5) — die
   Korpora selbst werden beim Pilot gebildet, nicht hier ausgeliefert.
8. **Multi-Maschinen-Deployment** — [`deploy/apercu.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/deploy/apercu.md)
   ist der Einstiegspunkt (was, wo, warum, Voraussetzungen); es synthetisiert
   die rollenspezifischen Anleitungen (Router, Zelle, Server, Supervisor) und ihre
   maschinenspezifischen Abnahme-Checklisten. `deploy/selftest/` **führt**
   die Anleitungen aus (`bash deploy/selftest/selftest.sh`, 82 Kontrollen,
   fail-closed) — vor dem Anfassen einer echten Maschine ausführen.

Bei jedem Schritt gegen das Reibungsbudget (§9.1) messen — siehe
[`tests/p1_friction/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/tests/p1_friction) für die exakten Schwellenwerte und
das ausführbare Harness. Der Pilot scheitert, wenn Latenz oder Arbitrierungsrate
diese Schwellenwerte überschreiten, selbst wenn alles andere funktioniert.

## Roadmap: richtig dimensionierte Deployment-Skalen

TBP ist ein komplexes Governance-System in vollem Umfang — Cluster-Fencing, Quorum,
ein unabhängiger Supervisor, ein gehärteter Translator, ein Inter-Entity-
Handshake. Nicht jedes Deployment braucht all das. Ein Einzelserver-Kleinunternehmen,
das „kein KI-Agent handelt ohne nachvollziehbaren, protokollierten Grund" will,
braucht kein Zwei-Zellen-Failover, genauso wenig wie ein Heimnetzwerk ein
SOC braucht. Der Plan ist, das, was in diesem Repository bereits existiert, in
**vier Deployment-Skalen** zu verpacken, jede eine strikte Obermenge der vorherigen —
durchgängig dieselben Primitive (fail-closed, hash-only Leaves, Monitor vor
Closed), mehr davon miteinander verdrahtet, je höher die Skala, und die
Security-Posture — und die operative Komplexität, die sie erkauft —
entsprechend steigend:

- **Skala 1 — Einzelmaschine.** Ein Host, ein gesteuerter Perimeter: `pepd`
  vor dem Dienst, ein lokaler OPA-Sidecar, eine einzelne `CellLog`-
  Registry. Kein Cluster-Fencing (nichts zu fencen mit einer Zelle), kein NAC
  (nichts auf ein Netzwerk zuzulassen — es ist eine Box), kein Broker- oder
  Supervisor-Daemon. Genesis kollabiert auf ein einzelnes Operator-Schlüsselpaar,
  als solches dokumentiert, statt eine Quorum-Zeremonie vorzutäuschen, die
  keine ist. Geringste operative Komplexität: die OPA-Regeln richtig hinbekommen, im
  Monitor-Modus deployen, das Reibungsbudget beobachten, `closed` verdienen.
- **Skala 2 — Kleines Team / einzelner Standort.** Eine Handvoll Maschinen in einem
  LAN hinter einem `brokerd`, weiterhin eine einzelne Registry (noch kein Fencing —
  eine autoritative Zelle reicht bei dieser Größe noch), NAC hinzugefügt
  (`config/freeradius/`, 802.1X am Switch), um Maschinen auf das
  Segment zuzulassen, Host-Härtung überall angewendet. Ein Daemon mehr, ein
  Subsystem mehr, dasselbe Registry-Modell wie Skala 1.
- **Skala 3 — Resiliente Multi-Zelle.** Was bereits vollständig gebaut und
  dokumentiert ist als der Pilot-P1-Deployment oben: 2+ Zellen, Cluster-Fencing
  (Epoch-Ausstellung/-Rotation, k-of-n-Quorum für Klasse-W-Aktionen,
  Mirror/Canary-Promotion), ein unabhängiger Supervisor mit Read-only-
  Konsole, der gehärtete Translator mit kontrollierter Degradation, die vollständige
  `deploy/`-Anleitungssequenz und ihr 82-Kontrollen-Selftest. Für Organisationen,
  die einen Ausfall einer einzelnen Zelle nicht tolerieren können oder deren
  gesteuerte Agenten die zusätzlichen Maschinen rechtfertigen.
- **Skala voll — Multi-Entity.** Der Inter-Entity-Handshake (§3):
  Nachweis von Policy, Historienkontinuität und Liveness über organisatorische
  Grenzen hinweg, nicht nur über Zellen derselben Organisation —
  Föderation zwischen unabhängig gesteuerten TBP-Deployments, die einander
  vertrauen müssen, ohne einander zu vertrauen. Bewusst noch nicht begonnen;
  verfolgt in [#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33)
  (T32), damit es als spätere, eigenständige Phase sichtbar bleibt statt
  stillschweigend zu fehlen. Dies ist genuin neue Protokollarbeit, nicht nur mehr
  Maschinen, die das bereits Existierende ausführen.

**Ehrlichkeit darüber, wo das steht**: Skala 3 ist heute geliefert unter
dem Pilot-P1-Namen, der in dieser README durchgängig verwendet wird. Skalen 1 und 2 sind
noch nicht als eigene Anleitungen verpackt — sie sind heute erreichbar durch Deployen
einer Teilmenge des Dokumentierten (Cluster-Fencing und NAC für Skala 1 überspringen,
NAC hinzufügen, aber eine Zelle für Skala 2 behalten), aber dieser Pfad ist noch nicht
aufgeschrieben, und nichts hindert derzeit jemanden daran, es korrekt
auf eigene Faust zu verdrahten, vorbehaltlich derselben Doktrin. Skala voll erfordert
tatsächlich neuen Code (die drei Beweise aus §3), nicht nur neue Anleitungen.

### Nächste geplante Arbeit

Zwei Arbeitsströme, als separate Issues verfolgt, weil es unterschiedliche
Arten von Aufwand sind:

1. **Skalenspezifische Deployment-Anleitungen plus Admin-Tooling, dimensioniert für jede
   Skala** ([#86](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/86)).
   Die obigen Skalen in `deploy/scale-1.md` /
   `deploy/scale-2.md` zu verwandeln — Skala 3 hat bereits ihre Anleitungssequenz, es ist
   `deploy/apercu.md` und die rollenspezifischen Anleitungen, die es synthetisiert — ist die eine
   Hälfte davon: ein dokumentierter, selftest-abgedeckter Pfad pro Skala statt
   „die Pilot-Anleitung, minus das, was man selbst herausfindet, zu überspringen". Die andere Hälfte
   ist operatorseitiges Tooling, das heute eine
   Read-only-JSON-API ist (`src/supervision/console.go`: `/v1/arbitration`,
   `/v1/epoch`, `/v1/indicators`) plus Rohdateien und CLIs (Rego-Policies
   von Hand bearbeitet, `policies/gen_capabilities.sh` /
   `validate_determinism.go` zum Validieren und Entfernen vor dem Deploy; die
   Registry gelesen durch den verifizierten Scan von `ChainWatcher`, geübt in Tests
   und Selftest, aber ohne Browsing-UI). Drei dedizierte Tools sind
   geplant auf dem, was bereits existiert, jedes zugeschnitten auf das, was eine gegebene
   Skala tatsächlich braucht (ein Skala-1-Operator braucht keine Multi-Zellen-
   Arbitrierungsansichten; ein Skala-3-Operator schon):
   - ein **Supervision-Dashboard** auf der bestehenden Read-only-
     Konsole — menschengerichtet, konstruktionsbedingt weiterhin read-only (§7.1 „der
     Supervisor sieht alles, berührt nichts" gilt unverändert, D81);
   - ein **Regel-/Policy-Editor** für das OPA-Rego-Bundle — bearbeiten, testen
     gegen dieselben Determinismus- und Capability-Stripping-Gates,
     die `validate_determinism.go` bereits erzwingt, und diffen gegen das, was
     deployt ist, bevor irgendetwas die Produktion erreicht;
   - ein **Audit-Browser** für die Registry — Suche und Filterung der Leaf-
     Historie (`KindDecision`, `KindTelemetry`, `KindQuorum`, …) mit demselben
     drittseitig verifizierbaren Checkpoint-Beweis, den `ChainWatcher` bereits
     programmatisch erbringt, lesbar gemacht für einen menschlichen Auditor statt für eine
     Test-Assertion.
2. **Standards-Angleichung — von einem proprietären Policy-Modell zu einem
   interoperablen** ([#87](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/87)).
   TBPs Regel-Taxonomie (Klassen F/I/W/OUT, §5.3),
   sein Audit-Trail (hash-only Merkle-geloggte Leaves, §6.2) und sein
   Kontrollset (fail-closed, Monitor-before-Closed, Quorum für
   High-Stakes-Aktionen) sind heute TBP-spezifisch — intern konsistent
   und getestet, aber nicht auf irgendein externes Framework abgebildet, das ein Auditor oder
   ein Regulator bereits erkennen würde. Die Arbeit besteht darin, zu identifizieren, auf welche
   bestehenden (und aufkommenden) Standards dies abbildet, und wo die Lücken
   sind — nicht anzunehmen, dass irgendeiner davon zutrifft oder dass TBP sie bereits erfüllt,
   ohne zuerst diese Abbildung vorzunehmen. Kandidaten, die es wert sind, als
   Ausgangspunkt evaluiert zu werden: **ISO/IEC 42001** (Standard für KI-Managementsysteme —
   die beste Passung für eine „KI-Governance"-Behauptung), das **NIST
   AI Risk Management Framework**, die Logging- und
   Human-Oversight-Pflichten des **EU AI Act** für Hochrisikosysteme (§4.1s Leaf-per-
   Decision und §4.2s Plan-as-Contract-Arbitrierung sind strukturell
   nahe an dem, was Artikel 12/14 verlangen — unverifiziert, braucht eine echte
   Abbildung, keine Annahme), **NIST SP 800-207** (Zero Trust
   Architecture — die Spec positioniert TBP bereits gegenüber Zero Trust in
   §3.3, ein formaler Kontrolle-für-Kontrolle-Vergleich ist der natürliche nächste
   Schritt) und **OSCAL** (NISTs maschinenlesbares Control/Assessment-
   Format — ein plausibles Exportziel, damit TBPs eigener Audit-Trail
   Standard-Compliance-Tooling speisen kann, statt einen maßgeschneiderten Reader
   zu erfordern). Dies ist Forschungs- und Spezifikationsarbeit, bevor es Code ist:
   das Produkt ist eine Gap-Analyse und, wo eine echte Abbildung existiert, entweder
   Adapter-Code oder dokumentierte Äquivalenz — kein Rewrite der Regel-
   Engine.

## Lizenzierung

Duale Lizenz, nach Subtree:
- **`docs/` und `figs/`**: [CC BY 4.0](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/docs/LICENSE) — frei zum Teilen und
  Anpassen mit Attribution.
- **Alles andere** (`config/`, `src/`, `policies/`, `lab/`, `tests/`,
  `deploy/`, `scripts/`, `.github/`): [Apache 2.0](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/LICENSE) — dieselbe Lizenz
  wie das Kernprotokoll in
  [Responsible-Alliance-Protocol](https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol).
  Dieser Code war während einer anfänglichen Pilotphase closed-license; diese
  Phase ist vorbei — das Projekt ist nicht lebensfähig, allein gebaut zu werden, und ein
  Governance-Protokoll, dessen eigene Doktrin „niemals durch Vertrauen, immer durch
  verifizierbaren Beweis" lautet, sollte nicht um Vertrauen in seine eigene Implementierung
  bitten.

Siehe [`CONTRIBUTING.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/CONTRIBUTING.md) für Beiträge — Code
jetzt inklusive, nicht nur Dokumentation — und die Regeln, die beim
Bearbeiten der Spec zu befolgen sind (Terminologie-Normalisierung, verifizierte Zitate,
Changelog).