材料不合格时，箭头返回提交节点很常见，但有些修改仍属于原任务，有些变化已经形成新请求。若不区分，历史结果、责任和统计都会混乱。本文以虚构的资料申请说明判断方法，不替任何组织制定统一规则。
先限定这次要解决的问题
检查申请对象、目的和责任边界是否仍与原任务一致。先写清任务对象、使用者和本次边界。没有确认的条件保持待确认，不为了让内容完整就补写规则、数据或人物背景。本图只讨论业务身份与记录，不说明具体系统编号或按钮。
把材料拆成可以核对的部分
区分仍有效的检查、需要重做的部分和已经失效的结论。每一部分说明来源或判断依据，并区分事实记录、团队解释与准备采取的动作。相同词语不一定代表相同含义，不能只按表面相似进行合并。
在虚构示例中走一次完整过程
示例中，只补一项缺失附件且申请目标未变，可以在原任务内补充并重新检查；如果申请对象和使用目的都改变，则需由规则负责人判断是否重新发起，并保留原任务结束原因。这个案例只用于演示方法，不代表真实客户、业务数据或产品自动完成了相应判断。遇到实际规则时，应回到当前有效材料和负责人的确认。
检查容易被忽略的异常与反例
关注修改范围不明、原任务已关闭、旧结论被覆盖和新旧负责人不同。如果出现与预期相反的记录，应保留并解释它影响了哪一项判断。未知状态不能直接归入失败、同意或完成，也不能用一条看似顺畅的箭头把问题藏起来。
让未参与整理的人试用
分别用补充附件和更换申请目的验证流程是否得到不同结果。请另一位读者仅根据成稿完成一次查找、判断或交接，记录需要追问的位置。修正时回到原始依据，不用更肯定的措辞掩盖缺口，也不把示意图冒充真实产品截图。
最后的交付建议
建议先定义哪些字段改变会影响任务身份，再决定画回线还是新入口。不要为了减少节点把所有变更都塞回原流程，也不要把小修正全部复制成新任务。图形和画布负责把关系呈现清楚，不能替团队制定尚未存在的业务规则。若对象、版本或场景发生变化，应重新核对这套方法是否仍然适用，并保留尚未解决的问题。