# 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，記錄所有違反，允許開發者選擇是否啟用硬性終止。

```python
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 result
```

`BrokenOperator` 是顯性標記的損壞算子——它是合法的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*