社区规则更新后，怎样让旧处理仍可解释而不被追溯改写？

可以用一个反事实标准划线：在事实完全相同的情况下，新措辞是否可能改变‘是否违规、需要什么证据、采取何种措施、能否申诉’中的任一结果。若不会，只是补充示例、统一术语或修正不影响含义的错字，可作为解释文本更新，但仍应留修订记录；若会，就必须发布新版本并标明生效时间。适用范围、判断阈值、证据要求、处置等级、例外条件和申诉路径的变化，都应直接视为版本变化。

对旧内容的例外复查，建议只针对‘当前仍在持续的状态’，而不是重新判定全部历史。触发条件可限定为：内容仍公开传播并造成可说明的现实风险；出现明确的法律、隐私或安全义务；原处置至今仍限制当事人权益，且规则变化可能使当前限制不再相称。复查结果应写成‘历史判断保持不变，当前状态自某时起调整’，并记录触发依据、审查范围、决定者和申诉入口。

避免无限追溯的关键不是只设一个年份截止线，而是同时设置四个边界：仅处理仍持续的影响；一次复查只回答预先列明的问题；影响终止后不再进入队列；同一事实无新证据或新规则时不重复启动。这样既能处置现实影响，也不会把版本更新变成对历史记录的反复重写。

落地时还可以把“规则版本”和“处理时间”扩成一组双时间记录：一项表示决定在何时生效，另一项表示系统在何时记录它。补录旧决定、延迟执行或事后更正时，这两个时间不能互相覆盖，否则审计者仍可能把后来录入的信息误当成当时已知。

处理事件本身宜只追加、不改写，至少固定关联内容修订号、规则版本、证据快照、决定与生效时间。发现原记录有误时，新建一条更正事件并指向被替代记录；面向普通读者的“当前状态”则由这些事件计算得到。这样既能简洁展示现状，又保留“当时为何如此”的完整链条。规则文本的摘要值可以帮助发现历史版本被静默修改，但不能替代可读取的原文归档。

可以再加一个回放验收：选取几个跨越规则修订、申诉和状态调整的案例，仅用保存的事件重建任一历史时点，结果应与当时展示一致；随后加入一次更正，过去的历史视图不应被重算，只有更正生效后的视图发生变化。这个测试能较早发现版本引用正确、时间语义却混乱的问题。

还可以增加一套匿名化的‘边界案例回归测试’，用来防止解释文本在不知不觉中改变实际规则。测试集不必很大，但应包含典型案例、刚好落在阈值两侧的成对案例，以及曾在申诉中暴露歧义的案例；每个案例固定记录事实摘要、适用规则版本、所需证据和预期处置。每次修改解释、示例或术语后重放这些案例，只要任一案例的违规判断、证据门槛或处置级别发生变化，就应把这次修改升级为新版本，而不能仍称作纯解释更新。

版本引用也最好保存一份‘适用规则包’，而不只是单条规则编号。一次处理往往同时依赖全局规则、版面细则、执行指引和当时可用的产品措施；其中任一依赖后来变化，仅靠主规则链接仍无法还原判断。规则包可以记录各依赖项的版本及优先级，避免出现两条规则分别可追溯、组合关系却丢失的情况。

这套测试集只能作为变更探测器，不能反过来取代规则正文。发现预期结果与新文本冲突时，应由复核者明确决定是修正文案、发布新版本，还是承认旧案例本身有误并追加更正记录；否则历史案例容易被悄悄改成迎合当前规则。

还需处理一个容易与可审计性冲突的边界：保留历史依据不等于永久保留全部原始内容。旧处理记录可能包含后来应删除或限制访问的个人信息；若为了可回放而完整复制到多个规则包和证据快照，反而会扩大暴露面。

可以把审计材料拆成三层：公开层只显示规则版本、决定类型、生效时间和变更原因；受限层保存经过最小化处理的事实摘要，供申诉与复核使用；原始证据单独加访问控制和保留期限，到期后删除正文，只留下不可反推出内容的完整性校验值、删除时间与删除依据。历史视图此后应明确标记‘原始证据已按期限清除’，不能用残缺材料重新推断当年的事实。

相应地，回放验收应增加两种情况：证据仍在时能否复核决定链条；证据依法或按政策清除后，系统能否继续证明某次决定曾依据哪个规则版本发生，同时又无法从审计记录恢复被删除内容。若做不到后一项，‘不可改写’就可能被误实现成‘不可删除’。

还需要为规则切换时仍在队列中的事项写一张明确的过渡表。否则同一批事实可能仅因处理速度不同，分别落到新旧版本。可以把时间点拆开判断：实体判断原则上依据行为发生时有效的规则；证据提交、通知和申诉期限等程序保障采用当前流程，但不得因此降低当事人原本已有的保障；持续中的展示或限制措施则作为当前状态单独评估，只向未来调整。

对规则生效前已受理、尚未决定的事项，系统应在受理时固定候选版本，规则发布后由过渡表自动给出适用结果，不能让处理者逐案自由选择。若新版本放宽条件，可预先规定是否适用于未决事项；若收紧条件，则不应把新增责任倒推到生效前的事实。已经进入申诉的事项仍复核原决定所用版本，同时允许另开一项“当前措施是否继续相称”的审查，避免两种问题混成一次重判。

上线验收可以加入一组跨越生效时刻的成对案例：事实完全相同，只改变行为、受理、决定和申诉时间，检查版本选择是否符合过渡表。规则变更记录还应公开过渡口径、受影响的未决数量及例外原因，这样才能判断差异来自明确规则，而不是队列先后。

还应把“规范版本”和“执行实现版本”分开记录。同一份规则文本没有变化，匹配逻辑、评分阈值、证据聚合顺序、缺失值处理或操作界面的默认选项发生变化，都可能让相同事实得到不同结果；旧处理若只引用规则版本，仍解释不了为何当时作出那个决定。

每条处理记录可以固定关联执行器版本、配置版本、实际读取的输入字段及关键中间结果。涉及应按期限清除的材料时，不必永久保存原始输入，但应保留足以说明决策路径的最小化摘要、完整性标记和清除记录。人工决定也应记录当时界面提供了哪些候选动作，避免后来把产品上尚不存在的选择假定为当时可用。

发布新实现前，可用去标识的固定案例做一次新旧版本并行回放。若规则文本未变而结果出现差异，应先判断是实现缺陷，还是执行口径事实上已经改变：前者追加更正并评估受影响范围，后者则必须发布新的执行指引版本和生效时间。验收时除了检查历史页面能否重建，还应验证使用保存的实现与配置能否复现当时结果；这样才能发现“文档未改、执行已漂移”的隐性追溯改写。