---
title: "CWSR Paper 06｜24／72 計算範式的世界狀態自適應路由"
english_title: "Adaptive World-State Computation Routing with the 24/72 Computational Forms: Causal Admissibility, Heterogeneous Placement, Switching Cost, and Falsifiable Selection"
series: "CWSR — Causal World-State Runtime"
paper: "06 / 08"
version: "v0.1"
date: "2026-10-16"
author: "Neo.K"
ai_research_collaborator: "Aletheia / GPT-6"
institution: "EveMissLab / 一言諾科技有限公司"
status: "Research Draft — Engineering Extension / Not an Independent Foundational Theory"
canonical_source: "UTF-8 Markdown; mathematical delimiters $...$ and $$...$$ only"
language: "zh-TW"
predecessor: "CWSR Paper 05 v0.1"
next_paper: "CWSR Paper 07 — CWSR Runtime：遊戲引擎整合與參考實作"
---

# CWSR Paper 06｜24／72 計算範式的世界狀態自適應路由

## 從局部計算形態、因果義務、資源硬限制到 CPU／GPU 多尺度世界工作的保守配置、動態切換及可證偽比較

**English:** *Adaptive World-State Computation Routing with the 24/72 Computational Forms: Causal Admissibility, Heterogeneous Placement, Switching Cost, and Falsifiable Selection*

**系列位置：** CWSR Paper 06 / 08；承接 Paper 00–05，向 Paper 07 的參考 Runtime 與 Paper 08 的 A/B 實驗交付明確且可否證的路由介面。

**研究性質：** 既有 Computation 24／72、Global Computation Methodology（GCM）、GCCF 06、GCCFT／GCCWT 與成熟異質排程技術的**單機遊戲工程延伸**，不是新的計算本體論或跨硬體最優性定理。

**本篇交付：** 工作形態及候選路由型別、因果與硬資源可行性檢查、全路徑成本／不確定性／切換成本建模、Pareto 候選與確定性政策、保守回退、跨尺度示例、Rust 介面草案、可證偽命題和基準設計。

**未交付：** 已編譯的 Rust 套件、已執行的 GPU kernel、已取得之 FPS 改善、完成之模組整合、已審查的通用最優路由器或任何已在實機驗證的新效能結果。

**作者：** Neo.K  
**機構：** EveMissLab / 一言諾科技有限公司  
**日期：** 2026-10-16  
**版本：** v0.1  

---

## 摘要

單機開放世界的 CPU、GPU、RAM 與 VRAM 資源有限，世界演化卻包含同時存在的宏觀、中觀與微觀狀態、不同時間期限、事件責任、連續數值計算、稀疏因果傳播、識別／索引存取、隨機轉移與多種精度要求。若所有工作都交由每幀主循環執行，可能過度輪詢和重算；若把所有工作一律改成事件觸發、GPU 並行或預測性預熱，則可能製造更高的治理開銷、資料搬移、同步等待、顯存競爭與世界語義錯誤。CWSR Paper 00–05 已分別建立邏輯世界與活動執行的分離、義務保全的條件喚醒、多尺度聚合／細化、動靜態記憶體契約，以及 CPU／GPU 因果小流與合法合批。

本篇在不重新定義這些上游規則的前提下，處理下一個問題：**當某一局部世界計算已被判定有執行義務，且存在數種具有不同計算形態和硬體實現的候選路徑時，Runtime 如何在不更改世界真實性、版本、期限、精度與副作用責任的前提下，選擇、記錄、維持、切換或撤回一條路徑？**

我們把既有「計算的二十四重範式」v4.0 與「七十二格計算動力學候選空間」v0.1 作為 **Form Coordinate／Transition-Law Annotation（形態座標／轉移律註記）**，並承接 GCCF 06 所述的 Global Computation Routing Grammar。但分類座標只描述計算，不直接給出時延、記憶體佔用、硬體可用性、或輸出安全性。局部工作可以有複合形態、跨階段形態路徑、混合分布或尚未可判定的形態。對任一候選 route，本篇必須另外綁定確定的 capability、backend、資料位置、依賴前沿、驗證機制和世界提交權限。

提出 CWSR 工作性的 **World-State Route Contract（世界狀態路由契約）**、**Form-Aware Candidate Set（形態感知候選集合）**、**Hard-Gate Admissibility（硬門檻可行性）**、**Uncertainty-Aware Route Cost（含不確定性的路由成本）**、**Hysteretic Route Switching（帶遲滯的切換）** 與 **Conservative Fallback Route（保守回退路徑）**。先排除語義不正確或超出硬限制的配置，再以完整時間、能源、駐留、搬移、渲染干擾、穩定性和回復等成本比較；當證據不足時，可以選擇經驗證的成熟 CPU／事件系統，而不是強迫採用高複雜度的路由方案。

核心假說不是「24／72 一定使遊戲變快」，而是：**在存在異質、可區分計算形態，且動態選擇所得效益超過分類、規劃、切換與驗證成本的負載中，一個受世界契約治理的路由器，可能比固定配置或單一效能啟發式更有效。** 此假說必須由 Paper 08 在相同遊戲規則、期限、精度和硬體條件下，與成熟 CPU ECS／Job System、事件／Dirty Flag、GPU Compute 及不使用 24／72 的普通異質路由器分開比較。

**關鍵詞：** CWSR；24 Computational Paradigms；72-Cell Candidate Dynamics；Form-Aware Routing；World-State Computation；Causal Microflow；Feasibility Gate；Global Computation Methodology；CPU／GPU Heterogeneous Scheduling；Pareto Allocation；Switching Cost；Hysteresis；Render Contention；Commit Gate；Falsifiable Benchmark。

---

# 0. 論域、責任及不可提前宣稱的成果

## 0.1 本篇回答哪一個問題

Paper 02 回答「為什麼這項工作現在需要執行？」；Paper 03 回答「它應以何種尺度忠實地表示與推進？」；Paper 04 回答「必要資料可以合法存在於哪種實體駐留狀態？」；Paper 05 回答「如何把具有因果責任的小流合法分批，交由 CPU 或 GPU 形成候選結果？」。

Paper 06 的新問題才是：**既然已經有合法的工作與可使用的執行方式，現在選哪一條可驗證路徑？若世界或資源改變，何時應切換？**

它必須能選擇「不切換」、「保留原有成熟流程」、「CPU 向量化」、「CPU 事件／期限更新」、「GPU compute」、「已驗證快取重用」、「固定步進回退」、「分尺度混合路由」等候選。它不能決定某個規則義務不存在，也不能因 GPU 更快便擅改世界規則。

## 0.2 六個研究問題

- **RQ06-1：** 24／72 可提供哪些具體區分資訊？何時不足以用單一格描述整段任務？
- **RQ06-2：** 如何在沒有性能量測結果時，只用形態描述形成保守而可撤回的候選，不冒充速度結論？
- **RQ06-3：** 如何對世界版本、因果、期限、精度、授權、RAM／VRAM 及渲染保留量施加不可交換的硬限制？
- **RQ06-4：** 如何把資料搬移、排隊、驗證、提交、設備故障及切換抖動納入真實 end-to-end 路徑成本？
- **RQ06-5：** 何時動態重規劃值得其監控、統計與遲滯代價？
- **RQ06-6：** 如何區別「24／72 分類帶來的增量」、「一般異質路由帶來的增量」，以及「單純使用更好 GPU kernel」的增量？

## 0.3 不成立的假設

1. 「Parallel」不等於 GPU，也不等於工作量較小。
2. 「Jump」不保證低複雜度；稀疏索引仍有建立與維護成本。
3. 「Recognition／Retrieval」不等於零時間、零記憶體或免費查詢。
4. 「Continuous」不等於必須使用浮點數；也不保證所有數值近似合法。
5. 「拒單測觀察」不是不可測、不可計算或一種特殊硬體；其語境與不變量不可省略。
6. 「Quantum-channel-like」不等於 GPU Tensor Core、SIMT 或一般神經網路推論；遊戲一般使用 CPU／GPU 不需量子硬體。
7. 形態分類沒有測得的吞吐量與延遲，就不能推出哪台設備比較快。
8. AI 提出路由不等於它取得合法執行權、世界修改權或設備預約權。
9. 成功完成 GPU dispatch 不等於世界狀態已提交。
10. 預測性的路由提示不能取代已驗證的世界因果或時間義務。
11. 世界局部有效不代表全部未觀測路徑安全。
12. 本篇不要求所有單機遊戲安裝一個複雜自適應路由器。

## 0.4 正式研究完成的語義

本篇完成表示已交付可測試的設計與候選演算法，並明示前提、反例、版本和責任。即使語義模型在靜態檢查下自洽，也不等於已獲得任何硬體實驗結論。Paper 07 才負責參考實作；Paper 08 才能根據可重現數據支持或否定性能假說。

---

# 1. 不變的上游世界：Paper 00–05 契約

## 1.1 邏輯世界與有限活動執行

沿用 Paper 01–05 已固定的局部世界模型：

$$
W_t^{\mathrm{log}}=\langle V_t,E_t,X_t,T_t,H_t,\Gamma_t\rangle.
$$

$$
R_t^{\mathrm{run}}\subseteq A_t^Q\subseteq Q_t.
$$

$$
N_t\subseteq A_t^Q\cup P_t.
$$

 $V_t$ 是世界節點， $E_t$ 是規則依賴， $X_t$ 是狀態描述符， $T_t$ 是時間義務， $H_t$ 是歷史， $\Gamma_t$ 是規則與觀察語境。 $N_t$ 是必要義務， $A_t^Q$ 是可取得排程資格的工作投影， $P_t$ 是符合延後契約的待處理義務， $R_t^{\mathrm{run}}$ 是實際執行集合。

不在 $R_t^{\mathrm{run}}$ 不等於不存在；不在 GPU 執行不等於未執行；GPU 內已算出資料不等於可直接寫入世界。

## 1.2 狀態身份／副本／版本

沿用 Paper 04／05：

$$
\mathrm{StateRef}=(\mathrm{sid},\mathrm{revision},\mathrm{schema},\mathrm{rule}).
$$

$$
\mathrm{ReplicaRef}=(\mathrm{StateRef},\mathrm{replica\_id},\mathrm{generation}).
$$

物理副本可以轉移、重建或撤銷；其 device pointer 不是穩定世界身份。`ReplicaRef` 亦不自動提供寫入權。若 data hazard、讀寫 lease、fence 或 generation 未清楚記錄，不能把設備搬移當成安全操作。

## 1.3 因果小流的直接輸入

沿用 Paper 05 的工作性定義：

$$
m=\langle id,c,w,\sigma,rd,wr,g,\theta,\pi,\epsilon,\alpha,\delta\rangle.
$$

其中 $c$ 為 Cause／Wake Ticket， $w$ 為版本化快照， $\sigma$ 為尺度語境， $rd,wr$ 為讀取與候選寫入範圍， $g$ 為 Guard， $\theta$ 為時間契約， $\pi$ 為 Compute Shape， $\epsilon$ 為精度契約， $\alpha$ 為權限／副作用， $\delta$ 為恢復／回退。

Paper 06 **不得**把 $\pi$ 與下文的路由計畫混淆；本篇用 $\mathcal R$ 表示路由候選， $\Pi$ 表示候選集合或整體路由計畫，並保留 Paper 05 的 $\pi$ 作 Compute Shape 欄。

## 1.4 合法批次是路由器的輸入，不是輸出保證

Paper 05 的 batch 輸入：

$$
B=\langle bid,\mathcal M,\omega,\kappa,\lambda,\theta_B,\epsilon_B,\beta_B,\nu_B\rangle.
$$

其中 $\mathcal M$ 是小流集合、 $\omega$ 是快照相容證據、 $\kappa$ 是 kernel family、 $\lambda$ 是 buffer／lease／layout、 $\theta_B$ 是期限、 $\epsilon_B$ 是精度、 $\beta_B$ 是資源界限， $\nu_B$ 是驗證與回退。

路由器可以拒絕某個合批實作，改採同等語義的子批次、CPU 工作包、固定步進或其他合法實現；但不能把已經不合法的衝突批次用「選了某個 72 格」洗成合法。

## 1.5 三個不可交換的層級

- **Plan／Proposal：** 建議執行路徑與預算。
- **Execute／Complete：** 具體 backend 依合法快照形成候選結果，可能失敗或過時。
- **Verify／Commit：** 檢查因果、版本、精度、守恆、授權後，才允許更改 canonical world。

如果世界在路由與提交間已變動，必須重新驗證、拒絕或具合法 rebase 證據；不得悄悄採用舊結果。

---

# 2. 原始 24／72 分類的確定邊界

## 2.1 Computation 24 的正式基底

《計算的二十四重範式》v4.0 定義：

$$
\mathfrak P_{24}=\mathfrak B_2\times\mathfrak U_4\times\mathfrak O_3.
$$

$$
\mathfrak B_2=\{\mathsf C,\mathsf D\}.
$$

$$
\mathfrak U_4=\{\mathsf S,\mathsf J,\mathsf P,\mathsf R\}.
$$

$$
\mathfrak O_3=\{\mathsf C,\mathsf D,\mathsf X\}.
$$

其三軸是：(i) 在指定語境下採用連續或離散底空間，(ii) 序列、選擇跳躍、並行或識別／檢索型更新，(iii) 連續、離散或拒單一觀察表示的觀察組織。

因此：

$$
|\mathfrak P_{24}|=2\cdot4\cdot3=24.
$$

這裡的 $\mathsf X$ 是**指定語境、相關觀察量與容許誤差下，單一表示不能保留所有必需不變量**的相對性判定，不表示不可觀測或沒有數學描述；不能用「輸出同時有文字和圖片」就自動判為 $\mathsf X$。

## 2.2 七十二格第四軸的最低充分轉移律

既有七十二格候選動力學增加：

$$
\mathfrak L_3=\{\mathsf F,\mathsf K,\mathsf Q\},
$$

$$
\mathfrak P_{72}^{(0.1)}=\mathfrak P_{24}\times\mathfrak L_3.
$$

$$
|\mathfrak P_{72}^{(0.1)}|=72.
$$

 $\mathsf F$ 為 deterministic／function-like 轉移； $\mathsf K$ 為 stochastic-kernel-like 轉移； $\mathsf Q$ 為 coherence／quantum-channel-like 轉移。分類優先採 **最小充分轉移律**，不能因為確定函數可嵌入機率核，就一律標為 $\mathsf K$ ；也不能因 classical probability 能嵌入量子通道表示，就把普通遊戲計算標為 $\mathsf Q$。

本稿在常規 CPU／GPU 單機模擬的範圍，絕大多數候選可落在 $\mathsf F$ ／ $\mathsf K$ 或其合法組合。 $\mathsf Q$ 保留為上游理論原有候選，不製造「顯示卡就是量子電腦」的錯誤類比。

## 2.3 一個工作不必是一個格

對複合世界工作，允許：

- `SingleCell`：在確定語境與局部工作下可指定單一形式；
- `FormSet`：尚有數種可行描述，需要細化或保留多個候選；
- `FormPath`：多階段各自有不同形式；
- `FormStack`：同一任務跨數個互依層堆疊；
- `FormDistribution`：含不確定權重的候選形式分布；
- `Unclassified`：缺必要規則、語境、轉移律或觀察契約，暫不得強制分類。

以上是本篇**借用既有 GCM／GCCFT 可複合形式的方向，為 CWSR 指定操作性描述符**，不是宣稱上游每份文件已有相同 API 名稱與全部欄位。

## 2.4 分類不能替代計算圖

例如一個城市經濟任務包含：讀取稀疏市場事件、為居民需求做平行數值更新、將需求按地區約簡、索引查找庫存、形成物價候選。這不是一個可以誠實地指定單一 $\langle B;U;O;L\rangle$ 並推出具體運行方式的單元。

合法的做法是先保留子工作之間的依賴、衝突與提交權限，再分段標記 24／72 形態；不同子工作可混合 CPU/GPU，亦可在全 CPU 實作中保持同一 form path。

## 2.5 v4.0 和 v0.1 的方法論限制

- 24 v4.0 是**固定分類軸與觀察語境下的相對閉合性**，不是通用宇宙列舉。
- 72 v0.1 是**候選動力學空間**；存在性、空格、退化格和混合系統有待驗證。
- 兩者均不建立格點與 Big-O、FLOPS、VRAM 或能源的一對一函數。
- 同一計算在不同尺度、觀察語境和精度下可以合法擁有不同分類。
- 任何修改 canonical axes 的想法須另走上游研究修訂，不得在 CWSR Paper 06 靜默改版。

---
# 3. 從 Computation Form 到 Route：四個問題不混淆

## 3.1 四種不同的物件

| 物件 | 回答 | 典型欄位 | 不能直接推出 |
|---|---|---|---|
| `Form` | 這段計算的形態及轉移律是什麼？ | 24／72、語境、confidence、版本 | GPU 必然較快 |
| `Capability` | 哪些功能與效果可以被合法實現？ | 運算語義、精度、版本、ABI、效果 | 資源已被授權 |
| `Backend` | 哪些執行載體與實作可用？ | CPU SIMD、Job System、GPU Compute、API、driver | 目前容量足夠 |
| `Route` | 怎樣安排依賴、資料與後端來完成此項義務？ | DAG、placement、replica、proof、fallback、成本 | 世界已提交 |

**重要：** `Form` 不是 `Capability`；`Capability` 不是 `Backend`；`Backend` 不是 `Route`。此分離繼承 GCCF 06 的路由文法與 GCCWT 的規劃／授權邊界。

## 3.2 路由候選的工作性定義

對已驗證的工作前沿 $F_t$，本篇定義候選路由：

$$
\mathcal R=\langle rid,F_t,\mathcal P_f,\mathcal G_x,\mathcal B,\mathcal D,\mathcal S,\mathcal V,\mathcal C,\mathcal H\rangle.
$$

各欄位分別是：路由識別、工作集合、form profiles、執行階段圖、backend 映射、資料與版本計畫、同步與序計畫、驗證／提交責任、成本／資源估計、恢復與回退路徑。每份路由必須附來源快照、規則版本、設備能力版本、policy 版本及形成時的觀察資料版本。

路由候選是一份 proposal，並非被允許修改世界的程式碼。物理預約、device buffer lease、kernel submission 與 Commit Gate 仍各有自己的合法性檢查。

## 3.3 Form Profile 的可執行性不等於形式可描述性

一個局部形態可以被成功標註，卻找不到符合精度或期限的 backend；反過來，一個成熟 CPU 函式可以正確處理某工作，但暫時無法精確分類其混合 form。兩種情形都可能合法存在。

CWSR 不把「分類失敗」等同「世界無法計算」：若已知安全 fallback 可以直接執行，就應優先保留世界義務；分類器可退到旁路觀察，不得把世界堵死。

## 3.4 工作切分與執行階段圖

令：

$$
\mathcal G_x=(Q_x,E_x),
$$

 $Q_x$ 表示必需的計算／搬移／驗證／同步／提交階段， $E_x$ 表示順序、依賴、數據可用性和資源 hazard。CPU－GPU 複合路徑的上傳、dispatch、device fence、可選 readback、驗證、Commit Gate 不可在性能估計中被直接省略。

同一形態的實作可以映射到不同的 $\mathcal G_x$ ；不同形態也可能共享相同物理 backend。分段與形態沒有固定一對一關係。

## 3.5 Profile 的來源責任

`FormProfile` 應指明它從哪個 `CausalMicroflow`／Batch、哪個計算語境、哪套分類軸版本產生；由人標註、靜態分析、可執行探測或 AI 提案，也需要記錄來源。由 AI 提案的分類不得默認高信任；正式路由只可使用通過契約檢查的描述，或採取不依賴分類的 fallback。

---

# 4. 世界路由請求的型別與語義

## 4.1 請求必需資訊

一個 Route Request 必須保留至少下列欄位：

1. 世界、規則、schema、epoch、快照的版本戳記；
2. 因果起點、合法 Wake Ticket、讀寫範圍、動態依賴及副作用；
3. 宏／中／微 Scale Context、聚合／細化憑據、邊界帳本及必須維持的不變量；
4. Deadline、simulation clock、monotonic clock、序依賴、可容許 batching window；
5. Bitwise／Bounded／Statistical Precision Contract 與其驗證 oracle；
6. RAM／VRAM 的 capacity、render reserve、in-flight bytes、workspace、可重建性與 Lease；
7. 設備能力、計算 shape、資料布局、已驗證 kernel／算法註冊表；
8. 既有路由與切換歷史、遷移成本、測量可信度和 fallback；
9. 世界提交者、執行授權、設備資源擁有者與外部副作用界線；
10. 若有 MOD／規則擴充，須包含 MOD hash、規則差異、ABI 版本和分類憑據有效性。

這些 metadata 可用 shared handle 或穩定索引存取，不要求每個 NPC 與每一筆 RAM 都保存完整拷貝；治理成本本身應受預算約束。

## 4.2 Unknown 不是合法假設的零成本

若不知道狀態是否具有動態依賴，不能把它當成沒有依賴；若沒有 GPU kernel 的最壞記憶體估計，不能臆測足夠 VRAM；若 precision oracle 未定義，不能宣稱 bitwise 等價。

可用狀態要區分 `Known`、`BoundedEstimate`、`Unknown`、`Unsupported` 與 `Stale`。對硬限制所需資訊為 Unknown 時，路由採 fail-closed 或安全已驗證路徑，不可用單一樂觀點估值取代證據。

## 4.3 工作責任先於設備便利

時間已到的 NPC 任務、跨尺度守恆帳本、橋樑破壞後的道路阻斷、必須可重播的 RNG 事件，即使 GPU 目前忙於渲染，也不能被刪掉。系統可以選擇 CPU 或延後至合法的緩衝期限；若沒有能履行截止時間的合法路徑，應回報不可行並觸發規則級的安全降級，而不是偽造世界已正常更新。

## 4.4 世界精度是契約，不是滑桿的口號

CWSR 允許依規則將部分近似工作從高成本路徑退至統計或有界數值；但交易資產、人物 ID、劇情旗標、已發生的不可逆事件與權威存檔往往不能近似。路由器不能把違反關鍵身份、單位帳本或事件歷史的候選稱為「畫質差一點」並放行。

## 4.5 版本戳記與瞬時資源快照

世界版本、設備功能、driver／shader ABI、RAM／VRAM 壓力可能在路由選擇之後更新。Planning Snapshot 只能提供判斷時的資訊，不能免除 execution-admission 與 commit-time validation；必要時必須重做容量檢查或拒絕過時候選。

---

# 5. 路由候選生成：先保留成熟基線

## 5.1 至少包含保守路徑

候選集合 $\Omega_t$ 應盡可能包含已有正確性憑據的 CPU 既有流程：

$$
\mathcal R_{safe}\in\Omega_t.
$$

若因世界規則改動使原 fallback 也失效，這個假設不能強行成立；必須明示沒有已知安全路由，而不能宣稱永遠有安全解。

## 5.2 候選不是全笛卡兒暴力遍歷

一個世界批次可能有數十段工作、多個 backend、多種資料位置和尺度。把全部組合暴力列出會造成指數級候選爆炸。建議以因果 DAG 的可分解部分為界，使用 typed constraints、backend capability filtering、局部候選修剪、有限 beam／branch-and-bound 或保守啟發式生成少量可驗證候選；若生成成本超預算則停在已知路徑。

## 5.3 初始候選家族

| 家族 | 合法時可能適用 | 典型代價 |
|---|---|---|
| `CPU-Serial` | 小規模、強依賴、低 latency | 可能浪費可平行能力 |
| `CPU-SIMD` | 固定資料型別與規則、規整批量 | packing／vectorization |
| `CPU-Jobs` | 可拆分區域、較大工作、低衝突 | queue、steal、sync |
| `CPU-Event` | 稀疏變化與可追蹤期限 | 訂閱、Dirty Index、查詢成本 |
| `GPU-Direct` | 規整大量平行、資料已或可放入裝置 | upload、dispatch、fence、contention |
| `GPU-Resident` | 多階 device-side 工作流、可合法長駐 | VRAM、lease、stale generations |
| `Cache-Reuse` | 版本、依賴、精度與期限可證明有效 | validation、index、storage |
| `Hybrid` | 形態不同、可分階段且搬移收益正 | hetero synchronization、routing |
| `Fixed-Step-Fallback` | 持續動力、無法安全事件化 | 可能有較多固定更新 |

這些是候選**實現型態**而非 24／72 的新軸；不允許把它們硬寫成某格的唯一實現。

## 5.4 關閉自適應也是正式選項

若任務太小、形態沒有變化、資源常態穩定，或路由元數據開銷過高，Runtime 可以維持 `StaticRoute`；如果 24／72 分類沒有提高可行路由選擇品質，也應允許 `FormAblatedMode`。這兩種模式對 Paper 08 的研究可證偽性尤其重要。

## 5.5 計算形態只做合法修剪與候選展開

當 profile 表示近似規整的平行更新，可以提議 SIMD／Job System／GPU 而非直接硬選 GPU；當更新為 Jump／Selective，可提議索引、事件批次與 active-ID compaction；當更新為 Recognition／Retrieval，可提議快取或索引查找，但仍需記錄索引建立、失效、資料讀取和 provenance。這些只能形成候選集合，最終須由硬門檻和實測成本淘汰或接受。

---

# 6. Hard-Gate Admissibility：先正確，再考慮較快

## 6.1 可行集合

令候選集合為 $\Omega_t$，約束語境為 $\mathcal K_t$。定義：

$$
\Omega_t^{safe}=\{r\in\Omega_t\mid \operatorname{Admissible}(r,\mathcal K_t)\}.
$$

其中 `Admissible` 不是可任意調低門檻的性能分數，而是所有 hard constraints 的聯取：

$$
\operatorname{Admissible}(r,\mathcal K_t)=\bigwedge_{j=1}^{k}H_j(r,\mathcal K_t).
$$

只有當 $\Omega_t^{safe}$ 非空時，才可進行效能與 Pareto 取捨。不存在安全路由時須輸出 typed infeasibility，不能提交一個語義錯誤的「最快選項」。

## 6.2 不可略過的硬門檻

| Gate | 最小拒絕條件 | 可接受證據 |
|---|---|---|
| G1 World／Rule／Schema | 候選對應舊版或錯誤規則 | Snapshot／Rule hash |
| G2 Causal／Hazard | 衝突未排序、跨尺度事件遺漏 | Dependency proof／ledger |
| G3 Deadline | 必須完成的義務無合法時間排程 | Bound on critical path |
| G4 Precision | 準確性、數值或統計責任未保留 | Oracle／certificate |
| G5 Authority | 無合法世界寫入或資源使用許可 | Typed capabilities／lease |
| G6 Memory | 超 RAM／VRAM 容量、reserve 或 in-flight 上界 | Capacity snapshot＋bound |
| G7 GPU／ABI | Kernel、shader、driver 或 layout 不相容 | Backend profile／signature |
| G8 Persistence | 結果不可恢復、租約未安全解除 | Recovery contract／fence |
| G9 External Effects | 候選提前發生不可逆外部作用 | Effect staging／commit plan |
| G10 Scale Consistency | 聚合／細化失去身份、帳本或時間界限 | Scale certificate／ledger |

## 6.3 時間風險不是一律 soft objective

若遊戲規則要求特定模擬事件在指定期限前完成，該 deadline 是 hard constraint；若畫面 FPS 僅是偏好目標、但仍有可容忍最低幀率，也需清楚區分 render hard floor 與 performance soft target。可降低某些顯示品質，不代表可擅自延後世界必需事件。

## 6.4 硬容量不能只看平均值

設備可用 VRAM 隨渲染、驅動、外部工作與遊戲狀態改變。需要考慮 render reserve、in-flight、峰值暫存、碎片與測量不確定性。若只知道平均可用 VRAM，且沒有合理安全上界，則不得批准可能導致 OOM／渲染失敗的 GPU 路由。

## 6.5 對 Unknown 的 fail-closed 與保留義務

「候選被拒絕」不等於「事件已完成」。路由器須保存 Wake Ticket、deadline 與世界義務，改走安全 fallback、短期等待或向更上層回報 `NoAdmissibleRoute`。不得偷偷遺棄義務來維持畫面 FPS。

## 6.6 將實驗性分類器與安全決策層隔離

試驗 24／72 profile 能否提升性能時，允許記錄分類器的提議與真實所選路由，並在 shadow mode 比較預測。但分類器不能直接繞過驗證狀態機、內部 reserve 或 hard constraints。模型分數再高，也不得覆蓋 G1–G10。

---
# 7. 完整路徑成本：不是比較 CPU 函式與 GPU Kernel

## 7.1 核心誤判

若只測 CPU 路徑的總延遲，卻只測 GPU 單一 kernel 的 device execution time，會高估 GPU 優勢；若只看 GPU upload 而忽略已常駐 buffer 的連續工作鏈，又可能低估 GPU 優勢。因此測量單位應是相同規則義務、相同輸入 snapshot、相同提交條件的完整 execution route。

## 7.2 Route DAG 的臨界路徑

令路由 $r$ 包含有向無環階段圖 $\mathcal G_r$，各階段耗時為 $d_i$。若所有依賴必須完成才可啟動下一階段，理想下界可寫為：

$$
T_{cp}(r)=\max_{p\in\mathrm{Paths}(\mathcal G_r)}\sum_{i\in p}d_i.
$$

實際 wall-clock 時間還可能包括排程佇列、裝置爭用、抖動與無法重疊的資源約束；單純最長路徑公式只描述在給定階段時間和合法重疊假設下的結構性下界，不是可保證的實機上界。

## 7.3 分離工作量、延遲與吞吐

一條路由能以 GPU 高吞吐處理十萬個 NPC，不代表它適合一個截止時間僅剩 1 ms 的單一 NPC 決策；反之，CPU 任務總吞吐量較低，也可能具有較短的首次有效結果時間。至少記錄：

- `total_work`：CPU／GPU／資料搬移的總工作量與能源；
- `end_to_end_latency`：從必要 Ticket 到 Commit 或合法可觀察結果的時間；
- `throughput`：每單位時間完成且通過驗證的義務數；
- `deadline_miss`：按硬期限測量的違約率與最壞見證；
- `render_impact`：GPU 世界 compute 對 frame time／frame pacing 的額外影響。

## 7.4 全路徑成本向量

對路由 $r$ 定義估計成本向量：

$$
\widehat{\mathbf C}(r)=\langle \widehat T,\widehat E,\widehat M,\widehat V,\widehat D,\widehat R,\widehat S,\widehat U\rangle.
$$

分別表示 wall time、能量、RAM 峰值、VRAM 峰值、資料搬移、render interference、switch／recovery cost，以及估計不確定性。不同單位不得在無政策聲明時隨便相加。這是操作性的多維估計，不等於實際觀測值。

## 7.5 分解完整的 GPU 路徑

一條 GPU 路由可能需具體評估：

$$
T_{G}^{gross}=T_{route}+T_{prepare}+T_{upload}+T_{queue}+T_{dispatch}+T_{kernel}+T_{sync}+T_{readback}+T_{verify}+T_{commit}.
$$

此式是成本項列舉，不可把可重疊執行的項全部當成不可重疊的總時長。測量時須同時記錄 DAG critical path 和 GPU／CPU timestamp，以免重複或漏算。

## 7.6 CPU 也不是免費的

CPU 事件索引、Job queue、SIMD 重排、跨執行緒 cache line traffic、thread wake-up、鎖與原子操作同樣可能昂貴。若 CPU baseline 已是成熟 ECS／Job System，就不能拿 naive per-object main loop 代表 CPU 的唯一效能。

## 7.7 Resident 的長期成本

GPU-resident buffer 讓中間結果免於反覆上傳／下載，但其駐留量會佔用顯存、可能增加渲染記憶壓力與冷熱工作集抖動。評估時需有多個遊戲場景長時間窗口，而非只測同一筆暖機 batch。

## 7.8 Metadata Tax 與 Classification Tax

本篇的路由資訊、24／72 profile、cost model、history logging 都有成本。定義：

$$
T_{overhead}=T_{classify}+T_{plan}+T_{gate}+T_{monitor}+T_{replan}+T_{validate}.
$$

部分階段可能與執行重疊，但其 CPU 工作量與 RAM 仍存在。若 $T_{overhead}$ 的額外支出大於節省下來的必要計算，本篇自適應策略在該工作負載上不具性能優勢。

---

# 8. 成本證據、信心區間與硬限制估計

## 8.1 三種成本來源

1. **Structural Bound：** 由資料量、需求 buffer、最壞事件範圍、依賴 DAG 和已認證 kernel 限制得出，適合硬門檻。
2. **Empirical Profile：** 在明確硬體、OS、driver、編譯參數、世界 shape 下實際測量，適合性能排序。
3. **Predictive Estimate：** 回歸模型、歷史分桶或 AI 提議的可能成本，只能作為可撤回的輔助，不能冒充確保安全的最壞上界。

同一資料若來自不同 source 必須有不同 provenance；歷史 profile 在遊戲規則、kernel、設備或 driver 變更後需要重新確認。

## 8.2 不確定成本不可當成確定時間

對觀測性成本，建議保留分位數、信心區間或上下界而非只有平均：

$$
\widehat T_r\in[\underline T_r,\overline T_r].
$$

如果上界僅為依統計假設得到的高分位估計，必須明說其概率意義，不能把它當成硬 deadline 的形式證明；嚴格期限需使用可證明容量／排程界限或指定保守餘裕與風險接受政策。

## 8.3 路由使用的資料粒度

避免每幀為每個 NPC 跑新的性能模型。適合以 kernel family、活躍單元數、資料布局、變化密度、讀寫衝突級別、scale region、硬體 feature profile、render pressure tier 建立小型可版本化的 profile bucket。

當 bucket 不足以描述分支爆炸、資源劇變或新 MOD，須降級信任而不是外推精確數值。

## 8.4 現場測量不能破壞世界

可在非權威 sandbox、shadow execution、複製 snapshot 上評估候選，但若會消費真實 RNG 序列、造成外部副作用、寫入世界或延誤 deadline，就不能當成零成本探測。真實路由器使用 instrumentation 須受 CPU／GPU 時間與記憶體預算管制。

## 8.5 量測本身可能帶來偏差

GPU timestamp、profiler hook、資料 readback 與完整事件追蹤會增加不同程度的 overhead。正式比較需固定工具、開關和樣本策略，區分研究 instrumentation 下的數據與玩家實際 runtime 數據；不可只向某一個 baseline 開啟昂貴追蹤。

---

# 9. 多目標可行選擇：Pareto、字典序與簡單性偏好

## 9.1 Feasibility before Preference

對可行候選 $\Omega_t^{safe}$，再計算多目標偏序，而不是把硬世界錯誤用高 FPS 分數補償：

$$
\Pi_t^{Pareto}=\operatorname{Pareto}(\Omega_t^{safe},\widehat{\mathbf C},\mathcal P_t).
$$

這裡 $\mathcal P_t$ 是明示政策，不是任意自稱全域最優的 AI 決策。

## 9.2 Pareto 不必有唯一答案

一條路由低延遲但多耗 VRAM；另一條路由節省 VRAM 但降低 render headroom。若兩者均不在所有維度不劣於另一條，即屬非支配候選，不能只靠「最快」假設取代使用者明示的電力、畫面或世界期限要求。

## 9.3 政策在 Hard Gate 之後才生效

可採：`LatencyFirst`、`RenderStabilityFirst`、`EnergyFirst`、`MemoryConstrained`、`RiskBounded`、`BalancedPareto` 等明確政策；其 tie-break 也要確定性、版本化和可重播。政策不得動態修改必須守住的精度／世界正確性條件。

## 9.4 單機遊戲預設保守政策

當多條路由性能估計差異落在不確定範圍內，優先保留現有路由；若無明確優勢，優先選擇較低同步成本、較少跨設備搬移、較容易驗證與恢復的解。這是一種**可撤回的設計偏好**，不是計算理論定理。

## 9.5 正式審計輸出

每次做實際切換或保留路由時應保存：`candidate_ids`、`rejection_reasons`、`selected_route`、`cost_evidence`、`policy_version`、`resource_snapshot`、`scale_certificate`、`timestamp`、`fallback` 和後續 actual metrics。對於極高頻工作，可摘要記錄同型決策並保留可回放最小信息，避免日誌吞噬性能。

---

# 10. 動態切換：變換形態／設備／資料位置需要付成本

## 10.1 路由改變不是免費函式指標切換

從 CPU 事件執行變成 GPU-resident 可能需要 buffer 建立、SoA 轉換、搬移、shader warm-up、fence、依賴改寫與重新驗證；從微觀切換到中觀還可能需要合法 aggregation、身份帳本和歷史義務。這些都不是「選另一格」本身所能消除。

## 10.2 切換前的最低收益門檻

令維持舊路由在展望窗口 $h$ 的預計成本為 $C_{old}(h)$，改走新路由並承擔一次性切換後的預計成本為 $C_{new}(h)$，切換成本為 $C_{switch}$。對某個明確單位化且已指定權重的 soft policy，可以要求：

$$
\widehat C_{old}(h)-\widehat C_{new}(h)>\widehat C_{switch}+\eta.
$$

 $\eta$ 是為不確定性與頻繁震盪留出的遲滯餘裕。此標量不等式只能用在相同政策衡量下的可比較量；多維 Pareto 問題不能偷換成萬用單一分數。

## 10.3 Minimum Dwell Time

可以指定一個最短保持窗口 $d_{min}$，避免每幀因細微負載變化反覆移動 CPU／GPU 資料；但遇到世界正確性、device loss、硬資源超量或必須在期限前重規劃時，安全事件應優先於 dwell preference。

## 10.4 Hysteresis／Churn

追蹤：

$$
\chi(T)=\frac{\#\mathrm{RouteSwitches}(T)}{T}.
$$

若切換頻率升高、卻未降低 deadline miss 或總路徑成本，需加大遲滯、縮小候選集合、固定某 workload 的 route，甚至關閉自適應。不能把頻繁切換誤判為系統更聰明。

## 10.5 何時重規劃

正當觸發包括：可用設備改變、容量快照失效、渲染長期壓力改變、工作規模越過經量測 crossover 區間、規則／MOD 變動、state residency 失效、依賴拓撲改變、精度／deadline contract 改變及故障回復。

單純每經過一幀就重規劃全部世界工作，通常沒有必要。若固定週期重評估確有價值，也必須計入其成本。

## 10.6 Route Switch 不可偷渡 World Commit

切換只改變未來工作如何執行。切換前已開始的 GPU 工作若尚未提交，必須追蹤其 generation、是否可取消及是否能把候選結果安全轉交新路由。不能同時把舊路由與新路由的候選結果當作兩次權威世界更新。

## 10.7 Time-to-benefit 與較短玩家會話

預計在大型遊戲時間窗中可回收的 VRAM 搬移投資，不代表短短三分鐘測試也值得。切換策略應有 break-even horizon；遊戲暫停、角色死亡、存檔載入或進入選單可能讓預期收益窗口立刻縮短。

---

# 11. 24／72 的路由作用：分類帶來哪種可檢驗增量？

## 11.1 底空間軸 $\mathfrak B_2$

底空間採連續模型時，路由器可探索固定步進、數值積分、時間步縮放或規整 field kernel；採離散模型時，可探索事件圖、索引、位元運算、有限狀態轉移與稀疏工作。這是候選生成方向，不是設備限制：連續工作能在 CPU 上算；離散工作也能在 GPU 上算。

## 11.2 更新軸 $\mathfrak U_4$

- $\mathsf S$：可能對依賴深度敏感，慎重拆分，先看序邊與 critical path。
- $\mathsf J$：可優先評估 active set、事件索引與選擇性 materialization；仍需計入 index／compaction。
- $\mathsf P$：可提議 SIMD／Job System／GPU 批次；須先完成 write hazard 和 deterministic reduction 契約。
- $\mathsf R$：可提議 index lookup、cache reuse 或 materialized view；不能省略版本有效性。

同一任務可經歷 $\mathsf J\rightarrow\mathsf P\rightarrow\mathsf R$ 的形態路徑，並在不同後端完成。

## 11.3 觀察軸 $\mathfrak O_3$

 $\mathsf C$ 的輸出可能涉及精度與場值度量； $\mathsf D$ 的輸出可能涉及 ID、事件及離散結果； $\mathsf X$ 需要針對一組不可被單一容許表示共同保全的觀察不變量做額外驗證。這一軸主要約束**可接受的結果與驗證介面**，不是 GPU 排程優先級。

例如宏觀人口平均數與微觀 NPC 的逐一身份／財產帳本是不同不變量；若觀察語境要求兩者，不能因計算快就只傳回一個總平均。是否在正式原始軸意義下屬於 $\mathsf X$，仍需明確給出 $\Gamma$ 、容許表示族與不可共同保全的理由。

## 11.4 轉移律軸 $\mathfrak L_3$

對 $\mathsf F$，重點在確定性轉移與算法語義；對 $\mathsf K$，需記錄 RNG identity、分布、採樣語義及統計等價規則；對 $\mathsf Q$，必須有真正所需的相干／量子通道語義，不能以 GPU 浮點或 AI 推論冒充。

尤其，固定 seed 不會讓原先的隨機過程本體上變成普通確定函數型：在可重播實作層，給定 RNG seed／counter 後運行可重現；在模型轉移律層仍可能是 stochastic kernel。兩個觀察語境不得未註明地混用。

## 11.5 Classification Value Hypothesis

新增 form profile 可能減少 route candidate search，使不同形態的路由更易被預先篩選；也可能增加 metadata，卻沒有提高對硬體選擇的預測力。其增量由 Paper 08 對照 `form-aware` 與 `form-blind` 兩種**同樣具因果、設備、期限及完整成本輸入**的路由器測量，而非拿 full CWSR 與 naive main loop 比較。

---
# 12. 宏觀—中觀—微觀的路由不能只看資料量

## 12.1 Scale Context 不是硬體標籤

宏觀經濟可能適合 GPU 進行大批量更新，中觀城市物流可能適合 CPU 圖搜尋與 GPU 數值場共同完成，微觀 NPC 也可能形成適合 GPU 的大規模同構狀態處理。反過來，宏觀國家政策的少量非線性事件分支可能只需要 CPU。Paper 03 的尺度回答表示精度與因果作用範圍，不表示應固定使用哪台設備。

## 12.2 聚合前與細化後的不同 form profile

同一個城鎮的萬人需求在中觀層以群體統計表示時，可能是規整平行數值更新；當玩家進入城鎮要求逐一 NPC 故事與身份歷史時，可能變成離散檢索、分支決策與事件重播。路由切換要同時支付 aggregation／refinement、生成有效個體狀態、讀取錨點及驗證歷史的成本。

## 12.3 上行事件的保全

當玩家在微觀層毀損橋樑，中觀物流系統受到道路容量變更，宏觀商品價格可能依規則在下一個結算期改變。路由器不得只因宏觀 GPU 批次尚未到達足夠 batch size，就忽略中觀截止時間或橋樑不可通行事實。允許局部 CPU 快速處理並讓晚些的 GPU 維護合法總量。

## 12.4 下行規則的版本邊界

當宏觀稅率政策變更，中觀城市市場和微觀商人定價都可能受影響；若此時有 GPU-resident 市場資料，必須透過 rule/version invalidation、dependency ledger 或按 epoch 重建，防止舊稅率運算在新的世界修訂後被提交。

## 12.5 多時計算的時間切面

不同尺度可依 Paper 03 在不同 simulation epochs 更新；route DAG 應標記每個階段讀取的世界時間窗與 temporal cut。絕不能讓 macro step 的未來結果被 micro step 當成已在過去發生的事實，除非模型有明確預測資料與候選／權威分離。

## 12.6 自適應路由不得直接改變世界模型

選擇一個更簡略的 macro model，不是單純選另一台 CPU／GPU 或另一 form。若該模型改變可觀察義務、精度、不變量或轉移律，需作為**模型／尺度契約的合法變更**經 Paper 03 的判定；本篇路由只能在已認可模型與精度下挑選等價或容許近似的執行方式。

---

# 13. 駐留／搬移／回收作為路由的一部分

## 13.1 路由可能選擇留資料不動

假設世界狀態已合法 GPU-resident 且下一段也是 GPU-friendly 工作，優先考慮 device-side chain，避免 GPU→CPU→GPU 的不必要往返。但世界 authority 與版控仍在其指定的邏輯責任層，GPU buffer 只是副本或受約束的候選存放處。

## 13.2 何時需要搬移資料

只在新 route 真正需要不同 backend 且 full-path benefit 足以支付 transfer／layout／sync／eviction／recovery 成本時搬移。當 CPU 只需少量摘要值，可考慮 device-side reduction 後讀回少量摘要，而非整個城市狀態；前提是精度、依賴、身份與驗證契約允許。

## 13.3 路由與配置器的權限分離

Route Planner 只能要求 `ResourceReservation`／`ReplicaLease`。Memory Manager 負責物理區段，device queue 負責提交與 fence，Commit Gate 負責更新 canonical state。Planner 不應能透過釋放 RAM／VRAM 順便刪除世界已發生的事實。

## 13.4 Render Reserve 隨場景改變

低渲染負載場景可以給世界 Compute 較多 GPU 時間；高畫面負載時則縮小世界 Compute slice、移回部分 CPU、延後合法非緊急工作或保留較大顯存緩衝。但 Render Reserve 的改變也有觀測延遲與資源切換成本，不能每幀全量計算最優配置。

## 13.5 VRAM 不足時的合法行為

可以縮小 batch、串流 region、釋放可重建暫存、轉到 CPU 或拒絕 GPU 候選；不得丟棄不可重建的 NPC 行為歷史、任務旗標、已授權資產轉移或尚未完成的 Wake Tickets。

## 13.6 預記載與路由的分界

GCCF 05 所述 Predictive Preloading 可以把可能將進入視野的城市資料預先暖化，也可預編 shader 或 reserve buffer；但這是 `Prepare`，不是 `Execute` 或 `Commit`。若玩家突然轉向，預熱可以撤回；已承諾的世界義務則不可因預測失準而刪除。

---

# 14. 因果流、計算形態與 GPU 小流的聯合控制

## 14.1 三套圖不是同一張圖

- `Causal Graph`：哪些世界事實／事件依賴哪些其他事實；
- `Computation Form Graph`：哪些子工作採何種 24／72 profile 與轉移律；
- `Execution Graph`：哪些 backend、資料搬移、同步與驗證構成合法路徑。

三張圖有 bridge mappings，但不可任意合併成「GPU kernel DAG」；世界因果可能不等於執行排程邊，執行排程邊也可能只是資料局部性或設備使用要求。

## 14.2 先形成因果就緒前沿

從 Paper 02 的合法 Wake Tickets 與 Paper 05 的 read/write hazard 取得 ready frontier。若有迴圈依賴、動態 write set 或未知 side effects，須先透過驗證的 epoch barrier、固定點／迭代規則或保守序列化解除疑義。

## 14.3 Form-Aware Plan 只在 ready frontier 上工作

即使某工作被分類為並行 $\mathsf P$，也不能越過尚未完成的前置 world dependency。並行是相對依賴前沿的局部合法性，不代表全域事件可亂序完成。

## 14.4 準備、執行與提交的三次驗證

1. **Plan Gate：** 依當前規則與資源快照建立安全候選。
2. **Dispatch Gate：** 實際提交 CPU／GPU 工作前重新確認 lease／backend／generation／deadline。
3. **Commit Gate：** 根據已完成的證據檢查世界、依賴、精度、因果與權限才提交。

三個 Gate 不能視作同一張一次性批准文件；允許在它們之間拒絕或重規劃。

## 14.5 裝置可並行並不代表狀態可合併

若兩批 GPU 工作都讀同一舊版區域並寫同一資產總量，即使 kernel 能並行跑完也未必可交換。候選合併需明確 reducer、順序、衝突解決規則及世界時間；未定義合併時必須序列化或拒絕其中一批。

## 14.6 GPU 工作與 Render 的跨佇列依賴

Compute Queue／Graphics Queue 可有 async overlap，但是否真能重疊取決於 GPU 架構、driver、同步和資源競爭。需測量真實 frame pacing 與世界截止延遲，不以 API 支援 async compute 就假定一定加速。

---

# 15. 六組世界案例：路由選擇是一種可驗證假說

## 15.1 案例 A：城市一萬人生活需求

輸入：一萬居民有飢餓、睡眠、工作等有限狀態，部分規則在每個世界時間段必須更新；居民資料有固定身份、可能存在先前積累的不可逆事件。

**候選分段：** 按到期／事件過濾 $\mathsf J$，對活動個體批量需求更新 $\mathsf P$，對群體供需做 reduction，最後由 Commit Gate 更新權威狀態。

**可能 route：** CPU 事件索引＋CPU SIMD、CPU 事件索引＋GPU resident parallel update、成熟 CPU Jobs 或合法的固定步進。

**拒絕條件：** 若 GPU 需要每名居民大量不規則腳本分支且資料搬移高於節省成本，GPU route 應被淘汰；若事件索引維護接近全掃描成本，可能以 fixed step 更好。分類不會預先保證收益。

**評估：** 總工作量、p95 deadline、VRAM peak、render slowdown、NPC 軌跡／資產完整性與形態分類成本。

## 15.2 案例 B：數十萬個地區市場需求單元

宏觀市場具備相對規整的需求函數與區域約束。可評估 GPU 局部 numerical kernels，再以中觀 boundary ledger 和 CPU 權威邏輯處理真正交易與不可逆資產。當供需轉移規律改變或 MOD 加入複雜條件分支，原先 profile 可能失效，須重新 gate。

**對照：** 直接 GPU 批次（不帶 form profile）與 24／72-aware routing 必須在相同資料布局、相同 kernel 和相同資源政策下比較，才能識別形態感知的增量價值。

## 15.3 案例 C：連續天氣格點與離散災害事件

一個天氣區域可能包含連續近似數值積分，適合 GPU field kernel；當某區域超過災害閾值時，離散災害事件需送回經驗證因果途徑，產生道路、農產、城市及 NPC 影響。GPU 產生的候選閾值不等於權威災害已發生，須符合指定數值精度與時間切面才可提交。

**路由候選：** CPU-only fixed step、GPU-grid＋CPU-event、GPU resident event-compaction；各自比較全路徑和歷史正確性。若 GPU 浮點非決定性使某災害命中不同世界規則分支，則該路由在 Bitwise Exact 契約下不可行。

## 15.4 案例 D：玩家炸毀橋樑後的物流

微觀破壞事件立刻更改橋樑通行約束；中觀物流需重新尋路；宏觀商品統計可在明定結算窗口更新。由於局部最緊急工作的 deadline 可能短於大規模 GPU 重新計算，合理路由或為 CPU 先更新斷路與少量受影響路徑、GPU 在另一個合法時間窗重算大規模運量矩陣。

此處最重要的不是理想 FLOPS，而是**因果時間順序與真正的跨尺度義務**。若 GPU 批次更快卻把橋樑已毀事實延後到玩家穿過橋後才生效，即為失敗。

## 15.5 案例 E：快速旅行與十日世界推進

玩家瞬間前往遙遠城市時，Runtime 可針對規則允許的事件做解析式或批次 time-skip；對必須逐步解決、可能引入新因果邊的事件則要保留順序與期限。Form path 可能有稀疏 Jump、部分規整 Parallel 和歷史 Retrieval。

若所有事件都一律提前展開到 micro 精度，可能耗盡資源；若直接用 macro 統計偽造具名 NPC 的個人歷史，則失去身份與因果正確性。最終 route 需要 Paper 03 的合法細化憑據與 Paper 02 的事件重播責任。

## 15.6 案例 F：MOD 讓居民行為從簡單狀態轉移變成腳本 AI

新 MOD 改變規則版本、read/write set、分支複雜度與 side effects。舊 GPU kernel 的編譯結果、form profile、cost history 及批次合併證據均可能過時；Router 必須標記不相容候選，回到仍合法的腳本／CPU fallback，待重新建置依賴圖、kernel 和對照測試後才允許 GPU route。

**額外反例：** 若 MOD 要求讀取無法在 GPU 上取得的外部資料，禁止把舊估計的 GPU 平行性能當成當前候選的真實能力。

---

# 16. 對資源與義務同時敏感的路由演算法

## 16.1 參考流程，不是已驗證實作

```text
function route_ready_world_work(verified_frontier, current_world, resource_snapshot):
    assert verified_frontier.has_durable_or_replayable_tickets

    request = build_route_request(
        frontier       = verified_frontier,
        world_stamp    = current_world.canonical_stamp,
        scale_context  = current_world.scale_certificates,
        time_contracts = current_world.outstanding_obligations,
        resources      = resource_snapshot,
    )

    if request.has_unresolved_causal_hazards:
        return preserve_tickets_and_fallback_or_hold("CausalUnknown")

    forms = classify_with_versioned_context(request)
    if forms.is_unknown_or_low_confidence:
        forms = FormAnnotation::Unclassified

    candidates = generate_bounded_candidates(
        request, forms, include_safe_baseline = true)

    admissible = []
    for candidate in candidates:
        decision = evaluate_hard_gates(candidate, request)
        if decision.is_admissible:
            admissible.push(candidate)
        else:
            audit_rejection(candidate, decision.typed_reasons)

    if admissible.is_empty:
        return preserve_tickets_and_report_no_admissible_route()

    estimates = collect_versioned_cost_evidence(admissible)
    ranked = pareto_filter_then_apply_explicit_policy(estimates)
    selected = hysteresis_and_switch_cost_guard(
        current_route = request.current_route,
        proposal      = ranked.best_candidate,
        deadline      = request.deadline,
        safety        = request.hard_constraints)

    plan = freeze_versioned_proposal(selected, request, estimates)
    return plan
```

本演算法的 `safe baseline` 僅能在實際仍合法時存在；`classify_with_versioned_context` 未成功，不得使世界停止所有工作；而 `freeze_versioned_proposal` 仍不意味可直接執行。

## 16.2 第二階段：承諾之前必須重新批准

```text
function dispatch_and_commit(plan, live_resources, canonical_world):
    dispatch_check = refresh_dispatch_gates(plan, live_resources, canonical_world)
    if dispatch_check.rejected:
        preserve_all_unfulfilled_tickets(plan)
        return replan_or_known_safe_fallback(dispatch_check)

    lease = reserve_declared_cpu_gpu_memory_and_time(plan)
    if lease.rejected:
        preserve_all_unfulfilled_tickets(plan)
        return replan_or_known_safe_fallback("CapacityChanged")

    receipt = execute_candidate_plan(plan, lease)
    if receipt.failed:
        release_or_quarantine_in_flight_resources(lease, receipt)
        return recovery_procedure_preserving_world_duties(receipt)

    evidence = verify_result_against_current_world(
        receipt, plan, canonical_world.current_revision)

    if not evidence.permits_commit:
        discard_or_rebase_only_with_proof(receipt)
        return preserve_tickets_and_retry_if_legal()

    commit = canonical_world.commit_gate(evidence, receipt.candidate_changes)
    if commit.accepted:
        record_effects_and_mark_obligations_fulfilled(commit)
        return commit
    else:
        return preserve_tickets_and_handle_commit_rejection(commit)
```

此流程只是具責任分層的偽碼。真實同步、執行併發、device loss、資源與 lease 強制等細節由 Paper 07 實作；不能因偽碼中函式叫做 `verify` 就推斷它已提供形式證明。

## 16.3 標準失敗返回

至少應區分 `WorldStale`、`RuleChanged`、`CausalUnknown`、`DeadlineInfeasible`、`PrecisionViolation`、`AuthorityDenied`、`CapacityChanged`、`KernelUnsupported`、`InvalidReplicaGeneration`、`DeviceLost`、`SwitchBenefitUnproven`、`NoAdmissibleRoute`、`CommitRejected` 和 `FallbackUnavailable`。

這些失敗不得全部記成 `GPU error`；也不得全部導向自動擴張 RAM 或降低精度。不同原因有不同合法恢復策略。

---
# 17. Rust 介面草案：形式座標、候選、硬限制與路由回執

## 17.1 為什麼用 Rust 作為參考

Rust 的所有權、借用和型別系統有利於表達 snapshot reference、replica lease、有限生命週期和錯誤分支，但不能自動證明 NPC 因果依賴、GPU shader 正確性、跨尺度歷史有效性或機率分布等價。本節是**未編譯的接口草案**，並非已交付程式庫；可由 Paper 07 將它拆分成 Rust crate 與後端 adapter。

## 17.2 形態座標保持 canonical axes

```rust
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
pub enum StateBasis { Continuous, Discrete }

#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
pub enum UpdateMode { Sequential, Jump, Parallel, Recognition }

#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
pub enum ObservationMode { Continuous, Discrete, SingleMeasureRefusal }

#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
pub enum TransitionLaw { Function, StochasticKernel, QuantumChannel }

#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
pub struct Form24 {
    pub basis: StateBasis,
    pub update: UpdateMode,
    pub observation: ObservationMode,
}

#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
pub struct Form72 {
    pub morphology: Form24,
    pub transition: TransitionLaw,
}

#[derive(Clone, Debug)]
pub struct FormContext {
    pub classifier_basis_version: String,
    pub rule_revision: u64,
    pub observation_contract_id: String,
    pub resolution_contract_id: String,
    pub source_evidence_id: String,
}

#[derive(Clone, Debug)]
pub enum FormProfile {
    Single { cell: Form72, context: FormContext },
    Set { possible: Vec<Form72>, context: FormContext },
    Path { steps: Vec<Form72>, context: FormContext },
    Stack { layers: Vec<Form72>, context: FormContext },
    Unclassified { reason: String, context: Option<FormContext> },
}
```

實際實作可以把 `FormDistribution` 加入型別，但需要具有可檢驗校準方式的權重來源，不能靠未定義的假機率造出 72 格可信度。

## 17.3 Backend 與工作語義分離

```rust
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
pub enum BackendClass {
    CpuSerial, CpuSimd, CpuJobs, CpuEvent,
    GpuDirect, GpuResident, CacheReuse,
    Hybrid, FixedStepFallback,
}

#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
pub enum PrecisionContract {
    BitwiseExact,
    BoundedNumerical,
    Statistical,
}

#[derive(Clone, Debug)]
pub struct RouteWorkStamp {
    pub world_revision: u64,
    pub sim_epoch: u64,
    pub rule_revision: u64,
    pub schema_revision: u64,
    pub mod_hash: Option<String>,
    pub scale_certificate_id: Option<String>,
}

#[derive(Clone, Debug)]
pub struct ExecutionStage {
    pub stage_id: u64,
    pub predecessors: Vec<u64>,
    pub backend: BackendClass,
    pub kernel_or_algorithm_id: String,
    pub verified_semantics_id: String,
    pub required_state_refs: Vec<String>,
    pub candidate_write_set: Vec<String>,
}

#[derive(Clone, Debug)]
pub struct RouteCandidate {
    pub route_id: u64,
    pub request_id: u64,
    pub stamp: RouteWorkStamp,
    pub forms: FormProfile,
    pub stages: Vec<ExecutionStage>,
    pub fallback_route_id: Option<u64>,
    pub policy_version: String,
    pub cost_evidence_version: String,
}
```

## 17.4 硬限制應當返回 typed failure

```rust
#[derive(Clone, Debug, PartialEq, Eq)]
pub enum HardGateFailure {
    WorldOrRuleStale,
    CausalConflict,
    DeadlineNotAdmissible,
    PrecisionNotVerified,
    ExecutionAuthorityDenied,
    MemoryBudgetExceeded,
    BackendIncompatible,
    UnsafeReplicaOrRecovery,
    PrematureExternalEffect,
    ScaleInvariantViolation,
    RequiredEvidenceUnknown,
}

#[derive(Clone, Debug)]
pub enum GateVerdict {
    Admissible { certificate_ids: Vec<String> },
    Rejected { failures: Vec<HardGateFailure> },
}

#[derive(Clone, Debug)]
pub struct RouteScoreEvidence {
    pub route_id: u64,
    pub estimated_latency_bounds_ns: Option<(u64, u64)>,
    pub measured_p95_ns: Option<u64>,
    pub ram_peak_bound_bytes: Option<u64>,
    pub vram_peak_bound_bytes: Option<u64>,
    pub transfer_bound_bytes: Option<u64>,
    pub render_interference_evidence_id: Option<String>,
    pub uncertainty_policy_id: String,
    pub measurement_provenance_id: String,
}

#[derive(Clone, Debug)]
pub struct RouteProposal {
    pub selected: RouteCandidate,
    pub hard_gate: GateVerdict,
    pub selection_evidence: RouteScoreEvidence,
    pub rejected_candidate_ids: Vec<u64>,
    pub prior_route_id: Option<u64>,
    pub reason_for_switch: String,
}
```

這些型別不強迫使用 `String` 作高頻熱路徑身份；Paper 07 可改用 interned IDs、typed integer handles 或 immutable shared metadata。上述例子主要確保語義欄位不被遺失。

## 17.5 真正需要的 Runtime 邊界

```rust
pub trait RoutePlanner {
    fn propose(&self, request: &WorldRouteRequest) -> Result<RouteProposal, RouteError>;
}

pub trait ExecutionAdmission {
    fn admit(&self, proposal: &RouteProposal) -> Result<Reservation, RouteError>;
}

pub trait CandidateExecutor {
    fn execute(&self, reservation: &Reservation) -> Result<CandidateReceipt, RouteError>;
}

pub trait WorldCommitAuthority {
    fn verify_and_commit(
        &mut self,
        proposal: &RouteProposal,
        receipt: &CandidateReceipt,
    ) -> Result<CommittedWorldRevision, RouteError>;
}
```

`WorldRouteRequest`、`RouteError`、`Reservation`、`CandidateReceipt`、`CommittedWorldRevision` 尚待 Paper 07 定義；**本程式碼不是完整的可編譯範例**。意圖是把四種責任編譯為獨立介面，阻止 Planner 僭越真正的 world writer。

## 17.6 反對把 72 寫成硬體驅動選項

不可設計如下錯誤介面：

```text
bad_route(form_72_id):
    if form_72_id is PARALLEL:
        return GPU
    else:
        return CPU
```

這會混淆計算分類與設備能力，略過 read/write conflict、精度、資料搬移、deadline、記憶體和渲染競爭。正確的最小模型為：`Form Profile + Validated Work Contract + Backend Capabilities + Hard Constraints + Measured Costs + Policy → Candidate Route`。

---

# 18. 路由演化與失敗恢復狀態機

## 18.1 建議路由狀態

`Proposed → Checked → Reserved → Dispatching → InFlight → DeviceCompleted → Verified → CommitAccepted`。

任何階段也可能走到 `Rejected`、`Stale`、`Cancelled`、`RecoveryPending` 或 `CommitRejected`。不要以單一 bool `completed` 表示任務已完成，因為裝置運算完成、世界驗證通過與歷史提交是不同事件。

## 18.2 Frozen Proposal 與重規劃

在已凍結的計畫中，設備快照、policy version 和選中候選不得悄悄改寫。當 VRAM 容量變動或 GPU 故障時，應生成新的 proposal 並鏈到舊 proposal 的 audit ID；舊計畫的未完成義務仍須保留且不能雙重履行。

## 18.3 GPU 故障後的 CPU 恢復

若 GPU kernel 因 device loss 或資源不足未能形成可驗證候選，嘗試 CPU safe route 前須確認 CPU 需要的最新權威資料仍可取回或從合法事件記錄重建。若僅剩 GPU 中已損毀的不可恢復資料，不能假裝安全恢復；必須回報儲存契約的失敗。

## 18.4 推理器或 AI Planner 失聯

CWSR 的 world-critical route 不應以即時呼叫外部 LLM 作為必須成功的唯一通路。AI 可提出 profile、長期路由優化與候選 kernel，但線上安全決策需有本地可用且確定性的 policy/fallback。即使不執行 AI，遊戲仍應能依既有規則處理必要義務。

## 18.5 Unknown 的逐層縮退

當高解析度 form 不可判定時，可依序縮退到較粗的 workload family、靜態可驗證 backend feature、成熟 CPU／GPU policy 或已知固定流程。縮退路徑每一步仍需 hard gate；「較保守」不代表自動合法。

---

# 19. 可證偽命題與最低論證責任

## 19.1 P06-1：Form 不決定 Hardware

**命題：** 固定 $\langle B,U,O,L\rangle$ 不足以唯一決定可行硬體與執行成本。

**理由：** 同一形態的計算可以用 CPU serial、CPU SIMD、GPU shader 或不同資料布局實作，而各自有不同的 data movement、memory capacity、deadline 與同步成本。此命題是概念性不充分性判斷，不是新的數學定理。

**可反駁方式：** 若有人主張存在某個明確限制問題類別，使某 form 在指定硬體集合中唯一對應一個可行 backend，可在該限定域內給出定義、證明與實驗；不應將這個限定結論推成通用法則。

## 19.2 P06-2：硬門檻先於優化

若候選 $r$ 違反規則身份、期限、精度或容量硬限制，則 $r$ 不屬於可行集合。此結果直接由 `Admissible` 的定義成立；它不是本篇的效能實驗成果。

**測試責任：** 任一 Gate Failure 必須在 route ranking 之前拒絕，即使某候選號稱更高 FPS 或更低平均耗時。

## 19.3 P06-3：形態感知可能減少搜尋，但不保證改善性能

當 profile 能有效篩除不相容候選，且分類開銷比節省的搜索／錯誤嘗試更低時，形態感知的路由可能更快；若 backend 選擇已由簡單 shape features 高效完成，24／72 註記可能沒有額外收益。

**可證偽條件：** 在相同候選和性能觀測下，FormAware 對比 FormBlind 的總成本、正確率和切換率未見改善，或改善小於分類成本。

## 19.4 P06-4：切換只有在合理窗口才有收益

若路由切換造成的重建、搬移、warm-up 和驗證成本超過相同窗口內可節省的工作成本，則切換在該 policy 衡量下不具正收益。

**可證偽條件：** 若路由器忽略短期 horizon 或經常選到負收益切換，應調整或停用 hysteresis／switch model。

## 19.5 P06-5：動態世界局部可採混合計算形態

一個跨尺度世界更新工作可能需要多段不同 update mode 與不同 backend；若所有依賴與權威世界義務可保留，混合 route 是合法候選。它不是由 24／72 的格點數推得，而是以具體任務分解、算法與驗證責任為前提。

**可反駁條件：** 選定系統中所有候選混合方案均有額外同步或精度錯誤，導致全 CPU／單 backend 路徑更佳時，應承認混合路由在該域無效益。

## 19.6 P06-6：Backend 成功不足以推出 World Commit

GPU kernel 返回成功或 CPU 函式無錯誤，仍可能輸出來自舊版規則、重複交易、錯誤模擬時間或不滿足精度的候選。因此 route completion 不保證 Commit Gate 接受。這是依既有狀態模型的邏輯區分。

## 19.7 P06-7：路由器的最佳決策取決於觀察環境

相同世界規則與資料在不同 GPU render pressure、VRAM 可用容量、CPU 負載、driver、模擬期限下可能有不同可行或較優路徑。沒有上述前提就宣稱跨機器通用最優路由，是不充分的。

## 19.8 P06-8：有些系統應永久維持成熟固定路由

對工作非常小、每步都具有真實必要更新、資料形態單一且平台穩定的子系統，分類／監控／切換開銷可能大於任何可節省計算。此時 `StaticRoute` 是可被正式選擇的結果，而不是研究失敗被隱藏。

---
# 20. 基準實驗：必須讓「24／72 的增量」可以單獨失敗

## 20.1 研究不是比較最慢與最快的示範

若 CWSR 只有和 naive O(N) 每幀更新相比而勝利，可能證明的只是事件化、批次化、SIMD、GPU Compute 或更好的資料布局有用；它**沒有**證明 24／72 路由文法帶來新的性能效益。因此至少採下列共同工作負載與義務的對照：

| 組別 | 配置 | 主要要排除的混淆 |
|---|---|---|
| B0 | naive per-frame object loop | 僅作最基本參照，不能作唯一 baseline |
| B1 | 成熟 CPU ECS／SIMD／Job System | 排除「只因優化普通迴圈」的假陽性 |
| B2 | CPU Event／Dirty Flag／Deadline | 排除「只因減少不必要執行」的假陽性 |
| B3 | 成熟 GPU Compute 直接批次 | 排除「只因使用 GPU」的假陽性 |
| B4 | 異質 CPU／GPU，依完整 shape／cost／gate 路由，但**不使用 24／72** | 檢驗一般成本感知路由的實際基線 |
| B5 | B4 加入既有 24／72 profile，保持其餘條件相同 | 檢驗計算形態分類的增量 |
| B6 | B5 加入 hysteresis、history 與故障重規劃 | 檢驗自適應切換的增量與代價 |
| B7 | B6 去掉一項 gate 或成本欄位作受控非權威 shadow ablation | 辨識治理開銷與不可接受風險，不可投入玩家的權威世界 |

B7 只允許在隔離測試環境中比較；不能為了速度而在真實權威世界關閉因果、容量、身份或提交門檻。

## 20.2 公平比較必需條件

所有組別都必須使用相同的世界規則、NPC／市場／天氣資料、版本 seed 與 RNG policy、事件期限、可觀察結果、存讀檔語義、渲染場景、圖形品質目標及容許精度。當一組採用近似算法而另一組採用精確算法，必須在相同誤差契約下重新對照；不能拿少算義務的 route 當優勢。

## 20.3 一個基準必須包含遊戲真實工作

至少涵蓋：(i) 稀疏變化的 NPC 需求與日程；(ii) 稠密的人口數值更新；(iii) 宏中微跨尺度物價與物流；(iv) 連續天氣場與離散事件；(v) 高衝突交易；(vi) MOD 動態更改規則；(vii) 快速旅行與時間跳進；(viii) 高渲染負載、低 VRAM 餘裕情境。

## 20.4 主要硬體與軟體變數

記錄 GPU 型號、VRAM、CPU 架構與核心數、RAM 容量及速度、OS、driver、API backend（如 Vulkan／DirectX／CUDA）、編譯器與 optimization flags、shader hash、引擎版本、圖形設定、螢幕解析度及 GPU render utilization；在不同 consumer devices 上重複測試，不能只挑對新路由有利的平台。

## 20.5 性能指標

報告：p50／p95／p99 end-to-end obligation latency、每秒合法提交的世界工作量、world deadline miss、frame time p95/p99、frametime spikes、CPU 使用率／thread time、GPU compute timeline、GPU render contention、RAM／VRAM peak、transfer bytes、buffer recreation rate、能源或可取得的設備功率與路由器 metadata overhead。

為了避免只看 FPS，應將世界進度義務和視覺回應同時列入；更高 FPS 但世界時間偷跑或 NPC 歷史遺失，直接判為語義不通過。

## 20.6 正確性與公平性指標

至少包括：Commit Gate rejection、world-state hash（對 bitwise 模式）、跨尺度身份與資產不變量、事件 exactly-once 或合約指定的去重語義、重播一致性、RNG counter 消費、deadline 義務完整性、Bounded Numerical 誤差、Statistical 的分布檢驗及其信賴區間。

## 20.7 交叉負載與分位數

不要只跑一個平均負載。對 CPU／GPU 路由特別應用：活躍項目數、資料形狀、稀疏度、branch divergence、衝突比、buffer residency、GPU render pressure、world change rate 和期限窗口做交叉組合；每組需要充足且獨立的樣本，並事先指定停止與失敗判準。

## 20.8 Crossover 不是只畫一條曲線

CPU/GPU crossover 應在不同工作量、resident／nonresident、render load 和 precision policy 下測量。即使發現臨界點 $n^*$，它也通常依硬體及資料狀態而變，不能寫成普遍固定的 NPC 數量門檻。

## 20.9 避免測量污染

熱機與冷機、shader compile cache、OS file cache、GPU 使用率、背景程式、初次場景載入及 save/load 路徑需分開。對自適應策略須提供長時間 workload transition trace，否則無法量測切換抖動、冷熱資料策略和學習錯誤。

## 20.10 何謂失敗

如果 B5 與 B4 的效率幾乎無差，或 B5 因分類 metadata 變慢，則必須報告「本類負載未發現 24／72 帶來可測增量」；如果 B6 比 B5 多次抖動且無明顯收益，則應認為自適應策略的現行參數失敗。不能用「分類更具哲學意義」來抵消工程基準失敗。

---

# 21. 測試矩陣：正確性、性能與失效域

| ID | 測試條件 | 必須保持的結果 | 預期失敗代碼／反證 |
|---|---|---|---|
| T06-01 | 分類器輸出 $\mathsf P$，CPU SIMD 可行且 GPU 超小批次 | 不固定綁 GPU；仍比較 full-path | GPU 僅測 kernel 時誤選 |
| T06-02 | $\mathsf J$ 更新但 Dirty Index 成本過高 | 可選全量 CPU 掃描 | 路由 metadata 超過工作本身 |
| T06-03 | $\mathsf R$ 快取未滿足 revision／deadline | 禁止重用過時結果 | `WorldOrRuleStale` |
| T06-04 | $\mathsf X$ 被分類器當作不可測 | 拒絕錯誤分類或降級未分類 | `FormContextInvalid` |
| T06-05 | 一般 GPU 作業被標 $\mathsf Q$ | 不通過轉移律標註檢查 | `TransitionLawMisclassified` |
| T06-06 | 新 MOD 加入寫入 hazard | 舊 route 被撤銷，義務保留 | `CausalConflict` |
| T06-07 | world revision 在 GPU dispatch 後改變 | 舊候選不得直接提交 | `WorldStale` |
| T06-08 | VRAM reserve 在 planning 後下降 | 重做 admission／改 CPU／拒絕 | `CapacityChanged` |
| T06-09 | 高 frame time，但世界事件到期 | 保護世界硬期限並合法管理渲染 | `DeadlineInfeasible` |
| T06-10 | 快速旅行跳過十日 | 時間義務與 NPC 身份仍可重播 | Missing wake／ledger mismatch |
| T06-11 | 兩個 route 同時完成同一交易 | 僅合法一次 Commit | Double commit |
| T06-12 | CPU/GPU 浮點改變關鍵分支 | Bitwise 需求下拒絕新 route | `PrecisionViolation` |
| T06-13 | GPU device lost，僅有舊權威快照 | 恢復到合法版本，Ticket 仍存在 | `RecoveryUnavailable` |
| T06-14 | 外部 LLM／AI Planner 不可用 | 不影響本地必要世界義務 | Planner dependency deadlock |
| T06-15 | 成本估計信心不足 | 保留成熟 route 或安全 fallback | False hard-time guarantee |
| T06-16 | GPU 需大量資料上傳與回讀 | 全路徑比較，允許 CPU 勝出 | Kernel-only benchmark bias |
| T06-17 | 相同工作，B4 對 B5 | 單獨量測 form profile 增量 | No incremental benefit |
| T06-18 | 相同工作，B5 對 B6 | 單獨量測 hysteresis／切換代價 | Excessive route churn |
| T06-19 | 觀測成本升高 | 降低分類頻率或改靜態 route | Instrumentation dominates |
| T06-20 | 宏中微不同時鐘聯動 | Causally consistent temporal cut | Future-read violation |
| T06-21 | GPU candidate 未經授權外部作用 | 禁止先行副作用 | `AuthorityDenied` |
| T06-22 | 不可重建的狀態被標為可回收 | 確認拒絕釋放 | `UnsafeReplicaOrRecovery` |
| T06-23 | 重複 / 亂序 Wake Ticket | 去重、排序或保守重播 | Duplicate obligation |
| T06-24 | 索引不存在引入新匹配 | 動態依賴與負向查詢喚醒 | Missed dynamic dependency |

**必要產物：** 每個測試至少提供 fixture hash、world/rule/schema 版本、route policy、硬體快照、事件順序、預期 oracle、實際結果、是否採用 fallback、測量方法與失敗證據。若需要統計檢驗，另附樣本數、信心水準與多重比較策略。

---

# 22. 反例與負面結果的正式收錄

## 22.1 F06-A：所有世界狀態每次都變

若工作已是密集且必須每次更新，選擇性執行節省不了必要總工作；24／72 profile 至多幫助找合適硬體與算法，不會使 O(N) 的必要讀寫神奇消失。

## 22.2 F06-B：任務太小

極小型計算可能只需單一 CPU 函式呼叫，任何索引查找、classification、GPU dispatch 或 policy 計算都比必要工作昂貴。最佳路徑可能是永遠不進自適應 Router。

## 22.3 F06-C：依賴完全不明

對黑盒逆向遊戲，如果無法可靠推導 read/write sets 和時間義務，嘗試全事件化、GPU 化並不能保證遊戲正確性；此時可保持成熟主循環／隔離的局部已知安全熱點最佳化。

## 22.4 F06-D：渲染與 GPU 世界計算完全競爭

若 GPU render queue 已接近 frame deadline，世界 compute 可能造成嚴重視覺卡頓，GPU 的高理論吞吐不可等同玩家體驗更好。應允許 CPU 工作、合法推遲或縮小 batch。

## 22.5 F06-E：最佳 route 快速反覆切換

分類、路由與 hysteresis 不當導致每秒多次 CPU/GPU buffer 互搬，其穩態效率可能低於固定單一 backend；不能把動態行為本身當成正面成果。

## 22.6 F06-F：24／72 已被 shape features 完全涵蓋

若在確定 workload／backend 集合中，僅憑稠密度、分支、資料布局、read/write hazard 和尺寸已能選出相同候選，24／72 的附加標記沒有足夠資訊增益。這不推翻其作分類學的存在價值，卻會**限制本篇對路由優化的應用主張**。

## 22.7 F06-G：模型近似越過世界界限

若為了性能將微觀身份或經濟交易替代為無憑據的宏觀平均，即使整體曲線相似，也不能算同一世界規則下的合法路由。其正確名稱是新的模擬模型或近似政策，不可混入 route 實作的等價比較。

## 22.8 F06-H：設備能力和跨平台語義不一致

某些 GPU、driver 與 shader backend 對整數溢位、浮點順序、atomic、memory model 或 workgroup size 的處理限制不同。未提供實際一致性證據，應避免聲稱同一 72 格 across device 等價。

## 22.9 F06-I：形式分類不穩定

當語境或解析度小幅變更就造成大規模分類換格，路由器可能放大不必要切換。需固定 classification context 版本、使用 form-region／form-path 或保留既有 route，而不是強行每幀選新格。

## 22.10 F06-J：資料重建不可行

若 CPU 版本已回收、GPU replica 已失效，且世界歷史缺少可恢復證據，fallback 可能不存在；這是 Paper 04 的存放契約和 Paper 06 的規劃失敗，不可暗示重算一切都能恢復。

---

# 23. Paper 07｜Runtime 與引擎適配的精確交接

## 23.1 最小可運行目標

Paper 07 不必實作完整 GCM／GCCWT／GCCFT 世界計算架構，也不必先完成龐大開放世界。優先使用 Rust 建立「固定世界 fixture + verified event frontier + form-aware Router + CPU baseline + 一個 GPU compute adapter + Commit Gate + replay」的**可運行、可量測參考系統**。

## 23.2 建議里程碑

1. **M1 — Deterministic CPU Reference：** 固定世界身份、狀態版本、Wake Ticket、明示 read/write hazards、deadline、權威提交、replay oracle。
2. **M2 — Route Types and Hard Gates：** 實作 `RouteCandidate`、FormProfile、backend capability、typed rejection、no-admissible-route、fallback。
3. **M3 — FormBlind Heterogeneous Router：** 在不用 24／72 的條件下，僅用形狀、資源及端到端成本選路，建立強力 B4 baseline。
4. **M4 — FormAware Layer：** 加入版本化 24／72 分類，嚴格保留未分類與複合形態，量測 classification tax。
5. **M5 — GPU Residency and Fences：** 使用一個經認證的 kernel family，連接 device buffer generation、submission、fence、candidate receipt 與 Commit Gate。
6. **M6 — Dynamic Switching：** 引入 profile、hysteresis、replanning、render reserve、fallback 及 audit trail。
7. **M7 — Multi-Scale Fixture：** 加入城市、居民、商品物流與時間跳進，對應 Paper 03／05 的跨尺度因果案例。
8. **M8 — Engine Adapter：** 提供 Godot／EveWorld 可選適配器，不要求取代現成物理、渲染或主循環。

## 23.3 最小接口責任矩陣

| 元件 | 讀取權 | 寫入責任 | 不可做之事 |
|---|---|---|---|
| World Registry | 讀 world ID／revision | 由 canonical writer 管理 | 以設備指標代表世界身份 |
| Wake Controller | 讀事件／期限／Guard | 管理 Ticket lifecycle | 刪除未完成義務 |
| Scale Adapter | 讀尺度契約／錨點／帳本 | 產生候選 scale transition | 憑摘要偽造個體歷史 |
| Form Classifier | 讀 typed work context | 產生可撤回 annotation | 直接寫權威世界 |
| Route Planner | 讀可行選項／budget | 產生 frozen proposal | 覆蓋 hard gates |
| Resource Allocator | 讀物理可用量 | lease／reservation／release | 刪除邏輯世界事實 |
| Backend Executor | 讀合法 snapshot 和 leases | candidate receipt | 未經 Gate 直接提交 |
| Commit Gate | 讀完整版本／規則／證據 | 唯一權威 world mutation | 把未證明候選當成事實 |
| History／Replay | 讀路由及世界提交記錄 | durable audit／replay records | 把預測 preload 記成真實事件 |

## 23.4 驗證基準先於大規模升級

每加入新 GPU kernel、新 MOD 或新路由策略，應以已通過正確性檢查的 CPU 版本和世界 fixture 作對照；不能僅以編譯成功、沒有崩潰、畫面正常或單一 FPS 數據宣布成功。

---

# 24. Paper 08｜證偽性能與語義驗證的交接

## 24.1 必須公開的實驗條件

同一套 input fixtures、明確世界規則及時序、完整 backend／driver 組態、policy 版本、資料布局、RAM／VRAM peak 和核心指標。沒有完成這些元資料，即使 benchmark 速度很好，也不足以提供可重現證據。

## 24.2 三個主比較問題

- **Q1 正確性：** CWSR 是否在因果、身份、精度、期限與世界提交上與指定規則保持一致？
- **Q2 整體效能：** 相對成熟 CPU／GPU／事件系統，CWSR 在何種 workload 達到較好的總延遲、render stability、能源或記憶體效率？
- **Q3 真正增量：** 保留相同 scheduler、backend、cost model 與 Gates，24／72 FormAware 是否比 FormBlind 更值得其分類成本？

## 24.3 第一輪論文不可寫的結果

在 Paper 08 實測以前，禁止宣稱「GPU 世界小流提高 FPS 某百分比」、「消費級顯示卡可執行百萬 NPC 無代價」、「24／72 一定能讓計算效率提升」、「不需再升級硬體」或「新 Runtime 已超越所有傳統引擎」。這些不是 Paper 06 所能論證的實測結論。

## 24.4 成功也必須有適用域

如果在稀疏變化的單機模擬中有優勢，但在持續全量、高分支、強同步或低 VRAM 的工作中沒有優勢，則如實將系列成果限制到適用域。這比把整套架構宣稱成所有軟體應採用的普遍法則更精確。

---

# 25. 已知成熟技術、上游原稿與研究責任

## 25.1 本系列直接承接的 CWSR 原稿

1. Neo.K × Aletheia，**CWSR Paper 00｜因果世界狀態運行：既有計算理論的單機遊戲 Runtime 延伸總綱**，v0.1，2026-10-16。`CWSR_Paper00_Causal_World_State_Runtime_Series_Charter_v0.1_2026-10-16.md`。
2. Neo.K × Aletheia，**CWSR Paper 01｜世界狀態本體與可執行狀態分離**，v0.1，2026-10-16。`CWSR_Paper01_World_State_Ontology_and_Executable_State_Separation_v0.1_2026-10-16.md`。
3. Neo.K × Aletheia，**CWSR Paper 02｜因果觸發、執行休眠與條件喚醒機制**，v0.1，2026-10-16。`CWSR_Paper02_Causal_Trigger_Execution_Dormancy_and_Conditional_Wakeup_v0.1_2026-10-16.md`。
4. Neo.K × Aletheia，**CWSR Paper 03｜宏觀—中觀—微觀多尺度世界模擬**，v0.1，2026-10-16。`CWSR_Paper03_Macro_Meso_Micro_Multi_Scale_World_Simulation_v0.1_2026-10-16.md`。
5. Neo.K × Aletheia，**CWSR Paper 04｜動靜態記憶體契約與選擇性物化**，v0.1，2026-10-16。`CWSR_Paper04_Dynamic_Static_Memory_Contracts_and_Selective_Materialization_v0.1_2026-10-16.md`。
6. Neo.K × Aletheia，**CWSR Paper 05｜CPU／GPU 異質世界計算與因果小流**，v0.1，2026-10-16。`CWSR_Paper05_CPU_GPU_Heterogeneous_World_Computation_and_Causal_Microflows_v0.1_2026-10-16.md`。

## 25.2 已核對的 EveMissLab 上游來源

7. Neo.K，**《計算的二十四重範式》**，正式版候選稿 v4.0，2026-07-19。`計算的二十四重範式_正式版_v4.0.md`。
8. Neo.K × Aletheia，**《從二十四重計算形態學到七十二格計算動力學》**，v0.1，2026-07-19。`從二十四重計算形態學到七十二格計算動力學_v0.1.md`。
9. Neo.K × Aletheia，**《全域計算方法論：異質計算的全域一致組合》**，v0.1，2026-08-23。`01_全域計算方法論_異質計算的全域一致組合_v0.1.md`。
10. Neo.K × Aletheia，**GCCF 04｜全域可尋址狀態與選擇性物化**，v0.1，2026-09-22。`GCCF_04_Globally_Addressable_State_and_Selective_Materialization_v0.1_zh-TW.md`。
11. Neo.K × Aletheia，**GCCF 05｜因果流計算與預記載**，v0.1，2026-09-22。`GCCF_05_Causal_Flow_and_Predictive_Preloading_v0.1_zh-TW.md`。
12. Neo.K × Aletheia，**GCCF 06｜計算 24 範式與 72 格作為全域計算路由文法**，v0.1，2026-09-22。`GCCF_06_24_Paradigms_72_Cell_Global_Computation_Routing_Grammar_v0.1_zh-TW.md`。
13. Neo.K × Aletheia，**GCCWT Paper 04｜計算場與資源激發：跨 CPU／GPU／Memory／Agent 的動態執行域**，Draft v0.2。`GCCWT_Paper04_Draft_v0.2.md`。
14. Neo.K × Aletheia，**GCCWT Paper 06｜AI 原生全域調度：從 Task Scheduler 到 World Computation Planner**，Draft v0.2。`GCCWT_Paper06_Draft_v0.2.md`。
15. EveMissLab，**GCM Phase B：Deterministic Compute Allocator 技術白皮書**，v0.1，2026-08-27。`GCM Phase B：Deterministic Compute Allocator 技術白皮書 v0.1.md`。
16. Neo.K × Aletheia，**《從有序計算到全域耦合計算》統合母論文**，v0.1，2026-09-22。`Global_Coupled_Computation_Integration_Mother_Paper_v0.1_2026-09-22.md`。

## 25.3 成熟外部工程背景與未補齊的文獻責任

本篇的事件排程、增量計算、Dirty Flag、ECS、Job System、SIMD、SIMT、GPU Compute、GPU／CPU 資料傳輸、cache locality、multi-objective scheduling、Pareto frontier、hysteresis、兩階段驗證與資料版本控制均與既有大量成熟工程技術有關。本文不將其發明權歸於 CWSR。正式公開投稿前，應進行獨立的外部文獻檢索、實際引擎對照和適當引用，尤其關於 work stealing、heterogeneous task scheduling、GPU compute graphics contention、incremental dataflow、multi-scale modeling 與 uncertainty-aware scheduling。

**來源聲明：** 上述內部文檔用於繼承及語義核對，不代表經過獨立同行審查；上游型別或方案的「已提出」不等於已在消費級硬體上證明可行。

---

# 26. 結論

CWSR Paper 06 所提出的不是另一套 24／72，也不是要求每個遊戲變成由 AI 完整接管的異質超級排程器，而是一個狹義的單機遊戲工程接口：**在世界義務已確認、尺度與精度已約束、資源與授權可檢查的條件下，讓局部計算形態成為路由決策的可版本化資訊，而不讓任何分類取代因果、硬限制、真實成本或權威提交。**

其最重要的操作順序為：

```text
Verified World Obligation
  -> Dependency-Ready Frontier / Scale Contract
  -> Versioned 24/72 Form Annotation (or Unclassified)
  -> Capability + Backend Candidate Generation
  -> Hard-Gate Admissibility
  -> End-to-End Cost and Uncertainty Evidence
  -> Pareto / Explicit Policy / Switching Hysteresis
  -> Frozen Route Proposal
  -> Dispatch-time Resource Recheck
  -> Execution and Candidate Receipt
  -> Verification + Canonical Commit Gate
  -> Audit, Recovery, and Replanning
```

因此，24／72 的主要價值在於可能提高**可理解、可比較、可組合、可版本化的計算形態描述能力**；它是否能實際改善某款遊戲的速度或資源使用，必須留待與 FormBlind 強基準及成熟 CPU／GPU 路徑同條件驗證。如果新增 profile 沒有資訊增量，或切換成本高於收益，CWSR 應接受不使用分類器或固定成熟路由的結果。

這回到了整個系列最初的工程立場：**不把增加硬體視為開放世界動態模擬的唯一解法，也不以複雜的新治理取代早已足夠好的程式；而是先界定世界真正需要完成哪些因果工作，再以符合期限、精度、記憶體及畫面需求的最低合法成本，選擇實際應啟動的計算。**

Paper 07 應將本篇的可行性門檻、路由型別、保守退路與計算形態剝離實驗落實為可執行 Runtime；Paper 08 則以實測結果判定其可行域與失敗域。未來若需要對母理論補充新軸或新物理詮釋，應另行修訂上游，而不是將本篇工程接口偷換成新的基礎理論。

---

**End of CWSR Paper 06 v0.1 — UTF-8 Markdown Canonical Source**