**当前状态（截至 2026-09-22）：部署代码已实现并
在完整路径上测试通过——创世 → 围栏 → 注册表 → 代理 → PEP →
监督 → 翻译器 → 部署。** 每个 `src/` 包都带有自己的测试套件
（Go 单元/集成测试，审计和测量工具使用 Python），
`deploy/selftest/` 端到端执行部署指南
（**82 项控制，0 失败**——偏离代码的指南会在这里失败，
而不是在操作员那里失败）。目前没有针对此仓库的开放 PR——
之前进行中的待办事项（T25 受控降级、T38 有界异步注册表持久性、
T26 翻译器质量测量）均已合并。有两项被有意保持开放并跟踪，
均不阻塞试点：剩余法语文档的英文翻译
（[#83](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/83)，
进行中——`deploy/` 和 `docs/` 的大部分已有英文主版本，
见上文“关于语言的说明”），以及跨域层
（规范 §13——由规范本身推迟，跟踪于
[#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33)，
以便“推迟”保持可见而非悄然缺失）。除此之外，有意
**尚未**包含的内容：原生各语言翻译器语料库
（将在试点时构建，§15——回放并以其为门控的流水线已构建）
以及人工仲裁升级路径（brokerd v1 仅接受 `structured` 翻译器）。
不要按原样部署 `config/`——那里的每个文件都明确说明了这一点，
在此也值得重复。此部署代码所依据的协议也不是骨架：
`tbp4.2.1/` 通过 git submodule 在树内 vendor 了工作核心
（HSM 签名器、Merkle 审计链、OPA 策略引擎、测试、对抗性审查
流程），固定到特定提交——在此存在，但未被复制或重复。

## 配置指南——从哪里开始

基于实现顺序（§13）和试点 P1 范围（§13、
§9.1：1 个服务器 VLAN、Debian 路由器、2 个单元、802.1X、中央注册表、
实测用户体验回归 = 0）：

1. **创世与密钥**（§7.2、§3.2）——先于一切：由控制器
   法定人数（m-of-n、HSM）签名的创世仪式，带外锚定。
   [`scripts/genesis/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/scripts/genesis) 提供
   epoch-0 工具（含开发路径）；仪式本身仍是
   程序性的，而非代码——此仓库中没有任何东西替代它。
2. **集群围栏**（§7、§13 步骤 2）——epoch 签发与轮换、
   控制器法定人数（k-of-n）用于 class-W 操作、镜像/金丝雀
   晋升。在任何多单元部署之前必需，包括下面的
   2 单元 P1 试点——单单元可以推迟此项，试点不能。
   实现在 [`src/cluster/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/cluster)（单权威 epoch
   跟踪器、法定人数、基于接收证明的晋升——那里不持有
   私钥）并接入代理（[`src/broker/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/broker)）。
3. **OPA + 注册表**——安装 OPA，按照
   [`policies/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/policies/README.md) 生成 `policies/capabilities.json`
   （在任何部署之前剥离 `http.send` 和 `time.now_ns`，绝不在之后；
   `validate_determinism.go` 和确定性 CI 门控强制执行此点），
   用 `lab/docker-compose.yml` 启动它以在本地迭代规则。
   经证实的清单和测量启动（§6.3、§13 步骤 3）——单元
   自身状态必须在其决策之前可证明——实现在
   [`src/registry/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/registry) 中，与单元日志、
   背压和锚定并列。
4. **PEP**——第一个真正受治理的边界（§13），实现在
   [`src/pep/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep)：令牌验证（CWT/COSE、Ed25519）、
   内存有界故障关闭反重放、时钟状态降级模式、
   执行配额，以及计划即合约门控（§4.2、§13 步骤 4——
   仅令牌验证治理单个操作，而非操作员实际签署的
   多步计划）。阅读
   [`src/pep/README.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/README.md)，以及
   [`config/nftables/pep-redirect.nft`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/nftables/pep-redirect.nft)
   了解 Debian 侧网络重定向。**首先以监控模式部署**
   （记录，不阻断）——首次部署绝不使用 `closed`（原则
   §5.3）；姿态切换流程见
   [`deploy/monitor-to-closed.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/deploy/monitor-to-closed.md)。对于
   PostgreSQL，进程内双钩子 PEP 位于
   [`src/pep/postgres-extension/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/pep/postgres-extension)（§4.4）。
5. **并行 NAC**——[`config/freeradius/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/freeradius)：
   802.1X/EAP-TLS 复用与握手相同的 PKI（§3），故障关闭
   在交换机层面强制执行（不仅在 RADIUS 侧），v1 中无
   RADIUS 分配的 VLAN。`lab/tests/` netns 套件演练
   故障关闭、MAB/IoT-VLAN 和 OCSP 修复路径。
6. **主机加固**——[`config/sysctl/99-tbp-hardening.conf`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/config/sysctl/99-tbp-hardening.conf)
   应用于每台运行 TBP 组件（代理、PEP、注册表）的机器。
7. **翻译器最后**（§13）——一旦其他一切稳定。交付
   于 [`src/translator/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/src/translator)：运行时加固（非 root、
   cap-drop、seccomp——区别于 `dm-verity`，后者保护
   静态镜像，而非运行时）、受控降级状态
   机（仅结构化，无云回退），以及质量测量
   （`measure.py` 回放语料库并在 FNR/FPR 回归上对 CI 进行门控，
   `tmetrics` 将结果作为注册表叶子写入，T26、§4.5）——
   语料库本身在试点时构建，不在此处发布。
8. **多机部署**——[`deploy/apercu.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/deploy/apercu.md)
   是入口点（什么、在哪里、为什么、先决条件）；它综合了
   各角色指南（路由器、单元、服务器、监督器）及其
   每机验收清单。`deploy/selftest/` **执行**
   这些指南（`bash deploy/selftest/selftest.sh`，82 项控制，
   故障关闭）——在接触真实机器之前运行它。

每一步都要对照摩擦预算（§9.1）进行测量——参见
[`tests/p1_friction/`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/tests/p1_friction) 了解确切阈值和
可运行的测试框架。如果延迟或仲裁率超过这些阈值，
试点即失败，即使其他一切正常。

## 路线图：规模适配的部署层级

TBP 是一个复杂的、全规模的治理系统——集群围栏、法定人数、
独立监督器、加固翻译器、跨实体握手。并非每个部署都需要
全部这些。一个想要“没有可证明、有记录的理由，任何 AI 代理都不得行动”
的单服务器小企业，不需要双单元故障转移，就像家庭网络不需要
SOC 一样。计划是将此仓库中已有的内容打包成
**四个部署层级**，每个都是前一个的严格超集——
自始至终使用相同的原语（故障关闭、仅哈希叶子、先监控后
关闭），随着层级上升，更多原语被连接在一起，安全姿态——
以及为此付出的运营复杂性——相应增加：

- **层级 1——单机。** 一台主机，一个受治理边界：`pepd`
  在服务前面，本地 OPA sidecar，单个 `CellLog`
  注册表。无集群围栏（单单元无可围栏之物），无 NAC
  （无可准入网络之物——就一台机器），无代理或
  监督器守护进程。创世坍缩为单个操作员密钥对，
  如实记录，而非假装一个并非如此的法定人数仪式。
  最低运营复杂性：把 OPA 规则弄对，以监控模式部署，
  观察摩擦预算，赢得 `closed`。
- **层级 2——小团队/单站点。** 一个 LAN 上的几台机器位于一个 `brokerd`
  之后，仍是单个注册表（尚无围栏——
  在这个规模下一个权威单元仍然足够），添加 NAC
  （`config/freeradius/`，交换机处的 802.1X）以准入机器进入
  网段，处处应用主机加固。多一个守护进程，多一个
  子系统，与层级 1 相同的注册表模型。
- **层级 3——弹性多单元。** 已完全构建并
  记录为上述试点 P1 部署的内容：2+ 单元、集群围栏
  （epoch 签发/轮换、class-W 操作的 k-of-n 法定人数、
  镜像/金丝雀晋升）、带只读
  控制台的独立监督器、带受控降级的加固翻译器、完整的
  `deploy/` 指南序列及其 82 项控制自测。适用于
  无法容忍单单元宕机的组织，或其受治理代理
  证明额外机器合理的组织。
- **完整层级——多实体。** 跨实体握手（§3）：
  跨组织边界证明策略、历史连续性和活性，
  而不仅是同一组织的单元之间——
  独立治理的 TBP 部署之间的联邦，它们必须
  互相信任而又不互相信任。有意尚未开始；
  跟踪于 [#33](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/33)
  （T32），以便它作为后期独立阶段保持可见，而非
  悄然缺失。这是真正的新协议工作，而不仅是更多
  机器运行已有内容。

**关于现状的诚实说明**：层级 3 今天以本 README 中通篇使用的
试点 P1 名称交付。层级 1 和 2 尚未打包为
各自的指南——它们今天可以通过部署
已记录内容的子集来达到（层级 1 跳过集群围栏和 NAC，
层级 2 添加 NAC 但保留一个单元），但该路径尚未写下来，
目前也没有任何东西阻止某人自行正确接线，但须遵守相同的原则。
完整层级需要实际的新代码（§3 的三个证明），而不仅是新指南。

### 下一步计划工作

两个工作流，作为独立 issue 跟踪，因为它们是不同
类型的努力：

1. **各层级部署指南，以及适配各层级的
   管理工具**（[#86](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/86)）。
   将上述层级转化为 `deploy/scale-1.md` /
   `deploy/scale-2.md`——层级 3 已有其指南序列，即
   `deploy/apercu.md` 及其综合的各角色指南——是其中的
   一半：每个层级都有文档化、自测覆盖的路径，而非
   “试点指南，减去你自己摸索出要跳过的部分”。另一半
   是面向操作员的工具，目前是一个
   只读 JSON API（`src/supervision/console.go`：`/v1/arbitration`、
   `/v1/epoch`、`/v1/indicators`）加上原始文件和 CLI（Rego 策略
   手工编辑，`policies/gen_capabilities.sh` /
   `validate_determinism.go` 用于部署前验证和剥离；注册表
   由 `ChainWatcher` 的验证扫描读取，在测试
   和自测中演练，但没有浏览 UI）。在已有内容之上
   计划了三个专用工具，每个都限定于给定
   层级实际需要的范围（层级 1 操作员不需要多单元
   仲裁视图；层级 3 操作员需要）：
   - 在现有只读
     控制台之上的**监督仪表板**——面向人类，构造上仍为只读（§7.1“监督器
     看到一切，不触碰任何东西”原样延续，
     D81）；
   - 用于 OPA Rego 包的**规则/策略编辑器**——编辑、针对
     `validate_determinism.go` 已强制执行的相同确定性和能力剥离门控
     进行测试，并与已部署内容进行 diff，
     在任何东西到达生产之前；
   - 用于注册表的**审计浏览器**——搜索和过滤叶子
     历史（`KindDecision`、`KindTelemetry`、`KindQuorum`、……），
     使用与 `ChainWatcher` 已以编程方式执行的相同的第三方可验证
     检查点证明，使其对人类审计员可读，
     而非测试断言。
2. **标准对齐——从专有策略模型到
   可互操作模型**（[#87](https://github.com/philippeabraxas-jpg/TBP-NETWORK/issues/87)）。
   TBP 的规则分类法（类别 F/I/W/OUT，§5.3）、
   其审计追踪（仅哈希的 Merkle 记录叶子，§6.2）及其
   控制集（故障关闭、先监控后关闭、高风险操作的
   法定人数）目前是 TBP 特有的——内部一致
   且经过测试，但未映射到审计员或
   监管机构已认可的任何外部框架。工作是识别这映射到哪些
   现有（及新兴）标准，以及差距
   在哪里——不是在没有先做该映射的情况下假设其中任何一项适用，
   或 TBP 已满足它们。值得作为起点评估的
   候选：**ISO/IEC 42001**（AI 管理体系
   标准——最契合“AI 治理”主张）、**NIST
   AI 风险管理框架**、**EU AI Act** 对高风险系统的日志和
   人类监督义务（§4.1 的每决策一叶子和 §4.2 的计划即合约仲裁在结构上
   接近第 12/14 条的要求——未经核实，需要真正的
   映射，而非假设）、**NIST SP 800-207**（零信任
   架构——规范已在 §3.3 中将 TBP 定位于零信任，逐控制的正式比较是自然的下一步），
   以及 **OSCAL**（NIST 的机器可读控制/评估
   格式——一个可能的导出目标，使 TBP 自身的审计追踪能够馈入
   标准合规工具，而非需要定制读取器）。
   这是代码之前的研究和规范工作：产品是差距分析，
   以及在存在真实映射的地方，适配器代码或文档化等价性——
   而非重写规则引擎。

## 许可

双许可，按子树：
- **`docs/` 和 `figs/`**：[CC BY 4.0](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/docs/LICENSE)——可自由分享和
  改编，需署名。
- **其他一切**（`config/`、`src/`、`policies/`、`lab/`、`tests/`、
  `deploy/`、`scripts/`、`.github/`）：[Apache 2.0](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/LICENSE)——与
  [Responsible-Alliance-Protocol](https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol)
  中的核心协议相同许可。
  此代码在初始试点阶段为闭源许可；该
  阶段已结束——项目独自构建不可行，而一个
  自身原则为“绝不靠信任，始终靠可验证证明”的治理协议，
  不应在其自身实现上要求信任。

参见 [`CONTRIBUTING.md`](https://github.com/philippeabraxas-jpg/tbp-network/blob/main/CONTRIBUTING.md) 了解如何贡献——现在包括代码，
不仅是文档——以及编辑规范时需遵循的规则（术语规范化、经验证的引用、
变更日志）。