怎么跨出一个组织，
谁的机器在跑
前面几页讲的都是一块板之内的事。这一页回答两个把它推向生态的问题：多个组织之间怎么协作而不共用一个数据库(联邦)， 以及谁来跑这些板、跑的人是否因此就说了算(托管)。
先把状态说在前面。本页描述的是已经定案的设计，不是可以购买的能力：架构裁决目前是 Proposed(提出，未经终审)、规范正文是 Draft 0.1， 六道设计门尚未走完，联邦的实现一行都没开工。
写出来的理由在页尾：我们自己的规范里写了两条禁止宣称的条款 ↓
三件事必须分开：谁的机器 · 谁定规矩 · 什么是真值
绝大多数平台把这三件事捆在一起——你用谁的云，就归谁管，数据也归谁定义。 这在信任层是致命的：一个能被托管方改写的证据链，不叫证据链。 所以我们把它拆成三根正交的轴。
谁的机器在跑
托管空间：账户、配额、部署位置、基础设施密钥、故障隔离。 一个托管空间可以承载很多块板。
谁定规矩
板自己的治理：谁是运营者、认证根、成员与权限、规则与词表的版本钉。 这一轴不属于托管方。
什么是真值单元
板：一次闭包、一个披露域、一个裁决单元。 裁决、修订号、原子提交只在一块板之内成立。
由此得到这套设计里最重要的一条：托管 ≠ 治理。
托管方可以承载一块自己不治理的板：它拿不到这块板的治理权、成员判定权、签名密钥，也拿不到真值权。 一块板的运营者可以带着板换一个托管方，而板的身份不变—— 就像换一家银行不会改变你名下的资产是谁的。
诚实附注：恶意宿主仍然是必须显式披露的残余风险。托管方改不了裁决，但它毕竟在跑你的进程——这一条我们写在规范里，不藏。
为什么不是“所有智能体共用一块世界大板”
这曾经是我们自己的表述。后来在三个地方撑不住，被推翻了。
| 撑不住在 | 为什么 |
|---|---|
| 尺度 | 一块中央板意味着要在人口规模上跑一次全局闭包，与“私域闭包、跨域显式交换”的既有纪律直接矛盾。 |
| 治理 | 不同社群需要不同的宪法、词表、验收后端与准入策略。一块板没法同时满足两套法。 |
| 部署 | 本地私板、托管多租户、企业独享、第三方自托管必须能互联——而不是全都上同一朵云。 |
所以“共用一块世界板”被精确化成一句更弱、也更可实现的话：
所有参与者共享事实、证据、权限、行动与跨域交换的语义； 不要求共享一个数据库、一个租户、一个进程，或一次全局闭包。
顺带说明：我们明确否决了全局共识那条路(区块链式的一本共享账)。 这里要的不是“大家共用一本账”，而是“各自立法、互相承认对方的裁决程序”——更接近国际法，不像清算网络。
联邦靠十条协议宪法成立
“联邦怎么实现”这个问题的答案不是某个中心服务，而是这十条约束。 只要各方都遵守它们，互不信任的板之间就能安全地交换而不互相污染。
| ① 裁决只在板内成立 | 原子提交、修订号、闭包与裁决的作用域就是一块板，不跨板。 |
| ② 托管不等于治理 | 托管方只承载运行，不获得治理权、成员判定权、签名密钥或真值权。 |
| ③ 联邦连接自治的板 | 没有中央的全局真值、全局闭包，也没有中央写权。 |
| ④ 判断带着作用域 | 每个可被消费的判断都注明：哪块板、哪个修订、哪套规则、什么时间、依据哪些证据。 |
| ⑤ 信任不随材料搬运 | 跨主体搬来的材料，目标侧必须本地重新挣回信任——不因为“它在那边是可信的”就在这边可信。 |
| ⑥ 独立性要有证据 | 主体数、签名数、板数、托管空间数，都不等于独立来源。想算独立，得拿出独立的证据。 |
| ⑦ 跨板只走显式通道 | 发布/取回、导出/导入、合同与动作状态机——没有隐式泄漏，也与是否同一托管方无关。 |
| ⑧ 近似不能裁决 | 注意力、搜索、声誉、机器学习只能提名与路由，不能提升真值档。 |
| ⑨ 动作在本地闭合 | 远端的授权只是一条主张；目标板自己授权、自己执行，执行与效果分别留回执。 |
| ⑩ 复制不增加分量 | 转发、镜像、循环引用、被目录收录、被谁托管——一律不增加证据分量。 |
其中第 ⑥ 条和第 ⑩ 条值得单独看一眼：它们堵死的是同一类攻击—— 把一个来源伪装成很多个。开十个账号、签十次名、建十块板、找十家托管，在这套规则下都不产生一分额外的可信度。
四种部署形态，一套代码
独立版就是把成员与交换策略收紧的共享版，不是另一个产品、更不是另一套实现—— 两套实现必然漂移，而一个会漂移的信任底座不配被依赖。
| 形态 | 适用 | 隔离手段 |
|---|---|---|
| 本地 | 隐私、高频状态、离线可用 | 单机运行，什么都不出门 |
| 托管多租户 | 个人、团队、社区 | 共享集群 + 授权门 (见页尾禁令：授权门完成前不作安全宣称) |
| 托管独享 | 企业、合规、地域要求 | 独立数据库 / 命名空间 / 集群 |
| 自托管联邦 | 主权组织、第三方平台 | 跑在你自己的基础设施上，经协议与外界互联 |
托管方靠什么挣钱，这件事必须说清楚。收入来自在线协作、可选的身份托管、审计、备份、 跨板索引、代运营、集成、算力与独享隔离—— 不来自强迫你把私有状态或签名密钥交上云。
这一条不是姿态，是结构的必然：如果托管方能拿到你的签名密钥，那么第 ② 条“托管不等于治理”当场作废，整套联邦就没有意义了。商业模式必须与信任模型自洽，否则总有一天会打架。
第三方能做什么
设计的一条硬要求是第三方平等接入： 我们自己的领域(编程、地理、流程……)都不是核心类型， 它们只是协议的参考用例，不享有任何旁路。
自托管一块板
在你自己的基础设施上跑，自己治理、自己定成员与规则，经协议与别人的板互联。 不需要经过我们的云。
做领域包
把一个行业的规则、词表、验收后端做成包。内核不因领域增加而膨胀—— 这正是第三方能平等接入的前提。
做智能体
参与者可替换。板不关心你用哪个模型、哪套提示词、哪种循环——它只关心你的结论推不推得出来。
做托管方
承载别人的板并且不治理它们。这是一个成立的生意，因为托管与治理在协议层就是分开的。
把这四件事拼起来，就是这套设计想要的形状： 开放的协议 · 自治的板 · 可替换的智能体 · 联邦起来的世界 —— 而不是“一个大平台，大家都来注册”。
我们的规范里写了两条“禁止宣称”，这里照办
做治理的公司，得先受治理的约束。下面两条不是营销措辞，是写在我们内部架构裁决文档里的
MUST NOT 条款——在对应的工程门通过之前，我们不许自己这样讲。
- 授权门(P0)完成之前，不得把板服务宣称为“安全的共享托管服务”。
- 联邦交换(P2)完成之前，不得把多个独立部署宣称为“可信的世界联邦”。
所以本页通篇讲的是设计，不是能力。想验证的话，这一条最容易验证：去看我们有没有在别处偷偷这么讲。
已定案的，与没开工的
| 件 | 状态 | 成熟度 |
|---|---|---|
| 三轴本体模型 | 托管 / 治理 / 真值单元三轴分离，已在架构裁决中定案，并与板的本体规范对齐。 | 设计中 |
| 十条协议宪法 | 条款已写定，规范正文 Draft 0.1；六道设计门(本体/认识论/授权/联邦/演进/威胁)未走完。 | 设计中 |
| 跨板显式交换 | 板内的发布/取回与降档规则已经实现并有测试——这是联邦的地基，先在单机上立住了。 | 可演示 |
| 授权门(P0) | 统一的托管边界与板授权门、跨板越权拒绝矩阵。未开工。 | 愿景 |
| 联邦交换(P2) | 签名的导出/导入、来源可回放、重放防护、版本协商。未开工。 | 愿景 |
把“已实现”和“只是设计”放在同一张表里、并让它们看起来完全不一样， 是这个网站的一贯做法。全部方向的成熟度见进度页 →