摘要

  • 2020 年 9 月的记录确认了两件事：AFPUB-2020-GEN-004-DRAFT02 是继 AFPUB-2020-GEN-004-DRAFT01 之后被识别的版本，且九月出现了一项针对 Draft 2 的共识声明。它没有提供一份完整、经认证、可逐条核对的 D1→D2 红线，因此不能据此断言任何具体条款被增加、删除、收窄、扩大或原样保留。
  • 共识声明是一项关于特定文本与特定程序的判断，不是权力的原始来源。Policy Development Process、PDWG、董事会地位与 RSA 都要分别通过自身的范围、权限和适用性检验；任何一项都不能靠循环引用，把另一项抬升为无限权力。
  • 一项可复核的共识判断需要完整的异议台账：确切版本、异议命题、提出者角色、受影响条款、所据证据、作者回应、共同主席处理结论与理由、最终文本位置，以及仍未解决的部分。现有记录缺少这样一条完整链条，也没有披露足以说明多少受影响成员或运营者审阅了确切 Draft 2 的分母。
  • 董事会面对公司法、合同、安全、可行性与业务连续性风险时，确有提出狭窄风险意见的正当空间；但这种接口必须有明确事由、公开理由、证据、时限、复核和回滚，而不能变成随意改写政策的通行证。
  • NRS、Lu Heng、LARUS 与 BTW 在这项分析中承担不同且受限的角色：成员保护与去中心化、记账人边界与“出席不等于授权”、运营连续性的传导机制，以及对文本、程序、权力、证据和未知的分层核验。它们都不替代 AFRINIC 的正式记录，也不构成国家权力或执法授权。

L3 — 九月共识判断实际推进的是哪一版文本

一个程序词语的重量，止于它所指向的文本

把时间停在 2020 年 9 月，最重要的动作不是先评价 Draft 2 好坏，而是先辨认究竟发生了什么。可核实的制度动作，是 AFPUB-2020-GEN-004-DRAFT02 的发布，以及同月对这份 Draft 2 作出的共识声明。AFRINIC 32 的公共政策会议举行于 9 月 16 日，为这项声明提供会议语境。这里的“共识”首先是一个程序词语：共同主席或程序主持者对一份已识别文本所处状态作出判断，使它可能沿既定路径继续前进。

这个词语当然有实际分量。若一项程序完全不能形成任何阶段性判断，参与者便无法知道某一版本是否仍在起草、是否需要回应更多异议，或是否可以进入后续审查。共识判断的正当用途，正是把分散的讨论收束到一个可识别的程序节点。然而，它的分量必须由指向对象来界定：是哪一个版本、在什么审阅期间、通过哪些公开渠道、面对哪些仍属实质性的异议、依据什么理由作出判断。离开这些限定，“共识”就从可检查的程序结论滑向一种无边界的政治修辞。

因此，九月声明能够直接证明的事情很窄。它证明记录把 Draft 2 当作当时的共识对象；证明程序状态相对于更早版本发生了变化；也证明处理者认为相关异议已经达到可以作出该程序判断的状态。它不能单独证明所有受影响方都同意文本，不能证明所有资源持有人都审阅了文本，不能证明未发言者同意，更不能证明 AFRINIC 因此获得原本不在其私人技术与公司权限之内的权力。

这一区分不是削弱共识，而是保护共识。只有把程序判断限制在它真正能够承载的范围内，人们才能就版本、异议和理由进行复核。若把同一个词同时用作“讨论阶段结束”“成员普遍授权”“董事会权力合法”“合同已经生效”和“实施可以启动”的替代品，它反而什么都证明不了。一个词承担五种不同制度功能，结果通常不是权威增强，而是责任链消失。

D1 是基线，不是可供想象填补的红线

AFPUB-2020-GEN-004-DRAFT01 于 2020 年 8 月 13 日发布。现有记录把 Draft 1 的基线概括为若干董事会干预类别：发起或改变政策文本、暂停一项政策、拒绝批准，或要求启动政策行动。这些类别说明了提案家族所触及的制度敏感点，也解释了为什么 Draft 2 的共识对象必须被认真审查。但是，本篇分析的对象不是逐项裁判 Draft 1 的全部条款优劣；Draft 1 在这里仅承担“前一已识别版本与干预架构基线”的作用。

Draft 2 是随后被识别的版本，其发布日期在现有记录中只能精确到 2020 年 9 月。版本顺序是可知的，完整的逐条变化却不可知。现有材料没有给出一份经认证、可逐行验证的 D1→D2 红线。正因如此，不能把两个版本并列出现误写成某项条款已被增加或删除，也不能把九月的共识状态误写成文本必然已经收窄、扩大、澄清或保持不变。

这里需要一种克制但并不含糊的表达。可以说：从 D1 到 D2 发生了版本转换；Draft 2 成为九月程序判断所针对的对象；记录把最终干预条款以及被视为已解决的异议置于该对象之中。不可以说：某一个具体句子如何变动，某项权力如何增减，或某位异议者因为某处文字改变而接受了版本。前一组陈述有记录支撑，后一组陈述需要尚未见到的红线、时间戳和异议处置链。

版本纪律之所以重要，不只是为了编辑准确。政策权力往往藏在动词、条件、例外、定义和程序时限里。“可以”与“必须”、“暂停”与“终止”、“请求重新考虑”与“自行改写”，在治理上不是语气差异，而是权力结构的差异。没有经认证的红线，任何人若替文本补写变化方向，都可能把自己的期待装扮成历史事实。支持提案的人可能想象保护性限制已经加入，反对提案的人也可能想象干预空间仍然无限；两者都越过了证据。

一套可信的版本保管机制应当至少保存 D1 与 D2 的不可变副本、各自的版本标识、发布时间、校验值、提案作者说明和可机器核验的差异文件。若在讨论期间又出现修订，还应明确每一轮讨论究竟指向哪份文本。这样，后来读到“异议已解决”时，读者能够定位解决发生在何处，而不是只能相信一项没有文本坐标的结论。

九月声明改变的是程序状态，不是法律本体

D1→D2 的版本转换与九月共识声明，分别回答两个不同问题。前者回答“当前对象是哪一版”；后者回答“程序处理者如何评价围绕这一版的异议状态”。两者相加，仍然没有自动回答“提出的每一种董事会行动是否在公司权限内”“是否能约束某个具体成员”“是否满足合同生效条件”，更没有回答“私人机构是否取得公共监管权”。

这可以用一条简单的证据链理解。文本存在，是文本事实；参与者讨论，是过程事实；共同主席宣布共识，是程序事实；董事会依法采取某项公司行动，需要公司权限事实；某项义务对一名成员发生私法效果，需要合同事实；对社会公众或整个地区施加命令，则需要完全不同的公法授权。每一环都必须有自己的依据。把前一环存在当成后一环当然成立，就是制度上的越级。

所以，九月节点最精确的读法是：一个已经被命名的 Draft 2 获得了一个程序状态。它可以成为下一项程序动作的输入，却不是所有后续动作的预先批准书。分析到这里必须停住。记录没有让我们在这个节点内断言后续阶段是否完成、董事会是否作出某种决定、RSA 是否吸收了文本、技术系统是否执行了它，或任何争议是否由此产生。那些问题需要各自独立的日期、文本、权限和证据，不能从“共识”两个字倒推。

精确对象也是公平程序的最低条件

对提案作者而言，精确对象能保护他们免于被旧版本中的表述永久绑定；对异议者而言，它能保证自己的意见不会被回答在一个版本里、却在另一个版本上被宣布“解决”；对共同主席而言，它提供可以公开说明判断理由的坐标；对董事会而言，它避免公司风险审查被迫面对一份持续漂移的文本；对运营者而言，它让合规与技术评估有稳定输入。

若版本保管模糊，最先受损的往往不是抽象的程序美感，而是责任归属。作者可以说异议针对旧稿，异议者可以说新稿从未充分展示，共同主席可以说整体方向已有支持，董事会可以说程序已经授权。每一方都可能在自己的叙述中有部分道理，却没有共同可审计的对象。制度争议于是从“某一条规则是否妥当”变成“我们当时究竟在谈什么”。

九月声明的可信度因此与 Draft 2 的文本保全紧密相连。共识不是漂浮在会议上方的情绪，也不是对提案名称的概括性赞许；它应当锚定在确切版本上。承认现有记录尚不能提供完整红线，不等于认定程序失当，更不等于指控任何人隐瞒。它只意味着在可获得证据范围内，结论必须停在“版本转换与新程序状态”这一层，不能跨到“具体条款如何变化”这一层。