L4.15.4confirm is not fair duty transfer设计研究
把最终确认交给人不等于责任已合理转移，人须具备拒绝的条件
别名: 确认不等于合理转责 · conditions to refuse · 空确认不转责
概念解释
界面上有人点了确认，条款就可以写「由用户最终确认」。合理转责要问的不是点没有，是这个人当时能不能拒绝：有没有对象和后果、有没有时间、否决会不会被当成故障、否决是不是真的拦住。确认不等于合理转责（confirm is not fair duty transfer）：缺拒绝的条件，签字是展览，责却写在签字的人头上。
名义回路把能力留在机器上、把名写在人身上。这里是那件事在归责条款上的对应。
机制
转责被当成一次合同：人有机会做差因，才谈得上担。机会需要材料、时间和不受罚的否决，并且否决接到执行。四件缺一，确认就只满足审计对「有人签」的检查。疲劳、倒计时默认放行、否决被考核惩罚，都会把拒绝条件拆掉，同时把条款留着。人于是用盲目点是来自保——点了至少符合流程，不点会被问为什么挡。
交权时要人显式接受，钟才启动；这里更早也更日常：每一次确认作为转责事件，都必须满足拒绝条件，否则钟不该为人而走。
怎么研究
做一次有害放行，比较：材料齐且否决有效、倒计时默认放行、否决被事后责问、只有空按钮。事后问操作者、主管、条款撰写者责任百分比。自变量：拒绝四件是否齐、条款是否写「用户已确认」。因变量：归因、人是否报告「我没办法说不」、有害项实际被拦下的比率。
条款写着用户担、实际拦不下，是转责不成立的操作定义。
边界
建议级系统不声称转责，确认若只是「我看见了」可以不走这套。人一直握着控制、本来就是执行者，转责问题不出现。档都看不清时，更谈不上对这一档拒绝。字段齐、寿命够，解决的是事后能不能查；查出来若是空确认，仍是不合理转移。
怎么落地
- 任何被条款当成转责事件的确认，必须同时满足：实例可见、时间够读、否决是一等动作且接到执行、否决不被考核惩罚。缺一件，条款不得写「由用户确认」。
- 超时默认只能是否决或保持未执行，不能是放行。
- 验证：让审核员否决一次有害项，看世界有没有变、事后有没有被责问。变了或被责问，拒绝条件就不成立，转责条款要拿掉或改权限。抽一批短于可读时间的确认——那一批不能当转责事件记账。