大多数软件会记住改变了什么。能记住为什么允许某次改变、由谁或由什么做出决定、决定基于哪些证据的软件则要少得多。正是在这道缝隙里，信任在悄然瓦解。一个运营团队通常能回答“现在的状态是什么”；却往往无法回答“给我看看我们是怎么走到这一步的，并证明我们当时被允许这样做”。
Threada 的构建方式确保第二个问题始终可以回答。每个受治理的操作都会留下一份凭据。
凭据实际包含什么
凭据不是一行日志。一行日志说的是“发生了某件事”。而凭据所说的，足以让人日后重建并为某项决定辩护。在 Threada 中，一个受治理的操作会记录：
- 操作者。 人类操作员或 AI 参与者，记录为彼此区分的操作者事件。代理的审批绝不会冒充某个人。
- 输入。 WorkItem、其抽取出的实体、请求者身份，以及请求到达时所经由的来源渠道。
- 证据。 引用、检索轨迹，以及——当上下文不足时——明确的回退原因。没有引用或没有记录在案的回退原因，就无法创建 Work。
- 策略。 当时哪一套策略处于生效状态、版本是什么，以及它是在整个租户范围内生效，还是收窄到某个 pack、工作流、渠道或请求者群组。
- 结果。 该操作是被提议、被批准、被拒绝、已执行、成功还是失败——并附带回链到它所触及的外部记录。
把这些字段放在一起读，你就得到了对单个步骤站得住脚的说明。在一个 WorkItem 的整个生命周期中通读它们，你就得到了它的完整历史。
把可审计性作为默认，而非事后加装的功能
大多数系统的诱惑是把审计留到后面再做：先交付功能，等到客户索要 SOC 2 证据，或监管者上门时，再用日志把它包起来。这个顺序是颠倒的。事后加装的审计总是不完整的，因为系统从未被要求在决定做出的那一刻就承载相应的上下文。
Threada 颠倒了这个顺序。运行时会在每个有意义的状态转换处发出结构化事件——work_item_created、approval_requested、approval_decided、action_proposed、action_executed、fallback_triggered——因为完成工作的那个动作，与记录工作的动作是同一个。这里没有单独的“开启审计”步骤，因为根本不存在工作脱离记录而发生的时刻。
这就是我们说该模型是记录与凭据时所指的含义。记录不是你去生成的一份报告；它是正确完成工作之后留下的残留物。
为什么凭据会改变团队的运作方式
凭据对季度末的审计员是有用的。但它更安静的价值，属于某个寻常周二里身处其中的操作员。
当每个操作都携带其证据和策略依据时，三件事会变得更轻松：
- 审查变得既快又诚实。 审批者不必凭记忆重建上下文，也不必追着请求者去问最初的诉求。证据就在操作旁边。信心、可逆性和清晰度在决策点都一目了然，因此审查者会以可审查性为优化目标，而不只是一味追求速度。
- 回退变得安全。 因为凭据点明了策略版本和输入，回滚一个操作就是一项有明确定义的操作，而不是一场考古工程。你清楚自己在撤销什么，以及当初为什么这样做。
- 问责不再具有对抗性。 当记录自行组装，“这是谁批准的”就不是一句指控——它只是一个字段。构建者、审批者与治理角色之间的职责分离得到强制执行且清晰可见，因此问责的问题在任何人开口之前就已经有了答案。
高风险工作仍由人来把控，并留有记录
凭据并不意味着一切都被自动化。它们意味着一切都可被问责。高风险的自动化遵循明确的人在回路推进——先提议、再批准、再执行——并且只在策略明确允许的地方才自动执行。凭据会记录某个操作走的是其中哪一条路径。自动化与审批并不冲突；它们都不过是会留下痕迹的步骤而已。
其结果是一个你可以同样放心地交给审计员和新操作员的系统。审计员看到的是各项控制都守住了。操作员看到的是上一个人如何处理了眼前的这个案例。两者读的是同一批凭据。
这就是 Threada 背后的赌注：记录一项决定为何被允许，成本最低的时刻就是你做出它的那一刻；而一个从不脱离记录工作的团队，就是一个永远能回答第二个问题的团队。