建立贯通的纠错路径

沿着一个错误追踪到底

列出一个重要错误必须经过的处理阶段：发现、独立质疑、专业诊断能力、叫停或撤销的权限、补救，以及制度性学习。这是一个设计框架，并不是说所有机构都遵循同样的顺序，也不是说有了检查清单就能保证成功。有些步骤会同时发生；有些需要外部机构参与。重点是让各环节之间的连接清晰可见。

即使有一整套控制措施，纠错路径也可能在其中断裂。监测工具可能发现了漂移，却没有通知负责该项决策的团队。调查人员可能查明了原因，却无权暂停系统。针对个人的补救，可能没有触及共同原因。应测试证据能否在不同阶段之间传递，并改变下一步行动。

明确交接安排

对于每一处连接，都应记录输入信息、接收方、时限、需要作出的决定，以及保留的证据。“已上报管理层”过于笼统，无法测试。具体是哪一个管理岗位？需要哪些信息？如果此人不在场怎么办？何时，回应延迟本身就会触发另一种行动？一个可用的计划应经得起棘手个案的考验，而不只适用于各方都配合的情况。

既要考虑后续风险，也要回溯既有影响。暂停有故障的流程可以防止新的风险暴露，却无法找出所有已经受到影响的人。更正数据库，并不意味着依赖它的决定都会被重新审视。补救可能需要沟通、重新评估、恢复业务运行或赔偿。适当的形式取决于实际义务和损害，而不是哪一种技术修复最方便。

从中学习，但不改写历史记录

应保留当时已知的信息、原始决定，以及修改决定的原因。否则，机构可能看起来从一开始就是正确的，理解失误所需的证据也就丢失了。应保存版本，并区分更正后的输出与曾经影响行动的历史输出。

修复之后，要测试根本原因是否已改变，以及纠错是否产生了其他问题。应复测受到影响的依赖环节，而不只是检查最终显示的界面。应记录证据的局限。一次成功的纠错，只能支持对该项修复作出有限结论，不能成为整个系统安全的证明。

建立附有证据的交接记录

针对虚构的资格判定错误，分配一个个案标识，并记录源数据版本、受影响的规则、发现时间、已知影响范围，以及不确定之处。第一位接收者应当能够判断所请求的行动，而无须重新拼凑整个事件。应在保存任何更正后状态的同时，保留原始输入和决定；绝不能修改历史记录，让原决定看起来像是正确的。

设置六个检查点：发现问题的证据、质疑已被受理并进入调查、诊断获得证据支持、暂停或撤销已获授权、受影响的决定已得到补救，以及修复已接受复测。每个检查点都应描述一个可观察的结果。一条写着“已发送给团队”的消息，只能证明发送，不能证明调查。数据库经过修改，只能证明数据发生了变化，不能证明所有受影响者都已获得补救。

在中断之后增加核对步骤。如果某条指令可能已经执行，应先检查实际结果，再决定是否重复执行。否则，一次恢复尝试可能造成重复付款、重复通知或重复记录。在书面推演中，要求学员维护待处理、已确认和不确定等状态，并列出允许每次状态转换的证据。不要仅仅因为工作流程包含一个标识，就声称它能保证“恰好执行一次”。

研讨：停在半途的纠错

向每个小组提供一份停在不同阶段的事件日志：已更正输入、已授权撤销，或已完成下游更新。要求他们指出哪些事项尚未解决，以及需要什么证据才能了结。由另一个小组加入接收者缺席或更新版本发生冲突的情况。学员必须保留那些更新的工作，而不能为了完成自己的检查清单就将其覆盖。

提交一页交接日志，以及一份结案说明。英文原版的篇幅要求为250词；如用中文作答，可选择约500字的适配篇幅，这不是逐词对应的等值换算。结案说明必须指出已经核实的修复、其适用范围，以及任何剩余的不确定性。在复盘中，对比纠正眼前结果与改变产生该结果的流程之间的区别。