# 候選不是提交
## 多 X 計算中的因果校正、錯位檢測與可恢復執行

**English Title:** *A Candidate Is Not a Commit: Causal Correction, Misalignment Detection, and Recoverable Execution in Multi-X Computation*  
**系列：**《計算域支配智能：AI 語義控制面與自適應多 X 計算》第 3 篇  
**系列代號：** CDI / AIVS  
**文件編號：** EML-CDI-03-CCRE-2026-v0.1  
**作者：** Neo.K  
**協作整理：** Aletheia  
**機構：** EveMissLab／一言諾科技有限公司  
**版本：** v0.1  
**日期：** 2026-08-10  
**文件類型：** 計算架構理論論文／一致性與提交協議／可恢復執行方法論  
**證據成熟度：** E0–E1。本文大量借鑑 transaction、optimistic conflict detection、sequence counter、lease、WAL 等成熟 primitive，但「將 AI 語義判斷作為多 X 計算 candidate/commit 的高階控制面」仍是本文提出之架構假說，需要獨立 MVP 驗證。

---

## 摘要

前兩篇分別提出計算域支配智能（CDI）與 AI 垂直同步（AIVS）。CDI 將 AI 從主要計算者改置於語義—因果控制平面；AIVS 則透過 Worker → Relay → Governor 的分層結構，使 AI 認知成本不必隨 raw operation count 同步膨脹。

然而，只要系統開始允許：

- 多核心並行；
- 多 GPU／NPU 異質執行；
- speculative execution；
- runtime rerouting；
- AI 建議的 parallelization；
- Relay 局部自治；

就會出現一個更根本的問題：

> **某個計算單元「算出了一個結果」，是否就代表這個結果有資格成為正式程式狀態？**

本文提出核心分離：

$$
\boxed{
ComputedResult
\neq
CommittedProgramState.
}
$$

並將任何尚未通過狀態版本、因果父關係、依賴、invariant、權限、拓撲、重複提交與必要語義檢查的輸出稱為 **計算候選**（Compute Candidate）。只有通過 **Semantic-Causal Fence** 後，候選才可成為 commit。

其基本流程為：

$$
\boxed{
Execute
\rightarrow
Candidate
\rightarrow
Verify
\rightarrow
Fence
\rightarrow
Commit
\rightarrow
Receipt.
}
$$

失敗時：

$$
\boxed{
Candidate
\rightarrow
Reject
\lor
Retry
\lor
Recompute
\lor
Reroute
\lor
Rollback
\lor
Compensate.
}
$$

本文特別區分三種「回退」：

1. **Candidate Discard**：候選尚未產生正式副作用，直接丟棄；
2. **State Rollback**：已在隔離或可版本化狀態上修改，可恢復 snapshot / journal；
3. **Compensating Correction**：副作用已進入不可逆或不適合倒放的外部世界，只能追加反向／補償行動，而不能假裝舊事件未發生。

此區分對遊戲、GUI、網路、檔案、支付、硬體控制與實體設備尤其重要。

本文進一步提出：

- Compute Candidate Object（CCO）；
- Commit Receipt；
- Semantic-Causal Fence（SCF）；
- Epoch / Lease / Fencing Token；
- Read Version / Input Digest；
- Idempotency Key；
- Candidate DAG；
- Local / Domain / Global Commit；
- Causal Misalignment Detection；
- Stale Read / Stale Write；
- Shadow Execution；
- Effect Barrier；
- Conflict Classes；
- Append-Only Correction；
- Recovery Ladder；
- Commit Uncertainty；
- Proof-Carrying Candidate。

本文指出，這些設計與資料庫 transaction、FoundationDB optimistic conflict detection、SQLite atomic commit / WAL、Linux sequence counters、Intel TSX 與 Kubernetes Lease 等成熟技術有結構親緣，但 AIVS/CDI 不應把它們混成同一層：低階一致性仍交給既有硬體／OS／資料庫 primitive；AI 只補充傳統機制難以直接表達的高階語義依賴、因果角色與跨區域工作目的。

本文最後提出十組可反駁假說與一組 source-visible／game-loop MVP 測試，作為下一篇 24／72 Runtime Routing 的提交安全基礎。

---

## 關鍵詞

Candidate/Commit、計算域支配智能、CDI、AI 垂直同步、AIVS、Semantic-Causal Fence、Speculative Execution、Rollback、Compensation、Stale State、Epoch、Lease、Fencing Token、Idempotency、Optimistic Concurrency、遊戲加速、多 X 計算

---

# 0. 系列位置

第一篇：

$$
\boxed{
TraditionalCompute
+
AISemanticControlPlane.
}
$$

第二篇：

$$
\boxed{
DenseCompute
+
SparseAdaptiveCognition.
}
$$

第三篇現在補上：

$$
\boxed{
DenseCompute
+
SparseCognition
+
VerifiedCommit.
}
$$

因此目前 CDI 的最小閉環變為：

$$
\boxed{
Observe
\rightarrow
Route
\rightarrow
Execute
\rightarrow
Candidate
\rightarrow
Verify
\rightarrow
Commit.
}
$$

---

# 1. 今日跨任務實驗提供了什麼工程原型？

2026-08-09 的十席跨任務實驗中，固定接力曾讀到 stale response；自由接力則出現錯值、舊值與拒絕。

重要的不是「AI 有錯」。

真正重要的是：

$$
\boxed{
錯誤發生
\neq
正式狀態被錯誤修改.
}
$$

因為候選輸出與正式提交被分離。

這個結構可以從 AI 協作直接搬到一般計算。

---

# 2. 計算中最危險的隱含假設

很多 pipeline 默認：

$$
FunctionReturns
\Rightarrow
ResultAccepted.
$$

單線、同步、強型別且無共享副作用的簡單程式中，這通常合理。

但在多 X 計算中：

$$
\boxed{
Return
\neq
Validity.
}
$$

因為結果可能：

- 基於舊 state；
- 基於錯 dependency；
- 使用舊 topology；
- side effect 已被其他 worker 改變；
- 超過 deadline；
- 來自已失效 lease；
- 重複執行；
- 被 speculative branch 產生；
- 語義上已不再符合當前 task contract。

---

# 3. Compute Candidate

定義一個計算區域：

$$
E_i.
$$

輸出：

$$
r_i.
$$

在正式驗證前：

$$
\boxed{
c_i=(r_i,\mu_i)
}
$$

稱為 Compute Candidate。

 $\mu_i$ 為 metadata。

---

# 4. Compute Candidate Object（CCO）

最低：

```yaml
candidate:
  candidate_id:
  task_id:
  region_id:
  flow_id:

  producer:
    worker_id:
    relay_id:
    runtime_id:

  version:
    epoch:
    topology_version:
    policy_version:
    input_state_version:

  causal:
    parent_refs:
    read_set_digest:
    input_digest:
    output_digest:

  execution:
    started_at:
    completed_at:
    deadline:
    speculative:
    side_effect_class:

  validation:
    invariant_status:
    dependency_status:
    semantic_status:
    confidence:
    evidence_refs:

  authority:
    lease_id:
    fencing_token:
    commit_scope:

  idempotency_key:
```

---

# 5. 候選的第一原則

$$
\boxed{
Candidate
}
$$

可以：

- 錯；
- stale；
- duplicate；
- speculative；
- incomplete；
- contradicted。

這不是 bug。

只要：

$$
\boxed{
InvalidCandidate
\not\Rightarrow
InvalidCommit.
}
$$

---

# 6. Commit 是什麼？

Commit 是：

> 把某個候選結果變成後續正式計算可以依賴的狀態。

定義：

$$
\boxed{
Commit(c_i,S_t)
\rightarrow
S_{t+1}.
}
$$

其語義強度遠高於：

$$
Return(c_i).
$$

---

# 7. Commit 必須產生 Receipt

最低：

```yaml
commit_receipt:
  commit_id:
  candidate_id:
  previous_state_version:
  committed_state_version:
  commit_scope:
  validator_set:
  epoch:
  fencing_token:
  evidence_digest:
  committed_at:
```

---

# 8. 為什麼 Receipt 很重要？

沒有 Receipt：

$$
Silence
$$

可能表示：

- 沒提交；
- 提交成功但回覆遺失；
- timeout；
- crash；
- duplicate retry；
- verifier crash。

所以：

$$
\boxed{
Attempt
\neq
KnownCommit.
}
$$

這在 transaction system 中也是重要問題。

---

# 9. Commit Uncertainty

定義：

$$
\boxed{
CommitUnknown.
}
$$

意思是：

> 呼叫方不知道某次 commit 究竟成功還是失敗。

此時如果無條件 retry：

$$
Effect
$$

可能發生兩次。

所以：

$$
\boxed{
Retry
}
$$

必須與：

$$
\boxed{
Idempotency
}
$$

共同設計。

---

# 10. Idempotency Key

每個可能重試的 effect：

$$
k=(task,region,epoch,logicalAction).
$$

要求：

$$
Apply(k,x)
$$

重送：

$$
n
$$

次，外部正式 effect 至多一次。

---

# 11. 不是所有動作天然 idempotent

例如：

```text
set volume = 30
```

通常可 idempotent。

但：

```text
add 30 coins
```

不是。

因此：

$$
\boxed{
OperationSemantics
}
$$

必須成為 CDI metadata。

---

# 12. Semantic-Causal Fence（SCF）

本文提出高階提交屏障：

$$
\boxed{
SCF(c,S_t)=1
}
$$

才允許：

$$
Commit(c).
$$

---

# 13. SCF 不等於 CPU Memory Fence

CPU memory fence 處理：

- memory ordering；
- visibility；
- reordering。

SCF 處理：

- state freshness；
- causal parents；
- dependency；
- invariant；
- authority；
- topology；
- semantic contract。

所以：

$$
\boxed{
MemoryFence
\neq
SemanticCausalFence.
}
$$

---

# 14. SCF 的最低條件

$$
\boxed{
SCF(c,S_t)
=
Fresh(c)
\land
ParentsValid(c)
\land
DependenciesValid(c)
\land
InvariantPass(c)
\land
AuthorityValid(c)
\land
TopologyCurrent(c)
\land
IdempotentSafe(c)
\land
SemanticAccept(c).
}
$$

---

# 15. Fresh

如果 candidate 基於：

$$
S_{840}
$$

但正式世界：

$$
S_{842},
$$

不一定自動失效。

真正判定應是：

$$
\boxed{
ReadSet(c)
\cap
Changed(S_{840}\rightarrow S_{842})
=
\varnothing?
}
$$

若交集空，可能仍可 commit。

若不空：

$$
Stale.
$$

---

# 16. 這比「版本號不同就全部重算」更精細

粗略：

$$
VersionMismatch
\Rightarrow
Reject.
$$

精細：

$$
VersionMismatch
+
NoRelevantConflict
\Rightarrow
PossibleCommit.
$$

這就是 optimistic concurrency 思想的重要啟示。

---

# 17. Read Version

每個 candidate 應記：

$$
v_r.
$$

表示：

> 我是基於哪個公共狀態視圖開始算的？

Commit 時：

$$
CurrentVersion=v_c.
$$

若：

$$
v_r\neq v_c,
$$

執行 conflict check。

---

# 18. Linux Sequence Counter 的啟示

Sequence counter 提供一個非常簡潔的 consistency pattern：

1. reader 先讀 sequence；
2. 讀資料；
3. 再讀 sequence；
4. 若 sequence 改變，retry。

抽象：

$$
\boxed{
Read
\rightarrow
ValidateVersion
\rightarrow
Accept/Retry.
}
$$

AIVS 可以把同一思想提升到 compute region。

---

# 19. 但 AI 不能取代低階 sequence validation

若一個 64-bit version counter 就能判定 stale：

$$
\boxed{
DoNotCallLLM.
}
$$

只有當：

> 版本不同，但是否真的語義衝突不明確

時，AI 才有價值。

---

# 20. Deterministic First

SCF 的檢查順序應優先：

1. schema；
2. epoch；
3. fencing；
4. idempotency；
5. version；
6. hash；
7. deterministic invariant；
8. static dependency。

最後才：

$$
SemanticAI.
$$

---

# 21. AI 是最後一層，不是第一層

所以：

$$
\boxed{
MachineCheck
\rightarrow
SemanticCheck
}
$$

而不是反過來。

這直接符合 ACR。

---

# 22. Conflict Classes

CDI 至少應辨識：

$$
\boxed{
\mathcal C
=
\{
RW,WW,Causal,Semantic,Temporal,Topology,Authority,Resource
\}.
}
$$

---

# 23. Read-Write Conflict

Worker A 讀：

$$
x_0.
$$

Worker B 已修改：

$$
x_0\rightarrow x_1.
$$

A 再根據舊值提交。

---

# 24. Write-Write Conflict

A：

$$
x\rightarrow a.
$$

B：

$$
x\rightarrow b.
$$

兩者都想成為正式狀態。

不能：

$$
LastWriteWins
$$

作為通用默認。

---

# 25. Causal Conflict

candidate 宣稱：

$$
Parent=B,
$$

但：

$$
B
$$

尚未 commit，或已被 supersede。

則：

$$
\boxed{
OrphanCandidate.
}
$$

---

# 26. Semantic Conflict

兩個結果在低階資料上都合法，

但高階目的互斥。

例如遊戲：

- physics worker 說「門已關閉」；
- script worker 說「角色已穿過門」。

數值各自可能合法，

全域語義卻：

$$
Conflict.
$$

---

# 27. Temporal Conflict

candidate 完成正確，

但錯過 deadline：

$$
t_{result}>t_{deadline}.
$$

real-time 系統中：

$$
\boxed{
LateCorrect
}
$$

可能等同：

$$
\boxed{
InvalidForCurrentEpoch.
}
$$

---

# 28. Topology Conflict

candidate 使用舊 route：

$$
G_{11},
$$

正式 topology：

$$
G_{12}.
$$

如果 route change 影響其 dependency：

$$
Reject/Reroute.
$$

---

# 29. Authority Conflict

producer 的：

$$
Lease
$$

已過期，

即使答案正確：

$$
\boxed{
NoCommitAuthority.
}
$$

正確性與授權必須分離。

---

# 30. Resource Conflict

兩個候選都要求：

$$
ExclusiveResource.
$$

例如：

- GPU queue；
- file handle；
- audio device；
- game state lock；
- physical device。

需重新排程。

---

# 31. Candidate DAG

多 X 計算的 candidate 不必是線性鏈。

可以：

$$
c_1
\rightarrow
\{c_2,c_3,c_4\}
\rightarrow
c_5.
$$

因此維持：

$$
\boxed{
CandidateDAG.
}
$$

---

# 32. Commit DAG

只有通過 fence 的 candidate 進：

$$
CommittedDAG.
$$

所以：

$$
CandidateDAG
\supseteq
CommittedDAG.
$$

---

# 33. 錯誤可以留在 Candidate DAG

這與 append-only 實驗紀錄一致：

$$
\boxed{
FailureHistory
}
$$

不需要被刪掉。

它可用於：

- debugging；
- learning；
- anomaly model；
- future routing。

---

# 34. 但錯誤不能變成 dependency root

Rejected candidate：

$$
status=REJECTED.
$$

後續合法 candidate 不應把它當正式 parent。

---

# 35. Candidate Lifecycle

$$
\boxed{
CREATED
\rightarrow
RUNNING
\rightarrow
PRODUCED
\rightarrow
VALIDATING
\rightarrow
COMMITTED
}
$$

旁路：

$$
VALIDATING
\rightarrow
REJECTED
$$

或：

$$
\rightarrow
RETRY
$$

或：

$$
\rightarrow
SUPERSEDED.
$$

---

# 36. Speculative Execution

如果兩條未確定 branch：

$$
A
\lor
B,
$$

可以：

$$
A\parallel B.
$$

但：

$$
Result_A
$$

與：

$$
Result_B
$$

都只是 candidate。

條件確定後：

$$
Commit(A)
$$

並：

$$
Discard(B).
$$

---

# 37. Speculation 的核心不是「提前算」

而是：

$$
\boxed{
提前算
+
延後承諾.
}
$$

沒有延後 commit：

$$
Speculation
$$

很容易直接污染正式狀態。

---

# 38. Intel TSX 的結構啟示

Transactional memory / RTM 允許一段執行先 speculative 地進行，最後：

$$
Commit
$$

或：

$$
Abort.
$$

而 Intel 文件也明確要求 software 準備非 transaction fallback，因為 RTM 不保證某個 region 最終一定能 transactionally commit。

對 CDI 的啟示不是「用 TSX 做 AI」。

而是：

$$
\boxed{
Speculate
\rightarrow
Commit/Abort
\rightarrow
Fallback
}
$$

是一個成熟計算模式。

---

# 39. Candidate Discard

最便宜的 rollback：

$$
\boxed{
尚未 commit
\Rightarrow
直接丟棄.
}
$$

這就是為什麼：

$$
DelayedCommit
$$

很重要。

---

# 40. State Rollback

若 candidate 在 isolated snapshot 上工作：

$$
S_t^{shadow}
\rightarrow
S_{t+1}^{shadow},
$$

失敗：

$$
Discard(S^{shadow}).
$$

若已進入可 journal 的 local state：

$$
Rollback.
$$

---

# 41. WAL 的結構啟示

SQLite WAL / rollback journal 展示：

> 正式資料與「尚未完成的修改紀錄」可以被分離，使 commit / rollback 具有明確邊界。

CDI 不需要重做資料庫。

而是應重用：

$$
\boxed{
JournalBeforeUnsafeMutation.
}
$$

---

# 42. 但遊戲世界不能全部用資料庫 rollback 思考

例如：

- 已送出 network packet；
- 已播放不可取消外部音訊；
- 已寫外部檔案；
- 已發送付款；
- 已控制實體馬達；
- 玩家已經看到／回應某個事件。

這些：

$$
\boxed{
ExternalEffect
}
$$

不一定可倒帶。

---

# 43. Effect Classes

定義：

$$
\boxed{
EffectClass
=
\{
Pure,
Reversible,
Compensatable,
Irreversible
\}.
}
$$

---

# 44. Pure

沒有外部副作用。

最適合 speculation。

---

# 45. Reversible

可以：

$$
Rollback.
$$

例如 isolated memory state、temporary buffer。

---

# 46. Compensatable

不能真正倒放，

但可以追加相反 action。

例如：

$$
Reserve
\rightarrow
Release.
$$

---

# 47. Irreversible

例如某些外部實體 action。

此類：

$$
\boxed{
SpeculationForbiddenByDefault.
}
$$

---

# 48. Effect Barrier

本文提出：

$$
\boxed{
EffectBarrier.
}
$$

任何 candidate 在跨入：

$$
ExternalEffect
$$

前，必須先確定：

- authority；
- causal state；
- idempotency；
- rollback / compensation policy；
- risk。

---

# 49. Effect Barrier 與 Semantic Fence 的關係

$$
SCF
$$

判斷：

> 這個計算結果可不可以成為正式狀態？

$$
EffectBarrier
$$

判斷：

> 這個正式狀態可不可以造成外部不可逆 effect？

所以：

$$
\boxed{
SCF
\rightarrow
EffectBarrier
\rightarrow
ExternalAction.
}
$$

---

# 50. 三種回退必須分開

## A — Discard

$$
Candidate
\rightarrow
\varnothing.
$$

## B — Rollback

$$
S_{t+1}
\rightarrow
S_t.
$$

## C — Compensate

$$
Effect_1
\rightarrow
Effect_2
$$

使業務／世界效果回到可接受區域。

---

# 51. Compensation 不等於歷史沒發生

這非常重要。

若：

$$
Charge
\rightarrow
Refund,
$$

不能寫成：

$$
ChargeNeverHappened.
$$

正確：

$$
\boxed{
Event_1
+
Compensation(Event_1).
}
$$

---

# 52. Append-Only Correction

因此：

$$
\boxed{
WrongEvent
}
$$

可以保留，

再追加：

$$
Correction.
$$

這和跨任務實驗的 correction 模式一致。

---

# 53. Recovery Ladder

本文提出：

$$
\boxed{
L_0:
DiscardCandidate
}
$$

$$
L_1:
RetrySameRoute
$$

$$
L_2:
RecomputeFreshState
$$

$$
L_3:
RerouteDifferentWorker
$$

$$
L_4:
SerializeSafePath
$$

$$
L_5:
RollbackSnapshot
$$

$$
L_6:
CompensateExternalEffect
$$

$$
L_7:
Human/GovernorIntervention.
$$

---

# 54. Recovery 也應遵守 ACR

簡單 stale：

$$
R_0.
$$

局部 dependency conflict：

$$
R_1.
$$

未知 semantic conflict：

$$
R_2.
$$

不可逆 external effect：

$$
Escalate.
$$

---

# 55. Local Commit

Relay 可以只對：

$$
\Omega_j
$$

內部、低風險、可回退狀態 commit。

條件：

$$
Scope(c)\subseteq\Omega_j.
$$

---

# 56. Domain Commit

跨多個 worker、同一 causal domain：

$$
\rightarrow
DomainValidator.
$$

---

# 57. Global Commit

跨：

- multiple causal domains；
- global world state；
- irreversible effect；
- security policy；

則：

$$
\rightarrow Governor.
$$

---

# 58. Commit Scope

$$
\boxed{
Local
<
Domain
<
Global.
}
$$

越往上：

$$
CognitiveDepth\uparrow,
$$

$$
CommitFrequency\downarrow.
$$

這與 AIVS 梯度一致。

---

# 59. Lease

Relay / worker 的提交權不是永久的。

$$
Lease=(scope,epoch,validUntil).
$$

---

# 60. Fencing Token

每次新的 authority epoch：

$$
f_{k+1}>f_k.
$$

resource / committer 只接受：

$$
f=f_{current}.
$$

舊 actor 即使晚到：

$$
Reject.
$$

---

# 61. 為什麼只看時間戳不夠？

舊 worker 可能：

1. 早開始；
2. 網路延遲；
3. 新 worker 已接管；
4. 舊 worker 晚到。

其 timestamp 可能有各種順序。

安全判定應看：

$$
\boxed{
CurrentAuthorityEpoch.
}
$$

而不是：

> 誰比較早。

---

# 62. Kubernetes Lease 的啟示

Kubernetes 將 Lease 用於：

- node heartbeat；
- leader election；
- coordinated leader election。

AIVS 可借用：

$$
\boxed{
AuthorityHasLifetime.
}
$$

但 CDI 的 fencing token 與 semantic commit scope 是本文自己增加的抽象，不能說 Kubernetes 已提供完整 CDI 保證。

---

# 63. Commit Protocol v0.1

本文提出：

$$
\boxed{
Prepare
\rightarrow
Produce
\rightarrow
Validate
\rightarrow
Fence
\rightarrow
Commit
\rightarrow
Receipt.
}
$$

---

# 64. Prepare

固定：

- input version；
- dependencies；
- policy；
- authority；
- side-effect class。

---

# 65. Produce

Worker 執行。

結果只寫：

$$
CandidateStore.
$$

---

# 66. Validate

低階：

- checksum；
- type；
- invariant；
- state；
- dependency。

高階才：

- semantic contract；
- causal role；
- cross-flow consistency。

---

# 67. Fence

SCF 最後確認：

$$
CurrentState
$$

在驗證到 commit 的窗口沒有破壞候選前提。

---

# 68. Commit

Atomic：

$$
S_t\rightarrow S_{t+1}.
$$

若底層 store 支援 transaction：

優先使用。

---

# 69. Receipt

留下：

- candidate；
- old version；
- new version；
- authority；
- evidence；
- time。

---

# 70. FoundationDB 的結構啟示

FoundationDB 使用 optimistic transaction：

- transaction 先基於 read version 工作；
- commit 時檢查與已提交 transaction 是否 conflict；
- conflict 則 reject / retry。

這跟 CDI 的：

$$
\boxed{
ComputeFirst
\rightarrow
ConflictCheckAtCommit
}
$$

高度相似。

---

# 71. 但 CDI 多一層 Semantic Conflict

資料庫主要知道：

- key/range；
- read/write conflict。

CDI 還要知道：

- 兩個計算結果雖未寫同一 key，是否在高階世界模型中互相矛盾？

這才需要 AI / semantic verifier。

---

# 72. Proof-Carrying Candidate

候選最好不是只帶：

$$
Result.
$$

而帶：

$$
\boxed{
Result
+
Evidence
+
Dependencies
+
Version
+
Authority.
}
$$

也就是：

$$
Candidate
\rightarrow
ProofCarryingCandidate.
$$

---

# 73. 「Proof」不是形式證明的濫用

這裡 proof carrying 指：

- checksum；
- test result；
- invariant；
- parent refs；
- profiler trace；
- semantic explanation。

不是宣稱每個結果都有數學形式證明。

---

# 74. Evidence Strength

$$
EvidenceLevel
=
E_0,E_1,E_2,\ldots
$$

低風險 commit 只需：

$$
E_1.
$$

高風險：

$$
E_k.
$$

---

# 75. Shadow Execution

AI 建議新的 parallel route：

$$
P'.
$$

先：

$$
P'
$$

在 shadow 執行。

正式：

$$
P.
$$

兩者比較：

$$
StateDigest(P)
\stackrel{?}{\sim}
StateDigest(P').
$$

---

# 76. Shadow Candidate 永遠沒有 effect authority

所以：

$$
\boxed{
Shadow
\Rightarrow
NoExternalCommit.
}
$$

---

# 77. Promote

只有通過：

- correctness；
- performance；
- stability；
- replay；

才：

$$
ShadowRoute
\rightarrow
ActiveRoute.
$$

---

# 78. Replay

Candidate / commit 應足以重建：

$$
\boxed{
WhyThisStateExists.
}
$$

至少保存：

- input refs；
- task；
- route；
- version；
- output digest；
- receipt。

---

# 79. Deterministic Replay 與 Semantic Replay

## Deterministic Replay

相同 input：

$$
\rightarrow
$$

相同 output。

## Semantic Replay

即使 nondeterministic，

仍滿足：

$$
InvariantSet.
$$

遊戲常需要第二種。

---

# 80. 遊戲的特殊問題：RNG

如果原遊戲 RNG sequence：

$$
r_1,r_2,\ldots
$$

parallelization 改變呼叫順序，

可能：

$$
Gameplay
$$

完全不同。

所以：

$$
\boxed{
RNGState
}
$$

必須被視為 dependency / state。

---

# 81. Frame Epoch

遊戲可以定義：

$$
Epoch=f.
$$

candidate：

$$
c^{(f)}.
$$

若已進：

$$
f+1,
$$

則 candidate 是否仍可用，依 subsystem 決定。

---

# 82. Render Candidate

部分 render work：

$$
late
$$

可以直接丟。

---

# 83. Physics Candidate

late physics state 可能：

$$
不能直接丟,
$$

而要：

$$
Recompute/Serialize.
$$

---

# 84. Asset Candidate

asset decode：

可能跨 frame 仍有效。

所以：

$$
\boxed{
FreshnessPolicy
}
$$

必須按 flow 定義。

---

# 85. UI Candidate

如果 UI 已因新 state 改變：

舊 UI result：

$$
Discard.
$$

通常很安全。

---

# 86. 所以「stale」不是單一布林值

定義：

$$
\boxed{
Freshness(c)
=
f(
Flow,
Dependency,
Deadline,
StateChange
).
}
$$

---

# 87. Causal Misalignment Detection

假設：

$$
ExpectedParents(c)=\{a,b\}.
$$

實際：

$$
ObservedParents(c)=\{a,d\}.
$$

則：

$$
\boxed{
Misalign(c)>0.
}
$$

---

# 88. 簡單度量

$$
M_c
=
1-
\frac{
|E\cap O|
}{
|E\cup O|
}.
$$

其中：

$$
E=ExpectedParents,\quad O=ObservedParents.
$$

 $M_c=0$ 表示 parent set 完全一致。

這只是 v0.1 heuristic。

---

# 89. 語義錯位

parent 都合法，

但 task role 變了。

例如 worker 原本：

> 評估 path。

卻輸出：

> 修改 world state。

需要：

$$
SemanticRoleCheck.
$$

---

# 90. AI 判斷何時有必要？

只有：

$$
MachineChecks=Pass
$$

但：

$$
SemanticAmbiguity>0.
$$

才：

$$
InvokeAI.
$$

---

# 91. Candidate Buffer

候選需要有界 buffer。

若無限保存：

$$
Memory\uparrow\infty.
$$

Policy：

- max candidates；
- TTL；
- supersede；
- archive evidence；
- discard payload keep metadata。

---

# 92. Supersession

新 candidate：

$$
c_2
$$

基於更新 state，

可：

$$
Supersede(c_1).
$$

但：

$$
c_1
$$

保留 audit metadata。

---

# 93. Commit Ordering

同一 causal chain：

$$
c_a\prec c_b.
$$

不能：

$$
Commit(c_b)
$$

先於：

$$
Commit(c_a)
$$

除非協議允許 rebase。

---

# 94. Partial Order

多 X 系統不需要全域 total order。

若：

$$
a\parallel b
$$

且無依賴，

可只維持：

$$
\boxed{
CausalPartialOrder.
}
$$

這可減少不必要同步。

---

# 95. 不要把所有事件強制排成一條線

否則：

$$
Concurrency
$$

會被 global commit lock 消滅。

CDI 應只序列化：

$$
\boxed{
真正衝突的 causal domain.
}
$$

---

# 96. Local Serializability

每個 domain：

$$
\Omega_j
$$

維持局部一致性。

跨 domain：

只有必要 edge：

$$
Sync.
$$

---

# 97. 這是 AIVS 與 Candidate/Commit 的結合點

AIVS 決定：

> 誰該看？

Candidate/Commit 決定：

> 誰有資格改變正式狀態？

所以：

$$
\boxed{
AIVS
=
AttentionRouting
}
$$

而：

$$
\boxed{
CommitProtocol
=
StateAuthorityRouting.
}
$$

---

# 98. 兩者不能混在一起

Relay 被喚醒：

$$
Wake
$$

不表示：

$$
CanCommit.
$$

AI 看懂：

$$
Understand
$$

不表示：

$$
Authorized.
$$

---

# 99. Failure Mode 1：False Commit

錯誤 candidate 通過。

最嚴重。

Metric：

$$
FCR
=
\frac{InvalidCommitted}{TotalCommitted}.
$$

---

# 100. Failure Mode 2：False Reject

正確 candidate 被拒。

影響：

- latency；
- throughput；
- AI cost。

---

# 101. Failure Mode 3：Retry Storm

high contention：

$$
Reject
\rightarrow
Retry
\rightarrow
Reject
\rightarrow\cdots
$$

需要：

- backoff；
- serialize fallback；
- reroute；
- scope reduction。

---

# 102. FoundationDB 的另一個啟示

其 transaction retry loop 在 high conflict 時會使用 backoff。

CDI 同樣不能：

$$
Conflict
\Rightarrow
ImmediateInfiniteRetry.
$$

---

# 103. Failure Mode 4：Double Effect

CommitUnknown + retry：

$$
Effect\times2.
$$

需 idempotency。

---

# 104. Failure Mode 5：Rollback Impossible

已造成 irreversible effect 才發現錯誤。

因此 EffectBarrier 必須在 effect 前。

---

# 105. Failure Mode 6：Stale Authority

舊 Relay 晚到 commit。

用 fencing。

---

# 106. Failure Mode 7：Semantic Fence Hallucination

AI 說：

> 合法。

但證據不足。

所以：

$$
\boxed{
AISemanticPass
}
$$

只能作 SCF 的一個條件，

不能是全部。

---

# 107. Failure Mode 8：Global Lock Collapse

所有 commit 都送 Governor。

結果：

$$
Parallelism\rightarrow0.
$$

所以需要 Local / Domain commit。

---

# 108. Failure Mode 9：Over-Rollback

其實沒有 relevant conflict，

卻因 version mismatch 全重算。

解法：

$$
ReadSet/DependencyAwareConflict.
$$

---

# 109. Failure Mode 10：Hidden Side Effect

AI 認為 Pure，

實際：

$$
ExternalMutation.
$$

第一階段必須依：

- static analysis；
- sandbox；
- syscall / API trace；

確認 effect class。

---

# 110. Commit Cost

$$
\boxed{
C_{commit}
=
C_{machine}
+
p_sC_{semantic}
+
C_{coordination}
+
C_{journal}.
}
$$

其中：

$$
p_s\ll1
$$

才符合稀疏 AI 認知。

---

# 111. Speculation Utility

$$
\boxed{
U_{spec}
=
p_{use}G_{latency}
-
C_{extraCompute}
-
C_{validation}
-
C_{rollbackRisk}.
}
$$

只有：

$$
U_{spec}>0
$$

才值得 speculative。

---

# 112. Commit Window

candidate 完成到 commit：

$$
[t_p,t_c].
$$

這段越長：

$$
ConflictRisk\uparrow.
$$

所以：

$$
\boxed{
LongAIReasoning
}
$$

不能無限制卡在 commit critical path。

---

# 113. Fast Fence / Deep Fence

可分：

## Fast Fence

machine checks。

## Deep Fence

semantic / cross-domain。

高頻 low-risk：

$$
FastFence.
$$

低頻 high-risk：

$$
DeepFence.
$$

---

# 114. ACR 再次進場

$$
FenceDepth
=
f(
Risk,
Conflict,
Novelty,
EffectClass
).
$$

不是每個 commit 都最大驗證。

---

# 115. Commit Safety Invariant

若初始：

$$
I(S_0)=1,
$$

且每個 commit 都保證：

$$
I(S_t)=1
\Rightarrow
I(Apply(S_t,c))=1,
$$

則有限 commit history：

$$
S_0,\ldots,S_n
$$

都保持：

$$
I=1.
$$

這是條件式歸納，不是對現實 verifier 正確性的證明。

---

# 116. 真正難點被移到了 Validator

因此：

$$
\boxed{
Candidate/Commit
}
$$

沒有魔法。

如果：

$$
ValidatorWrong,
$$

安全性仍會失效。

所以研究必須測：

- false accept；
- false reject；
- shared blind spot。

---

# 117. H1 — Candidate/Commit 降低錯誤污染

與 direct-write baseline 比較：

$$
InvalidStateRate_{CC}
<
InvalidStateRate_{Direct}.
$$

---

# 118. H2 — Relevant-conflict validation 優於純 version mismatch

比較：

- any-version-change retry；
- read-set/dependency-aware conflict。

要求：

$$
UnnecessaryRetry\downarrow.
$$

---

# 119. H3 — Semantic Fence 能找到 machine checks 看不到的高階衝突

建立：

- checksums pass；
- types pass；
- versions current；

但 task roles 互斥的測試。

若 AI/semantic verifier 無法提高 detection：

H3 失敗。

---

# 120. H4 — Idempotency 防止 CommitUnknown 重複 effect

故意：

1. commit；
2. 丟失 ACK；
3. retry。

要求：

$$
EffectCount=1.
$$

---

# 121. H5 — Fencing 阻止 stale Relay

A lease 失效，

B 接管。

A 晚到。

要求：

$$
Commit_A=Rejected.
$$

---

# 122. H6 — Shadow route 可在不污染正式狀態下評估 AI parallelization

要求：

$$
ExternalEffect_{shadow}=0.
$$

同時可收集 performance / equivalence。

---

# 123. H7 — Recovery Ladder 優於一律重啟

比較：

- restart app；
- hierarchical recovery。

要求：

$$
RecoveryTime\downarrow
$$

且 correctness 不下降。

---

# 124. H8 — Local commit 可避免 Governor 成為 global lock

比較：

- all global commit；
- scoped local/domain/global。

要求：

$$
Throughput\uparrow,
$$

且 cross-domain conflict 不增加至不可接受。

---

# 125. H9 — Effect Class 能降低不可逆 speculative error

對 mixed workload：

若 Irreversible 預設不 speculation，

$$
IrreversibleWrongEffect\downarrow.
$$

---

# 126. H10 — ACR Fence Depth 降低 AI 成本

比較：

- every commit deep AI；
- adaptive fence。

同等 false commit rate 下：

$$
Token_{adaptive}<Token_{deep}.
$$

---

# 127. MVP Test A：Stale Read

Worker A：

$$
v=1.
$$

B commit：

$$
v=2.
$$

A candidate 提交。

若 read-set conflict：

$$
Reject.
$$

---

# 128. MVP Test B：Version Changed But No Conflict

A 讀：

$$
x.
$$

B 只改：

$$
y.
$$

A candidate：

$$
仍可 commit.
$$

這驗證 dependency-aware conflict。

---

# 129. MVP Test C：Duplicate Commit

同 idempotency key：

$$
10
$$

次。

正式 effect：

$$
1.
$$

---

# 130. MVP Test D：Stale Lease

A token：

$$
41.
$$

B 新 token：

$$
42.
$$

A 晚到：

$$
Reject.
$$

---

# 131. MVP Test E：Speculative Branch

A / B 同時計算。

只讓一支：

$$
Commit.
$$

另一支：

$$
Discard.
$$

---

# 132. MVP Test F：Shadow Parallelization

Original：

$$
Serial.
$$

Shadow：

$$
Parallel.
$$

比較：

- output；
- state digest；
- latency。

---

# 133. MVP Test G：Semantic Conflict

machine state 全 pass，

但高階 scenario 設計成邏輯互斥。

測 AI semantic verifier。

---

# 134. MVP Test H：AI Timeout

Deep Fence timeout。

要求：

$$
SafeFallback.
$$

不能直接 optimistic commit 高風險 effect。

---

# 135. MVP Test I：Compensation

先產生 compensatable effect。

後發現錯誤。

要求：

$$
CorrectionEvent
$$

與：

$$
CompensationEvent
$$

都存在。

---

# 136. MVP Test J：Governor Failure

Local safe commit 可繼續。

Global/high-risk commit：

$$
Hold.
$$

Governor 恢復後再處理。

---

# 137. 第六篇工程實作需要的資料表

本篇預先指定：

```text
candidates
candidate_parents
candidate_evidence
commit_receipts
state_versions
leases
fencing_tokens
idempotency_keys
corrections
compensations
shadow_runs
```

---

# 138. Candidate Store API

```text
create_candidate()
attach_parent()
attach_evidence()
mark_produced()
mark_rejected()
mark_superseded()
list_pending()
```

---

# 139. Fence API

```text
check_schema()
check_epoch()
check_fencing()
check_idempotency()
check_freshness()
check_dependencies()
check_invariants()
check_semantics()
check_effect_barrier()
```

---

# 140. Commit API

```text
prepare_commit()
commit_local()
commit_domain()
commit_global()
write_receipt()
query_commit_status()
```

---

# 141. Recovery API

```text
discard_candidate()
retry_candidate()
recompute_candidate()
reroute_candidate()
serialize_scope()
rollback_snapshot()
compensate_effect()
escalate_recovery()
```

---

# 142. 最小 Runtime Pipeline

```text
Worker
  │
  ▼
Candidate Store
  │
  ▼
Fast Fence
  │
  ├─ fail → reject/retry
  │
  ▼
AIVS Relay
  │
  ├─ low risk → local commit
  │
  ├─ ambiguity → Deep Fence
  │
  └─ cross-domain → Governor
  │
  ▼
Committer
  │
  ▼
Receipt / Event Log
```

---

# 143. 為什麼這篇是 24／72 Runtime Routing 的前置？

下一篇會允許 AI：

$$
P_i
\rightarrow
P_j
$$

動態改變 execution paradigm。

但只要 routing 可變，

就一定可能：

- 跑錯 route；
- 同時跑兩 route；
- route 變更時舊結果晚到。

因此沒有 Candidate/Commit：

$$
\boxed{
DynamicRouting
}
$$

很難安全。

---

# 144. Paradigm Switch 必須先產生 Candidate

例如原：

$$
Serial.
$$

AI 建議：

$$
Parallel.
$$

第一階段：

$$
ParallelRoute
\rightarrow
ShadowCandidate.
$$

而不是：

$$
直接取代正式程序.
$$

---

# 145. 最終統一

目前三篇已形成：

$$
\boxed{
CDI
=
SemanticControl
+
AIVS
+
CandidateCommit.
}
$$

再展開：

$$
\boxed{
CDI
=
\text{知道怎麼算}
+
\text{知道何時值得看}
+
\text{知道什麼結果可以相信並正式採用}.
}
$$

---

# 146. 結論

多核心、多 GPU、多 process、多 Agent、多 machine 的真正困難，不只是：

> 如何同時算？

還包括：

> **如何讓同時算出來的東西不互相污染？**

本文的回答是：

$$
\boxed{
ComputedResult
\neq
CommittedProgramState.
}
$$

系統允許候選層：

$$
\boxed{
快、亂、並行、推測、失敗.
}
$$

但正式狀態層要求：

$$
\boxed{
慢一點也可以，
但必須可驗證、可追溯、可授權、可恢復.
}
$$

因此：

$$
\boxed{
InternalExecutionFreedom
+
ExternalCommitDiscipline.
}
$$

成為 CDI 的第三個核心原則。

在低風險、純函數、可丟棄的區域：

$$
SpeculateAggressively.
$$

在高風險、跨域、不可逆副作用前：

$$
FenceStrictly.
$$

AI 的角色不是取代 transaction、memory ordering、WAL、lease 或 version counter；而是在這些成熟 primitive 之上補充：

$$
\boxed{
SemanticDependency
+
CausalRole
+
TaskIntent
+
CrossDomainConflict.
}
$$

最終：

$$
\boxed{
Execute
\rightarrow
Candidate
\rightarrow
Verify
\rightarrow
Fence
\rightarrow
Commit
\rightarrow
Receipt
}
$$

提供了一條從「AI 建議新的多 X 計算方式」通往「AI 可以安全治理新的多 X 計算方式」的必要橋樑。

下一篇將正式進入：

# 《從 24／72 計算範式到 Runtime 路由》
## AI 如何選擇、組合與切換計算形態

並回答：

> 如果候選與提交已可安全分離，那麼 AI 能否真的把一個程式視為範式路徑，並在執行期決定哪些 region 應該序列、並行、跳躍、識別、確定、機率或其他方式運算？

---

## 參考資料

### 內部研究線

1. Neo.K / Aletheia. 《AI 不必替代計算：從傳統執行平面到語義—因果控制平面》v0.1，2026。
2. Neo.K / Aletheia. 《AI 垂直同步：分層中繼、認知比例性與低成本因果一致》v0.1，2026。
3. Neo.K / Aletheia. 《Adaptive Cognitive Runtime（ACR）工程白皮書》v0.1，2026。
4. Neo.K / Codex. 《從線性接力到語義合成：以 AI Board 與 CTCL 觀測跨任務多 AI 持續執行》v0.1，2026。
5. Neo.K / Codex. 《Token 不是狀態：協議化語義交換與跨任務 AI 的分散式認知》v0.1，2026。
6. Neo.K. 《從因果點到因果流：AI 視角計算的線性複雜度重構》，2026。

### 2026-08-10 重新查閱之公開 Primary Sources

7. FoundationDB. *Developer Guide / Transaction Processing / Automatic Idempotency*, current documentation。
8. SQLite. *Atomic Commit in SQLite / Write-Ahead Logging*, current documentation。
9. Linux Kernel. *Sequence Counters and Sequential Locks*, current documentation。
10. Intel. *Intel Transactional Synchronization Extensions (TSX / RTM)*, official technical documentation。
11. Kubernetes. *Leases / Coordinated Leader Election*, current documentation。
12. Herlihy, M. & Moss, J. E. B. *Transactional Memory: Architectural Support for Lock-Free Data Structures*. ISCA, 1993。

---

## 版本紀錄

- **v0.1 / 2026-08-10**：正式建立 Compute Candidate、CCO、Commit Receipt、Semantic-Causal Fence、Effect Barrier、三類 rollback、Recovery Ladder、Local/Domain/Global Commit、lease/fencing、commit uncertainty、idempotency、shadow execution、conflict classes、10 組可反駁假說與工程 API。