确认操作不等于问题解决
别名: 报警确认 · alarm acknowledgement
概念解释
报警确认（acknowledgement）这个动作只说明有人已经接收到这条消息、并且承担起评估它的责任，它不代表触发条件已经消失、处置已经完成，或者风险已经解除。这条讨论的是确认之后状态该怎么呈现和演化，报警消息本身该包含哪些字段、声光该怎么配合优先级，分别是同组另外两叶的内容。如果界面把确认之后的报警直接移出操作员平时看的活动视野，就等于把一个纯粹的工作流程状态误当成了过程本身已经恢复正常的状态来呈现，这是一种呈现层面的错误映射。
机制
确认关闭的是一个通信回路——它证明消息已经从系统传达给了人；而处置完成、风险解除关闭的是现场或控制回路，需要过程本身给出恢复的证据，这两类回路依赖完全不同种类的证据，不能用同一个动作、同一个时间戳去代表两者。真正需要被记录下来的是：谁在什么时候接手了这条报警、接手之后实际采取了什么动作、触发条件本身是否已经恢复、以及基于什么依据判定这条报警可以关闭，这四类信息缺一不可。
边界
对于纯信息型事件，确认本身可能就是唯一需要的动作，因为除了知悉之外压根没有别的处置要做；对于会自动恢复的瞬态状况，处置这一步也可能根本不需要人工介入去关闭它。但这些类别必须在报警合理化阶段就预先定义清楚，绝不能让操作员在响应现场逐条临时判断"这条算不算需要处理"——那样会造成同一类报警在不同人手里得到不同对待。关闭规则本身也必须留痕，方便事后审计。
怎么落地
活动报警列表的默认排序逻辑不能因为一条报警已经被确认，就把它从视觉上压到不显眼的位置，导致真正尚未解决的高风险项反而被埋没在列表深处。界面上要清楚区分"新报警""已确认但尚未解决""处理中""触发条件已恢复"和"已验证关闭"这五种状态，并且每个状态变化都保留责任人和时间戳。验证时专门设计"确认后异常持续不消失""短暂恢复又再次复发"这两类回放场景，核对列表视图、过程画面和历史日志三处对同一条报警呈现的状态是否始终一致，不能出现互相矛盾的说法。