title

CWSR Paper 08｜可證偽驗證與開放世界效能基準

english_title

Falsifiable Validation and Open-World Performance Benchmarks: Semantic Equivalence, Strong Baselines, Consumer GPU Measurement, and Applicability Boundaries

series

CWSR — Causal World-State Runtime

paper

08 / 08

version

v0.1

date

2026-10-16

author

Neo.K

ai_research_collaborator

Aletheia / GPT-6

institution

EveMissLab / 一言諾科技有限公司

status

Research Draft — Benchmark and Falsification Protocol Complete; Execution Evidence Pending

canonical_source

UTF-8 Markdown; mathematical delimiters $...$ and $$...$$ only

language

zh-TW

predecessor

CWSR Paper 07 v0.1

series_closure

Paper 00–08 first-round research-document closure; empirical conclusions NOT established

CWSR Paper 08｜可證偽驗證與開放世界效能基準

語義等價、強基線、消費級 GPU、異質路由增量與工程適用域的系列閉合研究

English: Falsifiable Validation and Open-World Performance Benchmarks: Semantic Equivalence, Strong Baselines, Consumer GPU Measurement, and Applicability Boundaries

系列位置： CWSR Paper 08 / 08；本篇為 Paper 00–08 第一輪研究原稿的收束篇。

研究責任： 把前七篇的世界狀態、因果義務、尺度、記憶體、CPU／GPU、24／72 路由與參考 Runtime 契約，轉換為可執行、可反駁、可重播及能產生負面結果的效能與正確性基準。

目前證據狀態： 已提出測試方法、假說、資料格式、執行順序與交付契約；本篇沒有宣稱完成 Rust 編譯、GPU kernel 測試、Godot／EveWorld 真實整合、B0–B7 實機比較或取得任何效能改善數值。除非未來將帶原始證據的測試結果追加為新版本，本文表內所有數字門檻都是預註冊範例／研究協定選項，不是觀測結果。

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

摘要

CWSR（Causal World-State Runtime）從單機遊戲「畫面沒有變化，程式仍可能持續執行」的觀察出發，逐步將邏輯世界、執行義務、局部活動、動靜態記憶體駐留、異質 CPU／GPU 運算及權威狀態提交分離。Paper 01–07 已提出可操作的介面與條件：事件不該因休眠而遺失、宏觀摘要不應偽造微觀歷史、GPU 執行結果不是已提交世界事實、24／72 計算形態不是特定硬體的速度排名。然而，以上都不足以證明 CWSR 真的讓遊戲更快、更省記憶體、更穩定，或讓相同硬體承擔更大的開放世界。

本篇建立系列正式的雙軸驗證結構。第一軸為語義及可靠性門檻：世界事件、依賴訂閱、時間期限、身份、資產與流量帳本、候選／提交隔離、GPU 同步、存檔恢復、MOD 規則變更，均須在適當的精確、容差或分布等價條件下成立。第二軸才是效能與資源的比較：在相同規則、輸入、可觀察精度、硬體條件及評量窗口下，讓 CWSR 與成熟固定更新、CPU ECS／Job System、事件／Dirty Flag、GPU Compute、普通異質路由（FormBlind）、帶 24／72 註記的 FormAware 路由與遲滯治理版本競爭。

本文固定 B0–B7 比較架構，建立至少十二類工作負載與多維參數因子，設計冷／熱啟動、模擬時間快進、渲染佔用、VRAM 壓力、記憶體回收、訂閱競態、裝置失敗及 MOD 熱更新的反例。量測不只報平均 FPS，也報 p95／p99 frame time、模擬吞吐、CPU／GPU 端到端成本、RAM／VRAM 峰值、傳輸量、deadline miss、路由治理成本、重建時間、世界錯誤率及跨尺度可觀測精度。

本篇也定義明確的增量問題：B3 相對 B1/B2 的收益是 GPU／成熟架構的成果；B4 相對 B3 是一般異質路由的成果；只有 B5 相對同一 FormBlind B4 的額外收益，才可能支持 24／72 分類具有工程增益。B6 相對 B5，才測到遲滯、歷史與重規劃的增量。 若分類沒有額外效益、事件管理比全量迴圈昂貴、渲染競爭使 GPU 工作不值得、或世界狀態發生語義錯誤，必須接受局部或全部假說失效，而不能把基線降級或改變世界規則來保留預期結論。

因此，本篇的交付不是宣告 CWSR 已超越主流遊戲引擎，而是建立足夠嚴格的測量協定、負面結果規則、工程准入門檻與研究歸檔方式。Paper 00–08 的正式原稿系列於此完成第一輪研究文件閉環；真正的 Runtime／GPU 性能結論仍須由本地、跨設備和獨立重播證據產生。

關鍵詞： CWSR；Falsification；Open-World Simulation；Benchmark；Consumer GPU；CPU ECS；Event-Driven Simulation；Simulation LOD；Global Computation；24／72 Computational Forms；FormBlind；FormAware；Causal Microflow；Commit Gate；World Replay；Multi-Scale Correctness；RAM／VRAM；Frame Pacing；Hysteresis；Reproducibility。

0. 系列閉合究竟代表什麼

0.1 文件系列的閉合，不等於經驗性主張的閉合

本篇完成後，可以準確宣稱：

1. CWSR Paper 00–08 均有獨立 UTF-8 Markdown 原稿；
2. 第八篇確定了如何判斷前七篇提出的工程假說是否成立；
3. 已經制定候選基線、工作負載、量測資料格式、否定條件和發布門檻；
4. 未來工程團隊可依規格建置 test harness，測得正面、零效益或負面結果；
5. 「沒有完成實機驗證」仍然是公開而不可隱藏的事實。

不能準確宣稱：

1. CWSR 已通過全系列驗證；
2. 已達到任意 NPC 數量或幀率；
3. 全部 GPU 顯示卡都能高效處理此類世界工作；
4. 24／72 一定改善路由；
5. 已完成實用 Rust Runtime、Godot／EveWorld 正式插件；
6. 實驗以文檔形式交付，等於有了實際測量結果。

0.2 延伸而非重新建母理論

本篇不重新定義 Computation 24/72、GCM、GCCF、GCCFT、GCCWT、PCMT 或 GIPE 的基礎概念。CWSR 用它們描述世界計算候選，再用現有可測的遊戲引擎、CPU、GPU 與 OS 指標決定是否值得部署。

0.3 上游研究的具體驗證承諾

0.4 必須分開的五類證據

規格證據（Specification Evidence）： 已定義某介面或不變量。
靜態證據（Static Evidence）： 原始檔通過格式與靜態分析。
執行證據（Execution Evidence）： 程式在記錄的環境成功編譯、運行與測試。
比較證據（Comparative Evidence）： 可公平比較的多組實測。
外部證據（Independent Evidence）： 非原作者或另一獨立環境可重現的結果。

五類證據不可由前一級自動推出後一級。

1. 研究假說：每條都允許失效

1.1 H08-1｜義務正確性

在已明示世界規則、時鐘與全部依賴的測試域中，合格 CWSR Runtime 應保留和基準相同的必要事件與期限。若任一必要事件無理由被跳過、重複提交或超過硬性期限，該路由即為不合格；效能改善不能補償。

1.2 H08-2｜稀疏變化的有效管理

當狀態更新稀疏、依賴可追蹤、喚醒索引成本較低時，義務保全的事件／條件喚醒可比全量定期掃描減少有效 CPU 工作及記憶體活動。若更新密度提高導致索引成本超過節省量，應觀測到交叉點並啟用退路。

1.3 H08-3｜跨尺度可觀測等價

對可合法聚合與細化的模型，宏／中／微尺度切換可在已預先聲明的觀察量、身份及帳本不變量下保持等價或有界誤差。若已銷毀不可逆的個體資訊而又聲稱原樣還原，主張直接失效。

1.4 H08-4｜RAM／VRAM 駐留收益

選擇性駐留在部分工作集可降低峰值、持續駐留量或傳輸頻率，但須同時計入重建、I/O、lease 管理與 tail latency。若只減少 VRAM 卻造成長時間卡頓，不足以構成綜合成功。

1.5 H08-5｜GPU 因果小流端到端收益

對規整、弱耦合、資料足夠大、可合批且數值語義適配的工作，消費級 GPU 世界計算有機會降低完整更新成本；對小型、強分支、需要立即回讀的工作，可能更慢。

1.6 H08-6｜FormAware 的獨立效益

在完全相同的硬門檻、候選後端、量測資訊、切換機制與 tuning budget 下，加入 24／72 計算形態註記的 B5，只有在預註冊指標上勝過 B4，才可主張分類本身產生額外工程收益。未顯著改善或結果不穩定時應接受零效益。

1.7 H08-7｜動態遲滯的穩定效益

在工作形態或資源負載變動的情形，B6 的遲滯／重規劃可減少不必要 route churn；但若反應遲緩而多次錯過真正的快速路徑，也可能輸給 B5。

1.8 H08-8｜保守回退安全性

設備失敗、版本失效、分類不確定、VRAM 不足及 MOD 改規則時，系統能拒絕無證據候選並恢復至有效 CPU 或既有引擎路線；不能只報告成功執行而忽略損毀的世界狀態。

1.9 H08-9｜渲染競爭可被辨識

世界 GPU compute 可能改善模擬吞吐卻損害 frame pacing。本篇要求測得競爭，而不預設 Async Compute 必然改善畫面時間。

1.10 H08-10｜治理成本具有明確損益點

依賴追蹤、記憶體治理、Form annotation、路由與候選驗證都不是免費的。只有完整治理成本低於省略或改善的工作，才有工程收益。

1.11 H08-11｜消費級硬體可用性

在已事先定義的低、中階及高階硬體樣本中，CWSR 至少部分子系統可在不需要專用 AI 卡或外部伺服器的情況下工作；是否達到性能目標必須分別報告，不預設各裝置的通用性。

1.12 H08-12｜原始碼可重播且結論可獨立檢查

第三方能取得同一 fixture、版本、環境、隨機種子、路由設定與原始輸出，對至少一個平台重播主要結論；否則僅能稱內部報告，不稱已獨立再現。

2. 正確性優先的科學問題

2.1 「更快」不是沒有前提的謂詞

任一效能比較必須指定：

• 世界規則、rule revision 與 schema；
• 世界初態及必要歷史；
• 固定輸入事件與外部干擾；
• 模擬時間、真實時間與截止期限；
• 合法觀測集、可容忍誤差及隨機模型；
• 硬體與渲染工作負載；
• 預熱狀態、編譯／快取狀態、存讀檔階段；
• 計入哪些 CPU／GPU／I/O／同步與治理成本。

若上述任一要素不同，不可把速度比直接歸因於 Runtime 架構。

2.2 三類等價性不能混為一談

精確語義（Exact）： 預先指定的整數、身份、財產、事件順序、存檔版本和不可逆歷史不容忍差異；可用同一規則、同一 seed 的精確快照或事件規範比較。

有界近似（Bounded Approximation）： 如天氣或經濟連續量，在同一觀測窗口下以量綱正確的誤差界與守恆檢查比較；不得任意將全量微觀 oracle 定為唯一真相，因不同模擬解析度可能本身採不同合法模型。

分布等價（Statistical）： 隨機 NPC 或群體擴散若不能逐路徑對應，必須事前固定可比較的統計量、種子策略、置信區間及距離度量。單次結果相似不等於分布等價。

2.3 世界事件不是畫面像素

若兩個版本畫面相同、但一個漏算遠方城鎮的飢荒或重複產生貨幣，兩者不等價。正式 oracle 至少包含：已提交狀態、時間義務、歷史來源、可觀測查詢及事件因果鏈。

2.4 完整世界不必全部微觀物化

GCCF 的選擇性物化只允許邏輯與駐留分離，不允許替換必需世界資訊。當某項個體歷史被宣告必須精確恢復，不能用「重新生成相似角色」代替。

2.5 多條強基線可有不同工作等價性

固定物理步長、事件驅動以及模擬 LOD 不一定具有完全相同內部事件順序；必須以規格共同可觀察量與事前定義的等價條件測量，不可讓 CWSR 單方面放寬義務，而使 B0–B3 承擔更嚴格規則。

3. 形式化測量契約

3.1 共用狀態與必要義務

沿用 Paper 01–07 的原始記號，不另起新的計算本體：

$N_t$ 是必要世界義務， $P_t$ 是合法延後但不可遺失的義務， $A_t^Q$ 是具活動執行資格的工作， $R_t^{\mathrm{run}}$ 是實際執行工作。觀測不能只在 $R_t^{\mathrm{run}}$ 上計數。

3.2 可比較的實驗單元

令一個實驗單元包含：

其中 $F$ 是固定 fixture 規則， $S_0$ 是初態與歷史快照， $U$ 是事件輸入軌跡， $\Gamma$ 是語義及觀測契約， $H$ 是硬體／驅動環境， $C$ 是編譯與設定， $B$ 是測試基線。相同的 paired experiment 只允許 $B$ 隨設計變化；可疑差異必須加記錄並使結果標為不可比。

3.3 觀察投影與合格條件

對被預先允許的觀察投影集合 $\mathcal O_\Gamma$，先定義結果通過：

此式只適用於有合法距離 $d_o$ 的情形。精確 identity、資產守恆及離散事件序需以獨立不可豁免的不變量檢查，不可以平均數掩蓋少數嚴重違規。

3.4 CPU oracle 的適用域

Paper 07 的單執行緒、全域 revision barrier Rust 參考核心是初期狹窄的語義 oracle；它不是已知可以無損承載所有跨尺度物理、隨機世界及 GPU 平行演化的全域真理。超出可證明等價域時，要改用解析不變量、經驗參照、統計測試或已知數值解的 fixture。

3.5 事件守恆和因果一致性

必要事件的唯一身份和前置關係須可由 audit log 檢查。對任何義務 $n$，須有且只有一種合法結論：已按期提交、仍在容許等待窗口內、已由明確規則取消、或已產生可追蹤失敗。不存在無聲消失的第五種狀態。

3.6 資源契約

任何 route 的有效性都要求實測或可驗證的資源使用不超過當次配置的硬限制，包括 RAM、VRAM、host-staging、GPU in-flight bytes、模擬 deadline 和 render reserve；不許把驅動外部負荷估計當作已確認的實際保證。

3.7 世界提交與性能量測的先後關係

Candidate 結果若超出版本／規則／期限／精度契約而被 Commit Gate 拒絕，不應納入「成功世界吞吐」。可以另計算失敗嘗試成本與候選生成吞吐，但不得當成遊戲世界已完成工作。

4. B0–B7 強比較基線

4.1 對照組的整體定位

4.2 B0｜Naive Per-Frame CPU Baseline

與 Paper 06／07 一致，B0 是正確但不含專項最佳化的逐幀 CPU 更新基線；其價值在於說明被優化的原始負擔，不能作為唯一強基線。必要時另設獨立的決定性 CPU 語義 oracle（可共享規則與 trace，但不可無條件等同於 B0 的執行策略），優先便於審計、重播與檢查世界不變量。

4.3 B1｜成熟 CPU 版本

B1 應採用相同資料布局或公平可比較的 SoA、ECS、SIMD、任務切片、現代編譯最佳化及 cache-friendly 設計。對只適合 serial 的場景允許 serial。B1 應有公開的 tuning 策略和完整執行緒成本；不能僅用低最佳化單執行緒 C++ 或 Rust 對比 CWSR。

4.4 B2｜成熟事件與增量版

B2 必須真的實作事件訂閱、dirty propagation、期限計時器、物理休眠、必要時的 catch-up 與保守 fallback；也須滿足同一不可漏事件與版本契約。不能把 B2 寫成「每幀仍掃描全部 NPC 的事件版」。

4.5 B3｜成熟 GPU Compute 版本

B3 可使用最自然且公平的 compute batching、資料駐留與同步策略；GPU kernel 必須與 CWSR 同等最佳化預算，考慮 Vulkan Compute、CUDA 或相同平台可支援的計算 API。若 B3 只測 kernel 而 B5 包含全部同步，結果不可比較。

4.6 B4｜FormBlind 異質路由

B4 使用和 B5 同樣的：

• 同一 Work Contract、Guard、Precision、Deadline、Authority；
• 同一成本模型、設備能力、可行候選及資料需求；
• 同一 profiling budget 與參數調整權限；
• 同一合法預取、預載、失敗恢復和 Commit Gate；
• 只移除 24／72 計算形態註記與其導出的功能。

此分離是整個系列最重要的公平比較之一。

4.7 B5｜FormAware 24／72

B5 以既有三軸 24 分類、第四軸候選轉移律和組合路徑作為額外決策註記。但它不能多取得 B4 沒有的未來真值、未公開的測試分布、更多預算或更高權限。若無法把標註資訊和單純的 ComputeShape 特徵分離，須明示資訊重複及無可識別增量。

4.8 B6｜動態路由治理

B6 在 B5 基礎上加入切換成本、hysteresis、route history、regret audit 和 replan freeze window。當世界突然切換負載時，這些機制有可能幫忙，也可能因遲滯延後最優切換。

4.9 B7｜剝離實驗，不冒充正式世界結果

B7 至少包含移除依賴索引、移除預取、固定尺度、不使用 GPU resident、移除分類、移除遲滯與 shadow-only 推薦。對於省略必要 guard 或驗證的版本，只能在隔離試驗環境記錄其錯誤率，不得將該版本帶入正常可提交基線。

4.10 Baseline 強度審查

每一組由同一測試委員或不同開發者審查是否遭不對稱最佳化：編譯選項、memory allocator、工作資料布局、精度、GPU kernel、執行緒數、shader cache、引擎 settings 皆須公開。對表現最弱的組別先檢查是否存在人為不公平，再考慮解釋 CWSR 勝利。

5. 工作負載矩陣：十二種世界狀態情境

以下工作負載是預先設計的 fixture，不是聲稱已生成或執行的測試資料。每個 fixture 必須固定 seed、世界規則、事件產生器、正確性 oracle 或不變量、工作集規模及觀察窗。

5.1 W08-01｜靜態不是零義務

將玩家站立無操作、無背景可見變化和有／無世界期限兩組分離。禁止將「輸入不變」偷偷等同於「天氣、商店或任務期限不變」。量測 idle CPU、wake-up 數、睡眠狀態、p99 frame time 和必要模擬進展。

5.2 W08-02｜真稀疏及動態依賴

輸入包含角色裝備／關係變動、任務條件由 false 變 true、負向查詢結果翻轉及監聽器建立時的競態。對於先檢查再訂閱的實現，刻意插入提交事件證明是否漏喚醒。

5.3 W08-03｜零收益區域

將更新密度逐步提高到近乎全量，保留相同世界輸出。檢查事件索引、work ticket、計數器、分類器和路由器是否成為純額外負擔；這是應當允許 B1 或固定 tick 勝出的場景。

5.4 W08-04｜規整 GPU 候選

使用明示的群體狀態向量、簡單需求轉移、容量上限及可被比較的輸出聚合。禁止宣稱「百萬個完整 AI NPC 同時獨立思考」；本 workload 測的是數值／群體層的簡單狀態，不是大型語言模型推論。

5.5 W08-05｜橋樑與物流

由單一橋樑狀態變更觸發運送路徑變化、貨物延遲、城市供需變動、區域價格回饋。所有貨物流入流出必須可由雙向帳本或事件來源重算，任一商品不得因尺度切換被憑空增殖。

5.6 W08-06｜連續世界格網

測 CPU 向量版、GPU 常駐版、每步 readback 版與混合版本。用穩定數值方法或適當的參考解、固定邊界條件及守恆誤差檢查；浮點 bitwise 相同不應強制於本質上不同的合法算法。

5.7 W08-07｜Time Jump

時間向前跳數小時或多天，期間設有定時貿易、NPC 約會、疾病事件和非決定性事件來源。實驗不能直接把中途所有事件折疊掉，除非具有正式可接受的聚合證據；存檔後再快進亦需一致。

5.8 W08-08｜身份錨點

生成固定具名角色及不可逆歷史，從微觀離開至中觀／宏觀再返回微觀。檢查角色 ID、職業、關係、重要決策、已發生事件及未履行時間約定是否可恢復；禁止以隨機樣貌相似代替。

5.9 W08-09｜記憶體壓力

先給出 VRAM budgets 和最低渲染保留，再逐步增加世界 resident buffers、prefetch、readback 和 staging。測到具體峰值與回收成本，不以任務管理員的單一「GPU memory」欄位概括所有配置責任。

5.10 W08-10｜Render Contention

相同世界輸入，分別設無圖形、輕圖形、中圖形、重圖形與固定 GPU render budget。記錄世界 update latency、GPU queue 等待、frame present、p99 frame time、VRAM、clock state 和 shader cache 狀態。

5.11 W08-11｜MOD 與 schema

在同一 fixture 中更換影響 NPC、物價或資源生成的規則版本。已有 GPU cache、CPU dirty result、持久化快取和路由 profile 須明示失效。實驗包括回滾至舊 schema 的拒絕或合法遷移。

5.12 W08-12｜全域觸發與高階耦合

若全球災害同時影響所有城市，事件增量法很可能沒有稀疏優勢；需比較直接 B1/B3 及 CWSR 的 fallback。高階耦合可能使局部依賴圖需要廣泛重建，這是合格的負面結果。

6. 實驗因子、交叉點與可行域抽樣

6.1 五類必要自變數

單看世界總物件數會誤導。至少採用五類彼此區分的因子：

1. 狀態規模 $n$： 活動節點、非活動節點、邏輯身份和工作集大小分開統計。
2. 有效變化密度 $\rho$： 每個模擬時窗真正有必要變動的比例；須以 oracle 事件義務計數，而非以候選工作數替代。
3. 因果結構 $\kappa$： 依賴扇出、動態依賴比例、高階耦合與最大傳播深度。
4. 資源壓力 $\mu$： RAM／VRAM headroom、傳輸量、GPU 渲染佔比及儲存延遲。
5. 時間與精度 $\theta$： Deadline、模擬 tick、尺度階層、觀察頻率和可容忍誤差。

6.2 工作規模不是單一數字

最少註冊四種尺寸：小型（驗證功能）、中型（看到路由門檻）、大型（觸及容量）、壓力型（期待 fallback 或拒絕）。可以把工作規模設定成實際可完成的裝置適配值；不能因高規格機器可跑，就要求較低規格機器同規模跑到 OOM 再稱其低效。

6.3 變化密度掃描

建議以固定世界規模、調整更新密度的曲線找交叉點。初始候選水平可設： $\rho\in\{0,0.001,0.01,0.05,0.2,0.5,1\}$ ；這組只是範例，正式預註冊須鎖定使用的序列並說明其抽樣理由。

6.4 因果扇出掃描

從獨立事件、低扇出連鎖、可界定 DAG、高扇出及含循環義務的情形逐步增加難度。事件數一樣，傳播成本也可能完全不同；不能以事件總量代表因果工作量。

6.5 時間跳躍與高頻連續子系統

同一世界包含純事件結算、週期結算、固定物理步進以及獨立時鐘的 NPC 日程。必須比較每次 tick 都演化與可合法跳躍狀態的對應結果；不容許把不可逆中間事件視作數值插值直接略過。

6.6 記憶體工作集熱度

分成靜態資產、大量冷資料、局部熱資料、全量熱資料與不可重建資料五類。若某狀態熱度突然上升，記錄工作集重建代價；若快取回收導致反覆搬移，需標為 thrashing，而不能僅報平均駐留量降低。

6.7 CPU 與 GPU 負載配對

CPU 載入度、可用執行緒、GPU graphics utilization、VRAM headroom、PCIe／共用記憶體限制都可能改變最佳路徑。因此每個路由結論應包含可行的硬體環境與同期 render 負載資料。

6.8 交叉點是研究結果，不是應被掩蓋的失敗

若 $\rho$ 上升使事件化 CWSR 逐漸輸給 CPU ECS，這表示找到了適用域邊界。正式報告應呈現曲線與預先定義的切換政策，而不是只挑低 $\rho$ 點當作全部結論。

7. 正確性不變量清單與拒絕優先級

7.1 G08-01｜世界 ID 和版本

每一個權威世界變動都由唯一世界身份、rule/schema revision、基準 revision 與 commit record 關聯。相同物件 ID 不可在不同尺度或副本中暗中代表兩個互不知情的個體。

7.2 G08-02｜必要事件不得消失

每一個到期或由規則觸發的必要世界事件必須被處理或具有合法延後／取消記錄；測試統計 required, committed, pending, cancelled, failed 五種互斥、完整的命運。

7.3 G08-03｜期限和 clock domain

模擬時鐘、單調牆鐘及外部輸入順序須有各自來源；不得把遊戲暫停當作系統時鐘停止，也不得把模擬時間快轉視為所有外部截止期限可跳過。

7.4 G08-04｜訂閱屏障

當工作檢查 guard 與建立訂閱之間恰好發生提交，仍不得漏掉必要喚醒。此測試須有能控制執行順序的 adversarial scheduler 或同步障礙夾具。

7.5 G08-05｜負向查詢與動態依賴

例如「市場沒有存貨」及「沒有鄰近敵人」在上游狀態變化後，也能重新求值；不能只訂閱一個當下存在的正向引用。

7.6 G08-06｜候選與唯一提交

多個 CPU／GPU candidate 可生成，但每個符合規則的世界 mutation 只能經唯一 Commit Gate；不合時、過時或已遭取消的候選必須拒絕。

7.7 G08-07｜重複工作冪等性

重試、裝置復原、存檔重載不可以重複支付獎勵、重複生產商品、重複扣款或重複消費相同事件；對非冪等外部副作用需使用明示的 outbox 或提交記錄。

7.8 G08-08｜跨尺度身份

由微觀移至中觀或宏觀，須保留已聲明不可遺失的具名人物與唯一物件；從摘要回到微觀不得生成第二個同一身份。

7.9 G08-09｜流量及資產帳本

貨物、人口、財產與資源轉移使用一致的單位、邊界、時間與來源證據。允許明確的生產、消費、出生、死亡、損耗，但不得因 scale transition 產生未說明的新增或消失。

7.10 G08-10｜Scale Transition Certificate

每次尺度切換應記錄聚合來源、精度、條件細化政策、不可逆資訊責任及恢復界限。缺少必要憑證時必須拒絕切換或退回較精細模型。

7.11 G08-11｜Temporal Cut

不同子域以不同速度推進時，提交的共同觀測切面不可讀取尚未合法產生的未來事件，也不可用尚未完成的 GPU 世界資料作為已提交結果。

7.12 G08-12｜內容有效性與駐留分離

RAM／VRAM buffer 是否存在、是否 pinned、是否由 CPU／GPU 可見，不是內容仍有效或有世界寫入權的充分證據；每個可重用副本都需要 StateRef、generation 與依賴有效性。

7.13 G08-13｜安全回收

有未完成 GPU 使用、無法恢復的唯一世界資料、尚未提交的持久化義務或仍被借用的內容，不得在沒有正確替代機制下被回收。

7.14 G08-14｜GPU queue / fence

GPU dispatch、kernel 完成、可供 CPU readback、可供其他 queue 消費、世界提交是不同階段；要逐階段留下完成證據。GPU buffer generation 不得被 ABA 式重新使用而冒充同一版本。

7.15 G08-15｜數值與隨機語義

浮點近似須遵守精度契約；若規則要求整數守恆，不能拿浮點總量近似替代。使用隨機核則明示可再現 seed、流分割及統計檢驗規則。

7.16 G08-16｜路由可行性

路由被選擇前須通過 capability、Guard、資料可達性、精度、期限、資源上限、設備權限和可恢復性；不可先選最快裝置，再事後忽略違規。

7.17 G08-17｜預測不授權變更世界

因果前沿或 predictive preloading 可以暖化 buffer、準備 kernel，但不能把尚未發生的事件當作已提交現實。

7.18 G08-18｜存讀檔完整性

保存必須包含足以恢復的 canonical world、rule/schema、event journal、未完成期限、訂閱版本和尺度資訊；讀檔後應可重播而不是只恢復畫面。

7.19 G08-19｜MOD 熱更新隔離

規則修訂改變時，不能悄悄沿用以舊規則生成的候選、快取或預計算；轉換、失效或拒絕各有明確記錄。

7.20 G08-20｜引擎畫面不是 world authority

Godot／EveWorld 的 UI、動畫和視覺效果可呈現世界結果，但不能直接繞過 CWSR 的權威提交來修改遊戲規則狀態；除非適配接口正式將某事件映射為合法世界輸入。

7.21 G08-21｜失敗時的狀態完整性

設備中斷、allocator 拒絕、寫入競態或規則衝突時，舊版本世界仍可有效讀取，且有可追蹤的 fallback 或停止證據。

7.22 G08-22｜不可觀測成功不能替代必須的事實

某內部更新雖沒有立即可見結果，只要會影響已聲明的未來任務、存讀檔、歷史或期限，就不能被視為可永久刪除的無效工作。

7.23 優先判決表

8. 可觀測等價的三套測試制度

8.1 Exact Trace Suite

適用範圍是可列舉、決定性、具有唯一事件排序的工作，如貨幣總量、任務完成、角色身份、存檔版本、工作 ID、物品所有權。對給定 canonical ordering 的事件軌跡：

可作為強檢查，但不能代替原始 trace diff；若兩個合法實現允許不同獨立事件順序，須先定義偏序正規化，而不是將不同序列一律視為錯誤。

8.2 Approximation Suite

對連續物理／群體模型，先定義有物理量綱的誤差，例如：

其中 $s_i$ 是預先註冊的非零尺度，不是用觀測後的最大值任意放寬。對守恆量另設絕對或相對剩餘量；不能把可容忍位置誤差轉用來豁免資產遺失。

8.3 Probabilistic Suite

對隨機過程，重播與統計是兩個獨立要求：同一 RNG stream 的 deterministic replay 測流程，獨立 seeds 的多次結果測分布。統計比較可選 empirical CDF、事件率、均值、變異、分位數或分布距離，但測試的顯著性、樣本量、容忍差距和多重比較處理要先規定。

8.4 近似等價不等於同一故事

NPC 在兩個合法隨機模擬中可能採取不同次要行動，若世界設計允許則未必錯誤；反之，具名 NPC 已完成過的重要任務、不可逆事件或玩家持有資產，不能被「總體統計接近」抵銷。

8.5 跨尺度查詢階梯

觀察量至少區分：

1. 全球／宏觀統計：人口總量、貨品總額、降雨、區域產量。
2. 地方／中觀統計：城市物流、價格、職業分布、區域疾病率。
3. 具名／微觀查詢：角色身份、財產、關係、可見動作、任務履歷。
4. 時間因果查詢：事件發生之前後、交易憑證、來源流與期限履行。

每個尺度的檢查不能互相替代。

8.6 精度隨機率調整的公平問題

若 CWSR 動態提高近似程度，B0–B4 也應有相同可用的合法精度政策，或將 CWSR 的「較低精度」明確列入品質—成本 Pareto 取捨。禁止拿低精度 CWSR 比高精度基線卻直接宣稱純速度勝利。

9. 效能指標：從單次 kernel 到整個遊戲

9.1 工作端到端延遲

對必要世界更新 $q$，量測：事件具備資格開始，到權威世界提交為止的 latency；若允許合法待處理，其 deadline 與實際提交時間必須一併記錄。單獨的 kernel_ms 只是其中一項。

9.2 完整路徑成本分解

可將一條路徑的觀測成本拆成：

這是用於拆帳的概念式。真實 CPU/GPU 階段可能重疊，不能將所有重疊 wall-clock 項直接相加後誤稱實際端到端時間；以實測 span、critical path 和裝置時間戳分別報告。

9.3 模擬吞吐

分母應包含需要實際執行的準備與提交成本。若更少事件源於規則被省略，而非合法聚合，則該結果不能當成更高吞吐。

9.4 Frame Time 分布

以完整 frame time 的 p50、p90、p95、p99、p99.9（若樣本足夠）呈現。把 FPS 換算為 frame time 後再評估尾端；不要對 FPS 平均值和 frame time 平均值進行不具一致意義的直接排名。

9.5 Frame Deadline

對顯示更新設定可查證的 budget，例如 60 Hz 對應約 16.67 ms 只是常見範例。若使用 V-Sync、VRR 或不同顯示目標，應用當次實際設定的預註冊 frame deadline；不可任意挑目標來產生勝利。

9.6 CPU 工作與管理開銷

分開量測 gameplay computation、dirty checking、dependency indexing、ticket processing、route planning、cache handling、commit verification、engine adapter、render thread。理想是可把「真正節省的運算」與「新增加的治理」分開。

9.7 GPU 佇列／運算／渲染

至少區分 GPU kernel time、queue waiting、device synchronization、CPU readback、graphics queue competition 和 GPU idle；可在支援環境用 timestamp queries 或其他實機 profiler。部分硬體沒有獨立並行 compute queue，不能假設同樣 API 就能得到同樣並行效果。

9.8 RAM 峰值與駐留

記錄 process committed bytes、working set 或平台可核對的記憶體指標、allocator-reserved bytes、當前有效世界資料量和臨時 staging；不得只挑其中最低值宣稱記憶體收益。

9.9 VRAM 峰值與 headroom

至少分開 GPU buffer／texture 由 CWSR 跟蹤的預算、圖形基準佔用、裝置報告的 budget／usage、暫存／duplicate 及 in-flight bytes。跨 API 或不同 GPU 驅動回報不可直接當成完全可比的物理量。

9.10 資料搬移與同步

報 host-to-device、device-to-host、device-to-device 傳輸量，提交次數、batch 大小、barrier 次數、fence wait 及 buffer generation churn。若有資料常駐收益，須顯示傳輸減少，而非只從 GPU 利用率猜測。

9.11 路由治理

記錄 route candidate 數、HardGate 拒絕率、Planner 時間、Form annotation 時間、重新路由次數、遲滯被觸發的次數、policy rollback 和 plan regret。若分類特徵花的時間高於其節省，就不能宣稱淨收益。

9.12 能源與功耗

若設備可提供可信的 CPU package、GPU board 等功率或能源資料，可在同一 session 報告耗電；否則標為 unavailable，不得把 GPU TDP 或平台廣告值當成實測能耗。不同設備傳感器的可比性需要額外校準。

9.13 故障及恢復成本

測 device loss、OOM／VRAM budget fail、validation error、存讀檔恢復的恢復時間、丟失候選數、重試量和第一個成功提交的時間。正常運行期速度無法抵銷世界損毀。

9.14 使用者體感與規則層體驗分開

Frame pacing、輸入回應、載入卡頓和可見世界一致性是玩家體感相關指標；世界背景事件吞吐、經濟結算與 NPC 履約是規則層指標。可同時優化，不可只選其一就稱遊戲整體更好。

9.15 建議最小結果欄位

10. 主假說的損益平衡與增量分析

10.1 全量掃描與事件治理

令 $C_{full}$ 為成熟全量更新成本， $C_{ev}$ 為必要事件實際計算， $C_{idx}$ 為訂閱和依賴索引成本， $C_{wake}$ 為工作喚醒與驗證成本。僅在同等正確性下：

才有該 workload 的成本優勢。若使用數值近似，還須加入精度政策與品質成本。

10.2 CPU／GPU 端到端交叉點

令 $C_{cpu}(n)$ 為已最佳化的 CPU 全路徑成本， $C_{gpu}(n)$ 為包括 staging、dispatch、同步與必要 readback 的 GPU 全路徑成本。GPU 在該規模上的淨收益條件是：

這不是聲稱存在唯一交叉點；渲染負載、VRAM 熱度、batch size、clock／溫度可能使區域不連續或有多個交叉。

10.3 配置路徑的完整效益

設同一 fixture 與硬體上的已通過正確性候選為 $B_i$，定義時間成本比較：

當 $G_{i\to j}>0$ 才表示此時間指標有下降，但不能推出其他指標也改善。若 $T_i=0$ 或結果不具比較性，此量不可使用。

10.4 B4 對 B5 才是形態分類的貢獻

在相同路由後端、HardGate、tuning budget 和資料條件下：

若 $\Delta_{form}$ 不足以抵銷分類與維護成本，或置信區間不排除實務上重要的負面值，便不能宣稱 24／72 在該工作域改善性能。

10.5 B5 對 B6 是遲滯與重規劃增量

必須同時報 route churn、missed deadline 和 quality regression；較少切換若由過久維持劣路徑換來，可能沒有淨效益。

10.6 多目標成本不能強制壓成 FPS

對路由 $r$ 報告結果向量：

若兩路由在某些目標互有優劣，應列為 Pareto trade-off；只有預註冊硬約束通過後，才能依公開權重或優先序產生單一選擇。

10.7 「更大世界」的成本歸因

若 CWSR 在固定幀時間和記憶體預算下支援更多邏輯世界單元，必須同時提供：活動工作數、有效世界內容、模擬精度、可查詢歷史及未履行義務。純粹增加沒有任何狀態責任的裝飾 ID，不構成更大的動態世界。

11. 實驗預註冊與資料收集順序

11.1 預註冊的最小內容

正式測試前，鎖定世界 fixture 版本、run plan、硬體條件、metric definitions、等價門檻、主要比較、主要成功指標、負面結果處置與排除規則。測試中更改方案須版本化並標記 exploratory，不可事後悄悄取代原方案。

11.2 功能測試先於效能測試

測試順序：

1. 編譯與基本自動測試；
2. 單一事件及版本提交；
3. 十分微小的跨尺度或 GPU smoke test；
4. 可重播的 correctness/regression suite；
5. 強基線功能等價驗收；
6. 測量儀器校準；
7. 有限批次 paired benchmarks；
8. stress and soak；
9. 第二硬體環境與獨立重播。

如第 4 步失敗，後續速度資料只能作為診斷，不得列成合格速度勝利。

11.3 Fixture seed 和輸入隔離

世界初態 seed、RNG streams、玩家輸入 trace、MOD 操作及擾動排程，必須在 B0–B7 之間固定或做正式可比較配對。不能讓 B5 的 AI／planner 額外得知測試的未來事件。

11.4 Warm-up / Cold-run 分開

首次 shader compile、Rust 啟動、資源解析與 cache build 屬 cold-run；hot steady state 需預定 warm-up 完成條件。若正式產品需要承擔冷啟動，則 cold-run 不能完全從報告消失。

11.5 反覆測試與隨機交錯

執行 run 的順序應以 seed 和硬體環境為 block，隨機交錯 B0–B6，降低溫度、背景負載和驅動狀態所造成的順序偏差。此原則可參考 Google Benchmark 的 repeated trials 和 random interleaving；但其微基準工具不直接取代本研究的完整遊戲測量。

11.6 重複次數的規則

可先做 pilot estimation，再根據效果變異、可接受最小效果和硬體成本決定正式 run 數。正式 run 次數必須預註冊；「每種方案至少數次」只能當探索，不能取代變異與可信區間分析。

11.7 視窗與 tick 的配對

比較不應因某個版本自然執行更快就觀察更少世界時間。至少採兩種設計：固定 world-time window 比較完成該世界責任的 wall time，以及固定 wall-time budget 比較合法已提交工作量，兩者不能混成一個結論。

11.8 裝置溫度、clock 和功耗

同一硬體測試記錄 GPU／CPU clock state、temperature、power limit、thermal throttle 及電源模式（可測時）。若出現明顯 throttling，須先按預先定義的排除規則處置，不得只排除 CWSR 失利的 run。

11.9 作業系統背景程序

更新程序、其他 GPU 應用、瀏覽器視訊、編譯進程、驅動重設、掃毒／索引等可干擾結果。測量期間應記錄主要負載，並以相同穩定性條件對所有基線進行實驗。

11.10 Profiler 擾動

追蹤工具、GPU Timestamp、詳細事件日誌本身會產生額外成本。至少量測 instrumented 與 minimal instrumentation 兩種模式，評估量測帶來的相對 overhead；關閉記錄不能關閉正確性所需世界日誌。

11.11 實機可跑與不支援要分開報告

如某 GPU 不支援需要的 compute features，B3/B5 的相應路徑標為 UNSUPPORTED。不能把未能運行的樣本填成零時間，也不能用高階設備結果代替其他設備。

11.12 CWSR 的單機定義

本系列首輪使用單機消費級硬體，不依賴遠端雲端推論或租用專用 GPU cluster 才能達成實驗結果。若未來跨機版可以更快，應另列超出首輪論域的擴展試驗。

12. 資料、版本、時間戳與重現性 Schema

12.1 機器可讀文件一覽

這些是預期工程交付結構，不是聲稱當前存在的測試結果。實際產物應由實作系統生成並附 SHA-256，避免使用者只能從聊天畫面複製表格。

12.2 Run Manifest 範例

下面的 JSON 是可解析的格式示意資料，所有執行結果特意保持 NOT_RUN／null：

{
  "schema": "cwsr.benchmark.run.v0.1",
  "series": "CWSR",
  "paper": "08",
  "run_id": "placeholder-run-id",
  "evidence_state": "NOT_RUN",
  "fixture_id": "bridge_trade_003",
  "fixture_sha256": null,
  "rule_revision": "fixture-rule-v0.1",
  "schema_revision": "fixture-state-v0.1",
  "input_trace_sha256": null,
  "baseline": "B4",
  "backend": "CPU_OR_GPU_AFTER_CAPABILITY_CHECK",
  "seed": 12345,
  "cold_or_warm": "warm",
  "world_time_start": 0,
  "world_time_end": 86400,
  "hardware": {
    "cpu_model": null,
    "logical_cores": null,
    "installed_ram_bytes": null,
    "gpu_model": null,
    "gpu_vram_bytes": null,
    "os_build": null,
    "gpu_driver": null,
    "graphics_api": null
  },
  "toolchain": {
    "source_commit": null,
    "rustc_version": null,
    "shader_sha256": null,
    "build_profile": "release"
  },
  "limits": {
    "ram_budget_bytes": null,
    "vram_budget_bytes": null,
    "world_deadline_ms": null,
    "frame_target_ms": null
  },
  "results": {
    "conformance": "NOT_RUN",
    "valid_commits": null,
    "required_obligations": null,
    "hard_deadline_misses": null,
    "wall_ms": null,
    "frame_ms_p99": null,
    "world_latency_ms_p99": null,
    "ram_peak_bytes": null,
    "vram_peak_bytes": null
  }
}

12.3 事件與候選 ID 的可追溯性

對每一必要義務 obligation_id，記錄其唯一生成原因、來源 world revision、guard、依賴版本、deadline、允許延後政策及最後命運。對候選還應記錄 route_id、backend_id、generation、candidate_hash 與 commit_receipt。

12.4 Timestamp 不只一個時鐘

wall_monotonic_ns、world_tick、sim_time、gpu_timestamp_ticks 應分開存放。GPU timestamp 需保存 timebase 校準資訊與讀取方式；GPU 佇列事件與 CPU event 的順序不可只靠各自數值直接排序。

12.5 Event Journal 的最小欄位

{
  "schema": "cwsr.obligation.v0.1",
  "obligation_id": "o-0000001",
  "event_source": "bridge_collapse",
  "world_id": "fixture-world",
  "world_revision": 42,
  "rule_revision": "fixture-rule-v0.1",
  "world_time": 1337,
  "required_by_tick": 1340,
  "state": "PENDING",
  "resolved_by_commit": null,
  "cancellation_evidence": null,
  "failure_evidence": null
}

12.6 累積統計不是單筆資料

p99、mean、standard error、confidence interval 不可寫到單筆事件欄位當作原始量測。原始 duration_ns 要保留，統計摘要應由分析腳本從 trace／sample 產生；若有抽樣，須註明抽樣率和丟棄事件。

12.7 內容來源與 hashes

每個 fixture、規則文件、shader、Rust 原始碼、執行檔、輸入 trace 及報表都應有內容 digest，連接 source revision 與 benchmark run。為保障第三方重播，保存完整 source commit 並避免依賴 Git 工作樹中的未記錄修改。

12.8 隱私和商業素材邊界

遊戲存檔、內部 MOD、真實玩家行為或未公開商業素材不能因 benchmark 自動外洩。公開重現包應使用合成 fixture、最小化必要資料和合法授權；私有原始碼可以提供受限審核，但若第三方無法重播，必須降低可重現性主張。

12.9 不可使用假零值代替缺測

GPU 不支援、未量測、儀器失敗與真實零值有不同語義。未測資料用 null 加 NOT_MEASURED／UNSUPPORTED／INSTRUMENTATION_FAILED；禁止填 0.0 ms 造成虛假加速。

12.10 世界操作失敗需保留成本

即使 candidate 被拒絕，已花費的 CPU／GPU 時間、VRAM staging 或計算能耗仍是 route 經濟的一部分。成功 throughput 不計入，但 overall resource cost 必須包含。

13. 統計方案：避免一張圖變成萬用結論

13.1 主要比較先預註冊

每個 workload 選擇一個主要性能結果及必要 correctness/QoS guardrails。譬如 W08-04 可選「相同世界時間內每秒合法更新量」，W08-10 可選「p99 frame time + world deadline 不違約」。各工作負載可有不同 primary endpoint，但不能看到結果後才換成對 CWSR 最有利的指標。

13.2 Paired Block 設計

同一硬體、同一 fixture、同一 seed 及同一外部條件構成配對 block；在 block 內執行各 baseline。當一次 run 內含數千影格，它們不是數千個完全獨立實驗，不能直接把每幀當成獨立樣本給出虛假狹窄的信賴區間。

13.3 主速度效果尺度

對每個配對 run 可使用 log ratio：

當 $Z_k>0$，表示在該 run 下 B5 於該時間指標較快；但只有跨獨立 block 的估計與不確定性足夠，才可做一般化推論。若測試項不是越小越好，須使用相反定義，不能混用。

13.4 Confidence Interval 與效應量

建議對配對 block 做 bootstrap 或適當的階層模型，以估計 median／mean log-ratio 或其他預註冊效果及區間。重新抽樣單位是 seed-run／硬體 block，不是任意分散的單幀；若有時間序列相關性，可使用 block bootstrap 或其他時間相關方法。

13.5 預註冊最小值得改善幅度

定義 practical improvement threshold $\delta_{min}$，例如「p99 frame time 改善至少若干百分比且 deadline 不惡化」。具體百分比應於 pilot 和遊戲需求評估後固定；本稿不憑空指定一個適用全裝置、全遊戲的成功百分比。

13.6 等效與非劣性

若目標是用較低 RAM 實現與 B2 不差的 frame time，應以事前規定的非劣性界限檢驗 frame latency，再比較記憶體；不能因未達顯著差異便斷言兩者相等。若要聲稱「無差異」，需要足夠測試力或等效性方法支持。

13.7 負面結果的類型

「B5 明顯落後 B4」是劣勢證據；「區間跨越實務上有益和有害的範圍」是證據不足；「區間完全落在事前定義的無關緊要範圍」才支持無實務增量。三者不能混稱失敗或成功。

13.8 多重比較

B0–B6、十二工作負載、多硬體和數十指標會產生大量比較。主要假說應固定少數預註冊比較；其餘明示探索性並採合適的多重比較控制或審慎報告，避免挑選極少數偶然有利的測試結果。

13.9 Tail Latency 的獨特風險

p99 對長測試與罕見 event 很敏感。必須報 sample count、measurement window、frame pacing method、超過截止期限的絕對事件數；少量短測試的 p99 不應用來保證正式產品的尾端穩定性。

13.10 誤差、精度和速度的聯合結論

若一組方法更快但處於觀察誤差邊界內，結論應是「在指定精度政策下成本較低」；不能推廣成「任何精度都更快」。若某近似導致新的一類遊戲決策錯誤，應重新界定等價類而不是放寬所有容差。

13.11 缺測和退出

硬體 OOM、GPU crash、測試 timeout、driver lost、fixture invalid 必須保留 raw failure rows。若只分析完成 run，可能產生倖存者偏差。比較效能時需明示條件樣本與整體可行性兩張表。

13.12 分層外推

單一 GPU 的 B5 > B4 結果不自動推廣到全部顯示卡。跨硬體結論先按 backend、VRAM class、GPU 架構與 CPU 供應能力分層，再尋找可被設備能力解釋的共有適用域。

14. 消費級硬體與裝置能力分層

14.1 硬體層級的意義

本系列以「不必持續購買更昂貴電腦才有動態世界」為實務動機，但不能由此反向宣稱最低階 GPU 也能高效處理所有任務。硬體測試的責任是找出設備能力、資料規模、模型精度及執行路由之間的可行關係。

14.2 建議 Hardware Strata

實際測試須以具體型號、RAM/VRAM 和 API 支援為準；此表沒有宣稱已在上述五種設備實測。

14.3 裝置資料要完整

記錄 CPU 型號與核心配置、RAM 容量、通道／速度（可取得時）、GPU 型號、VRAM 容量、PCIe／共用記憶體拓撲、OS、driver、shader compiler、渲染 API、螢幕／輸出模式、電源和測試解析度。對 Windows／Linux 跨 OS 測試應記錄不同的排程及 GPU 驅動條件。

14.4 故意讓低階硬體失敗的測試要有限制

高壓 stress test 可以探測拒絕與恢復，但若已知超過系統硬限制，不能強迫設備 crash 才稱有驗證。正式驗證要看 Runtime 能否正確拒絕、節流、降合法精度或回退。

14.5 VRAM 使用率不是足夠指標

高 VRAM 使用率可能是有效的工作集，也可能造成 render 資源不足與 driver paging；低 VRAM 使用率可能降低佔用，但帶來更多 PCIe 傳輸。必須以時間、傳輸、版本重建及畫面指標一起判斷。

14.6 UMA／整合 GPU 情況

整合 GPU 不一定有與獨立顯卡相同的 H2D/D2H 成本，但共用記憶體頻寬、cache coherence 和 CPU/GPU 爭用仍可限制效能。不可把獨顯 PCIe 成本模型直接套用在 UMA。

14.7 安全使用 consumer GPU

本研究不需要製造超出電源限制或長時間無保護的硬體壓力；stress/run 應尊重裝置溫度、driver recovery、使用者保存中工作及正常操作規範。測試工具與遊戲可共用一台主機，但不得把其他任務被迫中止的資源損失當成免費成本。

15. Godot 與 EveWorld Engine 的引擎適配驗證

15.1 將 Host 和世界真值分開

引擎負責主執行緒事件、輸入、呈現、資產和圖形 API；CWSR Runtime 管理其獲授權的 world-state 更新與提交。兩者間必須有 typed event input、read-only snapshot／projection 和正式 world mutation proposal。

15.2 Headless 首先確立世界結果

先在無渲染的 host 或 Rust CLI 中跑相同 fixtures，保證世界規則與事件義務已正確。之後再加 Godot／EveWorld host，確認 adapter 不額外重放或漏送 input。

15.3 Renderer 啟動不是編譯器測試

Godot Scene 能載入、EveWorld 能顯示地圖、GPU shader 成功建立，都不是世界因果一致性的證據。必須做 state query、event journal 和 replay diff。

15.4 主執行緒界線

引擎 Node、UI、scene tree 等可能具有主線程約束。Adapter 應排程並可測量主執行緒安全回呼，不得直接從 Rust background worker 寫入需要主線程存取的物件。

15.5 Host-driven Tick

引擎可以定期通知 Runtime 執行時間／事件評估，但不應使每個世界實體必須每幀重算。對必須固定步進的物理系統，保留原引擎固定步進與必要子步證據。

15.6 Render Stress 設置

同一 camera path、相同 rendering resolution、V-Sync／VRR、材質、光照、draw calls 與場景內容在所有 B0–B6 之間固定。若 CWSR 只在更低畫質下勝出，屬品質—性能權衡而不是等價速度結果。

15.7 引擎 adapter 的副作用

若某 UI callback 同時向世界提交和直接改引擎內部數值，可能形成雙重 authority。驗證應刻意制造重複 callback、延遲 callback、resize、pause/resume 及 scene reload，確認世界只接受一次合法提交。

15.8 引擎整合完成分級

• E0：介面文件完成；
• E1：Native library 載入與 API smoke pass；
• E2：Headless world semantics replay pass；
• E3：Godot 或 EveWorld 一個 adapter conformance pass；
• E4：實際 GPU backend 與引擎共同運行 pass；
• E5：Render＋World 性能公平比較 pass；
• E6：長時間 save/load／MOD／故障恢復 pass。

目前 Paper 08 的文件完成不等於任何 E1–E6 已通過。

16. 故障注入、負面結果與恢復矩陣

16.1 Fault Injection 的最低要求

故障測試必須與正常速度跑分分開報告，並在每次故障後驗證 world history、未履行工作、設備租約和候選提交；不能用「遊戲沒有當機」代替完整恢復。

16.2 可注入性與真實故障不同

模擬 DeviceLost 可先測控制邏輯，但只有實機驅動事件能檢查完整 GPU 後端恢復。報告必須區分 synthetic fault pass 與真實裝置回復，不得以後者尚未執行而宣稱已完成。

16.3 故障結果欄位

每個 fault case 至少有 fault_id, injected_at, affected_state, candidate_count, canonical_revision_before, canonical_revision_after, pending_obligations, recovery_duration_ms, verdict, evidence_files。

16.4 故障後速度不是唯一關心事項

恢復時如果世界存檔被損毀，即使恢復時間非常短也不合格。相反地，安全保留世界但需要玩家等待，應將停頓作為 QoS 缺點真實報告，並探索合法的恢復加速。

17. 可證偽命題、預期反例與裁定矩陣

17.1 明確勝利也不是無條件通用

例如 B5 在 W08-04/HC2 比 B4 快，只能得出「在該類規整群體更新和硬體範圍、既定精度與負載下，FormAware 的加入具實測增益」。不能推成任意遊戲、所有 GPU、全部宏中微模型皆受益。

17.2 沒有收益仍可能保留 CWSR 的其他價值

若 24／72 註記對性能無幫助，但狀態版本、CommitGate 和恢復契約使系統更可審計，這是正確性與工程可維護性的候選價值。它仍須用錯誤檢出率、回歸風險與維護成本等相應指標建立證據，不能拿未測的維護價值替代既有失敗的速度假說。

17.3 強基線勝出應被視作有效結果

如果 B1／B2／B3 大部分時間已是更優方案，CWSR 可縮小為一組必要的 world contracts、測量器與選用的 backend adapter；不強迫保留高成本的全面路由層。

17.4 何時直接停止研究某個子方案

在清楚界定的 fixture 範圍，如果某子方案無法維持硬性語義、不具可恢復性、連續多輪公平測試均顯示無實務價值，便可標記 STOP 或 REVISE; 不必因系列已有九篇原稿而維持所有模組。

17.5 修正研究假說的程序

若出現強反例，將假說版本化：原假說仍保留於 v0.1，新增 v0.2 的適用域、反例解釋與改善設計；禁止回頭把 v0.1 改成永遠沒有做過較強主張的模樣。

18. 最終驗收：不能只以效能數字決定通過

18.1 驗收層級與其所需證據

18.2 A0／A1 與 A2–A8 不互相代替

正式 PDF、長篇 Markdown、工具生成測試計畫、可編輯 Rust 代碼都可能通過 A0／A1；若未跑真實 Rust／GPU／引擎，A2–A8 仍應保留 PENDING。不得在匯總圖上以一個「PASS」覆蓋其差異。

18.3 結論分為五種

• SUPPORTED-LOCAL： 在明確硬體、fixture、精度及世界規則下，正確性通過且實測支持預註冊性能改善。
• SUPPORTED-CONFORMANCE： 正確性或恢復契約通過，但尚未證明速度／記憶體收益。
• NEGATIVE： 在公平比較後，明確證據顯示該方案無實務收益或遭劣勢。
• INCONCLUSIVE： 樣本、能力、測試力或校準不足，不能判斷。
• INVALID： 世界語義錯誤、資料品質不達標、基線不公平或缺少必需來源。

其中 NEGATIVE 是合法研究成果，INVALID 則不能當成任何方向的強效能證據。

18.4 版本閉包條件

對每一新 benchmark version：鎖定 source hashes、預註冊方案、世界 fixture、工具鏈、儀器、原始執行結果和判決摘要。任何修訂都須保留舊版本及其不利資料；新一輪只用新的 version ID 與相應註解。

18.5 實務部署路由的准入條件

對實際玩家世界的 route admission 至少有三層門檻：

1. Semantic Safe： 規則、期限、版本、精度、身份與唯一提交通過。
2. Resource Feasible： RAM／VRAM、GPU 執行、渲染保留、可用硬體與恢復條件通過。
3. Worthwhile： 與成熟可用路徑相比，達到本遊戲預先定義的最小實務收益或符合其他優先目標。

即使第三項不成立，也不應迫使整個遊戲停止運作；可選成熟路由。第一或第二項不成立時，才必須拒絕不合法候選。

18.6 多目標決策示意

對某場景的 Pareto 候選，可以依預註冊優先序，例如：

1. 世界不可逆正確性；
2. 硬 Deadline、資源上限及玩家存檔安全；
3. 渲染 p99、輸入回應與玩家互動品質；
4. 世界模擬吞吐和額外可模擬規模；
5. 平均成本、能耗與長期運行穩定性。

上述是示意政策，不代表所有遊戲皆採同排序；若有不同優先級，須由遊戲設計和正式測試提前指定。

19. 分析、稽核與結論發布流程

19.1 原始 run 不可只保存勝利樣本

每一個原本計畫執行的 run 都應有紀錄，包括完成、被拒、設備不支援、儀器故障、OOM、超時及取消。從所有 run 到合格比較的排除路徑需要機器可讀原因。

19.2 分析腳本的獨立性

統計腳本只讀原始資料和預註冊配置，不應依 filename 裡的 B4/B5 直接套入預期結論。對照組可以在 primary analysis 中匿名標號，減少研究者偏差；解盲後保留原始分析輸出。

19.3 一次 benchmark 至少兩張主表

Conformance table： world correctness、deadlines、identity、ledger、commit、fault handling。
Performance table： 完整 latency、throughput、frame tail、memory、transfer、route overhead。

如果前者不通過，後者仍可作診斷資料，但不能編入合格性能勝利表。

19.4 需要可重現的主要圖表

推薦：有效變化密度 vs. end-to-end cost；工作集大小 vs. RAM／VRAM；GPU render pressure vs. frame p99；B4/B5 log-time ratio vs. workload；路由切換次數 vs. deadline misses；身份與資產 invariant violation counts；device-loss recovery distribution。

圖表必須由 script 從 raw evidence 產生，禁止在 Excel／圖形工具手工修改數據線條後只保存圖片。

19.5 凍結負面結果

失敗 case 可轉換為永久 regression fixture；修復後，舊版及新版都跑相同 case，並保留這次修復是否影響其他工作負載。不能修復一個高 profile case，卻取消另一個已知失利的條件。

19.6 宣傳與對外溝通邊界

即使未來某單一 benchmark 顯示 CWSR 提升吞吐，也應包含 hardware、rules、fixture、版本、樣本數、觀察誤差與基線類型，並附原始資料。不可只用「世界快了數倍」替代限定條件；若只有合成 benchmark，須標為 synthetic scenario。

19.7 排除規則的審計

研究可排除預先定義的 invalid runs，例如 fixture hash 不一致、OS 強制中斷、設備未支援 API。但不能因為某 run 特別慢、p99 spike 高或 CWSR 路由選錯，就認定為 outlier 並無證據刪除。

19.8 安全、公平與開放界線

內部研究結果可以先私有；若主張可獨立驗證，則至少需要可公開的合成 fixture、同義務測試規格、記錄和可執行 source 或公開兼容重實作。沒有公開資料的結果可呈現，但其可獨立再現程度應如實標示。

20. 具體工程交付次序：從 MVP 到研究結論

20.1 Milestone V0｜文件與 fixture 錨點

• Paper 00–08 source files 和 SHA-256 索引；
• Canonical rule/schema version；
• 三個最小固定 fixture：稀疏 NPC、橋樑物流、群體數值；
• B0 CPU 參考世界；
• Trace Schema 及基準 CLI 契約；
• 可執行能力與驗收狀態分離。

完成證據： 文件 hash、fixture source、可解析 metadata；尚不稱性能改善。

20.2 Milestone V1｜Rust CPU 語義驗證

先將 Paper 07 的 Rust 候選原始碼輸入可編譯 repo，補足事件時間、ID、world snapshot 和 Commit Gate 測試，取得真正的 cargo 輸出。至少通過 duplicate、stale、rule change、deadline 和 replay，才進下一步。

完成證據： cargo fmt --check、cargo check、cargo test、source commit、精確 pass count。實際未執行前，不可填入測試通過數字。

20.3 Milestone V2｜B1/B2 強 CPU 基線

建立成熟 ECS／SIMD 或 cache-friendly CPU 基線及完整事件／Dirty Flag／Deadline 基線。先做到公平的 CPU 對照，找出稀疏更新是否真的具有超越管理成本的有效區域。

完成證據： B0/B1/B2 的 correctness、相同 trace、perf counters 及初步交叉點。

20.4 Milestone V3｜第一個真實 GPU 工作負載

只接一種規整數值 kernel，例如簡單人口需求或天氣網格。明確量測 upload、queue wait、kernel、download 或 GPU 常駐消費、fence、candidate verify 和 commit，產生 B3 與 CPU 完整路徑比較。

完成證據： shader hash、driver、設備、同步時間、數值精度結果及性能表。

20.5 Milestone V4｜B4/B5/B6 增量比較

先讓 B4 完全不使用 24／72 形態也能合法選擇 CPU／GPU，再加入 B5 FormAware，最後加入 B6 hysteresis。確保三組共享同一 HardGate 和預測資訊；對分類特徵做註記與消融。

完成證據： 能回答「形態是否真的提供獨立訊息」及「遲滯是否真的減少完整成本」的 paired experiments。

20.6 Milestone V5｜尺度、VRAM 與多種類負載

加入橋樑物流、角色身份、跨尺度時間、VRAM 限制、MOD update、save/load、render pressure。讓 CWSR 經歷其理論最可能出錯的情境，而不只是測最佳的純數值內圈。

完成證據： 擴大 G08 invariant 測試、B0–B7、負面結果及保守 fallback 效果。

20.7 Milestone V6｜引擎與長時間穩定

實際與 Godot／EveWorld adapter 互動，進行至少一個完整遊戲式場景、重複進出場景、反覆存檔、裝置或視窗更新、長時間運行和事件歷史重播。能夠在遊戲畫面中正確呈現 canonical 世界不等於仍需要逐幀跑全部世界。

完成證據： build/run、adapter logs、render timeline、world replay、soak test。

20.8 Milestone V7｜跨硬體與第三方審核

固定基準版本，在至少另一組顯著不同的硬體上重播主要結論。若原先的 GPU 優勢消失或逆轉，應把路由政策修正為硬體依賴，而不是保持通用主張。

完成證據： 外部或獨立環境的版本、配置、原始 run 與誤差報告。

20.9 是否要建立新 GitHub 儲存庫

本篇不要求立即新開 Repo，也不要求改造既有 EveWorld Engine 的主分支。可以先以獨立 benchmark harness、Rust workspace 和只讀 Godot／EveWorld adapter staging 驗證；待權威提交與數值正確性通過後再決定實際整合位置。這是工程建議，非已執行的 GitHub 操作。

21. 原始文獻、成熟技術與研究可追溯性

21.1 本系列 Canonical UTF-8 原始稿

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。
7. Neo.K × Aletheia，CWSR Paper 06｜24／72 計算範式的世界狀態自適應路由，v0.1，2026-10-16。CWSR_Paper06_24_72_Adaptive_World_State_Computation_Routing_v0.1_2026-10-16.md。
8. Neo.K × Aletheia，CWSR Paper 07｜CWSR Runtime：遊戲引擎整合與參考實作，v0.1，2026-10-16。CWSR_Paper07_Runtime_Engine_Integration_and_Reference_Implementation_v0.1_2026-10-16.md。
9. Neo.K × Aletheia，CWSR Paper 08｜可證偽驗證與開放世界效能基準，v0.1，2026-10-16。本文件。

21.2 直接繼承的 EveMissLab 研究

1. Neo.K，《計算的二十四重範式》，正式版候選 v4.0，2026-07-19。計算的二十四重範式_正式版_v4.0.md。
2. Neo.K × Aletheia，《從二十四重計算形態學到七十二格計算動力學》，v0.1，2026-07-19。從二十四重計算形態學到七十二格計算動力學_v0.1.md。
3. Neo.K × Aletheia，《全域計算方法論》，v0.1，2026-08-23。01_全域計算方法論_異質計算的全域一致組合_v0.1.md。
4. Neo.K × Aletheia，GCCF 04，《全域可尋址狀態與選擇性物化》，v0.1，2026-09-22。GCCF_04_Globally_Addressable_State_and_Selective_Materialization_v0.1_zh-TW.md。
5. Neo.K × Aletheia，GCCF 05，《因果流計算與預記載》，v0.1，2026-09-22。GCCF_05_Causal_Flow_and_Predictive_Preloading_v0.1_zh-TW.md。
6. 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。
7. Neo.K × Aletheia，GCCFT，《從有序計算到全域耦合計算》統合母論文，v0.1，2026-09-22。Global_Coupled_Computation_Integration_Mother_Paper_v0.1_2026-09-22.md。
8. Neo.K × Aletheia，GCCWT Paper 04，《計算場與資源激發》，Draft v0.2。GCCWT_Paper04_Draft_v0.2.md。
9. Neo.K × Aletheia，GCCWT Paper 06，《World Computation Planner》，Draft v0.2。GCCWT_Paper06_Draft_v0.2.md。
10. EveMissLab，GCM Phase B，《Deterministic Compute Allocator 技術白皮書》，v0.1，2026-08-27。GCM Phase B：Deterministic Compute Allocator 技術白皮書 v0.1.md。

上述文件提供 CWSR 的研究來由與概念邊界；它們不是 Paper 08 已通過實驗的性能證據，也不等於全部已接受獨立同行審查。

21.3 已查核的外部工程與再現性參考

1. Google Benchmark — User Guide，含 repeated benchmark、warm-up、計數器、JSON／CSV 輸出及 random interleaving。https://github.com/google/benchmark/blob/main/docs/user_guide.md 。本篇採其微基準方法學為參考，不宣稱其工具足以測量整個遊戲世界。
2. Godot Engine — CPU Optimization（stable），說明 profiler、瓶頸分析及 profiling 本身造成的額外成本。https://docs.godotengine.org/en/stable/tutorials/performance/cpu_optimization.html 。
3. Khronos Vulkan Guide — Synchronization，對 CPU／GPU／queue synchronization 及錯誤同步風險的工程背景。https://github.com/KhronosGroup/Vulkan-Guide/blob/main/chapters/synchronization.adoc 。
4. Khronos Vulkan Samples — Timestamp Queries，對 device command timing 和 GPU profiling 的可實作參考。https://docs.vulkan.org/samples/latest/samples/api/timestamp_queries/README.html 。
5. NVIDIA Nsight Graphics — GPU Trace Overview，對 GPU timeline、unit utilization、跨 queue 同步與 GPU workload 的觀測背景。https://docs.nvidia.com/nsight-graphics/UserGuide/gpu-trace-overview.html 。
6. ACM — Artifact Review and Badging，關於 artifacts available、functional、reproducible／replicable evidence 的正式界線。https://prod-www.acm.bloomreach.cloud/publications/policies/artifact-review-and-badging-current 。

上列網址為 2026-10-16 研究時查核的官方／原始來源入口；不同 Godot、GPU API 和 profiler 版本仍需在真正執行時重新核對。公開投稿前應依期刊／會議格式補上固定版本、作者、存取日期與必要 DOI，且不冒稱存在尚未查得的學術實驗結果。

21.4 成熟研究領域不歸為 CWSR 原創

Event loop、Dirty Flag、Incremental Computation、ECS、Data-Oriented Design、Simulation LOD、Adaptive Mesh Refinement、DEVS、GPU Compute、Vulkan synchronization、CPU profiling、Statistical Benchmarking、Conformance Testing 和 Artifact Reproducibility 均已有既有研究與工程實作。本系列的可檢驗增量只在特定單機世界狀態合約的系統化結合及可能的實測收益；不把既有工具或概念改名後宣稱發明。

22. 系列總結：讓理論接受世界執行的裁判

22.1 回到最初問題

遊戲畫面不變，程式可以持續運行；程式持續運行，不代表每一項工作皆必要。CWSR 的核心提問從來不是把所有計算停止，而是能否更清楚地說明一個世界狀態何時存在、何時有效、何時必須被改變、何時可以保留結果、何時需要搬移資料，以及 CPU 或 GPU 應該實際做哪一段工作。

22.2 回到世界尺度

宏觀、中觀與微觀是世界描述與因果作用的相對尺度，不是 CPU、GPU 或 VRAM 三個固定分工區。世界可以在不同尺度演化，但每一次尺度轉換、事件結算和權威提交都須保留玩家與規則真正關心的身份、時間及歷史。

22.3 回到記憶體與資源

邏輯世界很大，不要求它的全部資訊永久處於相同實體駐留形態。然而資訊不因回收而神奇地消失又可免費恢復：需要可尋址性、有效性、來源、重建或持久化憑據，以及按資源預算執行的回復政策。

22.4 回到 GPU 不是只會畫畫

消費級 GPU 可以承擔大量世界狀態數值工作；但凡涉及資料準備、搬移、同步、數值精度與渲染資源競爭，都需要端到端測量。GPU 是候選計算執行者，不是任何任務都一定更快的魔法硬體。

22.5 回到 Computation 24／72

24／72 的重要性在於描述並組織可能的計算形態，而不是替遊戲選定必勝硬體。只有在公平的 FormBlind 對照下，FormAware 仍有額外可量測收益，才能把某些效能增量歸給分類及其路由用途；否則，分類仍可作為描述語法，卻不可被包裝成效能結果。

22.6 最終的科學責任

本研究應允許下列各種結果同時成立：

• CWSR 在一種稀疏世界經濟負載下改善成本；
• 在高密度物理更新中，傳統固定 CPU 迴圈更適合；
• 在 GPU 渲染飽和的機器上，CPU 路由更穩定；
• 有些多尺度切換因身份或精度風險而根本不准執行；
• 24／72 只提供可閱讀路由標籤，沒有額外速度優勢；
• 某些硬體或遊戲專案不值得部署完整 CWSR Runtime。

若結果如此，CWSR 不應因面對負面結論而失去研究意義。它的價值取決於是否能清楚界定何時應算、何時可不算、何時可以改變計算方法，以及何時不能犧牲世界正確性。

22.7 第一輪系列閉合聲明

CWSR Paper 00–08 共九篇研究文件的第一輪理論與工程方法論編寫，在本篇完成。

這是一個可驗證設計的文件閉環，不是產品驗收、GPU 效能證明或所有假說已通過實驗的閉環。後續可以由實機工程、第三方測試、反例發現與必要版本修訂繼續推進，但不需要因為仍有工作未測就自動增加 Paper 09、10 或重新創造一套母理論。

Appendix A｜前七篇主責任與本篇測試對照

Appendix B｜正式報告模板（未執行版）

Appendix C｜最小 CLI 測試契約草案

以下指令是未來實作應提供的命令介面草案，不是聲稱目前專案已有這些命令：

# Step 1: 編譯與功能門檻。實作後才可執行。
cargo fmt --all -- --check
cargo check --all-targets --all-features
cargo test --all-targets --all-features

# Step 2: 命令名稱需由未來 harness 定義；以下是規格示意。
# cwsr-bench fixtures validate --manifest fixtures/manifest.json
# cwsr-bench correctness --fixture bridge_trade_003 --baseline B0
# cwsr-bench matrix --fixture bridge_trade_003 --baselines B0,B1,B2,B3,B4,B5,B6
# cwsr-bench replay --run-id <run-id> --verify-commits
# cwsr-bench analyze --plan plans/p08-v0.1.json --out results/

若未來使用不同 crate 或 CLI 名稱，須在實作版 README 給出一份真正可複製執行的 script。提供命令草案本身不構成 A2 Build PASS。

Appendix D｜最小 Falsification Report（純文本）

CWSR Paper 08 — Evidence Record
Protocol revision: v0.1
Runtime revision: NOT_ASSIGNED
Fixture digest: NOT_ASSIGNED
Baseline pair: NOT_RUN
Correctness outcome: NOT_RUN
Deadline outcome: NOT_RUN
World-state equivalence: NOT_RUN
Performance effect: NOT_MEASURED
Effect uncertainty: NOT_ESTIMATED
Hardware reproducibility: NOT_TESTED
Independent replication: NOT_TESTED
Negative cases: NONE_RECORDED_YET
Final claim: SPECIFICATION_ONLY

此模板必須一直保留其證據狀態的真實性。當首輪實測完成後，應建立新 report／revision 並附原始資料，而不是在原始 v0.1 Markdown 內直接填入未經檢查的效能百分比。

CWSR Series 00–08 — First-Round Research Source Closure.
Paper 08 v0.1 Status：Benchmark protocol complete; runtime conformance and performance experiments pending.