模型准入需要未决状态

AI模型准入决策必须说明允许工件推进的证据是什么。当一次加载未产生任何被阻止的事件，但静态检查仍识别出危险全局对象时，批准操作会将两个不同的发现压缩成一个令人安心的单一答案。我希望未决的发现能够贯穿整个决策过程并保留下来，同时清楚说明仍需确立的事项。

我们围绕这一区别构建了Crucible，即我们的本地Model Vetting Firewall演示。它使用合成工件，其中包括一个签名扫描器未标记但加载时尝试执行数据库操作的文件，以及另一个包含未执行条件分支的文件。第一个案例证明了为什么观察到的尝试至关重要。第二个案例揭示了更困难的设计问题：当现有的检查结果不一致时，如何在不假装分歧已解决的情况下决定下一步该怎么做。

证据改变决策

在合成数据库示例中，PickleScan并未标记该工件。在加载期间，配置的CPython审计钩子记录并阻止了一次尝试执行的SQLite数据库操作。本地流水线返回QUARANTINE且未签发签名。数据库操作并未成功；有价值的证据在于尝试的效果及其被记录的阻止。

这为准入决策提供了一个干净扫描器结果无法给出的理由。团队可以指出被禁止的操作，而不是要求扫描器的标签来回答关于加载的每一个问题。扫描器作为对照仍然有用，但没有标记并不意味着可以抵消已观察到的被阻止尝试。

我更倾向于这种分离，因为这使决策具有可审查性。审查人员应当能够追溯发现与结果之间的关系。“配置的钩子阻止了该数据库操作尝试”是一个边界明确的陈述。它指明了证据、机制以及本地裁定的原因。宽泛的安全标签则会将这些关系隐藏起来。

观察也创造了其自身的信任边界。在此处，工作进程在Python子进程中尝试加载并监测配置的审计事件。这是带有进程隔离的演示仪器，而不是操作系统级或容器级的包容隔离。生产设计需要在向观察工作进程托付不受信任的工件之前，确定该工作进程本身是如何隔离的。增加行为证据并不能免除审查收集证据之环境的责任。

静默加载留下更棘手的问题

条件分支合成固件得出了不同的结果。静态检查发现了builtins.eval，这是该演示所配置的危险列表中的一个全局对象。由于在此环境中未执行条件分支，因此观察到的加载未记录到被阻止的危险事件。流水线将该工件路由至REVIEW，未签发任何签名。该路径尚未完成任何人工作业调查。

有三种合理的应对策略值得考虑，每种策略付出的代价各不相同。批准意味着接受不确定性。拒绝避免使用该工件，但可能会放弃更深入调查本可解释的内容。进一步审查则会推迟决策，并要求明确哪些额外证据能够改变决策。

针对这种情况，我更倾向于审查，因为不确定性是具体的。存在明确识别出的静态隐患和明确识别出的观察盲区。静默运行并未解释为什么存在危险全局对象，也未解释如果触发该分支会发生什么。批准将意味着必须接受这一盲区。立即拒绝可能是一种合理的组织策略，但这将是基于未解决的静态证据排除工件的选择，而不是证明禁止的后果已经发生的证据。

当团队制定准入策略时，这种区别至关重要。未观察到某种后果不应默默演变成该后果不可能发生的结论。同样，怀疑也不应默默演变成攻击成功的证据。REVIEW提供了一个可以同时保留这两项事实的机制，同时让组织选择其能够接受多少不确定性。

REVIEW需要退出标准

单凭审查状态可能会变成代价高昂的滞留区。只有当记录说明了未解决的问题以及下一步必须做出的决策时，它才有存在的意义。在此示例中，问题涉及静态全局对象和未执行的分支。在不改变调查内容的情况下重复相同的静默加载，只会增加另一次观察，而无法回答该问题。

在假设的企业流程中，团队可能会检查该分支、向工件供应商寻求可靠的解释，或者选择加载路径更易审查的替代工件。这些都是提议的应对措施，而不是本演示所完成的工作流。每种方案都有其代价：更深入的检查需要专业知识，供应商证据需要自身的验证，而替换则可能牺牲所需的功能。选择取决于团队能够获得哪些证据，以及其策略允许何种不确定性。

我希望这种选择是明确的。如果团队在现有约束下没有可行的调查能够解决疑虑，那么拒绝该工件可能是审查的合理终点。REVIEW不应承诺每个文件最终都能获得批准。其目的是防止未解决的问题在裁定中消失，并使最终决策对既定策略负责。

同样的准则也适用于AI解释。在演示中，分析师与挑战者的联合建议可以增加审慎考量并将基准ALLOW结果转为REVIEW；但它无法解除QUARANTINE。记录的演示结合使用了缓存的Codex建议与新配置的检查。一个合成参考记录说明了将叙述视为权威的危险性：其建议建议签署并推进，而最终结构化结果是REVIEW且未签发签名。

因此，准入使用者应当阅读结构化裁定、门禁理由和实际签名字段。有益的描述可以解释决策，但描述绝不能成为向前推进工件的第二项冲突许可。倘若审查流程信任建议语句胜过最终门禁，就失去了其本应保留的界限。

批准同样具有边界

合成干净权重字典获得ALLOW以及使用本地开发密钥对其模型名称、工件哈希和清单负载进行的签名。其训练数据来源和微调历史记录仍为UNKNOWN。只有ALLOW能获得该签名；REVIEW和QUARANTINE则不能。

这对于退出审查与干净路径同样重要。解决加载疑虑本身并不能确立训练历史。当上游问题仍未得到解答时，签名可以在本地针对其密钥验证指定的负载。团队应分别评估准入证据是否足以支持加载决策，以及缺失的来源对于预期用途是否可以接受。一项获批的检查不应平息其从未调查过的问题。

这份Crucible解说指南展示了这些本地示例及其证据。注册表集成、企业准入执行和生产签名保管仍然是本演示之外的工作。它的价值在于使决策边界清晰可见，而不是声称本地实现提供了企业所需的所有控制措施。

以下是展示本地合成模型审查演示的创始人视频。

对于正在评估准入设计的平台团队，我建议从证据无法清晰吻合的案例入手。追问是什么让未决的发现保持可见，谁来决定更深入的调查是否值得其代价，以及什么证据可以改变结果。一条干净的路径很容易描述。未决的路径才能揭示系统是否能将不确定性保留足够长的时间，从而做出负责任的决策。