執行控制工程

前言｜控制必須發生在現實之前

寫完《執行縫隙》以後，問題並沒有結束。第一本書最終留下的是一個很直接的問題：如果意圖、授權、審批和策略都不能自動推出這一次現實動作應該發生，那麼，到底什麼東西能夠讓它真正發生？

《執行控制工程》就是從這個問題開始的。

最初面對這些工程問題時，我也很自然地想到過一些常見答案。既然上游判斷可能出錯，就在執行之前再檢查一次；既然一條策略不夠可靠，就增加更多策略；既然某一個主體可能失誤，就增加更多參與者；既然軟件本身可能失效，就在外面再增加一層安全系統。這些方法當然都可能有價值，但隨著工程繼續往現實執行這一端推進，我越來越意識到，真正的問題並不是系統還缺多少檢查，而是這些檢查最終有沒有能力約束那一次真正改變現實的動作。

審批可以成立，卻可能發生在距離現實執行很遠的位置；Policy 可以返回 Deny，卻未必真的能夠阻止 Executor；一個系統可以擁有很多參與者，卻仍然共享同一個控制根；一條邊界在部署圖上看起來完全獨立，卻可能仍然被受它約束的主體關閉、修改或者繞過。甚至一個完全正確的判斷，如果發生在現實副作用已經產生以後，也只能用於解釋、審計和追責，而不能再控制這一次動作。

這些現象逐漸把問題從「如何增加更多規則」推向了另一個方向：怎樣讓意圖、授權、狀態、策略、證據和邊界，在現實動作發生以前真正取得約束力。

這也是這本書所說的 Execution Control。

它關注的不是一個主體理論上擁有什麼權限，而是到了此時此刻，在當前狀態、當前對象和當前邊界下，這一次具體的 Action 是否仍然有資格改變現實。為了回答這個問題，一些過去經常被放在一起討論的對象必須被重新拆開：Capability 不等於 Authority，Authorization 不等於當前執行資格，Evidence 不等於 Log，Policy 不等於 Final Authority，Adjudication 也不等於 Execution。

這些區分不是為了創造更多術語，而是因為它們在工程上承擔的職責確實不同。意圖提供這一次動作應該參照什麼，授權說明某種資格如何形成，狀態描述此刻與執行直接相關的事實，證據支撐這些事實是否能夠被依賴，策略限定當前範圍，Runtime 對同一次 Action 形成裁決，Boundary 則必須讓這個裁決真正作用到現實執行路徑，而最終真正改變現實的仍然是 Executor。

這並不意味著所有系統都必須被實現成同一種架構，更不意味著《執行控制工程》是在為某一個具體產品寫理論說明。產品、硬件、協議、部署方式和承擔這些職責的具體組件都可以變化，但只要一個系統聲稱自己能夠控制現實執行，它就始終需要面對幾個基本問題：誰能夠讓動作發生，誰能夠阻止它發生，判斷依據是什麼，這些依據在當前時刻是否仍然成立，判斷髮生在什麼位置，以及當必要條件無法被充分建立時，系統究竟應該向哪個方向失敗。

執行控制也不意味著把系統重新退回人工逐筆審批。恰恰相反，如果真正需要獨立約束的位置能夠被建立起來，那麼安全就不必繼續依賴每一次 Action 都等待一個人在場確認。邊界越清楚，邊界內部越可以自動化；成熟的執行控制應該減少不必要的人類介入，而不是把「有人點過確認」當成現實動作可以發生的最終理由。

AI Agent 讓這個問題變得更加迫切，卻沒有創造這個問題。過去的軟件更多停留在信息處理層，而越來越多的系統正在直接調用工具、移動資金、修改賬戶、操作設備，並把一個判斷直接轉化為現實狀態的改變。到了這裡，安全工程已經不能只問一個主體有沒有權限，也必須繼續追問：

在現實真正被改變以前，什麼仍然有權說不？

這本書不會給出所有答案。研究進行到後面，一些關係仍然沒有足夠證據被固定下來，一些結構也只能停留在明確的未決狀態。我不希望為了讓一本書看起來完整，就替這些問題補上一個目前還沒有依據的答案。能夠建立的，就把它建立起來；不能建立的，就把邊界留下來。

如果《執行縫隙》首先追問的是：

我們面對的究竟是什麼問題？

那麼《執行控制工程》繼續追問的就是：

在現實發生之前，我們怎樣真正控制它？

《執行控制工程》從這裡開始。

王林 · 2026 年 9 月 · 成都

---

致謝

《執行控制工程》不是在《執行縫隙》之後自然推導出來的一本書。發現一個問題，和真正回答這個問題應該怎樣被控制，中間還有很長一段路。

首先要感謝吳夢婷、張勇和鄧江。作為本書的聯合作者，他們參與了這套工作從工程判斷走向結構化理論的過程。很多後來寫進書裡的概念和邊界，都經歷過反覆討論、質疑和修改。真正困難的往往不是提出一個聽起來合理的答案，而是不斷追問：這個答案到底成立到哪裡，什麼情況下會失效，又有哪些東西其實還沒有資格被說成結論。

也感謝所有參與 HAVENLON 工程與研究工作的夥伴。

如果沒有真實工程，這本書很可能會變成一套過於整齊的抽象模型。真正的系統並不會按照理論最方便的方式運行。協議會遇到異常，狀態會變化，組件會失效，邊界會被繞過，原本看起來清楚的權力關係到了現實系統裡也可能重新變得模糊。正是在一次次架構設計、協議實現、硬件調試、故障排查和安全取捨中，很多問題才真正暴露出來。

工程不斷逼著理論回答一個很樸素的問題：你說這裡存在一條邊界，那麼它到底能不能真的攔住一次動作？

同樣感謝參與資料整理、術語考古、案例核驗和研究工作的同事與合作者。把一個工程直覺寫成可以公開討論的結構，需要的不只是寫作。我們需要確認一個詞在過去究竟被怎樣使用，需要區分一個案例實際發生了什麼和我們希望它說明什麼，也需要在證據不足的時候主動停下來，而不是為了讓體系顯得完整，替未知補上一個答案。

感謝那些留下事故調查、工程復盤、司法記錄、監管報告、論文和技術文檔的人與機構。很多執行控制問題，如果只停留在假設場景裡，很容易得到過於乾淨的答案。真實失敗留下的記錄提醒我們，現實系統中的權力、狀態、證據和邊界通常比架構圖複雜得多，而任何一個看起來漂亮的結構，都必須經得起這些現實材料的反問。

我也感謝那些曾經閱讀、討論、質疑或者引用這套工作的朋友。一個理論如果只能在自己的語言體系裡成立，它的價值是有限的。不同領域的人從安全、金融、支付、工業、AI Agent 或組織治理的角度提出問題，常常會暴露一些作者自己已經習慣、因而不再注意的假設。很多時候，真正推動這項工作繼續向前的，並不是別人說「這個想法很好」，而是有人問了一句：

「如果這裡失效了呢？」

最後，我仍然要感謝我的家人，尤其是我的小朋友。

寫第二本書的時候，工程、研究和寫作已經越來越難真正分開。很多晚上，我看起來只是在電腦前修改一段文字，實際上可能是在檢查一條理論邊界；也可能看起來是在調一塊板子、查一段日誌，但最後留下來的，卻是書裡的一句話。

這些事情佔用了很多時間，也讓一些原本屬於生活的晚上和週末變成了工作。

孩子不會在意 Authority、Evidence、Runtime 或 Execution Boundary，也沒有必要理解為什麼一個成年人會花這麼長時間研究「怎樣讓一件事情不要發生」。但那些與技術無關的日常一直提醒我：我們研究怎樣約束機器、系統和權力，最終並不是為了讓系統本身更加複雜，而是因為現實世界裡真正被改變的，從來不只是數據。

所有工程最終都會落到人的生活裡。

謝謝你，在我繼續做這些漫長而且有時候很難解釋的事情時，依然在旁邊長大。

如果很多年以後你再次翻到這本書，我希望你看到的不只是一本關於控制系統的書，也會知道，在它形成的那段時間裡，有一部分現實生活一直在提醒我：

真正值得被控制的，從來不是可能性本身，而是那些最終會進入現實的力量。

王林
2026 年 9 月 · 成都

---

第一章｜全都批過了，為什麼還不夠

本章從一個反直覺事實開始：審批、授權、策略、資格等上游對象都可以在各自範圍內成立，卻不能因此推出「這一次具體動作現在應當到達現實」。問題不一定是某一環做錯了，而可能是這些局部成立被默認成了一個從未真正建立的端到端結論。於是，執行控制關注的就不再是怎樣把審批做得更嚴，而是上游全部成立以後仍然缺少的那次當前判斷。主體可錯也在這裡成為設計前提：人、AI、程序或其他主體都不能以「未來永遠判斷正確」作為系統成立的條件；但可錯不等於惡意，也不等於錯誤必然進入現實。一個主體會不會犯錯，與這個錯誤是否擁有改變現實的權力，是兩個不同的問題。現實案例在本章只提供語境，不承擔證明。本章最終只建立一條有限結論：上游成立，不足以替代對當前 Action 的判斷。下一問因此變成：這次判斷必須發生在哪裡，才仍然能夠改變現實？

復盤一次已經造成後果的事故，最難回答的問題通常不是「誰做錯了」。把鏈條一節一節拆開，看到的往往是相反的情形：申請寫得清楚，審批有人簽字，權限是按流程開的，策略引擎返回了允許，執行程序按照它拿到的參數完成了它被要求完成的工作。每一個人、每一個組件，在被單獨問到「你那一步做得對不對」的時候，都能給出一個站得住的回答。而現實狀態已經改變了，並且朝著沒有人想要的方向改變了。

這裡的「站得住」不是託詞。工程系統裡的每一個環節，本來就是按照自己的成立條件被設計和驗收的。審批面對的是被提交的那份材料，它判斷這份材料所描述的事情是否值得同意；授權面對的是主體與資源的關係，它判斷這個主體是否有資格擁有某種能力；資格面對的是某個主體或某個對象是否滿足被納入這類操作的條件；策略面對的是一組可被求值的條件，它判斷這組條件是否落在允許的範圍內；執行程序面對的是一組已經確定的參數，它的正確性由「有沒有忠實地完成被交代的事」來衡量。每個對象都有自己的輸入、自己的判據、自己的驗收者。事故之後逐個複核，會發現這些環節確實都可以在各自的標準下成立。

難堪的地方在於，這些成立加在一起，並沒有產生任何一個人真正想要的那句結論。

復盤時使用的語言本身也預設了一個可以被定位的失效環節。「根因」這個詞預設根因存在；「責任鏈」這個詞預設責任可以沿著鏈條被定位；「到底是哪一步出了問題」這個問句，已經假定確實有某一步出了問題。當每一步都成立時，這套語言不是給出了錯誤的答案，而是找不到原本預設的那個答案。會議於是很容易轉向另一件事：既然找不到那個環節，就退回去討論流程本身夠不夠嚴。

接下來通常會出現一種補救反射：再加一道審批，再多一個簽字人，把策略寫得更細一點，或者把審批的粒度切得更小。這些做法在各自的範圍內都有意義，但它們回答的仍然是同一類問題——某一環是否成立。加一環，只是讓「都成立」這句話覆蓋的範圍更大一點。如果失敗恰恰發生在「都成立」的條件下，那麼把這句話覆蓋得更寬，並不會自動補上缺少的判斷。

這本書從這裡開始。它要問的第一個問題是：Intent、審批、授權、策略與資格全部成立，為什麼仍然不能推出「這一次具體動作現在應當到達現實」？

問題裡有兩件事被當作已經存在，不需要重新論證。第一，系統中確實有一類動作，它們一旦發生，現實狀態就變了：錢轉出去了，閥門開了，配置推到了生產環境。這類動作與查詢、計算、生成建議不同，它們不能靠「下次注意」收回。第二，Intent、審批、授權、策略並不是紙上的比喻，它們在今天的系統裡已經是具體的工程對象，有實現、有接口、有失敗模式，也有各自被驗收的標準。

這兩件事都不新鮮。麻煩在於它們之間那個看起來理所當然的連接。

上游通過，不蘊含這一次

先把一條容易被默認的蘊含關係直接拆開：

上游的批准、授權或資格在自身範圍內成立，這件事本身並不足以確立「這一次具體動作應當到達現實」。

Upstream approval / authorization / qualification locally holds does not by itself establish that this particular action should reach reality.

它的形式值得停一下。它說的是不足以確立，不是說上游是錯的，也不是說上游無關緊要。一次審批的成立，意味著面對被提交的那些材料，有人或某個組件作出了一個在自身範圍內成立的判斷。它建立了它自己範圍內的那件事。它沒有建立、也不打算建立另一件事：在此刻這一次具體動作即將改變現實的時候，這個動作是否仍然應當發生。

平時，這條蘊含並不會被單獨寫出來。一個請求帶著已經成立的審批、授權或資格繼續往下走，這些結果也會成為後續處理的依據。這樣的分層本身沒有問題：每一層都有自己的職責和判據，到了真正改變現實狀態的末端，執行者拿到的是已經形成的參數與上游結論，它要做的是完成被交代的動作。問題只在於，上游這些判斷各自成立，並不能因此推出「這一次是否仍然應當發生」已經被回答。

這種默認在工程上並非沒有道理。如果下游必須重新驗證上游已經驗證過的每一件事，分層就失去了意義，系統也沒法運轉。可疑的地方不在於下游信任上游，而在於這份信任被悄悄擴大了範圍：上游證明的是它自己那件事，被當成的卻是關於「這一次動作」的結論。這兩者之間的差額，往往不會直接寫進接口，因為接口描述的是各自範圍內要成立的東西，而不是替它們建立一個關於「這一次動作」的共同結論。

一旦把這條蘊含攤開來寫，它的可疑就變得明顯。平時真正容易被忽略的，恰恰是這一步。

這條表述只能以否定式使用。把它翻過來寫成「因此決定動作是否發生的其實是某某」，就已經越過了它能支撐的範圍。它不提供一個正面的替代答案，它只是把一個被默認的蘊含關係拆開。

同樣，這一章不會給「上游」下一個正面定義，也不會去定義什麼叫「獨立」。這些詞在這裡只承擔指認的功能：那些在各自範圍內已經完成、已經成立、並且通常被認為足以支持後續動作的對象。這一章需要的只是「它們各自在自身範圍內已經成立」這一點，不需要更多。給出更多，反而會讓後面的論證依賴一個此刻還沒有被建立的定義。

也正因為如此，把執行控制理解成「更嚴格的訪問控制」或者「更完整的審批」，從一開始就錯了對象。訪問控制和審批都有自己的作用範圍，它們在這些範圍內成立，也不該被指責沒有做到本來就沒有承諾的事。執行控制關心的是上游成立以後仍然留下的那個問題：這些成立，是否已經足以讓這一次具體動作到達現實。僅僅把前面的環節做得更嚴格，並不能替這個問題作答。

每一環都成立，結果仍然相反

現在可以把這一章的結論寫出來了：

每一環在自身範圍內成立，聚合後仍可能產生相反的現實結果。

這句話的對照物必須說死，否則它會立刻退化成一句正確的廢話。它的對照物不是「其中有一環沒做好」，而是每一環在自身範圍內已經成立的上游對象。一旦把對照物悄悄換成「其實有一環沒成立，只是當時沒查出來」，整句話就變回了一個質量問題——排查得更仔細一點、測試覆蓋率再高一點、評審再認真一點，問題就該消失。而這句話的意思正好相反：即使排查是徹底的，即使每一環的成立都經得起復核，相反的現實結果仍然可能出現。

「質量問題」這個讀法之所以頑固，是因為工程系統本來就是被分解成部件來構建，也是被分解成部件來驗收的。每個部件都有自己的接口契約、自己的測試、自己的負責人。當整體出了問題，最自然的動作就是回到部件裡，尋找那個沒有滿足契約的地方。這種方法對於檢查部件是否滿足各自的成立條件當然有用，但它處理的是部件層面的問題。當所有部件都滿足了各自的契約，而整體的現實結果仍然與原本的意圖相反時，繼續用同一種辦法往部件裡找，已經不能回答眼前的問題。

「聚合」這個詞在這裡承擔的分量也需要說清楚。它指的不是各環問題的相加——如果每一環都有一點小毛病，加起來變成大毛病，那仍然是質量問題的一個變體。它指的是：在每一環都沒有毛病的前提下，這些成立被組合起來之後，所指向的現實結果與其中任何一環所判斷的東西都不相同。每一個判斷仍然在回答自己的問題，但這些答案放在一起，並不能自動得到「這一次動作是否應當到達現實」的答案。聚合並沒有讓不同的問題變成同一個問題。

需要同時說清楚的是，這條結論並沒有要求取消其中任何一環。審批、授權、策略、資格在各自範圍內都在做有價值的事，它們攔下來的東西不會因為這條結論而變得不重要。它說的只是：把這些環節做得再完整，也不會自動產生那個關於「這一次」的判斷。因為這些環節各自的判據，本來回答的就不是同一個問題。

這也意味著，Intent、理解、判斷、授權與最終現實執行之間存在一個可能產生偏差的系統性空間。這一章把這件事說到這裡為止。它不打算說明這種偏差通過哪些方式產生、有幾種形態、哪一種更常見——那是另一個層面的工作，本章既不承諾，也不需要它來支撐結論。

需要同時守住這條觀察的使用邊界。它描述的是一種可以觀察到的結構外觀，不是產生結果的機制。看到「每一環都成立，而結果仍然相反」，並不等於已經知道偏差通過什麼路徑發生，也不等於已經找到了某一個導致結果的斷點。

因此，它不能直接承擔因果解釋。繼續沿著這句話去尋找「到底是哪一次交接出了問題」「是哪一個轉換導致了偏差」，實際上是在要求一個否定判斷給出它本來沒有提供的正面答案。

它也不能用來識別或分類案例。一個事件出現這種外觀，只能說明局部成立與端到端執行成立之間不能直接畫等號；它不能據此判斷這個事件屬於哪一種失效，更不能由此建立一套互斥分類或逐項檢查表。

所以，這條觀察的價值在於否定：

每一環分別成立，仍不足以推出端到端執行成立。

至於偏差具體怎樣產生，需要由後面的結構分析另行回答。

十一個案例只提供語境

為了讓前面的判斷不只停留在抽象表達上，本書選取了十一個現實事件作為語境案例：Therac-25、Ariane 5 Flight 501、三哩島 2 號機組、Knight Capital、哥倫比亞號（STS-107）、2003 年北美大停電、波音 737 MAX（JT610 與 ET302）、深水地平線 / Macondo、切爾諾貝利 4 號機組、珍珠港，以及挑戰者號（STS 51-L）。

這些事件來自不同年代、不同產業和不同技術環境。本章把它們放在一起，是為了讓前面的判斷進入不同的現實語境，而不是把它限定在某一種技術棧或某一個行業中。

這些案例不證明本章的理論判斷，也不能被當作十一種互斥的失效類型。現實事件往往同時涉及多個結構問題，因此不能因為某個案例呈現出這一外觀，就把它直接歸入某一種單一原因。

其中一些事件還存在事實爭議、不同官方調查之間的差異，或者必須保留的證據邊界。本章不在這裡展開這些問題，也不為了敘述順暢而消除這些限制。

十一項事件的完整背景、事實核驗、主要官方來源及各自的證據邊界，統一收入本書附錄 《現實失敗與邊界案例》。

在這一章裡，它們只負責提供現實語境，不替理論承擔證明任務。

可錯不是指控

還有一條前提要在這裡建立，否則前面的論證很容易被讀成另一件事。

主體可錯是設計前提，惡意不是失效的必要條件。

可錯的含義很窄：無法證明該主體未來每一次判斷都一定正確。它首先是一個工程屬性，不是道德判斷，也不是對某個人或某個組件的評價。合法不等於正確，善意不構成安全邊界，能力提高也不消除可錯性。一個更強的模型、一個更有經驗的工程師、一個更成熟的自動化流程，都可能改善具體判斷的質量，但都沒有把「未來每一次判斷一定正確」變成一件可以證明的事。

這條前提帶來的工程後果很直接：不能把系統的成立寄託在「找到一個永遠正確的主體」上。原因並不是人不可靠，也不是模型不可靠，而是「永遠正確」本身無法成為一個可以依賴的系統條件。職級、資歷、經驗或者多人會籤，都可以改變具體判斷形成和複核的方式，卻不能把這個前提消掉。

把可錯當作工程屬性而不是道德判斷，改變的是接下來還能做什麼。如果把它理解成對主體的評價，剩下的辦法自然會轉向挑選更可靠的人、加強培訓、事後追責。這些事情各有價值，但它們解決的不是這裡的問題。作為一個設計前提，可錯不要求我們先判斷某個主體究竟有多可靠，也不要求估計它犯錯的概率，就可以繼續追問系統應該怎樣面對這個事實。

這句話單獨放在這裡，很容易被讀回「所以主體不可信」。它不是。它和另一個問題是同一件事的兩半：

一個主體是否會犯錯，和這個錯誤是否擁有改變現實的權力，是兩個獨立的問題。

第二問才是這本書要處理的。第一問無論答案如何，都不會自動決定第二問。即使我們相信一個主體非常可靠，只要系統的成立仍然依賴於「它以後一直判斷正確」，問題就沒有消失。反過來，一個主體可能犯錯，也不能因此直接推出它的每一次錯誤都會成為現實；錯誤是否能夠繼續到達現實，是另一個需要單獨回答的問題。把兩問混成一問，得到的還是那種熟悉的補救方式：既然可能犯錯，那就多找幾個人確認。這樣做改變了第一問，卻沒有自動回答第二問。

這裡還要排掉幾種容易出現的讀法。可錯不等於不可信，它不是對主體做信任評級；也不意味著應該降低自主性或者增加人工審批。把「安全」直接等同於「所有動作都由人確認」，仍然是在第一問裡尋找一個更可靠的主體。它談的也不是模型幻覺。幻覺只是某一類主體的一種出錯形式，而這裡的前提並不依賴主體是什麼。

它同樣不是一個全稱肯定句。它沒有說所有主體都會犯錯，也不是一個概率陳述。它說的只是：不能把「某個主體永遠正確」當作系統成立的依據。前者是在判斷主體，後者是在限定系統可以依賴什麼，這兩件事不能混在一起。

這條前提還留下一個需要明確保留的邊界：什麼可以被稱為主體，本書不在這裡給出完備分類。

人、AI Agent、自動化程序、管理員、SaaS、策略引擎、運行時、設備或者外部服務，都可能在具體系統中承擔判斷或執行作用。但哪些對象最終應該被納入同一套主體定義，並不是本章需要先解決的問題。

前面的論證也不依賴這套分類已經閉合。這裡真正需要的只是一個更窄的前提：

任何被系統賦予判斷或執行作用的主體，都不能以「未來永遠正確」作為系統成立的條件。

主體邊界本身繼續保持開放，本章不利用一個尚未建立的分類去提前封住它。

兩條需要一次性固定的限定

其一，關於「每一環成立而結果相反」。 它是一條分析性觀察，是外觀，不是成因。零方差等於零區分力。它不是機制，不是因果解釋，不是挑選案例的標準，也不是一套正式分類。因此，它不能充當某種失效的原因，也不能作為判斷某個事件是否屬於某一類的依據。

其二，關於主體可錯。 它的核心是否定式的：無法證明某個主體未來每一次判斷都一定正確；惡意不是失效的必要條件。這不等於「所有主體都會犯錯」，也不是一個概率命題。它還必須和另一半放在一起理解——一個主體是否會犯錯，與這個錯誤是否擁有改變現實的權力，始終是兩個獨立的問題。

剩下的問題

把前面的東西合起來，這一章的位置就清楚了：上游的成立不蘊含這一次。每一環在自身範圍內成立，聚合後仍可能產生相反的現實結果。主體可錯是設計前提，而不是對誰的指控。

由此還會自然產生下一步問題：

最終動作仍然需要一次不完全依賴上游的獨立判斷。

這裡的「不完全依賴」仍然只是一個否定邊界。它說明，這次判斷不能只是把上游已經形成的審批、授權、策略或資格結論原樣接過來，也不能因為這些對象全部成立，就認為「這一次具體動作是否應當發生」已經得到了回答。

但這句話不能反過來被擴張成一個正面的存在斷言。它沒有告訴我們，這次判斷一定由某一個人、某一個模塊、某一種邊界或者某一種具體機制承擔。

本章能夠確定的是：上游成立，不足以替代對這一次具體動作的判斷。

至於這次判斷究竟由什麼構成、由誰作出，以及它如何真正約束現實執行，仍然需要繼續往下回答。

這一章要留給讀者的，就是這一點不舒服：流程全都走完了，仍然不夠；而「不夠」並不是因為哪一環沒走好。帶著它往下走，問題的形狀已經和進來的時候不同了——不再是「怎樣把每一環做得更可靠」，而是這些上游判斷成立之後，仍然沒有回答的那個問題。

那麼，這次不完全依賴上游的判斷，應該在什麼時候發生？

本章術語

• 執行控制 ｜ Execution Control
• 意圖 ｜ Intent
• 授權 ｜ Authorization
• 可錯 ｜ Fallibility

本章案例與資料來源

十一項現實事件語境案例池

本章使用十一項現實事件組成一個語境案例池：

Therac-25、Ariane 5 Flight 501、三哩島 2 號機組、Knight Capital、哥倫比亞號（STS-107）、2003 年北美大停電、波音 737 MAX（JT610 與 ET302）、深水地平線 / Macondo、切爾諾貝利 4 號機組、珍珠港，以及挑戰者號（STS 51-L）。

這些案例在本章只承擔語境作用，用於說明：「每一環在自身範圍內成立，而聚合後的現實結果仍可能出現偏差」這一問題可以出現在不同年代、行業和技術環境中。

本章不以這些案例證明核心判斷，也不把它們整理成十一種失效類型、案例識別標準或逐項檢查表。

部分事件存在不同官方調查之間的分歧、事實不確定性或必須保留的證據限制。本章不在這裡展開這些完整事實鏈。

十一項事件的完整背景、事實核驗、主要官方來源及各自的證據限制，見本書附錄 《現實失敗與邊界案例》。

資料來源

本章不在正文中重複展開十一項現實事件的完整事實鏈與書目資料。相關材料統一列入附錄 **《現實失敗與邊界案例》**及全書 《參考文獻與資料來源》。

---

第二章｜最後一刻

本章追問的不是判斷應該早幾秒還是晚幾秒，而是它必須站在哪裡，拒絕才還來得及改變現實。現實副作用已經發生以後，判斷仍然可以用於審計、解釋和證明，卻已經不再控制這一次 Action；但僅僅發生在執行之前也不夠，因為審批、資格或 Policy 可能早已形成，而當前對象、狀態或載荷已經改變。執行前控制因此位於一個因果位置：現實副作用尚未發生，判斷仍然面對當前條件，而且其結果能夠真實限制、延遲或拒絕執行。它至少要求使用當前輸入、關鍵條件變化後重新判斷，並讓拒絕真正作用到執行路徑。Authorization、Policy、Runtime 和監控都可以參與這個過程，卻不能僅憑自身替代執行前控制，因為「產生一個判斷」與「讓這個判斷約束現實」不是同一件事。本章確定的是控制應站在哪裡，不規定硬件、協議或部署方式。位置確定之後，下一問就是：站在這裡究竟應該判斷什麼？

上一章把讀者留在一個不太舒服的位置上：意圖是清楚的，審批是完成的，授權是有效的，策略是通過的，資格是齊備的，每一環在自己的範圍內都沒有出錯，而這些成立加在一起，仍然不足以推出「這一次具體動作現在應當到達現實」。因此，最終動作還需要一次不完全依賴上游的判斷。

那麼，這次判斷該在什麼時候發生？這個問法本身帶著誤導。「什麼時候」聽上去像在問鐘錶，像是要在一條已經畫好的流程線上挑出一格，把判斷插進去。可是隻要認真嘗試回答，被追問的東西就會變形：它問的不是時刻，而是位置——這次判斷要站在哪裡，它說出的「不」才還來得及。差別沒有聽上去那麼細。如果只談時刻，早一點還是晚一點、各自付出什麼代價，往往還有討論的空間。位置的問題不同，因為它決定的是一句話有沒有效力，而不只是它來得是否及時。一個判斷如果發生在動作已經落地之後，它可以是準確的、完整的、有充分依據的，但已經改變不了這次動作。它變成了一份說明，不再是一次控制。

判斷必須發生在動作還沒有成為現實的時候

上一章留下的是一個判斷問題：上游已經成立，仍然不能自動推出「這一次具體動作現在應當發生」。那麼，如果還需要一次針對當前動作的判斷，它首先必須滿足一個非常樸素的條件：

它必須發生在現實副作用尚未發生的時候。

一筆錢已經轉出去以後，可以檢查這筆交易是否符合規則；一項生產配置已經生效以後，可以重新判斷這次變更是否合理；一個設備動作已經完成以後，也可以重建當時的狀態和決策過程。這些判斷都可能準確，也可能非常重要，但它們已經無法改變這一動作是否發生。到了這個位置以後，判斷承擔的是解釋、審計、歸因或者證明作用，而不再承擔對這一次動作的控制作用。

因此，「執行之前」首先劃出了一條時間邊界。但僅僅位於這條邊界之前，還不夠。一個判斷完全可以發生在動作之前，卻仍然離真實執行太遠。審批可能提前幾個小時完成，策略可能在請求剛進入系統時已經求值，資格可能更早以前就已經建立。只要在判斷形成以後，對象、狀態、載荷或者其他關鍵條件發生變化，原來的結論就可能仍然存在，而它所依據的現實已經不同。

所以真正需要尋找的不是流程上最後一個已經完成的判斷，而是：

在現實副作用發生以前，仍然能夠依據當前條件對這一次 Action 作出判斷，並讓拒絕真實作用於執行的位置。

本章把這種控制稱為執行前控制（Pre-Execution Control）。執行前控制發生在現實副作用之前。它依據當前的 State、Policy、Authority、Boundary 和 Evidence，判斷這一次 Action 是否可以繼續，並且能夠真實限制、延遲或者拒絕執行。這裡有三個條件缺一不可。

第一，判斷必須位於能夠真實阻止執行的位置。如果一個位置只能看到動作、記錄動作或者給出建議，卻無法讓一個拒絕作用到真正的執行路徑上，那麼它不是這裡所說的執行前控制。

第二，判斷必須使用當前輸入。已經成立的歷史狀態、資格、審批和策略結果都可以成為輸入，但不能因為它們曾經成立，就假定動作真正發生時仍然成立。

第三，如果判斷以後關鍵狀態或者載荷發生變化，就必須重新判斷。否則，一個曾經正確的結論可能在真實執行發生時已經失去適用條件。

這三個條件也直接給出了執行前控制可能怎樣失效。控制點可以被旁路；判斷以後關鍵條件發生變化，卻沒有重新驗證；或者判斷已經給出拒絕，但這個拒絕根本無法到達實際執行能力。這些失效都不要求判斷邏輯本身出錯。

設想一個簡單的工程情形：某個控制環節準確地得出了「不允許」，結果也被完整記錄下來，但真正發起動作的調用路徑從來不會讀取這個結果。判斷沒有錯，日誌也沒有丟，動作仍然發生了。這裡缺少的不是更聰明的判斷，也不是更多記錄，而是一個能夠讓判斷對現實執行產生約束的位置。

「最後一刻」不是鐘錶上的最後一秒

這也解釋了為什麼本章叫「最後一刻」。這裡的「最後一刻」不是一個精確時間點，也不是要求所有判斷都拖到動作發生前的最後幾毫秒。它描述的是一個因果位置：

再往後，現實副作用就已經發生；而在這裡，一句「不允許」仍然來得及改變這一次動作是否發生。

因此，一個控制越靠近執行，並不自動意味著它越有效。關鍵不是物理距離，也不是流程順序，而是它是否面對真正發生動作時的條件，以及它的判斷是否能夠約束真正的執行路徑。這也意味著，判斷邏輯和執行能力並不要求物理上處於同一個進程、同一臺機器或者同一個設備裡。它們可以分開部署。真正需要建立的是因果上的關係：一旦執行前控制拒絕這次 Action，這個結果必須能夠真實限制、延遲或者阻止對應的現實動作。

所以「最後一刻」最終指向的不是一個時鐘位置，而是兩個條件同時成立的位置：**判斷仍然面對當前現實。****拒絕仍然能夠改變現實。**缺少前一個條件，判斷可能已經過期；缺少後一個條件，判斷只是一份意見。

幾個看起來很像、實際上不同的東西

執行前控制很容易和其他對象混在一起，因為它們可能出現在同一條執行路徑上，也都可能產生 Allow、Deny、通過、拒絕或者資格成立這樣的結果。但它們承擔的任務並不相同。授權可以為某個主體建立使用某類能力的資格。這個資格可以成為執行前判斷的重要輸入，但一個過去已經成立的授權，不會因為當前狀態發生變化而自動形成一次新的當前判斷。因此，Authorization 可以成為輸入，但不能僅憑自身替代執行前控制。

Policy 與執行前控制距離更近。Policy 可以描述判斷規則，也可以在動作接近執行時被求值。但規則得到了一個結果，並不自動意味著這個結果已經能夠約束真實執行。**Policy Decision 與讓這項 Decision 獲得現實約束力，仍然是兩個問題。**Runtime 也可能承擔執行前控制所需要的判斷邏輯，但運行判斷的位置和控制本身仍然不是同一個概念。一個 Runtime 能夠執行判斷代碼，只能說明判斷在那裡發生；它還不能單獨說明拒絕已經能夠限制現實動作。

執行控制（Execution Control）則是更大的對象。執行前控制是執行控制的一種重要形式，但執行控制不能被整體壓縮成「在執行前多做一次判斷」。後面還會涉及判斷依據、權威、邊界、拒絕、證據以及動作發生之後的證明問題。執行後證明（Post-Execution Proof）位於另一側。它面對已經發生的現實副作用，目的是建立有關執行過程或結果的可驗證事實。執行前控制面對的則是尚未發生的 Action，它必須在副作用出現以前仍然能夠改變動作是否發生。

普通監控也不是執行前控制。監控可以非常接近真實動作，可以看見狀態變化，甚至比其他系統擁有更多信息。但「看見」和「能夠阻止」不是一回事。一個位置即使知道所有必要信息，只要它的判斷不能作用到實際執行路徑上，它仍然是觀察位置，不是執行控制位置。

它不是審批，也不是一張流程圖

「最後一刻」很容易被理解成流程中的最後一道審批。這個理解看上去很自然：既然判斷要儘量靠近執行，那麼把審批放在流程圖最後一格，似乎就得到了執行前控制。但這裡區分的並不是流程上的早與晚，而是一個判斷有沒有現實控制能力。審批首先是一個流程對象。它可以規定由誰批准、經過多少層、按照什麼順序流轉，也可以決定什麼條件下進入下一步。執行前控制關心的是另一個問題：現實副作用發生以前，是否仍然存在一個位置，可以依據當前條件讓這一次 Action 停下來。

因此，一個審批即使位於流程的最後一格，也不會因為位置靠後就自動成為執行前控制。如果它依據的仍然是更早提交時的狀態，而執行前關鍵條件已經發生變化，它可能已經過期。如果它給出的拒絕只進入記錄、通知或者工單系統，真正的執行路徑仍然可以繼續，它也沒有形成執行前控制。

反過來，一個執行前控制也不要求自己必須以「審批」的形式存在。它可以由軟件邏輯、獨立控制組件或者其他結構承擔。本章不在這裡規定實現形態，只規定它必須滿足的控制條件。所以流程圖可以告訴我們事情經過哪些環節，卻不能單獨告訴我們哪一個環節真正控制現實執行。這一區別也限制了本章結論能夠推出什麼。

知道控制必須發生在現實副作用之前，並且拒絕必須真實作用於執行，只確定了一個工程位置和成立條件。它沒有進一步規定某種產品架構、協議、算法或者部署方式。本章不由「最後一刻」推出必須使用硬件，也不推出必須把判斷邏輯與執行器放在一起；同樣不推出一定要新增一道人工確認或者某一種固定流程。

這裡建立的只有一個更窄的約束：**在 Action 成為現實以前，必須仍然存在一個面對當前條件、並能夠真實限制這一次執行的位置。**至於由什麼組件承擔、怎樣部署、採用什麼協議，以及如何讓這個位置本身不被繞過，都屬於後面需要繼續回答的問題。

剩下的問題

到這裡，已經可以把「最後一刻」說得更準確。它不是鐘錶上的最後一個時間點，也不是流程圖上的最後一個節點。它是現實副作用發生以前，判斷仍然面對當前條件，並且拒絕仍然能夠真實約束執行的位置。執行前控制因此至少要求三件事同時成立：使用當前輸入；關鍵狀態或載荷變化以後重新判斷；判斷結果能夠真實限制、延遲或者拒絕對應的 Action。

這已經回答了判斷應該站在哪裡。但位置不是內容。知道一個判斷必須發生在這裡，還沒有告訴我們，站在這裡究竟要判斷什麼。

State、Policy、Authority、Boundary 和 Evidence 都可能進入一次執行判斷，但在回答「依據什麼判斷」以前，需要先確定一個更基本的問題：這些東西究竟是在幫助系統回答哪一個問題。否則，我們可能擁有很多信息、很多規則、很多資格和很多證明，卻仍然沒有把真正需要回答的那件事說清楚。所以第二章最終停在這裡：在那一刻要判斷的，究竟是哪一個問題？

本章術語

• 執行控制 ｜ Execution Control
• 執行前控制 ｜ Pre-Execution Control

本章案例與資料來源

**本章無現實案例。**正文中「某個控制環節得出不允許，但實際執行路徑並不讀取這一結果」屬於假設性工程情形，用於說明判斷存在與判斷能夠約束執行之間的區別。該情形不對應具體公司、產品或現實事件，也不承擔本章結論的證明作用。

資料來源

本章沒有需要單獨展開的現實事件資料。執行前控制的定義、成立條件、失敗條件及其與授權、策略判斷、運行時、執行控制、執行後證明和普通監控之間的邊界，均在正文中直接展開。涉及真實事件、外部報告、論文或標準的資料，統一列入本書附錄及全書 《參考文獻與資料來源》。

---

第三章｜能不能、允不允許、這一次是否應當

本章把一句「有沒有權限」拆成三個不同的問題：現實中能不能做到，制度上允不允許擁有這種能力，以及到了現在，這一次具體 Action 是否仍然應當發生。第一問面對 Execution Capability，第二問面對 Authorization 或資格，第三問才是當前執行判斷。三者彼此相關，卻不能互相替代：技術上做得到，不等於被允許擁有；資格已經成立，也不等於以後每一次動作都自動獲得執行資格。Authorization 是此前形成的資格事實，可以成為當前判斷的重要輸入，卻不能代替當前判斷本身，因為現實狀態可能已經變化。同樣，Capability、Authorization 與 Authority 之間也不存在一條天然的升級鏈，現實能力不會因為無人阻止就自動變成 Authority。本章的「應不應當」不是倫理判斷，而是一個工程問題：在當前條件下，這一次 Action 是否仍然可以進入現實。三問被拆開以後，真正缺少的問題終於顯現出來：究竟誰或什麼能夠讓這一次 Action 獲得現實效力？

上一章把判斷的位置釘在了現實動作發生之前的最後一刻。但位置確定以後，還有一個更基本的問題沒有回答：站在那個位置上的系統，究竟在判斷什麼？

工程語言很容易用一句「有沒有權限」把這個問題帶過去。但如果把它拆開，裡面其實至少包含三個不同的問題：一個主體能不能做到這件事。它是否被允許擁有或使用這類能力。到了此刻，這一次具體動作是否應當發生。為了避免後面再次混在一起，本章把它們固定成三個問題。

第一問，能不能做到。這是現實能力的問題：有沒有一條真實可達的路徑，能夠讓動作發生。第二問，允不允許擁有。這是資格的問題：某個主體是否被允許擁有或使用這一類能力。第三問，這一次是否應當發生。這是當前執行判斷的問題：即使能力存在、資格也已經成立，在現實動作發生之前的這一刻，這一次具體動作是否仍然滿足執行條件。

三者並非彼此無關。能力是資格判斷所約束的對象；已經成立的資格判斷又可以成為當前判斷的輸入之一。但它們不能彼此代替。能做到，不等於被允許擁有；被允許擁有，也不等於這一次就應當發生。它們之間還有一個很重要的時間差異。第一問描述的是當前現實中已經存在的能力；第二問描述的是此前已經形成的資格判斷；第三問則必須面對當前這一次動作重新作出。一個落在現實能力上，一個落在已經形成的資格記錄上，一個落在動作即將進入現實的那個時刻。後面的討論都圍繞這三個問題展開。

能不能做到，和允不允許擁有

先看第一問和第二問之間的界線。能不能做到，首先面對的是現實能力：系統中是否存在一條真實可達的路徑，使某個主體能夠造成對應的現實結果。允不允許擁有，面對的則是資格：這個主體是否被允許擁有或者使用這一類能力。兩者可以同時成立，也可以彼此分開。

一個主體即使沒有得到制度上的授權，只要它事實上擁有一條能夠獨立造成真實結果的技術路徑，這條能力就不會因為「沒有被批准」而自動消失。反過來，一個主體即使已經獲得某項資格，如果現實中並不存在對應的技術能力，資格本身也不會憑空創造出這項能力。

所以：

能不能做到，描述的是現實能力。

允不允許擁有，描述的是資格。

本章把第一問稱為執行能力（Execution Capability），但這裡需要保留一個邊界：本章並不試圖給「執行能力」建立一套完整的一般定義。在這一章中，它只承擔一個足夠窄的作用——把「現實中能不能造成結果」與「制度上是否被允許擁有這種能力」區分開。因此，不能因為一個主體事實上擁有執行能力，就直接把它讀成擁有 Authority；同樣，也不能因為一個主體擁有資格，就推出它已經具備現實執行能力。

這裡還缺少另一條更重要的關係：執行能力在什麼條件下、在什麼時刻會形成 Authority，本章沒有給出轉換規則。

「沒有人阻止它」並不能自動完成這個轉換；「技術上做得到」也不能直接等價於「它擁有讓這一次動作獲得現實效力的權威」。還要注意另一種常見的切分方式：Permission Set 描述一個主體名義上被允許接觸或調用什麼，而 Reachable State Space 描述它事實上能夠把現實狀態推到哪裡。這是一條有價值的觀察軸，但它和前面的「現實能力 / 制度資格」不是同一條軸。本章不把兩者強行對齊，也不假定其中一套可以逐項翻譯成另一套。

這裡真正需要固定的只有第一道界線：現實中做得到，與制度上被允許擁有，是兩個不同的問題。

昨天成立的事實

第一問和第二問分開以後，第二問與第三問之間還有一道更難忽略的界線：**時間。**授權首先是一項已經形成的資格事實，而執行面對的是此刻正在接近現實的具體動作。可以把這一區別寫得很直接：授權是過去發生的事實，執行是此刻發生的現實改變。過去的事實可以成為當下判斷的輸入，卻不能替代當下的判斷。

一次授權在形成的時候，只能依據當時能夠看到的對象、狀態、範圍和條件。授權一旦成立，就成為已經存在的資格記錄。但真正的執行可能發生在幾秒以後，也可能發生在幾個月以後。在這段時間裡，授權記錄可以完全沒有變化，而現實狀態已經改變。審批同樣具有這種時間屬性。一次審批反映的是作出審批時能夠獲得的信息以及當時適用的上下文。它可以繼續有效，卻不能因為仍然有效，就自動回答未來每一次具體 Action 在當時條件下是否仍然應該發生。

設想一種很簡單的情形。某類操作在季度初已經獲得使用資格。到了季度中間，其中一次具體操作遇到了批准時沒有出現的狀態。原有資格可能仍然完全有效。但眼前的問題已經變成了另一個問題：在現在這個狀態下，這一次動作是否仍然應該發生？

這就是為什麼 Authorization 可以成為當前執行判斷的重要輸入，卻不能成為當前判斷本身。可以把這條邊界再收緊一句：Input ≠ Authority。

一個授權事實可以被讀取，可以被驗證，也可以在判斷中佔據非常重要的位置。但「授權記錄確實存在」與「因此這次 Action 現在應當放行」不是同一個判斷。如果系統把前一個查詢結果直接接到後一個執行結果上，發生的並不是一次寬鬆的當前判斷，而是當前判斷被歷史資格替代了。

因此，問題不能只寫成「授權在上游、執行控制在下游」。更準確的區別是：授權回答的是曾經建立過什麼資格；執行判斷回答的是在當前條件下，這一次動作是否仍然成立。

授權不因此等同於 Authority，也不等同於執行能力，更不等同於一次具體動作已經獲得最終執行資格。這些區別並沒有告訴我們 Authority 的完整定義是什麼。它們只說明：一項過去已經成立的資格事實，不能自動成為此刻現實改變的最終答案。

「該不該」問的不是對錯

三個問題裡，第三個最容易因為「應不應當」這幾個字產生歧義。這裡的「該不該」，不是價值判斷，也不是倫理判斷。執行控制要回答的是：這一次具體 Action 在當前條件下，是否仍然滿足進入現實執行的條件。

它不判斷業務目標是不是明智，也不判斷一個動作在道德意義上是否正確。它面對的是一個更窄的工程問題：現實副作用尚未發生，而當前條件已經擺在面前，這一次 Action 是否可以繼續。因此，執行控制不能重新退回幾個已經熟悉的對象裡。

它不等於訪問控制。訪問控制首先處理主體能否接觸、進入或者使用某個對象；執行控制面對的是已經來到執行位置的這一次 Action 是否仍然可以發生。它不等於授權。Authorization 是已經形成的資格事實，可以進入當前判斷，但不能替代當前判斷。它不等於批准。Approval 同樣是在特定時間和上下文中形成的治理判斷；它曾經成立，不意味著當前動作已經被重新判斷。

它不等於 Policy。Policy 可以描述規則，也可以成為執行判斷的重要輸入，但一條規則或者一次 Policy Decision 本身，不自動等於這次 Action 已經獲得現實執行效力。它不等於人工確認。把判斷交給一個人，只改變了判斷由誰作出。如果確認動作沒有重新面對當前狀態，也不能真實約束執行路徑，那麼多一個點擊並不會自動形成執行控制。它不等於事後審計。審計面對已經發生的現實結果；執行控制面對尚未發生的 Action，並要求判斷在現實副作用發生以前仍然能夠產生約束。

執行控制也不能被壓縮成某一種單一的執行前檢查。執行前控制回答的是控制站在哪裡，Execution Control 還需要繼續回答它根據什麼判斷、誰具有現實效力、邊界怎樣成立、拒絕怎樣生效，以及執行以後如何形成證明。所以第三個問題真正問的是：在當前 State、參數、Authority、Policy、Boundary 與 Evidence 條件下，這一次 Action 是否仍然滿足執行條件？

這些判斷依據在這裡先被點名，但本章不繼續展開。第三章的任務只是先把問題本身分清楚。至於用什麼作為判斷依據，要等後面的章節再回答。同樣，本書使用的 Authority 是一個工程語義上的概念。它不能因為和其他領域存在同名詞，就直接繼承那些領域已經存在的含義。本章只在已經建立的邊界內使用它，不借同名術語提前補出正面定義。

不是一條向上的鏈

三個問題被分開以後，很容易產生另一種誤解：把它們重新排成一條自下而上的升級鏈。先有能力，再獲得授權，然後自然得到 Authority，最後由執行控制放行。這條鏈不能成立。

一邊存在有能力而沒有 Authority的情況。一個主體技術上可能已經擁有造成現實結果的路徑，但這並不能自動賦予它讓動作獲得現實效力的權威。另一邊也存在有 Authority 而不具備對應執行能力的情況。一個控制位置可以擁有獨立拒絕或者否決一項動作的權力，卻不因此獲得親自完成這項動作的能力。

因此，Capability 與 Authority 之間不存在一個可以默認成立的單向升級關係。授權也不能承擔中間那個自動轉換步驟。Authorization 可以改變一個主體的資格，但資格成立仍然不能自動推出當前動作獲得現實效力。

可以用一句很短的對照把這一點記住：

Permission describes possibility. Authority determines reality.

權限描述的是允許範圍與可能性；Authority 追問的是，什麼能夠讓現實結果最終成立或者停止成立。但這句話只是一條對照，不是一套完整定義。它既不能單獨定義 Permission，也不能單獨定義 Authority，更不能用來推導「具備哪些條件就獲得 Authority」。

所以三個問題之間有關係，卻不能畫成一條天然向上的箭頭：

能做到，不自動推出被允許擁有。

被允許擁有，不自動推出這一次應當發生。

擁有現實能力，也不自動推出擁有 Authority。

同樣，本章不把這些關係整理成一張看起來已經完成的層級圖或者對應表。原因不是三者不能比較，而是有些正面關係仍然沒有建立。過早把它們固定成上下層，很容易讓圖形替理論做出一個本章並沒有作出的推論。這裡需要保留的，是已經能夠確定的區分，以及它們之間不能自動推出的關係。

只能說它不是什麼

把三個問題分開，並不意味著相關概念已經全部獲得了完整定義。有幾道邊界必須繼續保持開放。

第一，**本章沒有給 Execution Capability 建立完整的一般定義。**這裡使用它，只是為了指向「現實中能不能做到」這個問題。這個用法足以把能力與資格分開，卻不足以繼續給出一套完整的執行能力判定標準。因此，本章不能回答「滿足哪些條件就一定構成 Execution Capability」。

第二，**Capability 如何形成 Authority，沒有一條已經建立的轉換規則。**一個主體擁有現實能力，不意味著這項能力會因為未被阻止而自動成為 Authority；授權這項能力，也不意味著 Authority 隨授權一併產生。這個轉換需要什麼條件、發生在什麼時刻，本章不回答。

第三，**Authority 在這裡仍然沒有一個完整的一般正面定義。**當前能夠穩定使用的是它的邊界：Authority 不能直接等同於 Permission、Authorization 或 Capability，也不能因為某個主體掌握實際執行路徑，就自動認定最終現實效力已經歸屬於它。這些否定邊界已經足以阻止一些錯誤等同，卻不足以反過來構成一套「什麼就是 Authority」的充分條件。

第四，本章出現了不止一種觀察權力結構的方法。現實能力與制度資格是一條切分軸；Permission Set 與 Reachable State Space 又是另一條切分軸。這些觀察方式可以同時有用，但它們之間並沒有建立可以逐項對應的關係。本章不把它們強行合成一個統一座標系。

這些未決部分不會妨礙本章已經完成的工作。第三章需要建立的是三道區別：

現實中能不能做到。

制度上允不允許擁有。

到了現在，這一次具體動作是否應當發生。

只要這三問不再被彼此替代，本章的任務就已經完成。剩下的定義、轉換和對應關係，可以繼續保持開放，而不需要為了讓這一章顯得完整就提前補上答案。

那麼，誰能讓它發生

回到最後一刻。現在，那一刻要判斷的問題已經被分開了：能不能做到，是一個現實能力問題；是否被允許擁有這類能力，是一個已經形成的資格問題；而這一次是否應當發生，是一個只能面對當前 Action 作出的執行判斷。已經成立的資格可以成為第三個判斷的輸入，但三者不能互相代替。

問題分開之後，一個新的問題隨之出現。既然「這一次是否應當發生」是一個獨立的問題，那麼——**誰能讓它發生，由什麼決定？**這個問題看起來仍然可以從前面的某一項中尋找答案：誰有身份，誰有權限，誰被授過權，誰簽過批，誰通過了策略判斷，或者誰事實上握著能夠造成現實結果的能力。但第三章已經說明，這些對象都不能因為自身成立，就自動成為最終答案。這一章把問題交到這裡。它不回答「誰能讓它發生」，只把這個問題從「有沒有權限」之類的已有問題中單獨拆出來，使它成為下一章必須正面面對的對象。

本章術語

• 執行能力 ｜ Execution Capability
• 權限 ｜ Permission
• 授權 ｜ Authorization
• 權威 ｜ Authority
• 執行控制 ｜ Execution Control

本章案例與資料來源

**本章無現實案例。**正文使用一處假設性工程情形，用於區分「資格仍然有效」與「這一次具體動作是否仍然應當發生」。該情形不對應具體公司、產品或現實事件，也不承擔本章結論的證明作用。

資料來源

本章沒有需要單獨展開的現實事件資料。正文涉及的 Execution Capability、Permission、Authorization、Authority 與 Execution Control，均按照本書已經建立的工程語義和邊界使用。尚未建立的一般定義、轉換關係與對應關係繼續保持開放，本章不為這些缺口補出額外答案。涉及外部論文、標準、官方資料或現實事件的內容，統一列入本書附錄及全書 《參考文獻與資料來源》。

---

第四章｜「誰能讓它發生」必須被單獨回答

本章把「誰能讓這一次動作真正發生」從身份、權限、授權、審批、策略和執行能力中單獨抽出來。Identity 能說明請求來自誰，Permission 說明主體名義上可以做什麼，Authorization 記錄資格如何形成，Approval 說明流程是否完成，Policy 可以產生 ALLOW 或 DENY，Capability 則說明現實中是否存在可達路徑；但這些對象中的任何一個，都不能因為自身成立，就自動回答「什麼使這一次 Action 獲得現實效力」。因此，Authority 必須被單獨分析。它至少指向一種在明確範圍內、能夠對 Action、規則、狀態或邊界形成系統約束的權力，但本章並不因此給出 Authority 的完整正面結構，也不把若干否定條件拼成一張檢查表。Policy Decision 是否正確，與它是否真正能夠約束 Executor，同樣是兩個問題；現實中做得到，也不等於擁有 Authority。本章完成的是把問題從其他概念下面完整抽出來。下一問隨之出現：最終現實效力一定要歸屬於某一個人、某一個組件或者某一個主體嗎？

上一章把三個問題分開了：能不能做到，允不允許擁有，這一次是否應當發生。分開本身沒有給第三個問題帶來答案，只是讓它終於有了自己的位置。而一旦把它放回現實動作即將發生的那一刻，問題會進一步收緊：**這一次，誰能讓它發生？**這個問題聽上去並不陌生，因為很多已經存在的判斷都與它有關。

它一直被當作別的問題的餘數

身份、權限、授權、審批、策略判斷和能力持有，都可以給出與一次執行有關的答案。麻煩在於，這些答案中的任何一項，都不能自動回答另一個問題：誰能讓這一次動作獲得現實效力？

身份系統回答請求來自誰；權限模型回答這個主體名義上可以做什麼；授權記錄回答某項資格如何形成；審批流回答流程是否完成；Policy 判斷回答當前請求是否落在允許範圍；Capability 則說明現實中是否存在一條真正能夠造成結果的路徑。把這些答案放在一起，很容易產生一種完整感。主體、資格、流程、規則和現實能力似乎都已經清楚，於是再問「誰能讓它發生」，看上去像是在重複一個已經回答過的問題。

設想一個內部系統正在修改對外收款賬戶。發起賬號真實存在，權限有效，授權記錄完整，審批已經通過，Policy 返回 ALLOW，執行服務也持有有效憑據。這些條件全部成立以後，仍然可以再問一句：究竟是什麼，使這次修改最終獲得現實效力？

前面的條件都重要，但其中任何一個都不能因為自己成立，就自動成為這個問題的答案。身份成立，不等於現實動作已經獲得最終效力；Permission、Authorization 和 Approval 成立，也沒有完成從資格到現實結果的跳躍；Policy 返回 ALLOW，只形成了一個判斷；而掌握執行能力，也不能因此直接被讀成擁有讓這一次 Action 獲得現實效力的 Authority。這些對象當然可以參與最終判斷。Authorization 可以成為輸入，Policy 可以成為判斷依據，Capability 決定動作在現實中是否可達。但：輸入不是結論，相關也不等於可以自動推出。

因此，本章要把那個長期容易被已有對象覆蓋的問題單獨拿出來：在一次具體現實執行發生之前，誰能讓它發生？

一條否定式的判斷

本章首先建立的是一條否定判斷：

在一次具體現實執行發生之前，「誰能讓它發生」是一個必須被單獨回答的問題；它不能由 Identity、Permission、Authorization、Approval、Policy 判斷或 Capability 佔有中的任何一項自動回答。

這句話只說明「不能由什麼推出」，不直接回答 Authority 完整地是什麼，也沒有給出 Authority 應該由誰持有。因此，把 Identity 做得更可靠、把 Permission 切得更細、把 Authorization 設計得更嚴格、增加更多 Approval、完善 Policy，或者把 Capability 控制得更加精確，都不能僅憑這些改進本身回答「誰能讓這一次動作獲得現實效力」。這並不表示這些對象彼此無關，也不表示它們對於執行控制不重要。真正需要保留的區別是：一個對象可以參與執行判斷，卻不因此等於最終現實效力本身。

所以後面即使出現「Authority determines reality」「Policy Decision 不是最終執行權」這樣的表達，也只能在這條邊界內理解。它們用於把 Authority 與已有對象分開，不用於提前補出一套完整的 Authority 正面定義。

這些區別最後都落到同一個問題

前面的否定可以從幾個不同方向繼續看。Permission 描述一個主體被允許擁有怎樣的可能性，但擁有這種可能性，並不等於某一次具體動作已經獲得現實效力。Policy 可以形成 ALLOW 或 DENY，但一個 Decision 被產生出來，與這個 Decision 能否約束真實執行，是兩個問題。訪問一條執行路徑，也不等於已經獲得讓對應現實結果發生的 Authority。能夠到達支付接口，與能夠讓一筆支付最終成為現實，不是同一件事。

同樣，身份、權限、授權、人工批准和 Policy 都可以對主體、資格、規則或者流程形成約束，但最終執行面對的是一次具體事件：這一次 Action 到底能不能獲得現實效力。

因此可以保留一句很短的對照：**Permission describes possibility. Authority determines reality.**這句話的價值在於區分兩個問題，不在於給兩個概念下完整定義。Permission 描述允許範圍和可能性；Authority 追問的是，什麼能夠對現實結果產生最終約束效力。

同樣，分析 Authority 時也不能只問「誰能說 ALLOW」。還需要問：**在 Action 即將成為現實以前，誰仍然能夠讓它停止？**這並不意味著 Veto 已經等於 Authority，也沒有因此建立一套完整的否決理論。它只揭示 Authority 的一個重要側面：一個主體參與了流程，與它擁有現實約束力，不是同一回事。

Authority 不能被現有對象直接吸收

把「誰能讓它發生」單獨提出以後，還會出現另一種自然反應：既然這是一個問題，那它會不會其實只是某個已有概念換了一個名字？本章的回答仍然是否定的。

Authorization 不能吸收它。Authorization 建立的是資格，而資格可以成為現實執行判斷的輸入，卻不能自動成為現實執行效力本身。Capability 也不能吸收它。一個主體現實中做得到，並不意味著它擁有讓這個動作獲得現實效力的 Authority。上一章已經把「能做到」和「這一次是否應當發生」分開。

Policy 同樣不能吸收它。Policy 可以規定邊界，也可以對當前請求形成 Decision，但一個 ALLOW 結果不會因為被產生出來，就自動獲得對現實動作的因果控制力。Policy 是否正確，與這個判斷是否能夠真正約束 Executor，是兩個問題。Governance 也不是答案。治理可以建立規則、流程、責任、監督和協調結構，但治理結構存在，不意味著它本身就是最終現實執行者。Governance 可以約束執行，卻不因此等於 Final Execution Authority。

Veto 也不能單獨吸收 Authority。能夠拒絕或者停止一項動作，是分析 Authority 時非常重要的能力，但單獨存在一個否決能力，並沒有回答 Authority 的全部結構、範圍和關係。Execution Control 更不能直接成為 Authority 的定義。Execution Control 本身需要 Authority 作為判斷和約束關係的一部分；如果反過來再用 Execution Control 定義 Authority，兩個概念就會開始互相解釋。

因此，這些對象都可以和 Authority 發生關係，卻不能由其中任意一個單獨把 Authority 無損替代。可以把這一點寫成一條更完整的邊界：**在一次具體現實執行發生之前，「誰或什麼能夠使這個 Action 獲得現實效力」不能由 Authorization、Capability、Policy、Governance、Veto 或 Execution Control 中的任意單項無損推出。**這就是為什麼 Authority 必須被單獨分析。

這裡還有一條同樣重要的原則：**Dependency ≠ Identity。**一個對象依賴另一個對象，不意味著它們就是同一個對象。Execution Control 的判斷可以依賴 Authority，Authority 也會影響一次 Action 最終是否獲得現實效力，但這種依賴關係並不意味著二者可以被合併成同一個概念。

Authority 至少有一條工程邊界

雖然本章不給 Authority 建立完整的一般正面結構，但這並不意味著這個詞完全沒有邊界。在本書中，Authority 至少按照下面這個工程含義使用：**權威是在明確範圍內，對 Action、規則、狀態或邊界作出對系統具有約束力之決定的權力。**這裡的 Authority 是工程意義上的權威，不是知識聲望、專家地位或者組織頭銜。

這個最小邊界同時排除了幾個容易發生的等同：**Authority ≠ Permission。****Authority ≠ Capability。****Authority ≠ Authorization。**一個主體擁有 Authority，也不表示它永遠正確。

Authority 的範圍必須能夠被說明。如果一項 Authority 可以被自動繼承、無限擴大，或者因為擁有某一種權力就被理解為擁有所有現實動作的最終權力，那麼它的邊界已經失去意義。Policy 與 Authority 的關係也必須繼續保持清楚：**Policy 是執行判斷的重要輸入，但不能被默認視為最終現實執行權本身。**一個 Policy Engine 可以形成 Decision，但最終讓現實狀態發生變化的 Authority 仍然需要被單獨分析。

這條最小邊界和本章前面的否定判斷並不互相替代。前者說明 Authority 在本書中至少怎樣被使用；後者說明「誰能讓這一次動作發生」不能從 Identity、Permission、Authorization、Approval、Policy 或 Capability 任意一項自動得出。兩者可以同時成立，卻不能因為有了這條最小邊界，就認為 Authority 的完整正面結構已經得到定義。

沒有完整正面結構，也不強行製造一張清單

到這裡仍然有一些問題沒有答案。最重要的一個是：**Authority 的一般正面結構究竟是什麼？**本章沒有給出一套完整答案。

知道 Authority 不能等同於 Permission、Capability、Authorization 或 Policy，並不能反過來組成一個充分定義。排除了若干錯誤答案，不代表剩下的部分自動成為正確答案。因此，本章不會把這些否定邊界反過來拼成一張「滿足這些條件就一定擁有 Authority」的檢查表。

關於 Authority 的具體形態，本書還會在不同問題中討論提議、批准、治理、仲裁、否決、執行以及其他現實約束能力。但這些具體結構並不自動組成一套已經統一完成的分類體系。它們之間哪些可以對應、哪些屬於不同觀察軸、最終是否應該統一成同一套結構，本章不提前決定。這不是為了留下一個模糊空間，而是為了避免一個更嚴重的問題：在還沒有建立充分依據時，先製造一套整齊的分類，再讓後面的理論反過來依賴這套分類。

所以第四章能夠走到的位置非常明確：**我們能夠說明 Authority 不能從什麼自動推出，也能夠說明哪些已有對象不能直接取代它。**但：Authority 的完整一般結構，本章仍然不定義。

這個邊界不會妨礙本章的核心結論。因為本章要證明的從來不是「Authority 完整是什麼」，而是：在一次具體現實執行發生之前，「誰能讓它發生」必須被作為一個獨立問題回答。

那麼，它應該由誰持有

把問題收回到本章開頭。一種很自然的理解是：Policy 已經返回 ALLOW，那麼這件事就可以發生。本章已經說明，這個推導不能成立。Policy 給出的是判斷；而判斷存在，與這個判斷能夠讓現實狀態發生或者阻止現實狀態發生，仍然是兩個不同的問題。

另一種理解是：權限已經配置清楚，誰擁有什麼能力都能夠從系統裡查出來，因此最終權力關係也已經清楚。這同樣回答不了本章的問題。Permission 描述的是主體被允許擁有什麼；Capability 描述的是主體現實中做得到什麼；Authorization 記錄資格如何形成；Approval 說明治理流程是否完成。但「這一次 Action 是否獲得現實效力」面對的是一個具體事件。這些對象即使全部成立，也不能自動成為這一問題的最終答案。

所以第四章能夠確定的是：**在一次具體現實執行發生之前，「誰能讓它發生」不能由 Identity、Permission、Authorization、Approval、Policy 判斷或 Capability 佔有中的任意一項自動回答。**它也不能簡單地被 Authorization、Capability、Policy、Governance、Veto 或 Execution Control 中任意一個已有對象吸收。

但這些否定仍然沒有告訴我們另一件事：**最終讓一次 Action 獲得現實效力的權力，應該以什麼形式存在，又應該由誰持有？**直覺很容易把這個問題重新理解成尋找一個名字：某個人、某個管理員、某個服務、某個策略引擎、某個 Runtime、某塊硬件或者某個專門組件。但本章沒有證明最終 Authority 必須擁有一個單一持有者，也沒有在這裡證明它一定不能擁有單一持有者。這個問題必須繼續保持開放。第四章只把它從其他問題下面完整地抽了出來。於是下一章要面對的，就是這個問題：

最終讓它發生的權力，一定要屬於某一個人、某一個組件或者某一個主體嗎？

本章術語

• 權威 ｜ Authority
• 身份 ｜ Identity
• 權限 ｜ Permission
• 授權 ｜ Authorization
• 審批 ｜ Approval
• 執行能力 ｜ Execution Capability
• 策略 ｜ Policy
• 治理 ｜ Governance
• 否決 ｜ Veto
• 執行控制 ｜ Execution Control

本章案例與資料來源

本章無現實案例。

正文中修改對外收款賬戶的情形屬於假設性工程場景，用於說明 Identity、Permission、Authorization、Approval、Policy 判斷與 Capability 同時成立以後，仍然可能留下一個獨立問題：**究竟是什麼，使這一次 Action 獲得現實效力？**該情形不對應具體公司、產品或現實事件，也不承擔本章理論判斷的證明作用。

資料來源

本章沒有需要單獨展開的現實事件資料。正文涉及的 Identity、Permission、Authorization、Approval、Policy、Capability、Governance、Veto、Authority 與 Execution Control，均按照本書已經建立的工程語義和邊界使用。尚未建立的 Authority 一般正面結構及不同具體結構之間的完整對應關係繼續保持開放，本章不為這些問題提前補出答案。涉及外部論文、標準、官方資料或現實事件的內容，統一列入本書附錄及全書 《參考文獻與資料來源》。

---

第五章｜最終裁決權不必屬於某一個人

本章撤掉一個自然預設：最終執行裁決權不一定要交給某一個人、組件或軟件模塊。多個彼此獨立、各自必要的約束，可以在一次具體 Action 上共同形成 Final Execution Authority；任何必要約束缺失，執行都應停止，而全部成立也只意味著繼續執行的資格可能被釋放，並不等於現實動作必然發生。裁決與實施必須分開：Adjudication 形成約束，Executor 才真正改變現實；Allow 不是執行，Deny 如果約束不到 Executor，也沒有形成真實控制。本章改變的是答案的形狀，而不是另找一個「最終負責人」；硬件、邊界或某個組件也不能因此變成新的絕對可信根。下一問隨之出現：所謂「多個獨立必要約束」裡的獨立，究竟是什麼意思？

上一章把一個問題從別的問題裡摘了出來：在一次具體動作真正改變現實之前，「誰能讓它發生」必須被單獨回答，它不能由身份、權限、授權、審批、策略判斷或能力持有中的任何一項自動回答。問題被單獨提出以後，下一步很容易沿著一個熟悉的方向繼續：既然這是一份獨立的權力，就給它找到一個明確的持有者。

問題就在「交給誰」這三個字上。它已經預設了答案的形狀：最終必須有一個持有者。那可以是一個人、一個崗位、一個服務、一個模塊，也可以是一臺設備。

這種答案形狀有很強的工程吸引力。一個明確的對象容易被寫進責任邊界、值守安排、交接文檔和接口關係裡。因此，當問題來到最終執行這一側時，繼續尋找一個明確對象作為最終持有者，是一種很自然的延伸。

設想一個很小的假設情形，只是為了把這個預設擺得具體一些：某個系統裡有一條會讓一批設備集中斷電的指令，它上游該走的環節都已經走完——意圖被記錄，審批通過，授權檢查通過，策略命中，資格校驗通過。現在要回答的是，誰來控制最後那一步。可以指定一個人，比如值班負責人；也可以指定一個組件，比如一個叫「執行網關」的服務。兩種方案討論的是不同對象，但它們共享同一個前提：最終答案應該落到某一個確定的持有者身上。

這個前提可以先從一條執行邊界上的直覺開始檢查：系統的擁有者、管理員、平臺方或其他高權限主體，不應僅憑自己的身份，就天然獲得繞過所有執行邊界的能力。高權限不等於無邊界。

這句話在這裡只用於執行邊界。它討論的是某個主體能不能憑藉自己的身份跨過邊界、讓一次動作發生；它不回答組織中誰該擁有什麼角色，也不規定審批層級、權限閾值或治理結構。本章不從這句話繼續推出這些結論。它只能排除一種簡單答案：站在系統最高位置的主體，不能僅因為位置最高，就自動成為最終執行權的持有者。

但這一步只排除了一個候選，並沒有排除「最終必須存在一個單一持有者」這個預設。把高權限主體拿掉以後，答案仍然可以繼續落到別的對象上：Policy Engine、Runtime，或者一塊專門的執行設備。只要問題仍然被理解成「那一個到底是誰」，答案的形狀就沒有改變。

最終執行裁決權不要求單一持有者

先把這一章的結論擺出來：

最終執行裁決權 = 非單一持有者的權威 FINAL EXECUTION AUTHORITY = NON-SINGLE-HOLDER AUTHORITY

這裡的意思不是最終執行裁決權一定要由很多人、很多組件或者很多系統共同持有，而是：它不要求由某一個單一主體、單一組件或單一軟件模塊獨自持有。

在一次具體 Action 上，多個彼此獨立的必要約束可以共同形成最終執行裁決權。只要其中任意一個必要約束沒有成立，這一次動作就不應繼續進入現實執行。

這個結論首先改變的是答案的形狀。過去問「最終權力應該交給誰」，很容易默認最後一定要找到一個名字：某個人、某個管理員、某個 Runtime、某個網關或者某臺設備。本章取消的是這個前提，而不是把它替換成另一個同樣僵硬的前提。

所以，「非單一持有者」不能被反過來理解成「必須由多個主體持有」。本章既不規定參與方數量，也不規定最終權威一定要表現為一個分佈式集合、一個固定結構或者某種特定組織關係。

它的作用域也落在具體 Action 上。多個必要約束共同形成的是針對這一次現實執行的裁決關係，而不是一次性形成整個系統範圍內的全局權力歸屬。

因此，本章現在能夠確定的是：最終執行裁決權不要求單一持有者。 至於這種持有關係最終應當怎樣形式化、是否應該被描述為一種結構，以及不同約束之間完整的組合關係，本章繼續保持開放。

同樣，把最終權威移到一個所謂「邊界」裡，並不能讓那個邊界自動成為新的絕對可信根。邊界本身如何建立、如何修改、由誰約束，仍然需要受到相應的執行約束。否則只是把原來的單一持有者從「人」或「組件」換成了「邊界」這個名字。

硬件也一樣。某個約束進入硬件邊界，可以改變它被軟件繞過的難度，卻不能由此推出「最終執行裁決權必須屬於硬件」。硬件可以成為約束結構的一部分，但不能僅憑自己更靠近現實執行，就自動成為新的單一最終持有者。

裁決不是實施

最終執行裁決權面對的是一次具體 Action，並對它形成具有約束力的 Allow 或 Deny 結果。這裡有一條必須始終保留的邊界：

Adjudication ≠ Execution。

Allow 的作用是釋放繼續執行的資格，而不是由裁決者親自完成現實動作；真正改變現實狀態的實施行為屬於 Executor。相應地，Deny 或 Final Veto 必須能夠阻止對應的現實執行，否則裁決雖然存在，卻沒有形成真正的執行約束。

這條邊界可以從三個典型失效方向看出來。第一，Allow 被理解成裁決者自己直接實施動作，於是「同意」和「動手」被合併成同一件事；第二，系統已經給出 Deny，但上游普通權限仍然能夠覆蓋這個結果；第三，裁決正常產生，真實 Executor 卻根本不受這一結果約束。

三種情況的共同問題都不是判斷本身是否準確，而是裁決沒有對現實實施形成它應有的約束。

因此，最終執行裁決權不要求單一持有者，並不意味著裁決與實施之間的邊界可以消失。Executor 可以具有完成現實動作的能力，卻不能僅憑這一能力自動獲得決定「這一次是否應當發生」的最終裁決資格；同樣，提議、審批、授權或 Policy 都可以參與判斷，卻不能因為自身成立就自動成為最終裁決。

最終執行裁決權規定的是它對一次 Action 形成怎樣的約束，以及這個約束必須怎樣作用於現實執行。至於這份 Authority 由什麼形態持有，是另一個問題，不能從 Adjudication 的定義裡直接推出。

一條只能給出方向的規則

多個獨立必要約束共同形成最終執行裁決權，其中真正承重的是「必要」二字。必要意味著少掉任何一項，成立條件就已經不完整，因此這裡能夠確定的是一個停止方向：

任何必要約束不滿足，執行都應停止。

但這條規則不能被反過來寫成「所有必要條件滿足，動作就一定執行」。即使所有必要約束都已經成立，得到的仍然只是繼續執行的資格被釋放，Allow 不是現實動作本身，Executor 是否真正實施仍然屬於後續的現實執行。

因此，這裡存在一個天然的不對稱：必要條件缺失，可以直接得到停止一側的判斷；必要條件全部成立，卻不能據此推出現實動作必然發生。

這裡所說的「關鍵約束」也不是通常意義上的「比較重要的約束」。它指的是某個成立關係中不可缺少的必要約束，而不是按照重要程度排在前面的若干條件。前者討論缺少之後關係還能不能成立，後者只是程度判斷。

這條規則還有一個層位問題需要保留。它既可以被理解為仲裁過程應當遵守的原則，也可以被理解為最終執行裁決權成立時必須滿足的條件。本章還不能確定它最終應該固定在哪一層，而這個差異會影響規則由什麼對象實現、在哪裡檢查，以及失效以後應該從哪一層尋找原因。

所以現在能夠固定的是規則的方向，而不是它在完整工程結構中的最終歸屬：少一個必要約束，執行就應停止；全部必要約束成立，也只意味著繼續執行的資格可能被釋放。

換掉的是答案的形狀

回到這一章最開始的問題：最終讓一次動作發生的權力，應該交給誰？

如果答案必須擁有一個單一持有者，那麼接下來的工作只是尋找那個名字：一個人、一個服務、一個 Runtime、一臺設備，或者一個專門的執行邊界。本章撤掉的正是這個前提。最終執行裁決權不要求預先落在某一個唯一持有者身上，多個獨立的必要約束可以在同一次具體 Action 上共同形成這份 Authority。

這意味著我們得到的不是另一個「最終負責人」的名字，而是一種不同的權力關係。每一項必要約束都必須成立，缺少其中任何一項，動作都不應繼續；全部成立時，也只是滿足繼續執行所需要的條件，而不是現實動作已經因此發生。

開頭那個集中斷電的假設情形，到這裡也可以重新理解。問題不再只是「值班負責人還是執行網關」，因為無論選哪一個，只要默認最終必須從中找出唯一持有者，答案的基本形狀都沒有改變。本章沒有在兩者之間挑出一個更好的對象，而是取消了「最後必須找到那一個」的要求。

同樣，把最終權威改叫「邊界」，或者把最後一個控制位置搬進硬件，也不會因此自動解決問題。邊界不能成為新的絕對可信對象，硬件也不能因為更靠近現實執行，就自然獲得不受其他約束的最終地位。改變承載對象，並不等於改變單一持有者這個假設本身。

但新的問題也隨之出現。本章一直使用「多個獨立必要約束」這個表述，其中「必要」已經得到了最小解釋：少掉任何一項，執行都應停止。真正還沒有回答的是「獨立」。

兩條約束由不同的人負責，就算獨立嗎？運行在不同服務裡、經過不同審批、使用不同密鑰或者不同簽名，就已經構成 Authority Decomposition 嗎？

**「獨立」究竟意味著什麼？增加參與方數量，是否就等於分解？**這是下一章的問題。

本章術語

• 最終執行裁決權 ｜ Final Execution Authority
• 權威 ｜ Authority
• 非單一持有者權威 ｜ Non-Single-Holder Authority
• 裁決 ｜ Adjudication
• 執行 ｜ Execution
• 執行者 ｜ Executor
• 最終否決 ｜ Final Veto
• 權威分解 ｜ Authority Decomposition
• 執行邊界 ｜ Execution Boundary

本章案例與資料來源

本章無現實案例。

正文使用一處假設性工程場景：一條可能使一批設備集中斷電的指令已經完成上游意圖記錄、審批、授權檢查、策略判斷與資格校驗，此時繼續追問最終執行裁決權應當由誰持有。

場景中的「值班負責人」和「執行網關」只是兩種候選答案，用於說明「最終必須存在一個單一持有者」本身也是需要被檢驗的前提。該場景不對應特定公司、產品、事故或公開事件，也不承擔本章理論判斷的證明作用。

資料來源

本章沒有需要單獨展開的現實事件資料。正文關於 Final Execution Authority、Adjudication、Executor、Final Veto、Authority Decomposition 與 Execution Boundary，均按照本書已經建立的工程語義和邊界使用。

關於「任何必要約束不滿足，執行都應停止」這一規則，本章只確定其方向，不確定其最終應歸屬於仲裁過程還是最終執行裁決權的成立條件；這一層位關係繼續保持開放。

涉及外部論文、標準、官方資料或現實事件的內容，統一列入本書附錄及全書 《參考文獻與資料來源》。

---

第六章｜多加幾個人不等於分權

本章拆掉「參與者越多，權力就越分散」的直覺。多人審批、更多簽名、服務、安全層或鑰匙份額，都只能證明數量增加，不能證明 Authority 已被分解。判斷 Authority Decomposition，必須回到具體受保護 Action 和已聲明的 Threat Model：允許失陷的主體集合，是否仍能獨立閉合從意圖到現實改變的因果鏈。這條判據只能用於排除，不能反過來當作完整定義。真正需要分開的，是性質不同、不能自動繼承、替代或覆蓋的 Authority，而不是同一種能力的多份副本。Macondo 在本章只提供壓力測試，說明多方參與和職責分離，不等於執行權已經結構性分解。下一步的問題因此不是還要增加多少人，而是這些看起來分開的 Authority，什麼時候才算真的獨立？

上一章留下了一個重要結論：讓一次動作最終進入現實執行的裁決權，不要求由某一個人、某一個組件或某一個軟件模塊單獨持有；它可以由若干條彼此獨立、各自必要的約束，在一個具體動作上共同形成。其中任何一條關鍵約束不滿足，執行就應當停止。

這個結論很容易被進一步理解成一個數量問題。既然權力可以由多條約束共同形成，那麼似乎可以繼續增加約束：多一個審批人，多一道複核，把服務拆得更細，把密鑰分成更多份，或者再增加一層安全控制。這樣做有一個很直觀的特點：數量可以被清點。審批有幾級、簽名有幾個、服務拆成多少個、控制疊了多少層，都可以直接寫進流程文件和架構圖。

但數量增加和權力結構改變並不是同一個問題。三個人參與一次審批，首先說明有三個人參與；三個服務共同出現在一條調用鏈上，首先說明系統裡有三個服務。僅從這些數字本身，還看不出它們之間是否形成了彼此不能自動替代、繼承或覆蓋的權威邊界。

這也是本章真正要檢查的問題：

多加幾個審批、幾個簽名、幾層服務、幾個微服務，是否就等於權力被分解了？

答案是否定的。但這裡的否定不是為了先給出另一套「正確數量」，而是要先把一件事分清楚：權威分解的成立與否，不能由參與方數量直接判斷。

一條只能反著說的判據

圍繞權威分解，可以先保留這樣一條判斷：

Authority Decomposition 的成立與否，不由參與方數量、審批環節數、安全層數、服務數或部署拓撲決定；判據是：在已聲明的威脅模型下，允許失陷的主體集合能否獨立閉合從意圖到現實改變的因果鏈。

理解這句話時，有四條邊界必須同時保留。

第一，它是一個否定式判據。它告訴我們什麼不足以證明權威已經被分解，並沒有反過來定義「什麼就是權威分解」。因此，不能把它改寫成：

只要允許失陷的主體集合無法獨立閉合因果鏈，權威分解就成立。

後一句比原判斷多走了一步。原判斷可以排除某些結構，卻不能僅憑這一條就授予一個結構「已經完成權威分解」的結論。

第二，判據中的「已聲明的威脅模型」是一個前置輸入。本章使用它，但不在這裡定義威脅模型應該是什麼，也不展開哪些主體應當被允許失陷、失陷如何組合或攻擊路徑如何形成。這裡需要的只是：在進行結構判斷以前，系統已經聲明瞭自己所採用的威脅模型。

第三，這條判據不能替代 Authority 與 Authority Decomposition 本身。它是用來檢查某類分解主張的結構性條件，不是對權威或權威分解概念的重新定義。

第四，這條判據目前也不能被擴寫成一套完整的形式定義、公式或充分條件。它的作用邊界仍然是判斷與排除，而不是由它單獨構造出一套完整的權威分解理論。

所以這裡的否定式不是一句等待被「補完整」的話。把它強行補成正面定義，反而會讓它承擔超出自身範圍的結論。

它能排除，不能授予。

威脅模型在這一章裡是什麼

本章會反覆使用「已聲明的威脅模型」和「允許失陷的主體集合」這兩個表述。它們不能從前面的判據中拿掉，因為這條判據本身就是在一個已經明確的威脅模型下進行結構判斷。

但本章並不負責定義威脅模型。這裡把它當作一個已經聲明好的輸入參數：系統先說明自己準備在什麼失陷假設下接受檢驗，然後再檢查，在這樣的假設成立時，某個主體集合是否能夠獨立閉合從意圖到現實改變的因果鏈。

因此，讀者在這裡不需要先掌握一整套關於威脅模型的理論。只需要接受一個前提：威脅模型已經被聲明，而本章在這個前提下討論權威結構。

這也限定了本章能夠回答的問題。給定一個已經聲明的威脅模型，我們可以檢查一個看似由多個主體、服務或控制組成的結構，是否仍然允許其中某個被允許失陷的主體集合獨立閉合整條因果鏈。這樣的檢查可以排除一些只有數量變化、卻沒有形成有效結構約束的安排，但它本身仍然不能反過來充當權威分解的完整正面定義。

與這個結構判斷無關的問題，本章不展開：威脅模型具體應該怎樣定義，哪些主體應當被允許失陷，攻擊者有哪些類型，不同失陷如何組合，局部失陷與協同失陷如何分類，攻擊路徑如何演化，殘餘風險如何定義，以及什麼情況下構成終局失效。這裡使用這些詞，只為了完成當前的結構判斷，不由它們繼續建立另一套對抗模型。

威脅模型之所以不能省略，是因為結構本身沒有改變，並不代表測試結果不會改變。假設條件發生變化，需要重新檢查的，是被允許失陷的主體集合是否能夠獨立閉合那條因果鏈。也正因為如此，單獨問「這個系統是不是分權的」還不夠完整：必須同時說明，它是在什麼威脅模型、針對什麼受保護動作下接受判斷。

被拆開的是什麼

沿著前面的判據繼續往下看，權威分解至少要守住一個目標：不能讓任何一個被允許失陷的單一主體，獨自完成從意圖產生到現實改變的完整因果鏈。

圍繞這個目標，有三個特徵不能省略。

首先，被拆開的必須是性質不同的 Authority，而不是同一種能力的若干份額。

其次，拆分必須落在結構上，而不能只發生在流程名稱和組織關係上。憑證、Runtime、Policy 來源、執行域，都可以成為觀察這種結構差異的位置，但這幾個對象不是一份部署清單，也不能從這裡直接推出某一種固定的系統架構。這裡真正關心的是：原有控制關係有沒有被改變。重畫組織圖、增加角色名稱或者重新分配職責，都可以在系統控制路徑不發生變化的情況下完成；結構性的分離則必須觸及權威實際如何到達執行。

第三，需要繼續檢查：單一主體的失陷，是否仍然足以完成整條執行鏈。 如果答案仍然是肯定的，那麼參與者數量已經增加這件事，本身並沒有解決這一問題。

第一點直接解釋了本章標題。把一件事交給三個人，如果三個人持有的是同一種 Authority，並且在同一條鏈上重複同一種判斷，那麼增加的是參與人數和操作份額，不是 Authority 的種類。三份同類份額加在一起，仍然是同一種權威。

可以設想一個純屬假設的安排。某次對外動作必須由三個人依次點擊「同意」，三個人來自不同部門，彼此也沒有隸屬關係。從流程上看，這是三次分別參與。

但如果三個人看到的是同一份摘要，依賴的是同一個狀態來源，最終觸發的也是同一條控制路徑，那麼部門不同、人數不同，並沒有自動形成三個獨立的 Authority。一旦共同依賴的那一處進入當前威脅模型允許失陷的範圍，這三次判斷就可能一起受到影響。

這個假設場景不用於證明分解判據，它只是說明一件事：把同一種能力分成多份，與把不同性質的權威真正分開，是兩個問題。

實際檢查時，可以先問三個問題：

控制面是否獨立？ 密鑰材料是否獨立？ 是否具備獨立的否決能力？

這三個問題有工程價值，但它們不是一份充分條件清單。即使三個答案都是「是」，也不能因此直接宣佈權威分解已經成立。否則只是把原來的「人數夠不夠」換成了「檢查項夠不夠」，仍然是在用可數項目代替結構判斷。

還有一個邊界需要先留下：獨立性是有方向的。A 相對 B 獨立，並不自動意味著 B 相對 A 也獨立。

這一點在本章只到這裡。至於「獨立」究竟由什麼構成，下一章再處理。

八樣不是分解的東西

沿著前面的判斷繼續排除，有八種安排不能僅因為它們看起來「更分散」，就被直接視為權威分解：多人審批、微服務拆分、組織職責分離、簡單多數表決、名義多籤、安全層數、門限授權、把一把鑰匙切成三把。

這八項的結論都是「不等於」，但它們不是一份窮盡的分類。知道這八樣不等於分解，並不能反過來推出某個沒有出現在這裡的第九種做法就一定構成分解。**補集不構成定義。**它們也不適合被理解成八個彼此平行、互斥的類別，因為其中有些只是同一個問題的不同表現。

多人審批、簡單多數表決、名義多籤、門限授權以及把一把鑰匙切成三把，就有一個共同點：它們首先改變的是同一種能力被分成多少份，以及需要湊齊多少份才能使用。

多人審批把批准動作交給多個人；簡單多數按照相同表決權計數；名義多籤與門限授權要求若干份憑證共同滿足條件；把一把鑰匙切成三把，則更直接地把同一種能力拆成多個份額。這些安排完全可能增加完成一次操作的難度，也可能提高單點直接完成操作的門檻，但提高湊齊難度，不等於改變權威結構本身。

可以繼續沿用前面的比喻：不管一把鑰匙被切成多少片，只要這些片段最終共同恢復的仍然是打開同一扇門的能力，被增加的是取得這項能力的條件，而不是另一種性質不同的 Authority。

因此，門限授權尤其不能因為存在多個參與份額，就直接被重新解釋成權威分解。它和多人審批在這裡面對的是同一個問題：把同一種能力分給更多主體，與把性質不同、不能自動替代的 Authority 分開，並不是一回事。

組織職責分離處理的是另一層問題。職責說明、彙報關係和組織圖可以明確誰負責什麼、誰對什麼結果承擔責任，但這些安排本身不能回答一個執行結構問題：在動作真正進入現實以前，誰仍然可以被繞過，誰不能被繞過？

前一個問題可以寫在制度和職責文件裡，後一個問題必須由系統裡的實際控制關係回答。職責劃分本身並不保證這兩種結構一致，因此組織職責分離不能直接等同於 Authority Decomposition。

微服務拆分與安全層數則主要改變部署和控制鏈的外觀。系統可以增加進程、服務、網絡分段和控制層，但這些數字本身仍然不能說明某個主體是否能夠獨立閉合從意圖到現實改變的因果鏈。服務拆得更多，也不必然形成更多彼此獨立的權威；調用路徑更長，同樣不能據此判斷權威已經被分開。

安全層數也是如此。如果幾層控制最終依賴同一個可覆蓋的身份、同一個狀態來源，或者同一條能夠繞過其他約束的執行路徑，那麼「有幾層」並沒有回答這些層之間是否真正形成獨立邊界。

這與權威分解本身的正式概念是一致的。權威分解討論的是：圍繞現實執行，把不同 Authority 放入不能自動繼承、替代或覆蓋的獨立邊界中。只要不同角色仍然共享一個可覆蓋的控制根，或者其中一種 Authority 能夠無條件繼承、替代、關閉另一種 Authority，結構上的分解就已經出現問題。

執行權分離把這個判斷進一步落到執行鏈上：分離不能只存在於名稱、角色、模塊或進程裡。如果它們最終仍然共享同一個可以覆蓋全局的身份、更新、恢復或執行路徑，那麼外表上的「多個」並沒有改變控制根。

所以這一節真正排除的不是某八種技術，而是一種判斷方法：

不能通過數人數、數簽名、數服務、數層級或者數鑰匙份額，來判斷權威分解是否成立。

這個系統是不是分權的，是一個問錯的問題

討論權威分解時，還有一個值得保留的觀察角度：執行門檻（Execution Threshold）。它問的是：

攻擊者最少需要控制哪些 Authority，才能完成一次受保護執行？

這個問題有一個很重要的限定：執行門檻相對於某一次具體的受保護動作定義，而不是整個系統的全局屬性。

執行門檻在這裡仍然只是一個受限的觀察角度，不能被直接擴寫成公式、評分表、風險等級或已經成熟的工程度量。它的價值，是把一個過於寬泛的問題——「這個系統是不是分權的」——收縮到一次具體受保護 Action 上。

同一個系統裡的不同動作，可能經過完全不同的 Authority、控制路徑和執行邊界，因此針對一個動作建立的約束結構不能自動推廣到另一個動作。真正需要指定的是：我們正在保護哪一次 Action，以及為了讓它最終發生，需要控制哪些 Authority。

於是，比「這個系統是不是分權的」更有意義的問題是：

對於這一次受保護動作，攻擊者最少需要控制哪些 Authority，才能完成這次執行？

這個問法給出了一個可以檢查的結構對象，但本章不把 Execution Threshold 進一步定義成一把已經校準好的量尺，也不據此建立所謂的「分權等級」。

這裡出現了「攻擊者」，但本章不繼續展開攻擊者本身。攻擊者有哪些類型、具有什麼能力、通過什麼路徑行動，以及不同失陷怎樣組合，都不是這裡要解決的問題。本章只使用「最少需要控制哪些 Authority」這一結構性問題。

它也不能被用來衡量動作發生以後會造成多大後果。一個動作需要跨越多少 Authority，與動作最終造成多大的影響，是兩個不同的問題。後果範圍可以解釋為什麼我們關心權威分解，但本章不建立災難半徑的計算方法，也不由此推出風險分級。

分解不是越多越好

前面已經說明，參與方數量、審批數量、服務數量和安全層數，都不能直接作為權威分解是否成立的判據。但這個結論不能反過來變成另一條數量規則：既然「多」本身不代表分解，就把結構繼續拆得更多、更細，認為分解程度越高就一定越安全。

這裡至少有三個限制需要同時看到。

分解到一定程度以後，邊際收益會開始轉為負值。繼續增加分解，並不自動帶來等比例的安全收益。

同時，集中本身並不等於不安全。一個集中的結構是否可以接受，仍然取決於已經聲明的威脅模型。前面反對的是用「數量更多」證明安全，這裡同樣不能用「數量更少」直接證明不安全。

執行預算（Execution Budget）提供了另一個容易被忽略的例子。限制一個主體在一定條件下能夠執行多少，可以降低「權限過大」帶來的部分風險；但預算本身必須依據某些狀態來計算和判斷。這樣一來，一部分風險會轉移到狀態源是否可信。原來的風險被壓低，並不意味著風險消失，它可能只是換了一個承重點。

因此，本章討論的不是「應該更集中」還是「應該更分散」。這兩個方向如果都只看數量，方法上沒有區別。要判斷一個結構是否真正改變了執行權威關係，仍然必須回到具體 Action、已聲明的威脅模型，以及那條從意圖到現實改變的因果鏈上。

權威分解本身也不承諾兩個結果：它不承諾所有組件都不會失敗，也不承諾主體失陷以後一定不會造成損害。

在可用性與正確性發生衝突時，本章保留一條執行原則：

寧可執行不發生，也不接受未被證明成立的執行發生。

這句話在本章只說明權威分解所選擇的執行方向。至於當信息缺失、衝突或無法證明時，系統應如何形成完整的安全失敗語義，本章不繼續展開。

紙面上什麼都不缺

到這裡，仍然容易出現一種誤讀：既然人數、審批和組織層級本身不能證明權威已經被分解，那麼問題是不是隻在於審批設計不夠好，或者職責劃分不夠清楚？

Macondo 井事故提供了一個現實中的壓力點。2010 年 4 月 20 日，這條作業鏈涉及三類組織角色：作業者、平臺的所有與運營方，以及固井承包商。參與方不止一個，審查也不止一道，合同和職責劃分中已經存在明確的組織分工。也就是說，僅從紙面上的參與方數量和職責結構來看，它並不是一個「只有一個人在做決定」的簡單系統。

但這並沒有自動建立執行結構中所需要的關係。關於負壓測試，有兩項已經核實的事實尤其重要：當時不存在指導該測試實施與解釋的法規或行業標準；與此同時，平臺運營方主張，其人員不負責解釋該測試，也不負責作出「井已安全、作業可以繼續」的判斷。

這兩項事實能夠支持的結論必須停在這裡：**紙面上的職責分離已經存在，但這並不足以證明，與這一具體判斷有關的權威關係已經被建立。**這也不能進一步推出結構中天然存在一個固定的「空位」，更不能據此判斷最終否決權應該屬於誰。

從執行結構看，本案還出現了「觸發」與「達成」之間的失效，以及「最上層的拒絕沒有歸屬」這一現象。本章只把它作為觀察對象使用，不從這裡建立否決權持有者的結論。

因此，這個案例在本章的角色只是壓力測試，不是證明。它不能證明本章關於權威分解的判斷，也不能讓前面的判據因為有了一個現實事故就獲得更高的證明強度。一個案例能夠讓問題變得具體，卻不能替代理論本身。

還有一項常見說法需要排除：「雙方各自以為對方負責制定規程」。現有一級來源並沒有為這句話提供逐字支持，因此本章不用它來解釋事故。圍繞這一事故還有一些常被一併引用的周邊事實，目前也沒有被核實到同一等級的來源，因此不進入本章論證。

本章也不借這個案例展開攻擊者類型、主體失陷組合或跨組織攻擊路徑，不根據事故後果大小來增加論證強度，也不由「拒絕沒有歸屬」推導誰應該擁有最終否決權。

它在這裡真正承擔的作用只有一個：**參與方很多、職責已經被分開，與執行鏈上的 Authority 是否真正形成結構性分解，是兩個不同的問題。**紙面上的分離可以成立，卻不能單憑這一點回答某個被允許失陷的主體集合是否能夠獨立閉合從意圖到現實改變的因果鏈。

留在外面的三件事，和一條被打開的線

到這裡，還有三個問題需要明確保持開放。

第一，Execution Threshold 還不是一項完整的工程度量。 本章可以用「攻擊者最少需要控制哪些 Authority，才能完成一次受保護執行」來觀察某個具體 Action 的權威結構，但還不能進一步給出統一公式、評分方法或閾值。因此，Execution Threshold 在這裡是一個結構性問題，而不是一項已經完成標準化的指標。

第二，Blast Radius 還沒有形成統一的度量和風險分級方法。 災難半徑討論的是一次錯誤、失陷或不受約束的執行可能把現實影響擴展到什麼範圍，但本章不能因此為某個 Action 計算一個統一的 Blast Radius 分數，也不能規定達到什麼數值就屬於高風險或者可以接受。

第三，影響 Blast Radius 的各個維度還沒有被組織成完整的形式關係。 動作作用域、可逆性、速率、持續時間、權力集中程度和傳播路徑等因素都會影響現實後果，但這些因素怎樣組合、彼此如何作用，以及最終怎樣形成一個可以比較的度量結果，本章不回答。

後兩項雖然都與 Blast Radius 有關，卻不是同一個問題。即使未來能夠清楚定義每一個影響因素，也不意味著統一的風險分級方法會自然出現；反過來，即使形成某種實用度量，也不能因此假定所有底層因素之間的關係已經完成形式化。

這些問題保持開放，並不影響本章已經建立的否定式結論。它們只是限定了當前理論能夠向前走到哪裡。

除此之外，前面的判據還打開了另一條問題線。我們一直假定威脅模型已經聲明，並在這個前提下檢查「允許失陷的主體集合」是否能夠獨立閉合從意圖到現實改變的因果鏈。但只要這個集合能夠被配置，就必須繼續追問：

誰能夠決定或者修改這些邊界？

威脅模型、主體集合以及相關配置並不是天然不可改變的。如果一個主體既能夠改變這些約束，又能夠利用這種修改放寬自身的執行邊界，那麼修改邊界本身就進入了 Authority 問題。

本章不回答這種配置權最終應該屬於誰，也不繼續建立一套配置治理模型。這裡只保留一條邊界：約束可以被修改，因此修改約束的 Authority 本身也需要接受執行控制。

本章術語

• 權威 ｜ Authority
• 權威分解 ｜ Authority Decomposition
• 執行權分離 ｜ Execution Authority Separation
• 執行門檻 ｜ Execution Threshold
• 威脅模型 ｜ Threat Model
• 執行預算 ｜ Execution Budget
• 災難半徑 ｜ Blast Radius

本章案例與資料來源

Macondo 井事故｜2010 年 4 月 20 日

本章使用 Macondo 井事故作為壓力測試案例，用於檢查一個具體問題：當一條執行鏈已經存在多個參與方、多個審查環節和明確的組織職責分工時，這些「數量上的多個」是否足以說明權威已經形成結構性分解。

案例涉及三類組織角色：作業者、平臺的所有與運營方，以及固井承包商。正文不展開完整事故時間線，也不以事故後果規模作為理論結論的證據。

本章使用兩項已經核實到位的事實：

• 當時不存在用於指導負壓測試實施與解釋的法規或行業標準。
• 平臺運營方主張，其人員不負責解釋該測試，也不負責作出「井已安全、作業可以繼續」的判斷。

這兩項事實只用於說明：紙面上的參與方數量和職責分離，與一次具體判斷所需要的執行關係是否已經建立，是兩個不同的問題。

本案例不用於證明權威分解的定義，也不用於證明本章提出的結構判據。它不能據此確定最終否決權應該由誰持有，也不用於展開威脅模型、主體失陷組合、跨組織攻擊路徑或災難半徑的度量。

一項常見表述——「雙方各自以為對方負責制定規程」——目前沒有獲得一級來源的直接支持，因此本章不採用這一說法。圍繞該事故還有若干尚未核實到同一證據等級的周邊事實，也不進入本章論證。

資料來源

本章圍繞參與方數量與 Authority Decomposition 的關係、同一種能力份額與不同性質 Authority 的區別、Execution Threshold 相對於具體受保護 Action 的作用範圍，以及權威分解的成本與邊界展開。

Execution Threshold 在本章只作為面向具體 Action 的結構性觀察角度使用，不被擴展為公式、評分體系或成熟的工程度量。

Blast Radius 用於描述錯誤、失陷或不受約束執行可能造成的現實影響範圍。本章不建立統一的災難半徑度量、風險分級方法，也不提前定義各影響因素之間的完整形式關係。

Macondo 井事故的完整事實背景、官方資料、證據邊界及來源說明，統一收入附錄 《現實失敗與邊界案例》；其他外部論文、標準和資料統一列入全書 《參考文獻與資料來源》。

---

第七章｜分開放著，不等於真的分開

本章把「分開放著」與「真正獨立」分開。兩個控制位於不同進程、服務、節點、機房或團隊，只能證明名義上分開，不能推出失敗來源已經獨立。真正要檢查的是：當其中一邊失陷時，另一邊是否仍保有獨立否決能力；如果兩邊共享身份、權限、更新、恢復、通信或其他共同控制根，部署圖上的兩個框仍可能一起失效。一個更直接的判斷是：如果某個上限可以被受它約束的主體自己調高、關閉或改寫，它就不能僅憑存在被視為獨立執行邊界。切爾諾貝利案例只用於暴露這種結構差異，不證明完整理論。本章最終保留的是一條否定邊界：名義獨立不能證明失敗來源獨立，而後者究竟由什麼充分構成，仍沒有完整正面定義。下一問因此落到執行判斷本身：一條邊界究竟拿什麼作為參照？

上一章停在一個否定上：審批的人更多、環節更長、服務拆得更細、安全層疊得更高、部署的節點更分散，都不足以推出權力已經被分解。數量不是分解。

把數量排除以後，另一個很自然的判斷會出現：既然數量不能說明問題，那麼位置總該可以。兩個控制如果根本不在同一個地方——一個運行在這臺機器上，一個運行在另一臺機器上；一個屬於這個服務，一個屬於另一個服務；一個是主副本，一個是異地副本——至少從部署結構上看，它們已經明確分開了。

這種分開很容易被觀察和記錄。部署圖上可以畫出兩個框，配置可以由兩個團隊分別維護，兩個節點甚至可以位於不同的機房。所有這些都能夠證明一件事：它們在部署上沒有放在一起。

但這還沒有回答另一件事：當其中一邊出現問題時，另一邊會不會因為同一個原因一起失效。

這正是本章標題裡兩個「分開」之間的距離。前一個可以從進程、節點、服務和部署位置上直接看到；後一個不能只靠這些外觀得到。把一個服務繼續拆成更多進程、更多節點或更多副本，會增加可以觀察到的分離，卻不會自動回答這些控制是否仍然共享同一個失敗來源。

所以這一章要把這個問題單獨拿出來：

兩個控制分處不同進程、節點、副本或服務，是否就構成兩個獨立的執行邊界？

一個只能反著說的判斷

圍繞「獨立」這個問題，本章先建立一條否定判斷：

名義上的獨立，不蘊含失敗來源上的獨立（nominal independence does not imply failure-source independence）。

這句話的形式本身就是結論的一部分。它沒有回答「獨立由什麼構成」，只說明瞭一件事：名義上的分開，本身不足以證明失敗來源已經獨立。

這裡的「名義」不帶貶義。它指的是能夠從命名、部署圖、組織關係或者架構描述裡直接觀察到的分開，例如兩個進程、兩個服務、兩個團隊、兩套代碼庫或者兩家供應商。這些差異都可以真實存在。

失敗來源上的獨立問的是另一個問題：當其中一處出現問題時，兩個控制是否可能因為同一個來源而同時失去作用。部署圖可以告訴我們系統被怎樣拆開，卻不能僅憑這些框和連線回答這個問題。要檢查的方向恰好相反：不是繼續數已經拆出了多少部分，而是沿著兩邊實際依賴的關係往回找，看它們是否仍然匯聚到某個能夠同時影響兩邊的來源。

案例可以幫助觀察這種結構，但不能因此把這條否定判斷擴展成獨立性的完整定義。

因此：

從「名義上已經分開」，不能推出「失敗來源已經獨立」。

它也不能反過來告訴我們，滿足哪些條件就一定構成真正的獨立。

這條判斷也不能被反向改寫成：

凡是名義上分開的控制，都不獨立。

這個結論同樣沒有依據。兩個控制位於不同機房，可能確實具有不同的失敗來源，也可能仍然共享某個關鍵依賴。僅憑「分處兩個機房」這個事實，兩種結論都不能得到。

在沒有完整正面定義的情況下，仍然可以從反方向進行檢查。可以先假設其中一個控制已經失去可信性，再追問另一個是否會因為同一條依賴關係同時受到影響。只要能夠找到一條足以同時取消兩邊約束的共同連接，就足以否掉這一次名義上的獨立；如果沒有找到，也只能說明當前檢查沒有發現這樣的連接，不能據此證明獨立已經成立。

所以這條判斷的使用方向始終只有一個：

它能證偽，不能證成。

名義上的分開容易被觀察，是因為這些分離通常會直接體現在部署、配置和文檔中。把兩個控制聯繫起來的共同依賴卻未必以同樣的形式出現，它可能來自身份、更新、恢復、通信或者其他共享關係。能夠看見兩邊分別存在，並不能替代對這些共同來源的檢查。

為什麼必須停在否定式上，原因並不複雜：本章能夠判斷一些結構為什麼不能證明獨立，卻還不能給出一套完整的「獨立性由什麼保證」的充分條件。

身份、權限、更新、恢復、通信以及其他共享關係，都可以暴露兩個控制之間可能存在的共同失敗來源。但找到這些失敗形態，不等於反過來就能得到一份完整的獨立性構成清單。

因此，本章不會把已經觀察到的共享關係直接排列成一套充分條件，也不會聲稱只要逐項排除這些關係，獨立性就一定成立。

這個邊界必須保留：

名義上的獨立不能證明失敗來源上的獨立；而失敗來源上的獨立究竟由什麼充分構成，本章不給出完整的正面定義。

可以被自己調高的上限

只能反著說，並不意味著什麼都不能判斷。沿著前面的方向，還可以保留一條更嚴格的判據：

兩個控制只有在其中一個失陷時，另一個仍然保有獨立否決能力，才構成執行意義上的兩個 Authority。

這裡的「失陷」只作為一個判斷條件使用。它不是在描述一次具體攻擊，也不是在展開一種威脅場景。可以把它理解成一個假設：如果其中一個控制已經不再可信，另一個是否仍然能夠保留自己的否決能力。

本章只把問題問到這裡。失陷如何發生、哪些部分可能同時失陷、不同失陷如何組合，以及失陷以後系統還剩下哪些保證，都不在這裡展開。

這條判據還有一個更容易直接拿去檢查系統的表達：

一個上限如果可以被受其約束的主體自己調高，它就不是執行邊界，而是一條默認配置。

它把「是否獨立」這個抽象問題，變成了一個可以對具體控制逐項追問的問題。速率上限、額度上限、併發上限、單筆金額上限、可調用的工具範圍、可觸達的目標集合，都可以問同一句：

誰能夠把這個限制放寬？

如果答案包含了正在被它約束的那一側，那麼這項限制即使真實存在，也不能僅憑它的存在被視為一條執行邊界。因為在真正需要約束生效的時候，被約束者仍然能夠改變約束本身。

這裡的「調高」也不能只理解成把一個數字改大。改變由誰判斷是否超限，可以產生同樣的問題；改變這項檢查是否啟用，同樣可以讓原來的限制失去作用。數字可能沒有變化，判斷邏輯也可能沒有變化，但約束已經不再生效。

所以真正需要檢查的不是配置文件裡有沒有這一項，而是它的生效狀態最終受誰控制。

這條判據仍然只能用於排除。一個上限不能被被約束的一側調高，並不足以反過來證明它已經構成一條獨立執行邊界。前一節留下的限制仍然有效：本章沒有一套完整的正面定義，可以據此宣佈「滿足這些條件，獨立就成立」。

因此，「誰能把它調高」這個問題可以很快排除一部分看起來像邊界的限制；至於剩下的限制是否真正構成獨立邊界，還需要繼續判斷。

一種軟化回答是：「能改，但要走審批。」但審批並沒有結束這個問題，它只是讓追問繼續向上一層移動。接下來仍然要問：誰能夠讓這次修改生效？誰能夠改變審批本身的生效條件？如果最終控制這項約束是否生效的能力仍然落在被約束的一側，那麼增加一道手續，並沒有改變這條判據的結論。

這裡也必須區分結構條件和權限管理建議。

這條判據並不是在說「不要給執行側修改配置的權限」。它檢查的是：一項本來聲稱能夠約束某個主體的限制，其有效性是否仍然依賴那個主體自己維持。

只要被約束的一側仍然能夠使這項限制失去約束力，那麼無論它是否打算這樣做、修改前是否需要經過手續，這項限制都不能僅憑現有形態被視為獨立的執行邊界。

接下來的案例會把這一區別落到一個具體事件中：問題不只是有沒有違反規則，而是約束本身是否能夠由它原本要約束的一側合法地失去作用。

程序上完全合規，而邊界並不存在

1986 年 4 月 26 日切爾諾貝利 4 號機組的事故，在這一章裡只承擔一個具體作用：把「約束的生效狀態由被約束的一側持有」這件事，從抽象判據落到一個真實事件中。這裡不展開反應堆物理，不復述完整事故時間線，也不試圖重新解釋事故最終由什麼造成。

IAEA 國際核安全諮詢組 1992 年的正式報告，對若干「違規」認定作出了更正：應急堆芯冷卻系統的關閉並不被禁止，並且已獲批准；蒸汽分離筒水位跳閘的停用並未發生——這是報告對其早先版本的修訂；兩臺汽輪機跳閘的停用為常規程序所要求。

這三項認定需要放在一起看，因為它們呈現出的並不是一個簡單的「違反規則，所以防護失效」結構。至少在這三項上，約束失去作用並不以違反程序為前提。某些防護可以在既有程序允許的範圍內被關閉或失去作用，而執行這一改變的一側，正是原本受到這些約束限制的一側。

這與上一節的判據直接相連。一個控制即使明確存在於設計、文檔和系統結構中，也還需要繼續追問：決定它是否生效的能力掌握在誰手裡？

如果受約束的一側本身能夠讓這項約束失去作用，那麼部署圖沒有變化、控制層數沒有變化，甚至規則文本也可以沒有變化，但這條約束在關鍵時刻已經不再形成獨立限制。

這就是名義分開與失敗來源獨立之間的差別。兩層控制可以同時出現在結構圖上，卻仍然共享一個能夠讓其中一層失效的控制來源。圖上看見的是兩層，真正需要檢查的是其中一層能不能被另一側合法地取消。

「合規」在這個案例裡因此出現了一種值得警惕的情形。通常我們會把違規視為防護失效的入口，於是事後的改進自然指向更嚴格的規則、更嚴密的監督和更高的違規成本。

但在上述三項認定中，問題並不是有人必須先違反規則，約束才會失去作用。在這三項上，並不存在需要先通過違規才能完成的那一步。於是僅僅繼續強化「不要違規」，並不能回答這裡暴露出來的問題。

需要重新檢查的是：那個能夠讓約束停止生效的開關，究竟由誰控制。

這個案例在本章中的作用是暴露機制，不提供證明。它不能證明本章關於獨立性的核心判斷，也不能因為現實事件與判據相符，就把前面的否定式升級成一套完整的正面定義。

同時，這起事故不能被壓縮成任何一個單一原因。不能把它簡單歸結為「操作員違規」，也不能反過來歸結為「設計缺陷」。INSAG-7 對事故最終觸發過程本身仍保留不確定性，本章不會利用這一個案例重新建立一條確定的事故因果鏈。

這一案例的使用邊界必須和案例本身一起保留。本章只使用 INSAG-7 中與當前問題直接相關的三項認定，不據此擴展整起事故的完整事實鏈。

即使刪掉這個案例，前面的理論判斷仍然成立。但保留它有一個重要價值：它讓兩種看上去相似的失效被區分開來。

一種是存在一條邊界，但有人違反規則繞過了它。

另一種是被當作邊界的約束，本來就可以由它所約束的一側合法地取消。

兩種情況在事後都可能表現為「防護沒有擋住動作」，但工程含義完全不同。前一種首先要求處理繞過問題；後一種則要求重新檢查：那裡究竟有沒有形成一條能夠獨立約束執行的邊界。

兩句定義，和一道沒有被填平的落差

把前面的討論落回兩個概念，問題會更清楚。

執行邊界是在 Action 成為現實之前，對其狀態、參數、資格和允許結果進行最終約束，並能夠真實允許或阻止現實副作用的邊界。它不是登錄、訪問、Policy、工具接口或普通網絡邊界本身，也不必綁定某種硬件實現。它的失敗條件是：存在不經過同等檢查卻能產生同等現實結果的路徑，或者邊界的拒絕無法約束執行器。

邊界獨立性則回答另一個問題：一個控制邊界的成立，不依賴於其所約束主體能夠同時關閉、重寫或繞過該邊界。這裡有兩條邊界需要同時保留：

不同進程、節點、副本、服務或名稱不自動構成獨立。

獨立不表示絕對隔離或永不共謀。

它的失敗條件是：邊界共享同一身份、權限、更新、恢復或通信控制根，導致一次失陷同時取消多層約束。

這兩個概念處理的不是同一個問題。執行邊界回答的是：在 Action 進入現實以前，是否存在一個能夠真實允許或阻止現實副作用的約束位置。邊界獨立性繼續追問：這條邊界本身，是否仍然依賴於被它約束的主體維持其有效性。

因此，一條執行邊界可以確實存在，卻仍然缺少邊界獨立性。上一節的案例之所以與這裡有關，正是因為約束並非不存在；問題在於，它是否能夠由原本受到約束的一側取消。

執行邊界定義中還有半句話需要按原意理解：

它也不必綁定某種硬件實現。

這句話既沒有說執行邊界與硬件無關，也沒有說執行邊界必須依賴硬件。它只排除一種簡單替換：不能因為某個控制被放進了獨立設備、獨立機器或者另一個物理位置，就直接用物理位置回答邊界獨立性的問題。

這裡關心的是因果上的可達關係。兩個控制即使相距很遠，仍然可能共享能夠同時影響兩邊的身份、更新、恢復或通信控制；反過來，物理距離很近，也不能單憑距離判斷它們的控制關係。本章開頭的「兩個機房」因此只能證明部署位置不同，不能直接證明失敗來源已經獨立。

邊界獨立性的失敗條件列出了身份、權限、更新、恢復和通信等共享控制根。這些是已經觀察到的共享形態，但不能把它們反過來理解成一份完整清單。

如果把它們排成一套逐項檢查表，很容易得到一個並不存在的推論：

只要這幾項全部排除，邊界獨立性就成立。

這個結論不能成立。身份、權限、更新、恢復和通信等共享控制根，可以用來發現獨立性為什麼失敗，卻不能反過來組成一套充分條件。排除了這些已知的共享關係，只能說明沒有在這些方向上發現共同失敗來源，不能因此證明邊界獨立性已經成立。

這裡還存在一道沒有被填平的落差。

前面使用過一條更嚴格的判斷：

兩個控制只有在其中一個失陷時，另一個仍然保有獨立否決能力，才構成執行意義上的兩個 Authority。

而邊界獨立性的定義是：

一個控制邊界的成立，不依賴於其所約束主體能夠同時關閉、重寫或繞過該邊界。

兩句話的強度並不完全相同。前一個判斷進一步要求：其中一個控制失陷以後，另一個仍然保有獨立否決能力，而且這種關係還具有方向性。後一個定義關注的是，邊界能否被它所約束的主體同時關閉、重寫或繞過。

因此，滿足邊界獨立性的定義，並不能自動推出已經滿足「失陷後仍保有獨立否決能力」這一更嚴格要求。

反過來，也不能直接把這個更嚴格的要求寫進邊界獨立性的定義。兩者處理的是彼此相鄰但並不完全重合的問題，它們之間仍然存在一道需要保留的理論邊界。

獨立是有方向的

還有一個容易被忽略的問題藏在「相互獨立」這個說法裡。這個詞聽上去是對稱的，但本章討論的獨立關係並不天然對稱。

A 相對 B 獨立，不蘊含 B 相對 A 獨立。

原因在於，同一對控制之間可以同時存在多種關係，而這些關係各有自己的方向。如果只從其中一條關係得出「A 和 B 是獨立的」，就很容易把一個局部判斷擴展到其他尚未檢查的關係上。

可以設想一個只用於說明方向性的情形。某個系統裡有一個執行側和一個審計側。審計側只讀取執行側寫出的狀態，不接受執行側的指令；但執行側所在的發佈通道，同時負責向審計側推送軟件更新。

從讀取關係看，審計側的判斷邏輯不受執行側直接修改；從更新關係看，執行側卻能夠改變審計側的軟件。於是，同一對控制在不同關係上，會得到不同方向的判斷。

這就是為什麼獨立性不能只對整個系統判斷一次，也不能只對一對控制籠統判斷一次。這裡要求的判斷粒度是：

針對每一對 Authority 和每一種安全屬性分別判斷。

必須同時說明正在判斷哪一對 Authority，以及判斷的是哪一種安全屬性。缺少其中任何一個條件，「這個系統是不是獨立的」這樣的問法都過於寬泛。

這也意味著，獨立性不能被當成一個一次確認以後就長期不變的系統標籤。控制之間的關係會隨著身份、更新、恢復、通信等控制路徑的變化而變化；某一次系統修改即使沒有改變服務名稱和部署位置，也可能改變某一對 Authority 在某項安全屬性上的關係。

這裡很容易繼續走向一個看似自然的做法：把 Authority 放在一邊，把安全屬性放在另一邊，逐項填寫「獨立」或「不獨立」。

但本章不能建立這樣的判定表。

原因並不是逐對逐項檢查這個思路有問題，而是每一個「獨立」的正面結論仍然需要回答：

憑什麼認為這一項獨立已經成立？

前面的判斷能夠排除一些明顯不足以證明獨立的結構，卻還不能給出「獨立性由什麼保證」的完整工程條件。如果現在把這些格子全部填成「是」或「否」，就等於先假定已經存在一套完整的正面判定方法，而這一點並沒有成立。

所以，逐對 Authority × 逐種安全屬性規定的是判斷粒度，不是一張已經完成的獨立性判定清單。

這不是縱深防禦的另一種說法

邊界獨立性不能直接被歸入縱深防禦，也不能因為一個系統採用了 Zero Trust，就認為這裡討論的問題已經得到回答。

本章檢查的是另一件事：看起來彼此分開的控制，會不會因為同一個失敗來源而同時失去作用。

增加更多控制層、部署更多節點或者採用不同的信任策略，都可能具有各自的工程價值，但這些做法本身不能替代對失敗來源獨立性的判斷。如果只是把「獨立」重新解釋成「層更多、位置更多、控制更多」，上一章已經否定掉的數量判斷就會重新回來。

同時，本章也沒有把獨立性定義成某種絕對隔離。

獨立不表示絕對隔離，也不表示永不共謀。

這裡關心的仍然是一個受限的問題：當其中一側失去可信性時，另一側是否仍然能夠保留本來屬於自己的約束能力。至於不同主體如何共謀、失陷怎樣組合，以及應該採用多強的隔離，本章不繼續展開。

到這裡，第七章能夠交出的內容已經明確。

第一，名義上的獨立，不蘊含失敗來源上的獨立。

第二，一個上限如果可以被受其約束的主體自己調高，它就不是執行邊界，而是一條默認配置。

第三，獨立性是有方向的。A 相對 B 獨立，不蘊含 B 相對 A 獨立，因此必須針對每一對 Authority 和每一種安全屬性分別判斷。

這些判斷能夠幫助排除一些看起來已經分開、實際上仍然共享控制來源的結構，但它們仍然沒有給出一套完整的「獨立性由什麼構成」的正面定義。前面留下的那道落差也仍然存在：更嚴格的判據與邊界獨立性的定義並不完全等價，本章不把兩者合併。

這些結論還會繼續引出幾個問題。

執行邊界的失敗條件提到：存在不經過同等檢查，卻能產生同等現實結果的路徑。那麼，「同等」究竟按照什麼判斷？一項約束要真正做到不可繞過，需要滿足什麼條件？

此外，作出判斷的位置和真正產生現實副作用的位置之間是什麼關係，也還需要單獨處理。判斷本身存在，並不自動說明執行者一定受到這次判斷的約束。

還有配置問題。既然一項限制是否構成邊界，取決於誰能夠改變它的生效狀態，那麼「誰能改配置」就不只是維護上的便利問題。改變配置，也可能是在改變誰能夠讓現實動作發生。

這些問題在本章都不回答。現在更直接的問題是：一條執行邊界要決定這一次 Action 是允許還是拒絕，總要拿當前動作與某些東西進行比較。前面的討論一直在追問「這一次是否應當發生」，卻還沒有回答：

這次判斷依據什麼？這些依據本身，又憑什麼可以被依據？

本章術語

• 權威 ｜ Authority
• 執行邊界 ｜ Execution Boundary
• 邊界獨立性 ｜ Boundary Independence
• 名義獨立 ｜ Nominal Independence
• 失敗來源獨立 ｜ Failure-Source Independence

本章案例與資料來源

切爾諾貝利 4 號機組事故

本章使用 1986 年 4 月 26 日發生的 切爾諾貝利 4 號機組事故作為機制解釋案例（Mechanism Exposition）。

本章引用這一案例，不是為了重新解釋切爾諾貝利事故的完整原因，也不是用它證明邊界獨立性的定義。

它在這裡承擔的作用，是把一個抽象的執行控制問題落到現實事件中：

一項約束即使真實存在，如果它的生效狀態仍然可以由受到這項約束的一側改變，那麼「約束存在」本身並不足以證明獨立邊界已經成立。

本章使用 INSAG-7 對若干既有「違規」認定的修訂，包括應急堆芯冷卻系統關閉並不被禁止且已獲批准、蒸汽分離筒水位跳閘的停用並未發生，以及兩臺汽輪機跳閘的停用為常規程序所要求。

這些事實只用於區分兩種不同的工程情形：一種是已經存在有效邊界，但有人通過違規或繞過使其失效；另一種是被視為邊界的約束，本身就能夠由受到它約束的一側在既有程序允許的範圍內取消或失去作用。

本章不據此把切爾諾貝利事故壓縮為「操作員違規」或「設計缺陷」中的任何一種單一原因，也不從這些事實擴展整起事故的完整因果鏈。

切爾諾貝利事故的完整事件背景、事實核驗、INSAG-7 相關認定及其作為本章機制解釋案例的證據限制，見本書附錄 《現實失敗與邊界案例》。

資料來源

本章不在正文中重複展開切爾諾貝利事故的完整事實鏈與書目資料。相關材料統一列入附錄 **《現實失敗與邊界案例》**及全書 《參考文獻與資料來源》。

---

第八章｜拿什麼當尺子

本章回答執行判斷規範側「拿什麼當尺子」的問題：這把尺子是 Intent，但不是一句自然語言、一個 Request 或一段 Prompt，而是能夠被識別、跨邊界引用、綁定、驗證和比較的規範參照。關鍵不在表達是否清楚，而在系統能否持續指認「引用的仍是同一個 Intent」。因此，主觀目標、原始請求與 Structured Intent 不能直接等同，其他已有對象也不能無損替代它。Intent 說明希望發生什麼，卻不會自動產生 Authority 或執行資格，也不保證執行和結果正確。Intent Binding 要防止靜默換綁、跨 Intent 複用和錯誤歸屬；哈希、簽名等只是實現方式。規範參照建立以後，判斷還缺少現實這一端：過去成立的 Authorization、Policy 和判斷，為什麼不能脫離當前 State 被繼續使用？

上一章留下了兩個問題：這次判斷依據什麼，這些依據本身又憑什麼可以被依據。本章先處理前一個，而且只處理它的一半。

一條執行邊界要在動作成為現實以前作出放行或拒絕，總得拿眼前這一次 Action 和某個參照進行比較。比對因此天然有兩端：一端是此刻正要發生的動作，包括它的對象、參數、範圍以及即將造成的狀態變化；另一端則是「本來應該發生什麼」。工程裡可以把後一端叫依據、口徑、基線或者參照，為了先把問題說清楚，也可以暫時把它叫作一把尺子。

這個比喻有一個好處：尺子自己不執行動作，它只是被拿來比較。作出判斷的主體不是尺子，正在發生的 Action 也不是尺子；如果一次判斷無法指出自己究竟依據什麼進行比較，那麼所謂判斷實際上很容易退化成「眼前這件事」與「此刻判斷者自己的理解」之間的比較。

但真實工程裡的規範參照又和一把普通尺子非常不同。真正的尺子已經存在，刻度固定，換一個人拿起來仍然是同一把尺子，放置一段時間以後也不需要重新證明它的身份。執行系統裡的規範參照沒有這些天然條件：它必須能夠被識別，能夠在不同邊界之間被引用，並且需要保證後續引用的仍然是同一個對象。

因此，「尺子」只能幫助我們看見這個位置，不能承擔後面的工程定義。真正要放在這個位置上的對象，是意圖（Intent）。

這個答案看起來非常自然。「依據當初的意圖」幾乎不會引起反對，真正的困難在於：不同人說到「意圖」時，所指的往往並不是同一個東西。它可能是提出事情時的一句話、一張工單、一封郵件、一段對話或者一個 Prompt，也可能已經成為系統內部經過結構化處理的對象。本章接下來首先要回答的，就是這些東西為什麼不能被直接視為同一個 Intent。

可識別，不是明確

先把這一章對 Intent 的基本含義固定下來：

意圖是對希望發生之 Action、對象、範圍、條件、狀態變化或結果方向的可識別表達。在 Execution Engineering 中，Intent 可以成為後續執行鏈跨邊界引用、綁定、驗證與比較的規範參照。

這裡真正承重的詞是可識別，不是明確，也不是真實。

一段願望可以表達得非常清楚，措辭毫不含糊，提出它的人也確實就是那個意思，但這些條件本身還不足以讓它成為執行判斷中的比對對象。比對要求的是另一種性質：系統必須能夠指認出「正在引用的是哪一個 Intent」，並且這個對象在進入第二個邊界、第三個邊界以後，仍然能夠被識別為同一個對象。

如果一句話到了不同環節以後，每一處都重新按照自己的方式理解一次，那麼原來的表達即使非常清楚，執行鏈裡實際上也已經出現了多個不同的解釋結果。此時缺少的不是更好的措辭，而是一個能夠跨邊界保持同一性的規範參照。

這和通常所說的「意圖不清」是兩個問題。日常交流裡，意圖不清往往意味著表達含混、需求沒有說透，或者雙方理解不一致，解決方式通常是重新溝通。但 Execution Engineering 所要求的可識別性並不止於溝通是否成功。一件事完全可以被所有參與者理解得毫無歧義，卻仍然沒有在系統中形成一個可以被持續指認的對象：沒有哪個邊界能夠明確說出「我現在引用的是這個 Intent」，也沒有哪個位置能夠在之後驗證，眼前的 Action 仍然對應最初那個行動指向。

反過來，一個表達也不必因為保留了一定範圍或條件空間，就失去作為 Intent 的資格。只要這些範圍和條件本身被包含在一個已經識別並綁定的對象中，它們就是 Intent 的組成部分，而不是留給下游各自補全的空白。

正因為承重的是「可識別」，Intent 才具有一組直接的工程含義。它使「最初希望發生什麼、作用於什麼對象、允許到什麼範圍、哪些條件和結果方向屬於這次行動指向」成為一個可以被引用的對象。多個彼此獨立的執行邊界可以引用同一個 Intent，但引用並不意味著邊界必須接受它；Intent 可以參與比較和驗證，也不因此變成事實、Policy、Authority 或裁決本身。它即使真實、完整、明確，並且已經得到確認，這些性質也仍然不是正確執行的充分條件。

這裡還必須區分三個經常被混在一起的對象：主體心裡的主觀目標，進入系統的原始請求或聲明，以及已經被結構化、能夠在執行鏈中被識別和引用的 structured Intent。

三者可以彼此關聯，卻不能直接等同。主觀目標可以產生請求，請求可以成為形成 Intent 的來源，而 structured Intent 則承擔後續跨邊界引用、綁定、驗證與比較的職責。把它們合併成一個對象，會讓「提出請求」和「形成一個可比對的規範參照」看起來像是在同一步裡自然完成，而這正是本章需要避免的混淆。

它不產生的七樣東西

Intent 的正面地位一旦建立，一個很自然的推論就會出現：既然它是執行判斷中的規範參照，那麼一個真實、明確、來源清楚的 Intent，是不是已經足以讓事情發生？

不是。這個否定不是附加在定義後面的一條謹慎說明，而是 Intent 工程邊界本身的一部分。

Intent 不自動產生 Authorization、Authority、Final Execution Authority、Execution Qualification、Execution Grant、Correct Execution 或 Correct Result。

這七項分別堵住了幾種不同的誤讀。前三項屬於權力問題：希望某件事發生，不等於已經獲得授權，不等於擁有對系統產生約束力的 Authority，更不等於擁有能夠在現實執行之前決定這一次 Action 最終是否發生的 Final Execution Authority。Intent 可以說明行動指向，卻不能因為這個指向真實存在，就自動產生這些權力。

Execution Qualification 與 Execution Grant 處理的是另一層問題。Intent 回答的是「希望發生什麼」，而資格和許可回答的是「在當前條件下，這一次是否具備繼續執行的條件」。前一個可以成為後一個的輸入，卻不能因為行動指向已經被識別，就把執行資格或執行許可一併產生出來。

Correct Execution 與 Correct Result 則位於執行和結果這一側。一個 Intent 可以被準確記錄，也可以完整表達原本希望發生的事情，但這並不保證實際執行過程一定正確，更不保證最後出現的現實結果就是正確結果。規範參照存在，只意味著我們終於有了一個可以進行比較的對象，並不意味著比較之後一定會得到符合預期的現實。

Intent 也不被定義為現實執行本身。這個區別在實現裡尤其重要：如果一個組件既負責記錄 Intent，又負責觸發 Action，那麼「記錄了什麼」與「現實中做了什麼」仍然必須保持為兩個能夠分別識別、分別約束和分別驗證的對象。否則，規範參照和現實執行會在實現上被壓縮成同一件事，而判斷本來需要保持的兩端也就隨之消失。

所以，這七項否定與 Intent 的正面地位必須放在一起理解。Intent 可以成為跨邊界引用、綁定、驗證與比較的規範參照，但它本身不自動帶來權力、資格、許可，也不保證執行和結果正確。

Intent 告訴系統應該拿什麼來比，但它不替系統完成後面的判斷，更不替現實完成執行。

它不是那句話

現在可以回到最開始那個最常見的理解了。

Intent 不是 Request。Request 是入口，是表達的載體，它完全可能只是某個服務收到的一次性輸入：到達、被處理，然後結束。它可以承載某個行動指向，卻不天然承擔在多個執行邊界之間保持同一性的職責。

Intent 也不是 Instruction。Instruction 表達的是命令語義：做這個。一條指令可以被正確接收、正確解析、正確執行，而整個過程中仍然沒有形成一個能夠被後續邊界重新引用和比較的規範參照。

這兩條區別說明了為什麼一段自然語言不能直接頂替 Intent。不論它來自人的口述、一封郵件、一張工單、一段對話，還是交給模型的 Prompt，它首先都是請求、聲明或表達這一層的東西。它可以成為 Intent 的來源，可以成為形成 Intent 的入口，也可以提供 Intent 的內容，但它不會因此自動成為執行工程中的 Intent。

二者之間隔著一道結構化要求：要進入執行判斷，這個行動指向必須達到足以被 identify、bind、reference、compare、validate 的程度。沒有達到，就沒有一個能夠在這條比對鏈中被持續指認和驗證的規範側對象。至於不採用這類顯式比對鏈的執行結構如何形成約束，則是另一個問題；本章不把基於 Intent 的比對寫成所有系統唯一可能的執行控制方式。

這一區分在 AI 或 Agent 參與行動生成以後尤其重要。AI 可以生成 Intent、派生 Intent、轉換 Intent，也可以提出 Intent，但這些動作不會因為生成主體發生變化，就自動改變 Intent 在執行鏈中的權力和資格地位。AI 生成的 Intent 不是被授權的 Intent，AI 派生的 Intent 不是 Final Authority，AI 生成的 Intent 不是 Execution Qualification，AI 生成的 Intent 也不是 Execution。

AI 只是 Intent 的可能來源或生成主體之一。來源身份不自動賦予現實執行效力，這一點對人同樣成立。生成速度更快、表達更加完整，或者一個 Agent 已經能夠獨立形成結構化 Intent，都不能因此把「它已經提出了要做什麼」改寫成「這件事已經被授權」或者「這一次已經獲得執行資格」。

至於 AI 派生出的 Intent 應當如何繼承、如何傳播、在什麼情況下需要重新授權，本章不建立完整的類型學。這裡需要固定的只有一條邊界：

生成它的是誰，不改變它是什麼；能夠生成 Intent，也不因此獲得讓這個 Intent 成為現實的 Authority。

為什麼不能讓別的對象頂替

到這裡還會出現一個很實際的問題：系統裡已經存在 Goal、Request、Authorization、Policy、Execution 等對象，為什麼還要把 Intent 單獨識別出來？如果某個已有對象能夠承擔同樣的職責，那麼繼續增加新的工程對象確實沒有必要。真正需要檢查的不是「要不要多一個對象」，而是：讓已有對象兼任以後，會不會丟掉 Intent 在執行判斷中必須承擔的東西。

最直接的五個候選都可以逐項檢查，而它們分別缺少不同的部分。

目標（Goal）表達的是目的或者方向。它可以說明系統最終想達到什麼，卻不足以承擔一次具體行動的對象、範圍、條件、否定性約束、身份、版本與綁定關係。知道「要提升可用性」，並不能據此判斷眼前這一條具體命令是否屬於被允許的行動指向。

請求（Request）承擔的是入口和表達。它可以把一次願望送進系統，也可以攜帶形成 Intent 所需要的信息，但它可能只是一次性輸入，本身並不負責在後續多個邊界之間保持同一個規範參照的身份。

授權（Authorization）處理的是資格。它可以說明某種能力是否被允許使用，或者證明某次授權確實發生過，卻沒有因此回答「這一次究竟希望發生什麼」。如果直接用 Authorization 代替 Intent，就會把「批准已經存在」與「被批准的內容究竟是什麼」混成同一個問題，而後者恰恰是執行時需要被重新比較的對象。

策略（Policy）處理的是規則及其適用條件。它描述「這一類 Action 在這一類條件下應當怎樣」，而 Intent 指向的是「這一次希望發生什麼」。兩者都可以進入同一次判斷，卻承擔不同職責：Policy 不能因為規定了規則，就替代一次具體行動的規範參照；Intent 也不能因為說明了行動指向，就替代 Policy 對執行條件的約束。

執行（Execution）則位於現實變化這一側。它描述已經發生或正在發生的 Action，卻無法承擔尚未執行、已經被拒絕、被撤回、已經過期或者發生偏離的 Intent。執行前判斷必須在現實動作發生之前就擁有規範參照，因此不能等到 Execution 已經出現以後，再由現實結果反過來承擔這一職責。

逐項看下來，這五個候選都不能無損地承擔 Intent 在本章中的兩部分作用：一部分是有界行動指向的可識別表達，另一部分是能夠被跨邊界引用、綁定、驗證與比較的規範參照身份。

這個結論只需要停在這裡。它說明的是 Goal、Request、Authorization、Policy 和 Execution 這五個候選都不能直接替代 Intent，並不建立一個關於所有可能對象的窮盡判斷。

同樣，Intent 也不是執行判斷中唯一的規範來源，更不是執行的充分條件。它解決的是規範側一個不可省略的問題：系統需要知道自己正在把當前 Action 與哪一個行動指向進行比較。但有了這個參照，並不意味著 Authorization、Policy、Authority、State、Boundary 或其他執行條件已經同時成立。

這一端不能被這五個已有對象無損替代，不等於有了這一端，執行判斷就已經完整。

綁定要擋住的五件事

到目前為止，把 Intent 稱為「規範參照」仍然只說明瞭它在判斷中的位置。要把這個位置變成工程要求，還需要繼續回答兩個問題：它必須和哪些對象保持可驗證關係，以及這些關係究竟要防止什麼。

一個進入執行鏈的 Intent，需要能夠與來源、對象、關鍵參數、上下文、審批、Policy、Payload、Execution 和 Evidence 建立可驗證關係。這九類不是一份窮盡清單，它們說明的是一種結構要求：系統不能只證明「某些內容曾經被記錄過」，還必須能夠檢查 Intent 與後續執行鏈中的具體對象之間究竟是不是同一條關係。

記錄和可驗證關係並不是一回事。記錄只能說明某件事被寫下來過，而可驗證關係要求系統在動作成為現實以前，仍然能夠提出諸如「眼前這個參數是否屬於這個 Intent」「這份 Approval 是否面對的就是這個 Intent」「當前 Payload 是否仍然對應此前綁定的對象」之類的問題，並且這些問題必須允許得到否定答案。如果一種所謂的綁定無論輸入什麼都只能得到肯定結果，那麼它形式上存在，實際上並沒有形成約束。

這些關係為什麼重要，從它們需要阻止的失效看得最清楚。第一種是對象、參數、範圍或環境被靜默替換。一個 Intent 已經完成此前的檢查，但在檢查結束到 Action 真正發生之間，其中某個關鍵字段被換成了另一個值。替換過程沒有報錯，沒有觸發新的判斷，原來被允許的是一個對象，最後真正受到作用的卻是另一個對象。此時每一個單獨環節都可能保留自己的記錄，但 Intent 與現實 Action 之間的關係已經被改變。

第二種是Approval 或 Policy Decision 被跨 Intent 複用。某一次判斷確實發生過，而且在當時面對的對象上完全可能是正確的；問題出現在它隨後被帶到另一件事情上繼續使用。判斷本身沒有被偽造，失去的是判斷與原始 Intent 之間的綁定。一份真實的批准被用在錯誤的對象上，仍然會產生錯誤的執行關係。

第三種是舊 Intent 在新的 State 下自動繼續。一個 Action 最初成立時依賴某些現實條件，隨後這些條件已經變化，而此前形成的 Intent、Approval 或其他判斷仍然沿著執行鏈繼續向前。在這一章裡，我們只處理問題的一半：Intent 必須能夠與它形成時所面對的條件建立關係，從而使「這個 Intent 在現在是否仍然適用」成為一個能夠被提出和檢查的問題。至於當前 State 本身如何形成、如何獲取，以及變化以後怎樣重新進入判斷，不在本章回答。

第四種是相同字段或簽名跨協議用途獲得新的證明含義。同一段數據或者同一個簽名，在原來的協議和上下文裡只證明一件事，被移到另一個用途以後卻被解釋為更強的證明。這裡可能沒有任何數據被偽造，真正發生變化的是這份 Evidence 與 Intent、協議和用途之間原本存在的綁定關係。

第五種是Result 被錯誤歸屬給另一個 Intent。現實動作確實發生了，結果也真實存在，但它被記錄到另一個 Intent 名下，於是那個從未真正發生過的 Intent 看起來像是已經得到了正確執行。這種失效說明 Intent 與 Result 之間必須存在能夠被驗證的關係，但這種關係的方向不能反過來。

Result 可以被拿來與 Intent 比較、驗證或者形成證明，卻不能重新定義 Intent。下面這種推理因此不能成立：

結果已經發生了
所以
原來的意圖一定就是這個意思

正確的方向恰好相反：先存在一個已經被識別並綁定的 Intent，再把觀察到的 Result 拿回來與它進行比較。否則，系統就會在事情發生以後按照現實結果重新解釋原來的規範參照，看起來仍然完成了比較，實際上卻已經把尺子改成了被量對象的形狀。

把這些關係落到具體系統中，可以使用 IntentHash、域分離、版本號、簽名以及其他機制來保持身份、完整性和綁定，但這些都是可能的實現載體，而不是 Intent 或 Intent Binding 在理論上的唯一實現方式。這裡要求的是關係能夠被可靠地識別和驗證，並不預先規定這種關係必須由哪一種密碼學結構、協議或者設備完成。

同樣，實現 Intent Binding 所使用的對象也不因此成為 Intent 本身。哈希、密碼學域、物理入口、硬件確認等機制都可以被 Intent 相關結構複用或者依賴，但複用不等於佔有。如果把某一種具體實現直接算進 Intent 的定義，那麼 Intent 的含義就會隨著協議、設備和實現棧一起變化，而本章需要建立的是一個在不同實現之間仍然能夠保持穩定的工程對象。

另一側走到的同一個地方

從 Execution Control 的方向再看一次，可以得到一個與前面相容、但不能被簡單等同的結論：如果系統採用顯式比對鏈，那麼最終執行的對象、參數、範圍和相關 State，就必須能夠和此前已經形成的 Intent、Approval 或其他規範參照建立可驗證關係。否則，系統即使擁有完整記錄，也無法回答眼前這一次 Action 是否仍然對應此前被接受的行動指向。

但顯式比對並不是所有執行控制結構唯一可能的形式。一個系統也可以通過明確的 Boundary 規則直接限制 Action，而不是在每一次執行之前都重新完成同一種 Intent 比對。因此，本章建立的是：**當 Intent 被作為規範側參照使用時，它必須具備可識別、可綁定、可引用、可驗證和可比較的性質。**這並不等於要求所有系統都必須採用同一種比對鏈。

Intent 本身的邊界也需要繼續保持清楚。主觀 Goal、進入系統的 Request、structured Intent、Authorization、Action 和 Result 可以位於同一條執行鏈中，卻不因此屬於同一個層級。Intent 可以真實、明確，也可以擁有清楚的來源，但這些性質都不會自動產生 Execution Qualification，也不會自動保證最終 Execution 或 Result 正確。

從工程失效的角度看，Intent 至少可能因為來源不明、語義漂移、結構被汙染、關鍵內容缺失，或者與後續 Action 失去可驗證關聯而失去作用。但這五種情況不是 Intent 失敗形態的全集。

一個 Intent 還可能因為過期、被替換、被重放、被跨用途複用，或者在 AI 參與生成和補全的過程中被加入原本沒有被授權的內容而失去原來的約束意義。這些情況不需要被強行壓進同一個最小定義裡；它們只說明一個事實：Intent 能夠被識別出來，並不意味著它在整個執行生命週期中會自動保持有效。

因此，本章對 Intent 的定義保持最小，而對它可能失效的方式保持開放。定義回答的是「什麼樣的對象可以承擔規範參照」，失敗分析回答的是「這個對象在進入執行鏈以後可能怎樣失去原來的含義或綁定」。兩者相關，但不需要被整理成一張看起來已經窮盡的分類表。

原則已經明確，歸屬仍然開放

現在可以把「尺子」這個比喻收回來了。一次執行前判斷所需要的規範側參照，並不是一件天然存在、拿起來就可以使用的東西。Intent 必須首先被識別出來，並且在進入後續執行鏈以後，仍然能夠被不同邊界引用為同一個對象。它需要擁有可以驗證的身份，需要能夠證明關鍵內容沒有被無痕改寫，也需要能夠說明自己與對象、參數、條件以及後續 Action 之間保持著怎樣的綁定關係。

真正的尺子不需要解決這些問題。它的身份、刻度和物理對象天然重合；Intent 卻不同。一個系統如果連自己正在引用的是不是原來那個 Intent 都無法證明，那麼後續所謂的比較、驗證和執行判斷也就失去了穩定的規範參照。

因此，進入執行判斷的 Intent 引用至少需要具備可驗證的身份（identity）、完整性（integrity）與綁定（binding）。同時，任何單一的可失陷主體，都不應當能夠無痕地重寫這個引用，再讓系統把被改寫後的對象繼續識別成原來的 Intent。

這一原則能夠明確，並不意味著實現歸屬已經隨之確定。Intent 應該存放在哪裡，由誰保存，由誰簽名，是否必須存在唯一的權威副本，以及 SaaS、硬件、Evidence Store 或其他組件之間應該如何分配這份責任，本章都不作結論。

這兩層問題必須分開。identity、integrity 與 binding 的要求不會因為 ownership 尚未確定而失效；反過來，原則已經成立，也不會自動回答 authoritative copy 應該屬於誰。如果一個系統只能說明「這個引用具有身份、完整性和綁定」，卻無法進一步說明它引用的 authoritative Intent 從哪裡產生、誰能夠修改、修改以後如何被識別，那麼實現結構中仍然存在一個沒有被回答的問題。

這裡尤其不能因為某一種實現看起來合理，就把它直接提升為理論結論。唯一權威副本是否必須存在，它應該由雲端、硬件、本地組件、Evidence Store 或其他主體持有，以及防改寫證明應當由誰提供，都繼續保持開放。

本章在這裡建立的是原則邊界，而不是 ownership 方案。至於這份 Intent 引用以及它與其他對象之間的關係，憑什麼能夠被系統認為是真的，則屬於下一層問題。本章只走到這裡。

這一章之後

到這裡，規範側的參照已經能夠被清楚描述：它是 Intent，是一個可識別、能夠被跨邊界引用、綁定、驗證與比較的對象。它可以來自人的表達、Request、工單、對話或者 Prompt，但不能因為這些表達存在，就把其中任何一個直接等同於 Intent；同樣，Intent 已經被識別出來，也不意味著 Authorization、Authority、Final Execution Authority、Execution Qualification、Execution Grant、Correct Execution 或 Correct Result 會隨之自動成立。

但是一次判斷不能只有這一端。即使系統已經擁有一個被識別、被綁定並能夠持續引用的 Intent，判斷仍然沒有完成。因為比對的另一端不是過去，而是此刻正在接近現實的這一次 Action。當初的 Approval 是在當時條件下形成的，Policy 面對的是當時的適用條件，此前某一次判斷之所以成立，也依賴那個時刻的對象、參數和 State。

這些條件不會因為 Intent 沒有變化，就被假定仍然保持原樣。第八章建立的是規範側參照，卻沒有回答當前現實條件應該如何進入判斷，也沒有回答過去已經成立的結論在新的 State 下是否仍然有效。

於是問題自然落到下一層：

為什麼已經成立的 Authorization、Policy 與此前判斷，不能脫離當前現實條件被重複使用？

本章術語

• 意圖 ｜ Intent
• 結構化意圖 ｜ Structured Intent
• 意圖綁定 ｜ Intent Binding
• 目標 ｜ Goal
• 請求 ｜ Request
• 授權 ｜ Authorization
• 策略 ｜ Policy
• 執行 ｜ Execution
• 結果 ｜ Result
• 證據 ｜ Evidence
• 權威副本 ｜ Authoritative Copy

本章案例與資料來源

本章無現實案例。

正文中關於對象、參數、範圍或環境被靜默替換，Approval 或 Policy Decision 被跨 Intent 複用，舊 Intent 在新的 State 下繼續執行，相同字段或簽名被跨協議賦予新的證明含義，以及 Result 被錯誤歸屬給另一個 Intent 等情形，均屬於假設性工程場景。

這些情形用於說明 Intent 作為規範參照時為什麼需要保持可識別性、完整性與可驗證綁定，不對應具體公司、產品、事故或現實事件，也不承擔本章理論結論的證明作用。

資料來源

本章沒有需要單獨展開的現實事件資料。正文涉及的 Intent、Structured Intent、Intent Binding、Goal、Request、Authorization、Policy、Execution、Result 與 Evidence，均按照本書已經建立的工程語義和邊界使用。

Intent authoritative copy 應由誰產生、保存、簽名，是否必須存在唯一權威副本，以及具體 ownership 如何分配，繼續保持開放，本章不為這些問題提前補出答案。

涉及外部論文、標準、官方資料或現實事件的內容，統一列入本書附錄及全書 《參考文獻與資料來源》。

---

第九章｜過去批准過，不等於現在還成立

本章把「過去成立」與「現在仍然成立」分開。Authorization、Policy 和此前形成的 Judgment 都可以繼續有效，卻不能因此替代當前這一次 Action 的判斷，因為規則沒有變化，不等於規則所面對的現實也沒有變化。為此，本章把 State 引入執行判斷：它是在特定時點、與某次 Action 能否被判斷和執行直接相關的事實與條件集合。State 不是數據庫快照，也不是系統全部數據；尤其不能把與現實高度相關的代理記錄自動當成現實本身。三里島案例只用於說明這種分離：記錄可以完全真實，而它所代理的現實狀態已經不同。State 的作用不是改寫 Intent，而是讓執行資格能夠隨著現實條件重新判斷。這樣，Intent 提供了規範側參照，State 提供了現實側參照。下一問因此變成：系統又憑什麼相信這些 Intent 和 State 確實成立？

「這件事上個月就批過了。」

說這句話的人通常沒有說錯。批准確實發生過，記錄也可能仍然有效，簽字的人當時有資格作出批准，流程也已經完成。問題不在這些事實是真是假，而在於它們後來被拿來回答了另一個問題：既然過去已經批准過，現在是不是就可以繼續執行？

Authorization 本身不能完成這個推導。它說明某種資格已經成立，卻不意味著一次具體 Action 在當前狀態、參數和邊界下仍然滿足執行條件。長期存在的 Authorization 可以繼續有效，但「這個主體仍然擁有資格」與「這一次 Action 現在仍然應當發生」始終是兩個問題。

Policy 也一樣。一條規則可以繼續存在，版本可以仍然被系統加載，甚至它曾經在完全正確的條件下產生過有效判斷，但這並不保證它原本面對的現實條件現在仍然存在。規則沒有改變，與規則所作用的世界沒有改變，不是同一件事。

所以這裡真正需要繼承的限制只有一句：

過去的事實可以成為當下判斷的輸入，卻不能替代當下的判斷。

Authorization、Policy 以及此前已經形成的判斷，都可以進入這一次執行判斷，但它們進入的身份是輸入，而不是能夠自動決定現實結果的 Authority。

問題也因此被進一步收緊。上一章已經給出了比對的一端：Intent 是可以被識別、引用、綁定和比較的規範參照，它告訴系統「原本希望發生什麼」。但一次現實執行不能只知道原本希望發生什麼，還必須面對另一個問題：

此刻，真正與這一次 Action 能否繼續有關的現實條件是什麼？

如果這一端沒有被明確指認，那麼「不能脫離當前現實條件重複使用過去判斷」仍然只是一句原則。要讓它成為可以進入執行判斷的工程對象，就必須先把所謂的「當前現實條件」本身說清楚。

直接相關

上一節留下的另一端，就是 State。

狀態是在特定時點，與某次 Action 能否被判斷和執行直接相關的事實與條件集合。

這個定義裡的三個限定必須同時成立：**在特定時點、與某次 Action、直接相關。**少掉任何一個，State 都會滑向另一個完全不同的對象。

「在特定時點」首先把 State 固定在時間上。State 不是一種脫離時間持續成立的性質，而是某一時刻與執行判斷有關的現實條件。正因為它帶有時點，「上個月已經批准」和「現在是否仍然成立」之間才有了可以被重新檢查的空間。過去的判斷面對的是過去的條件，當前判斷面對的則必須是當前條件。

「與某次 Action」進一步限定它的範圍。State 不是描述某一類 Action 的一般環境，也不是把整個系統此刻所有信息都收進來，而是圍繞這一次具體 Action確定哪些事實與條件會直接影響它能否被判斷和執行。同一個事實對於一項 Action 可能屬於 State，對於另一項完全不同的 Action 則可能沒有任何作用。

「直接相關」則把範圍收得更緊。它排除的不只是無關信息，也包括那些與目標事實存在相關性、卻不能直接承擔目標事實角色的記錄或信號。一個值可以長期準確地指示某種現實情況，也可以在絕大多數正常條件下與目標事實保持一致，但只要它本身仍然只是代理，系統就不能因為這種相關性而把它自動當成當前事實本身。

要進入執行判斷，這些事實與條件還必須在明確時點對當前判斷有效，並且能夠被 Runtime 作為輸入使用。一個事實即使真實存在，如果在裁決發生時無法被當前執行路徑讀取和使用，也無法承擔這一輪 State 的作用。

但這裡需要停住。State 能夠進入 Runtime，不等於本章要進一步定義 Runtime 收到這些輸入以後怎樣形成 Decision。那屬於另一個問題。

State 在這一章裡的作用可以壓縮成一句：

讓 Authorization、Policy 和此前判斷不能脫離當前現實條件被重複使用。

因此，State 並不是為了完整描述整個系統，也不只是一個泛化的 Context。它解決的是一個更窄的問題：讓「現在的條件」成為可以被明確指認、重新讀取並進入這一次執行判斷的對象。只有這樣，過去已經成立的 Authorization、Policy 或 Judgment 才不會因為記錄仍然存在，就自動延續到新的現實條件中。

State 的失效邊界同樣需要看清。狀態缺失、過期、衝突、無效或不完整，並不意味著現實系統本身已經發生了某種單一意義上的失敗；這裡真正的問題發生在系統面對這些情況時，仍然自動把執行條件判斷為滿足。

也就是說，危險的不只是「不知道」，而是：

在不知道當前條件是否仍然成立時，系統仍然把它當作已經成立。

它不是系統裡的那堆數據

State 不能被幾個相鄰對象直接吸收。它不等於 Database Snapshot，不等於 Policy，不等於 Trust，不等於 Evidence，也不等於系統全部內部數據。

其中最容易造成混淆的兩個方向正好相反：一個把 State 縮得太小，另一個把它放得太大。

把 State 理解成 Database Snapshot，是把「當前現實條件」替換成「某個存儲此刻保存了什麼」。Snapshot 描述的是某個存儲在某一時刻的內容，它的完整性由這個存儲自身的結構決定；State 描述的則是與這一次 Action 能否被判斷和執行直接相關的事實與條件，它的範圍由這一次 Action 決定。

因此，一個字段在數據庫裡是什麼值，與這個值此刻是否足以表示現實中與執行直接相關的事實，是兩個不同的問題。數據庫可以保持內部完整，記錄也可以完全一致，而真正決定這一次 Action 能否繼續的現實條件仍然沒有進入系統能夠讀取的位置。此時缺失的不是一條數據庫記錄，而是 State 本身。

另一個方向，是把 State 理解成系統全部內部數據。這樣看似什麼都沒有遺漏，實際上卻失去了 State 作為判斷對象的邊界。「與這一次 Action 能否被判斷和執行直接相關」這個限定，本來就是為了從龐大的系統信息中切出能夠進入當前判斷的那部分事實與條件。如果把所有內部數據都算作 State，那麼 State 就無法再被明確說成完整、缺失、衝突或過期，因為它已經變成了一個沒有執行邊界的集合。

Policy 與 State 的區別則更直接。Policy 描述規則及其適用條件，State 描述這些規則此刻所面對的現實事實。Policy 可以說「當 X 成立時允許」，State 回答的是「此刻 X 是否成立」。規則不能替代事實，事實也不能替代規則。

Trust 是另一個對象，本章不在這裡展開。

Evidence 也不能與 State 合併。State 回答的是：

現在與這一次 Action 直接相關的事實與條件是什麼？

Evidence 回答的則是：

憑什麼認為這些事實與條件成立？

前一個是本章的問題，後一個必須留到下一層再處理。把二者合併，會讓「現實是什麼」與「我們為什麼相信它是真的」失去邊界。

關於狀態的記錄不是狀態

「直接相關」這個限定，並不只是為了從大量信息中排除噪音。它還要處理一種更難發現的情況：系統手裡已經有一個與現實高度相關、甚至在自身語義上完全正確的記錄，但這個記錄仍然不是當前判斷真正需要的事實。

1979 年 3 月 28 日，三里島二號機組的一隻洩壓閥在按設計打開以後卡在了開啟位置，而控制室裡的指示卻讓操作人員認為閥門已經關閉。關鍵並不在於儀表產生了一個錯誤讀數。監管機構的技術材料指出，控制室中的狀態指示表示的是電磁閥已經失電，也就是關閉信號已經發出，而不是閥門真實的機械位置；當時控制室也沒有能夠直接顯示該閥門真實位置的儀表。

因此，判斷側實際擁有的是一個與目標事實高度相關的代理信號。在正常條件下，關閉信號發出以後閥門會隨之關閉，於是這個信號長期可以作為機械狀態的有效指示。但當閥門發生機械卡滯時，二者之間原本穩定的關係斷開了：關閉信號仍然真實存在，指示也仍然忠實表達了這個信號，可閥門本身卻仍然處於開啟狀態。判斷側看到的數據沒有說謊，只是它回答的已經不是執行判斷真正需要知道的那個問題。

這正是 State 定義中「直接相關」需要防止的混淆。一個代理記錄可以與當前事實長期保持一致，也可以在通常情況下足夠可靠，但只要它仍然只是代理，它就不能在關係失效時自動替代事實本身。記錄可以是真的，而它所代理的現實已經不是原來的樣子。

從 State 的角度看，這裡的問題屬於缺失：真正與這一次判斷直接相關的事實——閥門當前的實際機械位置——沒有進入判斷側可以讀取的通道，而這個缺口被一個語義上非常接近、卻並不等價的信號填補了。如果系統在這種情況下仍然自動把執行條件視為已經滿足，那麼問題就不再只是信息不足，而是代理記錄被錯誤地賦予了當前事實的角色。

這個案例在這裡僅承擔一個作用：說明代理記錄與當前事實可能發生分離，而且這種分離未必能夠從代理記錄自身被識別出來。它並不證明 State 的定義，也不是本章核心結論成立的依據；即使沒有這個案例，「State 必須是與當前 Action 直接相關的事實與條件」這一邊界仍然獨立成立。

同樣，也不能把三里島事故簡化成單一的人機界面問題或者操作人員失誤。監管機構對事故原因的描述涉及設備故障、設計相關問題與人員錯誤的共同作用，並指出可供人員使用的其他儀表存在信息不足或誤導性的問題。本章只取其中與當前論證直接相關的一點：**一個在自身語義上完全正確的信號，並不因此就是執行判斷所需要的當前事實。**事故的其他原因和結構問題不在這一章展開。

沒有塞進定義裡的七樣東西

讀到這裡，一個自然的問題會出現：既然 State 要承擔「當前現實條件」這個角色，那麼這些條件究竟應該怎樣被確定？一個事實從哪裡來才可以進入判斷，它屬於哪個版本，它是什麼時間形成的，它是否足夠新鮮，兩個來源發生衝突時怎樣處理，只有部分節點能夠觀察到的事實應該怎樣理解，系統從故障中恢復以後那段狀態又應該怎樣看待——這些都是真實的工程問題。

但它們沒有進入 State 的最小定義。

這裡至少有七個已經能夠被明確指出的問題：**來源資格、版本、時間、新鮮度、衝突、局部可見性和恢復狀態。**把它們留在最小定義之外，並不是認為它們不重要，而是因為 State 的最小定義現在只回答一個更基礎的問題：什麼樣的事實與條件能夠在特定時點、針對某次 Action，作為與判斷和執行直接相關的當前現實進入系統。

這七項討論的是這個最小對象建立以後仍然會出現的進一步問題。例如，一個事實可能確實與當前 Action 直接相關，但它來自哪個來源才可以接受；兩個來源可能同時提供相關事實，卻給出衝突答案；一個值可能在幾秒以前有效，現在卻已經過期；同一現實在不同節點上也可能只有局部可見。這些問題都會影響 State 能否被可靠使用，卻不因此自動成為 State 最小定義本身的一部分。

同樣，現在也不能因為七項已經被點名，就把它們整理成一套完整的 State 分類。它們目前沒有被證明屬於同一個層級，也沒有建立彼此並列的關係，更不能被當成一份已經窮盡所有問題的清單。把它們直接排成一張分類表，反而會讓版式替理論提前做出三個判斷：它們彼此並列、處於同一層級，而且已經覆蓋完整範圍，而這些結論目前都沒有建立。

因此，這一章寧願讓 State 的最小定義保持窄，也不提前把後續結構寫進去。最小定義負責確定 State 在執行判斷中的位置，而來源資格、版本、新鮮度、衝突、局部可見性、恢復狀態以及其他尚未被明確組織起來的問題，可以繼續在這個基礎上被分別討論。

這會留下一個明顯的不完整之處：我們已經知道執行判斷必須面對當前現實，卻還沒有得到一套完整的方法來描述「當前現實」內部所有可能的結構。但在這些關係尚未被充分建立以前，提前把它們固定成 State 的組成層級，只會讓後續所有依賴 State 的判斷被迫建立在一個尚未成立的分類體系上。

最小定義可以先成立，完整的 State 結構不必因此被提前假定。

條件變了，不等於想做的事變了

前面已經堵住了一種誤讀：State 不能被縮成數據庫裡的一個字段。這裡還需要堵住另一個方向相反、卻同樣容易出現的問題——如果 State 發生變化，使得原來允許執行的 Action 現在不再滿足條件，是不是意味著原來的 Intent 也隨之失效了？

不是。這裡需要保留一條基本區分：**約束的改變不等於 Intent 的改變。**Policy、State 或 Boundary 發生變化時，通常受到影響的是這一次 Action 在當前條件下的 Execution Qualification，而不是原來的 Intent 自動被改寫。原來的 Intent 仍然可以被識別，也仍然可以作為同一個歷史對象存在；變化的是，在新的現實條件下，它是否仍然具備繼續進入執行的資格。

因此，兩件事完全可以同時成立：Intent 仍然是原來的 Intent，而當前 Execution Qualification 已經發生變化。一個 Action 曾經符合執行條件，並不意味著在 State 改變以後仍然符合；但這種資格變化本身，也不能反過來被解釋成「原來想做的事情已經變了」。

這裡的「通常」必須保留，因為這不是一條全稱規則。如果發生的變化已經觸及 Intent 本身所表達的內容，那麼問題就進入了另一類：需要重新判斷這個 Intent 是否已經被修改，或者是否已經形成新的 Intent。至於什麼程度的變化構成 Intent Mutation，本章不建立判據，也不在這裡整理成分類或閾值。

同樣，本章也不為 Execution Qualification 建立完整的一般定義。它由哪些條件共同構成，由誰作出判斷，與最終 Decision 之間如何對應，這些問題繼續保持開放。本章只使用一個已經足夠支撐當前論證的事實：Execution Qualification 會隨著現實條件變化而變化，而這種變化不自動等於 Intent Mutation。

把前後兩種誤讀放在一起，State 的位置就會更清楚。往一個方向誤讀，會把 State 縮成數據庫中的某個值，於是所謂「檢查當前狀態」只剩下讀取一個代理記錄；往另一個方向誤讀，則會把任何條件變化都解釋成 Intent 已經改變，於是系統每遇到一次現實變化，都要重新回答「原來到底想做什麼」。

前一種錯誤會讓當前條件的重新判斷失去意義，後一種錯誤則會讓 Intent 無法在變化中的現實裡保持穩定身份。State 的作用，正是在兩者之間保留這樣一條邊界：現實條件可以變化，執行資格可以變化，而 Intent 不因此自動發生變化。

批准過的內容，和現在的現實

State 被引入執行判斷以後，一個很自然的關係就出現了：此前被批准的內容，和真正準備執行時的對象、參數與現實狀態，不能被當成同一件事。Approval 記錄的是某個判斷在當時條件下已經成立，而當前執行面對的，是此刻真正存在的對象、參數和 State。兩者之間如果沒有任何重新建立關係的機制，過去的批准就很容易被直接帶到已經變化的現實中繼續使用。

一種直接的工程做法，是在 Action 真正進入執行以前，把最終執行參數、執行對象和當前 State 與此前批准的內容重新進行一致性比較。這裡的重點不是再做一次完全相同的 Approval，而是確認當前準備成為現實的 Action，仍然落在此前已經形成的行動範圍和約束之內。

這種顯式比對很容易理解，但不能因此被寫成 Execution Control 唯一可能的結構。系統也可以通過明確的 Boundary Rule 直接限制當前 Action，而不逐項重新比較「現在」與「當初」。只要這條邊界在動作成為現實以前能夠真實約束執行路徑，它同樣可以承擔一部分當前條件約束的作用。

因此，本章真正需要保留的不是「所有系統都必須完成同一種比對」，而是更基礎的一條邊界：過去批准過的內容，與當前真正存在的對象、參數和 State 是兩個不同的判斷對象，前者不能因為曾經成立，就自動代表後者現在仍然成立。

當系統採用顯式比對鏈時，State 提供的是當前這一端；Intent、Authorization、Approval 或相關規範參照則提供此前已經形成的那一端。系統需要能夠判斷二者之間的關係，而不是把過去的結論直接複製到當前執行上。至於一個具體系統究竟採用逐項比對、邊界規則，還是其他能夠在執行前形成真實約束的結構，本章不把它固定成單一實現方式。

關係還沒有辦法被表示

這一章走到這裡，還留下了一個沒有解決的問題。前面的論證不斷使用「關係」這個詞：Approval 與當前 State 之間存在關係，代理信號與現實事實之間存在關係，Intent 與 Execution Qualification 之間也存在關係。但知道這些對象彼此有關，並不等於我們已經擁有一套足夠準確的方法來表示這種關係怎樣成立、怎樣變化，又怎樣失效。

最簡單的表示方式只有兩種：某種關係從未存在，或者它曾經存在、後來斷開。這兩個判斷當然有用，卻不足以覆蓋前面已經看到的全部情況。有些關係不是突然從「有效」跳到「無效」，而是在條件變化中逐漸失去原來的適用性；有些現實變化也不是 Component Failure，而是在原本允許的範圍內發生，卻仍然足以改變當前的 Execution Qualification。把這些不同變化全部壓進「斷了」或者「從未存在」兩種標籤，會丟掉判斷真正需要的信息。

因此，如果以後要建立一套更完整的關係表示，它至少需要能夠處理幾類不同的問題：關係是否從未存在；關係是否曾經存在但後來失效；關係的有效性是否依賴某個 Boundary；Execution Qualification 如何隨著 State 的變化而變化；以及一次 Component Failure 與一次被允許發生的 State Change 應該如何區分。

但這裡必須停住。這五項只是對未來表示能力提出的要求，並不意味著已經存在一個由五種狀態組成的模型，也不意味著它們彼此並列、互斥或者窮盡所有關係形態。現在甚至還不能確定，最終應該用狀態、關係、事件、約束，還是其他形式來表示這些變化。提前給它命名、畫出狀態遷移圖或者整理成固定分類，都會讓表達形式先於理論邊界成立。

其中一個原因，是「關係是否已經失效」本身也依賴幾個尚未統一的判斷口徑。系統 Boundary 怎樣劃定，Environment 是否被計算在內，Time Window 怎樣切分，以及 Component Failure 與 Allowed State Change 怎樣區分，都會直接影響某個變化最終應該被理解成什麼。只要這些前提沒有明確，同一個現實變化在不同邊界和時間尺度下就可能得到不同判斷。

因此，本章只走到這樣一個邊界：我們已經知道 State 與其他執行對象之間的關係不能只用「存在 / 不存在」或者「連接 / 斷開」來表達，也已經能夠指出未來的表示至少需要面對哪些問題，但這還不足以建立一個完整的 Relation-State Model。

能夠指出模型必須回答的問題，不等於已經擁有那個模型。

同樣，本章也不進一步建立 State Consistency Protocol、狀態同步機制或者具體數據結構。那些屬於更後面的實現問題，而它們需要的前提，比本章已經建立的 State 最小定義更多。

交出去的問題

到這裡，一次執行判斷的兩端都已經能夠被明確指認。規範側是上一章建立的 Intent，它描述那次 Action 原本希望發生什麼、作用於什麼對象以及允許到什麼範圍；現實側則是這一章建立的 State，也就是在當前時點，與這一次 Action 能否被判斷和執行直接相關的事實與條件。

這也解釋了為什麼「上個月已經批過」不能單獨結束今天的判斷。過去的 Approval 仍然是成立過的事實，Authorization 和 Policy 也沒有因此失去作用，它們都可以繼續作為輸入進入當前判斷；但它們面對的是形成它們時的對象、條件和 State，而今天的執行必須面對的是此刻真正存在的現實。把過去的判斷保留下來，與允許它自動替代當前判斷，是兩件完全不同的事。

然而，當 Intent 和 State 真正被放到一起以後，另一個此前一直被暫時擱置的問題就出現了：我們已經知道應該拿什麼進行比較，卻還沒有說明為什麼可以相信比對兩端本身成立。

Intent 為什麼能夠被認為仍然是原來那個 Intent？它在跨越多個系統、邊界和處理環節以後，憑什麼還能被認定為沒有被替換、汙染或者重新解釋？State 又為什麼能夠被認為就是此刻的現實事實，而不是一個已經過期、只在局部可見，或者僅僅與現實高度相關的代理記錄？

三里島案例正好把後一種問題顯露出來。控制室看到的信號在自己的語義中完全為真，操作人員也不需要讀錯那個信號，問題仍然可以存在，因為那個信號表達的不是閥門真實的機械位置。State 因此不能僅僅因為「系統裡有一個值」就證明自己成立，正如 Intent 也不能僅僅因為「系統裡保存著一份記錄」就證明自己仍然是原來的 Intent。

前面的章節已經能夠把這兩個對象指認出來，也能夠說明它們在執行判斷中分別承擔什麼作用，但把它們放進判斷的那一刻，系統其實已經預設了另一件事：這個 Intent 可以被信任為那個 Intent，這個 State 可以被信任為當前事實。

這個預設本身還沒有得到回答。那麼：判斷所依據的事實，憑什麼被認為成立？

本章術語

• 狀態 ｜ State
• 當前事實 ｜ Current Fact
• 代理記錄 ｜ Proxy Record
• 數據庫快照 ｜ Database Snapshot
• 執行資格 ｜ Execution Qualification
• 意圖 ｜ Intent
• 授權 ｜ Authorization
• 策略 ｜ Policy
• 證據 ｜ Evidence
• 邊界 ｜ Boundary
• 動作 ｜ Action
• 判斷 ｜ Judgment

本章案例與資料來源

三里島二號機組事故

1979 年 3 月 28 日，三里島二號機組發生事故。事故過程中，一隻洩壓閥在打開後卡在開啟位置，而控制室中的狀態指示所表達的是關閉信號已經發出，並不是閥門真實的機械位置；當時控制室也沒有能夠直接顯示該閥門真實位置的儀表。

本章只使用這個案例說明一個問題：代理記錄可以在自身語義上完全正確，卻仍然不等於當前事實。

關閉信號已經發出可以是真的，表示這一信號的儀表也可以正常工作，但這些事實不能自動推出閥門此刻確實已經關閉。當代理信號與真實機械狀態之間原本穩定的關係發生分離時，判斷側僅憑代理記錄本身無法識別這種變化。

這個案例不用於證明 State 的定義，也不用於證明本章關於 Authorization、Policy 或當前判斷不能自動複用的理論結論。State 的定義獨立於該事故成立；案例只用於幫助說明為什麼「與當前 Action 直接相關」不能被放寬成「與當前事實高度相關」。

同時，本章不把三里島事故簡化為單一的人機界面問題或操作人員失誤。監管機構對事故原因的描述涉及設備故障、設計相關問題與人員錯誤的共同作用，並指出可供人員使用的部分儀表提供了不充分或具有誤導性的信息。

資料來源

本章案例事實以監管機構公開的事故事實與技術材料為依據。

案例僅承擔工程說明作用：Proxy Record ≠ Current Fact

事故的完整因果鏈、組織因素、人機界面問題以及其他安全機制不在本章展開，也不作為本章 State 理論的證明材料。

本章涉及的 State、Intent、Authorization、Policy、Execution Qualification 與 Evidence 等概念，按照本書已經建立的定義與邊界使用。其中 State 的最小定義為：

狀態是在特定時點，與某次 Action 能否被判斷和執行直接相關的事實與條件集合。

關於 State 的來源資格、版本、時間、新鮮度、衝突、局部可見性與恢復狀態，本章只確認這些問題存在，不把它們組織成完整的 State Model；關於 Relation-State Model、State Consistency Protocol 以及具體數據結構，本章同樣不作定義。

---

第十章｜證據不是日誌

本章回答「憑什麼認為一個事實成立」。Evidence 不是 Log，也不是 Fact、State 或 Judgment 本身；它為一個與自身可區分的 claim、fact、state、relation 或 event 提供可驗證支撐。因此必須保持三元分離：被證明對象 ≠ Evidence ≠ 基於 Evidence 作出的 Judgment。事實不能因為被記錄就自動證明自己，Evidence 也不能因為存在就自動完成判斷。Log、Record、Signature 可以承載或參與形成 Evidence，卻不會僅憑記錄完整、簽名有效就自動取得 Evidence 的語義角色；載體與角色必須分開。Evidence 同樣不創造事實、不產生 Authority，也不自動產生 Execution Qualification。來源資格、綁定、時效和完整性等條件被刻意擋在 Evidence 本體之外，因為它們回答的是另一個問題：這份 Evidence 對當前 Judgment 來說夠不夠。於是下一章轉向 Evidence Sufficiency。

前兩章已經把一次執行前判斷所面對的兩端分別建立起來。第八章給出的是規範側的 Intent：這一次 Action 原本希望發生什麼、作用於什麼對象、落在什麼範圍內；第九章給出的是現實側的 State：在當前時點，與這一次 Action 能否被判斷和執行直接相關的事實與條件。

但把這兩個對象放到判斷裡，還不能直接開始比較。因為無論是 Intent 還是 State，都隱含著同一個更基礎的問題：憑什麼認為它成立？

系統裡保存著一份 Intent，並不自動說明它就是當初那個沒有被替換、汙染或者重新解釋的 Intent；系統報告當前連接數為零，也不自動說明現實中的連接數此刻確實為零。如果進入判斷的事實本身沒有得到支撐，那麼後面的比較即使完全正確，也只是把一個未經支撐的前提準確地傳遞到了現實動作上。

面對這個問題，一個很容易出現的回答是：「我有日誌。」

這個回答之所以有吸引力，是因為它把幾個原本不同的問題連在了一起：有記錄，似乎就有依據；有依據，似乎就能夠說明事實；能夠說明，似乎就已經完成了證明。但這條推理並不成立。記錄某件事，與為某件事提供能夠被驗證的支撐，並不是同一個動作；把記錄寫得更多、更完整，也不能自動補上兩者之間的差別。

第十章要處理的，就是這條邊界：當系統說「我有日誌」時，它究竟已經擁有什麼，又還缺少什麼。

被證明的東西不能是用來證明它的東西

要討論 Evidence 與 Log 的區別，首先必須把 Evidence 本身說清楚。在本書當前採用的定義中，Evidence 為一個與自身可區分的 claim、fact、state、relation 或 event 提供可驗證支撐。

真正承重的是「與自身可區分」。假設系統需要確認一個事實：**當前連接數是 0。**那麼這裡至少存在三個不同的對象。第一個是等待被確認的事實，也就是「當前連接數是 0」；第二個是用來支撐這個事實的 Evidence，例如與這次判斷相關的狀態讀取、簽名記錄或者其他可驗證材料；第三個則是系統讀取這些 Evidence 以後形成的 Judgment，例如「這些材料足以支持當前連接數確實為 0」。

用最簡單的話說，一個是要證明什麼，一個是拿什麼證明，最後一個是看完這些材料以後作出什麼判斷。

因此，本章需要保留這樣一個最基本的分離：

被證明對象 ≠ Evidence ≠ 基於 Evidence 作出的 Judgment

這三者之所以必須分開，並不是為了得到一個整齊的概念結構，而是因為任何一次合併都會改變它們原本承擔的作用。

如果把被證明對象與 Evidence 合成一件東西，就會出現自證。仍然以上面的例子來說，如果系統只是因為某條記錄寫著「當前連接數是 0」，就直接認為現實中的連接數確實為 0，那麼這條記錄既成了待證事實，又成了證明這個事實的材料。「記錄裡寫了什麼」與「現實中什麼成立」之間不再存在需要被驗證的距離。

如果把 Evidence 與 Judgment 合成一件東西，問題則發生在另一端。Evidence 原本只是判斷的輸入，現在卻開始替代判斷：材料一到齊，系統就自動認為條件成立；材料存在本身就等價於放行。這樣一來，本來應該發生在 Evidence 與現實 Action 之間的 Judgment 被整個省略了。

如果三個對象全部合在一起，系統就形成了一種自我證明的閉環：它自己執行，自己記錄，自己讀取記錄，再根據這份記錄確認自己的行為可以繼續。此時真正消失的不是某一條日誌，而是待證對象、支撐材料與判斷之間原本應當存在的距離。

因此，三元分離不是一種建模偏好。它守住的是一個非常基礎的工程邊界：事實不能因為被記錄就自動證明自己，Evidence 不能因為存在就自動完成 Judgment，而 Judgment 也不能反過來成為證明自身正確的 Evidence。

這裡同時需要保留一個關於定義強度的限制。目前，Evidence 的正式定義只有一處明確表述。其他相關論述與這一定義並不衝突，但這種兼容關係不能被視為第二個獨立定義來源，因為它們大多並沒有重新回答「Evidence 是什麼」這個問題。因此，本章後面的論證都建立在這一定義之上，同時保留這一單一來源所帶來的限制。

十條吸收路徑

既然 Evidence 被單獨作為一個對象提出，一個自然的追問就是：它真的需要獨立存在嗎？或者說，它其實只是 Fact、State、Log、Record、Signature、Proof、Authorization、Authority、Policy 或 Result 中的某一個，只是換了一個名字？

這十個對象都無法完整吸收 Evidence，但原因並不相同。最直接的一類問題發生在被支撐對象本身。Fact 不能吸收 Evidence，因為二者的方向相反：Fact 是等待被支撐的對象，而 Evidence 提供支撐。如果讓 Fact 同時承擔 Evidence 的角色，就又回到了上一節的問題——事實開始為自己證明自己。

State 也不能承擔這個角色。State 告訴判斷系統「此刻是什麼」，Evidence 要處理的則是「憑什麼認為此刻確實如此」。一個 State 可以在系統內部保持完全自洽，甚至在被改寫以後仍然表現得結構完整，因此 State 本身不能因為存在，就成為證明自身真實性的材料。第九章建立 State，正是為了讓當前現實進入判斷；到了這一章，它反過來成為需要 Evidence 支撐的對象之一。

Signature 的邊界又不同。簽名可以證明某份內容在簽署時以特定形式存在，也可以為內容完整性和來源關係提供重要支撐，但它不能自動證明被簽署內容所描述的現實事實本身為真。如果汙染髮生在簽名以前，一個完全有效的簽名仍然可以忠實地保護那份已經被汙染的內容。這裡需要區分的是「內容有沒有被正確簽署」和「內容描述的現實為什麼成立」。

Record 和 Log 更容易產生混淆，因為它們在工程系統裡往往正是 Evidence 的物理載體。一條記錄可以完整地保存某項聲明，一份日誌也可以準確記錄系統曾經輸出什麼，但「被寫下來」並不會自動提供來源資格、對象綁定、連續性或者事實真實性。記錄寫著某件事，與那件事因此成立，仍然隔著一個需要被驗證的距離。

Proof 不能在這裡吸收 Evidence，理由則不同。目前本書並沒有為 Proof 建立一個可檢查的定義，它只作為更高層的概念名稱出現。用一個尚未定義的對象去解釋一個已經具備邊界的對象，只會把問題從「Evidence 是什麼」移動到「Proof 又是什麼」，而不會真正減少概念。因此，Proof 與 Evidence 之間最終應當如何區分或關聯，在這裡繼續保持未決，本章不為了補齊結構而額外定義 Proof。

Authorization 和 Policy 也處在不同方向上。Authorization 處理主體是否擁有或使用某類能力的資格邊界，但 Evidence 可以支撐的遠不止 Authorization；當前條件、Judgment、Boundary State 和 Result 都可能成為被支撐對象。Policy 則描述在特定條件下應當如何判斷或約束 Action，它提供規則，卻不負責記錄現實究竟發生了什麼。規則可以保持不變，而它所面對的世界已經發生變化，因此 Policy 不能替代關於現實事實的 Evidence。

Result 同樣不能完成這種替代。系統報告「執行成功」，這句話首先仍然是一個待證的 Claim。執行被嘗試過、系統返回了成功狀態，以及現實中的預期結果真正發生，是幾個可能需要進一步區分的問題。Result 因而可以成為 Evidence 所支撐的對象，卻不能因為它位於流程末端就自動承擔自己的證明。

Authority 的問題更特殊，因為它涉及的已經不是「Evidence 是什麼」，而是「誰能夠讓 Action 成為現實」。這一條留到後面的權力邊界中單獨處理。

因此，這十個對象並不是 Evidence 的十種類型，也不構成一套 Evidence taxonomy。這裡沒有所謂「Signature Evidence」「Log Evidence」這樣的種屬關係需要被建立。十條路徑只回答一個更基礎的問題：能不能把 Evidence 完全併入某個已經存在的對象，從而取消它作為獨立語義角色的必要性。就目前建立的邊界而言，不能。

但「不能等同」也不意味著這些對象之間互不相干。尤其是 Log、Record 和 Signature，它們完全可以成為 Evidence 的載體，也可以參與 Evidence 的生成與保存。這裡必須區分物理或數據載體與它在判斷結構中承擔的語義角色。

**載體不是語義角色。**一份 Log 可以承載 Evidence，就像一張紙可以承載一份合同；紙本身不是合同，Log 也不會僅僅因為記錄得完整，就自動獲得 Evidence 的身份。因此，「我們擁有完整的審計日誌」與「我們已經擁有足以支撐某個事實的 Evidence」仍然是兩個需要分別回答的問題。

定義裡沒有的東西

Evidence 被單獨建立起來以後，它的邊界還需要繼續往裡收。除了「為與自身可區分的對象提供可驗證支撐」之外，還必須明確四件它不做的事：Evidence 不創造事實，不作出 Judgment，不產生 Authority，也不自動產生 Execution Qualification。

這四條不是後來附加在 Evidence 上的使用限制，而是 Evidence 仍然能夠保持自己身份的條件。如果 Evidence 可以創造事實，那麼記錄什麼就會變成發生什麼；如果 Evidence 可以直接作出 Judgment，那麼材料齊備本身就會變成 Decision；如果 Evidence 可以產生 Authority，那麼保存或持有材料的一方就會因為掌握 Evidence 而獲得讓現實發生的權力；如果 Evidence 自動產生 Execution Qualification，那麼「材料存在」與「允許執行」之間原本應該存在的判斷過程也會被整個跳過。到了這些位置，得到的都不是一種更強的 Evidence，而是另一個對象。

這條邊界在工程裡很容易被不經意地穿過。比如，一條記錄寫著「檢查已通過」，如果沒有其他支撐，那麼它真正證明的只是「系統裡存在一條這樣的記錄」，而不是檢查本身確實通過。記錄的存在與事實的成立之間仍然隔著需要被驗證的距離。類似地，當系統說「材料已經齊了，所以可以執行」，它也把兩個不同的問題合併了：Evidence 是否存在，以及基於這些 Evidence 應當作出什麼 Judgment。前者可以成為後者的輸入，卻不能替代後者。

與這四條否定同樣重要的是，Evidence 的最小定義還故意沒有包含另外七項條件：**來源資格、對象綁定、時效、內容完整性、順序完整性、集合完整性和存續性。**這些條件顯然都很重要，但它們處理的是另一個問題——不是「這是不是 Evidence」，而是「這份 Evidence 對這一次 Judgment 來說夠不夠」。

這一區分不能在定義層被抹掉。如果把來源資格、時效或者完整性之類的條件直接寫進 Evidence 本體，那麼一旦某項條件不滿足，這份材料在定義上就會被排除成「不是 Evidence」。這樣一來，「Evidence 已經存在，但 Evidence 不充分」這句話本身就失去了表達空間，而工程系統恰恰需要能夠區分這兩種情況。

這些條件也會隨著具體環境而變化。不同系統對來源、時間、新鮮程度、順序以及保存期限的要求可能完全不同；如果把這些變化中的工程要求寫進 Evidence 的最小定義，Evidence 本身就會隨著部署方式和基礎設施變化而改變。更重要的是，一旦這些條件被納入本體，「Evidence 存在」和「Evidence sufficient」就會被定義性地合併，後面再討論「什麼時候算夠」就已經沒有獨立問題可言。

因此，本章在這裡必須保留一個清楚的邊界：Evidence 的本體和 Evidence 的充分性是兩個不同層面。第十章回答的是前者——什麼對象可以承擔 Evidence 的語義角色；來源資格、對象綁定、時效、內容完整性、順序完整性、集合完整性和存續性，則留給後一個問題去處理：在一次具體的執行判斷中，已經存在的 Evidence 在什麼條件下才算足夠。

這裡關於 Evidence 本體的論述仍然受到前面那項限制：目前正式定義只有一處明確來源。其他相關表述與之兼容，但這種一致並不構成第二個獨立定義來源，因此這一限制不會因為本章繼續展開而消失。

憑什麼說它不是日誌

說「Evidence 不是 Log」並不困難，真正困難的是說明兩者究竟可以怎樣被區分。如果只能依靠名稱、格式或者系統裡的字段類型來判斷，那麼所謂區別就仍然只是命名上的區別。

這裡可以從三個不同方向觀察一份材料。第一個方向是驗證獨立性：這份材料所表達的內容，能不能在不依賴被驗證對象自身陳述的情況下被驗證。判斷的重點不是它能否被讀取，也不是格式是否完整，而是驗證過程是否必須相信被驗證方自己給出的說法。一個系統對自身行為留下的描述可以非常詳細，但如果驗證仍然完全依賴這個系統自己提供的數據，那麼「記錄得很完整」與「能夠獨立驗證」仍然不是同一件事。

第二個方向看的是這份材料在決策路徑中的位置。一個很直接的判斷方式是：如果把這份材料從系統裡拿掉，系統的行為會不會改變。如果它消失以後系統仍然照常判斷、照常放行，那麼它至少沒有承擔當前決策所依賴的輸入角色；它更接近觀察、歸檔或事後說明材料。反過來，如果缺少它以後某個判斷無法繼續，就說明它確實位於決策路徑之中。這裡判斷的不是材料叫什麼，而是系統實際上是否依賴它。

第三個方向是信任域分離。這裡關心的不是內容，也不是調用順序，而是誰能夠改變這份材料，以及誰能夠實施被它記錄或約束的行為。如果同一個主體既能夠完成某項 Action，又能夠無痕修改關於該 Action 的記錄，那麼這份材料在對抗條件下的支撐能力就會受到限制，因為行為與關於行為的記載處在同一個失陷邊界內。

這三個方向觀察的是不同問題，因此存在通過其中一個方向，卻在另一個方向上失效的情形。例如，一個 Executor 可以讀取自己生成的記錄，並依據那份記錄決定是否繼續執行。此時，刪除記錄確實會改變系統行為，所以這份記錄處於決策路徑上；但記錄和被記錄的行為仍然由同一個主體控制，因此驗證獨立性並沒有隨之成立。

這裡必須守住一個很重要的邊界：**這三個方向不是一套已經完成的 Evidence 判定清單。**任何單獨一個判據都不足以獨立決定某份材料是不是 Evidence，通過其中一條不自動獲得 Evidence 身份，不通過其中一條也不能單獨推出它必然不是 Evidence。每一條只暴露一個不同方向上的關係。

三者聯合起來是否構成必要條件，目前沒有建立；三者聯合起來是否已經足以完成判定，同樣沒有建立。能夠確認的只是，它們彼此觀察不同問題，並且存在一條成立而另一條不成立的情形。把這種獨立性進一步提升為「三條必須同時滿足」或者「滿足三條就足夠」都會多走一步，而這一步沒有現成支撐。

所以這裡不應該把三條讀成一個可以逐項打勾的 Checklist。它們更像三個不同的觀察方向，用來幫助識別為什麼某些 Log 即使非常完整，仍然沒有自動獲得 Evidence 在判斷結構中的語義角色。

但這一區分也絕不意味著 Log 沒有價值。審計日誌仍然承擔運維、調試、可觀測性和事後分析等重要作用，一般業務系統也完全可以依賴 Log 解決大量問題。本章要區分的只是另一種場景：當某份材料要參與一次關於現實 Action 是否應該發生的判斷時，「系統留下了日誌」本身還沒有回答「為什麼可以相信這裡面的事實」。

因此，**Evidence ≠ Log 是角色區分，不是替代關係。**Log 可以繼續存在，也可以成為 Evidence 的載體；真正需要額外回答的是，它在這一次 Judgment 中究竟憑什麼承擔 Evidence 的作用。

證據不做決定

前面的十條吸收路徑裡，還有一個對象需要單獨處理：Authority。它與 Fact、State、Log 或 Signature 不同，因為這裡涉及的已經不是 Evidence 能否被另一個對象解釋，而是誰擁有讓現實 Action 發生的權力。

Evidence 不是 Authority。它可以進入 Judgment，可以支撐 Judgment，也可以讓一個已經作出的 Decision 獲得可驗證基礎，但它不能因為自身存在、完整或者數量足夠，就自動取得裁決的位置。

證據不做決定，它讓決定可被檢驗；一旦它開始決定，它就已經不再是證據。

這裡說的不是一種使用建議，而是語義角色的變化。Evidence 在判斷結構中的位置是支撐某個 Claim、Fact、State、Relation 或 Event；如果它開始直接承擔「允許還是拒絕」的裁決，那麼它已經從支撐判斷的對象變成了作出判斷的對象。無論系統仍然把它命名為 Evidence、Proof 或其他名稱，這個角色都已經發生了變化。

與這一邊界相關，還有一個「Proof Authority」的表述。這裡所謂 Proof Authority，只表示生成、簽署與保存關於執行過程和結果之可信 Evidence 的能力。它不同於普通的 Log write access，也不能通過修改記錄去改變已經發生的事實。這個邊界很重要，因為 Evidence 所能影響的是事實如何被記錄、支撐和驗證，而不是事實本身是否曾經發生。

圍繞這一點，已有多條相互獨立的權力邊界表達，方向是一致的：從 Evidence 的讀取、保存到後續 Runtime 使用，Evidence-side capability 本身都不會因此產生 Execution Authority，也不會獲得創造現實事實的能力。能夠保存某個事實的記錄，與能夠讓那個事實發生，是完全不同的兩種能力。

至於 Proof Authority 是否應該繼續分解、由誰持有、是否需要與其他 Authority 進一步分離，以及這些 Authority 之間應當怎樣建立關係，本章都不作正面定義。這裡使用 Authority，只為了守住一條否定邊界：保管、生成或驗證 Evidence，不會因此自動獲得讓 Action 成為現實的權力。

這一點直接擋住了一個很容易發生的推導：Evidence chain 已經完整，所以系統可以放行。完整的 Evidence chain 說明支撐 Judgment 的材料已經存在，但「材料存在」和「Judgment 的結果是 ALLOW」仍然不是同一個命題。兩者之間還隔著一次判斷，而這次判斷不會因為 Evidence 已經齊備就自動消失。

如果系統把「Evidence 齊備」直接實現成「Action 放行」，那麼它實際上已經把 Evidence 與 Judgment 合併了，同時又讓這個合併後的對象獲得了現實執行權。這樣一來，上一節建立的三元分離就被重新壓回到一起，而 Evidence 也已經不再只是 Evidence。

發生過，和為什麼被允許發生

Evidence 還有一個很容易被縮窄的用法：把它理解成只在事情發生以後才需要的材料。這個印象並不難理解，因為 Log、Audit Record 和各種運行記錄經常被用來追查已經發生的事情。但如果 Evidence 只在事後出現，它就只能幫助解釋結果，無法支撐執行發生之前的判斷。

這裡必須把兩個問題分開：

Action happened.

以及：

Why was this Action allowed to happen?

第一個問題問的是現實中發生了什麼。Log 很適合回答這一類問題：什麼時候發生、哪個主體參與、使用了什麼參數、系統返回了什麼結果，都可以被記錄下來。

第二個問題問的卻不是結果，而是判斷。它追問的是：在 Action 成為現實之前，系統依據什麼認為這一次 Action 可以繼續。要回答這個問題，需要的不只是執行之後留下來的記錄，還需要能夠支撐當時 Intent、State、Boundary 和 Judgment 的材料。只有知道當時拿什麼作比較、面對什麼現實條件、依據什麼形成判斷，才能解釋「為什麼這一次 Action 被允許發生」。

如果這些材料在執行發生時從未存在，事後再增加更多日誌，只會得到對「發生了什麼」更詳細的描述，而不會自動補出「為什麼當時可以發生」的答案。

因此，Evidence 在執行控制中不能被限定為事後審計材料。它可以承擔執行依據、狀態證明、決策證明、邊界證明、結果關聯和事後驗證等不同作用，其中事後驗證只是其中之一。這裡不為這些作用建立統一的時間結構，也不把它們排列成固定流程；需要保留的只是一個邊界：Evidence 的作用並不從 Action 結束以後才開始。

這也和 Evidence 的最小定義一致。Evidence 可以支持關於執行前條件、執行判斷、邊界狀態或執行結果的可驗證事實，它不只是 Log，也不是任何被記錄的數據。記錄存在不等於事實成立，Receipt 不等於完整的執行 Evidence，而 Evidence 本身也不會決定 Action 是否應該發生。

圍繞這個對象，還可以明確幾種失效情形：來源不具資格、對象綁定錯誤、關鍵階段缺失、連續性斷裂，或者材料能夠被無痕覆蓋、替換或刪除。這些問題都會削弱 Evidence 在判斷中的作用，但這裡不能把它們和下一層關於 Evidence sufficiency 的條件合併成一份完整清單。兩組問題並不承擔相同角色，強行合併只會製造一個看起來完整、實際上沒有被建立的分類。

Receipt 在這裡也只表示一種邊界上的記錄形態，而不是已經定義完成的 Evidence subtype。本章不因此建立「Receipt Evidence」「Log Evidence」或其他 Evidence taxonomy。

所以，「系統能夠證明某件事發生過」與「系統能夠證明為什麼當時允許它發生」，始終是兩個不同的問題。一個系統完全可能把前一個問題回答得非常完整，卻從未為後一個問題保留足夠的支撐材料。

立起來了，還不算夠

到這裡，Evidence 的本體邊界已經可以被清楚描述。它為一個與自身可區分的 Claim、Fact、State、Relation 或 Event 提供可驗證支撐；被證明對象、Evidence 與基於 Evidence 作出的 Judgment 不能互相替代；Evidence 不創造事實，不作出 Judgment，不產生 Authority，也不自動產生 Execution Qualification。它可以由 Log、Record 或 Signature 等載體承載，但載體本身不會因此自動獲得 Evidence 的語義角色。

與此同時，本章也留下了幾項不能被順手補齊的限制。目前 Evidence 的正式定義仍然只有一處明確來源，其他相關表述與它兼容，卻不能因此被視為獨立的第二定義來源。驗證獨立性、決策路徑位置和信任域分離這三個觀察方向彼此不同，但它們聯合起來是否構成必要條件、是否已經足夠完成 Evidence 判定，都沒有被建立。Proof 在本書當前體系中也仍然沒有一個可檢查的定義，本章不為了得到一個更整齊的結構而替它補出答案。

這些限制不會因為增加更多例子而自動消失。案例可以暴露某個定義或判斷的反例，卻不能憑自身創造第二個獨立定義來源；同樣，一個具體系統恰好滿足三條觀察方向，也不能因此證明三者在一般意義上聯合必要或者聯合充分。因此，本章能夠建立的是 Evidence 的邊界，而不是把所有與 Evidence 有關的問題一次解決完。

真正需要交給下一章的，正是這個邊界之外的問題。一份材料即使已經能夠被認定為 Evidence，也不意味著它對任意一次 Judgment 都已經足夠。一個對象「是 Evidence」，回答的是它在判斷結構中承擔什麼語義角色；「Evidence 是否充分」，問的則是這些材料對於當前這一次具體判斷，能不能支撐系統繼續走向現實 Action。

這也是為什麼來源資格、對象綁定、時效、內容完整性、順序完整性、集合完整性和存續性沒有被直接寫進 Evidence 的最小定義。它們的重要性並沒有被否定，恰恰相反，正因為系統必須能夠表達「Evidence 已經存在，但仍然不充分」，Evidence 的本體與充分性才必須保持分離。

證據本身有了——那麼什麼時候算夠？

說得更準一點：證據在什麼條件下足以支撐這一次執行判斷？「夠」與「是證據」，是不是同一件事？

本章術語

• 證據 ｜ Evidence
• 待證對象 ｜ Object Under Verification
• 聲明 ｜ Claim
• 事實 ｜ Fact
• 狀態 ｜ State
• 關係 ｜ Relation
• 事件 ｜ Event
• 判斷 ｜ Judgment
• 日誌 ｜ Log
• 記錄 ｜ Record
• 簽名 ｜ Signature
• 權威 ｜ Authority
• 執行資格 ｜ Execution Qualification
• 驗證獨立性 ｜ Verification Independence
• 決策路徑 ｜ Decision Path
• 信任域分離 ｜ Trust-Domain Separation
• 收據 ｜ Receipt

關於 Proof

本章使用 Proof 這一術語，但不為其建立正式定義。因此，Proof 不應被理解為 Evidence 的上位類型、同義詞或已經完成定義的相鄰概念。本章只確認：不能用一個尚未定義的 Proof 去吸收已經具有明確邊界的 Evidence。

同樣，「證明權（Proof Authority）」在本章只作為既有表述用於說明 Evidence 與 Authority 的邊界，不據此建立新的權力類型、權力分解或治理結構。

本章案例與資料來源

本章無現實案例。

正文中使用了兩個工程情境。第一個情境是：系統中存在一條「檢查已通過」的記錄。它用於說明，記錄中出現某項聲明，只能首先證明「存在這樣一條記錄」，不能僅憑記錄本身推出該檢查在現實中確實已經通過。

第二個情境是：Executor 讀取自己生成的記錄，並依據這份記錄決定是否繼續執行。這個情境用於說明驗證獨立性、決策路徑位置和信任域分離分別觀察不同問題。一份材料可以真實處於決策路徑中，卻仍然缺乏獨立驗證能力，因此這些判據不能被合併成一套「滿足若干項即可認定為 Evidence」的 Checklist。

這兩個情境都不是現實事故、公司事件或歷史案例，也不承擔 Evidence 定義的證明作用。

資料來源

本章不依賴現實事件建立 Evidence 的定義，因此沒有需要單獨列出的事故、公司或歷史事件來源。

本章建立的核心邊界包括：

被證明對象 ≠ Evidence ≠ 基於 Evidence 作出的 Judgment

以及：

Evidence 不創造事實，不作出 Judgment，不產生 Authority，也不自動產生 Execution Qualification。

同時，本章只建立 Evidence ≠ Log 的語義角色區分，並不主張 Log 應當被 Evidence 取代。Log、Record 和 Signature 都可以成為 Evidence 的載體，但載體本身不會自動獲得 Evidence 的語義身份。

關於來源資格、對象綁定、時效、內容完整性、順序完整性、集合完整性和存續性，本章只確認這些條件屬於「Evidence 是否足夠」的問題，不把它們寫入 Evidence 的最小定義，也不在本章建立 Evidence Sufficiency Model。

Proof 的正式定義、三項判據之間的聯合必要性與聯合充分性，以及 Proof Authority 的內部結構與歸屬關係，均繼續保持開放，本章不為這些問題提前補出答案。

---

第十一章｜什麼時候算夠

本章把「是 Evidence」與「這份 Evidence 對當前 Judgment 夠不夠」徹底分開。同一份 Evidence 可以保持身份不變，卻因為 Action、時點或使用情境變化而不再充分。來源資格、對象綁定、時效、內容與順序完整性、集合完整性和存續性等要求，因此屬於 Sufficiency 一側，而不是 Evidence 本體；Evidence Presence ≠ Evidence Sufficiency。進一步地，「夠不夠」還至少包含兩個問題：材料本身是否足以被依賴，以及它是否足以支撐眼前這一次 Judgment。前一次充分，也不能自動轉移到下一次 Action。當前材料可以指出若干候選充分性方向，卻還不能把它們凍結成完整 taxonomy、Checklist 或評分表；Missing、Evidence Gap 與 Conflict 也不能被壓成同一種不足。真正留下的問題是：如果所需條件就是無法充分建立，系統應該怎麼辦？

上一章已經把 Evidence 的本體邊界建立起來：被證明對象、Evidence 與基於 Evidence 作出的 Judgment 不能互相替代；Evidence 不創造事實，不作出 Judgment，不產生 Authority，也不自動產生 Execution Qualification。

但確認一個對象「是 Evidence」，並沒有回答另一個問題：它對眼前這一次 Judgment 來說夠不夠。

這兩個問題看起來只差一步，實際上屬於兩個不同層面。「這是不是 Evidence」問的是某份材料在判斷結構中承擔什麼語義角色；「這份 Evidence 夠不夠」問的則是它能否支撐當前這一次具體 Judgment。前一個問題處理對象身份，後一個問題處理對象與具體判斷之間的充分性關係。

因此，同一份 Evidence 可以在身份上保持不變，卻在不同 Judgment 面前得到不同的充分性判斷。它可能足以支撐這一次 Action，卻不足以支撐另一項影響範圍更大的 Action；它也可能在某個時點仍然足夠，而在現實條件變化以後不再足以支撐新的判斷。發生變化的並不是它是否屬於 Evidence，而是這份 Evidence 與當前 Judgment 之間的關係。

正因為如此，「是 Evidence」與「對這一次 Judgment 足夠」不能被合併成同一個答案。前者一旦成立，不能自動推出後者；而後者離開具體 Judgment、當前條件和當前 Action，也無法單獨得到有意義的回答。把兩者合併，只會讓「Evidence 已經存在」被誤讀成「當前 Judgment 已經獲得充分支撐」。

第十一章處理的，就是這個被第十章有意留下的問題：Evidence 已經存在以後，什麼條件決定它是否足以支撐眼前這一次執行判斷。

七項條件被擋在定義之外

圍繞 Evidence，有七項條件需要和它的本體嚴格分開：**來源資格、對象綁定、時效、內容完整性、順序完整性、集合完整性和存續性。**這些條件分別對應一份支撐材料在實際被依賴時需要面對的問題，但它們都沒有被寫進 Evidence 的本體定義。

這條邊界可以壓縮成一句：

ESSENCE ≠ SUFFICIENCY CONDITIONS

本體不等於充分性條件。七項屬於 Sufficiency 一側，不屬於 Evidence 的定義本身。

之所以要把它們擋在本體之外，有三條彼此獨立的理由，其中任何一條都足以支持這種分離。

第一條涉及「Evidence 不充分」這句話還能不能成立。如果某項充分性條件本身就是 Evidence 的定義條件，那麼只要其中一項沒有滿足，這個對象在定義上就已經不再是 Evidence。這樣看似把定義收得更嚴，實際上卻失去了描述另一種非常重要狀態的能力：材料確實承擔 Evidence 的語義角色，但它對於當前 Judgment 來說還不夠。此時真正需要表達的不是「沒有 Evidence」，而是「Evidence 已經存在，但不充分」。

第二條涉及本體是否會隨著工程環境漂移。來源資格、時效、完整性、存續性等要求都可能隨著系統形態、部署環境和具體約束髮生變化。如果這些條件被寫進 Evidence 的定義，那麼工程條件一變，「什麼算 Evidence」也會跟著變化。條件收緊時，原本作為 Evidence 存在的對象會因為新要求而失去身份；條件放寬時，一批此前不滿足要求的對象又會突然獲得 Evidence 身份，而這些變化都不是因為對象的語義角色發生了改變，只是因為外部條件變了。本體如果隨著具體配置一起漂移，就很難在不同系統和不同時間之間保持穩定含義。

第三條涉及一個必須單獨保留的區分：

**Evidence Presence ≠ Evidence Sufficiency**

Evidence 存在，不等於 Evidence 已經充分。如果把 Sufficiency Conditions 直接寫成本體條件，那麼只要一個對象能夠被稱為 Evidence，它就已經在定義層滿足充分性，「存在」與「充分」也就被合併成了同一件事。這樣一來，第十一章要討論的整個問題都會在定義層被提前消失掉。

這三條理由分別從表達能力、本體穩定性以及 Presence / Sufficiency 分離三個方向說明了同一件事：Sufficiency 不能由 Evidence 的身份定義提前完成。只有把兩者分開，系統才能準確表達一種非常重要的情況——Evidence 已經存在，但它對眼前這一次 Judgment 仍然不夠。

把七項排除出本體，並不等於取消這些要求。獨立可驗證性位於 Sufficiency 與質量屬性一側，不進入 Evidence 本體；對象綁定同樣屬於 Sufficiency；集合完整性與順序完整性也是如此。把本體與充分性分開，不是在降低要求，而是讓「它是什麼」和「它夠不夠」分別在各自的問題中被判斷。

為了避免七項在連續敘述中被誤讀成「Evidence 的七個構成要素」，這裡把它們集中列出，但必須連同各自的非本體歸屬一起閱讀。

表 II-1｜被排除出 Evidence 定義的七項條件及其歸屬

第三列中的兩個信息需要分開理解。來源強度描述的是當前有多少獨立來源支持這一條件：multi-source 表示存在多個來源支持，two-source 表示目前只有兩個來源。當前狀態描述的則是這一條件在理論上的成熟程度：CANDIDATE 表示它已經有依據進入討論，但尚未被確立為 Evidence Sufficiency 的最終主維度。

因此，multi-source 不表示這個條件比 two-source 更重要，CANDIDATE 也不表示這個條件可有可無。第三列只記錄兩個事實：它目前有多強的來源支撐，以及它是否已經完成理論收口。

這張表最重要的仍然是第二列。七項任何一項不成立，都不能因此把對象直接從 Evidence 的身份中刪除；它表達的是「這份 Evidence 不充分」，而不是「這不是 Evidence」。

表 II-1 也不能反過來被讀成 Evidence 的定義表。它不是 Sufficiency Conditions 的完整清單，不是已經完成凍結的條件集，也不是判定表或評分表；這裡沒有權重、優先級和閾值，七項之間也沒有被建立為互斥或者窮盡的分類維度。它只說明兩件事：這些問題已經能夠被明確指出，而它們統一不屬於 Evidence 本體。

「夠不夠」本身是兩個問題

把 Sufficiency 從 Evidence 本體中分離出來以後，還不能立刻得到一個統一的「夠不夠」判斷。這裡實際上存在兩個不同的問題。

Constitutive Sufficiency 問的是：某個對象本身是否足以作為可依賴的 Evidence 成立。

Use Sufficiency 問的是：即使這份 Evidence 本身成立，它是否足以支撐當前這一個具體 Judgment。

這兩者不是先後兩步，也不是第一層通過以後再在其上增加第二層要求。它們之所以需要被分開，是因為一份在構成上完整的 Evidence，可能在某個具體使用時點不足以支撐眼前的 Judgment。此時材料本身沒有因此失去 Evidence 身份，發生變化的是它與當前 Action、當前條件以及當前 Judgment 之間的關係。

設想一份在形成時來路清楚、內容完整、綁定明確的支撐材料。它曾經足以支持一次具體 Judgment。此後，系統面對的是另一項 Action：對象不同、影響範圍不同，或者發生的時間已經改變。這份材料本身可能沒有發生任何變化，構成上仍然成立，但新的 Judgment 問的是另一件事——它是否足以支撐現在這一次 Action。前一次判斷中成立過的充分性，不能自動轉移到後一次判斷。

這個情境只是為了展示兩個問題可以分開成立，並不承擔本章結論的證明作用。在這個情境裡，Constitutive Sufficiency 可以保持成立，而 Use Sufficiency 仍然需要針對新的 Judgment 重新回答。

因此，第二條不等式必須和前面的 Evidence Presence ≠ Evidence Sufficiency 同時保留：

Valid Evidence ≠ Sufficient Evidence for this decision

前一條區分的是「Evidence 已經存在」與「Evidence 已經充分」；這一條進一步區分「這是一份有效的 Evidence」與「這份 Evidence 足以支撐當前 Judgment」。一個擋住「有就是夠」，另一個擋住「成立就是夠」。

這裡尤其不能把 Constitutive Sufficiency 和 Use Sufficiency 讀成一條檢查流程。如果把兩者理解成先後步驟，充分性檢查就可以被整體前移到 Evidence 被取得或形成的那個時點：只要當時檢查通過，以後就默認繼續有效。但 Use Sufficiency 所面對的恰恰是當前這一次 Judgment，它依賴於此刻面對的 Action、條件和使用情境，因此不能由過去一次構成性檢查提前完成。

需要保留的最後一個限制是：Constitutive Sufficiency 與 Use Sufficiency 目前只是用來區分兩個問題面的分析性名稱。它們是否應當進一步進入正式概念層，仍然沒有結論。本章使用這兩個名稱來保持問題清晰，但不因此把它們建立為已經定型的正式理論對象。

十項，各自站得有多穩

如果繼續追問 Evidence Sufficiency 可能涉及哪些條件，目前可以明確指出十個候選方向：來源資格（source qualification）、身份（identity）、綁定（binding）、時效與時間有效性（freshness · temporal validity）、內容完整性（content integrity）、順序完整性（sequence integrity）、集合完整性（set completeness）、連續性（continuity）、存續與留存（persistence · survival），以及跨來源一致性（cross-source consistency）。

這十項獲得的支撐強度並不完全相同。其中九項目前具有 multi-source 支撐，時效與時間有效性為 two-source。這個差異需要保留，但它不能被讀成重要性排序。來源更多，不意味著某個條件權重更高；來源較少，也不意味著它可以忽略。這裡記錄的只是這些候選條件目前獲得支撐的廣度，而不是它們在一次 Judgment 中應該佔據多少權重。

更重要的是，整個十項集合目前仍然處於 CANDIDATE 狀態。也就是說，這些條件都有依據被提出和討論，但目前沒有足夠依據把它們宣佈為 Evidence Sufficiency 的完整主維度集合。CANDIDATE 並不否定這些條件本身，它限制的是我們能夠從這個集合進一步推出什麼。

因此，可以使用這十項去檢查一份 Evidence，卻不能在十項全部沒有發現問題以後直接宣佈「Evidence 已經充分」。只要這個集合仍然不是一個已經建立的完整集合，十項全部通過能夠說明的最多是：**在目前這十個候選方向上沒有發現問題。**它不能進一步證明不存在尚未進入集合的其他充分性條件。

這也是為什麼十項不能被直接理解成一張 Evidence Sufficiency Checklist。Checklist 的「全部通過」通常暗示檢查範圍已經完整，而這裡恰恰沒有建立這種完整性。

十項與上一節的七項之間也不能作簡單的集合對齊。十項中出現了身份、連續性和跨來源一致性，而上一節的七項中沒有這三項，但這並不意味著七項只是十項的一個子集。現有關於 Sufficiency 的表達還存在其他枚舉，其中有六條件、五要素以及另一組五項表達，它們彼此之間同樣存在缺項。這些差異表明，各組枚舉並不是從同一個已經確定的分類體系中裁剪出來的，因此不能通過取並集或者補缺項的方式人為構造一個所謂「完整集合」。

基於同樣的原因，本章不建立正式的 Evidence Sufficiency Taxonomy。十項繼續保持 CANDIDATE，來源強度繼續保留，但不賦予它們已經建立的層級關係、互斥關係或窮盡性。否則，一個尚未完成理論收口的候選集合就會因為排版和命名看起來像是一套已經完成的模型。

還有一項邊界需要繼續保留。上一章用於區分 Evidence 與 Log 的那組判據，其聯合必要性和聯合充分性目前仍然沒有結論。本章只保留這一未決狀態，不重新展開那組判據，也不借 Sufficiency 的討論替它補出答案。

沒有升格的，和不會被補進來的

在這些候選條件周圍，還有三項已經有了明確去向：獨立可驗證性（independent verifiability）、可重複驗證性（re-verifiability）和來源綁定（origin binding）。三項都沒有被提升為新的獨立主維度，但「不升格」並不意味著它們得到了相同的處理。

獨立可驗證性的去向最明確。它被接受為一項候選的 Sufficiency Condition，並歸入 Constitutive Sufficiency 一側，用來追問某個對象本身是否足以成為可依賴的 Evidence。但這項歸屬同時帶著一個明確邊界：**獨立可驗證性不得寫入 Evidence 的本體定義。**它回答的是「這份 Evidence 在構成上是否足以被依賴」，不是「這個對象是不是 Evidence」。

可重複驗證性的處理不同。它被保留為一個由現有依據推導出的質量屬性，與 Proof 存在相鄰關係，但沒有被建立為獨立的主 Sufficiency 維度。這裡還必須保留一個未決點：Proof 本身在當前理論中沒有正式定義，因此「與 Proof 相鄰」不能繼續被展開成一個更完整的關係模型。能夠確定的是可重複驗證性不升格；至於它與 Evidence、Proof 之間最終是什麼關係，本章不補答案。

來源綁定的邊界更窄。它被保留為一個已有條件的特化，而不是新的獨立主維度，因此同樣不升格。

所以，三項裁決真正確定的是三件不同的事：獨立可驗證性有了 Sufficiency 一側的歸屬，可重複驗證性保留為質量屬性，來源綁定保留為特化。它們都沒有因此取得與十個候選主維度並列的地位。

這裡尤其不能把「三項已經裁決」誤讀成「Sufficiency 已經收口」。被確定的只是這三項各自如何處理，Evidence Sufficiency 的最終條件集仍然保持 CANDIDATE。局部對象有了去向，並不能反過來證明整個集合已經完整。

這一區分很重要，因為一種性質真實存在、工程上有價值，並不自動意味著它必須被建立成獨立主維度。一旦某項性質被升格為主維度，讀者自然會把它理解為需要與其他主維度並列檢查，並進一步推斷它具有獨立邊界、穩定地位甚至窮盡意義。本章對這三項都沒有建立這樣的依據，因此不賦予它們這種地位。

還有一個看起來非常自然、卻不能因此被補入的概念：不可否認性（non-repudiation）。

來源資格、綁定、順序完整性、存續性這些條件放在一起時，熟悉密碼學、數字簽名和審計系統的讀者很容易自然聯想到 non-repudiation。但在本章當前已經建立的理論依據中，non-repudiation 沒有被建立為 Evidence Sufficiency 的條件或主維度。它的狀態只能保持：

NOT ESTABLISHED

這裡的意思不是「它已經被評估，然後被否決」，而是目前沒有依據把它放進這套條件結構裡。

因此，**不得僅憑密碼學常識把 non-repudiation 補成所謂第十一項。**專業常識可以幫助我們提出問題，卻不能替代本書建立理論對象所需要的依據。把一個熟悉、合理甚至在其他體系裡非常重要的概念補進來，會讓條件集合看起來更完整，但這種完整性並不是本章已經建立的結論。

有記錄，不等於夠

在前面的條件中，存續性和順序完整性尤其容易與具體技術實現混在一起，因此這裡必須把條件、載體和實現繼續分開。

Log、Record 和 Signature 都可以成為 Evidence 的載體，也可以參與 Evidence 的生成，但載體本身不是語義角色。一份 Log 是否承擔 Evidence 的作用，不取決於它是不是 Log；一份內容是否經過 Signature，也不能因此自動證明這份內容所描述的現實事實為真。

**Signature ≠ Truth**

同樣：

**Log existence ≠ Evidence sufficiency**

Log 已經存在，只能首先說明系統擁有某種記錄，並不能進一步推出這份材料對於當前 Judgment 已經充分。Record 的存在也不等於它所描述的 Fact 因此成立。這裡延續的仍然是上一章建立的邊界：被記錄、被保存或者被簽名，與一個事實獲得足夠支撐，是幾個不同的問題。

因此，Log、Record 和 Signature 也不能據此形成 Evidence 的子類型。所謂「日誌型 Evidence」或者「簽名型 Evidence」只是按照載體形態分類，而本章討論的是材料在 Judgment 中承擔什麼語義作用。載體不同，並不會自動產生不同的 Evidence 身份。

這一點還需要繼續延伸到實現層。歷史上出現過的實現表達，不等於穩定的理論要求。 IntentHash、Result Hash、Counter、prev_hash、Merkle 結構、Checkpoint、Replication、WORM 存儲以及 Evidence Store 架構，都可以在具體系統中用於實現與 Evidence 有關的工程目標，但它們都不屬於 Evidence 的本體，也不得被寫成某項 Sufficiency Condition 的必要實現。

因此，存續性不等於 WORM，順序完整性也不等於 prev_hash。WORM 和 prev_hash 可以成為具體實現的一部分，但都不能反過來定義相應的充分性條件。

如果把一個理論條件直接綁定到某一種實現，檢查的對象就會發生變化。系統不再追問「存續性是否成立」，而會變成檢查「有沒有 WORM」；也不再追問「順序完整性是否成立」，而會變成檢查「有沒有 prev_hash」。一項實現是否仍然滿足理論條件，不能僅由這個實現是否已經部署、是否仍在運行來回答。只有條件本身保持獨立，具體實現是否真正滿足它才仍然是一個可以被繼續追問的問題。

簽名這裡還留下一個不能提前解決的問題。Signature 必然發生在某個時點，但這個時點與它所支撐事實之間允許存在多大的時間區間，以及誰有資格判斷這個區間是否仍然可以接受，目前都沒有確定答案。本章不為它給出閾值。

至於內容在 Signature 發生之前就已經被汙染的情況，它屬於更上游的成因，不屬於這裡討論的 Signature 與 Evidence Sufficiency 關係，也不在本章現有的 failure-condition 枚舉之內。這個問題真實存在，但不能因為它與 Signature 相鄰，就被塞進當前枚舉中補成一個看起來更完整的條件集。

有兩項不完全屬於這裡

七項條件中，時效和來源資格都不能完整地歸到 Evidence 一側。它們與 Evidence Sufficiency 有關，但同時涉及相鄰概念，因此需要分別劃清邊界。

時效首先涉及 Evidence 能夠證明什麼。Evidence 可以為狀態變化提供可驗證的來路，例如某個狀態何時發生變化、相關材料如何支撐這一變化。但這並不等於 Evidence 能夠回答當前狀態本身。當前值、狀態變化的速度，以及可併發消耗量的原子操作，屬於相鄰的狀態問題。

因此，時效是一個雙側共擔的問題。Evidence 一側處理狀態變化的可驗證支撐，另一側處理當前狀態是否仍然成立。兩邊都涉及時間和新鮮度，但並不回答同一個問題。當前狀態的原子性不在本章建立；時效在兩側之間如何進一步劃界，也仍然保持未決。

來源資格同樣存在這樣的分界。Evidence 一側能夠提供的是可驗證支撐，例如某份 Authorization 針對哪一個 Intent，以及相關支撐是否仍處在有效窗口內。但某個主體是否被允許擁有或使用某類能力，屬於 Authorization 本身的資格邊界；Authorization 的效力以及何時需要重新授權，也不由 Evidence Sufficiency 定義。

因此，本章不建立 Authorization 的有效期，也不建立 reauthorization 規則。這裡只區分 Evidence 能夠支撐哪些與資格有關的事實，以及哪些問題仍然屬於 Authorization 自身。

還需要避免另一種對齊。前面對 State 的討論中同樣出現過時間和新鮮度，但那裡討論的是 State 周圍沒有進入最小定義的問題；本章討論的則是 Evidence Sufficiency。兩邊使用了相似的詞，並不意味著它們屬於同一套條件，因此不得對齊，也不能據此合併出新的共同條件集。

最後，這些 Sufficiency Conditions 的適用範圍目前也沒有確定的統一上界。本章不給出這個上界，也不暗示它已經存在。

「不夠」不是一種情況

「Evidence 不充分」並不是一種單一狀態。目前至少可以區分三種不同形態：

Missing——單項取值缺失； Evidence Gap——區間不連續； Conflict——多來源不一致。

這三種形態需要分別保留，因為三者不必然導致同一處置。如果把它們統一壓成一個「Evidence 不足」的布爾值，形態本身的差異就會消失。本章只確認這種差異存在，不進一步規定每一種形態應該如何處理。

其中 Evidence Gap 需要單獨保持邊界：

Evidence Gap ≠ simple Missing Evidence

Missing 表示某一項需要的取值沒有獲得；Evidence Gap 表示區間、順序或集合上出現了不連續。它所描述的不是單個取值缺失，因此不能被簡化成「Missing 更多一些」，也不能直接與 Missing 當作同一種缺失形式處理。

Conflict 又是另一種已經被單獨指出的形態：多個來源都存在，但它們之間給出的內容並不一致。這裡需要保留的只是這個區別，不進一步為 Missing、Evidence Gap 和 Conflict 建立層級、分類關係或完整的 negative evidence state 模型。

因此，本章只做到這裡：區分三種「不夠」的形態，同時保留它們不必然導致同一處置這一限定。至於三種形態各自應當引出什麼處置，本章不回答；形態的區分與處置方向是兩個不同的問題。

這一章之後

上一章回答的是 Evidence 是什麼，這一章繼續追問它什麼時候才算夠。兩章之間真正需要守住的，是 Evidence 的身份與 Evidence Sufficiency 之間不能互相替代。

到這裡，可以明確留下三處分離。一處是「是不是 Evidence」與「夠不夠」必須分別回答。七項條件屬於 Sufficiency，不屬於 Evidence 本體；其中某項不成立，對象仍然可以是 Evidence，只是不充分。

另一處是 Sufficiency 本身還要區分兩個獨立問題：一份 Evidence 在構成上是否足以被依賴，與它是否足以支撐當前這一次 Judgment，並不是同一個判斷。

還有一處是「不夠」本身也不是單一形態。目前至少可以區分 Missing、Evidence Gap 和 Conflict，而且三者不必然導致同一處置。

與此同時，本章也保留了幾處明確的未決。Sufficiency 的最終條件集仍然是 CANDIDATE；non-repudiation 沒有被建立；Proof 仍無正式定義；Constitutive Sufficiency 與 Use Sufficiency 是否進入正式概念層仍未確定；時效的共擔邊界、Sufficiency Conditions 的適用性上界，以及簽名時點的可接受區間，也都沒有在本章給出答案。

這些未決不影響本章已經完成的工作。第十一章只需要把 Evidence 與 Sufficiency 分開，並進一步說明 Sufficiency 本身仍然存在尚未收口的條件、邊界和不足形態。

那麼：如果這些條件無法被充分建立，系統應當怎麼辦？說得更準一點——當所需條件無法被充分建立時，系統應當向哪個方向失敗？

本章術語

• 證據 ｜ Evidence
• 證據充分性 ｜ Evidence Sufficiency
• 構成充分性 ｜ Constitutive Sufficiency
• 使用充分性 ｜ Use Sufficiency
• 來源資格 ｜ Source Qualification
• 身份 ｜ Identity
• 綁定 ｜ Binding
• 時效與時間有效性 ｜ Freshness / Temporal Validity
• 內容完整性 ｜ Content Integrity
• 順序完整性 ｜ Sequence Integrity
• 集合完整性 ｜ Set Completeness
• 連續性 ｜ Continuity
• 存續與留存 ｜ Persistence / Survival
• 跨來源一致性 ｜ Cross-source Consistency
• 獨立可驗證性 ｜ Independent Verifiability
• 可重複驗證性 ｜ Re-verifiability
• 來源綁定 ｜ Origin Binding
• 缺失 ｜ Missing
• 證據缺口 ｜ Evidence Gap
• 衝突 ｜ Conflict

其中，構成充分性與使用充分性用於區分本章討論的兩個 Sufficiency 問題，但二者是否進一步進入正式概念層仍未確定。

**不可否認性（Non-repudiation）**在本章中為 NOT ESTABLISHED，沒有被建立為 Evidence Sufficiency 的條件或主維度，因此不列入正式術語表。

Proof 在當前理論中仍無正式定義。本章只在可重複驗證性的邊界討論中涉及該詞，不為其補充定義。

本章案例與資料來源

本章無現實案例。

正文使用了一處假設性工程情境：一份 Evidence 在形成時來路清楚、內容完整、綁定明確，並曾足以支持一次具體 Judgment；當系統面對另一項 Action 時，這份 Evidence 本身可能沒有變化，但它是否仍足以支撐新的 Judgment，需要重新回答。

這一情境僅用於說明 Constitutive Sufficiency 與 Use Sufficiency 是兩個獨立問題。它不對應具體公司、產品、人物或現實事件，也不承擔本章理論結論的證據或證明作用。

資料來源

本章沒有需要單獨列出的現實事件資料。正文討論的是 Evidence Sufficiency 的概念邊界，包括充分性條件與 Evidence 本體的分離、候選充分性條件、載體與實現的邊界，以及 Missing、Evidence Gap、Conflict 三種不足形態。相關未決問題繼續保持開放，本章不通過外部案例為其補充答案。

涉及外部論文、標準、官方資料或現實事件的內容，統一列入本書附錄及全書 《參考文獻與資料來源》。

---

第十二章｜說不清的時候，不許發生

本章回答條件無法充分建立時，系統應該向哪個方向失敗。這裡首先要區分：ALLOW cannot be established 只表示肯定判斷沒有建立，並不自動等於 Explicit Deny、Final Veto、Shutdown 或所有功能關閉。由此，本章把 Fail-Secure 固定為一條 failure direction：當受保護 Action 所需的 State、Evidence、Boundary 或 Execution Qualification 無法被充分建立時，不足本身不得產生 ALLOW，也不得成為擴大現實執行能力的理由，Reality-Changing Execution must not proceed。Fail-Secure 規定的是方向，不是某一種 decision value 或運行模式；系統仍可以保留擁有獨立充分依據的較小能力集合。Evidence 負責說明為什麼條件不充分，Fail-Secure 負責回答不充分以後怎麼辦。下一步的問題因此轉向成功路徑：多個有限、甚至相互不一致的規則，怎樣收斂成這一次 Action 的有限執行範圍？

第十一章已經把「是不是 Evidence」與「Evidence 夠不夠」分開，並把 Sufficiency Conditions 排除在 Evidence 本體之外。這樣一來，一個新的問題就變得明確：當來源資格、對象綁定、時效、完整性、存續性等所需條件無法被充分建立時，這一次 Action 應當怎麼辦。

這裡首先要避免把「無法充分建立」寫成一個已經形成的負向裁決。某項條件不足，只說明支撐這一次執行的肯定判斷沒有建立起來；它本身並不自動產生另一個 Deny。

因此，第十二章面對的不是「已經得到否定結論以後返回什麼值」，而是另一個問題：

當所需條件無法被充分建立時，系統應當向哪個方向失敗？

這裡需要的是方向，而不是一個單一的 decision value。具體系統可以將 failure direction 映射為 DENY、ERROR 或其他實現結果，但這些結果本身並不定義 failure direction。failure direction 只規定一條更上層的邊界：當 Execution Qualification 無法建立時，系統不能因此滑向某個本來沒有被充分建立的現實執行結果。

這也是「說不清的時候，不許發生」真正需要被寫清楚的地方。它不是一句憑直覺即可成立的口號，而是一條必須具有明確邊界的執行語義。接下來的問題，就是這條方向究竟規定了什麼，以及它不能被改寫成什麼。

一句被凍結的方向

這條 failure direction 已經有一個固定表述，其中三個部分都需要保留：

當一個受保護 Action 所需的 necessary conditions、State、Evidence、Boundary 或 Execution Qualification 無法被充分建立時，這種不足本身不得產生 ALLOW，也不得成為擴大該 Action 現實執行能力的理由。對該受保護 Action：

Execution Qualification cannot be established → Reality-Changing Execution must not proceed.

系統仍然可以保留那些擁有獨立充分依據的較小能力集合。

這裡首先規定的是：**不足本身不得產生 ALLOW。**如果系統沒有能夠充分建立這一次 Action 所需要的條件，就不能因為沒有得到明確的反對理由，而把這種缺失解釋成允許。在具體實現中，這種問題可能表現為默認分支、異常路徑、超時後的 fallback，或者校驗失敗以後仍然繼續進入執行路徑。它們的具體形式可以不同，但這裡需要守住的邊界相同：沒有建立 ALLOW，不能被等同於 ALLOW 已經成立。

第二個部分同樣重要：**不足不得成為擴大該 Action 現實執行能力的理由。**條件沒有建立起來，並不能反過來成為取得更高權限、繞過原有邊界或者擴大這一次 Action 可執行範圍的依據。Failure 本身不能成為 expansion 的理由。

可以設想一個只用於說明的情形：某次變更依賴一份上游確認記錄，但這份記錄當前無法取得。此時存在兩種需要被這條方向排除的做法：一種是先讓 Action 繼續，之後再補記錄；另一種是因為正常條件無法建立，而臨時開放一條權限更高或繞過原有校驗的路徑。前者把不足轉成了 ALLOW，後者把不足轉成了現實執行能力的擴大。這個情形只用於說明兩項邊界，並不承擔本章結論的證明作用。

最後一句規定的是適用範圍：**系統仍然可以保留那些擁有獨立充分依據的較小能力集合。**這不是對前兩項原則的放寬，而是說明 Fail-Secure 所約束的是這一次受保護的現實執行能力，並不要求系統因此失去所有其他能力。這個邊界後面還需要單獨展開。

措辭本身就是邊界

Failure direction 已經明確以後，還需要守住它的語言邊界。同一個狀態如果被換成另一個看似接近的說法，表達的對象可能已經發生變化。

因此，這裡優先使用 Execution Qualification cannot be established 或 ALLOW cannot be established。應避免單獨使用「當前無資格」，如果這個說法會被理解為系統已經形成了一個明確的負向資格判定。

兩種表述的區別在於：明確的 Deny 是一個已經形成的結果，而 ALLOW cannot be established 表示肯定判斷沒有建立起來。**前者是一個結果，後者是一個結果的缺席。**把結果的缺席寫成負向結果，就會改變後續系統實際接收到的語義。

這種區別也不能被後續處理抹平。一次明確 Deny 可以被作為已經形成的負向判斷處理；Execution Qualification 無法建立，則說明支撐肯定判斷的條件仍未充分建立。兩者可以產生不同的後續處理與審計含義，因此不能因為最終都沒有讓 Action 繼續，就把它們寫成同一種結果。

四條否定用於固定這條邊界。它們不是四種不同的失敗方向，而是對同一 failure direction 的四種誤讀攔截。

BOX-II-002｜Required Language Boundary

當所需條件無法被充分建立時，成立的表述是：

Execution Qualification cannot be established → Reality-Changing Execution must not proceed.

優先使用 Execution Qualification cannot be established / ALLOW cannot be established。避免單獨使用「當前無資格」，若該說法會被理解為已經形成明確的負向資格判定。

這一表述同時攜帶四條否定，四條必須一併出現：

Execution Qualification cannot be established
    ≠ Explicit Deny automatically exists
    ≠ Final Veto has been exercised
    ≠ System Shutdown
    ≠ All Functions Disabled

並且：

Fail-Secure 是 failure-direction semantic，不是單一 decision value、Authority holder 或具體運行模式。

在此之上，不足狀態的共同最小結果是 ALLOW NOT ESTABLISHED，而它不自動等於以下任何一項：Explicit Deny；Final Veto；permanent termination；同一種 Safe Mode；同一種恢復路徑。

這四條否定在後續複述中必須同時保留。刪掉第一條，就會把「肯定判斷沒有建立起來」改寫成一次 Explicit Deny；刪掉第二條，就會把沒有發生的 Final Veto 寫成已經被行使的權力；刪掉第三條，Fail-Secure 會被縮減成 System Shutdown；刪掉第四條，則會把 failure direction 誤解成系統所有能力同時關閉。

其中第三條尤其需要保留，因為 **System Shutdown 只是可能的實現形式之一，不是 Fail-Secure 本身。**如果二者被直接等同，failure direction 就會與 Availability 目標發生不必要的綁定，而本章並沒有建立這種等同關係。

不許發生，不等於停機

這條 failure direction 在概念層對應的是安全失敗（Fail-Secure）。它的最小定義是：安全失敗是在必要執行條件、State、Evidence 或 Boundary 無法被充分建立時，不允許系統把不確定性轉化為現實執行的上位執行語義，其默認方向是收縮執行能力，而不是擴大執行許可。

這裡的「上位」意味著它規定的是方向，而不是某一種具體運行狀態。因此需要同時保留四個邊界：

安全失敗 ≠ Safe Failure 安全失敗 ≠ Fail-Closed 安全失敗 ≠ Shutdown 安全失敗 ≠ Safe Mode

Fail-Secure 不規定所有系統進入同一種失敗狀態。同一個方向，在不同系統中可以由不同的具體狀態承載。支付系統可能停止新的結算而保留查詢，機械控制系統可能不執行新的位移，部署系統也可能停止新的變更。具體表現可以不同，約束保持相同：不確定性不能因此轉化為受保護的現實執行。

因此，Fail-Secure 不只是「系統壞了就停機」。Shutdown 可以是一種實現形式，但不是 Fail-Secure 的全部語義。把二者直接等同，會把一個上位 failure direction 縮減成一種具體運行狀態。

安全失敗也有明確的違反方式：未知或 Evidence 不足被解釋為允許；Boundary 異常時仍然釋放原有執行能力；或者恢復過程無條件恢復全部權限。

最後一種同樣屬於這裡的邊界。系統曾經因為條件無法充分建立而收縮執行能力，並不意味著進入恢復過程以後，原有資格就自動重新成立。**恢復不自動重新獲得資格，不可用也不產生旁路權限。**至於恢復過程本身應當怎樣設計，本章不建立相應協議。

還有一個名稱問題需要保持開放。「安全失敗」這一中文名稱與 Safe Failure 存在碰撞，而 Safe Failure 又是上述四個明確排除的對象之一。本章只登記這一碰撞，不在這裡解決。

「說不清」是從哪裡來的

Failure direction 已經明確以後，還需要回答另一個問題：系統憑什麼知道所需條件沒有被充分建立。這個問題仍然屬於 Evidence，而不是 Fail-Secure。

兩者的分工可以直接寫成：

Evidence answers:      Why is the claim / condition not sufficiently established?
Fail-Secure answers:   What should the system do when it cannot establish it?

Evidence 回答「不充分是怎樣被建立的」，Fail-Secure 回答「不充分以後應當向哪個方向失敗」。這條分工是單向的。Fail-Secure 接收 Evidence 一側已經形成的不足判斷，但不重新定義 Evidence 本體、Proof、Sufficiency 或 Evidence Gap。

目前已經明確命名的不足形態包括 Missing、Unknown、Expired、Conflict。除此之外，無效性、不可驗證性、陳舊性和關係未綁定也與不足有關，但它們沒有被建立為同一正式枚舉中的獨立成員，因此不能為了得到一張整齊的狀態表而直接合並進去。

Evidence Gap 同樣需要保持獨立邊界：

Evidence Gap ≠ simple Missing Evidence

而在 Sufficiency 一側，構成充分性與使用充分性也可能分別不成立。這些差異說明，「無法充分建立」並不是一個已經完成統一分類的單一狀態模型。

它們能夠共同收斂到的，只是一個最小結果：

ALLOW NOT ESTABLISHED

這裡的含義是肯定的 ALLOW 沒有建立起來，而不是系統已經形成某個統一的負向 decision value。不同不足形態仍然可以有不同邊界；某些能力可能繼續存在，也不意味著這些能力是所有系統在相同情形下都必須提供的功能。

因此，本章不建立一張統一的負向狀態處置表。這樣做會產生兩個目前沒有依據支持的暗示：一是表中的狀態已經構成完整全集；二是每個狀態對應的「仍可發生」事項已經成為系統必須實現的功能。當前能夠建立的是共同的 failure direction，而不是完整的 negative evidence state taxonomy。

同樣需要保持開放的是六種狀態的並列表達。Unknown、Missing、Expired、Conflict、Invalid、Incomplete 都需要在工程上被顯式面對，但這並不意味著它們已經被建立為一套統一、完整的理論枚舉。尤其是 Incomplete，並不屬於前述已經明確命名的歷史枚舉，因此不能直接把兩組表達合併成一套更完整的分類。負向 Evidence 狀態的完整語義在本章仍然未決。

還有一個邊界必須同時保留：Missing ≠ Attack

Evidence 沒有出現，並不能推出有人主動阻止它出現；但 Missing 也不能被視為正常狀態，而必須被顯式標記為安全異常。Evidence 系統不能因為沒有發現反對材料，就把缺失解釋成滿足。

因此，當系統無法證明一個 Action 滿足所需執行條件時，不能因為缺少反對 Evidence 而默認產生 ALLOW。這個判斷仍然屬於 Evidence 一側；Fail-Secure 接收的是它的結果，而不把它改寫成自己的定義。

不擴大的，是哪一部分能力

這裡需要繼續限定「不擴大」究竟指什麼。凍結下來的原則只針對一類能力：

FAILURE ITSELF MUST NOT EXPAND PROTECTED REALITY-CHANGING EXECUTION CAPABILITY

也就是說，當安全條件仍然未決時，**受保護的、能夠改變現實的執行能力不能因為 failure 本身而擴大。**這裡的主語不是系統的全部能力。

因此，不能進一步推出「故障狀態下的全部系統能力都必須少於或等於正常狀態下的全部系統能力」。診斷、健康檢查、Evidence 的訪問、導出與驗證、狀態同步以及其他不直接擴大受保護現實執行能力的功能，都可能在失敗狀態下繼續存在。

這一區分很重要，因為 Fail-Secure 約束的是受保護 Action 能否繼續改變現實，而不是要求系統在條件無法建立時失去所有觀察、診斷或恢復相關能力。本章因此不建立 capability lattice，不建立 total-system capability model，也不建立 mode state machine；能力集合之間是否能夠形成更一般的形式化關係，目前仍然沒有結論。

可以保留的能力例子包括：只讀能力；Evidence 的訪問、導出與驗證；診斷；健康檢查；狀態同步；有限的恢復；以及場景明確允許的低風險、可逆、本地可驗證能力。

但必須同時保留一個限定：

CORPUS-SUPPORTED CAPABILITY EXAMPLES ≠ UNIVERSAL REQUIRED CAPABILITY SET

這些只是已經能夠指出的能力例子，不是一份所有系統都必須開放的能力集合，也不是 Fail-Secure 定義的一部分。尤其是「有限的恢復」，這裡只說明它可能繼續存在，並不因此建立任何 Recovery protocol。

還需要避免另一種推論：失敗狀態下仍然存在某些能力，並不意味著 failure 創造了新的 Execution Qualification。某項能力存在，也不能自動推出它已經獲得 Authorization、最終 Judgment 為 Allow，或者這一次 Action 應當發生。

至於失敗狀態是否可能出現新的能力，或者新的 Execution Qualification，目前沒有結論。這裡保持開放，不把「沒有建立」改寫成「已經證明不會發生」。

九個可以把它吸收掉的位置

Fail-Secure 還需要與一組相鄰對象保持區分。需要排除的對象包括 Deny、Final Veto、Safe Mode、Recovery、Execution Control、Evidence、Authority、Policy 和 Availability。它們都與失敗處理有關，但其中任何一項都不能直接替代本章建立的 failure direction。

這裡需要保留的核心仍然是：當受保護執行所需的 Execution Qualification 無法充分建立時，failure 不能因此自然轉化為 ALLOW，也不能成為擴大受保護現實執行能力的理由。已有的 Deny、Veto、Policy 或其他對象，並不會自動回答這個問題。

其中，Final Veto 的邊界尤其明確：

FAIL-SECURE ≠ FINAL VETO

Final Veto 屬於 Authority 與拒絕結構，它涉及持有者以及一次具體的行使；Fail-Secure 則不會因此創建一個新的 Authority holder，也不會創建 refusal permission。Execution Qualification 無法建立，並不意味著某個主體已經行使了 Final Veto。這裡發生的是資格沒有建立，而不是某個人或某個組件完成了一次否決。

Safe Mode 也不能吸收 Fail-Secure。Safe Mode 可以是一種具體狀態或承載形式，但它不是 failure direction 本身，而且 Safe Mode 的通用語義目前沒有被建立。把兩者等同，就會把一個上位方向縮減成某一種具體運行模式。

Availability 與 Fail-Secure 回答的問題也不同。Availability 處理的是連續性目標，它本身不能建立 Execution Qualification，也不能產生 bypass permission。因此，可用性要求即使存在，也不能替代「條件無法充分建立時，受保護 Action 應當向哪個方向失敗」這一判斷。

Evidence 同樣不能吸收 Fail-Secure。Evidence 回答的是為什麼某項 claim 或 condition 沒有被充分建立；Fail-Secure 回答的是在這種情況下系統應當向哪個方向失敗。兩者之間存在交接，但不能互相替代。

其餘幾個對象——Deny、Recovery、Execution Control、Authority 和 Policy——同樣不能因為與失敗處理有關，就被直接當成 Fail-Secure 本身。本章只保留這一邊界，不在這裡為它們建立新的層級或分類關係。

現實壓力，與理論材料中的缺席

到這裡，Fail-Secure 的方向已經建立。現實案例在本章中的作用，不是證明這條方向，而是檢驗一種 failure pattern 是否真正具有現實壓力。

在本書核驗的案例中，這種結構反覆出現：所需事實尚未被充分確立，系統卻仍然獲得了執行資格。

這類案例不能反過來證明 Fail-Secure 為真。**Case ≠ Proof。**案例只能說明這種 failure pattern 並非純粹的理論假設，不能替代關於 failure direction 本身的論證，也不能因為重複出現，就自動獲得正式理論地位。

案例本身也帶有不能被抹去的證據邊界。有的事件缺少第一層級政府事故報告，而且其中多起事件不能被合併為一個單一競態，也不能概括為‘刪除了全部硬件聯鎖’；有的官方調查在責任性質上直接衝突，因此必須並列保留，不能引入後見之明；有的最終觸發事件在權威報告中本身仍保持不確定；還有的不同官方調查機構之間存在尚未解決的公開分歧，而且相關事故不能因此被合併處理。

因此，本章不逐案重新敘述這些事件，也不把案例池當作沒有爭議的事實證明。這裡需要保留的只是一個結果：這一 failure pattern 在現實案例中反覆形成壓力。

與這一現實壓力並列存在的，是理論材料中的另一種情況。在本書核驗的直接理論材料，以及更早的前身材料中，「所需事實尚未被充分確立，但系統仍然產生執行資格」這一結構，都沒有獲得一個獨立的位置。

這個結論的範圍必須保持有限。它只說明在本書核驗的這兩類材料中沒有形成獨立登記，不能進一步推出其他文獻從未討論過類似問題，也不能據此解釋這種缺席為什麼發生。

因此，真正值得保留的是這個不對稱：現實案例反覆暴露這種 failure pattern，而在當前核驗的理論材料中，它仍然沒有形成獨立的位置。

這種不對稱不能成為把這一結構直接寫成正式理論命題的捷徑。現實壓力再明顯，也不能直接把一個尚未完成理論定位的結構變成正式命題。

所以，本章對它保持三個邊界：保留這一問題，但不把它寫成已經成立的正式命題；承認其現實壓力，但不把案例當作證明；承認它在當前理論材料中的缺席，但不把這種缺席擴大成對整個文獻世界的判斷。

它在這裡承擔的作用到此為止：提醒我們，有些執行風險可以在現實中不斷出現，卻仍然沒有被現有理論對象清楚地單獨承接。

還開著的兩件事，和下一個問題

第十二章建立了 failure direction，但仍有兩類問題沒有因此得到答案。第一類是負向 Evidence 狀態的完整語義。Missing、Unknown、Expired、Conflict 已經能夠被明確指出，其他與無效、不可驗證、陳舊或關係未綁定有關的情形也已經進入討論，但這些內容還不能被合併成一套完整的 negative evidence state taxonomy。Incomplete 應當處在什麼位置，Evidence 的 validity 與 re-executability 之間是什麼關係，一個長期無法消除的模糊狀態最終如何停留，以及 Witness 或 Fact Source 本身失陷以後應當怎樣理解，這些問題目前都沒有結論。

本章只規定：當這些情形導致 Execution Qualification 無法被充分建立時，系統應當向哪個方向失敗；不替這些狀態建立完整語義。

第二類問題是失敗狀態中的能力變化。前面已經明確，failure 本身不得擴大受保護的、改變現實的執行能力；但這並不等於我們已經建立了一個完整的 failure-state capability model。失敗狀態是否可能出現新的能力，以及這些能力與新的 Execution Qualification 之間究竟是什麼關係，目前仍然沒有結論。

現實案例可以對這個問題形成壓力，但不能代替理論證明。**Case ≠ Proof。**因此，這個問題繼續保持開放。

到這裡，本章真正交出的仍然只是一個方向：

ALLOW NOT ESTABLISHED

它不是 decision enum 中的一個新成員，也不是 Explicit Deny、Final Veto 或其他負向結果的別名。它表達的只是：肯定的 ALLOW 沒有被建立起來。

至於這種「沒有建立」以後還需要怎樣區分，本章不繼續展開，也不建立任何 refusal authority。

接下來，問題轉向 failure direction 之前的另一部分。一次 Action 所面對的規則並不一定只有一個來源。不同規則可以擁有不同的適用範圍，也可能在同一次 Action 上同時生效而彼此不一致。某項約束限制時間窗口，另一項約束限定主體能力，還有的只對特定環境成立。它們各自在自己的範圍內有效，但最終需要面對的是同一次具體 Action。

於是：

多個各自有限、適用範圍不同、可能相互不一致的規則側輸入，如何形成這一次 Action 的一個有限、可驗證的範圍？

本章術語

• 安全失敗 ｜ Fail-Secure
• 失敗方向 ｜ Failure Direction
• 執行資格 ｜ Execution Qualification
• 現實改變型執行 ｜ Reality-Changing Execution
• 受保護的現實執行能力 ｜ Protected Reality-Changing Execution Capability
• ALLOW 未建立 ｜ ALLOW NOT ESTABLISHED
• 明確拒絕 ｜ Explicit Deny
• 最終否決 ｜ Final Veto
• 安全模式 ｜ Safe Mode
• 停機 ｜ Shutdown
• 可用性 ｜ Availability
• 缺失 ｜ Missing
• 未知 ｜ Unknown
• 過期 ｜ Expired
• 衝突 ｜ Conflict
• 證據缺口 ｜ Evidence Gap

其中，Fail-Secure 是 failure-direction semantic，不是一個單一 decision value、Authority holder 或具體運行模式。

ALLOW NOT ESTABLISHED 表示肯定的 ALLOW 沒有被建立起來。它不是 decision enum 中的新成員，也不自動等於 Explicit Deny、Final Veto、permanent termination、同一種 Safe Mode 或同一種恢復路徑。

「安全失敗」這一中文名稱與 Safe Failure 存在名稱碰撞。本章只保留這一問題，不在這裡為 Safe Failure 另行確定中文名稱或重新定義兩者關係。

Missing、Unknown、Expired、Conflict 等負向 Evidence 狀態在本章中用於說明「條件為什麼沒有被充分建立」，但本章沒有建立完整的 negative evidence state taxonomy。

本章案例與資料來源

本章使用現實案例作為 Fail-Secure 的壓力測試，不把案例作為理論證明。

在經權威來源核驗的執行控制案例中，一種結構反覆出現：**所需事實尚未被充分確立，系統卻仍然產生了執行資格。**這些現實事件說明，這種 failure pattern 具有實際壓力，但不能據此證明 Fail-Secure 本身，也不能因為案例反覆出現，就直接把尚未完成理論定位的結構凍結成正式命題。

案例材料本身存在不能消除的證據邊界。有的事件缺少第一層級政府事故報告；有的官方調查在責任性質上存在直接衝突，因此相關結論必須並列保留，不能引入後見之明；有的最終觸發事件在權威報告中本身仍保持不確定；還有的不同官方調查機構之間存在尚未解決的公開分歧，相關事件也不能因此被合併處理。

因此，本章不逐案重新敘述事故經過，也不把案例池視為沒有爭議的事實證明。案例在這裡承擔的作用只有一個：檢驗本章所討論的 failure pattern 是否具有現實壓力。

與現實案例形成對照的是，在本書核驗的直接理論材料以及更早的前身材料中，「所需事實尚未被充分確立，但系統仍然產生執行資格」這一結構沒有獲得獨立的位置。

這一結果同樣保持有限範圍：它只說明當前核驗材料中的理論缺席，不能推出其他文獻從未討論過類似問題，也不能據此解釋這種缺席為什麼發生。

因此，本章保留的結論是：

**現實案例反覆暴露這種 failure pattern，而在當前核驗的理論材料中，它仍然缺少一個獨立的位置。**案例提供現實壓力，但不替代理論證明。

資料來源

本章案例依據來自經權威來源核驗的現實事件資料，包括官方事故調查、政府報告及其他一手或高權威材料。正文不逐案展開事實鏈，相關事件、調查機構、報告版本及具體引用統一列入本書附錄及全書 《參考文獻與資料來源》。

---

第十三章｜只能收緊，不能放寬

本章處理多個規則側輸入如何共同約束一次 Action。Policy、Constraint 與 Condition 各自只有有限來源和適用範圍，因此它們不是多個完整答案，而需要在當前 State、Context 與 Intent 下形成一個有限、具體、可驗證的規則側範圍。這個過程的方向可以確定：收斂後的範圍不得比任何仍然有效、仍然適用的約束更寬；要解除約束，依據必須由解除側建立，Missing、Unknown、Expired、Unverifiable 或 Conflict 也不能因為信息不足而帶來放寬。但「只能收緊」不是一套通用求交算法，也沒有建立統一的嚴格程度、優先級或結果枚舉。Policy Convergence 形成的是規則側範圍，不是 Execution Permission、Execution Decision、Final Execution Authority 或現實改變。規則側已經收緊以後，下一問是：即使所有正向資格都成立，還有什麼能夠阻止 Action 真正進入現實？

上一章已經把 failure direction 固定下來：這一次 Action 所需的條件如果無法被充分建立，它就不得發生；而且這種不足本身，不能反過來成為擴大這一次 Action 現實執行能力的理由。上一章還用一個專門的方框固定了這條語言邊界，避免 Fail-Secure 被縮減成「系統出了問題就停機」。那個方框只在那裡完整出現一次，本章直接承接它，不再重述。

但這個方向只回答了一側。說不清的時候怎麼辦，已經有了邊界；條件能夠建立以後，多個規則側輸入究竟怎樣共同限定這一次 Action，還沒有回答。

一次受保護的 Action 真正面對的規則側輸入並不只有一個。本地限制、服務方約束、審批條件、物理能力邊界、風險判斷、治理狀態，以及執行路徑中已經確定的參數與邊界，都可能同時作用於這一次 Action。它們各自有來源，也各自有適用範圍，彼此之間並不要求形式相同，也不保證結論完全一致。

這種不一致並不意味著其中一定有一條錯誤。兩條約束可以各自在自己的適用範圍內成立，只是在這一次 Action 上同時生效，並且給出了不同的限制範圍。

因此，本章只回答一個問題：

多個各自有限、適用範圍不同、可能相互不一致的規則側輸入，如何形成這一次 Action 的一個有限、可驗證的範圍？

本章能夠建立的是一個規則側收斂過程，以及這個過程必須遵守的方向。它不是一套具體算法，也不是一張「最後返回哪個值」的對照表。收斂方向可以確定，但具體算法、求值順序和結果枚舉並不在本章建立。

一次動作面對的是多個有限判斷

先把輸入本身看清楚。作用在這一次 Action 上的每一條規則，回答的都只是自己覆蓋的那一部分：額度是多少，對象是否包含某一類，某個時間窗內是否允許，或者是否需要滿足某個前置條件。沒有哪一條規則單獨回答「這一次 Action 到底應不應當發生」。它們不是多個完整答案，而是多個有限判斷。

每一條規則同時都有自己的來源和適用範圍。來源說明它依據什麼成立，適用範圍說明它約束到哪裡。兩條規則即使看起來不一致，也可能只是因為各自處理的對象、條件或範圍不同；只有當它們在這一次 Action 上同時有效、同時適用並且都落在當前範圍內時，才真正需要進入同一次收斂過程。因此，不能先假定所有規則都處在同一個可以直接比較的平面上。

對單條 Policy，本書已經有一個最小定義：策略是表達執行判斷規則及其適用條件的對象，是裁決的重要輸入，但不是事實、最終 Authority 或安全本身。策略不自行證明事實，不等同於 Authority，也不能自動獲得最終執行裁決權。它的失敗條件包括來源被汙染、版本過期、作用域錯誤、衝突未處理，以及可以被旁路或無條件覆蓋。

這些失敗條件描述的是單條 Policy 自身什麼時候不再可靠，並沒有同時給出多條 Policy 應當怎樣歸併。「衝突未處理」是一種失敗，不等於已經有了一套衝突處理規則；「版本過期」是一種失敗，也不等於已經建立了一套版本協議。哪一份版本算當前版本、由誰判斷，本章都不回答。

因此，單條 Policy 的定義到這裡仍然保持原樣。它定義的是一個 Policy 自身的對象、適用條件和邊界，而不是多個規則如何共同形成這一次 Action 的有限範圍。後者正是本章需要單獨處理的問題。

一個過程，不是一個值

規則側收斂是一個過程。它把多個有限的、有明確來源和適用範圍，並綁定當前 State、Context 與 Intent 的 Policy、Constraint 和 Condition，解析為當前這個具體 Action 的一個有限、具體、可驗證的規則側可執行範圍。

這裡首先需要看清「綁定」。同樣一組規則面對不同 Action，得到的範圍可以不同，因為當前 State、Context 與 Intent 已經發生變化。因此，收斂不是把規則庫一次性壓縮成一份通用結論，再把同一個結果套用到不同動作上。一個脫離具體 Action 預先形成、之後可以直接複用的「收斂結果」，並不是這裡所說的規則側收斂結果。

綁定在這裡規定的是結果屬於哪一次 Action，而不是收斂必須在什麼時間開始。本章不規定求值順序，也不規定必須有哪些輸入在某個時刻同時到場。能夠確定的只是：最終形成的範圍必須與當前這一次 Action 建立明確綁定，不能省略這一關係。

第二個邊界在輸出一側。規則側收斂產生的是一個可執行範圍，而不是一個標量結果值。這裡不把輸出壓縮成「放行」「拒絕」「待定」或者另一套統一枚舉，因為本章沒有建立這樣的結果語義。它同樣不提供具體的收斂算法、求值順序或數據結構。

因此，這裡能夠確定的是輸出的性質：它是一個有限、具體、可驗證的規則側可執行範圍。拿到這個範圍以後，下游仍然可以繼續判斷當前 Action 是否落在其中；而一個單獨的「已放行」標記並不能承擔這種範圍約束。

方向確定，形式未定

這裡能夠固定下來的是一條方向：

收斂後的範圍，不得比任一仍然有效、仍然適用、仍在範圍內的約束更寬。

其中「仍然」是必要限定。這條原則針對的不是所有曾經存在過的歷史約束。一條已經合法失效、不再適用或者已經被合法替代的舊約束，不會因為曾經存在就永久限制當前 Action；真正被禁止的是在某項約束仍然有效、仍然適用時忽略它，從而讓收斂後的範圍變得更寬。

方向能夠確定，並不意味著收斂已經有了一套統一的形式化形狀。歷史表達中確實出現過「取最小」「求交」「單調收窄」一類寫法，但這些表達不能直接成為本章的定義語言。原因之一是，它們會把後來使用的形式化描述反向投射成這個問題最初就具有的定義；更重要的是，這種寫法很容易引入機械計算的含義，而「取交集」並不等於機械的布爾與，「更嚴格」也必須結合約束本身的語義判斷。

因此，本章保留方向性的表達，而不把「哪一條更嚴」改寫成一個統一的計算問題。

這裡尤其需要避免形式語言附帶帶入一些並未建立的前提。例如，兩條約束是否可以不分先後地合併，是否可以任意分組，任意兩條是否都能直接比較，以及是否總能找到其中「最嚴格」的一條，這些關係都沒有被建立。使用一套看起來熟悉的形式記法，很容易讓這些前提隨著記法一起進入定義。

在相同類型的量上，收斂方向可以表現得很直觀。例如額度可以取更小的範圍，目標範圍可以進一步收縮，有效期可以受到更早邊界的限制。但這些例子只說明對應維度上的收緊方向，不能由此推出一個跨越所有約束類型的統一嚴格程度次序，也不能推出一套統一的優先級模型。

同樣，多個 Deny 之間是否需要合併、怎樣組合，本章沒有建立答案。因此，第十三章固定的是「只能收緊、不能放寬」的方向，而不是一套可以對所有 Policy、Constraint 和 Condition 直接求值的通用算子。

舉證責任在解除側

方向原則之後，還有一條關於默認方向的規定：無法證明某條約束已經失效、已經過期、已經不適用或者已經被合法替代時，不得僅僅為了形成更寬的結果而忽略它。

這條規定確定的是舉證責任落在哪一側。如果要確認一條約束已經被替代，需要能夠建立替代關係本身以及替代的合法性；如果要確認它已經過期，也需要能夠建立相應的有效期狀態。只要這些條件沒有被充分建立，就不能僅憑「它可能已經不算數了」來擴大當前範圍。

設想一種情形：某條限制對應的流程後來發生過變化，但當前無法確認它是否已經被新的規則合法替代，只能說它「看起來不像還有效」。在這裡，這種不確定不能產生放寬。只要合法替代沒有被建立，就不能因為這種判斷而忽略原約束。

如果把舉證責任反過來，查不到、無法確認或者沒有人提出異議，就可能被直接解釋成放寬的依據。舉證責任放在解除側，擋住的正是這種轉換：缺少解除依據，不能本身成為擴大範圍的依據。

這並不意味著舊約束永久有效。約束可以因為已經失效、已經過期、已經不適用或者已經被合法替代而不再繼續限制當前 Action；關鍵在於，相應狀態需要被建立，而不能由「沒有發現反對理由」替代。

失效、過期、不適用和被合法替代描述的是不同情形。一條約束可能仍在有效期內，但已經不再適用於當前對象；也可能仍然適用，卻已經被另一條約束合法替代。因此，「這條太老了」並不等於「這條已經過期」，「我們已經不這麼做了」也不等於「它已經被合法替代」。前者只是描述或判斷，後者才觸及解除當前約束所需要建立的事實。

不足不能帶來放寬

第三條同樣規定默認方向：必要輸入處於 Missing、Unknown、Expired、Unverifiable 或 Conflict 狀態時，這種不足本身不得擴大可執行範圍。

這五種狀態面對的問題並不相同。Missing 是必要輸入缺失，Unknown 是當前無法確定其內容或狀態，Expired 表示已有輸入已經超過可使用的時效邊界，Unverifiable 表示當前無法完成所需驗證，Conflict 則表示多個輸入之間存在不能忽略的不一致。它們在本章中的共同點只有一個：規則側沒有獲得足以支持放寬當前範圍的完整依據。因此，不足不能被解釋成許可。

這一條與前面的「舉證責任在解除側」也需要分開。舉證責任處理的是一項已經存在的約束能否被解除；不足不擴權處理的是必要輸入本身沒有被充分建立。兩者方向一致，但面對的是不同問題：前者防止把仍然有效的約束未經證明就移除，後者防止把輸入缺失或不確定直接轉換成更寬的範圍。

這裡必須保持與上一章的邊界。**不足不擴權並不是第十三章重新定義出來的 failure semantic。**失敗方向已經由上一章建立；本章只在規則側收斂中承接這一方向。規則側收斂處理的是多個規則如何形成當前 Action 的有限範圍，不重新定義失敗本身應當是什麼。

因此，上一章已經建立的幾個邊界在這裡繼續成立：Unknown、Missing、Expired 和 Conflict 不能因為自身存在而產生放寬；ALLOW NOT ESTABLISHED 仍然只是肯定判斷沒有建立；Policy 不可用或無法求值時，不能因此擴大受保護的現實執行能力；沒有 ALLOW 也不自動意味著已經存在 Explicit Deny 或 capability-level refusal；failure 本身同樣不能擴大受保護的現實執行能力。

其中，「沒有 ALLOW」「Explicit Deny」與 capability-level refusal 之間究竟如何區分，本章不展開。這裡需要的只是保證規則側收斂不會因為這些狀態尚未區分完成，就提前把其中任何一種寫成另一種。

在具體方向上，可以看到相同的收縮原則：狀態不確定時不通過猜測擴大範圍；Policy 異常時不因此放寬；必要來源缺失時，結果不能因為信息不足而變得更寬；無法比較嚴格程度時，也不能把無法比較本身解釋成放行。至於是否進入治理流程、如何升級、由誰處理，本章不建立相應機制。未知的執行路徑同樣不能因為未知而獲得額外範圍。

這些方向只用於說明「只能收緊，不能放寬」的共同約束，不構成一份完整的失敗處置規則集。

還有兩項保持未決。無法收斂以後所進入的形態，究竟應被理解為收斂結果、系統狀態還是新的輸入，本章沒有結論；CANNOT_CONVERGE 也不能因此被直接寫成一個統一的結果值。

這個問題需要單獨回答

到這裡會出現一個自然的問題：規則側收斂是否真的需要單獨討論，還是它已經包含在某個已有對象裡面。

先看 Policy。單條 Policy 的定義只說明一條規則自身的對象、成立條件和邊界，不回答多條 Policy 如何共同形成當前 Action 的一個範圍，因此不能由單條 Policy 的定義直接吸收規則側收斂。

Fail-Secure 也不能吸收它。Fail-Secure 規定的是條件無法充分建立時系統應當向哪個方向失敗；規則側收斂處理的則是成功路徑上，多個仍然有效、適用並在範圍內的規則如何共同限制當前 Action。前者提供 failure direction，後者處理規則側範圍，兩者存在引用關係，但不是同一個問題。

Final Execution Authority 回答的是「誰能夠讓現實中的 Action 最終發生」，規則側收斂回答的是「規則側能夠給出的範圍有多大」。兩者回答的是不同問題，不能因此合併成一個對象。

Runtime 同樣不能被直接拿來承擔這個答案。Runtime 與裁決位置有關，但本章沒有建立 Policy Convergence 究竟發生在哪一層，也沒有建立 Runtime 就是它的固定承載位置。因此，「收斂發生在哪裡」仍然保持未決。

所以，即使 Policy、Fail-Secure、Authority / Final Execution Authority、Final Veto、Execution Control、Runtime、Evidence、Intent、Governance 與 Adversarial Completeness 都已經存在，仍然留下一個需要單獨回答的問題：

多個各自有限、適用範圍不同、可能相互不一致的規則側輸入，如何形成當前具體 Action 的單一、有限、可驗證，而且不會因為缺失、衝突或默認值而擴大的規則側有界結果？

這個問題不能被相鄰對象吸收，但這並不意味著 Policy Convergence 因此成為一條新的主幹理論。本書也不為它創建正式概念編號。

它發生在哪一層，輸出應當怎樣分類，多個收斂結果之間怎樣組合，以及它與其他對象之間是否存在更正式的關係，目前都沒有結論。本章只確認一件事：這個問題需要被單獨回答，但不能因為它暫時無法歸入其他對象，就替它補出一個尚未建立的理論位置。

收斂後的範圍不是許可

到這裡，收斂的方向、解除約束時的舉證責任，以及輸入不足時的默認方向都已經明確。接下來需要擋住一個容易出現的誤讀：規則側已經形成一個有限範圍，並不等於這一次 Action 已經獲得放行。

這一邊界由四條否定共同確定：

Policy Convergence ≠ Execution Permission Policy Convergence ≠ Execution Decision Policy Convergence ≠ Final Execution Authority Policy Convergence ≠ Reality Change

四條否定分別擋住不同的越界。不是 Execution Permission，意味著範圍已經形成不能被直接解釋為「可以執行」；不是 Execution Decision，意味著規則側收斂沒有替代針對這一次 Action 的最終判斷；不是 Final Execution Authority，意味著它沒有回答「誰能夠讓這一次 Action 真正發生」；不是 Reality Change，則說明規則側結果形成以後，現實狀態本身還沒有因此發生變化。

這些否定並不是依賴某一句總綱才成立。在相關材料中，對「規則側收斂結果等於執行許可」的否定分別出現在十一處不同討論中。它們關注的問題並不完全相同，卻都停在同一條邊界上：規則側能夠形成約束範圍，但這個範圍本身不能被直接改寫成執行許可。

這個邊界也限制了輸出的命名。Execution Grant、Final Authority、Execution Decision、Execution Permission 都沒有被建立為規則側收斂結果的正式名稱；Final Execution Permission 與 Final Execution Decision 則不能用來稱呼它。因為一旦把規則側結果直接命名為「許可」或「最終決定」，名稱本身就會把它推過本章尚未跨越的邊界。

這一點尤其需要謹慎，因為 Policy Convergence 本身沒有正式概念編號。當前能夠確定的是它承擔的功能和邊界，而不能靠一個更強的名字替它補出尚未建立的理論地位。

Policy 仍然只是裁決的重要輸入：它不自行證明事實，不等同於 Authority，也不會自動獲得最終執行裁決權。Policy Convergence 所做的是把規則側輸入收斂為當前 Action 的有限範圍。這個範圍隨後還可以進入後續判斷，但它本身沒有讓現實發生變化。

放行與限制並不對稱

規則側結果還有一項重要的不對稱：**放行只提供繼續接受後續驗證的資格，而拒絕與限制可以繼續向下收縮。**換句話說，限制可以繼續傳遞，放行不能以同樣的方式傳遞。

因此，兩者不能被當成同一種結果。上游形成的限制到了下游仍然構成限制；而上游形成的 ALLOW，並不意味著下游已經獲得了一個完成的 Execution Permission。它只表示當前 Action 可以繼續進入後續判斷。

這也是為什麼下游不能因為「上游已經放行」就省掉自己的檢查。它接收到的不是一份已經完成的最終許可，而是繼續判斷的資格。相反，上游已經形成的限制仍然約束下游：後續範圍可以繼續收緊，但不能僅因為下游沒有發現新的限制理由，就把已經存在的約束重新放寬。

這種不對稱也解釋了為什麼本章不建立一張統一的結果值表。如果把 ALLOW 與 DENY 排成同一組對稱枚舉，很容易讓人誤以為它們只是方向相反、性質相同的兩個值；而這裡建立的關係並不是這種對稱結構。

但不能從這一點繼續推出更多結論。首先，「限制可傳遞、放行不可傳遞」並沒有建立一套傳播算法或代數。其次，它也不能被直接改寫成「拒絕優先」的普遍規則；這種更強的命題在本章沒有成立。

同樣，**Policy-side Deny 不能被直接等同於 Final Veto。**本章只保留這一否定邊界，不進一步建立兩者之間尚未確定的結構關係。

這一章沒有回答的

到這裡，有三件事仍然沒有答案。第一，**Policy Convergence 發生在哪一層。**誰承載這個過程，它在系統中的具體位置是什麼，本章沒有建立結論。Runtime 不能因為與執行期裁決有關，就被直接指定為它的承載位置。

第二，**Policy Convergence 的輸出是否等於 Execution Qualification。**本章只建立規則側能夠形成一個有限、具體、可驗證的範圍，並沒有進一步把這個範圍定義成執行資格。

第三，**Policy Convergence 的輸出是否構成 Final Execution Authority 的一部分。**這個關係同樣沒有建立，因此本章既不能把兩者合併，也不能替它們補出一個形式關係。

除了這三項，本章仍然保留著一組更細的未決問題。例如，哪些 Policy 可以被稱為「關鍵」，哪些來源屬於「必要來源」；「不適用」是否需要擁有獨立於「不滿足」的語義；所謂 Deny Dominance 究竟適用於哪些對象；風險分級需要怎樣的前置判據；以及結果應當如何分類、多個結果之間如何組合。這些問題目前都沒有完整答案。

它們的存在並不削弱本章已經建立的方向。相反，它們限定了這條方向能夠被說到什麼程度。本章能夠確定「只能收緊、不能放寬」，能夠確定舉證責任在解除側，也能夠確定不足本身不能產生放寬；但這些結論並不足以自動推出完整算法、結果分類、層位模型或組合關係。

還有兩條邊界需要繼續保持。第一，前文提到的形式化措辭只能作為歷史表達，不能成為本章的定義語言。第二，Policy Convergence 目前沒有正式概念編號，本書也不在這裡為它創建一個。

這意味著後續再遇到這一過程時，只能繼續按照它已經建立的功能和邊界來描述，而不能把一個尚未成立的編號、模型或形式關係當作既有結論直接引用。

因此，第十三章最終能夠交出的，是一個規則側有界收斂過程及其方向邊界，而不是一套已經閉合的完整理論。

這一章之後

到這裡，規則側能夠交出的結果已經有了明確邊界：它是一個綁定當前 Action 的有限、具體、可驗證範圍，不得比任何仍然有效、仍然適用、仍在範圍內的約束更寬；解除約束需要由解除側建立依據；必要輸入不足時，也不能因此擴大這個範圍。

這個規則側結果不是 Execution Permission，不是 Execution Decision，不是 Final Execution Authority，也不是 Reality Change。它限定的是當前 Action 在規則側能夠到達的範圍，而不是直接決定這一次 Action 最終是否進入現實。

但規則側已經形成有限範圍，與 Action 真正發生之間仍然不是同一件事。Intent 已經識別並綁定，Authorization 已經成立，Approval 已經完成，Policy result 已經形成，Signature 已經齊備，甚至 Execution Qualification 也已經建立，這些條件仍然只說明正向資格已經走到了這裡。

於是，下一個問題是：那麼在正向資格已經形成之後，還有什麼能夠阻止它到達現實？

本章術語

• 策略收斂 ｜ Policy Convergence
• 策略 ｜ Policy
• 規則側可執行範圍 ｜ Policy-Side Executable Scope
• 規則側有界結果 ｜ Policy-Side Bounded Result
• 適用範圍 ｜ Applicability Scope
• 執行資格 ｜ Execution Qualification
• 執行許可 ｜ Execution Permission
• 執行決定 ｜ Execution Decision
• 最終執行裁決權 ｜ Final Execution Authority
• 現實改變 ｜ Reality Change
• 放行 ｜ ALLOW
• 拒絕 ｜ DENY

其中，Policy Convergence 表示多個有限、有明確來源和適用範圍，並綁定當前 State、Context 與 Intent 的 Policy、Constraint 與 Condition，形成當前具體 Action 的有限、具體、可驗證規則側範圍的過程。

Policy Convergence 在本章中沒有正式概念編號，也不被定義為一套具體算法、統一結果枚舉、求值順序或數據結構。

本章同時保持四條邊界：

Policy Convergence ≠ Execution Permission Policy Convergence ≠ Execution Decision Policy Convergence ≠ Final Execution Authority Policy Convergence ≠ Reality Change

規則側形成的範圍可以繼續約束後續判斷，但它本身不等於這一次 Action 已經獲得最終許可，也不意味著現實狀態已經發生改變。

本章案例與資料來源

本章無現實案例。

正文中關於多條規則同時作用於同一次 Action、不同規則具有不同適用範圍、舊約束是否已經失效或被合法替代無法確認、必要輸入處於 Missing、Unknown、Expired、Unverifiable 或 Conflict 狀態，以及上游已經形成 ALLOW 但下游仍需繼續檢查等情形，均屬於假設性工程場景。

這些情形用於說明 Policy Convergence 為什麼需要形成一個有限、具體、可驗證的規則側範圍，以及為什麼收斂只能收緊、不能因為缺失、衝突或默認值而放寬。它們不對應具體公司、產品、事故或現實事件，也不承擔本章理論結論的證明作用。

資料來源

本章沒有需要單獨展開的現實事件資料。正文涉及的 Policy、Constraint、Condition、State、Context、Intent、ALLOW、DENY、Execution Qualification、Execution Permission、Execution Decision、Final Execution Authority 與 Reality Change，均按照本書已經建立的工程語義和邊界使用。

Policy Convergence 發生在哪一層，其輸出是否等於 Execution Qualification，是否構成 Final Execution Authority 的一部分，以及多個收斂結果之間如何組合，繼續保持開放，本章不為這些問題提前補出答案。

涉及外部論文、標準、官方資料或現實事件的內容，統一列入本書附錄及全書 《參考文獻與資料來源》。

---

第十四章｜資格齊了，仍然可以不讓它發生

本章討論正向資格全部成立以後，現實執行為什麼仍然可以被阻止。Intent、Authorization、Approval、Policy result、Signature 與 Execution Qualification 即使齊備，也不能自動消除一條仍然有效的 Final Veto。這裡的 Final Veto 是面向當前、具體、受保護 Action 的負向執行約束：它必須能夠在現實效果閉合前觸達實際執行路徑，並且不能被受約束方繞過或直接覆蓋。它只能阻止當前 Action，不能因此修改 Intent、Target，或者創造替代動作。一個有效 Final Veto 在同一 Action、範圍、目標、語境和時間內，也不能被更多正向同意抵消；但不可補償不等於永久，也不等於不可恢復。Deny 被產生出來，與 Deny 真正約束 Executor，仍然是兩個問題。本章留下的下一問是：從外部看都只是「沒有發生」，資格未建立、明確拒絕、能力級拒絕和 Final Veto 真的是同一件事嗎？

上一章已經把規則側能夠給出的範圍收緊下來。多個各自有限、適用範圍不同、彼此可能不一致的規則側輸入，最終形成了這一次 Action 的有限範圍；收斂後的範圍不得比任何仍然有效、仍然適用、仍在範圍內的約束更寬，放寬約束的舉證責任在解除側，依據不足本身也不能帶來擴權。

再沿著執行鏈往前看，正向條件也可以已經全部具備：Intent 已經識別並綁定，Authorization 已經成立，Approval 已經完成，Policy 給出了結果，Signature 齊備，甚至 Execution Qualification 也已經形成。

問題因此落到了更靠近現實的一端：當這些正向資格已經成立以後，還有什麼能夠真實阻止這一次 Action 獲得現實執行效力？

前面的討論主要回答的是這一次 Action 是否取得了它應當取得的條件：是否存在明確 Intent，是否獲得 Authorization，Approval 是否成立，Policy 是否允許，Execution Qualification 是否已經建立。這些問題共同指向資格的形成，但資格形成並不等於現實效果已經閉合。在 Action 真正改變現實之前，仍然存在一個不同的問題：已經具備資格的動作，是否還能夠被有效阻止。

第七章已經建立過一條與此直接相關的邊界：如果一個上限可以被受它約束的主體自行抬高，它就不是有效的執行邊界。到了這裡，同一原則需要作用在拒絕一側：一個名義上的拒絕是否真的能夠約束現實執行，不能只看它是否存在，還要看它是否真正構成有效約束。

本章討論的正是這樣一種負向執行約束關係。它不增加新的正向資格，也不替 Action 創建新的目標或動作；它的作用只有一個方向——在相應條件成立時，阻止這一次受保護的 Action 獲得現實執行效力。

本章沿用 最終否決（Final Veto） 這一稱呼，但它在這裡沒有正式概念編號，接下來的討論也不會把它提前寫成一個形式定義。

只具有負向作用方向

存在一種面向一次當前的、具體的、受保護 Action 的負向執行約束關係。即使上游已經形成 Intent、Authorization、Approval、Policy result、Signature 或 Execution Qualification，只要一個仍然有效、仍在範圍內、可達，並且不可被受約束方繞過或直接覆蓋的負向約束，在受保護的現實改變效果閉合之前成立，這一次 Action 就不得獲得現實執行效力。

這段關係描述不是形式定義。它在這裡承擔的是限定本章討論對象的作用，而不是建立一套已經閉合的形式體系。後面的可達、不可繞過、適用範圍、時機和作用方向，仍然需要分別展開，不能被壓縮進一個看似完整的定義裡。

其中一個必須明確的邊界是：這條約束只具有負向作用方向。它不得因為能夠拒絕一次 Action，就自動獲得創建替代 Action、修改 Intent、修改 Target、生成新的業務動作，或者實施另一項現實副作用的權力。

「能夠阻止」與「能夠決定應該怎樣做」是兩個不同的問題。把一次轉賬攔下來，並不意味著可以把金額改小以後再放行；後者已經形成了新的 Action，需要重新取得屬於它自己的正向資格。Final Veto 所承擔的是阻止當前 Action 獲得現實執行效力，而不是替當前 Action 生成一個新的執行版本。

還有兩條邊界需要同時保留。第一，這條關係不保證否決持有者永遠正確。當相應負向約束成立時，它能夠阻止這一次 Action 獲得現實執行效力，但拒絕本身仍然可能錯誤、造成損失，或者事後被證明沒有必要。這些問題不由 Final Veto 本身解決。

第二，這條關係也不保證所有 Action 都受到同等強度的保護。它面向的是受保護的 Action；哪些 Action 需要保護，以及保護強度如何確定，都不由這條關係回答。

最後還要區分結果與結構：**一次可觀察到的拒絕結果，並不能證明這條負向執行約束關係已經成立。**系統可以返回失敗、記錄 Deny 或表現為沒有執行，但僅憑這些結果，既不能推出存在一個仍然有效、可達、不可繞過的負向約束，也不能推出存在一個獨立的 Final Veto holder。

因此，拒絕結果描述的是發生了什麼；本章討論的則是，這個結果背後是否真的存在足以約束現實執行的結構。

七項條件，而且這個數字是開放的

上面的負向執行約束關係要成立，需要同時滿足多個條件。這裡至少可以明確七項。

第一，它面向的必須是一次當前的、具體的、受保護的 Action，而不是一類 Action、一條 Policy 或一種抽象情形。「這類操作原則上不允許」表達的是規則；本章討論的則是「這一次、現在正要發生的 Action，不得獲得現實執行效力」。兩者可以同時成立，也可以分別存在：規則側的結論與這一次具體執行是否真正被阻止，並不是同一件事。

第二，上游的正向資格可以已經成立。如果只在 Intent、Authorization、Approval、Policy result 或 Execution Qualification 本身沒有建立時討論「不能發生」，處理的仍然是資格不足。本章關注的是另一種情況：正向資格已經具備，而現實執行仍然能夠被有效阻止。

第三，這條負向約束在當前仍然有效，並且仍在適用範圍內。已經過期、已經被合法解除，或者本來就不適用於這一次 Action 的約束，都不能據此產生最終否決。「仍在範圍內」同樣是必要條件：一條只針對特定對象、環境或時間成立的約束，不能越出自己的適用範圍去限制其他 Action。

第四，它必須在受保護的現實改變效果閉合之前具有因果上的觸達。效果一旦已經閉合，隨後出現的拒絕只能成為記錄、追責或後續處置的一部分，不能再阻止已經發生的現實改變。

第五，被這條負向約束所約束的一方不能繞過它。

第六，它的作用方向必須保持為有界的負向。

第七，它不能因為具有拒絕能力，就自動獲得創建替代 Action 的權力。

其中，第六項和第七項是上一節「只具有負向作用方向」的進一步展開。這裡的口徑是至少包含七項，而不是「由七項構成」，因此不能把它整理成一份「七項齊備即可證明 Final Veto 成立」的機械檢查表。本章沒有建立一個封閉、完備的充分條件集合。

同樣不能從這裡推出「所有必要條件都構成 Final Veto」。一次受保護的執行還依賴許多其他必要條件，例如網絡可達、時鐘狀態或輸入格式；這些條件缺失時，Action 同樣可能無法發生，但它們並不會因此自動成為本章討論的負向執行約束關係。

名義上的拒絕

先看可達。名義上擁有 Deny 的主體或組件，如果無法影響實際執行路徑、必要能力的釋放，或者受保護的現實改變效果，就不擁有一個有效的 Final Veto。

系統可以存在審核節點、拒絕按鈕，也可以在權限關係中明確寫出 Deny；一次拒絕同樣可以被記錄進日誌、返回給調用方並顯示在界面上。但如果這個拒絕沒有真正落在通向受保護現實效果的因果路徑上，動作仍然可能繼續到達現實。這裡缺少的不是拒絕的表達，而是拒絕對現實執行的實際觸達。

因此，**Reachability 是必要條件，Non-Bypassability 是實現屬性。**兩者都需要落實到實際執行路徑上。

Non-Bypassability 進一步帶來一條覆蓋要求：一個有效的 Final Veto 必須覆蓋全部能夠產生同等受保護效果的路徑，包括正常路徑、重試路徑、恢復路徑、管理路徑、調試路徑、備用執行者、備用密鑰、離線路徑與降級路徑。只要仍然存在一條能夠產生同等受保護效果、卻不受同等負向約束的等價路徑，這個 Final Veto 對該受保護效果就不是全局有效的。

這裡的「包括」必須保留。上述路徑只是對覆蓋要求的說明，不是一份窮盡清單。真正的判斷標準不是某幾類路徑是否已經逐項檢查，而是所有能夠產生同等受保護效果的路徑，是否都受到同等約束。

因此，判斷兩條路徑是否等價，看的不是它們在架構圖上屬於哪一層、由誰維護，或者是否經過同一個接口，而是它們最終能否產生同等的受保護效果。例如，一條正常業務路徑與一條恢復路徑在架構位置、用途和入口上都可以完全不同，但如果最終能夠造成同等的現實改變，它們就需要進入同一覆蓋判斷。

這與前面已經建立的 Execution Boundary 方向一致：如果存在一條不經過同等檢查、卻能夠產生同等現實結果的路徑，邊界就沒有真正覆蓋那個現實效果。但這裡列出的具體路徑種類只是對 Final Veto 覆蓋要求的說明，不能反過來寫入 Execution Boundary 的既有定義。

最後還要保留一個邊界：**Reachability 是因果意義上的可達，不必然意味著物理共址。**本章不要求統一的物理拓撲，也不要求 Final Veto 必須被實現為某一種硬件、某一臺設備或某一個單獨的產品組件。需要建立的是它對受保護現實效果的因果觸達，而不是特定的物理位置。

再多的同意也不能補償

接下來需要說明的是不可補償。在同一次 Action、同一範圍、同一目標、同一裁決語境和同一時間內，如果一個 Final Veto 仍然有效、可達、不可繞過，並且構成這次具體執行所需的負向約束，那麼即使其他正向資格已經成立，也不能通過增加更多同意來抵消它。只要這個負向約束仍然成立，受保護的執行就不得繼續。

這正是本章標題「資格齊了，仍然可以不讓它發生」的含義。這裡並不是說前面的 Intent、Authorization、Approval、Policy result、Signature 或 Execution Qualification 是無效的，而是說這些正向條件的成立，並不會自動消除一個仍然有效的 Final Veto。

這條關係同時必須保留兩項限制：

不可補償不等於永遠。

不可補償不等於不可恢復。

之後完全可能形成新的資格，但那意味著進入一次新的裁決：對象、語境、時間或適用條件已經發生變化，需要重新判斷相應的正向資格與負向約束。它不是在原來的同一次裁決中，用更多同意把一個仍然有效的 Final Veto 抵消掉。

因此，「同一裁決語境」是不可補償成立的重要邊界。換了語境，原來的 Final Veto 是否仍然有效、是否仍在範圍內，都需要重新判斷。本章建立的是當前這一次裁決中的不可補償關係，而不是給某個 Action 永久加上一道不能解除的封條。

所以，不可補償也不能被理解為終局性。後來 Action 仍然可能在新的條件下獲得執行資格並最終發生，但那屬於新的裁決，不表示原來的否決曾經被更多同意抵消。

這一關係也不建立一般意義上的投票規則、優先級規則或 Policy aggregation rule。不可補償不是「Final Veto 的優先級更高」，也不是一套輸入排序機制。這裡能夠確定的只有一點：在上述限定條件成立時，增加更多正向同意不能補償當前仍然有效的 Final Veto。

九個相鄰對象都不能替代它

到這裡需要確認一個問題：Final Veto 是否其實已經包含在某個已有對象之中。如果可以，就沒有必要再單獨討論它。

逐一比較九個相鄰對象後，可以看到，每一種替代都會丟掉一部分本章已經建立的結構。

把它直接讀成 Explicit Deny，會丟掉真實的 Reachability 與實際強制性。一個 Deny 可以完整存在於系統中，卻未必真正觸達到受保護的現實執行路徑。

把它讀成 No Allow 或「Execution Qualification 沒有建立」，會丟掉一個有約束力的負向結構，以及由此產生的 holder 問題。缺少正向同意描述的是資格沒有建立，它本身並不會回答是否存在一個具有約束力的負向結構，也不會提出由誰持有這一約束的問題。

把它讀成 Fail-Secure，會丟掉權限、能力和邊界的實現關係。Fail-Secure 規定的是失敗方向：條件無法充分建立時，不足不得自然轉化為 ALLOW，也不得因此擴大現實執行能力。它不創建 holder，也不創建拒絕權限。

把它讀成 capability-level refusal，會丟掉歸屬、獨立性與 non-compensability。一次 Action 在能力層面沒有發生只是一個結果，從這個結果不能推出存在一個獨立的 Final Veto holder。

把它讀成 Authority，會丟掉時機、因果路徑以及有界的負向作用方向。Authority 本身並不自動包含本章對 Final Veto 所要求的這些限定。

把它讀成 Final Execution Authority，範圍又過大。Final Veto 可以構成 Final Execution Authority 中一項必要的負向約束，但它不是完整的 Final Execution Authority。

把它讀成 Policy，會丟掉因果層面的強制與 Non-Bypassability。Policy 可以表達規則，但規則存在本身並不證明它能夠真正阻止現實執行。

把它讀成 Execution Boundary，同樣不能完整覆蓋這裡討論的負向約束關係。Execution Boundary 規定執行能夠到達的邊界，而本章還要求一個能夠在具體 Action 上形成現實約束力的負向關係。

把它讀成 Execution Control，則是範圍相反的問題。Execution Control 是更大的判斷與控制體系，Final Veto 只是其中一個很窄的負向結構，不能用整體概念替代這個具體問題。

這九項比較的意義，不是證明 Final Veto 已經因此成為一個新的正式概念，而是說明：把它直接併入任何一個相鄰對象，都會丟掉一部分已經建立的關係或邊界。

同樣，也不能反過來推出所有 Deny 都是 Final Veto。一個 Deny 可以完整存在，卻沒有 Reachability、Non-Bypassability 或其他必要條件，因此並不構成有效的 Final Veto。

這些相鄰對象各自承擔不同的作用。Final Veto 與它們有關，但不能被其中任何一個完整替代。

不可繞過的最低要求

「不可被受約束方繞過或者直接覆蓋」如果只停留在這句話上，還不足以成為一個可以檢查的要求。至少有一條最低邊界可以明確下來。

被 Final Veto 約束的一方，不能同時無條件控制三樣東西：否決所依據的判斷基礎、否決是否持續有效的狀態，以及所有能夠產生同等受保護效果的執行路徑。

如果這三項都被同一個受約束主體完全控制，那麼這個主體就可以改變否決所依據的條件，使否決失效，或者轉向另一條能夠產生同等現實效果的路徑。Final Veto 即使在接口、配置或日誌中仍然存在，也無法因此獲得真正的獨立性。

但這只是一條否定式的最低要求，不是充分條件。三項控制沒有同時集中在受約束方，並不能反過來證明 Final Veto 已經有效。前面已經建立的有效性、適用範圍、Reachability、Non-Bypassability 和作用方向等條件仍然需要成立。

之所以採用否定式，是因為正面的 holder 結構目前並沒有答案。如果要直接規定「Final Veto holder 必須是什麼、必須具備什麼」，就必須先解決 holder 本身究竟是哪一類對象。本章沒有建立這個結論。因此，這裡只確定一個不依賴 holder 最終形態的邊界：無論 holder 最終如何定義，上述三項都不能同時被受約束方無條件控制。

那麼，誰能夠持有 Final Veto？可能涉及的對象包括人、本地設備、安全域、硬件邊界、Runtime、Authority structure，以及分佈式集合。它們都可能承擔承載或參與作用，但最終 holder 必須是哪一類對象，本章不作判斷。

這裡能夠確定的一條邊界是：**Carrier 不等於 Authority Holder。**某個硬件、Runtime 或其他組件可以承載 Final Veto 的實現，但「承載這個能力」本身並不能證明它就是該否決權的 holder。至於一個結構或分佈式集合是否能夠滿足 holder 所需的形式要求，本章同樣保持開放。

Owner 或 Admin 也不會僅僅因為擁有或管理系統，就自動獲得覆蓋 Final Veto 的權力。Override Authority 需要被單獨建立，不能從所有權或管理權限中直接推出。

同樣，由原有來源直接解除或覆蓋 Final Veto，與在新的條件下重新取得 Execution Qualification 不是同一件事。誰擁有 release / exit authority，以及在什麼條件下能夠解除這一負向約束，本章都沒有給出答案。

正向收斂與最終否決不能互相替代

上一章處理的是規則側的正向收斂：多個有限的規則側輸入如何形成當前 Action 的一個有限範圍。這個過程回答的是正向範圍能夠到哪裡，它本身不是 Final Veto。

反過來也一樣。Final Veto 不能被直接併入 Policy 或 Policy Convergence。它處理的是一個已經具備正向資格的 Action，是否仍然存在一個有效的負向約束能夠阻止其獲得現實執行效力。兩者彼此相關，但回答的是不同問題，不能互相替代。

這裡還需要擋住兩個容易出現的等號。**Policy-side Deny 不等於 Final Veto。**Policy 可以在規則側給出 Deny，但僅有這個結果，並不能證明相應負向約束已經具備 Reachability、Non-Bypassability 以及本章前面要求的其他條件。

同樣，策略內部「出現 Deny 後如何形成 Policy result」的處理，也不等於這裡的 non-compensability。前者屬於規則側結果如何形成的問題，後者限定的是在同一次具體裁決中，一個仍然有效的 Final Veto 能否被更多正向同意抵消。

至於 Final Veto 是否只是 Policy 的一個輸入，或者它能否被 Policy Convergence 覆蓋，本書目前沒有建立答案，因此這裡不作決定。

另一個必須保留的缺口出現在多個負向約束同時存在時。目前能夠確定的只有有限幾項：多個必要的負向約束可以共同限制同一次 Action；只要其中一個仍然有效、仍構成當前執行所需的負向約束，受保護的執行就不能因為其他正向條件已經成立而自動繼續；更多正向同意也不會自動消除其中任何一個獨立的阻止。

再往下的組合關係仍然沒有建立。每一個必要條件是否都構成 Final Veto，多個 Final Veto 之間是否存在優先級，是否需要 quorum，怎樣聚合，發生衝突時如何處理，過期與撤銷如何組合，以及多個 Deny 之間是否存在一套統一代數，這些問題目前都沒有答案。Policy 一側同樣沒有建立一套可以直接移植過來的 multiple-Deny aggregation rule。

因此，本章不能為了讓結構看起來完整，就自行補出「任一 Deny 即拒絕」、固定優先級或其他組合規則。那樣得到的會是一套新的規範，而不是本章已經建立的結論。

最後還需要說明 Final Veto 的概念狀態。Final Veto 在本章中承擔了重要的理論作用，但它目前沒有正式概念編號。前面建立的是一條被凍結的負向執行約束關係，並且已經明確說明它不是形式定義；與此同時，這一主題的正式概念編號仍然保持為空。

因此，本章不會因為已經能夠清楚討論 Final Veto，就進一步把它寫成一個已經完成形式化的正式概念。給它補上一個尚未建立的編號，會讓當前仍然開放的理論狀態看起來已經閉合。

什麼都沒有發生

到這裡，前面建立起來的正向資格仍然全部有效，也仍然都是 Action 獲得現實執行效力所需要的條件。但這些條件全部成立，並不自動意味著這一次 Action 最終一定會發生。

資格回答的是這一次 Action 是否取得了所需的 Intent、Authorization、Approval、Policy result、Signature 與 Execution Qualification；本章補上的則是另一側：即使這些正向條件已經形成，一個仍然有效的 Final Veto 仍然可以阻止它獲得現實執行效力。

於是問題落到了結果一側。一次 Action 最終沒有進入現實，從外部觀察上可能呈現出相似的結果：資格沒有建立起來時，它沒有執行；資格已經形成、但被一個有效的 Final Veto 阻止時，它同樣沒有執行。日誌、監控或外部狀態看到的，都可能只是「這次 Action 沒有發生」。

但相同的外部結果，並不能說明內部發生的是同一件事。「沒有執行」看起來都一樣——但它們是不是同一件事？

本章術語

• 最終否決 ｜ Final Veto
• 負向執行約束 ｜ Negative Execution Constraint
• 可達性 ｜ Reachability
• 不可繞過性 ｜ Non-Bypassability
• 等價路徑 ｜ Equivalent Path
• 不可補償性 ｜ Non-Compensability
• 否決持有者 ｜ Veto Holder
• 承載者 ｜ Carrier
• 權限持有者 ｜ Authority Holder
• 覆蓋權 ｜ Override Authority
• 執行資格 ｜ Execution Qualification
• 最終執行裁決權 ｜ Final Execution Authority
• 明確拒絕 ｜ Explicit Deny
• 受保護的現實改變效果 ｜ Protected Reality-Changing Effect

其中，Final Veto 在本章中表示一種面向當前、具體、受保護 Action 的負向執行約束關係。只要該約束仍然有效、仍在範圍內、可達且不可被受約束方繞過或直接覆蓋，並在受保護的現實改變效果閉合之前成立，這一次 Action 就不得獲得現實執行效力。

Final Veto 只具有負向作用方向。它不能因為具有拒絕能力，就自動獲得創建替代 Action、修改 Intent、修改 Target、生成新的業務動作或實施其他現實副作用的權力。

Non-Compensability 表示在同一次 Action、同一範圍、同一目標、同一裁決語境和同一時間內，一個仍然有效的 Final Veto 不能被更多正向同意抵消。不可補償不等於永久，也不等於不可恢復；新的條件成立後可以形成新的裁決。

Reachability 指負向約束在因果意義上能夠觸達實際執行路徑、必要能力釋放或受保護的現實改變效果，不要求物理共址。Non-Bypassability 要求所有能夠產生同等受保護效果的等價路徑都受到相應約束。

本章沒有確定 Final Veto 的最終 holder 必須是哪一類對象。Carrier 也不自動等於 Authority Holder；人、本地設備、安全域、硬件邊界、Runtime、Authority structure 或分佈式集合都不能僅憑承載形態被直接認定為最終持有者。

Final Veto 在本章中沒有正式概念編號，本章也不把上述關係描述擴展為形式定義。

本章案例與資料來源

本章無現實案例。

正文中關於攔截轉賬後不能自行修改金額重新放行、系統存在審核節點和 Deny 權限但拒絕並未真正觸達現實執行路徑、正常業務路徑與恢復路徑可能產生同等現實效果，以及增加更多簽名仍不能抵消當前有效 Final Veto 等情形，均屬於假設性工程場景。

這些情形用於說明 Final Veto 的負向作用方向、Reachability、Non-Bypassability 與 Non-Compensability，並幫助區分名義上的 Deny、能力層面的拒絕與真正具有現實約束力的負向執行關係。它們不對應具體公司、產品、事故或現實事件，也不承擔本章理論結論的證明作用。

資料來源

本章沒有需要單獨展開的現實事件資料。正文涉及的 Final Veto、Execution Qualification、Final Execution Authority、Policy、Deny、Execution Boundary、Execution Control、Reachability、Non-Bypassability 與 Non-Compensability，均按照本書已經建立或在本章明確限定的工程語義使用。

Final Veto 最終由誰持有，結構或分佈式集合能否滿足 holder 要求，誰擁有 release / exit authority，以及多個 Final Veto 或多個 Deny 之間是否存在優先級、quorum、聚合、衝突處理或統一代數，繼續保持開放，本章不為這些問題提前補出答案。

涉及外部論文、標準、官方資料或現實事件的內容，統一列入本書附錄及全書 《參考文獻與資料來源》。

---

第十五章｜四種「沒有發生」

本章把同一個外部結果「Action 沒有發生」拆成四種不同結構。ALLOW NOT ESTABLISHED 是正向資格沒有建立的狀態；Explicit Deny 是明確的否定性決定結果；Capability-Level Refusal 是現實執行路徑最終沒有賦予 Action 執行效力的 outcome；Final Veto 則是負向約束在最終因果路徑上真正獲得阻止效力的結構關係。四者不是強弱不同，而是範疇不同，因此不能從「沒有發生」反推出「有人拒絕了」，也不能從 Deny 存在推出有效 Veto 已經成立。Fail-Secure 也不屬於這四項，它描述的是 qualification 無法建立時的 failure direction。本章不把四項整理成統一 disposition enum，Outcome Semantics 仍然開放。Boeing 737 MAX 案例只用於暴露 outcome 與 structure 的差別，不承擔理論證明。四項分開以後，問題轉向 Final Veto 本身：拒絕能力會不會失效，又能不能把失效方式列成一張完整清單？

上一章結束在一個很簡單的結果上：一次 Action 沒有獲得現實執行效力。從外部觀察，看到的只是「它沒有發生」。

問題在於，同樣的外部結果可以來自完全不同的內部結構。正向資格沒有建立，Action 不會發生；某個位置明確給出了 Deny，Action 也可能沒有發生；現實執行路徑最終沒有賦予它執行效力，結果仍然是沒有發生；一個有效的 Final Veto 真正阻止了它，外部看到的同樣還是沒有發生。

到了結果一側，這些差別很容易被壓平。日誌、監控或外部狀態能夠告訴我們「Action 沒有發生」，但這個結果本身並不會自動說明它為什麼沒有發生，也不能告訴我們背後究竟是哪一種結構。

因此，本章只回答一個問題：

同樣是「這次 Action 沒有發生」，它們是不是同一種語義結構？

這個問題決定了一條反向推理是否成立：從「沒有發生」能不能推出「被拒絕了」，從「被拒絕了」能不能繼續推出「存在一個有權拒絕的主體」，再進一步推出「這次拒絕真正阻止了現實執行」。

本章的答案是否定的，需要區分四項：**資格沒有建立、明確拒絕、能力級拒絕、最終否決。**它們可以產生相似的可觀察結果，但彼此不是同一種語義結構，也不能從其中一項自動推出另一項。

資格沒有建立

資格沒有建立，首先是一種狀態。ALLOW NOT ESTABLISHED 不是一次否定動作，而是一種狀態：這一次 Action 所需要的正向資格沒有被充分建立。它不要求任何主體已經作出一次否定性決定，也不證明存在一個能夠行使 Veto 的 holder。

Intent 的識別與綁定、Authorization、Approval、Policy result、Evidence Sufficiency、Signature 或 Execution Qualification 等正向條件，只要其中所需的一項沒有建立完整，都可能使 Action 停留在這個狀態。這裡描述的是「所需資格沒有形成」，而不是「某個人已經說了不」。

如果把這個狀態直接讀成一次拒絕，就會順手引入一整套並未成立的前提：誰拒絕了、為什麼拒絕、誰能夠推翻這次拒絕。實際上，ALLOW NOT ESTABLISHED 本身並不回答這些問題。它既不要求有人作出過拒絕，也不表明存在某個 Veto holder；它只說明所需的正向資格仍然沒有建立。

這個狀態隨後可以成為其他判斷的輸入，例如觸發拒絕、暫停或重新驗證，但狀態本身不等於一個具有現實阻止效力的結構。如果要真正阻止 Action 到達現實，還需要另外建立相應的可達、不可繞過的負向約束關係。

第十二章已經從 failure direction 一側固定過這一邊界：Execution Qualification 無法建立，不自動等於 Explicit Deny 已經存在，也不自動等於 Final Veto 已經被行使。

ALLOW NOT ESTABLISHED 本身還保持另一組邊界：它不自動等於 Explicit Deny，不自動等於 Final Veto，不自動等於 permanent termination，不自動等於同一種 Safe Mode，也不自動等於同一條 recovery path。

這兩組否定來自不同的問題，不能合併成一份統一枚舉。這裡需要保留的結論只有一個：

資格沒有建立，就是資格沒有建立。它不能被自動改寫成一次拒絕，更不能被自動改寫成一個已經生效的 Final Veto。

明確拒絕

明確拒絕是一項明確的否定性決定結果。明確拒絕與 Final Veto 的區別不在於誰更強。**Explicit Deny 是決定結果，Final Veto 是結構關係。**前者可以被產生、記錄和傳遞；後者回答的是這項負向約束能否真正作用到現實執行路徑上，使當前 Action 無法獲得現實執行效力。

因此，這裡有一條必須保留的不等式：Deny 存在，不等於有效 Veto 存在。

最直接的情況是，Policy engine 已經輸出 Deny，但 Executor 並沒有受到這個結果的實際約束，Action 仍然能夠繼續執行。此時 Explicit Deny 已經明確存在，但有效的 Final Veto 並沒有因此自動成立。

缺少的不是這次 Deny 本身的完整性，而是它與現實執行路徑之間的約束關係。即使 Deny 具有清楚的判斷依據、完整的記錄和明確的輸出，只要它無法真實影響最終執行路徑，它仍然只是一個決定結果。

所以，這也不是把 Deny 做得「更嚴格」就能解決的問題。增加判斷條件、補充理由、完善記錄或者加強簽名，都可以提高這個決定結果自身的完整性，但不能自動建立它對現實執行的約束力。

因此，「系統能夠產生 Deny」只能說明明確拒絕這一結果對象存在，**回答不了這個 Deny 是否真正攔住了現實執行。**要回答後一個問題，還必須繼續檢查它是否具有 Reachability、是否能夠被受約束方繞過或直接覆蓋，以及它與最終現實執行路徑之間究竟是什麼關係。

能力級拒絕

能力級拒絕描述的是一個 outcome：現實執行路徑最終沒有賦予這一次 Action 執行效力。

它既不是一次否定性決定，也不是一種負向結構關係，而是執行路徑最終留下的結果。一個有效的 Final Veto 生效時可以產生這樣的 outcome，但同樣的結果也可以來自其他原因，例如資格沒有建立、提交沒有形成、時間窗沒有開放或者某個組件不可用。

這裡的「例如」不能被讀成一份完整的成因清單。這些只是能夠產生 capability-level refusal 的若干情形，本章沒有建立一套窮盡的原因分類，也不能通過排除這些情形，反推出剩下的原因必然是某種拒絕。

因此，這裡需要明確另一條邊界：

這個 outcome 不自動證明存在獨立的 Veto Authority，也不證明存在持有它的 holder。

從外部看到「沒有發生」，不能推出「有人拒絕了」；即使確實存在一次 Explicit Deny，也不能由此推出作出 Deny 的主體擁有相應的 Veto Authority；即使這個主體擁有相應 Authority，也不能僅憑最終沒有執行，證明正是這次 Deny 阻止了現實執行。

這一側可以藉助 Execution Capability 進一步說明。Execution Capability 指主體、組件或路徑使某類現實動作實際發生的能力。能力存在，不表示本次使用已經獲得 Authorization，也不表示最終裁決已經給出 Allow，更不表示這一次 Action 應當發生。

相應地，如果 Execution Capability 被上游主體無邊界地繼承、擴大，或者能夠繞過 Execution Control 被直接使用，那麼能力與約束它的控制關係就已經失效。此時控制結構和執行能力都可以繼續存在，但能力不再必須經過原有控制才能產生現實效果。

這裡還要保留一個語義邊界：當前正式使用的 Execution Capability 概念，並不能反過來替早期尚未確定的相關表述補出定義；反過來，早期表述留下的語義空缺，也不能用來否定已經建立的正式概念。兩者需要分別保持各自的邊界。

最終否決

Final Veto 在這裡屬於另一類對象。上一章已經建立了它的邊界，本章這裡只取它在四路區分中的範疇。

Final Veto 是一種結構關係：它使一條負向約束能夠在最終因果路徑上真實阻止當前 Action 獲得現實執行效力。

因此，它不是資格狀態，不是一次 Explicit Deny，也不是 capability-level refusal 所描述的 outcome。它只具有負向作用方向，並且在當前理論中沒有正式概念編號，也沒有被寫成一個形式定義。

一個有效的 Final Veto 生效，可以使現實執行路徑最終沒有賦予 Action 執行效力，也可以伴隨一次被記錄下來的 Explicit Deny。但這些可觀察結果都不能反過來證明 Final Veto 已經存在。

原因很簡單：同樣的 capability-level refusal 可以由其他原因產生，Explicit Deny 也可以在沒有形成有效 Veto 的情況下存在。

所以，這裡的關係只能單向理解：

Final Veto 可以產生「沒有執行」的結果，但「沒有執行」本身不能證明 Final Veto 存在。

四者不在同一條線上

把前面的四項放在一起，可以看到它們首先不是強弱不同，而是範疇不同。

資格沒有建立是狀態。明確拒絕是決定結果。能力級拒絕是 outcome。最終否決是結構關係。

因此，四者不能沿著同一條軸比較「哪一種更強」或「哪一種更硬」。一個狀態、一個決定結果、一個 outcome 和一種結構關係，本來就不是同一種對象。它們不能因此被排成一個從輕到重的序列，也不能被整理成一個統一的處置值域。

這裡建立的是四項之間的兩兩不等：它們不能互相替代，也不能僅憑其中一項的成立推出另一項成立。

但這並不意味著這四項已經窮盡了所有「沒有發生」的語義結構。本章只建立這四項之間的區別，不把它們擴展成一個封閉、完備的分類體系。

這裡還必須排除另一個容易混入的對象：Fail-Secure 不是四路中的一項。

Fail-Secure 規定的是 failure direction：當所需資格無法充分建立時，系統不得因為這種不足而自然朝現實執行方向繼續。Final Veto 討論的則是一條負向約束如何真正作用於當前 Action，使其無法獲得現實執行效力。前者是失敗語義，後者是結構關係，兩者不能互相替代，Fail-Secure 也不會因此被吸收進 Final Veto。

Fail-Secure 同樣不等於「安全地失敗」、fail-closed、shutdown 或 Safe Mode。它規定的是失敗方向，而不是要求所有系統進入某一個統一狀態。

最後還需要保留一處已有差異。在 Fail-Secure 主題側，相關區分採用的是三層：資格未建立、明確拒絕、能力級拒絕；在 Final Veto 主題側，本章採用的是四路，多出的一項就是 Final Veto。

這兩種口徑不需要被強行統一。它們服務於不同的問題，因此這裡保留各自的邊界，只登記這種差異，不把三層和四路合併成一個新的枚舉。

同一個結果，四種結構

前面的四項分別展開以後，可以把它們集中到同一個位置觀察。這裡真正需要比較的不是哪一種「拒絕」更強，而是它們各自屬於什麼範疇，以及從一個可觀察到的「沒有執行」結果中，究竟能夠推出什麼、又不能推出什麼。

表 II-2｜四種「沒有發生」：同一結果，不同結構

這張表把前面已經建立的區別放到了一起，但它不能被讀成四個處置結果。資格沒有建立、Explicit Deny、Capability-Level Refusal 與 Final Veto 分別屬於狀態、決定結果、outcome 和結構關係，因此四行之間不存在一個可以直接排序的統一值域，也不能進一步補出「哪一種更強」「系統接下來應該怎樣響應」或者「哪一種對應哪條恢復路徑」之類的列。那樣做等於先假定它們是同一類結果，再為它們安排不同取值，而本章建立的恰恰是相反的結論。

這裡還存在一個不能被跳過的空缺：**Outcome semantics 目前仍然沒有統一下來。**現有材料中同時存在二值和多值的處置表達，例如 pause / proceed、trip / scram、halt / reject、lock out / load shed、override / cut out、EDS / deadman / shut in、AZ-5 / bypass、No-Go / waiver。這些詞分別來自不同的工程系統，在各自語境中有明確含義，但目前沒有依據說明它們之間能夠如何映射、排序或互換，也沒有建立一個統一的 ALLOW / DENY / HOLD 處置模型。

因此，本章不能因為四項已經能夠被清楚地區分，就順便把它們壓縮成一個統一的 disposition enum，更不能把某一種現有工程處置直接裁定為這裡的 Deny。四路區分回答的是「這些沒有發生是不是同一種結構」，而不是「系統最終應該有哪些統一結果值」，這兩個問題必須繼續分開。

這個未決狀態還會影響後續表達：如果未來 Outcome semantics 本身被正式裁定，那麼所有與拒絕相關的結構都需要重新檢查其表達方式。當前能夠確定的，只是這四項彼此不同；至於統一的處置語義應當長成什麼樣子，本章沒有答案。

結果存在，不等於結構成立

前面的四項區分已經說明，Capability-Level Refusal 是 outcome，Final Veto 是結構關係。波音 737 MAX 的兩起事故可以把這一區別放到一個現實機制中觀察：2018 年 10 月 29 日的 JT610 與 2019 年 3 月 10 日的 ET302 在這裡不承擔理論證明，而只用於暴露一個具體機制——拒絕作用在一次 Action 上，與限制某種 Execution Capability，本身不是同一個問題。

在相關事件中，能力級的拒絕確實可以產生「這一次沒有執行」的結果，但這種拒絕又能夠被複位。正因為如此，一個真實的 capability-level refusal outcome 已經出現，並不能據此推出 Final Veto 所要求的結構關係已經成立。Final Veto 要求負向約束對受保護現實效果具有真正的阻止效力，而一個可以被重新打開的能力級拒絕，不能僅憑「曾經阻止過一次」就被等同於這樣的結構。

這正是本章使用這個案例的邊界。它能夠讓 outcome 與 structure 的區別變得具體，卻不能反過來證明四路區分本身。四路區分的成立不依賴任何一起事故；案例所能說明的，只是在真實機制中，「一次沒有執行」與「存在一道有效的 Final Veto」確實需要分別判斷。

兩起事故本身也不能被合併為一條事實鏈。它們共享某些結構特徵，但仍然是兩個獨立事件。對於 ET302，美國國家運輸安全委員會與埃塞俄比亞事故調查局在最終報告的部分程序表述以及迎角加熱器成因表述上存在公開分歧，因此這部分材料不能被寫成無爭議事實。本章也不據此展開飛控系統設計、適航認證過程或未逐字核實的危害等級判斷，因為這些內容都超出了本節所需的機制邊界。

還需要避免另一種反向推理。一次拒絕曾經生效，只能說明在那一次具體情況下它產生了作用，不能由此推出那個位置此前一定存在某種 Execution Gap，也不能推出那裡一定不存在 Gap。獅航事故前一航班的相關經過在這裡僅用於說明這種推理限制：觀察到一次拒絕成功，並不足以恢復出完整的結構狀態。

因此，這個案例真正能夠提供的是一種有限的觀察：同樣看到「沒有執行」，我們可以確認一個 outcome 已經發生，卻仍然需要另外判斷背後的結構關係是否成立。結果可以被觀察，結構不能由結果自動反推。

三個等號不能成立

到這裡，本章真正需要排除的三個等同已經可以明確下來。「沒有執行」不能直接等同於「被拒絕」。資格沒有建立時，Action 同樣可能沒有發生，而這個狀態本身既不要求已經存在一次 Explicit Deny，也不證明存在一個 Veto holder。「存在 Deny」也不能直接等同於「現實執行已經被阻止」，因為 Deny 是決定結果，它是否真正約束執行路徑，還需要另外的結構成立。最後，這四項也不能被整理成四檔處置結果，因為資格沒有建立、Explicit Deny、Capability-Level Refusal 與 Final Veto 分別屬於狀態、決定結果、outcome 和結構關係，目前也沒有建立一個能夠容納它們的統一 disposition value space。

這四項被區分以後，問題就從「為什麼這次沒有發生」轉向了另一個方向。Final Veto 是其中唯一直接討論負向約束如何獲得現實阻止效力的結構關係，但確認這種結構存在，並不等於它在所有條件下都可靠。上一章已經給出了它成立時需要滿足的條件：約束仍然有效、仍在範圍內、能夠觸達現實執行路徑、不能被受約束方繞過或直接覆蓋，並且必須在受保護的現實效果閉合之前成立。只要這些條件中的某一部分不再成立，原本能夠發揮作用的負向約束就可能發生變化。

前面的案例已經給出一個有限的提示：一個真實存在的 Capability-Level Refusal 可以被複位，因此觀察到「曾經拒絕成功」並不能保證相應的阻止能力會一直保持有效。但這種失效究竟可以怎樣發生、是否能夠被整理成一份清單，本章沒有回答。本章完成的是四種「沒有發生」的區分，而不是建立拒絕能力的失效分類。

拒絕能力本身可以怎樣失效？這是否能被壓縮成一份清單？

本章術語

• 允許未建立 ｜ ALLOW NOT ESTABLISHED / No Allow
• 明確拒絕 ｜ Explicit Deny
• 能力級拒絕 ｜ Capability-Level Refusal
• 最終否決 ｜ Final Veto
• 執行能力 ｜ Execution Capability
• 否決權威 ｜ Veto Authority
• 否決持有者 ｜ Veto Holder
• 安全失敗 ｜ Fail-Secure
• 最終執行裁決權 ｜ Final Execution Authority
• 結果語義 ｜ Outcome Semantics

本章最重要的術語邊界不是為四項建立新的共同上位概念，而是保持它們之間的區別：ALLOW NOT ESTABLISHED 是正向資格沒有建立的狀態，Explicit Deny 是明確的否定性決定結果，Capability-Level Refusal 是現實執行路徑最終沒有賦予當前 Action 執行效力的 outcome，Final Veto 則是使負向約束在最終因果路徑上獲得真實阻止效力的結構關係。

四項彼此不能自動推出，也不能按照強弱排成一個統一序列。特別是，Explicit Deny 的存在不等於有效 Final Veto 已經成立，Capability-Level Refusal 也不能反推出存在獨立的 Veto Authority 或 Veto Holder。

Fail-Secure 不屬於上述四項之一。它描述的是 qualification 無法充分建立時系統應當遵循的 failure direction，而不是一種拒絕結果或 Final Veto 的另一種名稱。

本章同樣沒有建立統一的 Outcome Semantics。目前不存在已經確定的 ALLOW / DENY / HOLD 統一處置值域，因此不能把上述四項改寫成 disposition enum，也不能把它們理解為四檔處置結果。這一未決狀態繼續保留。

本章案例與資料來源

本章使用 Boeing 737 MAX 的 JT610 與 ET302 兩起事故作為現實案例，用於暴露 Capability-Level Refusal 與 Final Veto 之間的機制差異。

2018 年 10 月 29 日的 JT610 與 2019 年 3 月 10 日的 ET302 在本章中始終作為兩起獨立事故處理，不合併為一條統一事實鏈。案例關注的是一個有限的機制問題：作用於 Execution Capability 的拒絕可以真實地產生「這一次沒有執行」的 outcome，但如果這種能力級拒絕能夠被複位，它就不能僅憑這個結果被認定為滿足 Final Veto 所要求的不可繞過與持續有效的結構關係。

因此，這組案例只用於機制暴露。它不能證明本章提出的四路區分，也不能因為觀察到一次拒絕曾經生效，就反推出相應位置此前一定存在或一定不存在 Execution Gap。案例提供的是對結構差異的現實觀察，而不是理論結論的來源。

資料來源

本章案例的事實資料主要來自印度尼西亞國家運輸安全委員會（KNKT）對 JT610 的最終調查報告、埃塞俄比亞事故調查局（EAIB）對 ET302 的最終報告、美國聯邦航空管理局（FAA）的 Boeing 737 MAX 審查總結，以及美國國家運輸安全委員會（NTSB）對 EAIB 最終報告的正式回應。

這些來源之間並非所有判斷都完全一致。尤其是 NTSB 對 EAIB 最終報告中的部分程序表述以及迎角加熱器相關成因表述提出過異議，因此這部分官方分歧在本書中繼續保留，不能被壓平成單一、無爭議的事實結論。

本章不展開 Boeing 737 MAX 飛控系統的完整技術分析，也不討論適航認證過程；未經逐字核實的危害等級表述同樣不作為本章論據。這裡使用案例的唯一目的，是幫助讀者看清：一個「沒有執行」的結果已經發生，並不等於背後的 Final Veto 結構已經成立。

涉及上述事故的完整官方資料，以及本書其他外部論文、標準與案例來源，統一列入全書 《參考文獻與資料來源》。

---

第十六章｜拒絕也會失效，而且給不出清單

本章確認拒絕能力本身也會失效，但當前證據還不足以給出一份完整失效清單。Execution Control 案例池從八起擴展到十一起時，能夠區分的拒絕失效形態從八種增加到十二種；重要的不是「十二」這個數字，而是新增案例仍在帶來新的結構，說明這一維度尚未穩定，不能被凍結成 taxonomy。現實案例還暴露出更深的差別：拒絕可以已經生效，卻產生相反的現實作用；也可以原本具有阻止能力，卻被持有者主動收回，因此「有效 / 無效」同樣不是足夠的二值描述。現有分析角度可以幫助追問拒絕如何失效，卻不是 Checklist；多個 Veto 或 Deny 如何組合、誰優先、衝突時如何處理，也都沒有建立。本章留下的是認識邊界，而不是偽裝完整的工具。下一問因此落到裁決位置：Intent、State、Evidence、規則側範圍以及負向約束，最終在哪裡彙集，並對這一次 Action 作出判斷？

上一章把「沒有發生」拆成了四種不同的語義結構。資格沒有建立、明確拒絕、能力級拒絕與最終否決，可以留下相似的外部結果，但內部發生的事情並不相同。完成這一區分以後，問題自然會繼續落到拒絕本身：如果 Final Veto 是一種需要依靠具體條件才能成立的結構關係，那麼這些條件也可能不再成立，拒絕能力本身也會失效。

第十四章已經給出了這條負向約束成立時需要滿足的若干條件：它仍然有效，仍在適用範圍內，能夠觸達受保護的現實執行路徑，並且不能被受約束方繞過或直接覆蓋。沿著這些條件逐項反問，是理解失效最直接的入口：約束是否已經失效，當前 Action 是否已經超出範圍，它是否還能觸達需要阻止的現實效果，以及受約束方是否已經能夠繞過或者改變它。

這些問題都可以繼續追問，但把它們問完，並不會自動得到一份完整的失效清單。一個自然的工程需求，是把已經識別出的失效形態整理成可以核對的結構，用於設計評審、事故分析或者系統檢查。走到這一章，讀者也有理由期待看到這樣的結果，因為前面的章節已經逐步建立了資格、邊界、權威、執行能力以及最終否決等對象。

問題在於，本章現在不能交出這樣一份清單。原因不是失效形態無法被研究，也不是一份完整清單原則上不可能存在，而是當前證據還不足以把這個維度凍結下來。已經觀察到的形態仍然隨著案例增加而擴展，不同形態之間的關係也沒有穩定到可以被整理成一個封閉 taxonomy 的程度。

因此，本章真正要回答的不是「拒絕失效一共有多少種」，而是為什麼在當前證據狀態下，我們還不能誠實地給出這個數字，以及現階段關於拒絕失效究竟能夠確定到什麼程度。

案例增加，失效形態也在增加

這裡所說的案例，不是為了這一章臨時挑選的一組事故，而是本書一直使用的 Execution Control 案例池。當前這組材料包括 Therac-25、Ariane 5 Flight 501、Three Mile Island Unit 2、Knight Capital、Columbia（STS-107）、2003 年北美大停電、Boeing 737 MAX（JT610 / ET302）、Deepwater Horizon / Macondo、切爾諾貝利 4 號機組、珍珠港以及挑戰者號（STS 51-L）。它們來自軟件、金融、航空航天、電力、核工業、海上鑽井和軍事決策等不同場景，在本書中並不是用來證明某個理論，而是用來檢查已經提出的結構在不同現實條件下會遇到什麼壓力。

對「拒絕能力會怎樣失效」這個問題，這批案例留下了兩個值得比較的觀測點。較早的一輪材料只有八起已經完成核驗的案例，當時能夠區分出的拒絕失效形態也是八種；案例池擴展到十一起以後，能夠區分出的失效形態增加到了十二種。也就是說，案例增加了三起，已經能夠識別出的失效結構卻增加了四種。

這裡真正重要的不是「十二」這個數字，而是這個集合仍然沒有表現出可以被凍結的狀態。如果新增案例只是不斷落入已有結構，那麼隨著材料增加，我們會越來越有理由相信現有區分已經接近穩定；但當前看到的不是這種情況。新增材料仍然帶來此前沒有被區分出來的失效方式，因此現在把已經觀察到的十二種形態寫成「拒絕失效一共有十二種」，會把一個仍在變化的觀測結果誤寫成一個已經完成的分類。

案例與失效形態之間也不是一一對應關係。一個案例可能同時暴露多個不同結構，同一種失效結構也可能在不同案例中反覆出現。現有材料中，Boeing 737 MAX、Deepwater Horizon、2003 年北美大停電和切爾諾貝利等案例，都需要同時藉助多個結構才能描述清楚。這意味著「十一案、十二種形態」並不是十一件事情分別被塞進十二個格子，而是同一事件中可能同時存在多個不同的失效面。

這兩個觀測點同樣不能被解釋成增長率。它們不能告訴我們第十五起案例會增加多少種形態，也不能證明案例繼續增加時新形態一定還會以相同速度出現，更不能推出一份完整的失效清單原則上永遠不存在。它們能夠支持的判斷只有一個：在當前證據下，這個維度還不能被凍結。

已有的一條結構性描述也說明了為什麼現在還不能收口。此前關於拒絕失效的描述主要集中在兩類問題上：負向約束是否仍然能夠觸達需要阻止的對象，以及當前 Action 是否仍然處在它的有效範圍內。把這條描述與目前識別出的十二種失效形態對照後，它能夠完整覆蓋其中兩種，對另外兩種只能形成部分覆蓋。

這說明原有描述確實抓住了拒絕失效的一部分結構，但距離覆蓋當前已經觀察到的全部情形還有明顯距離。更重要的是，這個差距為什麼會出現，目前本身也沒有得到完整解釋，因此不能通過補寫幾個條件，就把剩餘形態重新塞回原來的框架裡。

所以，本章所說的「不可凍結」，不是說拒絕失效無法研究，也不是說未來不可能形成更穩定的分類，而是說現在手裡的案例還在改變我們對這個對象的認識。在這種狀態下，可以誠實交出的，是已經觀察到的結構、它們之間仍然存在的差異以及當前證據的邊界，而不是一份看起來已經完成的失效清單。

這批案例不證明什麼

上一節使用這組案例，不是為了證明「拒絕失效一定存在十二種」，更不是為了證明執行控制理論本身正確。它們在這裡承擔的作用，是對「當前已經可以給出一份完整失效清單」這個判斷施加壓力。

這種壓力有一個很清楚的邊界。如果後續增加案例以後，新的材料不斷落入已經識別出的結構，失效形態不再繼續增加，那麼「不可凍結」這個判斷就應當重新檢查。現在看到的只是相反的情況：案例池從八起擴展到十一起時，能夠區分出的失效形態仍然從八種增加到了十二種。因此，本章能夠說的是當前證據還不足以凍結這個維度，而不能進一步說一份完整的失效清單原則上永遠不可能形成。

這一點很重要，因為「現在沒有完成」和「這個對象不可能完成」是兩個完全不同的判斷。關於拒絕失效的研究還沒有走到能夠關閉這個問題的位置，未來如果有新的案例、更穩定的結構關係或者新的證據，當前狀態完全可能改變。本章保留的是這個開放性，而不是把「不可凍結」寫成對象本身永久的性質。

案例本身也不能脫離各自的事實邊界被壓成一組整齊的樣本。Therac-25 是其中一個典型例子：現有材料中沒有 Tier 1 的政府事故報告可以直接承擔完整事實基礎，而且通常所說的 Therac-25「案例」實際包含多起事故，不能把它們合併成一個單一競態，也不能把整個事件簡單改寫成「刪除了全部硬件聯鎖」。這些限定決定了它能夠在本章承擔多大的論證重量。

Boeing 737 MAX 同樣帶有不能消除的證據限定。JT610 與 ET302 是兩起獨立事故，不能合併為一條事實鏈；不同國家調查機構之間已經存在的正式分歧也必須繼續保留。因此，這組材料可以幫助觀察某些執行結構，卻不能被當成一個無爭議、單一因果鏈的樣本。

珍珠港案例的邊界又不一樣。在這裡使用的只是它所暴露出的結構位置，而不是對對手行為進行分析。1942 年與 1946 年的兩份官方調查在責任性質上存在直接衝突，這兩種判斷必須並列保留，也不能用後來獲得的信息替當時的決策者補齊他們並不掌握的事實。

這些限定不會讓案例失去價值，反而決定了案例應該怎樣被使用。它們能夠告訴我們，一個既有結構在新的現實條件下還會遇到什麼問題，也能夠迫使已經形成的判斷重新接受檢查；但它們不能替理論完成證明，更不能因為數量增加，就自動變成一份已經完成的分類體系。

拒絕是否有效，不是一個是非題

當前識別出的失效形態中，有兩個案例把問題推到了兩個明顯不同的方向。第一個是切爾諾貝利 4 號機組：這裡暴露出的結構不是「拒絕沒有發生」，而是拒絕動作已經被執行併產生了作用，但它的物理實現使作用方向發生了反轉。也就是說，僅僅確認一次拒絕已經生效，還不足以說明它最終產生了原本希望獲得的現實效果。

這起案例在這裡能夠承擔的只有這一層結構含義，事實邊界仍然必須保留。按照 INSAG-7 的口徑，最終觸發事件本身保持不確定，事故也不能被壓縮成「操作員違規」或者「設計缺陷」中的任一種單一原因。當時曾被歸為違規的做法中，還有三項後來被 INSAG-7 認定為並非違規，這些認定需要同時保留。把這些限定刪掉，案例會變得更容易講，卻也會被改寫成一個原始材料並不支持的簡單因果故事。

另一個方向由挑戰者號（STS 51-L）暴露出來。在這一側，否決具有可達性、及時性和適用範圍，在實踐意義上本來能夠阻止相應動作，但最終沒有繼續發揮這種作用，因為持有這項否決的人在壓力下收回了它。這裡失效的不是一個外部主體強行繞過或者覆蓋拒絕，而是原本存在的否決沒有被繼續堅持。

挑戰者號同樣帶著必須保留的事實限定。環境氣溫 36°F 與右後現場接縫測得的 28 ± 5°F 是兩個不同的數據，不能混用；「偏差的正常化」來自 Vaughan 1996 年的研究，而不是事故調查委員會的正式結論；流傳很廣的「某位工程師拒絕簽字」也沒有得到 Tier 1 證據支持，相關簽字人為 Kilminster。這些差別直接決定了這個案例可以被用來說明什麼，因此不能為了讓敘事更簡潔而把它們合併。

把這兩個極端放在一起，就能看到「拒絕是否有效」為什麼不能被簡單壓成一個是非判斷。切爾諾貝利這一側說明，拒絕可以已經生效，但最終現實作用卻朝相反方向發展；挑戰者號這一側則說明，一個原本具有實際阻止能力的拒絕，也可能因為持有者主動收回而沒有繼續產生阻止效果。兩者都不能僅靠「有效 / 無效」兩個值完整表達。

這一區分同時把「拒絕是否成立」和「拒絕最終產生了什麼作用」分開了。前面的章節已經建立了關於負向約束存在性、範圍、可達性、持有關係以及不可繞過性等判斷，但這兩個極端所暴露出的這一面並不能僅由這些條件直接回答：一個問題發生在拒絕被實現以後，另一個問題發生在拒絕由持有者繼續維持的過程中。

這也不能反過來被理解成拒絕有效性存在一條連續的刻度。兩個極端之間是否存在可以統一定義的中間狀態，這些狀態能不能排序，是否存在共同的度量，目前都沒有建立。本章能夠確定的只是：「拒絕是否有效」不能被壓縮成一個簡單二值屬性；除此之外，不再補出新的值域或尺度。

還不能形成一套分類

前面已經識別出十二種拒絕失效形態，但「已經看到十二種」與「已經形成一套分類」是兩回事。要把這些形態整理成一個可以獨立使用的 taxonomy，至少還需要回答幾個當前沒有答案的問題：這個集合是否已經封閉，各種形態是否處在同一層級並彼此互斥，以及一個現實案例是否能夠被唯一地歸入其中某一類。

當前材料還不支持封閉性。案例池從八起擴展到十一起時，能夠區分出的失效形態仍然從八種增加到了十二種，因此現在只能說「已經觀察到這些形態」，不能把它改寫成「拒絕失效一共有這些形態」。兩句話看起來接近，實際承擔的承諾完全不同：前者是一組當前觀測，後者已經是一套完成的分類。

形態之間的同層性與互斥性也沒有建立。前一節使用的兩個極端，只是為了說明「有效 / 無效」不足以容納現有觀察；另外還有一些形態只能被既有描述部分覆蓋。這些差異並不能自動說明十二種形態彼此平行，更不能說明它們之間不存在交疊。把它們排列成十二個並列類別，會在證據尚未建立的地方補上一層對稱關係。

現實案例本身又帶來了另一個問題。有些案例需要同時藉助多個結構才能描述清楚，因此案例和失效形態之間不是一對一關係。當前材料既沒有證明這些結構彼此互斥，也沒有建立一個最小充分集，所以不能要求每起案例最終只能落入一個類別。由此進一步計算「哪一種失效最常見」或者「多少案例已經被某一類覆蓋」，同樣缺少穩定的分類基礎。

正因為這些關係尚未建立，把當前形態直接整理成分類表會帶來額外含義：行與行之間看起來是平行類別，表格邊界看起來像集合邊界，每個案例也容易被理解為應該找到唯一歸屬。這些含義目前都沒有得到證據支持。分類樹、譜系圖也會遇到同樣的問題，因為它們同樣需要先假定類別之間已經存在穩定的結構關係。

只畫前面提到的兩個極端也不能解決這個問題。兩個極端能夠說明二值判斷不夠，但它們並沒有建立一條連續軸，更沒有說明中間狀態能夠排序或者存在共同度量。因此，從兩個極端直接畫出一條軸線，會把尚未建立的序關係補進來。

所以，本章所謂「只能以結構化方式呈現」，不是換一種形式去隱藏那十二種形態，而是保留每項觀察目前真實擁有的證據地位：哪些只是已經識別出的失效方式，哪些關係仍未建立，哪些案例同時暴露多個結構，哪些地方還存在明確空缺。只有這些邊界繼續留在論證中，當前材料才不會被誤讀成一套已經完成的拒絕失效分類。

分析角度不能當成檢查表

除了已經觀察到的失效形態，現有研究中還保留著另一組東西：一些用於追問拒絕為什麼會失效的分析角度。它們關注的方向包括拒絕是否存在、作用於什麼對象和層級、適用範圍在哪裡、觸發以後是否真正實現、實際作用方向是否符合預期、誰持有並能否撤銷，以及拒絕能力是否能夠被準確作用到目標上。

這些角度的價值，是幫助我們從不同方向繼續追問同一個問題。它們並不是七種失效機制，也不是七類彼此平行的失敗模式。這些角度只用於幫助拆開問題，本章不為它們建立正式編號，也不把它們升格為七種失效機制或一套新的taxonomy。

更重要的是，這些角度之間的關係目前沒有建立。我們還不知道哪些是必要條件，哪些組合起來才足夠，也不知道其中某一個角度能不能被另一個角度替代。因此，即使沿著這些方向全部檢查一遍，也不能據此聲稱「拒絕失效已經被完整覆蓋」。

這正是它們不能直接變成檢查表的原因。檢查表隱含的是一種覆蓋承諾：項目全部檢查完，就意味著相應問題已經被系統性排除。但現有材料只支持把這些角度作為提問工具使用，並不支持把它們解釋成一套具有必要性、充分性和完整覆蓋能力的結構。

類似的處理方式在本書對其他分析維度的討論中也出現過：分析維度可以幫助拆開問題，卻不因此自動成為對象的子類型，更不能因為多個維度同時存在，就把它們合併成一套統一體系。這裡同樣如此。

所以，這組分析角度可以幫助我們把「拒絕為什麼會失效」問得更細，卻不能替代本章沒有給出的那份完整失效清單。它們提供的是觀察問題的方向，而不是已經完成的分類。

已經識別，也還不能寫成統一定義

拒絕失效之所以還不能被凍結，不只是因為案例增加以後仍然出現新的失效形態。即使只看目前已經識別出來的部分，還有幾處關鍵關係沒有穩定下來：一些表達還不能形成統一值域，一些執行閉合位置只能在具體場景中成立，而當承擔拒絕的組件本身失陷時，它還能保留什麼保證，也沒有統一答案。這裡的問題已經不是「還沒有看到」，而是「已經看到了一部分，但還不足以把它寫成通用定義」。

拒絕這一側已經出現了多種處置與狀態表達，例如 Reject、Allow、Release Block、No Allow、Stop 和 Safe Mode。它們表面上很像一組可以直接枚舉的結果值，但目前沒有建立統一的處置關係，也沒有證明這些表達能夠被放進同一個 value taxonomy。尤其是 Release Block，它可以在特定場景中作為明確輸出存在，卻不能因此被提升為所有執行控制場景都共享的 Runtime 輸出。一個局部設計已經能夠工作，不等於它自動獲得了跨場景的語義覆蓋範圍。

執行閉合的位置也存在類似問題。提交、密鑰、簽名、廣播、執行器等位置，都可能在具體系統中成為某種能力真正獲得現實效力之前的關鍵關口，但這些位置並不因此組成一套通用生命週期。不同系統的最終閉合可能發生在不同位置，當前材料只支持把它們作為場景化的 closure points 使用，不能進一步聲稱任何 Action 都必須按照同一條固定路徑依次經過這些關口。

現有材料裡還有一個範圍很窄但很容易被擴大使用的例子：某一具體場景中的最後一致性驗證。它能夠說明在那個位置仍然存在一次阻止現實執行的機會，卻不能因此覆蓋 Final Veto 的全部結構。局部成立的最後檢查點，與所有系統都共享的最終否決位置，是兩個不同層次的主張。

為了描述這一類問題，本章會使用「最後有效否決點」這個說法，指某一次執行路徑上再往後就已經無法有效阻止受保護現實效果的位置。這個名字目前只是描述性稱呼，不是正式術語，也沒有獲得統一定義。因此，它可以幫助提出問題，卻不能被當成已經建立的概念繼續推導新的結構。

另一處未決出現在承擔拒絕的組件本身已經失陷時。此時它還能提供什麼 residual guarantee，目前沒有統一的全稱定義。這個問題會涉及權威如何被分解、失陷條件下還剩下哪些完整性保證、失陷能夠影響多大的範圍，以及系統應當沿什麼失敗方向退化。現有材料還不足以把這些關係凍結下來，因此本章只登記這個缺口，不據此建立威脅模型，也不把它整理成失敗矩陣。

這裡仍然要保持 Fail-Secure 的原有邊界。資格無法充分建立時，受保護的現實執行不能因為這種不足而繼續推進，但這並不意味著任何失敗都必須讓整個系統停機。如果某個較小的能力集合擁有獨立而充分的執行依據，它仍然可以被保留。至於這種保留具體應該對應哪一種運行模式、系統應當進入怎樣的 Safe Mode，目前並沒有統一語義，不能從「不要求全系統停機」這一點繼續推出。

因此，這一組問題與前面的形態計數共同指向同一個狀態：當前還沒有足夠依據把拒絕失效寫成一套統一定義。形態數量仍未穩定，而已經識別出的結構在值域、閉合位置和失陷條件下的保證上也各自保留著未決邊界。

兩個拒絕加在一起，等於什麼

單個 Final Veto 的結構已經可以被討論，但當同一次 Action 同時受到兩條、三條甚至更多負向約束時，問題會立刻發生變化。它們之間有沒有優先級，是否需要滿足某種數量條件，一條已經過期而另一條仍然有效時應該怎樣處理，兩個拒絕發生衝突時又應該怎樣得到最終結果，這些問題目前都沒有建立統一答案。

一個很自然的設計想法，是在已有拒絕之外繼續增加新的負向約束，並假定它們疊加以後只會讓執行條件更加嚴格。這個想法本身並不能直接變成組合規則。現有材料沒有證明多個拒絕之間天然滿足某一種固定的 AND、OR、quorum、優先級或者衝突消解關係，因此「拒絕越多一定越安全」現在仍然只是一個未經建立的推斷。

這並不意味著多條負向約束之間什麼都沒有建立。多個必要的負向約束可以共同限制同一次 Action；只要其中仍然有效的必要負向條件沒有得到滿足，受保護的現實執行就不應繼續；多個正向 Allow 也不會自動消除一條獨立存在的阻止關係。這些判斷已經能夠約束一些推理方向，但它們仍然只是單向關係，其中沒有給出多個 Veto 應該怎樣聚合的組合算子。

因此，真正未決的是 composition 本身。一個必要條件是否就等於一次獨立 Veto，多條 Veto 之間是否存在優先關係，是否需要 quorum，多個結果應該怎樣聚合，發生衝突時如何裁決，以及過期、撤銷和仍然有效的拒絕同時存在時應該怎樣計算，目前都沒有形成統一規則。這裡可以明確問題，卻不能把這些問題反過來寫成一套已經存在的組合框架。

還需要區分兩個看起來很接近的對象：**multiple Veto 與 multiple Policy Deny 不是同一件事。**即使策略側存在某些關於多個 Deny 的結構，也不能直接拿來替 Final Veto 建立組合規則；反過來，Final Veto 一側已經建立的負向約束關係，也不能替 Policy 一側補出多個拒絕如何聚合的答案。兩邊可以暴露相似的問題，但不能因為語言相近就共享一套尚未建立的組合代數。

所以，這裡留下的不是兩個相互衝突的答案，而是同一個尚未解決的結構缺口。第十四章已經從 Final Veto 本身的結構完整性一側碰到過這個問題：單個負向約束可以成立，但多條負向約束共同出現時如何組合，沒有被建立。本章再次遇到它，是因為即使未來拒絕失效的各種形態能夠被進一步穩定下來，多條拒絕如何共同作用仍然不會因此自動得到答案。

這兩個位置承擔的作用不同，但指向的是同一個未決問題。它不應該因為在兩個章節中出現就被計算成兩份獨立證據，也不能為了讓整個理論結構看起來完整而人為補出一個組合規則。當前能夠確定的，是這個缺口確實存在；至於它最終需要什麼樣的組合語義，本章沒有答案。

結構化，但不是清單

把這一章收一收，它做的其實是同時堵住三條出口。「給我一份失效清單」——給不了。形態數還在增加，現有的那條結構描述只能完整覆蓋其中兩種，對另外兩種也只是部分覆蓋。現在把它們做成一份完整清單，等於宣佈一件還沒有發生的事。

「拒絕要麼有效要麼無效」——不成立。一端是生效但方向反了，另一端是本可有效卻被持有者自己收回，這兩種都裝不進簡單的二值判斷；而承認這一點，也不等於就得到了一把連續的尺子。

「多個拒絕疊加就更安全」——不知道。多個必要約束可以共同限制一次動作，這是已經成立的；但它們如何組合、誰優先、發生衝突時如何處理，都沒有建立。目前沒有依據把這種疊加寫成一條已經成立的組合規則。

在全書最接近工程手冊的位置上，這一章偏偏沒有交出一份可以直接照著使用的手冊。這不是因為問題沒有整理完，而是因為把一個仍在變化的觀測集合寫成固定清單，比承認它還沒有穩定下來更容易，也更危險。一旦寫下來，它就很容易被當成完整的東西使用，而當前證據還不支持這種完整性。

這裡也要說一句關於空位的話。一本書留下一個空位，很容易被理解成作者還沒有寫完，但這一章留下的兩個空位不是這種情況。失效形態還不能凍結，是對現有案例進行比較以後得到的結果；多個拒絕如何共同作用沒有建立，也是現有材料對照以後留下的共同缺口。要改變這兩個狀態，需要新的材料或者新的結構性結論，不是多寫幾段文字。把這些空位保留下來，讀者至少知道當前還缺什麼；如果現在把它們填滿，反而會讓人誤以為答案已經存在。

所以這一章交給讀者的不是一份完整工具，而是幾條認識邊界：哪些判斷現在已經可以成立，哪些關係仍然沒有建立，哪些話繼續往前說就會超出當前證據。認識邊界比工具難用，但它至少不會把尚未建立的東西偽裝成已經完成的規則。帶著這些邊界繼續往下走，比帶著一份看起來很齊全、實際上尚未閉合的清單更可靠。

於是問題走到了下一步。前面十幾章一件一件建立起來的東西——邊界、意圖、狀態、證據、證據是否足夠、策略收斂之後的那個有限範圍——加上這一章反覆談論的這條只朝一個方向起作用的負向約束，它們最終要在某個地方碰面，並且對這一次具體動作給出一個確定的結果。

這些輸入與這條負向約束，究竟在哪裡被彙集並作出裁決？

本章術語

• 拒絕失效 ｜ Refusal Failure
• 拒絕失效形態 ｜ Refusal Failure Form
• 最終否決 ｜ Final Veto
• 多重否決 ｜ Multiple Veto
• 多重策略拒絕 ｜ Multiple Policy Deny
• 多重否決組合 ｜ Multiple-Veto Composition
• 閉合點 ｜ Closure Point
• 剩餘保證 ｜ Residual Guarantee
• 安全失敗 ｜ Fail-Secure

「最後有效否決點」（Last Effective Veto Point）在本章中僅作為描述性稱呼使用，目前不是正式術語，也沒有統一定義。

本章案例與資料來源

本章使用 Execution Control 主題下已經完成核驗的 11 個案例作為案例池，用於觀察拒絕失效形態在不同現實系統中的表現，以及案例增加後失效形態是否趨於穩定。案例在本章中承擔的是壓力測試作用，不構成對理論結論的證明。

案例池包括：Therac-25；Ariane 5 Flight 501；Three Mile Island Unit 2；Knight Capital；Columbia（STS-107）；2003 年北美大停電；Boeing 737 MAX（JT610 / ET302）；Deepwater Horizon / Macondo；切爾諾貝利 4 號機組；珍珠港；挑戰者號（STS 51-L）。

其中，本章重點使用切爾諾貝利 4 號機組與挑戰者號（STS 51-L）說明「拒絕是否有效」不能被壓縮為簡單二值判斷：前者對應拒絕已經生效、但現實作用方向發生反轉的情形；後者對應拒絕原本具有現實阻止能力、但最終由持有者主動收回的情形。

Therac-25、Boeing 737 MAX、珍珠港、切爾諾貝利與挑戰者號均帶有不能消除的事實或證據限定，本章正文已分別保留這些限定。案例所承擔的作用仍然是對既有結構施加壓力，而不是把現實事故直接作為理論證明，也不能因為案例數量增加，就把目前識別出的失效形態解釋成已經完成的分類體系。

資料來源

本章案例事實主要依據各事件對應的官方事故調查報告、政府或監管機構報告，以及少量在正文中明確標註的研究資料。對於存在來源分歧、事實不確定性或證據限定的案例，本章保留原始材料中的不同判斷，不將其壓縮為單一因果結論。

其中，切爾諾貝利相關判斷保留 INSAG-7 對最終觸發事件和事故成因的事實邊界；挑戰者號案例區分官方事故調查結論與 Vaughan 關於「偏差的正常化」的後續研究；Boeing 737 MAX 保留不同國家調查機構之間已經存在的正式分歧；珍珠港保留 1942 年與 1946 年兩份官方調查在責任性質上的不同判斷；Therac-25 則保留其現有事實來源層級和多起事故不能被合併為單一事件結構的限制。

涉及上述 11 個案例的完整官方報告、事故調查資料、監管文件、研究文獻以及本書其他外部來源，統一列入全書 《參考文獻與資料來源》。

---

第十七章｜只判斷，不動手

本章把前面分散建立的 Intent、State、Authority、Policy、Boundary、Evidence 等對象帶回同一次 Action，回答這些條件最終在哪裡形成確定裁決。Runtime 在這裡不是某個服務、進程或硬件，而是接收明確輸入、對具體 Action 作出確定判斷的邏輯裁決環境或抽象角色。Action 是被判斷對象，其餘信息是判斷依據；Runtime 可以讀取和判斷這些輸入，卻不能重新定義它們，也原則上不應產生業務副作用。它承擔的是裁決職責，不因此成為新的 Authority，更不能把 Policy 輸出直接當成最終裁決。Runtime 必須形成明確、可終止、可驗證、可解釋的約束性判斷，但統一的 Outcome Semantics 仍未建立。它只判斷，不動手；Executor 才負責真正改變現實。裁決位置確定以後，下一問隨之出現：誰能夠改變這些裁決所依賴的結構本身？

上一章結束的時候，手裡剩下的東西比前面任何一章都多，而且它們之間還有一些關係沒有閉合。

上一章處理的是拒絕能力本身如何失效。案例增加以後，能夠識別出的失效形態仍然在增加，因此最後交出來的不是一份完整清單，而是一個明確的判斷：在當前證據下，這個維度還不能被凍結。這樣的結果不能靠「照著清單逐項核對」來使用，它最終仍然要回到一次具體 Action 的判斷中。這個判斷在哪裡形成，上一章沒有回答。

前面的章節已經逐步建立了一批判定對象。邊界在什麼條件下才真正成立，Intent 是否對應這一次 Action，State 是否仍然是當前狀態，Evidence 是否成立、是否充分，規則側那些各自有限、彼此可能並不一致的輸入怎樣收斂成當前範圍，資格全部建立以後是否仍然存在能夠阻止現實執行的負向約束，以及同樣一個「沒有發生」的結果背後可能對應哪些不同結構。這些問題分別回答了某一類對象是否成立，卻還沒有回答：它們最後怎樣進入對同一次 Action 的判斷。

一種很自然的理解是，它們其實不需要彙集。邊界由邊界那一側判斷，證據由證據那一側判斷，策略由策略那一側判斷，只要每一部分都各自正確，最終結果就應該自然正確。但這本書第一章已經從另一個方向指出了問題：每一環都可以在自身範圍內成立，聚合以後仍然可能產生相反的現實結果。因此，「各管各的」並不足以回答最終 Action 是否應當獲得現實效力，而這些條件究竟在哪裡同時進入一次判斷，也就成為一個繞不開的問題。

這裡要小心一個滑坡。「各管各的不足以推出正確結果」，不能推出「因此一定存在某個新的控制結構」。它只推出一件事：如果系統事實上對每一次 Action 作出了確定判斷，那麼這個判斷一定是在某個邏輯位置上形成的，而這個位置值得被單獨看一眼。

這個區別在這一章尤其重要，因為這裡是前面多條判斷鏈第一次真正匯到同一個問題上。前面建立的那些對象如果只是並排放著，讀者得到的仍然是一份清單；而清單和輸入不是一回事。清單意味著逐項核對完成以後任務就結束了，輸入則意味著這些對象只有在同一次判斷中共同承擔依據時，才真正參與了這一次裁決。少掉一項，也不是少打一個勾，而是這次判斷所依賴的依據發生了變化。

這一章要問的正是：這些輸入在哪裡被彙集，並形成對這一次 Action 的確定裁決？

它是一個位置，不是一個東西

本書所說的 Runtime，是接收明確輸入並對具體 Action 作出確定裁決的邏輯裁決環境或抽象裁決角色。

這裡的「邏輯」和「抽象」不是修飾語，而是在限定這個概念的層次。讀到「有一個地方作出裁決」，很容易立刻想到一個具體組件：一個服務、一個進程、一個有端口和部署位置的方塊。接下來問題也會隨之變成它部署在哪裡、是否構成單點、性能是否足夠。這些都可能是具體系統需要處理的工程問題，但它們不能反過來成為 Runtime 的定義。

因此，這裡的 Runtime 不是 HAVENLON 服務，不是硬件，不是 daemon，不是編程語言裡的 runtime，也不是任意業務邏輯的執行容器。某個具體系統當然可以讓一個服務、進程或者設備承擔這個角色，但那只是這個系統選擇的實現方式。實現可以變化，Runtime 在這裡承擔的職責不能因此改變。

它也不能與前面已經建立的其他對象混在一起。Runtime 不是 Action 本身，因為判斷與被判斷的對象不能是同一個東西；它也不是 Final Execution Authority，後者回答的是誰擁有最終裁決權、什麼判斷具有最終效力，而 Runtime 回答的是這次裁決在什麼邏輯環境中形成。

Runtime 同樣不等於 Execution Control 本身。它承擔的是執行控制中的判斷職責，而不是整個執行控制體系。它也不是 Execution Boundary，因為判斷已經正確形成，並不等於這個判斷已經在現實執行路徑上獲得了約束能力。至於編程語言裡的 runtime，則只是名稱相同，兩者之間沒有理論上的等同關係。

同樣不能把這個角色重新解釋成 IAM 的擴展、Zero Trust 的延伸或者另一層審批。把它看成中間件或網關，也會產生類似的問題：中間件和網關首先是具體部署對象，通常按照請求怎樣經過它們來描述；這裡討論的 Runtime 則按照它承擔什麼判斷來定義。兩者可以在某個實際系統中落到同一個組件上，但這種實現上的重合不能被提升成概念上的等同。

Runtime 承擔的作用，是把多類輸入帶入對同一次 Action 的判斷，並形成確定裁決。這裡需要區分「彙集」和「收斂」：前者說明相關輸入在同一次判斷中同時在場，後者說明這些輸入最終形成了一個針對當前 Action 的判斷。Runtime 是承擔這兩件事的邏輯位置，而不是一個只負責收集信息的容器。

至於這些輸入具體依照什麼規則完成收斂，需要繼續保持已有的理論邊界。規則側如何從多個有限輸入形成當前適用範圍，前面的 Policy Convergence 已經處理了一部分；而裁決形成以後究竟使用怎樣統一的結果語義來表達，到這一章仍然沒有建立。沒有建立的是這些進一步的語義關係，不是 Runtime 作出確定裁決這一職責本身。

堅持把 Runtime 定義成邏輯裁決環境或抽象裁決角色，會犧牲一些實現上的具體感，但也避免了一個更大的問題：某一種產品實現一旦發生變化，理論概念就跟著改變。具體組件可以換，部署方式可以換，承擔這個角色的實體也可以換；Runtime 是否成立，判斷的仍然是它有沒有承擔這裡定義的裁決職責。

它不是一種新的權力

把裁決單獨拿出來討論，很容易讓人產生一個直覺：既然這裡負責作出最終判斷，是不是等於系統裡又增加了一個新的權力主體？這個理解並不成立。此前關於 Arbitration 的處理已經給出了相反的方向：它沒有被建立成一種獨立 Authority，而是被吸收進已有的權威結構、權威分解以及執行權分離之中；至於仲裁過程中涉及的評估與收斂，則屬於 Policy Convergence 已經處理的範圍，本章不重新展開。

這裡所謂「吸收」，不是說仲裁這個問題消失了，而是說它不再作為第四種獨立權力被疊加到已有結構之上。Runtime 建立的是一個承擔判斷的邏輯位置，不是一種新的權力。位置本身不因為承擔裁決就獲得額外 Authority；誰的判斷具有最終效力、權力如何被分解，仍然由前面已經建立的權威關係決定。

因此，有幾種很容易出現的理解需要繼續排除。仲裁不是重複審批。審批解決的是上游授權問題，而這一章面對的恰恰是「上游條件分別成立以後，如何針對當前 Action 形成一次確定判斷」。如果這裡只是把同一種審批再做一次，它並沒有增加新的判斷能力。仲裁也不等於簡單多數表決，因為多數回答的是有多少主體選擇了某個結果，而不是這個結果是否滿足當前 Action 所要求的全部條件。

同樣，仲裁不能退化成「權限最高的人說了算」。更高的權限意味著擁有更大的行動範圍，並不意味著它天然擁有更正確的判斷，更不能因此越過已經成立的 Boundary。把裁決變成權限排序，只是把「應該怎樣判斷」換成了「誰排在前面」。另一種相反方向的簡化，是直接執行 Policy 返回的結果。Policy 提供的是判斷依據，它的輸出可以進入裁決，卻不能因為來自規則系統就自動等同於最終裁決本身。前一種做法把判斷交給最高權限者，後一種做法把判斷交給規則輸出，兩者都跳過了這一章真正關心的那次裁決。

但這並不意味著 Arbitration 與 Runtime 之間已經存在一個確定的對應關係。它們究竟是不是同一個對象，目前的證據不足以判定，因此這裡必須保持**「不合並，不分立」**：既不能直接把 Arbitration 改名為 Runtime，也不能反過來斷言它們一定是兩個彼此獨立的對象。

這種懸置不是因為概念沒有整理清楚，而是因為兩種方向都需要額外依據。把它們合併，需要證明兩者承擔的是同一個理論對象；把它們分立，同樣需要證明兩者之間存在穩定而必要的區別。目前這些條件都沒有建立。Arbitration 與 Runtime 雖然在職責上存在交疊，但這種交疊本身不足以證明它們屬於同一個理論對象。功能上的相似可以提出比較，卻不能直接建立同一關係。

這會留下一個不夠整齊的位置，但比強行補出一個關係更準確。Runtime 可以在本章被定義為邏輯裁決環境或抽象裁決角色，同時 Arbitration 與 Runtime 的對象關係繼續保持開放；兩件事並不衝突。

還有一個相鄰問題也需要保持未決。當多個條件必須共同成立時，這種合取關係究竟屬於 Arbitration 層，還是屬於 Final Execution Authority 的實現層，目前沒有建立統一歸屬。本章會接觸到它，因為 Runtime 要處理進入當前 Action 判斷的多類輸入，但接觸到這個問題並不等於有權替它決定歸屬。這裡繼續保留這個空位。

它不是既有概念的改名

Runtime 並不是把前面某個已經存在的概念換了一個名字。此前已經分別討論過策略判斷、狀態綁定、仲裁、最終重新驗證、執行前控制和執行拒絕等結構，它們從不同方向回答了判斷依據什麼、由誰參與、什麼時候需要重新檢查，以及判斷不成立時執行會受到什麼影響，但其中沒有任何一個對象可以直接等同於這一章所說的 Runtime。

這些已有結構描述的是裁決的不同側面，而 Runtime 關注的是承載這次裁決的邏輯位置。它把此前分散討論的多類輸入帶入對同一次 Action 的判斷，並形成確定裁決。這個角色因此不是從某個舊概念直接演化出來的，也不能被理解成 Arbitration、Policy Engine 或其他已有對象的重新命名。

這種區別很重要，因為概念的來源不同，會直接影響我們能對它作出什麼推斷。一個從既有對象繼承而來的概念，可以繼續沿用那個對象已經建立的性質；Runtime 不是這種情況。它必須按照自己的職責和邊界被判斷：是否接收明確輸入，是否形成對具體 Action 的確定裁決，以及是否保持「只判斷、不執行外部動作」的界線。

同樣不能反過來用某個具體實現定義 Runtime。一個產品中的某個服務、進程或者硬件模塊，完全可能承擔這裡描述的裁決職責，但這隻說明它在那個系統裡實現了 Runtime 角色，並不意味著這個組件本身就是 Runtime 的定義。組件能夠做什麼、不能做什麼，也不能自動變成這個理論角色應該具備或不應具備的能力邊界。

如果讓實現反過來決定概念，結果會很直接：當前產品沒有實現的能力，會被誤寫成理論上不需要；當前組件採用的部署方式，也會被誤寫成 Runtime 必須具有的結構。這樣一來，理論只能解釋已經存在的實現，卻失去了判斷不同實現是否仍然滿足同一角色定義的能力。

因此，本章所說的 Runtime 始終保持為一個不綁定具體產品組件的邏輯裁決環境或抽象裁決角色。具體系統可以選擇不同的方式實現它，但實現方式不能反過來縮小或改寫這個角色本身。

六項性質，兩種語氣

Runtime 需要保持六項基本性質：無副作用、可終止、可驗證、可解釋、輸入明確、輸出明確。但這六項不能被簡單寫成六條強度完全相同的要求。

從 Runtime 的定義來看，裁決過程必須能夠終止、能夠被驗證和解釋，輸入與輸出也必須明確；對於副作用，表述則更剋制——原則上不得產生業務副作用。這裡的「必須」和「原則上」不能互換。前者關係到這個裁決角色能否成立，後者則保留了理論性質與具體工程實現之間仍然存在的距離。

從設計方向來看，這六項又可以被理解為 Runtime 理論上應儘量保持的性質。這樣的表述不是在降低定義本身的要求，而是在提醒工程實現：理論性質進入具體系統以後，不能未經論證就被翻譯成一組絕對、統一的實現指標。定義層與設計層表達的是不同強度的問題，把兩者寫成同一種語氣，反而會失去原本的邊界。

可終止意味著一次裁決最終能夠結束，並交出可以被後續執行鏈使用的判斷；如果裁決本身不能終止，依賴它的執行鏈就無法得到完整結果。可驗證意味著裁決及其依據能夠接受獨立檢查，而不是隻能相信裁決已經正確發生。可解釋要求判斷依據能夠被識別和理解，而不僅僅留下一個結果。輸入明確意味著這次裁決依賴的條件必須被說明，不能依靠無法識別的隱含輸入；輸出明確則要求裁決最終表達的約束本身是清楚的。

無副作用處理的是另一層問題。Runtime 的核心職責是判斷，因此它原則上不應在完成判斷的同時順手改變外部業務狀態。這裡強調的是職責邊界，而不是具體部署方式。它並不能直接推出 Runtime 必須運行在獨立進程、獨立設備、獨立網絡區域或者任何特定技術架構中；這些都是工程選擇，不能僅憑「無副作用」這一理論性質直接得到。

同樣，這六項也不是一套已經定義好的驗收指標。本章沒有為「可解釋」「可驗證」或者「無副作用」建立統一的評分標準、閾值或者測試方法。它們描述的是 Runtime 作為裁決角色應當保持的性質，而不是一張項目驗收表。具體系統當然可以進一步把這些性質轉化成工程指標，但那需要額外定義，不能由本章直接推出。

Runtime 的成立還要求輸入與輸出明確，裁決過程可終止、可驗證、可解釋，並且能夠產生確定的約束性判斷。這裡的重點是「確定」和「約束性」：針對同一次 Action，Runtime 必須形成可以實際約束後續行為的判斷。

但「能夠形成確定判斷」並不意味著本書已經定義了統一的結果值域。判斷是否確定，與它最終使用什麼結果名稱、這些結果之間具有什麼關係，是兩個不同的問題。前者屬於 Runtime 能否成立，後者到這一章仍然保留未決。

界線

這一章最重要的一條邊界可以用一句話表達：

Runtime adjudicates. Runtime does not execute external actions.

Runtime 作出裁決，但不負責執行外部 Action。界線的一側是判斷，另一側是讓現實狀態發生變化的動作。兩者之間的區別不是動作先後，而是職責不同：一個回答「這一次 Action 應當得到什麼裁決」，另一個負責把某種結果真正帶入現實。

這條界線很容易被忽略，因為一旦判斷已經形成，直接把對應動作繼續執行下去看起來是最短的路徑。但只要 Runtime 自己開始改變外部業務狀態，它就不再只是裁決角色，而同時成為了自己判斷的執行者。判斷與執行因此被壓進同一個職責之中，原本能夠約束兩者關係的界線也隨之消失。

Runtime 的失效可以沿幾個方向出現。最直接的一種，是它開始產生外部業務副作用，也就是在作出判斷的同時直接改變現實狀態。另一種是裁決邏輯無法終止，使系統遲遲得不到一個可以繼續處理的判斷結果。還有一種是裁決依賴沒有被明確說明的輸入：結果仍然可能正常返回，但外部已經無法完整知道這次判斷究竟依據了什麼，也就難以獨立驗證和解釋它。

最後一種發生在 Runtime 與 Executor 的關係上：兩者被合併成一個無邊界角色。這裡需要特別注意，「無邊界」並不等於「部署在一起」。本章不據此要求 Runtime 與 Executor 必須位於不同進程、不同設備或者不同模塊；反過來，即使它們在物理上彼此分離，也不意味著判斷職責與執行職責之間已經自動形成了有效邊界。這裡討論的始終是職責關係，而不是部署拓撲。

因此，「只判斷，不動手」不是一條部署規則，也不是對系統拓撲的要求。它規定的是 Runtime 的職責邊界：裁決可以決定外部 Action 應當受到怎樣的約束，但 Runtime 本身不直接把這個裁決變成外部業務動作。

前面所說的可終止、可驗證、可解釋以及輸入輸出明確，約束的是 Runtime 如何完成判斷；這一節增加的是另一條限制——完成判斷以後，它不能順勢跨到執行一側。只有這條界線仍然成立，Runtime 才能繼續保持為一個裁決角色，而不是演變成一個同時判斷、同時執行的無邊界對象。

七類輸入

Runtime 面對的是一次具體的 Action。這一次 Action 是被裁決的對象，而 Intent、State、參數、Authority、Policy、Boundary 和 Evidence，則是形成這次裁決時需要進入判斷的輸入。

這個層次不能混在一起。Action 回答的是「這一次到底要判斷什麼」，其餘輸入回答的是「憑什麼作出這個判斷」。如果把它們並列成八個對象，就會把判斷對象與判斷依據混成同一層，Runtime 的角色也隨之變得模糊。

這裡列出的七類輸入同樣不是一份接口規範。它們描述的是一次裁決需要面對的主要信息類型，並不意味著所有系統只能存在這七類輸入，也不意味著每一類都必須由一個獨立接口提供。一個具體實現可以把多類信息放在同一個載體裡，也可以把同一類信息拆成多個來源；這些都屬於實現方式，不改變它們在裁決中的邏輯身份。

這七類輸入之間也沒有在本章中建立固定順序。不能因為書寫時 Intent 排在 State 前面，就推斷 Runtime 必須先判斷 Intent，再判斷 State；同樣，也沒有已經建立的優先級說明 Policy 應當先於 Boundary，或者 Evidence 應當最後參與。只要把這些對象排成流程，就會額外引入一條目前並不存在的求值路徑。

Evidence 在這裡還有一條特殊邊界：Runtime 可以讀取 Evidence，可以判斷當前 Evidence 是否成立、是否充分，但不能修改作為判斷依據的 Evidence。否則，判斷所依據的東西會被判斷者自己改變，「依據是什麼」和「結果是什麼」之間就失去了可以獨立檢查的距離。

這裡所說的 Evidence 也不是普通意義上的運行日誌。日誌主要記錄已經發生了什麼，而這裡的 Evidence 是形成當前裁決時使用的依據。兩者當然可能來自同一套系統，但在邏輯角色上不能因此被視為同一種東西。

至於 Intent、State、Authority、Policy、Boundary 和 Evidence 各自在什麼條件下成立，前面的章節已經分別處理過。本章不重新定義這些對象，只關心一件事：當它們共同進入對同一次 Action 的判斷時，Runtime 在哪裡承擔裁決。

這可以壓縮成一個很簡單的關係：**Action 是被判斷的對象，七類信息是判斷依據，Runtime 是形成這次裁決的邏輯角色。**三者不要混成同一層。

確定判斷，不等於確定結果值

Runtime 必須能夠針對一次具體 Action 形成確定的約束性判斷。但「判斷是確定的」，並不意味著本書已經建立了一套統一的裁決結果值域。

目前沒有一組可以跨場景統一使用的 ALLOW / DENY / HOLD，也沒有已經成立的通用處置枚舉。現有表達中同時存在二值和多值的處置語義，但這些語義之間究竟是什麼關係，並沒有建立統一答案。不同現實場景中至少已經出現過八組不同的處置表達，它們可以各自在自己的上下文中成立，卻不能因此被直接排列成同一套結果集合。

原因在於，列舉本身就會引入關係。一旦把幾個詞並排寫成「Runtime 的可能輸出」，讀者自然會把它們理解成同一層級、彼此可比較，甚至默認它們共同構成一個封閉值域。而這些關係目前都沒有建立。因此，本章可以確認統一結果語義尚未形成，卻不能為了讓 Runtime 看起來完整而替它補上一組輸出值。

這需要和前面「產生確定的約束性判斷」嚴格區分。所謂確定，是說針對當前輸入和當前 Action，Runtime 必須形成一個不自相矛盾、能夠對後續執行產生實際約束的判斷。它描述的是判斷本身的確定性，不是判斷最後必須使用哪個固定結果名稱來表達。

因此，一個判斷完全可以是確定的，而承載這個判斷的統一取值體系仍然沒有建立。前者回答「這次到底有沒有形成明確裁決」，後者回答「所有裁決最終應該用哪些值表達，以及這些值之間是什麼關係」。這是兩個不同層次的問題。

保持這一點未決，會讓整個結構看起來少了一塊最直觀的東西：一個裁決角色居然沒有一張統一的輸出值表。但現在補上它，代價更大。因為一旦建立統一結果值域，前面關於 Explicit Deny、Capability-Level Refusal、Final Veto、Fail-Secure 以及不同「沒有發生」結構的表達，都必須重新檢查它們與這套值域之間的關係。

在這些關係真正建立之前，本章不提前給出答案。未來如果統一的 Outcome Semantics 被建立，相關章節當然需要隨之重新核對；但這只是一個可能改變現有表達的條件，並不意味著這項工作已經有了答案，也不意味著它即將發生。

所以這裡需要保留的結論很簡單：Runtime 必須形成確定裁決，但 Runtime 的統一結果值域目前仍未建立。

歸屬已經指派，對象還沒有建立

Runtime 為什麼可以討論裁決邏輯和輸入輸出，並不是因為這一章臨時把這些問題劃到了自己名下。前面對 Evidence、Intent 和 State 的討論已經從不同方向指向了同一個位置：當這些對象真正進入一次具體 Action 的裁決時，裁決邏輯以及輸入輸出的處理屬於 Runtime 所承擔的職責。

但還有另一類問題不能因此一起被回答：這些輸入之間究竟存在怎樣的關係，Runtime 應當怎樣表達這些關係，以及裁決過程中涉及的狀態應該怎樣被表示。

這個問題的歸屬已經比較清楚。它屬於 Runtime 所面對的裁決語義，而不是某個外部執行動作，也不是單獨某一種輸入自己的內部問題。換句話說，我們已經知道應該在哪裡處理它，卻還不知道最終應該用什麼結構來表達它。

現有的二元關係表示已經不足以承載這裡需要表達的內容。未來的替代方式至少需要覆蓋比簡單二元關係更多的結構，但目前還沒有足夠依據定義它應該由什麼組成、這些組成部分之間是什麼關係，以及哪些性質屬於必要條件。

因此，這裡必須保持一個很明確的狀態：不設計、不命名、不凍結。

「不設計」意味著本章不提前給出一個關係與狀態模型；「不命名」意味著不因為需要討論這個空位，就先創造一個正式概念；「不凍結」則意味著當前觀察到的要求還不能被寫成一套穩定結構。三者表達的是同一個邊界：問題已經被識別，但對象本身還沒有建立。

這正是「歸屬已經指派」和「對象已經建立」之間的區別。知道一個問題屬於 Runtime，並不意味著 Runtime 已經擁有了解決這個問題的完整模型。前者回答的是「這個問題應該在哪裡被處理」，後者回答的是「處理它所依賴的理論對象是否已經成立」。這兩個判斷不能互相替代。

如果只強調歸屬，讀者很容易認為這裡應該已經存在一個完整的關係與狀態模型；如果只強調未決，又會讓人以為這個問題仍然懸在整套結構之外。實際狀態處在兩者之間：它有明確的位置，但這個位置上的對象仍然缺失。

這更像一個空位，而不是一片空白。空白意味著我們連缺什麼都不知道；空位則意味著問題已經能夠被準確指出，只是目前還沒有足夠依據把答案寫進去。

所以本章在這裡停住。Runtime 可以承擔裁決，可以接收輸入，可以形成確定的約束性判斷，也可以明確哪些問題屬於自己的職責範圍；但涉及這些輸入之間的關係與狀態語義時，本章只確認它屬於這裡，不替未來提前建立那個尚未成立的模型。

這一章之後

到這裡，前面逐步建立的那些判斷對象終於有了一個共同的落點。它們不再只是分別成立的一組條件，而是作為判斷依據進入對同一次 Action 的裁決。承擔這次裁決的是一個邏輯裁決環境或抽象裁決角色：Runtime。它接收明確輸入，形成確定的約束性判斷，並保持一條明確的職責邊界——它作出裁決，但不執行外部動作。

這並不意味著 Runtime 已經成為一個完全閉合的理論對象。統一的 Outcome Semantics 仍然沒有建立，輸入之間的關係與狀態模型也仍然只有明確歸屬而沒有正式對象。前者意味著我們還不能給出一套通用的結果值域，後者意味著我們知道這個問題屬於 Runtime，卻還不能設計、命名或者凍結那個模型。這些空位不會阻止 Runtime 承擔已經成立的裁決職責，但它們也不能因為這一章即將結束就被順手補齊。

因此，第十七章真正完成的事情並不是把前面的對象重新裝進一個新的「大盒子」，而是確定了它們在一次具體 Action 上如何獲得共同的判斷位置。Boundary、Intent、State、Authority、Policy 和 Evidence 等對象仍然保持各自的語義邊界，Runtime 不替代它們，也不重新定義它們；它承擔的是這些條件進入同一次裁決以後所需要的判斷職責。

但走到這裡，問題開始發生變化。前面的章節一直在問：對於一次即將獲得現實效力的 Action，什麼條件必須成立？邊界是否成立，意圖是否仍然對應當前動作，狀態是否仍然有效，證據是否充分，策略怎樣形成當前範圍，負向約束是否仍然能夠阻止執行，以及這些輸入最終怎樣進入一次確定裁決。

這些條件一旦建立起來，很容易讓人把它們當成整個系統中固定不動的背景。但它們並不是天然存在的。哪些邊界有效，哪些輸入可以進入判斷，哪些規則能夠約束 Action，什麼 Authority 擁有什麼能力，這些結構本身也是被規定出來的，而已經被規定的東西，同樣可能被改變。

第十七章到這裡為止處理的，仍然只是一次 Action 走向現實之前的判斷。它沒有回答那些判斷條件本身由誰建立，也沒有回答誰有能力重新改變它們。

那麼，誰能夠改變這整套結構本身？

本章術語

• 運行時 ｜ Runtime
• 裁決 ｜ Adjudication
• 動作 ｜ Action
• 意圖 ｜ Intent
• 狀態 ｜ State
• 權威 ｜ Authority
• 策略 ｜ Policy
• 執行邊界 ｜ Execution Boundary
• 證據 ｜ Evidence
• 執行器 ｜ Executor
• 執行控制 ｜ Execution Control
• 最終執行裁決權 ｜ Final Execution Authority
• 仲裁 ｜ Arbitration

本章所說的 Runtime，是接收明確輸入並對具體 Action 作出確定裁決的邏輯裁決環境或抽象裁決角色。它不等同於 HAVENLON 服務、硬件、daemon、編程語言中的 runtime，也不是任意業務邏輯的執行容器。

**Arbitration 與 Runtime 是否屬於同一理論對象，目前仍未建立。**本章保持「不合並，不分立」，不將二者強行統一，也不提前劃分為兩個獨立對象。

統一的 Outcome Semantics 目前尚未建立，因此本章不把 ALLOW、DENY、HOLD 或其他處置表達凍結為 Runtime 的正式結果值域。

輸入之間的關係與狀態表示同樣尚未形成正式模型。本章只確認這一問題屬於 Runtime 所面對的裁決語義，不為其建立、命名或凍結新的關係與狀態模型。

本章案例與資料來源

本章無現實案例。

這一章討論的是 Runtime 作為邏輯裁決環境或抽象裁決角色的職責、邊界和成立條件，不通過具體公司、產品、事故或人物來證明這一概念。將某個現實系統中的服務、進程、設備或者控制組件直接作為 Runtime 的案例，反而容易把抽象裁決角色誤讀成某一種具體實現。

資料來源

本章沒有需要單獨展開的現實事件資料。正文涉及的 Runtime、Action、Intent、State、Authority、Policy、Execution Boundary、Evidence、Executor、Execution Control、Final Execution Authority 與 Arbitration，均按照本書已經建立或在本章進一步限定的工程語義使用。

其中，Runtime 的統一結果值域仍未建立；輸入之間的關係與狀態模型仍未建立；Arbitration 與 Runtime 的對象關係繼續保持「不合並，不分立」；多個條件之間的合取關係究竟屬於 Arbitration 層還是 Final Execution Authority 的實現層，也繼續保持開放。本章不為這些問題提前補出答案。

涉及外部論文、標準、官方資料或現實事件的內容，統一列入全書 《參考文獻與資料來源》。

---

第十八章｜能改配置的人

本章把視線從一次 Action 轉向決定未來 Action 如何被約束的那層權力。修改配置的人未必參與任何一次具體執行，卻可能改變誰擁有 Authority、哪些 Boundary 生效、哪些 Policy 被採用，因此這種能力作用的不是 Action，而是 Authority 本身。本章把這個位置稱為配置權力面，用來指出一種 authority-over-authority 的結構：改變權威歸屬的能力，也必須進入權威分析之中。挑戰者號案例只用於暴露「同一位置既能施加約束，也能解除約束」這種機制，不承擔理論證明。配置權力面不是一張賬號或角色權限表，也沒有被建立成新的正式概念；Authority 負責識別這個位置，Governance 則處理這種改變在什麼條件下成立。再加一道審批也不會自動形成權威分解。於是問題繼續推進：把這些邊界都建立起來以後，執行控制是不是最終仍然要靠人逐筆確認？

上一章結束的地方留下了一個問題：誰能夠改變這整套結構本身？

這個問題很容易被聽成一個關於人的問題——哪個人、哪個賬號、哪個團隊擁有這樣的能力。但這一章首先關心的不是持有者是誰，而是這種權力在結構中處在什麼位置。至於這個位置在某個具體系統裡最終由誰佔據，是另一個問題。

第六章已經建立了一條關於權威分解的判據：分解是否成立，不取決於參與方數量、審批環節數、安全層數、服務數或者部署拓撲，而取決於在已經聲明的威脅模型下，允許失陷的主體集合能否獨立閉合從意圖到現實改變的因果鏈。換句話說，如果單一主體的失陷不足以完成整條執行鏈，分解才真正具有意義。

第七章又建立了一條關於執行邊界的條件：一個上限如果可以被受它約束的主體自己調高，它就不是執行邊界，而只是一條默認配置。

這兩條判斷分別處理了主體之間怎樣形成分解，以及一條邊界在什麼條件下真正成立。但它們還留下了一個更早的問題：被檢查的主體集合、上限和邊界，本身是怎樣被決定的？

如果一項執行約束最終依賴某處可以被設定和修改的值，那麼那裡的改變就不再只是普通參數變化。誰被允許參與，閾值如何確定，哪些 Action 受到保護，哪些規則在當前範圍內有效，哪些證明被接受，這些內容一旦能夠被改寫，就可能同時改變後續執行所依賴的前提。

這裡所說的「配置」，不是某一種配置文件、管理工具、數據庫或者部署方式。它只是一個抽象稱呼，用來指代那些決定未來執行約束如何成立的可變內容。不同系統完全可以用不同方式承載它們，本章不從承載方式反推理論結構。

於是問題真正變成了：如果所有約束都由某處的配置決定，那麼改變配置的權力處在哪裡？

一個不出現在任何一次執行裡的權力

改變配置的權力有一個很容易被忽略的特點：它可以不直接參與任何一次具體執行，卻決定其他所有 Authority 由誰承擔。

先看前半句。沿著一次具體 Action 的執行鏈往下追，從意圖提出、條件判斷、授權、裁決一直到現實改變，配置本身的修改者未必出現在這條鏈上。它不需要提出這次 Action，不需要批准這次 Action，也不需要親自完成執行。僅僅檢查「這一次發生了什麼」，很可能看不到這個位置。

但這並不意味著它不重要。恰恰相反，它改變的是以後每一次執行所依賴的前提。誰能夠批准，誰能夠執行，誰擁有否決能力，哪些 Authority 被建立、取消或者重新分配，都可能由更早發生的配置改變決定。

這使它與普通的執行權力不同。普通 Authority 主要作用於 Action：讓某一次動作能夠進入下一步、獲得現實效力或者被阻止。這裡討論的權力則作用於 Authority 本身。它不只是決定「這一次誰可以做什麼」，還可能重新定義「以後誰能夠做什麼」。

本書把這個位置稱為配置權力面（authority-over-authority power surface）。這個名稱只是為了指認一種需要被單獨看見的權力位置，它在本書中不帶正式編號，也不被建立為新的正式概念。真正重要的不是名稱，而是它所處的層次：它面對的不是某一次 Action，而是決定 Action 將來由哪些 Authority 處理的結構。

這也重新照亮了前面關於執行邊界的判斷。對於那些由配置決定的邊界，被約束的一方位於邊界之內；而改變這些配置的權力，則處在邊界形成的一側。它不需要在執行時臨時抬高某一個上限，只要改變這個上限原本被設成什麼、適用於誰，後續 Action 面對的就已經是另一套條件。

因此，僅僅檢查一條邊界能否被當前受約束者自己調高，還不足以覆蓋這裡的問題。還需要繼續問：決定這條邊界內容的權力本身在哪裡？

這類改變與具體執行之間還可能存在時間上的距離。配置被修改，並不意味著它一定在修改發生的同一時刻對現實執行產生效果；有些改變後來可以被撤回，有些則未必如此。這裡暫時只保留兩個性質：生效延遲與可逆性。

這兩個性質不構成一套配置生命週期模型。本章不據此劃分配置階段，也不規定在哪個階段應當增加新的控制。它們只說明一個事實：改變執行前提的時刻，與具體 Action 真正獲得現實效力的時刻，可以不是同一個時刻。

**如果審查只圍繞單次 Action 組織，這種權力就可能不出現在審查對象中。**執行發生時，人們看到的是當前已經生效的 Authority、Boundary 和 Policy；真正改變這些前提的動作，則可能發生在更早的時候。

所以，這一節真正要指出的不是「誰在改配置」，而是一個更基礎的位置：

有一種權力不必親自執行 Action，卻能夠改變以後由誰擁有執行相關的 Authority。

一張能改寫自己的圖

如果把一個系統中的權威關係表示成一張圖，誰能夠提出 Action，誰能夠批准，誰能夠執行，誰能夠否決，以及不同 Authority 之間怎樣形成約束，都可以被理解為這張圖中的關係。

通常我們會把這樣的關係當成執行發生之前已經給定的背景。一次 Action 在既有權威結構中流動，系統判斷誰可以做什麼、誰不能做什麼。但配置權力面帶來了另一個問題：如果某個位置能夠改變 Authority 的歸屬，那麼它改變的就不只是圖上某一次 Action 的走向，而是這張圖本身的形狀。

這就是「Authority Graph 是一張能夠自我改寫的圖」在本章中的含義。

這裡的「自我改寫」不是說權威結構會自行變化，更不是說存在一個具有自主行為的圖。它指的是：**改變權威結構的能力，本身也屬於權威結構的一部分。**系統不僅包含「誰擁有 Authority」，還包含「誰能夠改變誰擁有 Authority」這一層權力。

這和普通的結構變更不同。如果修改權威關係的能力完全位於權威結構之外，那麼我們仍然可以把當前結構看成一個被外部修改的對象。但當改變 Authority allocation 的能力本身也必須被當作一種 Authority 來識別時，結構與修改結構的權力就不再能夠被徹底分開。

不過，這個判斷必須停在這裡。目前它還不足以支撐一套正式的 Authority Graph 模型，也沒有足夠的獨立依據定義其中究竟存在哪些節點、哪些關係以及所謂「改寫」應該怎樣被形式化。因此，本章只把它作為一種有界的分析性描述使用，而不把它升格成已經建立的形式對象。

這也是為什麼不能順勢把 Authority Graph 畫成一張完整的結構圖。一旦規定節點、邊、方向以及改寫關係，就等於提前回答了一批目前沒有答案的問題。那不再是在解釋「權威結構能夠被改變」，而是在建立一套新的權威圖模型。

本章只保留這一層判斷：決定 Authority 歸屬的權力，本身也必須進入 Authority 的視野。

正因為如此，權威結構不再只是執行發生時的靜態背景。它本身也可能成為權力作用的對象。

判據可以被繞過的那個位置

回到第六章的權威分解判據。它面對的是一個已經給定的主體集合，然後詢問：在允許其中某些主體失陷的情況下，這個集合能否獨立閉合從意圖到現實改變的因果鏈？如果能夠獨立閉合，分解就沒有真正成立；如果不能，分解才具有結構意義。

這條判據檢查的是集合具有什麼能力，但它默認了一件事：集合本身已經在那裡。

配置權力面觸及的恰好是這個前提。它不需要親自進入一次 Action 的因果鏈，也不需要獲得某個執行環節的能力。如果它能夠改變 Authority 的歸屬，那麼它改變的就是構成這條判據輸入的主體集合本身。

因此，分解判據存在一個必須被單獨識別的位置：誰能夠重新定義被判據檢查的集合。

**在本書當前能夠支持的證據範圍內，這是唯一被識別為能夠重新定義其他所有 Authority 歸屬的位置。**這裡的「唯一」只限定於當前證據邊界，不意味著現實世界不存在其他結構，也不構成對所有系統的窮盡性判斷。

它和其他 Authority 的區別就在作用對象上。提出、批准、執行、證明和否決等權力，無論影響多大，最終都作用於某一次 Action；配置權力面作用的則是這些權力本身的歸屬。前者改變一次 Action 的命運，後者改變以後哪些主體能夠決定 Action 的命運。

這也是為什麼僅僅保護執行時刻還不夠。如果邊界本身可以被重新定義，而這種改變沒有進入同樣的權威分解視野，那麼最終 Authority 就可能從執行時刻悄悄轉移到配置時刻。

這裡的「悄悄」不是一個可以被定位到某一天、某一次操作的時序事件。它描述的是一種結構性結果：之後發生的每一次執行都可能完全符合當前規則，因為真正發生變化的不是執行有沒有通過檢查，而是檢查所依據的規則、邊界或者 Authority allocation 已經被改變。

表面上看，系統仍然在按照規則運行。審批仍然有效，邊界仍然存在，Runtime 仍然完成裁決，Executor 仍然只執行已經通過的 Action。但如果決定這些前提的權力沒有被識別出來，那麼執行時刻的合規並不能回答更早發生的那個問題：誰決定了現在使用的是這一套前提？

因此，「正確地定位」配置權力面，並不是在這一章替它設計新的審批、流程或者限制，而是先把它從系統背景中拿出來，作為 Authority 結構的一部分進行識別。修改邊界本身，也必須進入權威分解所觀察的範圍；否則，判據只檢查已經給定的結構，卻沒有覆蓋改變這個結構的權力。

這裡必須停住。「判據可以被繞過」不是在描述一種攻擊方法，也不意味著本章接下來要建立威脅模型、失敗矩陣或者攻擊路徑。本章能確認的只是一個結構性事實：單點失陷不應自動等於執行權威的完全失守，而改變主體集合本身，是這個判斷必須覆蓋的位置之一。

所以，「改變集合本身」在這裡不是一種手法，而是一個需要被識別的位置。至於誰會利用它、怎樣利用、失陷之後如何演化，都屬於本章之外的問題。

一條被反覆豁免的發射約束

挑戰者號事故之前發生過一件很適合放在這裡看的事情。它不能證明前面的理論判斷，但可以把「改變約束本身的權力」具體地呈現出來。

一九八五年七月，航天飛機固體火箭助推器被正式施加了一條發射約束。總統調查委員會後來確認，這些約束由 Marshall 的固體火箭助推器項目經理施加，也由同一角色反覆豁免。到 51-L 之前，這樣的連續豁免已經發生過六次。

這裡真正值得注意的不是豁免次數，而是權力關係本身：同一個角色既能夠施加約束，也能夠解除這項約束。

這和簡單的違規不同。如果一個主體偷偷越過規則執行 Action，問題很容易被描述成「規則存在，但有人違反了它」。這裡不是這樣。約束確實存在，施加約束的角色也確實擁有豁免它的權力，因此約束被解除並不需要先發生一次越權。

這正是這個案例與本章的連接點。執行時刻可以完全遵守當時有效的規則，但決定「哪些規則當前仍然有效」的權力，可能早在執行之前就已經發生作用。此時，僅僅檢查最終 Action 有沒有通過當前約束，並不能回答那個更早的問題：誰有能力改變這些約束本身？

所以這個案例在本章只承擔一種作用：暴露一種機制。它說明規則並不一定要被破壞，結構性風險才會出現；如果施加約束和解除約束的權力處在同一個位置，約束的存在本身並不能說明那個位置已經受到獨立限制。

它不證明配置權力面必然存在，也不證明所有系統都會出現同樣的結構。本章關於 authority-over-authority power surface 的判斷並不依賴挑戰者號案例成立。這個事件只是讓一種已經被提出的結構關係變得可見。

同樣，不能從這個案例繼續推出應該設置怎樣的豁免審批層級、允許多少次豁免、需要多少角色參與，也不能把它擴展成關於組織文化、管理方式或者失陷路徑的判斷。這些都超過了它在本章承擔的作用。

關於挑戰者號還有幾種常見說法，需要和這裡使用的事實分開。

發射當天的環境氣溫與右後現場接縫溫度不是同一個數值：前者是 36°F，後者是 28 ± 5°F，不能把兩者混成同一個「發射溫度」。

「異常正常化」（Normalization of Deviance）也不是總統調查委員會當時給出的結論。這個概念來自 Diane Vaughan 後來的社會學研究，因此不能把它倒寫成委員會對事故的原始判斷。

另一個經常出現的說法是「McDonald 拒絕簽字」。在本章採用的第一手記錄範圍內，這個說法得不到支持；相關簽署者是 Kilminster。

本章對這個事件的使用範圍到這裡為止。採用的是總統調查委員會報告第一卷第四章和第五章中與上述事實直接相關的內容，不繼續展開發射前夜的完整決策過程、各級管理層的知情範圍或者事故當天的時間線。

那些內容能夠回答別的問題，但不是這一節的問題。這一節只需要留下一個結構性的觀察：

規則沒有被違反，並不意味著約束它的權力結構沒有問題。

它不是一張權限表

現在回到這一章最容易被誤解的那個詞：「誰」。

「誰能改配置」聽上去像是一個身份或者權限問題。最直接的做法似乎是列出賬號、角色以及各自能夠修改的項目，然後用一張權限矩陣回答這個問題。

但這樣的表只能回答：此刻是誰佔據了這個位置。

本章問的是另一件事：這個位置本身是否存在，它具有什麼 Authority，以及這種 Authority 與其他權威之間是什麼關係。今天由一個管理員持有，明天換成另一個管理員，位置並沒有因此消失；即使持有者從一個主體變成多個主體，也不能僅憑數量變化說明這個結構問題已經被解決。

因此，「能改配置的人」不能被還原成 Identity、Account 或 Role List。身份可以告訴我們某個主體是誰，權限表可以告訴我們當前賦予了它哪些操作能力，但這些信息本身並不能說明：重新定義其他 Authority 的那個位置，在整個權威結構中是否被單獨識別出來。

角色表還有一個更深的前提：它默認「可以修改什麼」已經是一份給定的清單。角色在行上，配置項在列上，然後討論誰擁有哪一個格子的權限。但配置權力面面對的問題恰恰可能比這更早——它不僅可能決定誰擁有某項能力，還可能改變有哪些項、哪些 Authority 存在，以及誰能夠重新分配這些 Authority。

因此，本章不給出一張「誰能改什麼」的權限矩陣。不是因為這些表在工程上沒有價值，而是因為它們回答的是持有者問題，而這一章正在識別的是結構位置。兩者混在一起，反而會讓一個 Authority 問題被一個正確的身份清單遮住。

這裡還需要保留一條已經建立的邊界：系統的擁有者、管理員、平臺方或者其他高權限主體，都不能僅憑「擁有」或者「權限更高」這一事實，就天然獲得繞過所有 Execution Boundary 的能力。

高權限不等於無邊界。

這句話在這裡仍然只是一條執行邊界判斷。它不規定管理員應該怎樣產生，也不規定配置修改應該經過幾級審批，更不因此推出一套治理制度。它只是排除一個危險的默認前提：因為某個主體擁有系統或者擁有最高權限，所以所有邊界最終都可以由它取消。

前面關於 Authority 的定義已經排除了這種無限化。權威如果範圍不明、能夠被自動繼承或擴大，或者被理解為對所有現實動作都擁有無限能力，它本身就已經失去邊界。

權威分解同樣給出了另一條限制：如果不同角色最終仍然共享一個可以覆蓋其他權威的控制根，或者某一種 Authority 能夠無條件繼承、替代、關閉其他 Authority，那麼表面上的角色分離並沒有形成真正的權威分解。

一個能夠重新分配其他 Authority 的位置，如果始終被當作普通管理員權限處理，就可能成為那個沒有被單獨識別的可覆蓋控制根；而重新分配其他 Authority 的能力，也正是「繼承、替代或者關閉其他權威」這一風險可能出現的位置。

所以，這一節真正要區分的是兩件事：

**「誰現在擁有這個位置」是身份與配置問題；「這個位置能夠改變什麼權威關係」才是本章要識別的結構問題。**前者可以用名單回答，後者不能。

識別，與識別之外的那一側

到這裡，本章已經完成了最主要的任務：指出配置權力面這個位置，並說明為什麼它不能繼續被當作普通配置或者系統背景處理。

但識別出這個位置以後，很自然會出現下一組問題：誰可以修改規則，修改需要滿足什麼條件，角色怎樣變化，發生錯誤以後怎樣恢復。

這些問題已經越過了本章負責的那一側。在這裡，Authority 討論負責的是識別：誰能夠改變 Authority 的歸屬，誰能夠改變未來的權威結構。至於規則怎樣變更、變更經過什麼過程、角色和結構怎樣調整，以及失效之後怎樣恢復，屬於 Governance 所處理的問題。

本書所說的 Governance，是決定執行規則、角色、閾值、狀態及其變更與恢復條件的受約束過程。它能夠改變未來的執行邊界，但不等同於每一次現實執行。它也不是一般意義上的行政、管理、審批或執行，而且程序本身合法，並不能自動說明結果就是正確的。

這正好說明了兩邊的區別。本章關心的是：改變 Authority 的位置有沒有被識別出來。 Governance 關心的是：這種改變在什麼條件下能夠成立。

兩者彼此相鄰，但不是同一個問題。因此，它們之間存在一個邊界明確、但尚未被形式化的共享接口（bounded shared interface）。哪一側負責什麼已經可以區分，但本書不因此建立一條新的形式關係，也不把 Governance 變成本章的主幹對象。

這一章只把配置權力面從背景中拿出來，使它能夠被看見。至於怎樣約束這個位置，則不能因為問題已經被識別，就順手補上一套制度。

因此，有幾件事必須停在這裡。本章不設閾值。雖然 Governance 的失敗條件涉及「無閾值」，但這並不能反推出一個具體閾值應該是多少。後果範圍怎樣分級，目前沒有已經建立的統一判據；在判據不存在的情況下直接給出一個數字，只會製造一種邊界已經精確成立的假象。

本章也不設計恢復路徑。如果 Authority 已經被錯誤地重新分配，由誰確認恢復、什麼狀態算恢復完成、什麼時候可以重新授予，這些問題目前都沒有形成足以支持統一答案的結構，因此不能在這裡提前指定。

同樣，本章不展開 Governance 自身的失陷。治理當然也可能發生問題，而且它的失效可能直接影響執行邊界，但這一章只確認這個風險存在，不繼續建立它的威脅模型、失效形態或恢復結構。

在本章範圍內，可以確定的只有一條負向邊界：Governance 不能成為繞過系統的後門。

這不是一套治理設計原則，而只是規定它不能產生什麼結果。治理能夠改變未來的執行邊界，但不能因為擁有改變邊界的能力，就自動成為現實執行的最終權力。

Governance is not final execution.

在本書中，這句話只承擔一條執行邊界意義：最終執行的裁決權不能因為治理能力的存在，就重新落回普通軟件可以單獨控制的失陷域。至於這應該怎樣部署、怎樣組織以及由什麼角色承擔，本章不作回答。

所以這裡的分工很清楚：**這一章負責讓配置權力被看見，Governance 負責處理它怎樣被改變。**前者是識別，後者是治理。兩者相接，但不能混成同一件事。

那就再加一道審批

識別出配置權力面以後，一個很自然的反應是：既然這個位置太重要，那就在修改配置之前再加一道審批。

但增加審批環節，本身並不等於建立權威分解。

第六章已經給出了判斷標準。真正需要看的不是多了幾個人、幾次確認或者幾層流程，而是在已經聲明的威脅模型下，允許失陷的主體集合是否仍然能夠獨立閉合從意圖到現實改變的因果鏈。如果新增的審批與原來的配置持有者仍然落在同一個可覆蓋控制範圍內，那麼環節從一層變成兩層，並不會自動改變判據結果。

第七章的邊界條件在這裡同樣適用。如果這道審批是否開啟、適用於哪些修改、在什麼範圍內有效，本身仍然可以被受它約束的同一位置重新配置，那麼這道審批就不能僅憑「存在」被認定為獨立執行邊界。它仍然可能只是另一條默認配置。

因此，問題不在於有沒有審批，而在於審批本身是否形成了獨立約束。

這裡還要考慮前面已經提到的一個特點：配置發生改變的時刻，與它真正影響具體執行的時刻可能並不一致。於是，當配置改變先於具體 Action 生效時，配置側面對的就不是一項已經出現的具體 Action，而是在更早的時候改變未來 Action 將要面對的條件。

這也說明為什麼「再加一道逐筆審批」不能直接成為本章的答案。逐筆審批處理的是一次具體動作，而配置權力面改變的可能是之後一系列動作共同依賴的 Authority、Boundary 或 Policy 前提。兩者作用的對象並不相同。

本章不回答審批應該怎樣設計，也不決定需要幾個人、幾層或者什麼流程。那些問題已經進入 Governance。

本章只保留兩條判斷標準：新增結構是否真正形成了 Authority Decomposition，以及它是否滿足 Execution Boundary 的成立條件。

加一道審批不是答案。新增的那一道審批，也必須接受同樣的邊界檢查。

兩處留白

這一章結束之前，還需要留下兩個沒有被繼續推進的地方。第一個是配置權力面本身。

本章已經能夠識別這個位置，也能夠說明它為什麼不同於普通的執行 Authority：它不必直接參與一次具體 Action，卻可以改變其他 Authority 的歸屬，並因此改變未來執行所依賴的前提，但這還不足以把它建立成一個新的正式概念。

本章沒有為配置權力面給出完整的形式定義，也沒有建立它全部必要條件、內部結構以及與其他 Authority 的完整關係。因此，它在這裡仍然只是一個被明確識別出來的權力位置，而不是一個已經完成形式化的理論對象。

第二個留白位於 Authority 與 Governance 之間。兩邊的職責已經可以區分：Authority 這一側負責識別誰能夠改變權威歸屬和未來的權威結構；Governance 負責處理這些改變通過什麼條件和過程成立。

但職責能夠被區分，不意味著兩者之間的關係已經被形式化。本章沒有建立一條新的正式關係，也沒有定義兩邊應當通過什麼結構進行銜接。

這兩處留白不是本章遺漏掉的答案。一個位置可以先被識別出來，再決定它是否值得繼續形式化；兩個主題之間也可以先劃清職責邊界，而不立即把它們連接成一套完整模型。對於這一章來說，能夠準確停在這裡，比提前補出一個結構更重要。

因此，第十八章真正增加的是一個新的觀察層次。如果執行約束依賴於可以被改變的配置，那麼只檢查執行發生時誰擁有 Authority、Boundary 是否成立、Policy 是否通過，還不夠。還需要看到另一個位置：誰能夠改變這些判斷所依賴的前提。

這個位置不一定直接參與具體 Action，卻能夠影響未來 Authority 怎樣分配、哪些邊界成立以及後續執行面對怎樣的條件。於是，權威分解不能只觀察已經給定的執行結構，還必須把改變這套結構的權力納入視野。

否則，具體執行可以一直保持合規，而最終 Authority 已經從執行時刻悄悄轉移到了配置時刻。

到這裡，本書已經從幾個不同方向逼近同一個要求：執行走向現實之前，需要有獨立的判斷；約束不能由被約束的一方自行取消；承擔不同 Authority 的主體不能因為表面上的分離，最終仍然共享一個可以覆蓋其他權威的控制根；而現在，連改變這些邊界和 Authority 歸屬的位置，也不能繼續被當作普通配置留在結構之外。

這很容易產生另一個印象。既然執行走向現實之前要受到 Boundary、Intent、State、Evidence、Policy 以及 Runtime 裁決等多方面約束，現在連改變這些條件本身的權力也要受到獨立約束，那麼系統是不是最終只能把人重新放回每一次 Action 前面？

那麼，這樣一套執行前的獨立判斷結構，是否等於把系統退回人工逐筆審批？

本章術語

• 權威 ｜ Authority
• 權威分解 ｜ Authority Decomposition
• 配置權力面 ｜ authority-over-authority power surface
• 權威圖 ｜ Authority Graph
• 權威歸屬 ｜ Authority Allocation
• 執行邊界 ｜ Execution Boundary
• 治理 ｜ Governance
• 有界共享接口 ｜ Bounded Shared Interface
• 動作 ｜ Action
• 策略 ｜ Policy

本章所說的配置權力面，指能夠改變其他 Authority 歸屬以及未來權威結構的權力位置。它不必直接參與某一次具體 Action，卻能夠改變後續執行所依賴的 Authority、Boundary 或其他結構前提。

「配置權力面」在本章中不是新的正式概念，也不建立獨立編號。本章只識別這個位置以及它帶來的結構性問題，不為其建立完整形式定義。

Authority Graph 在本章中是一種有界的分析性表達，目前缺少獨立的交叉支撐，因此不能被視為已經建立的形式對象。改變 Authority 歸屬的能力本身，也屬於 Authority 結構需要觀察的對象。本章不進一步定義 Authority Graph 的節點、邊或形式模型。

Authority Decomposition 仍然按照前文已經建立的判據使用：判斷重點不在主體數量、審批層數或系統拓撲，而在允許失陷的主體集合能否獨立閉合從意圖到現實改變的因果鏈。本章進一步指出，這一判據還必須面對集合本身能夠被改變的問題。

本章對 Governance 只作邊界引用。Authority 主題負責識別誰能夠改變 Authority allocation 和未來的權威結構；Governance 負責規則、角色、狀態及其變更與恢復過程。兩者之間保持有界共享接口，但本章不把這一接口升格為正式關係，也不設計治理流程、角色、閾值或恢復機制。

本章案例與資料來源

挑戰者號事故（STS 51-L）

本章使用挑戰者號事故之前的發射約束及其反覆豁免作為現實案例。

該案例在本章只承擔機制暴露作用：一項真實存在的發射約束由固體火箭助推器項目經理施加，同時同一角色也擁有反覆豁免該約束的能力。它展示的是一種結構性問題——同一位置既能夠施加約束，也能夠合法解除約束，而這一過程並不要求先發生越權或違規。

這個案例不用於證明配置權力面這一理論判斷，也不用於推出治理流程、審批層級、豁免次數閾值、組織文化判斷或失陷模型。案例只能讓一種已經被識別的權力結構變得具體，不能替代理論本身。

本章採用的主要一手資料為：

Report of the Presidential Commission on the Space Shuttle Challenger Accident, Volume I, Chapter IV 與 Chapter V，1986。

本章對該事件的事實採用範圍限定在上述兩章。正文不展開發射前夜的完整決策過程、組織層級、管理層知情範圍或事故時間線。

有三項容易與本章事實混淆的內容需要保持區分：

發射當天的環境氣溫 36°F 與右後現場接縫溫度 28 ± 5°F 是兩個不同數值，不能合併使用。

「異常正常化」（Normalization of Deviance）不是總統調查委員會當時給出的結論，而是 Diane Vaughan 後來的社會學解釋，因此不作為委員會原始結論引用。

關於「McDonald 拒絕簽字」的常見說法，在本章採用的一手資料範圍內得不到支持；相關簽署者為 Kilminster。

因此，挑戰者號案例在本章留下的意義被嚴格限制在一點：規則沒有被違反，也不能僅憑這一事實推出決定規則是否繼續有效的權力已經受到獨立約束。

---

第十九章｜邊界越清楚，裡面越可以自動

本章拆掉「安全等於所有 Action 都由人確認」這個等號。執行控制要求的是，在現實動作發生以前存在獨立、有效並能夠真實約束執行的邊界，而不是把人工逐筆審批變成所有動作的最終依據。人工確認可以存在，也可以在特定場景中成為必要步驟，但它是否存在，與它是否擁有最終執行效力，是兩個問題。邊界越清楚，系統越不需要把逐筆人工確認作為安全成立的普遍條件，邊界內部也就越可以自動化；但這裡表達的是方向，不是自動化等級、風險評分或一套刻度。本章同時提醒：現有結構雖然已經成形，卻處於不同的理論狀態，既沒有形成互斥完備的分類，也不能因為當前案例都能被解釋，就宣稱結構已經被證明完整。於是全書最後只剩一個問題：哪些地方我們已經明確知道還沒有答案？

上一章結束時，問題已經從一次具體 Action 的執行推進到了更高一層：不僅要問執行時誰擁有 Authority，還要問誰能夠改變這些 Authority 本身的歸屬。

走到這裡，很容易產生一個相反的印象。前面已經建立的幾條結構都在強調獨立約束。Action 真正產生現實效果之前，仍然需要存在能夠阻止它發生的負向約束；Runtime 負責形成裁決，卻不能自己執行外部動作；而決定未來 Authority、Boundary 和 Policy 前提的配置權力，也不能繼續被當作普通配置留在結構之外。

這些要求放在一起，看起來很像是在不斷增加「停下來確認」的位置。既然最後一刻仍然可以拒絕，既然執行之前還需要獨立裁決，既然連配置本身都不能由被約束的一方隨意改變，那麼一個很自然的問題就是：這套結構是不是最終又把人放回了每一次 Action 前面？

換句話說，這樣一套執行前的獨立判斷結構，是否等於把系統重新變成人工逐筆審批？

這裡所說的「人工逐筆審批」不是泛指系統中有人參與，而是一種更具體的結構：每一次 Action 在獲得現實效力之前，都必須等待一次人工確認，並且這次人工確認本身成為動作能夠繼續發生的最終依據。

這個問題不能簡單地當成對操作麻煩的抱怨。如果每一次 Action 都必須等待人工確認，那麼執行能力就會直接受到人工確認能力的約束。系統可以自動生成更多動作、自動完成更多判斷，但最終仍然必須排隊等待人的逐筆放行。在這種結構下，自動化擴大到哪裡，人工確認就必須跟到哪裡。

但這並不是執行控制的目標。本書對這一點已經預先給出了明確邊界，它不是從前十八章繼續推導出來的新結論，而是前面那些結構最終必須與之保持一致的目標約束：

執行控制的目標不是把系統重新變成人工逐筆審批。邊界越清楚，邊界內部越可以自動化。成熟的執行控制應該減少不必要的人類介入，而不是把「安全」等同於「所有 Action 都由人確認」。

這裡有幾個詞不能被隨意刪掉，尤其是「不必要的」。減少不必要的人類介入，不等於減少所有人類介入，更不等於把人從系統裡拿走。同樣，「邊界內部越可以自動化」也不是對自動化本身作價值判斷，更沒有給出一套自動化程度的標準。它只是在說明執行控制應該解決什麼問題：把需要獨立約束的邊界真正建立起來，而不是把無法說清楚的邊界統一交給人工確認兜底。

因此，第十九章不是要證明「自動化更好」，也不是要設計一種無人系統。它只回答前面已經出現的那個問題：

執行控制是否必然意味著人工逐筆審批？

那個等號

先拆掉一個最容易出現的等號：

安全 = 所有 Action 都由人確認。

執行控制並不等於人工確認。人工確認當然可以在系統中承擔具體作用，也可以在某些位置上成為必要步驟，但它和執行控制不是同一個對象。執行控制關注的是：一次 Action 在獲得現實效力之前，是否受到獨立、有效並且能夠真實約束執行的判斷；至於其中某一步是否需要人工參與，是另一個問題。

因此，真正需要排除的並不是人工確認本身，而是把它當成默認最終解決方案。

「默認」和「最終」兩個詞都不能省。這裡並不禁止某個具體 Action 在特定條件下等待人工確認，也不否認某些場景必須有人介入。被排除的是另一種做法：只要問題暫時難以通過邊界、狀態、證據或者策略說明清楚，就把最終判斷統一交給某個人，並把「有人確認過」當成 Action 可以成為現實的最後理由。

這樣做的問題不只是增加了一個操作步驟。更重要的是，那些原本必須被說清楚的問題會被人工確認覆蓋掉：當前狀態是否仍然成立，證據是否充分，Authority 是否仍然有效，邊界有沒有被改變，這些問題本來應該擁有各自的判斷依據，卻可能最終都被壓縮成一次「同意」。

可以設想兩個執行位置。第一個位置規定：只要有人完成確認，Action 就繼續執行。

第二個位置同樣允許人工確認存在，但確認之後，Action 在獲得現實效力之前仍然需要根據當前 State、Parameters、Authority、Policy、Boundary 和 Evidence 形成獨立裁決；如果裁決不成立，即使此前已經有人確認，Action 仍然不能發生。

這只是一個用於說明差異的假想情境，它不描述真實系統，也不承擔理論證明。它只說明一件事：人工確認是否存在，與人工確認是否擁有最終執行效力，是兩個不同問題。

兩種結構從流程表面上看甚至可能非常接近，都有人參與，都可能出現一個「確認」動作，但它們的權力結構並不相同。第一種結構把那次人工確認本身作為最終放行依據；第二種結構則把人工確認保留在它自己的位置上，而最終執行仍然受到獨立邊界約束。

這裡還要注意原命題中的另一個詞：所有。問題不是某一次 Action 是否需要人工確認，而是能不能把「所有 Action 都必須由人確認」定義成安全成立的普遍條件。如果這樣定義，那麼任何沒有人工確認的執行天然都會被視為缺口，系統也就只能通過不斷增加人工參與來維持這個定義。

這正是執行控制要避免的等號。但拆掉這個等號，並不意味著把人從結構裡拿走。人工確認仍然可以存在，人工決策也仍然可以在適當的位置承擔作用。本章沒有回答哪些介入是必要的，也沒有建立一套「什麼時候必須由人參與」的分類。

因此，「減少不必要的人類介入」中的不必要不能被刪掉。

把它改成「減少人類介入」，主張已經變了；再把它推進成「取消人類介入」，就走到了更遠的地方，而本章沒有這樣的結論。

同樣，「邊界內部越可以自動化」也不是在為自動化本身作價值判斷。它的主語始終是執行控制：當真正需要獨立約束的位置被說清楚以後，安全就不必繼續依賴所有 Action 都等待一次人工確認。

所以這一節拆掉的只有一個等號：

執行控制 ≠ 人工逐筆確認。

它沒有把人排除在系統之外，也沒有把自動化變成新的默認答案。

「邊界清楚」不是一個刻度

那麼，「邊界越清楚」裡的「清楚」，究竟指什麼？前面已經建立了幾條與它直接相關的判斷。Execution Boundary 是 Action 獲得現實效力之前的最終約束，並且必須能夠真實允許或阻止現實副作用。Boundary Independence 要求：如果受約束主體同時能夠關閉、重寫或者繞過這條邊界，就不能僅憑這條邊界的存在認定獨立性已經成立。Runtime 的職責則更明確：負責裁決，但不執行外部動作。

這些判斷共同指向一件事：真正需要被說清楚的是執行邊界本身。

「邊界越清楚，邊界內部越可以自動化」並沒有要求邊界內部採用某一種結構，也沒有規定內部必須怎樣運行。它表達的是另一層關係：如果 Action 是否能夠成為現實，已經由獨立並且能夠真實生效的邊界決定，那麼是否每一次都需要有人在場確認，就不再和這條邊界是否成立綁定在一起。

但這裡不能繼續向前多走一步。上面的幾項判斷各自在自己的範圍內已經成立，卻沒有足夠依據說明它們合在一起就構成了「邊界清楚」的充分條件。本章因此不會給「邊界清楚」建立一個完整定義，也不會補出一套判斷模型。

能夠確認的只是方向：如果阻止一次 Action 發生，並不依賴於某個人此刻正在觀察和確認它，那麼「有人正在看著」就不是這條邊界能夠生效的必要條件。內部是否逐筆等待人工確認，與邊界是否能夠在必要時阻止現實執行，是兩個可以分開處理的問題。

這也是「邊界內部越可以自動化」能夠說到的程度。它給出的是方向，不是刻度。這句話沒有提供自動化程度的單位，也沒有建立任何等級。它沒有告訴我們哪些 Action 可以完全自動執行、哪些必須人工介入，更沒有給出一個閾值，達到某個數值以後就可以把人移出執行鏈。

要建立這樣的分級，必須先知道不同 Action 應該按照什麼標準區分後果範圍、風險程度以及人工介入要求。目前並沒有已經建立的統一判據能夠承擔這項工作，因此本章不能從「邊界越清楚」繼續推出一張自動化等級表。

「越……越……」在這裡表達的是比較方向，而不是可以橫向比較的等級或數值。它只說明：邊界越清楚，系統越不必把逐筆人工確認作為安全成立的普遍條件。

這也解釋了為什麼上一節必須保留「不必要的」這個限定詞。

如果已經存在一套充分成立的劃分，能夠明確告訴我們哪些 Action 必須有人、哪些不需要，那麼「不必要的」確實可以進一步被展開。但現在沒有這樣的統一劃分，所以這個詞不能提前被換成一份看似精確的名單。

同樣的邊界也適用於執行控制本身。執行控制在形成判斷時需要面對 State、Parameters、Authority、Policy、Boundary 和 Evidence 等信息。這些是判斷成立時需要面對的對象，不是一份系統模塊清單。不能因為這裡出現了六類輸入，就反推出系統必須擁有六個組件、六條處理鏈或者某一種固定架構。

「判斷必須能夠真實約束現實執行」也是同樣的道理。它描述的是執行控制成立的條件，而不是指定一種技術手段。如果一個判斷最終無法影響 Action 是否獲得現實效力，那麼它就沒有形成這裡所說的執行控制；至於通過什麼組件、通信方式或者部署結構實現這種約束，本章不回答。

所以，「邊界越清楚，邊界內部越可以自動化」不能被展開成一套自動化工程方案。

它只確定一個方向：執行控制追求的不是增加人工確認，而是把真正決定 Action 能否成為現實的邊界說清楚，並讓它能夠真實約束執行。

不整齊

寫到這裡，很容易產生一種越來越完整的感覺。前面的對象被逐步拆開，邊界被逐步劃清，第十七章給出了裁決發生的位置，第十八章又把改變 Authority 結構本身的權力單獨指出來。繼續沿著這種感覺往下走，一個很自然的期待就是：把這些東西最後收成一張圖。

幾個層次，若干結構，每一種問題都能找到自己的位置。

但目前不能這樣做。現有結構之間確實存在不同狀態。有一些已經在明確條件下被凍結下來，但它們的成立始終帶著自己的限定；有一些已經獲得較多覆蓋，卻因為證據或者語義依賴尚未滿足而沒有凍結；還有一些則已經失去獨立結構地位，被降級、併入其他位置或者取消。

這三種狀態不能被放到同一根尺度上理解。所謂「條件凍結」，重點在「條件」。一個結構能夠被保留下來，不意味著圍繞它的全部問題都已經解決，而意味著在已經明確的範圍和限定下，它可以成立。限定一旦被拿掉，剩下的那句話即使仍然聽起來合理，也已經不再是原來那個判斷。

同樣，尚未凍結的結構也不是「弱一點的凍結結構」。它沒有取得凍結地位，可能是因為證據還沒有收斂，也可能是因為它所依賴的語義本身仍未建立。被降級或併入其他位置的結構則又是另一種狀態，它不能被理解成比「未凍結」更弱一級。

所以，這三種狀態不可互相替代，也不能排列成三個強弱等級。

更重要的是，目前也不能聲稱這些結構彼此互斥。在現有分析中，多數對象同時落入兩到三個結構範圍；在已經分析的四個案例中，每一個都需要五到六個結構共同解釋。這樣的結果至少說明，當前結構還沒有達到可以被當作互斥分類體系使用的程度。

最小充分性同樣沒有建立。能夠用現有結構解釋已經觀察到的問題，不意味著這些結構已經構成全部必要且充分的集合。一個具體情形可能同時涉及多個結構，而現有結構之外是否還存在尚未被識別出的一級問題，也不能因為當前案例已經能夠解釋就被自動排除。

因此，這套結構可以幫助分析，卻不能被直接當成一張分類表。如果把它畫成若干互不重疊的格子，圖形本身就會暗示兩件目前尚未成立的事情：每一個問題都能夠唯一歸類，以及這些格子加在一起已經覆蓋全部結構。即使在圖下注明限制，真正留下來的往往仍然是那個整齊的形狀，而不是限制本身。

所以本章不畫這樣的圖，也不製作對應的分類表。這不是排版選擇，而是理論狀態決定的結果。當前結構呈現出的不對稱，也不是為了保守或者形式上的謙遜而故意留下的。它來自當前證據能夠支持到的位置：有些結構已經可以在條件下成立，有些還不能，有些已經不再保有獨立地位。為了讓它們看起來整齊而把這些差異抹平，會把尚未建立的關係寫成已經建立的關係。

至於未來這些結構能否進一步形成互斥關係，或者最終能否得到一個最小充分集，本章不回答。那需要形式理論層面的工作，而這裡還沒有走到那一步。

本章能夠做的，是讓這種不對稱保持可見。因為一旦只留下「結構已經成形」這句話，而把這些限制壓到旁註、附錄或者圖注裡，讀者最終得到的就會是一個比當前證據更完整、更整齊的結構，而那不是這一章能夠聲稱的東西。

結構成形，不等於問題解決

上一節處理的是一種誤讀：結構已經出現，所以應該能夠被整理成一套整齊的分類體系。

還有另一種更容易出現的誤讀：結構既然已經成形，問題是不是也就解決了？

不是。一套結構能夠走到當前狀態，並不要求所有問題都已經得到答案。真正需要滿足的是另一種條件：還沒有解決的問題已經能夠被明確指出，不再以一個說不清楚的空缺留在結構裡。

這些未決大致可以處在幾種狀態中：有些已經被界定，知道問題究竟發生在哪裡；有些已經被命名，能夠被穩定地指認；有些已經被指派到明確的理論位置，知道應該由哪一側繼續承擔；還有一些則被顯式延後，因為當前條件還不足以繼續推進。

這幾種狀態有一個共同點：**它們都不是「已經回答」。**界定一個問題，不等於解決它；給它一個名字，也不等於擁有答案；知道它屬於哪裡，不意味著那個位置已經完成處理；顯式延後更只是承認當前還不能繼續往前。

因此，這些未決也不能被理解成一份普通的待辦清單。待辦意味著路徑基本已經清楚，只差執行；這裡的很多問題連最終應該形成什麼對象、採用什麼判據，都可能仍然沒有建立。

另一個容易被誤讀的判斷是：**一級結構缺口為零。**它的含義非常窄：在目前已經核驗的案例範圍內，沒有出現一個必須額外建立新的一級結構才能解釋的情形。現有案例都能夠由當前結構的組合解釋，因此目前沒有證據要求增加新的一級結構。

但「能夠被解釋」和「結構已經被證明」不是一回事。上一節已經說明，現有結構之間的互斥性沒有建立，最小充分性也沒有建立。有的具體情形甚至需要多個結構共同參與才能解釋。能夠把現象放進已有結構，並不能反過來證明這些結構已經正確、完整或者最終。

所以：

一級結構缺口為零，不等於未決問題為零。

當前仍然存在十二項開放邊界。本章不展開它們的具體內容，只需要保留一個事實：它們確實存在，而且其中任何一項都不能因為整體結構已經成形，就被改寫成「已經解決」。

這條限制很重要。一個尚未建立的判斷如果被提前寫成已經成立，後續結構就可能開始把它當作前提。之後的推理即使每一步都看起來合理，最下面依賴的仍然是一個沒有真正成立的東西。未決之所以必須保持為未決，就是為了阻止這種變化發生。

因此，「結構已經成形」必須帶著幾個明確的限制一起理解。

它不等於理論已經定案。

它不等於正式分類體系已經凍結。

它不等於以後不會修訂。

它也不等於從現有結構走向形式理論的工作已經完成。

這些判斷可以同時成立：結構已經足以被辨認，主要對象和邊界已經出現，在目前已經核驗的案例中也沒有出現無法解釋的一級結構缺口；與此同時，它仍然包含尚未解決的關係、判據和邊界。

所以，本章不能在這裡宣佈完整性。它能夠給出的判斷只有這麼多：

結構已經成形，但它既不整齊，也不完整。

還剩下什麼

回到這一章開始時的問題。本章所說的自動化不是一個獨立的安全目標，也不是自動化程度的分級概念。「邊界越清楚，邊界內部越可以自動化」表達的是執行控制的方向：邊界越清楚，系統就越不必把所有 Action 的安全建立在逐筆人工確認之上。

前面建立的幾個位置並不是為了把人重新放回每一次執行之前。負向約束負責在必要時阻止 Action 獲得現實效力，Runtime 負責形成裁決而不親自執行，配置權力面則讓改變未來 Authority 和 Boundary 的位置本身進入約束視野。它們共同指向的不是更多人工確認，而是讓真正決定 Action 能否成為現實的邊界能夠獨立成立。

因此，本章能夠回答最初那個問題：

執行控制不必以人工逐筆審批作為最終形態。邊界越清楚，系統就越不必把所有 Action 的安全建立在逐筆人工確認之上。

但這個答案有明確的限度。當前結構並不整齊。已有對象處於不同的理論狀態，它們不能為了形式統一而被強行放到同一層，也不能被提前整理成互斥、完備的分類體系。

當前結構同樣並不完整。結構已經成形，只說明主要問題已經能夠被識別和解釋，並不意味著所有關係、判據和開放邊界都已經得到答案。仍然存在沒有解決的問題，而這些問題必須繼續保持為未決，不能因為整體結構已經出現，就被提前寫成已經成立的前提。

所以，本章在這裡不能繼續向前宣佈完整性。它能夠確定的是：人工逐筆審批不是執行控制的默認終點；邊界清楚與內部自動化並不矛盾；現有結構也已經足以讓這個判斷獲得明確的位置。

但當這個問題被回答以後，另一個問題隨之變得更清楚。原來問的是：這套執行前的獨立判斷結構，是不是最終仍然要求每一次 Action 都等待人工確認。

現在要問的則是：既然它不需要依賴人工逐筆確認，那麼這套結構本身究竟已經走到了哪裡，還有什麼沒有被回答？

這套結構現在已經完整了嗎？還剩下哪些問題沒有被回答？

本章術語

• 執行控制 ｜ Execution Control
• 人工確認 ｜ Human Confirmation
• 執行邊界 ｜ Execution Boundary
• 邊界獨立性 ｜ Boundary Independence
• 運行時 ｜ Runtime
• 動作 ｜ Action
• 狀態 ｜ State
• 權威 ｜ Authority
• 策略 ｜ Policy
• 證據 ｜ Evidence
• 自動化 ｜ Automation

執行控制用於判斷具體 Action 在當前 State、參數、Authority、Policy、Boundary 和 Evidence 條件下，是否仍然可以改變現實狀態，並要求這一判斷能夠真實約束執行。它不等於人工確認，人工確認可以存在於執行結構中，但不能因此被視為執行控制本身。

執行邊界是 Action 獲得現實效力之前能夠真實約束執行結果的最終邊界；邊界獨立性則要求這條邊界不能因為受約束主體同時擁有關閉、重寫或繞過它的能力而失效。

Runtime承擔邏輯裁決，但不執行外部動作。它與 Execution Control 有關，卻不能替代整個 Execution Control。

本章所說的自動化不是一個獨立的安全目標，也不是自動化程度的分級概念。「邊界越清楚，邊界內部越可以自動化」表達的是執行控制的方向：執行邊界越能夠被清楚地建立和約束，系統就越不必把所有 Action 的安全建立在逐筆人工確認之上。

因此，本章強調的是減少不必要的人類介入，而不是取消人類介入。哪些 Action 必須由人參與、哪些可以自動執行，本章沒有建立統一劃分，也沒有給出自動化等級或度量標準。

本章案例與資料來源

本章沒有現實案例。正文中用於比較兩個執行位置的情境，是一個純粹的假想微例。它只用於說明一個已經建立的區別：人工確認是否存在，與人工確認是否擁有最終執行效力，不是同一個問題。

這個假想情境不描述任何真實系統，不承擔證據或證明作用，也不建立新的理論對象。即使刪除這個例子，本章關於「Execution Control ≠ Human Confirmation」的論證仍然成立。

本章在討論現有結構是否互斥、是否構成最小充分集時，還提到已經分析過的若干案例，其中四個案例都需要多個結構共同解釋。這裡使用的只是這些案例所形成的整體證據結果，而不是案例本身，因此本章不展開案例名稱、事實鏈或具體情節。

這一證據只支持一個有限判斷：當前結構還不能被寫成互斥、最小充分的分類體系。它不用於證明「邊界越清楚，邊界內部越可以自動化」，也不用於證明現有結構已經完整。

因此，第十九章不設置獨立的現實案例，也不增加外部案例資料來源。

---

第二十章｜九個還沒有答案的問題

本章不是把全書包裝成一個已經閉合的體系，而是明確這一階段研究能夠停在哪裡：一次具體 Action 在現實改變之前取得執行效力所需的主要條件已經建立，但「能夠解釋現有問題」不等於「結構已經被證明完整」。因此，本章保留九個明確未決：處置語義之間的關係；Amplifier 在不同證據層上的差異；尚不能開始設計的 Relation-State Model；使用「不需要實質變化」判據前必須先確定的邊界、環境、時間與狀態前提；四個尚未凍結的候選結構；仍未定義的 Proof；必要條件合取規則究竟歸屬哪一層；多個 Veto 與多個 Deny 怎樣組合；以及隨著案例增加仍在擴展、不能被凍結成 taxonomy 的拒絕失效形態。這九項不是遺漏，也不是待辦清單，而是當前證據的邊界；另一組形式化缺口與它們屬於不同觀察維度，不能簡單相加成十五個問題。研究可以停下來，但問題並沒有因此全部解決。

上一章的結論是：邊界越清楚，邊界內部越可以自動。執行控制不是把系統退回人工逐筆審批，成熟的控制結構應當減少不必要的人類介入，而不是把「安全」等同於「每一次動作都由人點一下」。這句話說完，這本書要建立的東西就建立完了。剩下的問題只有一個：它完整了嗎？

先把能說的說清楚。一次具體的 Action，在它變成現實世界裡的一次動作之前，要取得執行效力需要滿足什麼條件——這個問題已經有了答案，而且是一份可以逐項檢查的答案。這一次動作的意圖必須被識別出來並被綁定；授權必須存在，而且這一次仍在它聲明覆蓋的範圍內；批准過不等於此刻仍然成立；所依據的事實狀態必須可被驗證，而不是被記錄；充分性有一組可以檢查的條件，而不是一句「材料齊了」；規則側那些各自有限、彼此並不一致的輸入，收斂成這一次動作的一個有限範圍，而且收斂只能朝收緊的方向；裁決發生在現實動作之前的最後一刻，而不是事後的復盤裡；即使全部正向資格都已建立，仍然可以有一個有效的否定把它攔下來。這些條件各自有各自的成立方式，也各自有各自的失敗方式。它們加在一起構成這本書的正面結論：一次具體 Action 在現實動作發生之前獲得執行效力的條件，已經建立。

這句話的分量在它的限定語裡。它說的是條件，不是保證；說的是這一次具體的動作，不是一類動作；說的是現實動作發生之前的那一段，不是事後如何發現、如何回滾、如何追責。這些限定不是謙辭，它們標出的是這本書實際走到的地方：一次動作在真正落地之前，有哪些東西必須成立、由誰來確認、在哪個時點確認、缺了哪一項就不許繼續。把這些條件逐項建立起來，是一件可以完成的事，而它確實已經完成了。

但「已經建立」不等於「已經沒有問題」。這一章要做的，是把還沒有答案的九個問題按它們各自原本的樣子交出來——不補齊，不壓縮，不改寫成已經解決。

一本方法書的最後一章通常有兩種寫法。一種是把前面講過的東西再收一遍，給讀者一個閉合的印象；另一種是列一份後續工作清單，告訴讀者接下來還要做什麼。這一章兩種都不是。前一種會把「研究可以停下來」說成「問題已經解決」，後一種會把「目前沒有答案」說成「已經安排好了誰來回答」。九項的狀態並不相同：有些問題已經知道應該從什麼方向繼續追問，有些甚至連下一步應該建立什麼都還不能確定。但無論屬於哪一種，它們首先都是當前證據的邊界，而不是等待執行的工作清單。

研究停下來，不等於問題都解決了

一項研究能夠停下來，並不意味著所有問題都已經有了答案。還有另一種停法：已經知道哪些問題解決了，哪些問題仍然沒有答案，也知道為什麼現在不能繼續往前；與此同時，已經看到的問題仍然可以由現有結構解釋，沒有新的問題迫使我們再增加一個基本結構。

這本書停在的就是這個位置。但這裡必須守住一個很重要的區別：能被解釋，不等於結構被證明。

現有結構能夠容納已經看到的問題，只能說明到目前為止，還沒有出現必須靠一個全新基本結構才能解釋的東西。它不能進一步證明現有結構已經完整，也不能證明這些結構之間的關係已經最終確定。一個體系暫時沒有遇到解釋不了的問題，和這個體系已經是最終答案，是兩件完全不同的事。

所以這裡不會給出一句「體系已經閉合」。能夠結束的，只是這一階段的研究，而不是問題本身。

前面的結構已經足以讓我們繼續工作，後面仍然有問題沒有答案。這兩件事可以同時成立。第二十章要做的，就是把這些仍然沒有答案的問題留下來，而不是為了讓全書看起來完整，替它們補上一個現在還沒有依據的答案。

沒有答案，不等於遺漏

接下來的九項，都是這套結構裡還沒有得到答案的問題。但沒有答案，和問題被遺漏，是兩回事。

一個真正被遺漏的問題，往往連它的存在都沒有被意識到。這裡的九項不是這樣。我們已經知道問題出在哪裡，也知道現有依據為什麼只能走到那裡。每一項都有一個明確的停止點：不是因為不想繼續回答，而是繼續往前以後，答案就不再來自已經建立的東西，而需要加入現在還沒有依據的新判斷。

所以，這九項更準確地說，是當前證據的邊界。邊界以內，可以明確說什麼；走到邊界以後，哪些話暫時不能說，也同樣應該明確。一個看起來合理的答案，並不會因為它讓體系更完整，就自動變成一個已經成立的答案。

這一區分很重要。因為一個尚未回答的問題一旦被提前當成已解決，它就可能悄悄變成後續判斷的前提。原本沒有確定的關係，會被當成已經確定；原本還不能使用的判據，會開始支撐新的結論。最後的問題就不再只是某一處答案不夠準確，而是後面的推理建立在了一個從未真正成立過的基礎上。

同樣重要的是，這九個「沒有答案」也並不是同一種未知。有的是已有說法之間的關係還沒有確定，有的是一個概念本身尚未建立，有的是已經看見需要新的表達方式，卻還不能開始設計，還有的是現有結構已經有了輪廓，但證據仍不足以把它固定下來。

因此，下面不會把它們統稱為一句「有待進一步研究」。每一個問題為什麼停下來，就按它真正停下來的原因分別說明。這樣留下的不是一張待辦清單，而是一條清楚的邊界：哪些已經知道，哪些還不知道，以及我們究竟知道自己不知道什麼。

處置語義：兩套說法，沒有一句話說明它們的關係

第一項是處置語義。現在存在兩種不同粒度的結果表達：一種只區分是否通過，另一種則保留更多不同的處置結果。問題不在於哪一種更細，而在於兩者之間的關係還沒有建立。

一個粗粒度的「不通過」，是否等於另一種表達裡的某一種拒絕？更細的結果是不是對「不通過」的進一步拆分？還是說，兩套表達本來就在不同層次上描述不同的事情？這些問題目前都沒有答案。

因此，現在不能為了讓系統看起來更整齊，就把它們合併成一套統一的結果語義。只要兩者之間的關係沒有建立，任何統一都會額外引入新的判斷：哪些結果可以視為相同，哪些差異可以忽略，哪些結果應該被歸入同一種拒絕。現有結論還不足以支持這些判斷。

這不是一個單純的命名問題。只要不同位置對結果的含義還沒有取得共同語義，就不能默認一個位置給出的結果，到了另一個位置仍然代表完全相同的意思。

所以這一項只能停在這裡：不同的處置結果可以被區分，但它們之間還不能被整理成一套已經確定的共同語義。

這層關係一旦未來被真正建立，前面所有與拒絕有關的結構也可能需要隨之重新表達。

放大：一項在兩個證據層上對不上的觀察

第二項是「放大」這一觀察所留下的一個分歧。從機制本身去看一個問題，和從實際失效過程去看它，「放大」呈現出的重要程度並不一樣。有時它在機制描述裡並不突出，但到了真實的失效過程中，又會變得很難忽略。

這裡真正的問題不是哪一邊出現得更多，而是：為什麼同一個現象，在兩種觀察方式下會顯得如此不同？

這個問題不能靠數量來回答。一個現象出現得更多，並不能直接證明它具有更高的結構地位；出現得更少，也不能證明它只是次要因素。造成這種差異的原因可能很多：材料本身是怎樣選擇的，哪些失效被拿來觀察，觀察問題時採用了什麼層次，甚至一種現象在不同視角下是否容易被單獨看見，都可能改變最後呈現出來的結果。

現在的問題在於，這些解釋都還不能被排除。我們因此只能確認差異確實存在，卻還不能確定差異究竟來自「放大」本身，還是來自觀察它的方式。

所以這一項繼續保持開放。我們已經看見了不一致，但還沒有足夠依據解釋這種不一致。 在這之前，不能因為它在某一種觀察中更加突出，就把它提升成一個已經確定的結論；也不能因為它在另一種觀察中不夠突出，就把它忽略掉。

關係狀態：一個被接受但不許開始設計的模型

第三項是關係狀態。現在的問題是，簡單地把一段關係寫成「存在」或者「已經斷開」，已經不足以描述執行控制真正遇到的情況。

一段關係可能從來沒有建立過，也可能曾經有效、後來才失效；它是否仍然有效，可能取決於系統邊界怎樣劃定，也可能隨著當前狀態發生變化。除此之外，還必須能夠區分兩件完全不同的事情：組件本身發生了故障，和系統只是進入了一個原本就被允許的狀態。

這些差異說明，我們最終需要一種比簡單二元判斷更豐富的關係狀態表達。

但問題也只能走到這裡。知道現有表達不夠，不等於已經知道新的模型應該是什麼。 目前能夠確定的，只是未來的表達至少必須容納這些差異；至於它究竟應該有哪些狀態、這些狀態之間是什麼關係、應該怎樣命名和組織，現在都沒有足夠依據。

因此，這裡不會提前畫出一個模型，再等待後面的證據去填它。那樣做實際上已經把一個尚未回答的問題，偷偷變成了一個既定答案。

這一項留下的結論很有限，但也很明確：現有的關係表達不夠，而新的關係狀態模型現在還不能被定義。

「不需要實質變化」：四件必須先說清的事

第四項是一條現在還不能直接使用的判據。它問的是：一次失效發生時，是否存在某種本來應該發生、但實際上沒有發生的實質變化。

這個問題看起來簡單，實際上至少依賴四個前提：

1. 系統邊界劃在哪裡。 哪些東西算系統的一部分，哪些算系統之外，會直接改變我們對「有沒有發生變化」的判斷。同一個事件，在一種邊界劃法下可能表現為系統內部沒有變化；換一種邊界劃法，原本被放在外部的變化又會被計算進來。
2. 環境算不算系統的一部分。 如果環境不被計入，我們可能說「系統什麼都沒有變」；如果環境被計入，同一個事件就可能變成「環境已經發生變化，而系統沒有作出相應變化」。兩種說法觀察的是同一件事，卻會得到不同結論。
3. 觀察的時間範圍怎麼劃。 一段連續過程，從較長時間看可能存在明顯變化；切成更短的時間片以後，其中某些片段又可能表現為「沒有發生變化」。如果時間範圍沒有規定，「有沒有實質變化」本身就沒有穩定的答案。
4. 怎樣區分組件故障和被允許的狀態變化。 一個狀態發生改變，並不能單獨告訴我們它是組件壞了，還是系統按照規則正常進入了另一個允許狀態。反過來也一樣，一個值沒有按照預期改變，也不能在沒有進一步條件的情況下直接說明發生了哪一種失效。

這四件事不是細節，它們決定了這條判據究竟在判斷什麼。只要邊界、環境、時間範圍或者狀態變化的性質沒有規定清楚，同一個事件就可能因為觀察方式不同而得到不同答案。因此這裡有一條必須守住的限制：

在這四件事被規定清楚之前，「不需要實質變化」不得用於任何結構性論證。

這不是說這條判據一定錯誤，而是說它目前還沒有穩定的使用邊界。不能先拿一個邊界尚未確定的判據去證明某種結構成立，再把判據自己的邊界留到以後解決。

其中第四個問題——組件故障與被允許的狀態變化如何區分——也與上一節的關係狀態問題相連。同樣的區分也出現在關係狀態表達必須面對的問題中，但這種關聯本身並沒有替任何一邊給出答案。

所以這一項現在能夠給出的結論非常明確：四個前提沒有說清之前，這條判據不能承擔結構性判斷。

四個沒有被凍結的結構

第五項不是一個問題，而是四個仍然不能被確定下來的結構。它們共同的地方只有一個：都已經看見了問題，但現有依據還不足以把它們寫成已經成立的結構。至於為什麼不能確定，四項各不相同。

第一項，是判斷資格與因果能力之間的錯位。

誰有資格作出一個判斷，和誰真正有能力讓一件事發生，並不天然是同一個問題。一個主體可能有資格判斷，卻沒有讓動作成為現實的能力；另一個位置可能真正控制著動作能不能發生，卻並不承擔前面的判斷。

這種錯位已經能夠被觀察到，但現在還不能進一步確認：這些表現是否足以構成一個邊界穩定、可以獨立使用的結構。因此它可以繼續作為一個重要問題存在，卻不能被提前寫成已經確定的結構。

第二項，是拒絕能力與拒絕的實際效力之間的不一致。

系統擁有一個「拒絕」的位置，不代表這個拒絕一定能夠真正阻止動作發生。是否存在拒絕能力，和這個拒絕在具體執行鏈上是否最終有效，是兩件不同的事。

問題在於，我們現在還不能完整說明，一個拒絕在什麼條件下才算真正具有阻止現實執行的效力；已經看到的失效方式，也還不能被現有描述完整收住。因此，「有拒絕能力，但拒絕可能不起作用」這個問題已經明確，但它的結構邊界還沒有穩定下來。

第三項，是認識狀態被轉換成執行資格。

執行一個動作通常依賴一些關於現實世界的事實判斷。問題出現在這些事實還沒有被真正確立的時候：系統卻已經把某種「認為如此」「假定如此」或者「暫時沒有發現問題」繼續向下傳遞，並最終產生了執行資格。

這種現象並不是偶然才會被看到，它已經形成了足夠強的現實壓力。但反覆出現本身仍然不能證明它已經取得了一個獨立結構的地位。

這裡必須守住一個區別：案例能夠告訴我們一個問題值得重視，但案例出現得多，不能自動把一個觀察凍結成理論結構。

第四項，是控制前提與信任起點沒有受到同等約束。

執行控制會檢查 Action、授權、狀態、規則和最終裁決，但這些判斷本身也依賴一些更早的前提：某種能力是否真的存在，某個事實從哪裡來，某個條件是怎樣被建立起來的。

如果最終動作受到嚴格約束，而建立這些前提的過程本身沒有受到同等程度的約束，那麼控制邊界實際上仍然可能建立在一個未經同樣檢查的起點上。

目前已經能夠把這個問題收窄到兩個方向：一是控制所依賴的能力是否真實可得，二是那些被當作前提的條件究竟是怎樣建立起來的。但現在還沒有足夠依據，把這兩部分進一步固定成一個完整而穩定的結構。

所以，這四項現在都必須保持在同一個邊界上：它們可以被討論，可以繼續被觀察，也必須在後續分析中保持可見，但不能被寫成已經成立並可以繼續往上疊加的正式結構。

「目前最好的描述」和「已經確定的結構」不是一回事。這裡保留前者，不把它提前寫成後者。

「證明」這個詞還沒有定義

第六項很短，但它擋住的問題並不小。這本書已經反覆使用「證明」這個詞，但到目前為止，它在這套體系裡還沒有一個正式定義。

這件事直接影響一個更重要的問題：證據與證明之間到底是什麼關係。

Evidence 已經承擔了相對明確的工程作用：它記錄什麼發生過、什麼狀態被看見、什麼條件被滿足，以及這些事實怎樣被驗證。但如果 Proof 本身還沒有定義，那麼現在就不能進一步斷言：Evidence 就是 Proof，Evidence 構成 Proof 的一部分，或者 Proof 是比 Evidence 更高一層的對象。

這些說法聽起來都可能合理，但「聽起來合理」還不夠。不能用一個尚未定義的對象，去吸收一個已經相對明確的對象。 如果這樣做，結果不是把理論變得更完整，而是把原本已經清楚的 Evidence 也一起變得模糊。

當然，也可以從別的理論體系裡借一個「證明」的定義進來。但那樣解決的是另一套體系裡的問題，不等於這本書自己的 Proof 已經獲得了定義。只要這個定義不是從現有執行控制結構內部建立出來的，就不能拿它反過來決定 Evidence 應該處在什麼位置。

所以這裡現在只能停在一個很明確的邊界上：Evidence 已經是一個可以討論和使用的對象，但 Proof 還不是一個已經定義、可以承擔結構性工作的正式對象。

在 Proof 被正式定義之前，二者之間的關係不能被提前確定；更不能為了讓概念體系看起來完整，就讓一個尚未定義的詞去重新解釋已經建立的 Evidence。

一條合取規則，掛在哪一層

第七項不是規則本身有沒有成立，而是這條規則到底應該由哪一層承擔。

規則已經很明確：一次執行所依賴的必要條件必須同時成立。只要其中任何一個關鍵條件沒有滿足，執行就不能繼續。一個條件成立，不能補償另一個條件的不成立；多數條件成立，也不能把剩下的那個「否」變成「是」。

真正沒有答案的是：**誰負責把這條規則落實到最後。**一種可能的位置是仲裁層，也就是在形成這一次執行判斷時，就要求所有必要條件同時成立。另一種可能的位置，是最終執行裁決權的實現層，也就是在現實動作真正發生之前，由最後一道執行邊界保證這條規則仍然成立。

現在還不能在這兩個位置之間作出選擇。原因並不是兩者名字不同，而是這裡涉及的是最終責任歸屬：當某一個必要條件不成立時，究竟由哪一層對「不得繼續執行」承擔最後責任。只要這一點沒有確定，就不能為了讓架構看起來完整，提前把規則掛到其中任何一層。

這裡尤其要避免一個很容易出現的誤區：規則本身已經成立，不等於規則的歸屬也已經成立。

我們現在知道的是：

所有必要條件必須同時滿足；任何一個關鍵條件不滿足，執行都必須停止。

我們還不知道的是：

最終由哪一層負責保證這件事。

所以這一項必須停在這裡：規則已經有了，責任位置還沒有。

多個否決放在一起：一個共同的缺口

第八項很容易讓人誤以為已經解決了，因為關於「否決」本身，我們其實已經知道一些重要的事情。

已經能夠確定的有三件：

1. 多個必要約束可以同時限制同一次 Action。
   一次執行並不一定只受一個條件控制，多個彼此獨立的必要約束可以同時存在。

2. 只要一個仍然有效的必要負向約束沒有滿足，受保護的執行就不應繼續。
   其他條件已經成立，並不能自動補償這個缺口。

3. 多個正面的放行，不能自動消除一個獨立成立的阻止。
   「允許」出現得再多，也不能因為數量更多，就讓另一條仍然有效的否決自動失效。

但是，一旦問題從「一個否決是否有效」變成「多個否決怎樣共同作用」，答案就沒有了。

現在還沒有建立的至少有七件事：

1. 是不是每一個必要條件都構成一次獨立的否決。
2. 多個否決之間是否存在優先級。
3. 是否存在類似法定人數這樣的數量要求。
4. 多個否決應該怎樣聚合。
5. 如果不同否決之間出現衝突，應該怎樣處理。
6. 否決的失效、到期和撤銷應該怎樣共同作用。
7. 多個拒絕之間究竟存在什麼樣的組合關係。

這七個問題現在都沒有答案。還必須再區分一件事：多個否決，不等於多個策略拒絕。

多個 Veto 與多個 Policy Deny 不是同一個問題。兩側目前建立到的程度也不同，因此不能因為它們都與「阻止」或「拒絕」有關，就把一側已經成立的結論直接搬到另一側。

因此，我們現在既不能說多個 Veto 已經有了一套完整的組合規則，也不能說多個 Policy Deny 已經有了一套聚合規則，更不能假定二者最終會共享同一種組合方式。

這裡留下的不是一處衝突，而是一個共同的缺口。如果是衝突，意味著兩邊已經分別有了答案，只是答案彼此不兼容；這裡不是這樣。這裡真正的問題是，兩邊都還沒有建立足夠完整的組合關係。

所以不能為了讓結構看起來閉合，就替它補上一套優先級、投票、聚合或者衝突解決規則。現在真正能夠確定的邊界只有：

單個否決可以成立，多個約束可以同時存在；但多個否決以及多個拒絕究竟怎樣組合，目前還沒有答案。

十二種形態，不能整理成一張表

第九項來自一個很直接的變化。

當研究只覆蓋八個案例時，已經觀察到八種不同的否決與拒絕失效形態；案例增加到十一個以後，觀察到的形態不是十一種，而是十二種。

也就是說，形態數的增長快於案例數。

這個變化很重要，因為它說明我們現在看到的還不是一個已經穩定下來的分類空間。在這一次案例範圍擴展中，新增案例沒有隻重複已有形態，還暴露出了原有描述沒有完整覆蓋的東西。

事實上，前面使用過的「否決的可達性與有效範圍失效」這一描述，只能完整覆蓋目前十二種觀察形態中的兩種，對另外一些形態也只能部分解釋。它能夠描述這個問題的一部分，卻還不足以成為完整的分類結構。

更重要的是，「拒絕是否有效」本身也不是一個簡單的二值判斷。一種極端情況是：拒絕動作確實發生了，但它真正產生的物理作用方向卻與預期相反。

另一種極端情況是：否決原本是可達的、及時的、處在有效範圍內，也確實有能力阻止執行，但最終卻被否決的持有者自己收回。

這兩個極端已經足以說明，僅僅把拒絕寫成「有效」或者「無效」，會丟掉中間非常重要的結構差異。否決能力可以存在，卻以不同方式失去它原本應該產生的作用。

所以，這裡的問題不是把現有十二種形態整理得更漂亮，而是我們還沒有足夠依據確認：這十二種是不是一個完整集合，它們之間應該怎樣劃分，又哪些只是同一問題的不同表現。

因此，當前不能把它們凍結成一套正式分類。

這裡保留的只有三個結論：

第一，拒絕能力本身存在多種不同的失效形態。

第二，現有描述只覆蓋其中一部分，尚不足以構成完整結構。

第三，隨著案例增加，新的形態仍然被觀察到，因此當前證據還不足以證明這套形態已經窮盡。

所以這一章不會把十二種形態逐項列成一張表。不是因為它們不重要，恰恰是因為現在把它們排成一張完整清單，會給讀者一種並不存在的確定性。

這項問題目前只能停在這裡：我們已經知道拒絕能力的失效遠比「有或者沒有」複雜，但還沒有資格把這種複雜性凍結成一套最終 taxonomy。

另一組不能與九項合併的未決問題

前面的九項已經說完了，但還有另一組問題需要保持可見。這裡首先要避免一個誤解：這不是在九個問題後面再增加六個問題，也不能因此把本章理解成一共有十五個未決問題。

原因是兩組問題的組織方式不同。前面的九項，是圍繞執行控制結構本身收束出來的未決問題；這一組關注的，則是這套體系在進一步形式化時仍然留下的缺口。兩個視角並不相同，所以它們會發生交叉：有些問題會同時出現在兩組裡，有些則只屬於其中一組。

這一組目前包含以下問題。第一，邊界獨立性的形式定義，與更早使用的判據之間仍然存在強度落差。

我們已經有了對邊界獨立性的形式表達，但更早的判斷方式可能要求得更強。兩者之間究竟應該怎樣對齊，現在還沒有答案。因此這裡不能為了統一表達，直接削弱其中一邊，或者把兩者假定成完全等價。

第二，災難半徑怎樣度量，以及怎樣由此形成風險分級，還沒有正式歸屬。

一次失效最終能夠影響多大範圍，是一個真實存在的問題。但影響範圍怎樣度量、不同範圍怎樣形成風險等級，以及這條分界應該依據什麼建立，目前都沒有形成正式結構。

所以災難半徑可以說明為什麼某些控制需要被分離，卻還不能被直接拿來產生一套風險分級標準。

第三，「證明」仍然沒有定義。

這一項已經在前面的九個問題中出現過。只要 Proof 本身還沒有正式定義，Evidence 與 Proof 之間的關係就不能被提前確定。

第四，最終否決與策略收斂仍然缺少完整的正式概念地位。

它們在本書中承擔了真實而重要的作用，也反覆被使用，但「被使用」與「已經成為一個完成定義的正式對象」並不是同一件事。不能因為這些概念已經在本書中被反覆使用，就反過來假定它們在形式理論中的位置也已經完全確定。

第五，關係狀態模型還沒有被定義。

這一項同樣已經出現在前面的九個問題中。我們已經知道簡單的二元關係表達不夠，但新的關係狀態模型究竟應該是什麼，現在仍然不能提前設計和凍結。

第六，那條合取規則最終應該由哪一層承擔，還沒有答案。

規則本身已經成立：任何一個必要條件不滿足，執行就不能繼續。但最終由哪一層負責保證這一點，仍然沒有確定。這也是前面九項中的一個未決問題。

因此，這兩組問題之間存在三處直接重合：「證明」沒有定義，關係狀態模型沒有建立，以及合取規則的層歸屬沒有確定。

另外三個問題——邊界獨立性的定義落差、災難半徑與風險分級、以及最終否決與策略收斂的正式概念地位——並不在前面的九項之內。

所以這裡不能做簡單加法。它們不是十五個彼此獨立的問題，也不能因為存在重合，就被壓縮成同一張九項清單。

兩組問題只是從不同角度照到了同一個尚未完全形式化的體系。重合的地方必須承認重合，不同的地方也必須繼續保持可見。

這不是為了讓未決問題顯得更多，而是為了避免一個問題因為已經在另一張清單裡出現過，就在這裡被誤認為已經解決。

名義上的獨立

最後還剩一個問題。它來自一句必須嚴格保持為否定形式的判斷：

名義上的獨立，不蘊含失敗來源上的獨立。

這句話並不試圖定義什麼才叫真正的獨立。它只排除一個很容易發生的推理：把兩個結構分開設計、分開部署、分開承擔職責，並不能僅憑這些事實，就證明它們在失敗的來源上也彼此獨立。

這一區別放在整本書的最後尤其重要。前面的章節一直在做一件事：把一次 Action 真正進入現實之前所需要的條件逐層拆開。意圖不能直接等於執行，授權不能因為曾經成立就永久有效，狀態必須在當前時點重新成立，多個約束不能被隨意抵消，裁決必須發生在現實動作之前，而即使正向條件全部成立，仍然可以有一個有效的否決阻止執行。

這些結構之所以被分開，就是為了避免一個判斷、一份授權或者一個組件獨自擁有從意圖一路通向現實結果的全部權力。

但結構被分開，不意味著風險來源也已經被分開，因為這些邊界最終仍然要由現實中的東西來承載。作出判斷的是人或者系統，而它們可能出錯；表達約束的是規則，而規則可以被修改；實現邊界的是組件，而組件可能失效或者被控制。這些結構所處的環境也並不可靠，時間、網絡、外部服務和其他現實條件都可能發生變化。

於是問題發生了變化。前面整本書問的是：

**在這些結構能夠正常承擔各自職責的前提下，一次 Action 要獲得進入現實的執行效力，究竟必須滿足什麼條件？**這個問題，本書已經給出了答案。現在出現的是另一個問題：

當這些結構中的一部分已經失效、或者已經被控制的時候，這些邊界是否仍然成立？

這個問題不能靠把前面的答案重複一遍來解決。前面的結構告訴我們，正常情況下應該把哪些東西分開、在哪些位置重新檢查、什麼條件缺失時必須停止。但如果承擔檢查的主體本身已經不可信，如果表達邊界的規則已經被改寫，如果執行邊界所在的組件已經失陷，那麼問題已經不再只是「條件有沒有滿足」，而變成了「我們憑什麼相信那個負責判斷條件是否滿足的邊界本身」。

到了這裡，繼續向前就需要另一組證據和另一種問法，所以本書停在這裡。它不會為了得到一個更完整的結尾，就假定這些結構在失陷條件下仍然有效；也不會因為已經建立了一套執行控制結構，就把這套結構本身當成新的可信起點。

這不是對前面結論的否定，恰恰是在給它劃清最後一條邊界。

一次具體的 Action，在現實動作發生之前獲得執行效力所需要的條件，已經建立。

這些條件所依賴的主體、規則、組件和環境本身開始失效時，前面的邊界是否仍然成立，還沒有答案。

前一個問題是《執行控制工程》完成的工作，後一個問題仍然開放。

本章術語

• 執行控制 ｜ Execution Control
• 動作 ｜ Action
• 處置語義 ｜ Outcome Semantics
• 放大 ｜ Amplifier
• 關係狀態模型 ｜ Relation-State Model
• 證據 ｜ Evidence
• 證明 ｜ Proof
• 否決 ｜ Veto
• 策略拒絕 ｜ Policy Deny
• 名義獨立 ｜ Nominal Independence
• 失敗來源獨立 ｜ Failure-Source Independence

本章的術語部分有一個特殊邊界：一個名稱能夠被準確說出來，不等於它所指向的對象已經獲得完整定義。

Execution Control 與 Action 繼續按照前文已經建立的含義使用。本章不重新定義它們。這裡討論的仍然是一次具體 Action 在獲得現實執行效力之前，哪些條件已經能夠被確定，哪些關係仍然沒有答案。

本章用 Outcome Semantics 指代「不同處置結果之間究竟是什麼關係」這一尚未解決的問題。當前能夠確認的是，現有表達中同時存在不同粒度的結果語義；但這些表達之間究竟是什麼關係，目前沒有建立統一答案。因此，本章不建立統一的 ALLOW / DENY / HOLD，也不把已有結果表達排列成一個封閉值域。

Amplifier 在本章中只用於指認一個仍然存在層間差異的觀察：從不同證據層觀察時，它表現出的顯著程度並不一致。這個差異不能靠出現次數決定，也不能因此把 Amplifier 提升為已經凍結的獨立結構。

Relation-State Model 是對未來關係狀態表達問題的指稱。現有的簡單二元關係表達已經不足以保留已經觀察到的狀態差異，但這並不意味著新的模型已經存在。本章只確認需要一種更豐富的表達，仍然保持「不設計、不命名、不凍結」的邊界。

「不需要實質變化」判據目前依賴四個尚未被統一規定的問題：系統邊界劃在哪裡、環境是否計入系統、時間範圍如何切分，以及組件故障與被允許的狀態變化如何區分。在這些前提被說清楚之前，這條判據不能承擔結構性論證。

Evidence 與 Proof 在本章不能被合併使用。Evidence 已經承擔明確的判斷依據角色，而 Proof 目前還沒有獲得足以承擔結構性工作的正式定義。因此，本章既不把 Evidence 直接稱為 Proof，也不判斷 Evidence 是否屬於 Proof 的組成部分。不能用一個尚未定義的對象去重新解釋一個已經相對明確的對象。

Veto 與 Policy Deny 也不能因為都表現為負向結果就被視為同一種東西。多個 Veto 怎樣共同作用仍然沒有完整答案，多個 Policy Deny 怎樣聚合也沒有建立；一側已有的結論不能直接搬到另一側。

最後，本章只保留一條關於獨立性的否定關係：

Nominal Independence does not imply Failure-Source Independence.

也就是說，結構在名稱、職責、部署或者邏輯位置上彼此分開，並不能僅憑這些事實推出它們的失敗來源也已經獨立。本書不進一步給出 Failure-Source Independence 的完整正面定義。

本章案例與資料來源

**本章沒有現實案例。**這不是案例缺失，而是本章的理論角色決定的結果。

如果給某一個未決問題綁定一個現實案例，很容易讓案例從用於說明問題變成答案依據，進而產生一種錯誤印象：這個問題雖然被稱為未決，其實已經能夠由經驗事件解決。

因此，本章不設置獨立案例，不展開公司、人物、事故、時間線或者具體事件事實鏈。

正文中仍然會出現少量來自此前案例研究的整體證據結果。例如，否決與拒絕失效形態在案例擴展過程中從八個案例對應八種觀察形態，發展到十一個案例對應十二種觀察形態。這裡使用的是此前案例研究形成的整體觀察結果，而不是重新講述其中任何一個案例。

這一結果只支持一個有限判斷：**當前觀察到的形態仍然不足以凍結成一套完整分類。**它不證明未來永遠不存在完整分類，也不允許把十二種形態整理成一張正式 taxonomy。

同樣，本章涉及的層間差異、案例覆蓋或者不同結構在案例中的出現情況，也只用於說明為什麼某些問題目前仍然必須保持開放。出現得更多，不等於理論地位更高；案例能夠持續暴露一個問題，也不等於案例已經證明這個問題應該被建立成獨立結構。

因此，本章不重新綁定此前已經使用過的現實案例，也不重複列出這些案例的一手資料。

具體案例及其官方報告、論文和其他資料，仍然保留在實際承擔這些案例的章節以及全書《參考文獻與資料來源》中。

第二十章只保留它們已經形成的研究結果，並嚴格限制這些結果能夠支持什麼、不能支持什麼。

這也與本章本身的結論一致：案例可以幫助我們看見問題，但不能替尚未建立的理論關係補出答案。

---

附錄一｜術語與用法

《執行控制工程》中的詞同樣不處於一個理論層級。第二冊比第一冊進入了更具體的工程結構，因此更容易出現一種誤讀：一個對象因為在工程上更具體，就被自動理解為已經完成正式定義。這個附錄的首要作用仍然不是“把所有詞定義得更完整”，而是標明每個詞在本書中已經成立到哪裡、能夠承擔什麼論證重量，以及哪裡必須停下。

本附錄繼承《執行縫隙》已經出版化的術語基線。共享概念不重新發明；Book I 已經凍結的中文名、英文名、最小定義與邊界繼續有效。Book II 只在研究材料明確支持的地方增加執行控制側的展開。

本附錄使用以下狀態：

正式概念——已在《執行控制工程術語規範》v0.1 中凍結，具有穩定的中英文名稱和最小定義。

跨書共享術語——已經在 Book I 附錄中建立使用基線，Book II 繼承該基線；它本身未必是正式概念。

Book II 理論術語——在《執行控制工程》的研究層已經承擔明確結構作用，但尚未因此進入正式概念層。

Book II 工程術語——用於描述執行控制中的角色、輸入、範圍或過程，含義受本書邊界限制，不自動獲得本體地位。

分析標籤 / 結構性稱呼——用於定位一種結構、關係或問題，不構成新的 ontology、taxonomy 或正式機制。

工作性稱呼 / 未決對象——對象已經出現，但名稱、定義、關係或層歸屬仍未凍結。本附錄只保留邊界，不替研究補答案。

普通工程術語——按通常工程含義使用，本書只限定它在執行控制中的作用，不另行建立一套理論定義。

結果值 / 狀態值——表示一次判斷或輸入質量狀態，不因為被系統使用就自動成為理論概念。

---

一、跨書共享術語

執行 ｜ Execution

狀態：正式概念；跨書共享

使表達、判斷與承諾進入現實狀態變化的上位過程。Book I 已經區分執行過程（Execution Process）與真正改變現實狀態的執行動作（Execution Act），並明確結果是獨立對象，不能由“動作已經發生”自動推出。

Book II 邊界：裁決與執行必須繼續分開。一個系統已經形成 Allow、Deny 或其他判斷，不表示現實執行已經發生；負責判斷的 Runtime 也不因此成為 Executor。

結果 ｜ Result

狀態：Book I 理論術語（內部結構未凍結）；跨書共享

結果與執行動作是不同對象。技術結果、外部狀態與業務結果可以被區分，但 Book I 沒有把三者凍結成正式分類，也沒有規定它們之間的層級、順序或推出關係。

Book II 邊界：本書同樣不建立統一的 Outcome Semantics。一次 Action 沒有發生，也不能僅憑外部結果反推出內部究竟發生了 No Allow、Explicit Deny、Capability-Level Refusal 還是 Final Veto。

放大 ｜ Amplification

狀態：分析標籤；跨書共享

描述一個已經存在的偏差如何因速度、規模、連續自動化、反饋、級聯或糾正機會減少而擴大。放大回答“已經形成的偏差為什麼變得更快、更大、更深”，不回答偏差最初為何取得現實執行效力。

Book II 邊界：研究材料在機制層與案例層對 Amplification 的分佈明顯不同，這一層間差異仍然未決。本書不把 Amplifier 另立為新的理論術語，也不以出現次數決定其結構地位。

不完美主體 ｜ Fallible Subject ／ 可錯性 ｜ Fallibility

狀態：正式概念；跨書共享

不完美主體是能夠理解、判斷、授權、調用、控制或執行 Action，但無法被證明未來每一次判斷都一定正確的主體。可錯性是工程屬性，不是道德判斷。

邊界：可錯不等於惡意、失陷、不可信或無責任，也不表示主體每次都會犯錯。Book II 的權威分解、分層不信任和執行控制都以這一前提為背景，而不是以尋找一個“永遠正確”的主體為目標。

意圖 ｜ Intent

狀態：正式概念；跨書共享

對希望發生之 Action、對象、參數、條件或結果的表達。Intent 即使真實、明確並具有來源，也不能自動推出最終執行或現實結果正確。

Book II 展開：Intent 在執行控制中承擔規範參照作用，但必須能夠被識別、引用、綁定與驗證。Intent 的來源不自動賦予 Authorization、Authority、Execution Qualification 或最終執行效力。

授權 ｜ Authorization

狀態：正式概念；跨書共享

判斷主體是否被允許擁有或使用某類能力的資格邊界。它回答的是“是否被允許擁有或使用某類能力”，不是“此刻這一次具體 Action 是否應當發生”。

邊界：Authorization 可以成為當前裁決的重要輸入，但不能替代當前 State、Evidence、Policy、Boundary 與執行資格的重新判斷。

權威 ｜ Authority

狀態：正式概念；跨書共享

在明確範圍內，對 Action、規則、State 或 Boundary 作出對系統具有約束力之決定的權力。

邊界：Authority 不等於 Permission、Authorization、Execution Capability 或組織頭銜。一個主體技術上做得到，不表示它擁有讓該動作獲得現實效力的 Authority；反過來，擁有某種 Authority 也不等於擁有現實實施能力。

策略 ｜ Policy

狀態：正式概念；跨書共享

表達執行判斷規則及其適用條件的對象。Policy 可以提供規則側輸入，但不是事實來源，也不是最終執行裁決權本身。

Book II 展開：多個 Policy、Constraint 與 Condition 可能需要形成當前 Action 的有限規則側範圍；這一過程屬於 Policy Convergence，而不是把單個 Policy 升格為 Final Authority。

狀態 ｜ State

狀態：正式概念；跨書共享

特定時點與某次 Action 能否被判斷和執行直接相關的事實與條件集合。State 不是整個數據庫，也不是某個系統快照的同義詞。

Book II 展開：過去的 Authorization、Policy 或 Judgment 仍然有效，不等於當前 State 沒有變化。執行控制判斷必須面對當前事實，而不能把代理記錄、命令狀態或歷史快照自動當作現實本身。

資格 ｜ Qualification ／ 當前資格 ｜ Current Qualification

狀態：分析標籤；跨書共享

描述某個主體、對象或 Action 是否滿足已經建立之條件。Book I 已經強調“當前”：資格曾經成立，不能自動證明它對此刻這一次具體 Action 仍然成立。

Book II 展開：本書使用 Execution Qualification 指向一次具體 Action 在當前條件下繼續進入現實執行所需的資格狀態；它不是 Authorization 的同義詞，也不是 Execution Capability。

執行邊界 ｜ Execution Boundary

狀態：正式概念；跨書共享

在 Action 成為現實之前對其進行最終約束，並能夠真實允許或阻止現實副作用的邊界。

邊界：存在一個“檢查點”、服務、進程或硬件不等於存在 Execution Boundary。邊界必須能夠對現實執行路徑產生約束；如果受約束主體能夠無條件關閉、重寫或繞過它，僅憑部署位置不能建立獨立性。

證據 ｜ Evidence

狀態：正式概念；跨書共享

支持關於執行條件、判斷、Boundary State 或執行結果之可驗證事實的材料。

Book II 展開：必須保持三者分離：被證明對象 ≠ Evidence ≠ 基於 Evidence 作出的 Judgment。Evidence 不創造事實、不替系統作裁決，也不自動產生 Authority 或 Execution Qualification；Log、Record、Signature、Receipt 可以成為載體或輸入，但載體不自動等於 Evidence 角色。

回執 ｜ Receipt

狀態：普通工程術語；跨書共享

來自外部來源、關於請求是否被接收、處理或返回某種狀態的聲明。歷史術語考古繼續使用“回執 ｜ Receipt”，並明確 Receipt 只能證明其語義覆蓋的局部結果。

邊界：回執不等於最終業務結果，也不等於完整 Execution Evidence 或 Evidence Continuity。本書不另立“收據 ｜ Receipt”作為第二個術語。

災難半徑 ｜ Blast Radius

狀態：正式概念；跨書共享

一次錯誤、失陷或不受約束執行可能造成的最大現實影響範圍。

邊界：Blast Radius 不是發生概率、攻擊面、事故嚴重度或實際損失的同義詞。Book II 不建立統一的災難半徑度量或風險分級模型。

必要條件 ｜ Necessary Condition

狀態：普通工程術語；跨書共享

Book II 中它被用於一條明確的合取方向：一次執行所依賴的必要條件必須同時成立；任何關鍵必要條件沒有建立，其他條件的成立不能自動補償它。

未決：這條合取規則最終應該由 Arbitration layer 還是 Final Execution Authority realization layer 承擔，當前沒有答案。

人工逐筆審批 ｜ Per-Action Human Approval

狀態：Book I 結論用語；跨書共享

指每一次具體 Action 獲得現實效力之前，都必須等待一次人工確認，並把這次人工確認本身作為動作繼續發生的最終依據。

Book II 結論：Execution Control ≠ Per-Action Human Approval。人工確認可以存在，也可以在特定場景成為必要步驟，但“有人確認”與“人工確認擁有最終執行效力”是兩個問題。成熟的執行控制應減少不必要的人類介入，而不是把安全定義為所有 Action 都必須由人逐筆點一下。

---

二、Book II 正式概念與核心工程對象

執行控制 ｜ Execution Control

狀態：正式概念

當具體 Action 即將改變現實狀態時，基於當前 State、參數、Authority、Policy、Boundary 與 Evidence，判斷該 Action 是否仍滿足執行條件，並使這個判斷能夠真實約束現實執行。

邊界：Execution Control ≠ Access Control；≠ Authorization；≠ Approval；≠ Policy；≠ Human Confirmation；≠ Post-hoc Audit。判斷只停在日誌或建議層、控制點可被旁路、輸入不是當前事實，都不能據此聲稱執行控制已經成立。

執行前控制 ｜ Pre-Execution Control

狀態：正式概念

在現實副作用發生之前，依據當前 State、Policy、Authority、Boundary 與 Evidence 決定 Action 是否可以繼續，並能夠真實限制、延遲或拒絕執行的控制形式。

邊界：它是 Execution Control 的重要下位形式，但不等於整個 Execution Control。它也不是“越靠近執行越晚越好”的時間概念，而是一個因果位置：現實副作用尚未發生，拒絕仍然能夠改變這一次動作是否到達現實。

執行能力 ｜ Execution Capability

狀態：正式概念

主體、組件或路徑使某類現實 Action 實際發生的能力。它描述真實副作用能力，不等同於 Identity、Access、Permission、Approval 或每次使用的 Execution Qualification。

邊界：Capability ≠ Authority。能力存在不表示本次 Action 已獲 Authorization、最終裁決為 Allow，或當前動作應當發生。

最終執行裁決權 ｜ Final Execution Authority

狀態：正式概念

對一次具體 Action 輸出具有約束力的 Allow 或 Deny 裁決之 Authority。Allow 只釋放繼續執行的資格，不親自實施現實動作；現實實施屬於獨立 Executor。

Book II 重要邊界：Final Execution Authority 不要求由一個人、一個模塊或一個組件單獨持有。研究層已經接受其可由多個彼此獨立、各自必要的約束共同形成，但沒有建立完整的形式關係模型。

權威分解 ｜ Authority Decomposition

狀態：正式概念

圍繞現實執行，把不同 Authority 放入不能自動繼承、替代或覆蓋的獨立邊界中所形成的穩定結構。

邊界：Authority Decomposition ≠ 多幾個人；≠ 多籤；≠ 微服務拆分；≠ 組織架構；≠ 多幾層審批。判斷分解是否有意義，要看在聲明的威脅模型下，允許失陷的主體集合是否仍能獨立閉合從意圖到現實改變的因果鏈。

執行權分離 ｜ Execution Authority Separation

狀態：正式概念

把提議、審批、仲裁、最終裁決、現實實施和證明等執行相關 Authority 置於不能相互自動替代的邊界中，使任一單一角色都不能自然獲得完整執行權。

邊界：它是 Authority Decomposition 的下位結構，不等於普通職責分工、多人審批、進程分離或部署隔離。

信任 ｜ Trust

狀態：正式概念

在特定執行判斷中，系統允許某個主體、組件或事實來源承擔某類判斷作用的有限假設。

邊界：Trust ≠ Correctness；≠ Good Intent；≠ Permanent Reliability。信任必須有對象、範圍、作用與失陷邊界，並且不能因為一次成立就無限傳遞。

信任域 ｜ Trust Domain

狀態：正式概念

一組共享關鍵控制、信任假設或共同失陷路徑的主體與組件邊界。

邊界：不同節點、進程、副本、產品平面或網絡分區不自動構成多個獨立 Trust Domain；如果共享身份、權限、更新、恢復或通信控制根，名義上的多個組件仍可能屬於同一失陷來源。

分層不信任 ｜ Layered Distrust

狀態：正式概念

不假設任一單層主體、組件或控制面永遠正確，並讓不同層保留相互限制之邊界的工程結構。

邊界：Layered Distrust 不等於 Zero Trust 或 Defense in Depth，也不意味著“什麼都不信”。它要求的是有限信任與相互約束，而不是層數本身。

運行時 ｜ Runtime

狀態：正式概念

接收明確輸入並對具體 Action 作出確定裁決的邏輯裁決環境或抽象裁決角色。它必須終止、可驗證、可解釋、輸入輸出明確，並原則上不得產生業務副作用。

邊界：Runtime adjudicates; Runtime does not execute external actions。它不是 HAVENLON 服務、硬件、daemon、編程語言 runtime 或任意業務邏輯容器，也不是 Final Execution Authority 本身。

邊界獨立性 ｜ Boundary Independence

狀態：正式概念

一個控制邊界的成立，不依賴於其所約束主體能夠同時關閉、重寫或繞過該邊界的性質。

邊界：不同進程、節點、服務、機房或副本只證明名義分離，不自動證明失敗來源獨立。當前研究只建立了明確的否定邊界，沒有給出“失敗來源獨立由哪些充分條件構成”的完整正面定義。

治理 ｜ Governance

狀態：正式概念

決定執行規則、角色、閾值、State 及其變更與恢復條件的受約束過程。治理能夠改變未來 Execution Boundary，但不等於每一次現實執行。

Book II 邊界：本書只在“誰能夠改變未來 Authority / Boundary / Policy 前提”處與 Governance 形成有界接口，不在這裡展開完整治理流程、角色、閾值或恢復理論。

安全失敗 ｜ Fail-Secure

狀態：正式概念

當必要執行條件、State、Evidence 或 Boundary 無法被充分證明時，不允許系統把不確定性轉化為現實執行的上位執行語義；其默認方向是收縮受保護的現實執行能力，而不是擴大執行許可。

邊界：Fail-Secure ≠ Explicit Deny；≠ Final Veto；≠ Shutdown；≠ Safe Mode；≠ All Functions Disabled。Fail-Secure 規定的是失敗方向，不是統一 decision value、Authority holder 或單一運行模式。

---

三、Book II 理論術語、角色與分析結構

身份 ｜ Identity

狀態：普通工程術語

用於回答“請求或主體是誰”。Identity 可以成為執行判斷輸入，卻不能僅憑身份真實就推出 Authorization、Authority、Execution Qualification 或現實執行正確。

權限 ｜ Permission

狀態：普通工程術語

描述主體在既定規則下可以訪問或操作什麼。Permission 與 Execution Capability、Authorization、Authority 必須分開；“有權限”不能自動回答“這一次 Action 現在是否應當發生”。

審批 ｜ Approval

狀態：普通工程術語

表示某個上游流程對 Intent 或 Action 候選表達同意、拒絕或條件性意見。Approval 可以是重要輸入，但不會因為流程完成就自動取得最終現實效力。

裁決 ｜ Adjudication

狀態：Book II 工程術語

把與當前 Action 相關的明確輸入帶入同一次判斷，並形成確定的約束性結果。Adjudication ≠ Execution；承擔裁決職責的邏輯位置也不因為“作出判斷”就自動獲得新的 Authority。

非單一持有者權威 ｜ Non-Single-Holder Authority

狀態：Book II 理論術語

用於表達 Final Execution Authority 不必歸屬於單一 holder。多個彼此獨立、各自必要的約束，可以共同形成對同一 Action 有約束力的最終裁決結構。

邊界：這不是“多數表決”“多籤”或“人越多越安全”的同義詞，也沒有建立完整的形式關係模型。

執行者 ｜ Executor

狀態：歷史凍結工程角色（T216）；Book II 工程術語

在最終驗證之後實施真實狀態變化、但不決定業務目標和治理規則的角色或組件。

命名邊界：歷史術語總表凍結的是“執行者 ｜ Executor”。“執行器”可以在具體實現語境中作為普通組件稱呼，但本附錄不把它建立為第二個與 Executor 並列的理論術語。

執行資格 ｜ Execution Qualification

狀態：Book II 理論術語

指一次具體 Action 在當前 Intent、State、Authority、Policy、Boundary 與 Evidence 條件下，是否已經建立繼續進入現實執行所需的正向資格。

邊界：Execution Qualification ≠ Authorization；≠ Execution Capability；≠ Final Execution Authority；≠ Reality Change。資格成立也不消滅後續仍然有效的 Final Veto。

威脅模型 ｜ Threat Model

狀態：普通工程術語；Book II 有界引用

Book II 只在 Authority Decomposition 與 Boundary Independence 的判定中使用“已經聲明的威脅模型”作為範圍條件：討論哪些主體可以失陷、哪些共同控制根屬於同一失敗來源。

邊界：本書不建立完整 Threat Model、Failure Matrix、部分失陷 / 協同失陷 taxonomy 或最終失敗條件；這些屬於後續研究範圍。

名義獨立 ｜ Nominal Independence ／ 失敗來源獨立 ｜ Failure-Source Independence

狀態：Book II 分析術語（只允許否定式使用）

當前研究建立的有限關係是：Nominal Independence does not imply Failure-Source Independence。不同進程、節點、服務、角色或機房可以名義獨立，卻仍共享身份、更新、恢復、通信、信息源或其他共同控制根。

邊界：這句話只否定自動推出關係，不提供 Failure-Source Independence 的完整充分條件定義；獨立性還具有方向性，A 相對 B 獨立不蘊含 B 相對 A 獨立。

結構化意圖 ｜ Structured Intent

狀態：Book II 工程術語

指 Intent 已達到可以被 identify、bind、reference、compare 與 validate 的結構化程度，使其能夠跨執行邊界成為穩定的規範參照。

邊界：Structured Intent 不是一個被另行凍結的新 Formal Concept，也不要求某種唯一字段、Hash、簽名格式或產品實現。

意圖綁定 ｜ Intent Binding

狀態：Book II 理論術語

描述當前 Action、對象、關鍵參數、Context、Approval、Policy、Payload、Execution 與 Evidence 如何可驗證地指回同一 Intent。它用於防止靜默換綁、跨 Intent 複用、舊 Intent 在新 State 下被繼續使用以及結果被歸到錯誤 Intent。

邊界：Hash、簽名、域分離和版本字段只是可能的實現載體，不是 Intent Binding 的唯一理論實現。

當前事實 ｜ Current Fact ／ 代理記錄 ｜ Proxy Record ／ 數據庫快照 ｜ Database Snapshot

狀態：分析術語組

Current Fact 指當前執行判斷真正需要成立的現實事實；Proxy Record 與 Database Snapshot 是可能承載、描述或代理事實的記錄對象。

邊界：記錄真實不等於其代理的現實仍然真實。命令狀態、顯示狀態、快照或緩存可以完全忠實於自身數據，卻仍不能自動替代當前事實。

證據充分性 ｜ Evidence Sufficiency

狀態：Book II 理論術語

回答的不是“某材料是不是 Evidence”，而是“這份 Evidence 對當前 Judgment 來說夠不夠”。同一份 Evidence 可以保持身份不變，卻因為 Action、時點、綁定對象或使用情境變化而不再充分。

邊界：Evidence Presence ≠ Evidence Sufficiency；Valid Evidence ≠ Sufficient Evidence for this decision。充分性條件不能被回填進 Evidence 本體定義。

構成充分性 ｜ Constitutive Sufficiency ／ 使用充分性 ｜ Use Sufficiency

狀態：Book II 理論區分（dependency-level）

Constitutive Sufficiency 問材料本身是否足以作為可依賴的 Evidence；Use Sufficiency 問即使它是有效 Evidence，是否足以支撐眼前這一次 Judgment 或 Execution Qualification。

邊界：兩者不是“一次通過以後永久有效”的兩步流程，也沒有被建立成完整正式概念層。

充分性候選條件 ｜ Candidate Sufficiency Conditions

狀態：候選條件集合；未凍結 taxonomy

當前研究反覆出現的方向包括來源資格、身份、綁定、時效 / 時間有效性、內容完整性、順序完整性、集合完整性、連續性、存續 / 留存與跨來源一致性；Independent Verifiability、Re-verifiability 與 Origin Binding 還以不同強度出現。

邊界：這些項目不是 Evidence 的定義，不是完整 checklist、權重表或互斥 taxonomy；最終條件集仍未收口，Non-repudiation 也未建立。

Missing ／ Unknown ／ Expired ／ Conflict ／ Evidence Gap

狀態：輸入 / 輸入質量狀態；Evidence Gap 為獨立對象

Missing、Unknown、Expired 與 Conflict 在相關研究中有明確來源；它們共同的最小邊界是：不足、未知、過期或衝突本身不能被默認轉換成 Allow。Evidence Gap 指向證據連續性或集合中的缺口，Evidence Gap ≠ simple Missing。

邊界：這些狀態不是統一的 Deny 枚舉，也不要求進入相同處置路徑；Invalid、Unverifiable、Stale 等相鄰表達不能被倒灌成一套歷史正式枚舉。

策略收斂 ｜ Policy Convergence

狀態：Book II 理論術語（dependency-level stable semantic core）

把多個有限、有明確來源、有適用範圍，並綁定當前 State / Context / Intent 的 Policy、Constraint 與 Condition，形成當前具體 Action 的有限、具體、可驗證規則側範圍。

其方向已經建立：收斂後的範圍不得比任何仍然 valid / applicable / in-scope 的約束更寬；解除約束的舉證責任在解除側；Missing、Unknown、Expired、Unverifiable 或 Conflict 不得因為輸入不足而帶來放寬。

邊界：Policy Convergence ≠ Execution Permission；≠ Execution Decision；≠ Final Execution Authority；≠ Reality Change。它也不是一個已經凍結的 min、集合交、meet 或統一優先級算法。

規則側可執行範圍 ｜ Policy-Side Executable Scope ／ 規則側有界結果 ｜ Policy-Side Bounded Result

狀態：Book II 工程術語

用於描述 Policy Convergence 形成的當前規則側約束結果：它回答“規則側最多允許到哪裡”，不回答 Action 是否已經獲得最終現實執行資格。

未決：Policy Convergence 發生在哪一層、輸出是否等於 Execution Qualification、以及是否構成 Final Execution Authority 的一部分，都仍然開放。

最終否決 ｜ Final Veto

狀態：Book II 理論術語；依賴考古層穩定語義，不是正式概念

面向一次當前、具體、受保護 Action 的有界負向執行約束關係。即使上游已經形成 Intent、Authorization、Approval、Policy result、Signature 或 Execution Qualification，只要一個仍然有效、在範圍內、可達且不可被受約束方繞過的負向約束，在受保護現實效果閉合之前成立，該 Action 就不得獲得現實執行效力。

邊界：Final Veto 只能阻止、維持阻斷或解除自身阻斷；不能因為可以拒絕就自動獲得修改 Intent、Target、創建替代 Action 或產生其他現實副作用的權力。Final Veto ≠ Explicit Deny；≠ No Allow；≠ Fail-Secure；≠ Capability-Level Refusal。

負向執行約束 ｜ Negative Execution Constraint

狀態：結構性稱呼

用於承載 Final Veto 的最小共同語義：它只沿負向作用於當前受保護 Action，限制動作取得現實執行效力。

邊界：不是所有必要條件都自動叫 Veto，也不是所有 Policy Deny 都自動成為 Final Veto。

可達性 ｜ Reachability ／ 不可繞過性 ｜ Non-Bypassability ／ 不可補償性 ｜ Non-Compensability

狀態：Final Veto 的必要實現屬性 / 研究層邊界

Reachability 要求負向約束在受保護效果閉合前能夠到達真實執行路徑；Non-Bypassability 要求不能通過同等結果的替代路徑繞過；Non-Compensability 表示在同一 Action、Scope、Target、Context 與時間下，一個有效 Final Veto 不能僅靠更多正向 Allow 被數量性抵消。

邊界：不可補償不等於永久、不可恢復或一般性的“拒絕優先”代數；Reachability 也不要求物理共址。

ALLOW NOT ESTABLISHED

狀態：結果 / 資格狀態；中文公開名稱未凍結

表示當前所需的 positive qualification 沒有被充分建立。它是 Evidence 與 Fail-Secure 之間已經接受的共同最小結果表達。

邊界：ALLOW NOT ESTABLISHED ≠ Explicit Deny；≠ Final Veto exercised；≠ permanent termination；≠統一 Safe Mode；≠統一恢復路徑。輸入清單中的“ALLOW 未建立”“允許未建立”暫不被本附錄裁成兩個不同對象，也不在此凍結正式中文名。

明確拒絕 ｜ Explicit Deny

狀態：決定結果

表示已經形成一個明確的 negative decision。它與“正向資格沒有建立”不同，因為 No Allow 不要求任何主體作出明確拒絕。

邊界：Deny 被產生、記錄或傳遞，不等於它已經觸達並約束 Executor；DENY EXISTS ≠ EFFECTIVE VETO EXISTS。

能力級拒絕 ｜ Capability-Level Refusal

狀態：執行結果 / outcome

表示現實執行路徑或 Execution Boundary 最終沒有賦予該 Action 現實執行效力。

邊界：它可以由 No Allow、未形成 Commit、Slot 未開放、組件不可用或有效 Final Veto 等不同原因產生，因此外部看到“沒有執行”不能反向證明獨立 Veto Authority 或 holder 存在。

拒絕失效 ｜ Refusal Failure ／ 拒絕失效形態 ｜ Refusal Failure Form

狀態：分析標籤；taxonomy 未凍結

用於描述本來用於阻止、限制或撤銷現實執行的負向結構，如何在對象、範圍、可達性、撤銷、生效狀態、作用方向或其他方面失去應有作用。

邊界：案例從 8 個擴展到 11 個時，觀察到的形態從 8 種增加到 12 種，說明該維度仍在增長。本書明確不把這些形態整理成正式 taxonomy、窮盡清單或固定檢查表。

多重否決 ｜ Multiple Veto ／ 多重策略拒絕 ｜ Multiple Policy Deny ／ 多重否決組合 ｜ Multiple-Veto Composition

狀態：有界未決

已經知道多個必要約束可以同時限制同一 Action；任一仍有效的必要負向約束不滿足時，受保護執行不應繼續；多個正向 Allow 不自動消除一個獨立成立的阻止。

仍未建立：優先級、quorum、aggregation、conflict resolution、expiry / revocation composition 等完整組合關係。Multiple Veto ≠ Multiple Policy Deny；Policy 側的 multiple-deny aggregation 同樣沒有建立。

配置權力面 ｜ authority-over-authority power surface

狀態：分析性結構稱呼；不是正式概念

指一種不必直接參與任何一次 Action，卻能夠改變未來 Authority allocation、決定誰承擔哪些 Authority 的權力位置。它作用的不是一次具體 Action，而是 Authority 本身的分配關係。

邊界：Authority 主題負責識別“誰能改變 Authority allocation”；Governance 負責變更過程、角色與結構變更流程。兩者形成有界共享接口，本書不把該接口升格為 Formal Relation。

權威圖 ｜ Authority Graph

狀態：分析性描述；未形式化

用於表達系統中“誰可以提出、批准、裁決、執行、否決，以及誰能改變這些關係”的權威結構。本書使用“Authority Graph 是一張能夠自我改寫的圖”來說明改變 Authority allocation 的能力本身也屬於權威結構的一部分。

邊界：當前沒有正式 Authority Graph 模型，沒有凍結節點、邊、方向或改寫規則；不得由附錄補出一套圖論結構。

自動化 ｜ Automation

狀態：普通工程術語

Book II 只建立一個有限方向：Execution Control 與 Automation 不矛盾。邊界越清楚，邊界內部越不需要把人工逐筆確認作為安全成立的普遍條件。

邊界：本書不主張“自動化越多越好”，也不建立自動化等級。減少不必要的人類介入，不等於減少所有人類介入，更不等於無人系統。

---

四、必須保持開放的對象

Outcome Semantics ｜ 中文名稱未凍結

狀態：未決對象

當前材料同時出現二值與多值處置表達，並出現“結果語義”“處置語義”兩種中文寫法；研究層明確記錄：這些語義之間的關係尚未建立。

因此，本附錄不統一成 ALLOW / DENY / HOLD，不把任何 observed outcome 自動重命名為 Deny，也不在“結果語義 / 處置語義”之間替作者作最終中文命名裁決。

關係狀態模型 ｜ Relation-State Model

狀態：未來研究任務；未設計、未命名凍結

研究已經確認需要繼續研究“關係本身是否有狀態、如何隨時間和上下文變化”這一問題，但當前只允許保留為 future research direction。

邊界：本附錄不設計字段、狀態機、語法、形式關係或模型結構，也不把它寫成已經存在的理論對象。

證明 ｜ Proof

狀態：未定義對象

Proof 在現有材料中以執行後證明、執行證明層、執行證明、可驗證證明等上位名稱出現，但沒有形成定義句。

邊界：在 Proof 被正式定義以前，Evidence 與 Proof 的關係不能被提前決定。不能聲稱 Evidence 就是 Proof，也不能聲稱 Evidence 只是 Proof 的一部分；不能用一個未定義對象去吸收一個已經定義的對象。

---

五、一條使用說明

這份附錄最重要的不是詞多，而是層級不能被抹平。

正式概念可以按照 v0.1 已凍結的最小定義使用；跨書共享術語必須保持 Book I 基線；Book II 理論術語只能承擔研究材料已經建立的關係；分析標籤與結構性稱呼不能因為好用就被升級成 ontology；結果值與狀態值不能被整理成一個源材料從未建立的統一 enum；未決對象則必須保持未決。

尤其需要保留幾條本書反覆使用的分離：

Authorization ≠ Execution
Capability ≠ Authority
Policy ≠ Final Authority
Adjudication ≠ Execution
Evidence ≠ Log
Evidence ≠ Evidence Sufficiency
No Allow ≠ Explicit Deny ≠ Capability-Level Refusal ≠ Final Veto

附錄的作用不是把這些對象“整理成一個完整體系”，而是阻止讀者在轉述中把尚未建立的關係悄悄補上。

---

附錄二｜現實失敗與邊界案例

這份附錄是做什麼用的

《執行控制工程》當前使用 11 個經過案例考古與聯合審計的現實案例。它們橫跨醫療設備、運載火箭、核電、證券自動化、載人航天、電力系統、民航、海上鑽井與軍事戰區指揮等不同領域，時間跨度從 1941 年到 2019 年。

其中 6 個案例已經在《執行縫隙》的成品案例附錄中出現，本附錄把 Book I 的事件事實、日期、數字、機構身份、已知不確定性與主要來源作為共同事實基線；Book II 只增加執行控制側的理論使用。另 5 個案例是 Book II 新增節點，事件事實直接來自當前案例考古所登記的官方、一手或政府調查材料。

需要先說清楚案例在這本書中的地位。

案例不是證明。 案例可以承擔現實背景、壓力測試、機制暴露、邊界測試、反例或有限支持性證據，但不能證明 Execution Control、Final Veto、Boundary Independence 等理論“正確”。11 個案例都能被現有結構表達，只能說明在這個有界案例池裡沒有出現必須新增一級結構的證據需要；能被解釋，不等於結構被證明。

事實與用法必須分開。 每個案例的“事件摘要”只寫當前來源能夠確認的事實；“在本書中的作用”是本書研究層的映射，不是事故調查機構、法院或監管機構自己的理論結論。

不從後果反推結構。 後果嚴重、傷亡巨大或損失驚人，都不能單獨建立 Authority Decomposition、Boundary Independence、Final Veto 或 Refusal Failure。必須回到具體事實鏈，指出哪一個判斷、狀態、證據、邊界或拒絕關係實際成立、缺失或失效。

四個案例攜帶永久性證據限定。 Therac-25 沒有 Tier 1 政府統一事故報告；Boeing 737 MAX 的官方材料之間存在未解決分歧；Chernobyl 的最終觸發事件由 INSAG-7 明確保留不確定；Pearl Harbor 的 1942 與 1946 兩份官方調查對責任性質作出不同判斷。這些限定不會因為進入 Book II 而消失。

---

一、Book I 複用案例

Therac-25｜1985—1987

案例狀態：Qualified｜Book I shared case

事件摘要

1985 年 6 月至 1987 年 1 月間，Therac-25 醫療直線加速器涉及 6 起已知的嚴重過量照射事故，造成嚴重傷害並涉及死亡。Therac-25 把更多安全職責交給軟件，沒有複製前代設備的全部獨立硬件保護。在 1986 年 Tyler 事故鏈中，熟練操作員快速編輯模式與能量後觸發競態，界面顯示參數已驗證、機器可用，實際物理配置卻不安全；設備產生 Malfunction 54 這類信息量極低的提示，並允許按 P 繼續。相關競態在 Therac-20 上同樣存在，但 Therac-20 的獨立硬件聯鎖阻止了危險束流。1987 年 Yakima 事故來自另一項軟件錯誤，涉及共享變量與計數溢出，與 Tyler 競態不同。事故後糾正包括獨立硬件單脈衝關斷、轉盤位置監測與聯鎖，以及軟件與界面變更。

在《執行控制工程》中的作用

本案最有價值的對照不是“軟件有沒有 bug”，而是同類軟件錯誤在有無獨立物理拒絕邊界時是否能夠獲得現實效力。Tyler 鏈還提供了一個帶範圍限定的 NO MATERIAL CHANGE REQUIRED 樣本：在特定執行控制失效段，界面所代表的安全狀態與真實物理配置之間的關係從未被充分建立，而操作流程仍然能夠繼續。

它支持什麼

支持“軟件域既控制又約束自身”時獨立拒絕邊界的重要性；支持 Evidence / displayed state ≠ current physical fact；也支持 Evidence Sufficiency 與“信息存在”之間的區別。它還說明一個拒絕動作即使可達，如果作用對象不對，也不等於存在有效 Final Veto。

它不支持什麼

不支持把 6 起事故歸為同一個競態條件；Yakima 1987 是不同錯誤，部分早期事故的具體代碼原因並不確定。不支持“Therac-25 刪除了所有硬件聯鎖”。本案沒有 Tier 1 政府統一事故委員會報告，死亡與每位患者最終死因也不能被籠統合並。

主要來源

• Nancy Leveson、Clark Turner：An Investigation of the Therac-25 Accidents，IEEE Computer，1993，Part I—IV（MIT 存檔）
  https://web.mit.edu/6.033/2004/wwwdocs/papers/Therac_1.html

---

Ariane 5 Flight 501｜1996

案例狀態：Qualified｜Book I shared case

事件摘要

1996 年 6 月 4 日，Ariane 5 首次飛行在升空約 40 秒後偏離航跡、解體，並由機載中和系統銷燬。慣性參考系統中的一段對準功能來自 Ariane 4，在進入飛行模式後仍繼續運行約 50 秒；Ariane 5 並不需要該功能。與 Horizontal Bias 相關的 64 位浮點到 16 位有符號整數轉換沒有受異常保護。起飛後約 36.7 秒，更高的水平速度使該值超出 16 位範圍，主備慣性參考系統因相同軟件與假設先後停止；診斷位模式又被飛控計算機解釋為飛行數據，最終產生極端噴管偏轉命令。調查委員會把事故定性為規範與設計錯誤，並指出評審與系統測試不足。

在《執行控制工程》中的作用

Ariane 5 是“名義冗餘不等於失敗來源獨立”最乾淨的現實樣本之一：兩套 SRI 在硬件上是兩個單元，卻共享相同軟件、相同數據範圍假設和相同失效條件。它還說明拒絕或保護機制可以對自己聲明的對象有效，卻在實際需要保護的範圍上不足。

它支持什麼

支持 Nominal Independence does not imply Failure-Source Independence；支持上游結論在新環境下仍需重新確認其適用邊界；也支持“保護動作本身可能成為現實失效鏈的一部分”。

它不支持什麼

不支持“代碼複用本身危險”這一一般結論；不支持“主備系統沒有冗餘”；不支持把所有組件描述為都按正確規範工作——官方報告明確指出規範、設計、異常處理與測試存在缺陷。機載中和系統最終按設計工作，因此本案也不能被寫成“所有拒絕機制都失效”。

主要來源

• Ariane 5 Flight 501 Failure: Report by the Inquiry Board，ESA/CNES 獨立調查委員會
  https://www-users.cse.umn.edu/~arnold/disasters/ariane5rep.html
• ESA：Ariane-501: The Inquiry Board's Report
• ESA：Flight 501 failure — first information

---

Three Mile Island｜1979

案例狀態：Qualified｜Book I shared case

事件摘要

1979 年 3 月 28 日，Three Mile Island 二號機組發生部分堆芯熔燬。事故起於主給水系統停止供水，汽輪機與反應堆自動停機。穩壓器頂部的先導式安全閥按設計打開，但在壓力下降後機械卡在開啟位置。控制室指示反映的是關閉命令與控制狀態，而不是閥門的真實機械位置；冷卻劑持續流失。與此同時，偏高的穩壓器水位被錯誤理解為堆芯仍被水覆蓋，隨後冷卻泵被關閉、緊急注水被削減，堆芯逐漸裸露並過熱。美國核管會記錄事故沒有造成可歸因的死亡或傷害，場外釋放很小；官方將原因歸為設備故障、設計相關問題與人員錯誤的組合。

在《執行控制工程》中的作用

本案用於區分命令狀態、顯示狀態、代理記錄與當前物理事實。一個記錄可以真實描述“系統發出了關閉命令”，卻不能證明閥門此刻真的已經關閉。它也顯示保護動作可以被擁有裁量權的第三方撤銷或縮減，因此“保護曾啟動”不等於保護在整個因果鏈上持續有效。

它支持什麼

支持 Proxy Record ≠ Current Fact；支持 State 必須被當前驗證，而不是由歷史命令狀態代替；支持 Evidence 的對象綁定與 Use Sufficiency。它也對“拒絕 / 保護動作可被撤銷”這一失效形態提供現實壓力。

它不支持什麼

不支持“所有儀表都錯誤”，也不支持把事故壓縮成單一操作員錯誤或單一告警問題。官方使用的是設備、設計與人員因素的組合解釋；本案也不支持“大量公眾死亡”之類表述。

主要來源

• U.S. Nuclear Regulatory Commission：Backgrounder on the Three Mile Island Accident
  https://www.nrc.gov/reading-rm/doc-collections/fact-sheets/3mile-isle
• NRC：Knowledge Management Digest: Three Mile Island Accident
• Report of the President's Commission on the Accident at Three Mile Island（Kemeny Commission）

---

Knight Capital｜2012

案例狀態：Qualified｜Book I shared case

事件摘要

2012 年 8 月 1 日，Knight Capital 在部署新交易功能後激活了舊的 Power Peg 代碼，約 45 分鐘內產生數百萬錯誤訂單，損失約 4.6 億美元。新 RLP 代碼分階段部署到 8 臺服務器，一名技術人員漏掉其中 1 臺；7 臺運行新代碼，1 臺仍保留舊 Power Peg。開盤前系統發送了 97 封 Power Peg disabled 自動郵件，但這些郵件沒有被設計或審查為系統告警。開盤後，212 個父訂單觸發數百萬子訂單，形成約 400 萬次成交，涉及 154 只股票、超過 3.97 億股。處置過程中，公司從 7 臺正確服務器卸載新 RLP 代碼，使舊 Power Peg 在更多服務器上可被觸發，問題因此加劇。

在《執行控制工程》中的作用

本案把“自動化速度”與“拒絕能力必須跟得上執行能力”放到同一條現實鏈上。信息並非完全不存在：97 封郵件實際產生了，但它們沒有被配置為能夠實時改變執行資格或阻止現實交易的控制輸入。事故處置動作還顯示，停止性動作本身也可能擴大可達執行能力。

它支持什麼

支持監控、日誌或通知不等於 Final Veto；支持執行控制必須位於能真實約束高速執行的位置；支持 dormant capability、版本路徑和恢復動作本身也需要受邊界約束。

它不支持什麼

不支持把事故歸結為單一“軟件 bug”或單一技術人員錯誤；也不支持“系統沒有任何信號”。97 封郵件確實存在，只是沒有承擔實時拒絕角色。事故處理中發生的是從正確節點卸載新代碼，不應被簡化為正常安全回滾。

主要來源

• U.S. Securities and Exchange Commission，Administrative Order，Exchange Act Release No. 70694
  https://www.sec.gov/litigation/admin/2013/34-70694.pdf

---

Boeing 737 MAX｜2018、2019

案例狀態：Qualified｜Book I shared case

事件摘要

2018 年 10 月 29 日的 Lion Air JT610 與 2019 年 3 月 10 日的 Ethiopian Airlines ET302 兩起 737 MAX 8 空難，分別造成 189 人與 157 人遇難，合計 346 人。MCAS 的功能在開發中擴展，原設計每次依賴兩隻迎角傳感器之一；原安全評估沒有充分包含同一迎角故障引發的多個告警與指示，也沒有充分包含重複激活對機組反應的影響。JT610 中，錯誤的單一迎角數據觸發重複 MCAS 低頭配平。復飛整改後，新設計比較兩側迎角，差異超過閾值時禁用相關功能，每個高迎角事件只允許一次激活，並限制配平權限。

在《執行控制工程》中的作用

本案用於區分動作級拒絕與能力級拒絕。飛行員可以通過電動配平暫時反向作用於一次 MCAS 動作，但原邏輯在持續高迎角信號下可以再次激活；一次 Action 被抵消，不等於產生該類 Action 的能力已經被可靠阻斷。它同時把運行期輸入資格與更早的校準、維護、安裝測試等信任建立過程放到同一條分析鏈上。

它支持什麼

支持 Action-level refusal ≠ Capability-level refusal；支持兩隻同類傳感器的存在不自動構成獨立驗證；支持輸入來源資格、當前 Evidence 與可達執行能力之間需要保持結構性邊界。

它不支持什麼

不支持把 JT610 與 ET302 寫成完全相同的因果鏈；兩起事故的維護、告警、機組動作與調查判斷存在差異。也不支持“軟件在任何條件下絕對取消全部人工控制”或“復飛後兩個傳感器就等於正交獨立”。官方材料之間存在必須保留的分歧，不能由本書統一裁掉。

主要來源

• Indonesia KNKT：Aircraft Accident Investigation Report: Lion Air JT610
  https://knkt.go.id/Repo/Files/Laporan/Penerbangan/2018/KNKT.18.10.33.04-Final-Report.pdf
• U.S. NTSB：Safety Recommendation Report ASR-19-01
• FAA 與國際適航機構聯合組：Joint Authorities Technical Review: Boeing 737 MAX Flight Control System
• FAA：Summary of the FAA's Review of the Boeing 737 MAX

---

Challenger / STS-51L｜1986

案例狀態：Qualified｜Book I shared case

事件摘要

1986 年 1 月 28 日，STS-51L 挑戰者號航天飛機在發射後約 73 秒解體，7 名機組成員遇難。物理原因是右側固體火箭助推器後部現場接縫密封失效，高溫燃氣穿過失效密封，破壞了助推器與外部燃料箱的結構連接。此前多次飛行中，O 形圈已經出現侵蝕和吹蝕跡象。發射前一晚，Thiokol 最初書面建議在低於既往最低經驗溫度 53°F 時不要發射；管理層複議後改變建議，部分工程師仍反對發射。總統調查委員會確認，最終決策者並不知道 O 形圈問題的完整近期歷史，也不知道最初的 No-Go 建議和持續工程反對。委員會認定發射決策過程存在嚴重缺陷。

在《執行控制工程》中的作用

本案在 Book II 中用於暴露一個更高層問題：約束的持有者也可能擁有合法解除約束的通道。 一個 No-Go 關係原本可達、及時、在範圍內並具有實踐效力，卻可以在組織壓力下由其 holder 自己收回。這樣一來，問題不只是“有沒有否決”，還包括“誰能改變否決是否繼續有效”。

它支持什麼

支持 Authority Decomposition 不能只看角色數量；支持 authority-over-authority 分析——改變規則、waiver、約束有效性的權力也必須進入 Authority 視野；支持有效 Veto 的 revocability / holder 關係仍是未完成問題。

它不支持什麼

不支持把事故寫成所有工程模塊都正確，也不支持把“異常正常化”寫成 Rogers Commission 的正式結論。環境約 36°F 與接縫區域的更低估計溫度必須分開；“摘下工程師帽子”屬於聽證證詞語境，不能代替委員會結論。當前源材料也不支持把所有 waiver 簡化為個人非法違規。

主要來源

• Report of the Presidential Commission on the Space Shuttle Challenger Accident（Rogers Commission）
  https://sma.nasa.gov/SignificantIncidents/assets/rogers_commission_report.pdf
• Volume I, Chapter V: The Contributing Cause of the Accident，NASA History
• NASA：Challenger STS-51L Accident

---

二、Book II 新增案例

Columbia / STS-107｜2003

案例狀態：Qualified｜Book II new case

事件摘要

2003 年 1 月 16 日，Columbia 執行 STS-107 任務。起飛約 81.7 秒後，一塊大型泡沫從外貯箱左側雙腳架區域脫落並撞擊左翼 RCC 5—9 號面板附近；撞擊直到次日才被地面團隊看見。Flight Day 2 開始出現外部影像請求，最終共有三次請求鏈。CAIB 記錄，碎片評估團隊沒有明確的 Mission manager 對其行動負責，請求在層級中被稀釋為“非關鍵工程願望”，Mission Management Team 最終沒有繼續追求影像。團隊使用的 Crater 模型遠超其 3 立方英寸驗證範圍，而初始碎片估計約 1,200 立方英寸；工程師最後只能得出“分析沒有顯示存在 safety-of-flight issue”。CAIB 明確批評這種舉證責任方向：在缺少能夠判定損傷的影像時，團隊反而被置於需要證明危險存在的位置。2 月 1 日再入時，過熱氣體經左翼破口進入，結構逐步失效，飛行器解體。

在《執行控制工程》中的作用

Columbia 是本案例池中最清楚的“維持原狀態本身就是一次執行判斷”樣本之一。關鍵失效段不需要錯誤的新動作：沒有獲取更多影像、沒有改變既有任務狀態、繼續沿原計劃返回，本身就構成現實決策。它同時暴露了“誰有資格為風險作最終判斷”的 ownership vacancy，以及 Evidence Sufficiency 的舉證責任方向。

它支持什麼

支持“沒有新的 Action”不等於“沒有執行控制問題”；支持在必要事實沒有被建立時，不能把未知狀態兌換成正向資格；支持 Evidence Sufficiency 與 Authority ownership 必須分別被建立。CAIB 關於影像請求、Crater 適用域和舉證責任的材料為這些分析提供現實壓力測試。

它不支持什麼

不支持把“偏差正常化”寫成 CAIB 獨立原創的因果結論——CAIB 明確把該表述歸於 Diane Vaughan 的社會學框架。不支持“本可輕易救援”：報告只說在 Flight Day Seven 前明確判定災難性損傷的前提下，Atlantis 救援可能可構想；維修方案被評為高風險。CAIB 同時列出多重技術與組織成因，不能壓縮為單一管理原因。

主要來源

• Columbia Accident Investigation Board Report, Volume I，CAIB，2003-08
  https://ehss.energy.gov/deprep/archive/documents/0308_caib_report_volume1.pdf
• NASA SMA 副本：
  https://sma.nasa.gov/SignificantIncidents/assets/columbia-accident-investigation-board-report-volume-1.pdf

---

2003 North American Blackout｜2003

案例狀態：Qualified｜Book II new case

事件摘要

2003 年 8 月 14 日，北美電網發生大範圍停電。美加聯合工作組最終報告確認，FirstEnergy 控制室的告警與日誌系統在約 14:14 後失效且直到停電後才恢復，操作員並不知道監視工具已經失效；與此同時，SCADA 仍向 MISO、AEP 等外部監視點發送正常、準確的數據。15:05 至 15:41 之間，三條 345-kV 線路在額定條件內因樹木接觸發生真實故障跳閘。16:05:57 Sammis-Star 線路跳閘後進入不可控級聯階段；NERC 分析指出，隨後多數線路跳閘來自 zone 3 繼電器在低電壓和大功率擺動條件下對“感知過載”的動作，這些本地保護動作會擴大停電範圍。最終報告把事故歸為四組成因，而不是單一“樹木接觸”。

在《執行控制工程》中的作用

本案同時暴露兩類執行控制問題：一是可觀測性鏈路自身的健康狀態沒有被作為必須驗證的 State / Evidence；二是級聯階段的保護裝置可以在自己的本地邏輯內正確動作，卻在系統層成為傳播機制。這正好說明“局部正確”與“系統級約束效果”不能互相替代。

它支持什麼

支持 monitoring exists ≠ monitoring health established；支持多個組織可以都在交換真實數據，卻仍基於不完整、不一致的事實作判斷；支持保護動作的局部正確性不自動建立系統級安全效果。

它不支持什麼

不得把前三次 345-kV 跳閘寫成錯誤保護動作——它們是實際樹木接觸造成的短路故障。不得把“樹木接觸”寫成唯一根因。不得聲稱系統“沒有數據”，因為 SCADA 持續外送準確數據。報告也沒有確認更早甩負荷一定能避免停電；約 15:46 時甚至可能已經太晚。

主要來源

• Final Report on the August 14, 2003 Blackout in the United States and Canada: Causes and Recommendations，U.S.-Canada Power System Outage Task Force，2004-04
  https://www.energy.gov/sites/prod/files/oeprod/DocumentsandMedia/BlackoutFinal-Web.pdf

---

Deepwater Horizon / Macondo｜2010

案例狀態：Qualified｜Book II new case

事件摘要

2010 年 4 月 20 日，Deepwater Horizon 正在 Macondo 井進行 temporary abandonment。美國國家委員會記錄，當時沒有法規或行業標準指導負壓測試的實施與解釋；測試中鑽桿出現約 1,400 psi 異常壓力，而報告認為除井在流動外沒有明顯解釋，所謂 bladder effect 也不是有效物理解釋，但現場仍把測試判斷為成功並繼續作業。爆炸後，平臺人員嘗試 EDS，面板指示燈亮起，但平臺未與 BOP 分離。國家委員會早期調查記錄 deadman 沒有完成預期效果；CSB 後續檢查進一步發現兩個冗餘控制艙存在接線 / 電氣缺陷，同時確認 AMF/deadman 確實觸發，但鑽桿屈曲、偏心使 blind shear ram 無法完全關閉並密封井筒。事故造成 11 人當場遇難，多人重傷；官方估計約 490 萬桶原油釋放，誤差約 ±10%。

在《執行控制工程》中的作用

本案把三個問題放到同一條鏈上：關鍵安全測試缺乏外部規範與清晰的資格歸屬；衝突 State / Evidence 被一個不存在的解釋消解；最後一道屏障的就緒狀態本身沒有被有效驗證。同時，AMF/deadman 的事實說明“觸發了拒絕動作”與“拒絕真實達成”是兩個對象。

它支持什麼

支持 trigger ≠ achieved effect；支持最後屏障的 availability / readiness 也需要進入 Evidence 與 Boundary 判斷；支持一個成功的局部控制動作甚至可能製造擊敗後續屏障的物理條件。本案還對 Authority vacancy、Evidence conflict 與 Final Veto reachability 提供現實壓力。

它不支持什麼

不支持“BP 與 Transocean 各自都以為對方負責”的流行表述——當前使用的 Tier 1 材料沒有逐字支持這一說法。也不支持“BOP 本來就不可能密封”：正壓測試中 blind shear ram 曾成功密封，但該證據不足以證明井噴條件下能力相同。國家委員會明確不是法律責任裁決機構，本書不作責任判斷。

主要來源

• Deep Water: The Gulf Oil Disaster and the Future of Offshore Drilling，National Commission，2011
  https://www.govinfo.gov/content/pkg/GPO-OILCOMMISSION/pdf/GPO-OILCOMMISSION.pdf
• Macondo Investigation Report, Volume 2，U.S. Chemical Safety and Hazard Investigation Board，2014
  https://www.csb.gov/assets/1/7/vol_2_final_version.pdf

---

Chernobyl Unit 4｜1986

案例狀態：Qualified｜Book II new case

事件摘要

IAEA INSAG-7 對切爾諾貝利 4 號機組事故的更新分析指出，RBMK 在事故條件下可能出現很強的正空泡反應性；從完全抽出位置插入控制棒時，石墨 displacer 會先排開下部通道中的水，在特定功率分佈與工況下形成局部正反應性，即所謂 positive scram。應急保護棒完全插入需要約 18 秒。ORM 由一套需要約 10—15 分鐘完成周期計算的系統給出，相關儀表距控制台約 50 米；其數值既不方便操作員獲得，也未納入反應堆保護系統。INSAG-7 還記錄，操作員可以通過可訪問端子上的 jumper wires 手動停用某些安全系統、旁路自動 scram trips，並且規程在某些條件下允許這樣做。positive scram 效應在 1983 年 Ignalina 已被發現，但擬議限制沒有真正實施。INSAG-7 明確保留最終觸發事件的不確定性，只說安全棒插入很可能是決定性促成因素之一。

在《執行控制工程》中的作用

本案同時暴露狀態可見性、保護可用性與拒絕方向三個層面：判斷“此刻是否仍具備停堆能力”所需要的 ORM 不是方便可得的當前狀態；保護是否生效可以由被約束一側在程序允許下改變；而在事故特定工況下，停止動作的物理實現可能先沿相反方向作用。

它支持什麼

支持 Boundary Independence 不能只看“保護系統存在”；支持“拒絕是否有效”不是簡單二值；支持控制前提和保護就緒狀態也必須進入執行控制視野。它還對 authority-over-authority 提供一個重要現實壓力：受約束者能夠在規則允許的路徑中改變約束是否生效。

它不支持什麼

不得把事故壓縮為“操作員違規”或“設計單一缺陷”。INSAG-7 明確修訂了早期幾項違規認定，同時仍保留對操作行為的批評。最終觸發事件not known for certain，positive scram 只能寫為很可能的決定性促成因素，不能寫成已證實的唯一觸發。當前案例研究主要依賴 INSAG-7，且全文檢索使用了其 OCR 副本，正式引用仍以 IAEA 原文件為準。

主要來源

• IAEA INSAG-7：The Chernobyl Accident — Updating of INSAG-1，Safety Series No. 75-INSAG-7，1992
  https://www-pub.iaea.org/MTCD/Publications/PDF/Pub913e_web.pdf

---

Pearl Harbor｜1941

案例狀態：Qualified｜Book II new case

事件摘要

1941 年 11 月 27 日，美國陸軍與海軍分別向夏威夷指揮系統發出警告：陸軍電文指出日本發動敵對行動“隨時可能”，海軍電文更直接寫明“this despatch is to be considered a war warning”。Short 回覆稱已針對 sabotage 進入戒備，並維持與海軍聯絡；Alert No. 1 的定義針對破壞和島內騷亂，不包含外部威脅。12 月 7 日清晨，USS Ward 的潛艇接觸報告在 07:12 到達海軍基地值班鏈，但沒有據此發出 alert；Opana 雷達在 07:02 發現約 130 英里外的大編隊，07:20 報告給一名經驗不足的中尉，對方認為附近有友軍飛機而未採取行動。襲擊於 07:55 開始。1942 Roberts Commission 將 Kimmel 與 Short 的行為定性為 dereliction of duty；1946 國會聯合委員會則明確稱其為 errors of judgment and not derelictions of duty。

在《執行控制工程》中的作用

這是 11 個案例裡唯一存在真實外部軍事對手的樣本，因此它對“無外部攻擊者是不是執行控制失效的必要條件”提供了否定性對照。更重要的是，雷達、潛艇報告與上報鏈並非完全不存在；失效集中在探測之後是否升級狀態這一判斷上。這裡甚至沒有一個已經形成、等待被 Veto 的執行請求，說明拒絕問題不能被統一成“對某個 Action 說不”。

它支持什麼

支持“檢測到事實 ≠ 狀態自動升級”；支持 Evidence 到 Judgment / State transition 之間仍然需要 Authority 與明確的決策鏈；支持外部攻擊者存在並不會自動產生一套不同的執行控制基本結構。

它不支持什麼

兩份 Tier 1 官方調查對責任性質直接衝突，必須並列保留，本書不作責任裁決。當前材料不支持“美方已經提前破譯具體襲擊計劃”，也不支持“如果當時升級戒備就能減少多少傷亡”的反事實量化。Roberts 的表述只說中尉相信附近有友軍飛機，當前 Tier 1 材料沒有核實把它具體化為“B-17 編隊”。

主要來源

• Attack Upon Pearl Harbor by Japanese Armed Forces，Roberts Commission，1942
  https://www.ibiblio.org/pha/pha/roberts/roberts.html
• Investigation of the Pearl Harbor Attack — Report of the Joint Committee，79th Congress, S. Doc. 244，Part V，1946
  https://www.ibiblio.org/pha/pha/congress/part_5.html

注：當前案例考古實際讀取的是上述歷史文檔存檔站副本；正式出版引用應優先替換為同一政府文件的 govinfo / NARA 穩定版本，而不改變本文事實口徑。

---

三、11 個案例一起能夠說明什麼

11 個案例全部通過當前案例准入審計，且沒有 Boundary Case。但這個結果不能被讀成“11 個案例證明執行控制結構已經完備”。它只支持一個有界負面觀察：在當前跨行業案例池裡，沒有出現現有結構組合無法表達、因而必須新增一級結構的證據需要。

案例層同時給出了幾個重要限制。第一，REQUIRED RELATION NEVER EXISTED 與 NO MATERIAL CHANGE REQUIRED 不能互相替代；當前 11 案都含前者成分，但只有 4 案在帶口徑限定的情況下支持後者，無條件成立者為 0。第二，名義獨立和失敗來源獨立可以明顯分離；Ariane 5、Deepwater、Columbia、Challenger 等分別暴露不同的共同失陷來源。第三，拒絕能力的失效形態仍在增加：案例從 8 個擴到 11 個時，觀察到的形態從 8 種增加到 12 種，因此本書不能把它們凍結成完整 Veto / Refusal taxonomy。

最重要的一條仍然是：Case ≠ Proof。 每個案例都只能在它自己的事實與證據邊界內承擔壓力測試；案例越多，也不能把“當前沒有看到反例”改寫成“理論已經被證明完整”。

---

四、證據限制

共享案例的事實層不重寫。 Therac-25、Ariane 5、Three Mile Island、Knight Capital、Boeing 737 MAX 與 Challenger 的共同事實基線沿用 Book I；Book II 只增加執行控制側的理論使用。

官方分歧必須保留。 Boeing 737 MAX 的不同官方材料存在未解決分歧；Pearl Harbor 的 1942 與 1946 官方調查在責任性質上直接衝突；Chernobyl 的最終觸發事件由 INSAG-7 自身保持不確定。這些都不是附錄可以替作者或調查機構消除的“噪聲”。

不用通行說法補齊來源缺口。 當前研究沒有明確支持的死亡人數、責任歸屬、反事實結果、具體參數或流行敘事，一律不因為“大家都這麼說”而寫進事實層。

研究映射不是官方結論。 Authority、Boundary Independence、Evidence Sufficiency、Fail-Secure、Final Veto、Refusal Failure、authority-over-authority 等詞屬於本書的研究映射，不得被讀成 NASA、NRC、SEC、FAA、IAEA、國會委員會或其他調查機構自己的術語。