# 同一個應用是什麼：功能契約、觀測等價與程式身分

## What Makes an Application the Same? Functional Contracts, Observational Equivalence, and Software Identity

**系列名稱**：AI 自適應封裝與遞歸演化計算論（AI-Adaptive Encapsulation and Recursive Evolutionary Computation, AEREC）  
**系列編號**：EML-AEREC-2026-02  
**作者**：Neo.K（許筌崴）with Aletheia（GPT）  
**機構**：EveMissLab／一言諾科技有限公司  
**版本**：v0.1 身分與等價框架初稿  
**日期**：2026 年 7 月 29 日  
**文件定位**：程式身分、功能契約、觀測等價、語義版本、契約漂移、跨代演化

---

## 摘要

若一個應用的原始碼、演算法、資料結構、中介表示、編譯器、二進位、DLL 邊界、容器映像、硬體映射與執行時策略都可以被 AI 持續改寫，那麼一個根本問題立即出現：經過多代演化之後，為什麼它仍然是「同一個應用」？

傳統軟體工程常以檔名、套件名稱、版本號、程式庫識別碼、API 名稱或產品名稱作為應用身分，但這些多半只是外部標記。它們無法單獨保證兩個版本在功能、狀態、副作用、權限、安全、時間與錯誤行為上保持一致。相反地，兩個二進位完全不同的版本，也可能在所有重要觀測下完成相同任務。若缺乏嚴格的身分理論，AI 自適應封裝容易出現兩種相反錯誤：第一，把任何內部變動都誤判為身分破壞；第二，把逐代功能漂移偽裝成效能最佳化。

本文提出「程式身分—實現分離」框架。本文主張，應用身分不應由單一原始碼、二進位或封裝格式決定，而應由權威程式根、功能契約、觀測者集合、語義版本、治理邊界與歷史連續性共同構成：

$$
\mathcal I_{\mathrm{app}}
=
\left(
r^\ast,
\mathcal C,
\Omega,
v_s,
\mathcal G,
H
\right).
$$

其中 $r^\ast$ 是權威身分根， $\mathcal C$ 是功能與觀測契約， $\Omega$ 是合法觀測者與觀測介面集合， $v_s$ 是語義版本， $\mathcal G$ 是治理與遷移規則， $H$ 是可追溯歷史。

本文將功能契約擴張為：

$$
\mathcal C
=
\left(
\mathcal I,
\mathcal O,
\mathcal S,
\mathcal E,
\mathcal P,
\mathcal Q,
\mathcal R,
\mathcal T,
\mathcal A,
\mathcal X
\right),
$$

分別表示輸入、輸出、狀態、副作用、權限、品質、錯誤、時間、可用性與外部依賴。若兩個版本在指定觀測者與容許誤差下保持不可區分，則稱其觀測等價：

$$
P_a
\equiv_{\mathcal C,\Omega}
P_b.
$$

本文進一步區分七種等價層級：值等價、行為等價、狀態等價、副作用等價、時間等價、治理等價與生命週期等價。不同應用可依風險與任務選擇不同強度的身分契約。純函數可能只要求輸出等價；金融、醫療、工業控制與多代理世界狀態系統則需要更強的狀態、順序、權限、可回滾與證據等價。

本文也提出「契約漂移」與「身分漂移」。若每一代只與上一代進行寬鬆比較，局部微小偏差可能逐步累積，使第 $n$ 代版本不再與初始版本等價。為避免此問題，系統必須同時維持鄰代驗證、錨點驗證與歷史不變量驗證：

$$
P_{n+1}
\equiv_{\mathcal C}
P_n,
$$

$$
P_{n+1}
\equiv_{\mathcal C}
P_0,
$$

以及：

$$
\operatorname{Inv}_{H}(P_{n+1})=1.
$$

本文最後區分最佳化、兼容演化、功能升級、產品分叉與身分斷裂五種變更類型，避免把新功能加入、契約更新、重大權限變更與純實現改良混為一談。

本文的核心結論是：同一個應用不是同一份程式碼，而是同一個可追溯的功能承諾、觀測邊界與治理身分。AI 可以無限改寫實現，但不能在不更新契約與語義版本的情況下，悄悄改變應用究竟承諾了什麼。

**關鍵詞**：程式身分、功能契約、觀測等價、語義版本、契約漂移、身分根、AI 自適應封裝、可驗證演化

---

## 1. 問題的提出：程式變了，應用還是同一個嗎

假設一個應用經歷以下變化：

- Python 重寫為 Rust；
- 單執行緒改為多執行緒；
- CPU 改為 GPU；
- 雜湊表改為 B-tree；
- 本地模型改為遠端模型；
- 動態連結改為靜態連結；
- 多個 DLL 合併為單一映像；
- 精確演算法改為容許誤差的近似演算法；
- 檔案快取改為記憶體快取；
- 傳統 API 改為 Agent 工具協議。

哪些改動仍屬於同一應用？哪些改動已經創造另一個應用？

若只看原始碼：

$$
P_a^{\mathrm{source}}
\neq
P_b^{\mathrm{source}},
$$

幾乎所有最佳化都會被判定為不同。

若只看產品名稱：

$$
\operatorname{Name}(P_a)
=
\operatorname{Name}(P_b),
$$

那麼即使功能、權限與安全行為已完全改變，也可能被錯誤視為相同。

因此，應用身分不能只依賴表面標記，也不能只依賴內部實現。

---

## 2. 三種常見但不足的身分模型

### 2.1 文字身分

以原始碼內容或檔案指紋決定身分：

$$
\mathcal I_{\mathrm{text}}(P)
=
\operatorname{Hash}
\left(
P_{\mathrm{source}}
\right).
$$

它適合辨識特定版本，但不適合辨識跨代應用。

### 2.2 二進位身分

以執行檔、DLL 或套件內容決定身分：

$$
\mathcal I_{\mathrm{binary}}(P)
=
\operatorname{Hash}
\left(
P_{\mathrm{binary}}
\right).
$$

它可用於供應鏈與部署驗證，但重新編譯、換平台或改連結方式就會產生不同身分。

### 2.3 品牌身分

以名稱、套件 ID、應用商店識別或公司宣告決定身分：

$$
\mathcal I_{\mathrm{brand}}
=
\left(
\operatorname{Name},
\operatorname{Publisher},
\operatorname{PackageID}
\right).
$$

它具有法律與商業意義，卻不能單獨保證功能等價。

因此，三者都應被保留，但不應成為唯一身分本體。

---

## 3. 程式身分的六元結構

本文定義應用身分為：

$$
\boxed{
\mathcal I_{\mathrm{app}}
=
\left(
r^\ast,
\mathcal C,
\Omega,
v_s,
\mathcal G,
H
\right).
}
$$

### 3.1 權威身分根 $r^\ast$

穩定根識別碼，用來連接所有投影、版本、證書與部署。

它不等同內容雜湊，因為內容會改變。它更接近一個持續存在的語義實體識別：

$$
r^\ast
=
\operatorname{RootID}
\left(
P^\ast
\right).
$$

### 3.2 功能契約 $\mathcal C$

定義應用承諾完成什麼，以及不得做什麼。

### 3.3 觀測者集合 $\Omega$

定義哪些主體、介面與測量方式有資格判斷版本是否等價。

### 3.4 語義版本 $v_s$

當契約發生有意義改變時，必須更新語義版本，而不是偽裝成單純最佳化。

### 3.5 治理規則 $\mathcal G$

定義誰可以修改契約、批准版本、簽署證書、部署與回滾。

### 3.6 歷史連續性 $H$

保存每次改寫、驗證、遷移與分叉，確保版本不是突然冒出的無來源物件。

---

## 4. 功能契約的完整結構

本文將契約定義為：

$$
\mathcal C
=
\left(
\mathcal I,
\mathcal O,
\mathcal S,
\mathcal E,
\mathcal P,
\mathcal Q,
\mathcal R,
\mathcal T,
\mathcal A,
\mathcal X
\right).
$$

### 4.1 輸入契約 $\mathcal I$

包含：

- 輸入型別；
- 值域；
- 編碼；
- 格式；
- 前置條件；
- 不合法輸入行為。

### 4.2 輸出契約 $\mathcal O$

包含：

- 輸出型別；
- 結構；
- 語義；
- 穩定排序；
- 可重現性；
- 容許差異。

### 4.3 狀態契約 $\mathcal S$

包含：

- 持久狀態；
- 暫態；
- 狀態轉移；
- 交易；
- 一致性；
- 回滾；
- 遷移。

### 4.4 副作用契約 $\mathcal E$

包含：

- 檔案；
- 網路；
- 資料庫；
- 日誌；
- 通知；
- 裝置控制；
- 外部服務。

### 4.5 權限契約 $\mathcal P$

包含：

- 可讀資源；
- 可寫資源；
- 可調用工具；
- 最小必要權限；
- 高風險操作；
- 人工確認要求。

### 4.6 品質契約 $\mathcal Q$

包含：

- 精度；
- 召回率；
- 錯誤上限；
- 確定性；
- 穩定性；
- 可解釋性；
- 公平性；
- 安全裕度。

### 4.7 錯誤契約 $\mathcal R$

包含：

- 錯誤類型；
- 例外；
- 重試；
- 降級；
- 回退；
- 告警；
- 資料恢復。

### 4.8 時間契約 $\mathcal T$

包含：

- 延遲；
- 吞吐；
- 順序；
- 截止期限；
- 同步窗口；
- 陳舊容忍度。

### 4.9 可用性契約 $\mathcal A$

包含：

- 可用率；
- 容錯；
- 備援；
- 災難恢復；
- 離線模式；
- 服務退化。

### 4.10 外部依賴契約 $\mathcal X$

包含：

- 依賴來源；
- 版本；
- 供應商；
- API；
- 模型；
- 授權；
- 網路需求；
- 外部資料新鮮度。

---

## 5. 觀測者不是單一使用者

### 5.1 觀測者集合

令：

$$
\Omega
=
\left\{
\omega_{\mathrm{user}},
\omega_{\mathrm{api}},
\omega_{\mathrm{state}},
\omega_{\mathrm{security}},
\omega_{\mathrm{operator}},
\omega_{\mathrm{auditor}},
\omega_{\mathrm{environment}}
\right\}.
$$

不同觀測者關注不同性質。

使用者可能只看結果；API 客戶端關注型別與錯誤碼；安全觀測者關注權限與網路；運維系統關注延遲與可用性；審計者關注來源與證據。

### 5.2 觀測函數

每個觀測者具有觀測函數：

$$
\operatorname{Obs}_{\omega}
:
\operatorname{Run}(P,x,e)
\longrightarrow
Y_{\omega}.
$$

完整觀測可表示為：

$$
\operatorname{Obs}_{\Omega}
=
\prod_{\omega\in\Omega}
\operatorname{Obs}_{\omega}.
$$

### 5.3 觀測盲區

若契約未納入某種觀測，最佳化可能在該盲區中改變重要行為。

例如，只比較輸出值，可能忽略：

- 網路資料外洩；
- 寫入額外檔案；
- 延遲顯著增加；
- 日誌包含敏感資訊；
- 隨機性改變；
- 依賴第三方服務；
- 故障恢復能力下降。

因此，觀測者集合本身就是安全邊界。

---

## 6. 七種等價層級

不是所有應用都需要同一強度的等價。

### 6.1 值等價

對所有合法輸入：

$$
f_a(x)=_{\epsilon}f_b(x).
$$

適合純計算函數。

### 6.2 行為等價

除輸出值外，還要求交互順序與公開事件相同：

$$
\operatorname{Trace}_{\mathrm{public}}(P_a,x)
=
\operatorname{Trace}_{\mathrm{public}}(P_b,x).
$$

### 6.3 狀態等價

要求狀態轉移在指定抽象下等價：

$$
\alpha
\left(
S_a^{t+1}
\right)
=
\alpha
\left(
S_b^{t+1}
\right).
$$

其中 $\alpha$ 是狀態抽象。

### 6.4 副作用等價

要求對檔案、資料庫、網路與裝置的可觀測副作用等價。

### 6.5 時間等價

不要求每一指令同時發生，而要求符合期限、順序與同步契約：

$$
\operatorname{TimeObs}(P_a)
=_{\mathcal T}
\operatorname{TimeObs}(P_b).
$$

### 6.6 治理等價

要求權限、確認、證據、回滾與責任邊界不被削弱。

### 6.7 生命週期等價

除單次執行外，還要求長期升級、遷移、維護、資料恢復與可審計性保持。

由此可建立等價強度偏序：

$$
\equiv_{\mathrm{value}}
\prec
\equiv_{\mathrm{behavior}}
\prec
\equiv_{\mathrm{state}}
\prec
\equiv_{\mathrm{effect}}
\prec
\equiv_{\mathrm{time}}
\prec
\equiv_{\mathrm{governance}}
\prec
\equiv_{\mathrm{lifecycle}}.
$$

這不是嚴格適用於所有情境的全序，而是表示通常需要逐步增加觀測維度。

---

## 7. 確定等價、容許等價與統計等價

### 7.1 確定等價

$$
P_a\equiv P_b
$$

表示對指定範圍完全一致。

### 7.2 容許等價

允許誤差：

$$
d
\left(
\operatorname{Obs}(P_a),
\operatorname{Obs}(P_b)
\right)
\leq
\epsilon.
$$

適合浮點、近似、壓縮與多媒體系統。

### 7.3 統計等價

對隨機或 AI 系統，可能要求分布等價：

$$
D
\left(
\mathbb P_a(Y\mid x),
\mathbb P_b(Y\mid x)
\right)
\leq
\epsilon.
$$

其中 $D$ 可為適當分布距離。

### 7.4 風險等價

高風險事件的機率不能增加：

$$
\operatorname{Risk}(P_b)
\leq
\operatorname{Risk}(P_a)+\delta.
$$

因此，AI 系統的身分契約不能只比較單次文字輸出。

---

## 8. 等價的領域與邊界

### 8.1 全域等價

要求所有合法輸入成立：

$$
\forall x\in\mathcal I.
$$

### 8.2 分布等價

只要求在工作分布 $\mathcal D$ 下成立：

$$
x\sim\mathcal D.
$$

### 8.3 區域等價

只在指定功能區、平台或風險區域內成立。

### 8.4 條件等價

在環境條件 $E$ 下成立：

$$
E\models
P_a\equiv_{\mathcal C}P_b.
$$

例如 GPU 版本可能只在特定驅動與精度模式下符合契約。

每份等價證書都必須攜帶適用域，不能把局部證明誤稱為普遍證明。

---

## 9. 身分根與內容指紋

### 9.1 穩定身分根

$$
r^\ast
$$

跨越多代存在，不因內容改變而改變。

### 9.2 版本內容指紋

每個版本具有：

$$
h_n
=
\operatorname{Hash}
\left(
P_n,\mathcal C_n,\mathcal Z_n
\right).
$$

### 9.3 投影指紋

不同投影具有：

$$
h_{n,i}
=
\operatorname{Hash}
\left(
\pi_i(P_n)
\right).
$$

所以完整識別可表示為：

$$
\operatorname{ID}(P_{n,i})
=
\left(
r^\ast,
v_s,
n,
i,
h_n,
h_{n,i}
\right).
$$

穩定根回答「它是哪個應用」；內容指紋回答「它是哪一個精確版本」。

---

## 10. 語義版本與實現版本

本文區分：

### 10.1 語義版本

$$
v_s
$$

當功能契約發生對使用者或治理有意義的改變時更新。

### 10.2 實現版本

$$
v_i
$$

內部演算法、封裝與執行投影更新，但契約保持。

### 10.3 證書版本

$$
v_z
$$

驗證方法、覆蓋率或證據更新。

### 10.4 環境版本

$$
v_e
$$

硬體、作業系統、模型、依賴與工作負載版本。

完整版本座標為：

$$
v
=
\left(
v_s,v_i,v_z,v_e
\right).
$$

這能避免把實現最佳化錯誤宣告為功能升級，也避免契約變更被藏在修補版本中。

---

## 11. 契約漂移

### 11.1 鄰代漂移

即使：

$$
P_{n+1}
\equiv_{\epsilon}
P_n,
$$

若每代允許小誤差，長期可能有：

$$
P_n
\not\equiv_{\mathcal C}
P_0.
$$

### 11.2 漂移累積

若每代最大偏差為 $\epsilon_i$ ，最壞情況總偏差可能近似：

$$
\Delta_n
\leq
\sum_{i=1}^{n}\epsilon_i.
$$

因此，只做鄰代比較不夠。

### 11.3 三重驗證

每個候選至少應比較：

#### 鄰代等價

$$
P_{n+1}\equiv_{\mathcal C}P_n.
$$

#### 錨點等價

$$
P_{n+1}\equiv_{\mathcal C}P_0.
$$

#### 歷史不變量

$$
\operatorname{Inv}_{H}(P_{n+1})=1.
$$

### 11.4 契約指紋

對契約產生：

$$
h_{\mathcal C}
=
\operatorname{Hash}
\left(
\operatorname{Canonicalize}
\left(
\mathcal C
\right)
\right).
$$

任何未授權契約改變都應中止「純最佳化」流程。

---

## 12. 身分漂移

契約可能未明文改變，但實際行為、依賴或治理已發生變化。

可定義身分漂移向量：

$$
\mathbf D_{\mathrm{id}}
=
\left(
D_I,
D_O,
D_S,
D_E,
D_P,
D_Q,
D_R,
D_T,
D_A,
D_X
\right).
$$

若：

$$
\mathbf D_{\mathrm{id}}
\not\preceq
\boldsymbol{\epsilon}_{\mathcal C},
$$

則版本不應被視為純實現演化。

常見漂移包括：

- 輸出語義悄悄改變；
- 新增未聲明網路依賴；
- 權限擴張；
- 錯誤時不再回滾；
- 模型更新導致分布偏移；
- 延遲尾部惡化；
- 資料保留政策改變。

---

## 13. 五類程式變更

### 13.1 純最佳化

契約與語義版本不變：

$$
\mathcal C_{n+1}
=
\mathcal C_n.
$$

### 13.2 兼容演化

新增能力，但舊契約仍完整成立：

$$
\mathcal C_n
\subseteq
\mathcal C_{n+1}.
$$

### 13.3 功能升級

契約有意改變，需要新語義版本與遷移說明。

### 13.4 產品分叉

新版本保留來源關係，但不再承諾相同身分：

$$
r^\ast_{\mathrm{child}}
\neq
r^\ast_{\mathrm{parent}}.
$$

### 13.5 身分斷裂

未經明確版本與治理程序，功能或權限發生重大改變。這不是合法演化，而是失控漂移。

---

## 14. 契約精度與最佳化自由度

契約越精確，允許的最佳化空間通常越小。

令契約約束強度為：

$$
\kappa(\mathcal C).
$$

候選空間為：

$$
\mathfrak O_{\mathcal C}
=
\left\{
\phi\in\mathfrak O
\mid
\phi(P)\equiv_{\mathcal C}P
\right\}.
$$

通常：

$$
\kappa(\mathcal C)\uparrow
\quad\Longrightarrow\quad
|\mathfrak O_{\mathcal C}|\downarrow.
$$

但過度寬鬆的契約會增加漂移風險。

因此，需要在：

$$
\text{身分穩定}
\quad\text{與}\quad
\text{改良自由}
$$

之間建立適當邊界。

---

## 15. 契約不是單一文件

實際契約應由多種證據共同構成：

$$
\mathcal C
=
\mathcal C_{\mathrm{formal}}
+
\mathcal C_{\mathrm{type}}
+
\mathcal C_{\mathrm{test}}
+
\mathcal C_{\mathrm{policy}}
+
\mathcal C_{\mathrm{trace}}
+
\mathcal C_{\mathrm{human}}.
$$

包括：

- 形式規格；
- 型別與效果；
- 測試；
- 權限政策；
- 真實執行軌跡；
- 人類可讀承諾；
- 法律與服務條款；
- 歷史兼容要求。

AI 可以協助抽取與補全契約，但不能把自己推測的隱含行為直接升格為正式契約。

---

## 16. 隱含契約

成熟應用通常具有大量未寫下的兼容行為，例如：

- 特定輸出排序；
- 錯誤訊息格式；
- 邊界輸入處理；
- 非正式檔案位置；
- 日誌欄位；
- 執行時機；
- 第三方依賴的非公開行為。

可從真實軌跡抽取候選隱含契約：

$$
\widehat{\mathcal C}_{\mathrm{implicit}}
=
\mathcal L
\left(
\operatorname{Traces}(P)
\right).
$$

但必須區分：

- 應保留的相容行為；
- 偶然實現細節；
- 錯誤但被依賴的行為；
- 應被正式修正的技術債。

隱含契約的處理本身需要治理決策。

---

## 17. 等價證書

每次版本提交應附帶：

$$
Z_{a\rightarrow b}
=
\left(
\mathcal C,
\Omega,
D,
\mathcal V,
R,
E,
h_a,
h_b
\right),
$$

其中：

- $\mathcal C$ ：契約；
- $\Omega$ ：觀測者集合；
- $D$ ：適用域；
- $\mathcal V$ ：驗證方法與結果；
- $R$ ：剩餘風險；
- $E$ ：環境條件；
- $h_a,h_b$ ：版本指紋。

證書不必宣稱絕對證明，而應精確聲明：

- 證明了什麼；
- 測試了什麼；
- 沒有覆蓋什麼；
- 在什麼環境成立；
- 何時需要重新驗證。

---

## 18. 身分遷移

當契約真的需要改變時，系統應使用顯式遷移：

$$
\mu:
\left(
\mathcal I_{\mathrm{app}}^{(n)},
\mathcal C^{(n)}
\right)
\longrightarrow
\left(
\mathcal I_{\mathrm{app}}^{(n+1)},
\mathcal C^{(n+1)}
\right).
$$

遷移至少包含：

- 差異；
- 理由；
- 資料遷移；
- API 兼容；
- 回滾；
- 使用者通知；
- 風險；
- 舊版本支援期限。

這與純最佳化不同，不能使用相同的自動提交門檻。

---

## 19. 多變體與單一身分

同一應用可以同時存在多個合法變體：

$$
\mathcal V_n
=
\left\{
P_n^{\mathrm{latency}},
P_n^{\mathrm{energy}},
P_n^{\mathrm{memory}},
P_n^{\mathrm{offline}},
P_n^{\mathrm{secure}}
\right\}.
$$

只要它們都滿足：

$$
P_n^{(i)}
\equiv_{\mathcal C_i}
P^\ast,
$$

便可共享同一身分根。

但不同變體可能具有不同附加契約。例如離線版不承諾雲端同步，低能耗版不承諾最低延遲。這些差異必須顯式表示，而不能假裝所有變體完全相同。

---

## 20. 與演化膠囊的關係

演化膠囊中的：

$$
P^\ast
$$

提供權威本體；

$$
\mathcal C
$$

提供身分邊界；

$$
\mathcal V_n
$$

提供多個實現；

$$
\mathcal Z_n
$$

提供等價證據；

$$
\mathcal H_n
$$

提供歷史連續性；

$$
\mathcal G
$$

提供合法變更程序。

所以演化膠囊不是版本資料夾，而是一個保存應用身分跨代連續性的治理結構。

---

## 21. 可反駁條件

本框架在下列情況下可能失敗。

### 21.1 契約不可充分表達

若重要行為無法被形式、測試、軌跡或政策描述，等價判定會持續存在盲區。

### 21.2 觀測者集合不完整

若漏掉安全、運維或外部環境觀測者，候選可能在未被注意的維度中破壞身分。

### 21.3 驗證不可負擔

若強等價證明成本高於全部最佳化收益，系統只能使用分層或風險化驗證。

### 21.4 版本鏈過長

若長期演化無法對初始錨點重驗，漂移可能累積。

### 21.5 契約被最佳化器操弄

AI 可能透過縮小輸入域、改寫指標或放寬品質條件製造虛假改良。契約修改權必須與候選生成權分離。

### 21.6 身分根被濫用

商業或治理主體可能維持相同產品名稱與根識別，卻實際進行重大契約變更。因此，身分根不能取代語義版本與契約證書。

---

## 22. 理論邊界

本文不主張：

- 普遍程式等價可以被完全自動決定；
- 所有隱含行為都應被保留；
- 名稱相同就代表身分相同；
- 輸出相同就代表應用完全相同；
- 契約越嚴格越好；
- 多變體必須在所有維度完全一致；
- 功能升級可以偽裝為最佳化；
- 歷史連續性可以取代當前驗證。

本框架的目標不是消除所有身分爭議，而是讓每次跨代演化都能清楚回答：

1. 哪些東西被承諾不變？
2. 哪些東西允許變動？
3. 誰有資格觀測？
4. 等價在哪些環境成立？
5. 哪些風險仍未被排除？
6. 這次變更屬於最佳化、升級、分叉，還是身分斷裂？

---

## 23. 主要理論命題

### 命題一：身分—內容分離命題

應用身分不等同任何單一文字、二進位或投影內容。

### 命題二：契約身分命題

應用身分主要由功能契約、觀測邊界、治理根與歷史連續性構成。

### 命題三：多層等價命題

輸出值等價不足以保證完整應用等價；狀態、副作用、時間、權限與生命週期可能同樣構成身分。

### 命題四：觀測者相對命題

等價總是相對於觀測者集合、適用域與容許誤差，而非無條件抽象宣告。

### 命題五：契約漂移命題

只驗證鄰代版本不足以防止長期漂移，必須保留初始錨點與歷史不變量。

### 命題六：版本多軸命題

語義版本、實現版本、證書版本與環境版本應被分開管理。

### 命題七：變更分類命題

純最佳化、兼容演化、功能升級、產品分叉與身分斷裂是不同事件，不能共用同一提交語義。

### 命題八：身分可演化命題

身分不是永遠靜止；契約可以透過顯式遷移合法更新，但不能被候選最佳化器暗中改寫。

---

## 24. 結論

本文回答了 AI 自適應封裝最根本的問題：

> 在程式碼、演算法、資料結構、封裝與硬體映射都被反覆重寫後，什麼仍使它成為同一個應用？

答案不是同一份原始碼，也不是同一個 EXE、DLL、套件名稱或品牌標記，而是：

$$
\boxed{
\mathcal I_{\mathrm{app}}
=
\left(
r^\ast,
\mathcal C,
\Omega,
v_s,
\mathcal G,
H
\right).
}
$$

也就是：

- 同一個權威身分根；
- 同一組或合法遷移後的功能契約；
- 明確的觀測者與觀測邊界；
- 可追溯的語義版本；
- 合法治理規則；
- 連續且可驗證的歷史。

版本之間的等價不是單一布林值，而是一組分層、相對且帶適用域的承諾：

$$
P_a
\equiv_{\mathcal C,\Omega,D,\epsilon}
P_b.
$$

AI 可以自由搜索更好的實現，但不能自行縮小輸入域、放寬品質、增加權限、改變錯誤語義或移除回滾，然後仍把結果稱為同一功能的最佳化。

為防止多代漂移，每一代必須同時維持：

$$
P_{n+1}\equiv_{\mathcal C}P_n,
$$

$$
P_{n+1}\equiv_{\mathcal C}P_0,
$$

以及：

$$
\operatorname{Inv}_{H}(P_{n+1})=1.
$$

本文的核心結論為：

$$
\boxed{
\text{同一個應用，不是同一份程式碼；而是同一個可追溯、可驗證、可治理的功能承諾。}
}
$$

只有先建立這個身分錨點，後續的演化膠囊、多版本競爭、全層最佳化與無限遞歸改良，才不會從「持續最佳化」滑向「持續改變自己究竟是什麼」。

---

## 系列內部定位

本文為《AI 自適應封裝與遞歸演化計算論》第二篇。

第一篇建立總命題與演化膠囊；本文建立跨代應用身分、功能契約與觀測等價框架。

下一篇為：

**《從 EXE 與 DLL 到演化膠囊：自適應封裝的新本體》**。

---

## 前置文件

1. Neo.K with Aletheia，《程式完成之後：AI 自適應封裝與遞歸演化計算論的總命題》。  
2. Neo.K with Aletheia，《多重投影程式論：原始碼不再是程式本體》。  
3. Neo.K with Aletheia，《穩定核心與動態表面：自適應程式語言的分層設計》。  
4. Neo.K with Aletheia，《多重投影程式系統技術架構白皮書：權威 IR、可驗證回寫與 AI 原生治理》。  
5. Neo.K with Aletheia，《解空間幾何計算論》系列。