昨天談 Fail Closed。
當關鍵 Context、State 或 Authority 不清楚時，
AI 不應該自己猜。
應該先停。
乍聽之下很簡單。
結果真的開始做 Governance 之後，我又碰到一個更麻煩的問題：
如果我真的說「停」，到底要停什麼？

想像一下。
現在同時有：
Workflow A 正在跑到 Step 3。
Workflow B 剛剛開始。
Tool Call C 還在 Pending。
另一個 Background Process 正在處理資料。
然後我跟 Sol 說：
「先停。」

人類聽到這句話，很容易靠前後文理解：
「Ronnie 應該是在講剛剛那個。」
可是 System 不能永遠靠：
「應該是吧。」

因為真正的 Runtime State，
不一定跟我眼前看到的畫面完全一致。
UI 可能還停在上一個 Step。
Conversation Context 可能還在談 Workflow A。
但實際 Runtime 已經切到 Workflow B。
甚至 Tool Call C 可能已經進入執行階段。
這時候一句：
「停。」
如果綁錯 Target，
可能發生一件很荒謬、也很危險的事情：
AI 很認真地停錯東西。

這也是我們後來開始重視：
Current-State Reconciliation
意思是：
在執行像：
Stop。
Continue。
Retry。
Resume。
這類和「現在狀態」高度相關的指令之前，
System 不能只看 Human 剛剛說了什麼。
還要重新確認：
目前 Active Workflow 是什麼？
Runtime State 是什麼？
現在 Pending 的 Action 是哪一個？
Conversation Context 跟 Runtime Reality 還一致嗎？

這裡我要先講清楚一件事。
我今天說的：
Current-State Reconciliation
主要是在講：
Governance / Runtime State 層。
不是在宣稱：
Sol 已經能完整感知所有 Physical Reality。
Day 19 我們才會正式談 Reality Architecture。
今天先處理的是：
System 自己知不知道現在到底跑到哪裡。

所以當 Human 說：
「停。」
理想上不是直接：
Human Command
↓
Stop Something
而是比較接近：
Human Intent
↓
Conversation Context
↓
Runtime State
↓
Active Workflow
↓
Current-State Reconciliation
↓
Stop Target

這裡真正關鍵的一步就是：
Stop Binding
也就是：
這個「停」到底要綁到哪一個：
Workflow？
Action？
State？
Tool Call？

如果綁定不清楚，
我寧願它不要執行，
也不要讓它自己猜。

這跟昨天的 Fail Closed 完全接得起來。

例如：
我原本正在看 Workflow A。
後來 Workflow A 已經結束。
系統自動進到 Workflow B。
但我的畫面還停在 A 的結果。
這時候我說：
「停。」
如果 Sol 只依照畫面 Context，
可能認為：
「Ronnie 要停止 A。」
但 A 根本已經不存在。
那她接下來要不要：
自動改停 B？
不可以。
因為：
B 沒有被 Human 明確綁定。

這裡就出現另一個我們很在意的概念：
Causal Binding
Human 這一句指令，
到底是因為哪一個前置事件、哪一個 Workflow、哪一個 Action 才產生？
如果這條因果關係已經斷掉，
原本那一句話就不能被靜默套到另一個東西上。

這其實跟人類對話很像。
我跟一個人說：
「那個先停。」
對方會自然理解：
「剛剛我們正在談的那一件。」
但如果中間已經切換三個任務，
他通常會再問：
「你是說哪一個？」
這不是笨。
這反而是正確。

所以我現在越來越覺得：
Clarification 有時候就是 Safety Feature。
不是所有事情都要追求：
AI 秒懂。
尤其進到 Action Layer，
問清楚，
比猜得快更重要。

這也讓我發現：
Stop 本身也是一個 Action。
以前我會覺得：
Stop 很安全啊。
不就是什麼都不要做？
後來才發現不是。
停止某個 Workflow，
本身會改變 System State。
取消某個 Tool Call，
可能影響後續流程。
中斷某個 Action，
也可能留下部分完成的狀態。
所以：
Stop 不能被當成「沒有動作」。
它也是：
State-changing Action。

這個觀念到 Physical World 會更明顯。
例如未來有：
HVAC Workflow。
Lighting Workflow。
Access Workflow。
Energy Optimization Workflow。
我說：
「先停。」
那到底是：
停 AI Decision？
停這次 Command？
停 Automation？
停整個控制 Loop？
還是只是：
停止下一步？
這些完全不一樣。
所以 Physical World 的例子，目前只能當：
Future Physical Application
不是說我們現在已經全面把這些控制進 Production。

但治理原則已經很清楚：
一個 Stop 必須有 Target。
而且：
Target 必須跟 Current State 對得起來。

我覺得這件事情非常有意思。
因為我們平常都覺得：
「開始做事情」很危險，
「停下來」比較安全。
但真正做 System 之後，我開始發現：
錯誤地停止，也可能是錯誤 Action。

例如：
停止錯 Workflow。
停止錯 Tool。
停止已經進入 Critical Section 的流程。
甚至因為 Stop Target 判錯，
反而讓真正該停的東西繼續執行。
所以 Stop Governance 不是：
「聽到停止就全部 Kill。」
而是：
正確辨識 Human Intent，並綁定到正確的 Current State。

目前 Stop Binding / Current-State Reconciliation 已經進入我們的 Sandbox-scope Governance Work。
這部分有實際工程脈絡。
但我仍然不會寫成：
「所有 Sol Workflow、所有 Tool、所有 Physical Action 都已經完成完整 Stop Enforcement。」
還沒有。
今天真正可以確定的是：
我們已經把 Stop 當成正式的 Authority / State Binding 問題，而不是一句文字指令。

而這件事情一旦想通，
下一個問題就更麻煩了。
如果 Action 不是停止，
而是：
「再試一次。」
那會發生什麼？
第一次 Action 已經失敗。
State 可能改變。
Permission 可能已經被消耗。
甚至第一次到底有沒有真正執行成功，也可能不完全確定。
這時候 AI 可以自己想：
「沒關係，我再來一次。」
嗎？
我的答案現在是：
不一定。
因為第二次 Retry，
有時候其實已經是一個新的 Decision。
Day 17：
AI 做錯了，可以自己偷偷再試一次嗎？