摘要

  • 现有来源把 CPE 列为模块五中的一项按标准开展的字符串争用解决评估。
  • 申请人可以准备并记录自己的证据；现有来源不能证明评估小组最终会作出何种判断。

下文有关证据台账、来源链和版本控制的做法属于 BTW 为提高可审计性提出的编辑建议，并非 ICANN 明文要求。

“不是人气竞赛”是 BTW 的编辑性概括，并非现有 ICANN 来源的原文。现有来源把 CPE 列入模块五，并提供评估指南相关资源；它们没有说明评估小组进行非正式投票，也不能证明哪一项申请会采用某条具体程序路径。在这一证据边界内，申请人不应把公开支持的数量本身视为已经满足公开标准的证明。

因此，材料准备的核心问题不应是“我们能收集多少封支持信”，而应是“哪些可以核验的资料，能够把所主张的社群、申请字符串以及申请承诺，与公开标准逐项连接起来”。

先确认 CPE 在程序中的位置

ICANN《2026 轮次申请人指南》把 CPE 列入模块五的字符串争用解决程序。现有来源能够证明这一程序位置，但不能单独证明任何申请结果、签约资格或委派状态。

本文使用的证据不能证明由谁选择某一具体程序路径，也不能证明 CPE 之后必然产生何种后果；这些问题需要另外适用的 ICANN 来源和具体申请记录。

用标准组织证据，而不是堆积附件

ICANN 于 2026 年 6 月 24 日宣布发布本轮次更新后的最终 CPE 评估指南。此前的公众意见征集已于 5 月 4 日结束。随指南一同公布的还有由 CPE 服务供应商制定的评估小组流程与程序。这些文件构成申请人设计证据档案的适当框架。

实用的做法，是建立一份逐项索引：每一项重要主张都要对应具体来源、责任人和日期。对社群范围、社群成员以及社群与申请字符串之间关系的定义，应在申请表、附件和公开说明中保持一致。支持函应能说明签署人的权限以及其了解相关事实的依据。组织文件也只能用于证明其实际记载的事项，不能仅凭文件名称被当作当然成立的证据。

按照 BTW 的内部审阅方法，档案还应区分三个层次：申请人作出的主张、独立来源提供的佐证，以及评估小组最终作出的判断。前两层可以在提交前准备和核查；本文所用来源不能预先证明第三层的结论。

本文能够确认的是，CPE 属于模块五字符串争用解决中的正式评估。现有记录不证明分数、申请结果、签约资格或委派状态。