L1.09.5the loop transfers liability and must say so设计研究
把人放进回路同时把责任放到了人身上，这一转移需被明示而非默认
别名: 责任转移 · 回路与归责 · explicit liability transfer
概念解释
组织把人嵌进回路，常常是为了在事故之后有一个签名。嵌进去的那一刻，责任从系统侧转移到签字的人——在制度里是这样运行的，在界面上却很少被说出来。责任转移必须明示（the loop transfers liability and must say so）：人有权知道自己正在接过哪一段后果，也有权在条件不足时拒绝接。
默示转移是把归责当作用户没读过的条款。
机制
「批准」在日常界面里像「继续」。继续不转移责任，批准在事故审查里会。两种言语行为共用一个按钮，人按的是继续，被写成的是批准。事后他们报告「我以为只是让它往下走」，审查报告写「经人工确认」。错位不是他们推诿，是控件把两种行为叠在一起。
形式回路那张处理因果是否接上。这里即使因果接上了，归责语义仍可能是偷运的。没有明示，人无法用「条件不够我拒签」来保护自己，于是在材料不足时仍点下去——因为那看起来像进度，不像法律行为。
怎么研究
事故剧本：有害动作经闸放出。问放行人「谁该负责」，再看界面上批准的标签、确认文案、是否记录了拒绝权。自变量：按钮写「继续」vs.「我确认并承担责任」、拒绝是否与批准同样可用。因变量：责任归因、拒绝使用率、材料不足时是否仍放行。
自我报告的「我知道我在负责」要和标签理解分开测。很多人会在事后同意负责，当时却按「继续」在理解。
边界
建议型系统不声称转移，若仍在事故后拿「人看过一眼」来归责，是组织在回路外抓替罪，不是这张卡能修的界面问题，但界面至少不该提供那种「看过一眼」的伪节点。受雇审核员的劳动合同可能已经写明责任，界面仍要把这一次的对象说清，否则合同是概括的、动作是具体的。这条不处理闸该钉在哪。
怎么落地
- 不可逆闸的主按钮用「确认并发送 / 我同意承担这次操作的责任」，不用「继续」「下一步」。拒绝与确认并列，不是藏在角落的取消。
- 放行记录写清：谁、在何种材料下、对哪个对象。材料不足时人应能勾「材料不够，拒签」。
- 对内说明与对外说明一致：对外说人在回路，对内就要把责任范围写进人接班时能看见的地方。
- 验证：走一次闸，问「如果你点下去，出事了算谁的」。答「不知道」或「算系统的」，而你们的事故流程会找这个人，转移是默示的。再看拒签是否和确认一样好按。