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

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. 理論邊界

本文不主張：

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

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

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

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 到演化膠囊：自適應封裝的新本體》。

前置文件

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

同一個應用是什麼_功能契約觀測等價與程式身分_v0.1