SOS 組合安全性規格
——Cl-safe Composition 技術文件 v0.1
文件編號：EML-SOS-CLSAFE-2026-v0.1 日期：2026-05-30 作者：Neo.K（許筌崴） 機構：EveMissLab（一言諾科技有限公司） 狀態：設計規格草稿 關聯文件：EML-SOS-2026-WP-v0.1
摘要
符號算子系統（SOS）的核心操作是算子合成（⋈）：兩個符號算子組合，產生新的閉包算子。SOS白皮書（v0.1）定義了合成操作的代數結構，但未處理一個根本性的安全問題：算子合成在特定條件下會產生未定義行為（undefined behavior），且系統無法在無外部守門機制的情況下自行偵測。
本文件定義三種SOS組合失效模式，給出「Cl安全組合（Cl-safe composition）」的正式定義，規格化執行時驗證協議（Runtime Validation Protocol, RVP），並指定三層架構中各層的安全責任邊界。本文件不處理Sem槽脈絡多態或G槽張量積的完整形式化——這些是後續問題。本文件只處理：如何確保合成操作不會在靜默中輸出結構性無意義的結果。
§1 問題陳述
1.1 為什麼SOS需要獨立的安全規格
SOS白皮書定義了合成操作的形式：
$$\hat{O}(A) \circ \hat{O}(B) = \hat{O}(AB)$$
三個槽分別合成：
$$G_{AB} = G_A \otimes G_B \qquad \text{Sem}_{AB} = \text{Sem}_A \circ \text{Sem}B \qquad \text{Comp}{AB} = \text{Comp}_A \cap \text{Comp}_B$$
這個定義描述了「合法合成」應該是什麼——但沒有處理「非法合成發生時，系統如何回應」。
在傳統型別系統中，「非法」等同於「型別不相容」，編譯器在靜態分析階段拒絕。但SOS的三槽結構比傳統型別系統複雜：型別不相容可以發生在三個不同的槽，且因為Rice定理，完整的靜態驗證在一般情況下是不可判定的。這意味著部分合法性驗證必須移到執行時。
在執行時缺乏守門機制的情況下，非法合成的後果是：系統繼續執行，輸出一個語義上已破損但外觀上看似正常的算子。這比顯性崩潰更危險——它是靜默的結構性損壞。
1.2 靜默損壞的具體形式
以自然語言的符號序列為類比：「colorless green ideas sleep furiously」（喬姆斯基）。語法合法，語義無意義。在SOS中，等價情況是：Comp槽通過了（型別相容），但Sem槽的合成輸出了一個在語義空間中無定位的結果。系統不報錯，輸出一個「合法形狀但空洞語義」的算子。
如果這個損壞的算子被繼續使用，進入後續的合成鏈，損壞會向下游傳播。在多層組合後，損壞的來源將難以追溯。
§2 失效模式分類
SOS組合存在三種結構性失效模式，對應三個槽。
2.1 失效模式一：Comp崩潰（Comp-collapse）
定義：在組合深度 $n$ 時，組合規則集的交集趨近空集：
$$\bigcap_{i=1}^{n} \text{Comp}_{A_i} = \emptyset$$
此時合成鏈沒有任何合法的繼續方向，但系統若無守門機制，仍然繼續執行——結果是一個Comp槽為空集的算子，即一個在任何語境下都無法繼續組合的終止符，但不帶有任何標記表明它是無效的。
特徵：發生在較深的組合層，淺層可能正常。後果局部化，不一定傳播至全局。
類比：程式語言的型別系統中，深度巢狀的泛型（generic）參數在特化（specialization）時型別約束無法同時滿足，編譯器報錯。SOS缺乏等價的編譯期保護。
2.2 失效模式二：Sem發散（Sem-divergence）
定義：語義槽的合成 $\text{Sem}_A \circ \text{Sem}_B$ 在執行時不收斂——即不存在定義域內的不動點，或達到不動點所需的迭代次數無上界：
$$\nexists\ n < \infty : (\text{Sem}_A \circ \text{Sem}_B)^n(x) = (\text{Sem}_A \circ \text{Sem}_B)^{n+1}(x)$$
在語言三角耦合（LTC）的框架中，三語言迭代的核心機制就是不動點收斂（H\* 的發現即為案例）。Sem發散意味著迭代不收斂，語義計算進入無限迴圈或振盪。
特徵：不一定在首次執行時顯現，可能在特定輸入條件下才觸發。後果可以是全局性的（語義計算環境掛起）。
類比：函數式語言中的非終止遞迴。停機問題的不可判定性保證這類情況無法被完全靜態地排除。
2.3 失效模式三：G不一致（G-incoherence）
定義：幾何槽合成 $G_{AB} = G_A \otimes G_B$ 的輸出違反幾何一致性不變量（geometry coherence invariants, GCI）：
$$\text{GCI}(G_{AB}) = \text{False}$$
幾何一致性不變量的最小集合包括：拓撲連通性（topological connectivity）、定向一致性（orientation consistency）、尺度有界性（scale boundedness）。違反任一項，G槽的輸出在渲染或進一步合成時產生不可預期的結果。
特徵：在第一層（函式庫實作）中後果相對有限（渲染錯誤）；在第三層（硬體實作）中後果可能更嚴重。是三種失效中可靜態分析程度最高的，部分GCI可以在編譯期驗證。
類比：3D圖形管線中的non-manifold幾何，在著色器執行時產生未定義的著色結果。
§3 Cl安全組合的定義
3.1 核心定義
定義（Cl-safe composition）：一個組合操作 $\hat{O}(A) \circ \hat{O}(B)$ 是Cl安全的，當且僅當同時滿足以下三個條件：
條件C（Comp安全）：
$$\text{Comp}_A \cap \text{Comp}_B \neq \emptyset$$
合成後Comp槽非空，確保結果算子在某些語境下仍然可以繼續組合。
條件S（Sem安全）：
$$\exists\ n \leq K_S : (\text{Sem}_A \circ \text{Sem}_B)^n = (\text{Sem}_A \circ \text{Sem}_B)^{n+1}$$
語義合成在有界迭代次數 $K_S$（系統參數，預設值待定）內達到不動點。
條件G（G安全）：
$$\text{GCI}(G_A \otimes G_B) = \text{True}$$
幾何合成的輸出滿足全部幾何一致性不變量。
Cl-safe組合的定義依據閉包（Cl）框架的Cl-1公理（自我一致性）：合成的結果算子必須仍然在SOS型別系統的定義域內，不能落在系統外部。三個條件分別是Cl-1在Comp槽、Sem槽、G槽上的具體展開。
3.2 Cl-safe組合的代數性質
Cl-safe組合不是封閉的：兩個分別Cl-safe的算子，其組合不保證Cl-safe（Comp槽的交集可能在更深層崩潰）。這是SOS型別系統不同於簡單類型論的關鍵點，也是為什麼需要執行時驗證而不能只依賴靜態分析。
Cl-safe組合在有限深度下有保守估計：對於有限的符號集和有限的組合深度，Cl-safe性質在原則上是可以窮舉驗證的。但在開放符號集（可動態擴展）的條件下，這個保守估計不再適用。
3.3 靜默損壞的形式化
定義（靜默損壞算子）：若一個合成操作違反條件C、S或G之一，但系統未偵測到並繼續執行，產生的結果算子 $\hat{O}_{broken}(AB)$ 稱為靜默損壞算子。
靜默損壞算子的危險性在於：它具有正確算子的外觀（有G槽、Sem槽、Comp槽），但其中一個或多個槽的內容在語義上是未定義的。後續使用 $\hat{O}_{broken}(AB)$ 進行的任何組合，其結果也是未定義的，且損壞不帶標記地向下游傳播。
阻止靜默損壞算子進入組合鏈，是SOS安全架構的核心目標。
§4 執行時驗證協議（RVP）
4.1 協議概述
執行時驗證協議（Runtime Validation Protocol, RVP）定義了每次⋈操作前必須執行的驗證序列。RVP的設計原則：
快速失敗（fail fast）：驗證失敗時立即終止組合，返回有型別標記的錯誤，不允許在任何失敗條件下繼續執行。
有序檢查（ordered check）：三個條件按C→G→S的順序檢查。Comp安全是最廉價的檢查（集合交集操作），G安全次之（不變量計算），Sem安全最昂貴（迭代至不動點）。快速失敗原則要求廉價檢查先執行。
錯誤型別化（typed error）：驗證失敗返回的不是通用錯誤，而是具有具體型別的失效描述：CompCollapseError、SemDivergenceError、GIncoherenceError。型別化錯誤使上層系統可以做出有意義的恢復決策。
4.2 協議流程
function cl_safe_compose(Ô(A), Ô(B)):
// Step 1: Comp安全檢查（O(|Comp_A| + |Comp_B|)）
comp_intersection = Comp_A ∩ Comp_B
if comp_intersection == ∅:
return CompCollapseError(A, B, depth=current_depth)
// Step 2: G安全檢查
g_candidate = G_A ⊗ G_B
if not GCI(g_candidate):
return GIncoherenceError(A, B, g_candidate)
// Step 3: Sem安全檢查（有界迭代）
sem_candidate = Sem_A ∘ Sem_B
converged = false
for i in 1..K_S:
if sem_candidate^i == sem_candidate^(i+1):
converged = true
break
if not converged:
return SemDivergenceError(A, B, K_S)
// 全部通過：返回合法算子
return Ô(AB) {
G_slot: g_candidate,
Sem_slot: sem_candidate (at fixed point),
Comp_slot: comp_intersection
}4.3 K_S 參數的設定原則
Sem安全檢查的有界迭代上限 $K_S$ 是一個系統參數，需要在實作時確定。設定原則：
$K_S$ 過小：合法但需要較多迭代的語義合成被誤判為Sem發散，產生假陽性（false positives）。語言表達能力下降。
$K_S$ 過大：真實的Sem發散要等到 $K_S$ 次迭代後才被偵測，浪費計算資源，且在即時應用中可能造成延遲。
初版建議值：$K_S = 256$。理由：對於字母級別的基礎符號組合，語義不動點應在很少的迭代步驟內達到。256提供了充裕的上限空間，同時對真實發散案例的偵測延遲在可接受範圍內。這個值應在實作後根據實際測量調整。
4.4 RVP在深度組合中的累積開銷
對於長度為 $n$ 的組合鏈，RVP被調用 $n-1$ 次。最壞情況下（每次都到達Sem安全檢查且在 $K_S$ 步收斂），累積開銷為 $O(n \cdot K_S)$。
這個開銷在第一層（函式庫）是可接受的（Python層面的函數調用）。在第二層（SOS語言層）可以通過編譯器優化減少部分靜態可確定的情況。在第三層（硬體層）Cl-check應當成為單指令原語，開銷趨近零。
§5 三層架構的安全責任邊界
5.1 第一層：函式庫實作
安全責任：軟性RVP，記錄所有違反，允許開發者選擇是否啟用硬性終止。
class SymbolOperator:
def compose(self, other: 'SymbolOperator',
strict: bool = True) -> 'SymbolOperator':
result = cl_safe_compose(self, other)
if isinstance(result, CompositionError):
if strict:
raise result
else:
log_warning(result)
return BrokenOperator(self, other, result)
return resultBrokenOperator 是顯性標記的損壞算子——它是合法的Python物件，但攜帶一個明確的損壞標記，防止靜默傳播。任何嘗試使用 BrokenOperator 進行進一步組合的操作，自動返回相同的錯誤。
預設行為：strict=True，即硬性終止。strict=False 只在偵錯和測試場景下使用。
5.2 第二層：SOS語言層
安全責任：靜態分析與執行時的完整硬性RVP。
在靜態分析階段（編譯期）：對於符號集和組合規則在編譯時可確定的情況，進行條件C的靜態驗證（Comp安全）。對於GCI，在幾何定義為靜態常數時進行靜態驗證。
在執行時：完整RVP強制執行，無例外。失效只產生型別化錯誤，不允許靜默繼續。
語言層面的設計要求：SOS語言的型別系統應當內建Cl-safe約束，使「非Cl-safe的組合」在語言語法層面就是不合法的表達式——不是執行時錯誤，而是語法錯誤。這個目標可能在語言設計的早期版本中只能部分實現，但應當作為型別系統設計的長期目標。
5.3 第三層：硬體實作
安全責任：Cl-check作為硬體原語（hardware primitive），單指令執行RVP的核心邏輯。
在硬體層，Cl-check原語的設計規格：接受兩個符號算子的型別描述子作為輸入；輸出合法/非法的布林結果加錯誤碼；執行時間為常數（O(1)）；不允許任何形式的旁路（bypass）。
第三層的詳細設計留待第二層語言成熟後確定。本文件在此只標記設計要求，不規格化具體的指令集架構。
§6 已知限制與開放問題
6.1 不可判定性的硬限制
Sem安全的完整靜態驗證是不可判定的（停機問題的直接推論）。這意味著：SOS語言層的靜態分析只能驗證Sem安全的充分條件（sufficient conditions），不能驗證必要條件。換句話說，靜態驗證可以保證「確定安全的」組合通過，但無法排除所有不安全的組合。
執行時RVP是對這個不可判定性的工程妥協：用 $K_S$ 有界迭代替代真正的停機驗證，接受一定的假陰性率（真正收斂但需要超過 $K_S$ 步的組合被誤判為發散）。
這個妥協的代價是：SOS語言在理論上有一個無法被靜態排除的表達力盲區——某些語義上合法但迭代緩慢的算子組合，會被RVP拒絕。這個盲區的大小取決於 $K_S$ 的設定。
6.2 BrokenOperator的隔離問題
第一層的 BrokenOperator 設計假設：攜帶損壞標記的算子不會被傳入不知道這個標記的系統。若SOS函式庫在大型系統中與不了解 BrokenOperator 類型的代碼共存，標記可能被外部代碼忽略，退化為靜默損壞。
這個問題在第二層（語言層）的型別系統中可以被完全解決（BrokenOperator 成為獨立的不可組合型別），但在第一層中是依賴使用者紀律的半工程解法。
6.3 GCI的完整定義留待實作
本文件只列出GCI的最小集合（連通性、定向一致性、尺度有界性）。G槽的完整幾何一致性不變量，需要在英文字母原型的G槽設計完成後，根據實際的幾何定義補充。本文件在此留白，標記為「實作期補充」。
技術結語
SOS是一個關於符號本體論的命題，但本文件處理的是一個更樸素的工程問題：一個輸出靜默損壞的系統是沒有用的，不論其本體論多麼優雅。
Cl-safe composition的設計哲學是：寧可顯性失敗，不要靜默損壞。失敗可以被偵測、被修復、被學習。靜默損壞只能在系統下游出現奇怪行為時才被回溯發現，且發現時損壞已經擴散。
型別化錯誤是這個哲學的具體實現：每次失敗都帶有結構性的失敗原因，使SOS的使用者可以對「為什麼這個組合不被允許」有精確的理解，而不只是收到一個通用的「操作失敗」。
SOS的設計目標是讓符號的存在等同於它的算子性質。這個目標的工程前提是：算子的組合操作必須可預期、可追溯、且在失敗時可診斷。Cl-safe composition是這個前提的技術保證。
⋈
EML-SOS-CLSAFE-2026-v0.1 © EveMissLab