**Estado actual (a 2026-09-22): el código de despliegue está implementado y
probado a lo largo de toda la ruta — génesis → fencing → registro → broker → PEP →
supervisión → traductor → despliegue.** Cada paquete de `src/` lleva su
propia suite de pruebas (pruebas unitarias/de integración en Go, Python para el
herramental de auditoría y medición), y `deploy/selftest/` ejecuta las guías de
despliegue de extremo a extremo (**82 controles, 0 fallos** — una guía que se
desvía del código falla ahí, no en el operador). No hay ningún PR abierto contra este
repositorio en este momento — el backlog que estaba en curso (T25 degradación
controlada, T38 durabilidad del registro con async acotado, T26 medición de
calidad del traductor) ya se ha fusionado. Quedan dos elementos abiertos y rastreados
deliberadamente, ninguno bloquea el piloto: la traducción al inglés de la
documentación francesa restante ([#83](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/83),
en curso — la mayor parte de `deploy/` y `docs/` ya tiene primarios en inglés,
véase "Nota sobre el idioma" arriba), y la capa inter-dominio
(spec §13 — diferida por la propia spec, rastreada en
[#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33) para que
"diferida" siga siendo visible en lugar de estar silenciosamente ausente). Lo que
deliberadamente **no** está aquí todavía más allá de eso: los corpus nativos del
traductor por lenguaje (a constituirse en el piloto, §15 — el pipeline
que los reproduce y aplica las compuertas está construido) y la ruta de
escalado por arbitraje humano (brokerd v1 acepta solo el traductor
`structured`).
No despliegue `config/` tal cual — cada archivo allí lo dice explícitamente,
vale la pena repetirlo aquí también. El protocolo contra el que gobierna este código de despliegue
tampoco es un esqueleto: `tbp4.2.1/` incorpora el núcleo funcional (firmante HSM, cadena de auditoría Merkle, motor de políticas OPA, pruebas, proceso de revisión adversarial)
en el árbol mediante submódulo git, fijado a un commit específico — presente
aquí sin ser copiado ni duplicado.

## Guía de configuración — por dónde empezar

Basado en la secuencia de implementación (§13) y el alcance del piloto P1 (§13,
§9.1: 1 VLAN de servidor, router Debian, 2 celdas, 802.1X, registro central,
regresión medida de experiencia de usuario = 0):

1. **Génesis y claves** (§7.2, §3.2) — antes que nada: una ceremonia de génesis
   firmada por el quórum del controlador (m-de-n, HSM), anclada
   fuera de banda. [`scripts/genesis/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/scripts/genesis) proporciona el
   herramental de época-0 (incluida la ruta de desarrollo); la ceremonia en sí sigue siendo
   procedimental, no código — nada en este repositorio la reemplaza.
2. **Fencing del clúster** (§7, §13 paso 2) — emisión y rotación de épocas,
   quórum del controlador (k-de-n) para acciones de clase-W, promoción de
   espejo/canario. Requerido antes de cualquier despliegue multicelda, incluido el
   piloto P1 de 2 celdas de abajo — una sola celda puede diferir esto, un piloto no.
   Implementado en [`src/cluster/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/cluster) (rastreador de época de autoridad única,
   quórum, promoción por prueba de recepción — no se guarda ninguna clave privada
   allí) y conectado al broker ([`src/broker/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/broker)).
3. **OPA + registro** — instale OPA, genere `policies/capabilities.json`
   siguiendo [`policies/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/policies/README.md) (elimine
   `http.send` y `time.now_ns` antes de cualquier despliegue, nunca después;
   `validate_determinism.go` y la compuerta de CI de determinismo lo aplican),
   arránquelo con `lab/docker-compose.yml` para iterar sobre las reglas localmente.
   El manifiesto atestiguado y el arranque medido (§6.3, §13 paso 3) — el estado
   propio de una celda debe ser demostrable antes de que lo sean sus decisiones — están implementados
   en [`src/registry/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/registry) junto con el registro de celda,
   la contrapresión y el anclaje.
4. **PEP** — el primer perímetro genuinamente gobernado (§13), implementado en
   [`src/pep/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep): validación de tokens (CWT/COSE, Ed25519),
   anti-replay fail-closed con memoria acotada, modo degradado por estado del reloj,
   cuotas de ejecución, y la compuerta de plan-como-contrato (§4.2, §13 paso 4 —
   la validación de tokens por sí sola gobierna una acción única, no el plan
   multipaso que un operador realmente firma). Lea
   [`src/pep/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/README.md), y
   [`config/nftables/pep-redirect.nft`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/nftables/pep-redirect.nft)
   para la redirección de red del lado Debian. **Despliegue primero en modo monitor**
   (registrar, sin bloquear) — nunca `closed` en el primer despliegue (doctrina
   §5.3); el procedimiento de cambio de postura es
   [`deploy/monitor-to-closed.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/deploy/monitor-to-closed.md). Para
   PostgreSQL, el PEP de dos hooks en proceso vive en
   [`src/pep/postgres-extension/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/postgres-extension) (§4.4).
5. **NAC en paralelo** — [`config/freeradius/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/freeradius):
   802.1X/EAP-TLS reutilizando la misma PKI que el handshake (§3), fail-closed
   aplicado a nivel del switch (no solo en el lado RADIUS), sin
   VLAN asignada por RADIUS en v1. Las suites netns de `lab/tests/` ejercitan las
   rutas fail-closed, MAB/IoT-VLAN y remediación OCSP.
6. **Endurecimiento del host** — [`config/sysctl/99-tbp-hardening.conf`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/sysctl/99-tbp-hardening.conf)
   en cada máquina que ejecute un componente TBP (broker, PEP, registro).
7. **Traductor al final** (§13) — una vez que todo lo demás esté estable. Entregado
   en [`src/translator/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/translator): endurecimiento en tiempo de ejecución (no-root,
   cap-drop, seccomp — distinto de `dm-verity`, que protege la
   imagen en reposo, no el tiempo de ejecución), la máquina de estados de degradación
   controlada (solo estructurado, sin fallback a la nube), y medición de calidad
   (`measure.py` reproduce el corpus y aplica compuertas de CI sobre la regresión de FNR/FPR,
   `tmetrics` inscribe el resultado como una hoja del registro, T26, §4.5) — los
   corpus en sí se constituyen en el piloto, no se envían aquí.
8. **Despliegue multimáquina** — [`deploy/apercu.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/deploy/apercu.md)
   es el punto de entrada (qué, dónde, por qué, prerrequisitos); sintetiza
   las guías por rol (router, celda, servidor, supervisor) y sus
   listas de verificación de aceptación por máquina. `deploy/selftest/` **ejecuta**
   las guías (`bash deploy/selftest/selftest.sh`, 82 controles,
   fail-closed) — ejecútelo antes de tocar una máquina real.

En cada paso, mida contra el presupuesto de fricción (§9.1) — véase
[`tests/p1_friction/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/tests/p1_friction) para los umbrales exactos y
el arnés ejecutable. El piloto falla si la latencia o la tasa de arbitraje
superan estos umbrales, incluso si todo lo demás funciona.

## Hoja de ruta: escalas de despliegue dimensionadas adecuadamente

TBP es un sistema de gobernanza complejo y a escala completa — fencing de clúster, quórum,
un supervisor independiente, un traductor endurecido, un handshake
inter-entidad. No todos los despliegues necesitan todo esto. Una pequeña
empresa de un solo servidor que quiere "ningún agente de IA actúa sin una razón
demostrable y registrada" no necesita failover de dos celdas más de lo que una red doméstica necesita un
SOC. El plan es empaquetar lo que ya existe en este repositorio en
**cuatro escalas de despliegue**, cada una un superconjunto estricto de la anterior —
los mismos primitivos en todo momento (fail-closed, hojas solo-hash, monitor antes de
closed), más de ellos conectados a medida que sube la escala, y la
postura de seguridad — y la complejidad operativa que esta compra —
aumentando en consecuencia:

- **Escala 1 — Máquina única.** Un host, un perímetro gobernado: `pepd`
  frente al servicio, un sidecar OPA local, un registro `CellLog` único.
  Sin fencing de clúster (nada que cercar con una celda), sin NAC
  (nada que admitir en una red — es una sola caja), sin daemon de broker o
  supervisor. La génesis se reduce a un único par de claves de operador,
  documentado como tal en lugar de pretender una ceremonia de quórum que no
  lo es. Menor complejidad operativa: acertar con las reglas OPA, desplegar en
  modo monitor, vigilar el presupuesto de fricción, ganarse `closed`.
- **Escala 2 — Equipo pequeño / sitio único.** Un puñado de máquinas en una
  LAN detrás de un `brokerd`, todavía un registro único (sin fencing aún —
  una celda autoritativa sigue siendo suficiente a este tamaño), NAC añadido
  (`config/freeradius/`, 802.1X en el switch) para admitir máquinas en el
  segmento, endurecimiento del host aplicado en todas partes. Un daemon más, un
  subsistema más, el mismo modelo de registro que la escala 1.
- **Escala 3 — Multicelda resiliente.** Lo que ya está completamente construido y
  documentado como el despliegue piloto P1 de arriba: 2+ celdas, fencing de clúster
  (emisión/rotación de épocas, quórum k-de-n para acciones de clase-W,
  promoción de espejo/canario), un supervisor independiente con una consola
  de solo lectura, el traductor endurecido con degradación controlada, la secuencia completa
  de guías de `deploy/` y su selftest de 82 controles. Para organizaciones
  que no pueden tolerar que una sola celda caiga, o cuyos agentes gobernados
  justifican las máquinas adicionales.
- **Escala completa — Multi-entidad.** El handshake inter-entidad (§3):
  demostrar política, continuidad de historial y vivacidad a través de fronteras
  organizacionales, no solo entre celdas de la misma organización —
  federación entre despliegues TBP gobernados independientemente que tienen que
  confiar entre sí sin confiar entre sí. Deliberadamente no iniciado
  todavía; rastreado en [#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33)
  (T32) para que siga visible como una fase posterior y distinta en lugar de
  silenciosamente ausente. Esto es genuinamente trabajo de protocolo nuevo, no solo más
  máquinas ejecutando lo que ya existe.

**Honestidad sobre dónde está esto**: la escala 3 se entrega hoy bajo
el nombre piloto-P1 usado en todo este README. Las escalas 1 y 2 aún no
están empaquetadas como sus propias guías — son alcanzables hoy desplegando
un subconjunto de lo documentado (omita el fencing de clúster y el NAC para la escala 1,
añada NAC pero mantenga una celda para la escala 2), pero esa ruta no está escrita
todavía, y nada impide actualmente que alguien la conecte correctamente por
su cuenta sujeto a la misma doctrina. La escala completa requiere código nuevo real
(las tres pruebas de §3), no solo guías nuevas.

### Próximo trabajo planificado

Dos flujos de trabajo, rastreados como issues separados porque son tipos
de esfuerzo diferentes:

1. **Guías de despliegue por escala, más herramental de administración dimensionado para cada
   escala** ([#86](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/86)).
   Convertir las escalas anteriores en `deploy/scale-1.md` /
   `deploy/scale-2.md` — la escala 3 ya tiene su secuencia de guías, es
   `deploy/apercu.md` y las guías por rol que sintetiza — es la mitad
   de esto: una ruta documentada y cubierta por selftest por escala en lugar de
   "la guía del piloto, menos lo que averigües que hay que omitir". La otra mitad
   es el herramental orientado al operador, que hoy es una
   API JSON de solo lectura (`src/supervision/console.go`: `/v1/arbitration`,
   `/v1/epoch`, `/v1/indicators`) más archivos crudos y CLIs (políticas Rego
   editadas a mano, `policies/gen_capabilities.sh` /
   `validate_determinism.go` para validar y eliminar antes de desplegar; el
   registro leído por el escaneo verificado de `ChainWatcher`, ejercitado en pruebas
   y selftest pero sin interfaz de navegación). Tres herramientas dedicadas están
   planificadas sobre lo que ya existe, cada una dimensionada para lo que una escala dada
   realmente necesita (un operador de escala 1 no necesita vistas de arbitraje
   multicelda; uno de escala 3 sí):
   - un **panel de supervisión** sobre la consola de solo lectura
     existente — orientado a humanos, todavía de solo lectura por construcción (§7.1 "el
     supervisor ve todo, no toca nada" se mantiene
     sin cambios, D81);
   - un **editor de reglas/políticas** para el bundle Rego de OPA — editar, probar
     contra las mismas compuertas de determinismo y eliminación de capacidades que
     `validate_determinism.go` ya aplica, y comparar contra lo que está
     desplegado, antes de que nada llegue a producción;
   - un **navegador de auditoría** para el registro — buscar y filtrar el historial
     de hojas (`KindDecision`, `KindTelemetry`, `KindQuorum`, …) con la
     misma prueba de checkpoint verificable por terceros que `ChainWatcher` ya
     hace programáticamente, hecha legible para un auditor humano en lugar de una
     aserción de prueba.
2. **Alineación con estándares — de un modelo de políticas propietario a
   uno interoperable** ([#87](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/87)).
   La taxonomía de reglas de TBP (clases F/I/W/OUT, §5.3),
   su rastro de auditoría (hojas registradas en Merkle solo-hash, §6.2), y su
   conjunto de controles (fail-closed, monitor-antes-de-closed, quórum para
   acciones de alto riesgo) son específicos de TBP hoy — internamente consistentes
   y probados, pero no mapeados a ningún marco externo que un auditor o un
   regulador ya reconocería. El trabajo es identificar a qué
   estándares existentes (y emergentes) se mapea esto, y dónde están las brechas
   — no asumir que alguno de estos aplica, o que TBP ya los satisface,
   sin hacer primero ese mapeo. Candidatos que vale la pena evaluar
   como punto de partida: **ISO/IEC 42001** (estándar de sistema de gestión de IA —
   el que mejor encaja para una afirmación de "gobernanza de IA"), el **Marco de Gestión de Riesgos de IA del NIST**,
   las obligaciones de registro y supervisión humana de la **Ley de IA de la UE** para sistemas de alto riesgo
   (la hoja-por-decisión de §4.1 y el arbitraje de plan-como-contrato de §4.2 son estructuralmente
   cercanos a lo que piden los Artículos 12/14 — sin verificar, necesita un mapeo
   real, no una suposición), **NIST SP 800-207** (Arquitectura Zero Trust
   — la spec ya posiciona TBP frente a Zero Trust en
   §3.3, una comparación formal control por control es el siguiente paso
   natural), y **OSCAL** (el formato de control/evaluación legible por máquina del NIST
   — un objetivo de exportación plausible para que el propio rastro de auditoría de TBP pueda alimentar
   el herramental de cumplimiento estándar en lugar de requerir un lector
   a medida).
   Esto es trabajo de investigación y especificación antes de ser código:
   el producto es un análisis de brechas y, donde existe un mapeo real, ya sea
   código adaptador o equivalencia documentada — no una reescritura del motor
   de reglas.

## Licencia

Licencia dual, por subárbol:
- **`docs/` y `figs/`**: [CC BY 4.0](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/docs/LICENSE) — libres de compartir y
  adaptar con atribución.
- **Todo lo demás** (`config/`, `src/`, `policies/`, `lab/`, `tests/`,
  `deploy/`, `scripts/`, `.github/`): [Apache 2.0](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/LICENSE) — la misma licencia
  que el protocolo central en
  [Responsible-Alliance-Protocol](https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol).
  Este código tuvo licencia cerrada durante una fase piloto inicial; esa
  fase terminó — el proyecto no es viable construido en solitario, y un
  protocolo de gobernanza cuya propia doctrina es "nunca por confianza, siempre por
  prueba verificable" no debería pedir confianza sobre su propia implementación.

Véase [`CONTRIBUTING.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/CONTRIBUTING.md) para saber cómo contribuir — código
incluido ahora, no solo documentación — y las reglas a seguir al
editar la spec (normalización de terminología, citas verificadas,
changelog).