我们自身设计中的一项风险

众包安全机制可能走偏的地方。

如果我们不够谨慎，一个众包安全系统可能会演变成别的东西。用于发现真实失败的同一套机器，可能变成强制推行偏好的工具。我们在正在构建的架构中看到了这种风险，点名它是抵御它的第一步。

我们担忧的失败模式

如果人们对具体案例进行众包裁决（「这个特定回复是否违反了规则？」），偏见就会渗入每一次解释。同样的行为，因今天谁在投票而得出不同结论。即使出于好意，这个循环也会滑向强制推行多数人偏好，而不是发现真正的伤害。

这就是失败模式。我们所承诺的约束，正是为了让这种偏移显而易见、代价高昂。

人们提出并投票表决规则：公开、有日期、有签名、可撤销。再由确定性检查将这些规则应用于具体案例。相同回复加上相同规则，每次得出相同裁决。争论移到上游——规则本身是否应该存在——而不是下游的具体案例今天算不算数。

规则在付诸投票前必须通过操作语言关。规则必须可以不经判断地进行核查，否则还没有准备好。每条规则都有日期、签名和版本锁定，对任何具体回复的裁决都是确定性产生的。

如果某项裁决事后被证明有误，申诉将经由全新审核小组进行复议（原裁决者回避），而不是交回产生该裁决的同一群体。这种结构性分离是承重的关键。

这一切都不是自动的。只有当规则语言保持操作性——关乎机器可以核查的事物，而非感受——这种约束才能成立。一旦某条规则从「用词不当」滑向「感觉不尊重」，人的解读就从后门重新进入，偏移就此开始。架构中列出了我们能想到的每一种抵御机制；真正守住这条线是运营层面的工作，不是架构层面的。

众包基础要素、申诉路径和机器可执行规则格式都在 CIRISNodeCore 规范中。29种语言的心理健康测试集是这个循环首先运行的场景。