功能不變，實現可變

從 AEREC 到觀測保持型自適應計算

English Title: Stable Function, Mutable Implementation: From AEREC to Observer-Preserving Adaptive Computation
系列：《觀測保持型自適應計算》（Observer-Preserving Adaptive Computation, OPAC）第 1 篇
系列編號： EML-OPAC-2026-01
作者： Neo.K
協作整理： Aletheia
機構： EveMissLab／一言諾科技有限公司
版本： v0.1
日期： 2026-08-10
文件定位： AEREC × CDI 橋接母論文／Runtime 身分與實現分離／觀測保持型在線演化
證據成熟度： E0–E1。AEREC 已完成跨代身分、觀測等價、候選驗證與回滾框架；JIT、tiered compilation、runtime profiling 等公開技術證明「執行期可改變實現」本身已有成熟前例。本文新增的是將功能契約、觀測等價與 CDI Runtime 治理統一成更廣義的在線實現演化框架，尚需工程驗證。

摘要

如果一個程式的原始碼、演算法、資料結構、中介表示、編譯方式、Runtime 策略、硬體映射與平行化拓撲都可以改變，那麼「同一個程式」究竟由什麼保持？

《AI 自適應封裝與遞歸演化計算論》（AEREC）已提出一個明確答案：應用身分不等於某一份 source code、EXE 或單一實現，而由權威身分根、功能契約、合法觀測者、語義版本、治理規則與可追溯歷史共同構成。AEREC 允許每一代改變演算法、資料結構、IR、編譯、執行時、封裝與硬體映射，只要求新版本在指定契約與觀測條件下保持等價。

近期 CDI / AIVS 研究則從另一個方向到達相近結構：AI 不必親自完成所有計算，而可以成為計算域的語義—因果控制面；Runtime 可以依當前 world state、dependency、hardware state、profiling evidence 與 resource policy 改變 execution plan，並透過 Candidate → Verify → Commit 保持正式狀態安全。

本文指出，這兩條研究線之間存在一個更一般的共同形式：

\boxed{ \text{Stable Observable Identity} + \text{Mutable Implementation Form}. }

AEREC 主要處理：

\boxed{ \text{跨代實現演化} }

而 CDI 開始處理：

\boxed{ \text{執行期實現演化}. }

本文因此提出 觀測保持型自適應計算（Observer-Preserving Adaptive Computation, OPAC）作為橋接框架。

令應用身分為：

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

令當前具體執行實現為：

\pi_t.

OPAC 不要求：

\pi_{t+1}=\pi_t.

它要求的是：

\boxed{ \pi_{t+1} \equiv_{\mathcal C,\Omega,D,\epsilon} \pi_t, }

並為避免多代／多時段漂移，同時維持：

\boxed{ \pi_{t+1} \equiv_{\mathcal C,\Omega,D,\epsilon} \pi_0. }

因此，Runtime 可以在合法等價類中改變演算法、串行／並行拓撲、CPU/GPU/NPU 映射、tick frequency、simulation resolution、cache/retrieval、precision、speculation、data representation、verification depth 與 AI attention allocation，只要所有契約承認的觀測者仍得到可接受的功能、狀態、行為、副作用、安全、時間、錯誤與恢復語義。

本文特別反對一個過度簡化：

\boxed{ \text{使用者看不到} \not\Rightarrow \text{內部可以任意改}. }

合法觀測者不只有使用者，也包括 API、state observer、security、operator、auditor 與 environment。真正的自由度存在於：

\boxed{ \text{契約未區分、且所有必要觀測保持等價的實現空間}. }

本文最後建立 OPAC 的母形式、在線適應算子、執行等價類、漂移防護與 AEREC/CDI 對接關係，為下一篇《程式作為動態渲染：執行等價類、觀測纖維與 Runtime 重實現》建立形式地基。

關鍵詞

觀測保持型自適應計算、OPAC、AEREC、CDI、程式身分、功能契約、觀測等價、Runtime adaptation、dynamic implementation、JIT、adaptive compilation、Candidate/Commit、execution rendering

0. 系列定位

本系列固定四篇：

《功能不變，實現可變：從 AEREC 到觀測保持型自適應計算》
《程式作為動態渲染：執行等價類、觀測纖維與 Runtime 重實現》
《觀察者看不到的自由度：從功能契約到自適應世界狀態機》
《從跨代演化到在線遞歸：AEREC × CDI × ACR × AIVS 的統一 Runtime》

第 1 篇建立母命題；第 2 篇建立等價類／觀測纖維與「動態渲染」形式；第 3 篇進入遊戲、沙盒與世界狀態機；第 4 篇統一 Runtime 後封頂。

1. 問題不是「程式能不能改」

現代計算系統早已證明 Runtime 不是完全靜態。JIT compiler 可以 runtime compile、lazy compile、profile hot code、tiered optimize、invalidate assumptions、deoptimize、recompile。

因此本文不是主張：

程式執行時可以產生不同 machine code。

這不是新的。

真正的問題是：

如果 AI 可以跨越多個抽象層改變實現，究竟什麼仍使它保持為同一個應用？

2. 程式身分不能再綁定單一實現物

若只改：

MachineCode_A\rightarrow MachineCode_B,

而高階語義顯然一致，問題相對簡單。

但如果 AI 可以改：

\boxed{ Algorithm + DataStructure + IR + Runtime + Parallelism + HardwareMapping, }

「同一程式」不能再依 source hash、binary hash、file name 或 process image 定義。

3. AEREC 已給出身分核心

AEREC 將應用身分寫成：

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

其中：

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

這是 OPAC 的身分地基。

4. 功能契約不是只有輸入／輸出

AEREC 的功能契約可表示為：

\boxed{ \mathcal C = ( \mathcal I, \mathcal O, \mathcal S, \mathcal E, \mathcal P, \mathcal Q, \mathcal R, \mathcal T, \mathcal A, \mathcal X ). }

分別涵蓋輸入、輸出、狀態、副作用、權限、品質、錯誤、時間、可用性與外部依賴。

所以：

\boxed{ SameOutput }

只是：

\boxed{ SameApplication }

的一小部分。

5. 觀測者集合

AEREC 定義：

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

不同觀測者看到不同投影。

對每個 $\omega\in\Omega$ ：

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

完整觀測：

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

6. 「使用者看不到」為什麼太弱？

假設新 implementation：

使用者輸出完全相同；
但偷寫額外檔案；
增加網路傳輸；
改變 RNG；
破壞 rollback；
latency 增加十倍。

則：

Obs_{\mathrm{user}}(P_a) = Obs_{\mathrm{user}}(P_b)

不表示：

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

因此真正的自由度不是「玩家現在沒看到」，而是「契約承認的全部必要觀測都沒有把兩個實現區分開」。

7. 實現自由度

本文定義：

\boxed{ ImplementationFreedom = \text{契約未區分的內部差異}. }

更精確地：若

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

則 $P_a$ 與 $P_b$ 的內部差異在該契約語境下可被視為合法實現自由。

8. 等價是相對的

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

依賴：

$\mathcal C$ ：契約；
$\Omega$ ：觀測者；
$D$ ：適用域；
$\epsilon$ ：容許誤差。

不是宇宙絕對不可區分。

9. 適用域 $D$

如果新實現只在：

x\in D_1

等價，而原應用要求：

x\in D_0, \quad D_1\subset D_0,

就不能偷偷把 $D_0$ 縮成 $D_1$ ，再宣稱「功能不變」。

10. 誤差 $\epsilon$

純整數函數可能要求：

\epsilon=0.

浮點 simulation 可能允許：

\epsilon>0.

但 $\epsilon$ 必須由契約決定，而不能由 optimizer 為了 speedup 自行放寬。

11. AEREC 的跨代形式

AEREC 原本要求：

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

更完整地可寫：

P_{n+1} \equiv_{\mathcal C,\Omega,D,\epsilon} P_n.

12. 防止逐代漂移

只比較相鄰代：

P_{n+1}\equiv P_n

仍可能累積 drift。

因此還要維持：

\boxed{ P_{n+1} \equiv_{\mathcal C,\Omega,D,\epsilon} P_0. }

並要求歷史 invariant：

\operatorname{Inv}_H(P_{n+1})=1.

13. AEREC 的真正對象

所以 AEREC 的對象不是：

\boxed{OneBinary.}

而是：

\boxed{ OneApplicationIdentity + ManyLegalImplementations. }

14. CDI 帶來的新問題

CDI 不只問：

下一版怎麼改？

它開始問：

這一刻應該用哪個 execution form？

令：

\pi_t

為時刻 $t$ 的具體執行實現。

15. $\pi_t$ 可以是什麼？

例如：

\boxed{ \pi_t = ( Algorithm_t, Topology_t, Backend_t, Resolution_t, Frequency_t, Precision_t, Cache_t, Verification_t ). }

16. 下一刻不必相同

\boxed{ \pi_{t+1} \neq \pi_t. }

但應用身分仍可能保持：

\boxed{ \mathcal I_{\mathrm{app}}(t+1) = \mathcal I_{\mathrm{app}}(t). }

17. OPAC 母命題

只要一個新的執行實現在指定功能契約、合法觀測者、適用域與誤差容忍下保持觀測等價，那麼實現形態可以在執行期間持續改變，而不必將每一次改變視為新的應用身分。

形式：

\boxed{ \pi_{t+1} \equiv_{\mathcal C,\Omega,D,\epsilon} \pi_t. }

18. Root Equivalence

同時要求：

\boxed{ \pi_{t+1} \equiv_{\mathcal C,\Omega,D,\epsilon} \pi_0. }

避免 runtime adaptation 逐步漂移。

19. Runtime Adaptation Operator

定義：

\boxed{ \Phi: ( \pi_t, S_t, H_t, E_t, G_t ) \rightarrow \pi_{t+1}^{cand}. }

其中：

$\pi_t$ ：當前實現；
$S_t$ ：應用／世界狀態；
$H_t$ ：硬體／backend 狀態；
$E_t$ ：證據與 profiling；
$G_t$ ：目標／policy；
$\pi_{t+1}^{cand}$ ：候選新實現。

20. 為什麼是 Candidate？

因為：

\boxed{ AIProposal \neq ValidImplementation. }

所以 $\pi_{t+1}^{cand}$ 不能立即取代 $\pi_t$ 。

21. 驗證與提交

需要：

\boxed{ Verify( \pi_t, \pi_{t+1}^{cand}, \mathcal C, \Omega, D, \epsilon ). }

只有：

Verify=PASS

才：

\boxed{ \pi_{t+1} = Commit( \pi_{t+1}^{cand} ). }

若失敗：

\pi_{t+1}=\pi_t

或執行 fallback。

22. OPAC 基本閉環

\boxed{ Observe \rightarrow Diagnose \rightarrow Generate \rightarrow Shadow \rightarrow Verify \rightarrow Commit \rightarrow Observe. }

這直接承接 AEREC 的跨代改良閉環，只是將時間索引從「版本代」移到「Runtime 狀態」。

23. AEREC 與 OPAC 的差別

AEREC 主要索引：

n=\text{generation/version}.

OPAC 主要索引：

t=\text{runtime state/time}.

AEREC：

P_0\rightarrow P_1\rightarrow P_2\rightarrow\cdots

OPAC：

\pi_0\rightarrow\pi_{t_1}\rightarrow\pi_{t_2}\rightarrow\cdots

並且可以在同一次長期 process / world execution 中完成。

24. 雙時間尺度

更完整的軟體演化有兩個時間尺度：

\boxed{ n:\text{跨版本慢時間}}

與：

\boxed{ t:\text{執行期快時間}}.

25. 雙層遞歸

跨代：

\boxed{ P_{n+1} = \Psi(P_n,\text{long-term evidence}). }

每個版本內：

\boxed{ \pi_{t+1} = \Phi(\pi_t,\text{runtime evidence}). }

26. Runtime 學習與版本演化

Runtime 蒐集：

successful routes；
failed routes；
workload profiles；
drift；
rollback；
performance。

這些可回到：

P_{n+1}.

而新版本又可把歷史成功 route 編入 policy、cache、classifier、compiler hints。

因此：

\boxed{ RuntimeLearning \leftrightarrow VersionEvolution. }

27. JIT 與 OPAC 的關係

現有 JIT 已可 runtime profile、hot code compilation、lazy compilation、tiered optimization 與 deoptimization。

這些可視為 OPAC 的部分低階前例或相鄰實作模式。

但本文不宣稱：

JIT=OPAC.

28. 差異一：改變尺度

傳統 JIT 多半改：

IR/MachineCode/Inlining/Optimization.

OPAC 希望允許更廣：

Algorithm + DataStructure + TaskTopology + Resolution + Backend + Frequency.

29. 差異二：身分治理

JIT 的 correctness 一般由 compiler / VM semantics 保證。

OPAC 因 AI 可能提出跨抽象層新實現，額外需要：

\boxed{ \mathcal C+\Omega+D+\epsilon. }

30. 差異三：觀測多元

OPAC 不只優化 execution time。

它可能契約化：

state；
security；
permission；
energy；
quality；
recoverability；
external effects。

31. 差異四：候選治理

OPAC 明確要求：

\boxed{ Candidate \rightarrow Evidence \rightarrow Commit. }

AI 無法以「我認為等價」取代驗證。

32. 現有 Runtime 最佳化仍然重要

LLVM ORC、HotSpot 與 GraalVM 類系統的意義不是替 OPAC 提供完整證明，而是證明：

\boxed{ ImplementationForm }

本來就不必完全固定。

OPAC 是把 adaptive compilation 的自由度進一步擴大並契約化。

33. ACR 的接口

如果每個 state change 都重新分析所有 implementation，成本會失控。

因此 ACR 可控制：

adaptation frequency；
analysis depth；
evidence retrieval；
verifier strength；
model cost。

OPAC 不要求每時每刻都改。

若：

ExpectedGain \le AdaptationCost,

合法 action：

\boxed{NOOP.}

34. 穩定本身也是選擇

成熟 adaptive system 不應：

\boxed{ChangeForTheSakeOfChange.}

而應：

\boxed{ChangeOnlyWhenExpectedUtilityPositive.}

35. Utility

定義：

\boxed{ U(\pi') = Benefit(\pi') - TransitionCost - VerificationCost - Risk. }

只考慮：

U>0.

36. 觀測等價不等於 bit equality

某些純函數要求 Exact；某些 simulation 允許 Approximate；某些 stochastic systems 要求 Distributional。

所以 equivalence level 必須由 contract 決定。

值等價：

f_a(x)=_\epsilon f_b(x).

行為等價可要求公開 trace 保持一致或指定 partial-order 等價。

狀態等價：

\boxed{ \alpha(S_a^{t+1}) = \alpha(S_b^{t+1}). }

其中 $\alpha$ 是契約承認的狀態抽象。

37. 為什麼只比較當下畫面不夠？

可能：

Obs(S_a^t)=Obs(S_b^t)

但內部 RNG／latent state 不同，造成：

Obs(S_a^{t+1}) \neq Obs(S_b^{t+1}).

所以 OPAC 必須關注：

\boxed{TraceEquivalence}

而不只 snapshot equivalence。

38. Rolling Horizon

對長期運行系統，完整無限未來等價通常不能直接工程驗證。

可使用：

\boxed{Horizon_T}

配合：

invariants；
replay；
differential tests；
runtime monitoring；
rollback。

39. OPAC 的證明責任

本文不宣稱：

所有 implementation equivalence 都可被完全判定。

相反，OPAC 需要：

\boxed{LayeredEvidence.}

例如：

E_0:\text{output sample}

E_1:\text{unit/property tests}

E_2:\text{state/trace differential}

E_3:\text{invariants/static proof}

E_4:\text{shadow runtime}

E_5:\text{repeated production evidence}.

40. 權限與證據耦合

\boxed{ AdaptationAuthority \le EvidenceStrength. }

低證據：Observe / Advise。

中證據：Shadow。

高證據：Low-Risk Commit。

高風險領域仍可要求 Human / External Authority。

41. 身分變更與實現變更

如果：

\mathcal C

真的要改，那不是 implementation optimization，而是：

\boxed{SemanticMigration.}

Semantic Migration 必須顯式改變：

v_s.

42. 不能偷偷改契約

AI 不可以為了 speedup 偷改：

品質；
世界規則；
input domain；
tolerance；
security observer；
rollback requirement。

否則：

\boxed{ Optimization \rightarrow SemanticDrift. }

43. 合法實現等價類

令：

\boxed{ [P]_{\mathcal C,\Omega,D,\epsilon} = \{ Q: Q\equiv_{\mathcal C,\Omega,D,\epsilon}P \}. }

這是所有合法實現的等價類。

44. OPAC 的在線搜尋空間

AI 不應在：

AllPrograms

中自由亂走。

而應在：

\boxed{ [P]_{\mathcal C,\Omega,D,\epsilon} }

附近生成 candidate。

Candidate 可以暫時出界，但不能直接成為 active implementation。

45. Commit Gate

只有當：

Q^{cand}

有足夠證據位於可接受等價區，才：

Commit(Q^{cand}).

46. OPAC 核心 Invariants

I1 — Identity Root Stable

$r^\ast$ 不由 optimizer 偷改。

I2 — Contract Governed

$\mathcal C$ 只能經顯式 migration 改變。

I3 — Observer Set Governed

不能偷偷刪掉 security / state / audit observer。

I4 — Root Equivalence

不能只保持相鄰版本。

I5 — Candidate Before Commit

新實現先是 candidate。

I6 — Evidence Retained

證據可回溯。

I7 — Rollback Exists

適用時必須可恢復。

47. OPAC 與 CDI

CDI 提供：

\boxed{ \text{Implementation Selection / Routing Mechanism}. }

OPAC 提供：

\boxed{ \text{什麼改變仍然算合法同一應用}. }

CDI without OPAC 的風險是：route 變快了，但功能語義也變了。

OPAC without CDI 則只有身分／等價理論，缺少 Runtime observation、routing、AIVS 與 commit mechanism。

48. 合併

\boxed{ OPAC = AERECIdentity + CDIRuntimeAdaptation + EquivalenceGovernance. }

49. OPAC 與 AIVS

AIVS 回答：

什麼變化值得被 AI 看？

OPAC 回答：

看完後，什麼變化仍可被當成同一功能？

50. OPAC 與 Candidate/Commit

OPAC 不信任 Generation 本身。

它信任：

\boxed{ Generation + Verification + GovernedCommit. }

51. OPAC 與 24／72

24／72 可以描述：

\pi_t

目前的計算形態。

但：

p(\pi_t) \neq \mathcal I_{\mathrm{app}}.

計算範式可以變，應用身分不一定變。

例如：

\mathsf S\rightarrow\mathsf P

序列變並行；或：

\mathsf J/\mathsf S\rightarrow\mathsf R

搜尋變 retrieval。只要契約保持，仍可屬同一應用。

52. CPU → GPU 不是身分變更

硬體映射：

CPU\rightarrow GPU

本身不是 semantic migration。

前提仍是：

Equivalent.

53. 高解析 → 低解析更敏感

如果：

Resolution\downarrow

仍在：

\epsilon

內，可合法。

否則就是 Contract Change，而不是單純最佳化。

54. 可反駁命題 H1

若在實際系統中，任何有意義的跨演算法／拓撲／解析度 Runtime 改變都無法在合理成本下建立足夠觀測等價證據，則 OPAC 的工程適用範圍非常窄。

55. 可反駁命題 H2

若：

AdaptationCost\ge Benefit

在絕大多數 workload 中成立，在線 adaptation 不具優勢。

56. 可反駁命題 H3

若跨代 AEREC 已足以處理所有有價值 adaptation，Runtime 級 OPAC 沒有額外價值。

57. 可反駁命題 H4

若合法觀測契約必須完整描述全部 internal state 才能安全，則：

ImplementationFreedom\rightarrow0.

OPAC 的自由度消失。

58. 可反駁命題 H5

若 AI 候選錯誤率／驗證成本過高，則 AI 未必適合作 controller。

OPAC 可退化為：

deterministic optimizer；
search；
compiler policy；
learned router；
hybrid controller。

所以：

\boxed{OPAC\neq AIOnly.}

59. 公開技術前例的正確位置

LLVM ORC：lazy JIT、concurrent compilation、IR optimization layer、remote execution。

HotSpot：runtime profiling、tiered compilation、adaptive compilation。

GraalVM：hotspot detection、optimizing compiler、partial evaluation / runtime optimization。

它們支持：

\boxed{RuntimeImplementationCanAdapt.}

60. 它們不能直接支持什麼？

不能直接推出：

任意演算法可在線替換；
任意資料結構可在線改變；
任意世界模擬可降解析；
觀測等價一定可驗證；
AI governance 一定有淨收益。

這些仍是 OPAC 的研究問題。

61. 「動態渲染」在本篇只作預告

本文先確定：

\boxed{Identity\neq Implementation.}

下一篇才把：

[P]_{\mathcal C,\Omega,D,\epsilon}

看成 Runtime 可渲染的實現空間。

62. 下一篇核心問題

如果所有合法 implementation 形成等價類 $[P]$ ，那麼：

AI 是否可以把當前 world / hardware / context 當成「渲染條件」，在 $[P]$ 中選擇一個當下最適實現？

下一篇將引入：

觀測纖維；
等價類；
implementation graph / geometry；
Execution Rendering；
runtime re-materialization；
current-state vs future-trace equivalence；
observer-relative freedom。

63. 本篇最核心的一句

\boxed{ \text{程式的身分可以穩定， 而程式的實現可以持續改變。} }

64. 更精確的一句

\boxed{ \text{真正被保存的，不必是程式碼； 可以是可追溯、可治理、可驗證的觀測功能身分。} }

65. 結論

AEREC 已經建立：

\boxed{ \text{程式完成} \not\Rightarrow \text{程式停止演化}. }

CDI 則進一步提出：

\boxed{ \text{程式正在執行} \not\Rightarrow \text{執行形態必須固定}. }

兩者交會後得到：

\boxed{ \text{Stable Observable Identity} + \text{Mutable Runtime Implementation}. }

本文將其命名為：

Observer-Preserving Adaptive Computation

觀測保持型自適應計算（OPAC）

OPAC 的核心不是允許 AI 任意修改程式，而是建立一個受約束的自由空間：

\boxed{ [P]_{\mathcal C,\Omega,D,\epsilon}. }

AI／controller 可以在這個空間裡搜索、分叉、shadow、比較、切換與回退，但正式 active implementation 必須持續滿足：

\boxed{ \pi_t \equiv_{\mathcal C,\Omega,D,\epsilon} \pi_0. }

因此真正不變的不是 Source、Binary、Algorithm、Topology 或 Hardware；真正不變的是：

\boxed{ \text{Contracted Observable Identity}. }

這也為下一篇建立最直接的入口：

如果身分是一個觀測等價類，那麼一個正在運行的程式，就可以被理解成在同一等價類中持續「重新渲染」其當下實現。

參考資料

內部研究線

Neo.K with Aletheia，《程式完成之後：AI 自適應封裝與遞歸演化計算論的總命題》，2026。
Neo.K with Aletheia，《同一個應用是什麼：功能契約、觀測等價與程式身分》，2026。
Neo.K with Aletheia，《無限遞歸改良動力學：觀測、診斷、生成、驗證與提交》，2026。
Neo.K with Aletheia，《功能不變如何被證明：等價證書、差分驗證與安全回滾》，2026。
Neo.K with Aletheia，《AI 自適應封裝與遞歸演化系統技術架構白皮書》，2026。
Neo.K with Aletheia，《計算域支配智能：AI 語義控制面與自適應多 X 計算》系列，2026。
Neo.K with Aletheia，《Adaptive Cognitive Runtime 工程白皮書》，2026。

2026-08-10 Fresh Technical References

LLVM Project, ORC Design and Implementation, current LLVM documentation。
LLVM Project, Building an ORC-based JIT, current LLVM documentation。
Oracle, Java HotSpot Virtual Machine Performance Enhancements, Java 17 documentation。
GraalVM, GraalVM as a Java Virtual Machine, current reference manual。
GraalVM, Optimizing Truffle Interpreters, current reference manual。

版本紀錄

v0.1 / 2026-08-10：建立 OPAC 母命題、AEREC 跨代演化與 CDI 在線演化之雙時間尺度、Contracted Observable Identity、Runtime Adaptation Operator、Root Equivalence、Evidence/Authority 邊界、OPAC 與 JIT/HotSpot/GraalVM 的差異，以及下一篇 Execution Rendering 接口。

01_功能不變實現可變_從AEREC到觀測保持型自適應計算_v0.1