title

CWSR Paper 04｜動靜態記憶體契約與選擇性物化

english_title

Dynamic–Static Memory Contracts and Selective Materialization: Bounded Residency, Causal Validity, and Recoverable World State

series

CWSR — Causal World-State Runtime

paper

04 / 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 03 v0.1

next_paper

CWSR Paper 05 — CPU／GPU 異質世界計算與因果小流

CWSR Paper 04｜動靜態記憶體契約與選擇性物化

從預宣告資源區、所有權與生命週期到世界狀態 RAM／VRAM 駐留、回收及可驗證恢復

English: Dynamic–Static Memory Contracts and Selective Materialization: Bounded Residency, Causal Validity, and Recoverable World State

系列位置： CWSR Paper 04 / 08；直接承接 Paper 00–03 的狀態、喚醒、尺度與 Commit Gate 工作契約。

研究性質： 單機遊戲 Runtime 的工程方法論延伸；不聲稱發明虛擬記憶體、記憶體池、Rust 所有權、生命週期、快取、串流、垃圾回收、資料庫交易或 GPU 資源管理。

本篇交付： 可配置的動靜態資源契約、物理駐留狀態機、內容有效性／存放位置分離、回收與重建安全條件、RAM／VRAM 壓力治理、跨尺度資料安置、可證偽測試及 Paper 05–08 介面。

本篇未交付： 編譯通過的 Rust 套件、驅動層 VRAM 配置器、實機效能數據、跨 GPU 後端 benchmark、Godot 或 EveWorld Engine 已完成的整合聲明。

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

摘要

若開放世界遊戲把「世界存在」誤解成「所有物件必須長時間駐留在 RAM／VRAM」，即使藉由因果排程省下 CPU 工作，也可能因資料膨脹、重複副本、無限制預載、頻繁配置、快取抖動或 GPU 工作與渲染競爭而失去效果。反之，極端地追求低駐留量也並非合理目標：重建、I/O、PCIe 傳輸、同步與期限違反，可能讓過度回收比保留工作集昂貴。

CWSR Paper 00 提出部分記憶體區可以先宣告靜態基底、動態區、預算及可擴張但受局部上限治理的工作集；Paper 01 分離世界身份、結果有效性、物化、副本與權威提交；Paper 02 建立義務保全的喚醒契約；Paper 03 說明宏觀、中觀與微觀的聚合／細化、身份錨點、世界時間與跨尺度帳本。Paper 04 的任務不是重述這些原理，而是指定狀態在什麼條件下可以配置、共享、固定、移動、縮減、釋放、重新建構，並證明它不因此失去世界事實、必要期限或合法觀察。

本篇將記憶體管理視為兩個彼此分離的問題：第一，哪些邏輯世界事實、候選結果、摘要或觀察投影需要物理載體；第二，在現有 RAM、VRAM、持久化儲存與計算預算下，哪一種載體與時間安排最能履行契約。為此，本文引入 CWSR 工作性的 Residency Contract（駐留契約）、Memory Region Contract（區域契約）、Replica Descriptor（實體副本描述符）、Eviction Certificate（安全回收證據） 與 Recovery Plan（恢復方案）。

核心主張是：應用可以持有可擴張的邏輯世界，卻只實際啟動有限、有明確時限與安全責任的物理工作集；既有資料若仍合法且有價值可以保留，已無需求且可恢復的資料則可以回收。 所有預算與策略只在具體硬體、工作負載及規則契約下成立，不能被提升為與設備無關的通用最優定理。本篇提出可操作的型別、程序與反例，交由 Paper 07 建立執行原型，Paper 08 做實測與比較。

關鍵詞： CWSR；Memory Contract；Static/Dynamic Memory；Selective Materialization；World-State Residency；RAM／VRAM；Budget；Versioned Replica；Rust Ownership；Eviction；Reconstruction；Causal Validity；Simulation LOD；Memory Pressure；Device Fence；Commit Gate；World State。

0. 本篇的問題域、責任與非主張

0.1 真正要處理的問題

原始問題不是「如何把所有資料壓到最少位元組」，而是：如果應用能更早聲明什麼會一直存在、什麼只在事件到來時存在、什麼資料會因狀態變化失效，能否防止無必要的配置、複製、搬運與重算，讓有限硬體負擔更大、更持續的動態世界？

本篇從單機遊戲開始；不把「全域記憶體」解釋成共享全部實體位址的單一超大陣列，也不將使用者購買更多 RAM 或 GPU 視為解決世界複雜度的必要前提。

這裏的「動靜態」至少包含兩種不同語義，絕不能混寫：

1. 資料變動性（Mutability）： 在指定規則、版本與期間內，內容能否改變。
2. 資源區配置性（Allocation Behavior）： 用量是固定、受限成長、按需配置、可回收還是可重建。

一個長期不變的貼圖可以在可回收的資源區；會持續變動的經濟摘要也可以長時間保持駐留。不能因名稱有 Static 就認為永不失效，或因名稱有 Dynamic 就認為一定每幀重新配置。

0.2 與 Paper 00–03 的嚴格關係

不變原則： Planning、Execution、World Mutation 與 Resource Ownership 不是同一種權力；Memory Manager 可以管理物理副本，但無權自行創建或刪除已提交世界事實。

0.3 明確不成立的宣稱

本篇不宣稱：

• 不使用記憶體就能保存任意完整資訊；
• 可以不用 RAM／VRAM 而直接在任意裝置上零成本計算；
• 所有狀態都可從 seed 或程序化生成法無損恢復；
• 選擇性物化必然改善所有遊戲的幀率、能耗或總記憶體佔用；
• Rust 的 borrow checker 可以自動判斷世界事件因果；
• 預宣告資源區等於在程式啟動時把所有容量實際配置完畢；
• 一般遊戲程式可以保證驅動層 VRAM 的真實物理保留量；
• 任何快取命中都可無條件免除時間、版本、權限或精度檢查；
• 一個可行配置就必定是全域最優配置；
• 可以不觀測硬體、OS、驅動與渲染競爭而預估完整效益。

0.4 本篇的完成標準

完成是指交付可以被測試的語義與介面，不是宣稱程式已跑通。最低標準為：每個真實世界資料副本可以追溯所對應的狀態版本；每次配置與回收有容量決策；每個不可恢復資料具有不可任意回收的保護；GPU in-flight buffer 釋放須有完成證據；跨尺度細化不因資料重建造成身份／資產複製；存讀檔後的因果與時間義務仍可恢復。

1. 兩個空間：邏輯世界與物理存放

1.1 Logical World State 不等於 Resident Working Set

沿用 Paper 01 的邏輯世界 $W_t$，設其中可尋址狀態集合為 $\mathcal S_t$，實際供工作存取的物理副本形成 $\mathcal R_t$。

$\mathcal N_t$ 為當前可用儲存與執行層，包括 RAM、GPU memory、memory-mapped storage、持久化檔案、某些硬體支援的共用區等。此集合是邏輯類型化而非宣稱存在一個通用裸位址空間。

可能有：

但此比較僅適合量測已定義世界狀態；不應拿未定義、未實例化的可能內容偽裝成已存在的一兆個 NPC，製造誇大的壓縮比。

1.2 四種不能混為一談的內容

1. Canonical Fact： 已提交的身份、劇情、庫存、期限、事件與規則版本。
2. Derived Valid Result： 依給定版本、依賴、時間與精度契約計算出的可重用結果。
3. Candidate / Speculative Result： 尚未通過 Commit Gate 的結果、工作暫存或預熱產物。
4. Observation / Rendering Projection： UI、畫面、音效或導出的觀察資料，可與世界事實不同步且須標記新鮮度。

四者可能同時出現在不同記憶體區，卻具有不同的回收、重算與授權條件。候選結果即使被 GPU 快速算好，仍是候選；UI 缺資料時也不能自行「補算」一個角色人生並默默讓它成為世界歷史。

1.3 Logical ID、版本、物理位址與 Replica ID

對狀態 $s$，沿用：

另外增加三個不應混淆的識別：

ReplicaRef 可能指向可搬移或已釋放的實體實例；PhysicalLocation 更可能隨資源分配而變。任何跨休眠、存檔或 GPU 完成回呼的穩定身份，都不得直接用裸指標、offset 或 VRAM address 代替。

1.4 版本仍有效，不等於副本仍在

一名角色的技能派生數值依賴版本未變、結果理論上仍有效，但其 CPU 快取可能已在記憶體壓力下釋放。此時 Valid 為真，Resident 為假；再次需要時可從合法副本載入或按依賴重算。

反過來，RAM 中緩衝仍存在，也不保證它屬於目前權威世界版本。Resident 可為真，Valid 為假；它不可因配置器尚未回收就獲得世界合法性。

此分離是本篇所有記憶體政策的前提。

2. 記憶體契約的五個正交維度

2.1 不用 Static／Dynamic 二分法描述全部狀態

對每個資料物件與區域，至少獨立宣告五個維度：

另外，狀態具有 Scale Profile、Temporal Duty、Dependency Stamp、Precision Contract、Authority 與 Recovery Evidence。這些不是第六種互斥的 Static/Dynamic 標籤，而是可相互組合的約束。

2.2 Static-Core 區與固定容量不是一回事

Static-Core 概念上是生命週期穩定、變更相對較少且每次執行都可能需要的基底：規則表、schema、固定索引、必要 metadata、稽核 configuration 等。但它不必在進程啟動時完整配置，仍可延後載入、版本切換或只讀共用。

Fixed-Capacity 指區域某時間段的容量約束，即使內容常改變也成立，例如固定容量的 frame staging ring。相反地，Static-Core 的全體內容可能隨 Mod 載入或地圖版本增加。兩者不能相互推導。

2.3 Dynamic 區不等於無界堆積

Dynamic 區允許在既定預算與工作負載下成長，但不得在有限硬體上無條件擴張。可採固定硬上限、可借用預算、有期限的 backpressure、冷資料回收，以及規則容許的解析度降低。

「不完全有限，也不是完全無界」可轉譯為：邏輯狀態領域可以隨遊戲進度擴張，而任一時刻、任一已承認的硬體域只有有限物理配額；當承諾高於現有可行域，必須啟動合法退化或拒絕流程。

世界的潛在延展不受一份預先窮盡枚舉的固定角色清單所限制；這不是宣稱有限電腦能承載任意大的已存在世界。

2.4 生命週期是資料合約，不是借用語法

Rust &T、&mut T 與生命週期限制可幫助避免非法引用與資料競爭；但 Rust 引用生命週期不描述 NPC 在世界存在多久、某狀態在第幾個模擬 tick 失效、GPU fence 何時完成或候選結果能否提交。

因此至少區分：

• Reference lifetime： 指標與引用何時仍然安全；
• Allocation lifetime： 實際記憶體配置何時仍然有效；
• Semantic lifetime： 資料在什麼世界版本與時間契約下可使用；
• Lease lifetime： 哪個子系統在多長時間內有權阻止回收；
• Execution lifetime： 背景工作、GPU dispatch、DMA 或 I/O 何時完成。

只有這幾者共同滿足，引用與資料才可合法交付下游。任一失效都不能用「borrow checker 已通過」代替其他證據。

2.5 可重建性不是布林捷徑

rebuildable: true 必須附帶受驗證的 Recovery Plan：所需輸入、來源版本、schema、規則版本、隨機種子或隨機流位置、可依賴的 checkpoint／journal、耗時上界、恢復後有效性檢查。

不具上述資訊的宣告不能提升為可安全回收。某些隨機抽樣只有固定 seed 不夠：若工作拆分、隨機數消耗順序或機率演算法版本改變，同一 seed 未必產生同一世界結果。

3. Memory Region Contract：應用先宣告的資源區

3.1 區域宣告的工程定位

Region 是 allocation policy 與責任的單位，不一定是實體上連續的 virtual address block，更不是物理記憶體已被分配。可由 arena、pool、allocator class、GPU heap、ring buffer、cache tier、disk chunk 或 memory-mapped pages 等成熟技術實現。

定義最低工作性記錄：

$B_{soft}$ 是軟目標而非違法線， $B_{hard}$ 是 admission gate 的上限， $B_{guard}$ 是給已承諾工作與外部系統的保守餘額。平台無法提供可靠容量保證時，須把容量標為估計／觀測上界，而非假稱硬體強制執行。

3.2 建議的區域類別

一份物件可有多種語義角色，但不能因此在帳本中重複計算；同一 RAM 實體副本若由多個 Region 共用，需有共享所有者與唯一容量計數。

3.3 預宣告範例

以下是示意的機器可讀草案；數值不代表任何硬體已驗證的最佳配置：

memory_contract_version: cwsr-mem-v0.1
world_profile: example-rpg
units: MiB
policy:
  allow_unknown_demand: true
  unknown_demand_action: conservative_admission_or_refuse
  preserve_committed_facts: true
  gpu_preload_is_advisory: true
regions:
  - id: world-anchors
    tier: RAM
    budget_soft_mib: 64
    budget_hard_mib: 128
    retention: durable
    growth: bounded
    eviction: only_after_durable_recovery_verified
  - id: active-details
    tier: RAM
    budget_soft_mib: 512
    budget_hard_mib: 768
    retention: rebuildable_when_proven
    growth: bounded_borrowable
    eviction: dependency_and_deadline_aware
  - id: gpu-world-buffers
    tier: VRAM
    budget_soft_mib: 256
    budget_hard_mib: 384
    retention: transient_candidates
    growth: bounded
    eviction: fence_and_snapshot_checked
  - id: transfer-staging
    tier: RAM
    budget_soft_mib: 32
    budget_hard_mib: 64
    retention: ephemeral
    growth: bounded
    eviction: after_transfer_completion

Region 容量只是局部請求，總量必須通過共享實體資源的聯合 admission。不能因多個 Region 各自宣稱還有 300 MiB 可用，就推定 GPU 同時有多個獨立的 300 MiB 餘額。

3.4 Region 可伸縮，但收縮也有契約

擴張需經容量、配額、硬限制、其他工作 reservation 與期限檢查。收縮需檢查仍被引用或 in-flight 的物件、可恢復性、回收成本、預測重用、已提交歷史與資料依賴。

Request Growth
  -> Capacity Snapshot
  -> Hard Constraint Check
  -> Reservation / Borrow or Refuse
  -> Allocation
  -> Replication / Materialization
  -> Verify / Publish Handle

所謂「最近沒讀過」與「可以安全丟掉」是完全不同的命題。

4. 物理駐留描述符與配置世代

4.1 Replica Descriptor

給定某一版本的 StateRef 及物理 tier $n$，定義：

這是物理副本，不是 Paper 01 的全域狀態身份。其欄位至少包含：

欄位不必同樣放入所有 payload，可以是 metadata sidecar、allocator handle 或索引記錄，重點在可觀測、可驗證與可恢復。

4.2 Handle 不等於可永久保留的裸位址

底層配置器會搬動資料、GPU heap 會重配置、物件會從 RAM 移往壓縮儲存，外部系統應透過含世代的 handle 重新解析並檢查有效性。Stable Logical ID 不表示 Buffer 此刻仍在 VRAM。

採 generational handle 時，一個失效引用即使 offset 再次出現，也不能憑位址相同便讀到新物件。這是 ABA 類風險在遊戲資源重用下的具體形式。

4.3 Replica 的 Authority 不由所在 tier 決定

即使 GPU 保存最新中間結果，只有 Commit Gate 驗證成功才可能使它成為新權威世界版本。RAM 或 GPU 的快取副本也可以表示以前合法、現在已過期的 StateRef。

Replica stores payload        != world has committed that payload
Replica contains latest bytes != dependency / time contracts still valid
Replica is GPU resident       != CPU can read it without synchronization
State identity is addressable != resident instance has been allocated

4.4 Clean、Dirty、Candidate 不是同一維度

Clean 的最低意義是：副本內容相對記錄的 StateRef 或來源可重新取得，不存在未保存且唯一的變更。Dirty 不能簡化為「比另一副本新」，因為時間有效性、未提交候選與持久性是不同維度。

尚未提交的 GPU buffer 可能包含正在計算的候選數據；即使 Dirty 位元沒有被上層設定，也不應被當成世界事實寫入 save file。須靠資料型別與 provenance 區分。

5. RAM／VRAM／Storage 的容量與保留決策

5.1 總量 admission 不得只看單一 Region

對實體 tier $n$，定義已配置量 $U_n(t)$ 、尚未轉為配置的合法 reservation $Q_n(t)$ 、安全緩衝 $G_n(t)$ 、應用當下被承認的可用預算 $B_n(t)$。

在不重複計數的假設下，要求：

$U_n$ 以實際不可共享的底層配置量計數，若一份配置被多個 Region 引用只計一次。 $Q_n$ 僅計尚未轉為 $U_n$ 的配額，以避免使用量與 reservation 雙計。

$B_n$ 不等於標稱總 RAM 或列出的全 VRAM；它是扣除其他用途、系統限制、引擎已有承諾及保守餘裕後，應用願意接納的新計算預算。若無強制保障，當外部進程或驅動壓力改變時， $B_n(t)$ 必須重新估計並收縮。

5.2 軟目標與硬限制

定義每個區域：

超過 soft 表示需要觀測、降級或評估回收；超過 hard 且無正式借用／擴張決策，新的配置必須被阻擋。已開始而無法安全取消的 GPU 工作、世界提交或存檔操作，需事先保留足夠的容量。

5.3 VRAM 不是整台 GPU 的「可自由使用區」

消費級 GPU 常同時負擔 OS 桌面合成、渲染貼圖、shadow maps、幀暫存、驅動配置與 compute buffer。CWSR 應保留 Render Budget 的優先級，不可把「顯示還剩 VRAM」無條件拿來預載整個世界。

此處 VRAM budget 指由裝置 API 與 Runtime 共同估算的可用域；須分清 local memory、host-visible / shared memory、driver-managed residency 與實際資料傳輸或 paging。Unified Memory、BAR 或 host-visible heap 不等於 CPU／GPU 存取沒有頻寬、延遲、同步或頁面遷移成本。

5.4 RAM 也不能被忽視

OS page cache、配置器碎片、程式堆、堆疊、引擎資產、音效緩衝、腳本系統、背景工作及存檔快照都消耗 RAM。將 GPU buffer 對映為 host memory，或把所有資料從 VRAM 移到 RAM，也不是零成本。

若系統已出現 swap／重大 page fault，可能應先縮減 live working set、消除重複副本或降低高峰寫入速度，而不是繼續縮短 GPU kernel 時間。

5.5 記憶體壓力分級

閾值須以硬體實測決定：

Critical 不得靠捨棄玩家已提交的任務、遺失經濟帳本或秘密取消 NPC 期限來消除壓力。合理退化是降低可見細節或暫緩不承諾的工作，不是偷偷改寫世界規則。

6. 駐留狀態機：何時有副本、何時能釋放

6.1 狀態機管理物理副本，不管理世界存在

建議為每個 ReplicaRef 提供可追溯的生命週期：

UNMATERIALIZED
  -> RESOLVING
  -> ALLOCATED
  -> POPULATING
  -> RESIDENT_UNVERIFIED
  -> RESIDENT_VERIFIED
  -> EVICT_PENDING
  -> RELEASED

RESIDENT_VERIFIED -> IN_FLIGHT -> RESIDENT_VERIFIED / FAILED
RESIDENT_VERIFIED -> STALE
STALE             -> REFRESHING -> RESIDENT_UNVERIFIED
EVICT_PENDING     -> EVICT_BLOCKED / RELEASED

Pinned、Dirty、Lease、Due、Candidate、Committed 是對不同對象或正交狀態的標籤，不應全部硬塞進同一排他列舉；例如 Resident Verified 且 Pinned 且 In-Use 可以合法同時成立。

6.2 RESIDENT_VERIFIED 不代表永久有效

它只表示載入時資料、來源雜湊與當時指定的快照契約通過檢查。每次供實際工作讀取前，仍須比對與本次工作相關的 input revision、schema、規則與時間窗口。若上游已變更，同一副本可在物理上保留，但須標記 Stale 或用途受限。

6.3 為什麼不能由 free(ptr) 直接推導安全性

一份 CPU buffer 可能正被其他工作借用；GPU staging buffer 可能有未完成 DMA；GPU shader 還可能正在存取 buffer；背景 save worker 可能尚未將唯一新修訂寫入 durable file。此時 free、重用或縮容可能產生 use-after-free、錯誤畫面、資料遺失或把舊結果當作新世界。

釋放前至少確認：沒有不可撤銷借用；沒有 live reader／writer；相關 GPU／I/O fence 完成；不存在未持久化的唯一正當狀態；沒有尚未移交的期限、喚醒或 checkpoint 責任；不存在未完成的世界提交責任。

6.4 EVICT_PENDING 不是永久卡住

回收可以被阻擋，但阻擋必須 typed 並有最終處置路徑：等待 fence、等待 checkpoint、移動到其他 tier、撤銷過期 lease、縮小其他區域或取消回收計畫。若硬預算已緊張，無限等待不可釋放項目同時繼續接納新配置，也是錯誤。

6.5 縮容競態及 ABA

對 lease／pin 不應先檢查「沒有讀者」後直接睡眠再釋放，因為新讀者可能在兩步間取得存取權。借用註冊、generation 檢查與回收切換至少需要可線性化同步點；GPU 完成條件另須受裝置 API 同步契約約束。

不要求單一全球 mutex，但要求每個可回收物件的狀態切換，在本機併發條件下可被證明一致。即使空間 offset 回收後被再次配置，使用舊 generation 的句柄必須失敗而不是意外命中新物件。

7. Residency Contract：何種世界狀態需要怎樣的駐留

7.1 本篇的核心工作性契約

對狀態 $s$ 、使用者工作 $q$ 、合法時間窗口 $I$，定義一個契約物件：

其作用不是替代 Paper 01 的 State Descriptor，而是補充這次使用所需的物理服務條件。

• ref：必須讀取哪一份 StateRef，或明確容許哪一組版本。
• needs：完整內容、摘要、索引、特定欄位、增量片段或只需 capability handle。
• tier：支援的 RAM／VRAM／Storage 載體與硬體限制。
• deadline：對模擬時鐘及實際等待時間分別定義期限。
• precision：此目的所允許的誤差，不能從畫面 LOD 偷推世界精度。
• keep：使用完成後應釋放、保留、延時保留或固定。
• recover：何種來源、成本與證據可重建。
• authority：誰有權讀寫與批准世界修改。
• evidence：依賴章戳、時間水位、世代、校驗與可追溯原因。

7.2 Needs 可以是局部投影

玩家打開地圖時可能只需「城市座標、已發現地點、交通連通性」；不應因此把城市所有 NPC 的對話樹、材質與內部行為資料載入記憶體。玩家點開一名有持續身份的 NPC，才可能需要身份錨點、關係資訊及一小段狀態詳細資料。

但 Needs: summary 不自動代表能代替詳細資料。若玩家詢問「昨天是誰殺了商人」，僅有城市犯罪率統計無法合法回覆明確身份；必須明示未知、查詢事件來源或進行有根據的詳細物化。

7.3 按版本匹配，而不是按資料相等匹配

假設一座城鎮的糧食先 +10 後 -10，最後總數又回到 100。用快取直接比較 payload 相等並宣稱完全有效，可能漏掉兩次已提交交易、商人關係變化或任務事件。CWSR 的快取匹配優先考慮版本、依賴與時間契約；內容雜湊只能是完整性或特定純函數重用的輔助。

7.4 Residency Contract 不能創建不存在的因果義務

Materialization 請求是資源請求；如果純粹為觀察而載入某個已提交狀態，不應自行觸發一次新的世界時間事件、重新抽取亂數或把視圖展開當作玩家行動。真正的 World Mutation 仍依 Paper 02 的 Wake／Execution 與 Paper 01 Commit Gate 處理。

7.5 預載與正式需求的權力不同

承接 GCCF 05：預測玩家可能進城，可提前載入城鎮 schema、貼圖及被規則允許的摘要。這個 Predictive Hint 不賦予取消確定事件期限、佔滿渲染保留區或讓預計算候選直接寫入世界的權限。

當實際需求與預測不同，必須能取消投機項目並收回容量，而不損害已承諾世界狀態。

8. 安全回收：Eviction 不是刪除世界事實

8.1 Can Evict 必須先過硬條件

對副本 $r$，工作性的可回收判定可寫成：

其中 Unused 指沒有不可安全撤銷的當前借用；FenceDone 要求所有相關非同步讀寫完成；RecoverableOrRedundant 不只是「某處還有舊副本」，而須保證新的合法讀取可以恢復滿足版本的內容。

這些是候選充分條件的工作性綜合，而不是所有平台的形式證明。裝置錯誤、儲存媒體失效、外部 Mod 和異常中止仍須有保守處理。

8.2 持久化前不得釋放最後一份必要事實

對不可重建的 canonical fact，如果當下只有一份 RAM 副本且尚未成功持久化或複製至經驗證的 durable source，該副本不可直接回收。

即使 world revision 已遞增，若寫檔只停留在暫存或尚未達成 durability 條件，也不能宣稱可以釋放唯一可用資料。需先完成日誌、快照、manifest 或其他經實測的恢復閉包。

8.3 不能靠遺失事件隊列釋放記憶體

Paper 02 已建立 Wake Ticket、期限與訂閱屏障。若某個休眠 NPC 的細部資料被回收，其 due_tick、事件游標、因果訂閱、待提交效果與恢復位置仍須保留在可按時喚醒的索引或可靠儲存中。

把 detailed AI struct 刪掉但未保留下次期限，不叫省記憶體，只是漏掉世界義務。

8.4 Eviction Certificate

定義最小回收證據：

它記錄「當時為什麼允許回收」，但不是形式證明器產出的通用數學證書。內容至少有：

replica_id / generation
world_revision / schema_revision / rule_revision
state_kind: canonical | derived | candidate | observation
last_verified_recovery_source
recovery_method_and_estimated_cost
live_lease_count / in_flight_fences
event_obligation_cursor / next_due_tick
scale_membership_and_ledger_watermark
allocation_release_generation
policy_version / issuer / decision_timestamp

若字段缺失、互相矛盾或來源不可用，回收應被阻止、延期或採取保守複製路徑；不得把空值默認為安全。

8.5 冷資料可以壓縮，但壓縮形式仍須可驗證

將大區域細節壓縮為摘要，可降低常駐量，但要區分：

• 無損壓縮： 有解碼方式與資料完整性校驗。
• 可重建省略： 有完整依賴來源與決定性或容許誤差的重建方法。
• 有損聚合： 僅保留指定世界不變量，不可冒稱保存全部微觀歷史。

若聚合失去具名 NPC 的任務證據，就必須保持這部分在 Anchor／Journal 或其他 source；不能因總人口統計正確就判定所有細節可回收。

8.6 回收優先順序不可只靠單一分數

正式決策流程應先以硬約束排除不安全候選；剩餘候選才評估保留的期望效益、容量壓力、重新計算與 I/O 成本。不可讓某個高分數覆蓋不可丟失的世界事實。

可以先採成熟 LRU/LFU/clock 或分層 cache 作基線，再比較 CWSR 的因果／時間額外資訊是否真的帶來收益。本篇不宣稱 LRU 天生錯誤，因為許多遊戲在充分局部性下 LRU 已非常有效。

9. 按需載入、重新計算與完整恢復

9.1 Recovery Plan 是預先存在的責任

Recovery Plan 必須說明：資料從哪來、需要哪些版本、何種演算法重建、輸入可不可見、是否須等待磁碟／GPU、是否涉及觀察結果、執行期限及出錯後如何回退。

recovery_plan_version: cwsr-recovery-v0.1
state_ref: world-A/city-2/market/price@revision-1042
source_kind: checkpoint_plus_journal
checkpoint_ref: checkpoint-987
journal_start: 988
journal_end: 1042
expected_schema: economy-schema-4
expected_rule_revision: economy-rule-9
random_stream_contract: counter_based_per_entity_v2
precision: exact_for_inventory_and_transactions
max_recovery_latency_class: interactive
validation:
  - state_identity
  - version_chain
  - journal_continuity
  - balance_ledger
failure_action: refuse_or_fallback_to_verified_older_snapshot_with_explicit_staleness

這是示意，不代表從較舊 snapshot 恢復後的資料一定能用於所有世界修改。若請求指定 revision-1042 且只取得 987，只能作明示過期的觀察或安全後退，不能直接提交需要新版本的交易。

9.2 三類恢復

Exact Restore： 從資料或事件來源取得與指定 StateRef 完全相符的狀態，需考慮版本、序列化和平台差異。

Semantic Restore： 在宣告的精度與世界觀察合約下，重建語義等價結果；例如某些純數值視圖可容許浮點差，但貨幣交易和劇情事實未必可容許。

Refinement Materialization： 將宏觀或中觀摘要在合法規則下建立新的微觀表示。依 Paper 03，除非已經保存完整可逆來源，這通常不是既有微觀歷史的無損反函數。

9.3 重建不一定比載入便宜

一個資料或許只需 1 MiB，卻要昂貴數值模擬或重新生成才可恢復；另一個 50 MiB 的暫存陣列則可能很快重新計算。應量測恢復耗時、資源競爭、I/O throughput、CPU/GPU 同步與延遲尾端，而不只用 bytes 決定保留價值。

9.4 再生速度及 deadline

即使某資產從演算法上可重建，若下一個互動需要在 16 ms 內回答，而重建需要 100 ms，它也不符合當前交互 deadline。可以預熱、保留熱副本、先取得低精度合法視圖或接受延遲；但不得假裝所有期限都能被滿足。

9.5 不要讓重建有世界副作用

Derived cache 的重新計算應盡量為純函數或在受控隔離的快照中執行。若重建時呼叫新的隨機抽籤、移動 NPC、扣除玩家資源或發出交易，該流程不是純快取恢復，必須返回 Paper 02 的因果執行與 Commit Gate。

9.6 失敗時的正確回答

當 recovery source 已遺失、schema 不可解碼、journal 缺段或 reconstruction 在期限內無法完成時，系統應產生 typed failure，例如 RECOVERY_SOURCE_MISSING、SCHEMA_INCOMPATIBLE、DEADLINE_UNSATISFIABLE、CHECKSUM_MISMATCH 或 WORLD_REVISION_STALE。

不可悄悄偽造舊世界狀態；可合法降級的部分須明示其限制，不能合法降級時就拒絕讀取／提交並保留回復機會。

10. 記憶體有效性與因果失效的閉合

10.1 Paper 02 的 Invalidation 也作用於駐留副本

若世界事件使衍生狀態的依賴失效，該資料不一定要立即 free，但不能再被工作視為有效輸入。失效是語義判定；回收是物理資源決策；兩者可以不同步完成。

例如一項裝備變動使攻擊力快取失效，UI 面板當下未顯示，不必立即算新攻擊力；保留舊快取至記憶體壓力時回收也可以。但當有計算需要新攻擊力，必須先檢查依賴版本並重建正確結果。

10.2 動態依賴須確實建立

當 NPC 的任務會依「是否存在守衛」等負條件決策時，只記錄之前觀測到的具體守衛列表是不夠的。配置器不能因快取尚存就忽略集合成員新增、索引版次或否定查詢改變。此問題由 Paper 01 的 Rule-Causal Dependency 與 Paper 02 的動態依賴契約保證，本篇只要求副本必須附帶可重新驗證的依賴 stamp。

10.3 Invalidate 先於 Serve 的可靠性

假設上游更新提交與下游取用快取並行。若更新提交成功後的通知尚未被副本管理器處理，讀者可能拿到已過期資料。因此正式服務時須使用被證明足夠的版本快照、同步水位或可追溯讀寫次序；僅靠非原子的 stale 布林值並不足夠。

10.4 多版本共存是合理狀態

對同一 State ID，舊版本可能仍被正在完成的純讀取工作使用，新版本則成為權威世界。此時可透過 immutable snapshot、多版本控制或 copy-on-write 共存，待所有合法讀者完成才釋放舊版本。多版本共存不等於出現多份互相競爭的 canonical world。

10.5 候選結果必須採分離的成本帳

如果 GPU 產生大型候選 buffer，而 Commit Gate 最後拒絕提交，這段記憶體應從候選工作集清理，不可把 rejected result 納入 canonical state。測量時要把候選暫存峰值計入系統成本，不能只統計最後提交的資料大小。

11. 多尺度世界的記憶體安置

11.1 宏／中／微不是 RAM／VRAM／Disk 的對應表

尺度由規則、觀察與因果作用域決定；放哪個 tier 由資料局部性、工作形態、頻率與容量決定。宏觀人口統計可能適合 GPU 大批次操作，具名 NPC 的任務日誌可能適合 RAM／持久化儲存；但任何尺度都不被永久綁定某一硬體。

11.2 Anchor 與 Summary 必須分離

承接 Paper 03 的四層資料：Identity Anchor、Event/Obligation Journal、Scale Summaries、Materialized Details。這四層不必全部常駐，卻有不同的最低可恢復責任：

• Anchor 保護已承諾身份、關係、不可替代世界事實。
• Journal 保護已提交事件、未履行期限、恢復位置與跨尺度來源。
• Summary 保護有版本和精度證據的宏中尺度狀態。
• Detail 承載需要互動、觀察或精細計算時的實體表示。

Anchor 可由持久化檔案加小型 RAM 索引組成；不能因稱為「保護」就要求全部內容永遠在 RAM。

11.3 聚合後回收微觀，不得消失守恆義務

城市糧食總量為 100 袋，玩家進倉庫時將其中 20 袋表現為可互動細物件。從微觀恢復中觀後，已扣除的袋數、所有權、移動事件與未完成交易，須在同一世界 revision 和跨尺度 Ledger 中正確反映。

可工作性要求：

此式只在定義明確、互不重疊的資產分區與同一有效時間切面下成立；若存在運輸中資產、預留交易或回滾候選，須把其帳目分類納入，不得直接套用簡化式。

11.4 首次細化不等於歷史重播

從「某城人口 5,000、商人 8%」的 Summary 建立可互動 NPC，是一次受規則約束的細化／初始生成，不是證明這些 NPC 過去都已被逐 tick 模擬過。若要求持續身份或過去事實，就要有 Anchor、Journal 或明確的世界初始化提交，而非假裝細化推回唯一的歷史。

11.5 觀察熱度不是唯一保留策略

距離玩家最近可能是高熱資料，但遠方已設定為下一秒爆發的重大世界事件，或一筆到期商隊交易，仍可能具有更高的計算優先權。Residency Contract 必須同時接收 Causal Frontier、due time、identity anchors、觀察精度與資源成本。

11.6 防止反覆細化／聚合造成抖動

若玩家在兩座城市邊界快速走動，系統可能不停載入、展開、回收 NPC 詳細資料。可運用 hysteresis、prefetch margin、最低駐留時間、空間與因果連續區域、漸進式展開等成熟手段，但必須量測其成本。

在不突破硬記憶體限制的前提下，適當保留 warm state 可能優於每次切換都完全清空；無條件強制全部保留則可能導致 VRAM 溢出。

12. 給 GPU 的世界資料：駐留與計算不能混成同一決策

12.1 Device Compute 不是畫面輸出

當大量經濟流量、細胞式區域狀態、群體統計或弱耦合代理更新具備共同計算形態，GPU 可以作為世界狀態計算器。但「GPU 能算」不能推導「應該把所有世界資料搬到 VRAM」，也不能推導所有工作都該按 GPU 時鐘持續運作。

Paper 05 才正式討論 kernel、batch、非同步隊列與運算路由；本篇提供其輸入資料的配置與有效性要求。

12.2 CPU↔GPU 傳輸成本不可省略

候選計算路徑至少包含：

並非每個 kernel 都需要 readback；若後續 GPU 工作直接使用合法中間結果，可只做裝置側依賴與適當 barrier。但任何省略必須由實際提交契約和裝置 API 證明，不能假稱 GPU 結果已在 CPU 上可讀。

12.3 GPU buffer 可以常駐但不能擁有世界修改權

同一批數據在多輪 GPU 世界計算中持續駐留，可以降低搬移成本。它是合理的性能候選。然而 GPU resident result 的權威地位仍依 Paper 01 Commit Gate；若 world revision 或 input stamp 失效，必須拒絕過期候選或採用合法重算策略。

Resident-on-GPU 與 Authoritative-in-world 是兩個獨立的描述。

12.4 Buffer ring 與 in-flight fence

多幀或多批次 GPU 工作可以使用 ring buffer、double/triple buffering 與 staging pool。不可在舊 dispatch 未完成時覆蓋其輸入 buffer，也不可在 GPU 尚在使用舊 generation 時將同一記憶體區分配給新工作。須由 fence/timeline semaphore 或對應裝置同步機制確認安全點。

12.5 GPU 工作與渲染預算競爭

即使世界 compute kernel 極快，如果佔用過多 VRAM、記憶體頻寬、排程時槽或使幀時間尾端惡化，整體遊戲體驗仍可能變差。本篇建議先限制 GPU 世界區的 soft/hard 預算、預留渲染和緊急用途、在出現壓力時優先取消投機世界預熱。

具體的 CPU／GPU 分工策略、渲染競爭驗證及可適應路由分別交給 Paper 05、06、08。

12.6 某些工作留在 CPU 可能更好

少量頻繁分支決策、資料極度稀疏且跨域查詢很多、每次結果都要求同步世界提交，或 GPU 上已有高負載的遊戲，將資料留在 CPU 可能避免反覆傳輸和延遲。硬體分配的正確性來自完整路徑與實測，不來自固定口號。

13. 物化規劃：從請求到資源安置

13.1 必須先回答的五個問題

當工作 $q$ 要求狀態 $s$，Materialization Planner 不應直接決定 malloc(bytes)，而應先詢問：

1. 語義需求： 要完整內容、部分欄位、索引、聚合摘要或可重算的衍生值？
2. 來源有效： 目前哪一份 SourceRef 與目標世界／規則／時間／精度契約一致？
3. 資源可行： 哪個 tier 具備合法權限、容量、所需同步及截止期限？
4. 經濟合理： 是直接使用現有副本、跨層搬移、在資料所在地計算、重建、延後還是拒絕？
5. 失敗怎麼辦： 容量不足、世界被新事件改變、GPU reset、存檔源損壞時如何保護世界？

13.2 候選路由與決策順序

本篇建議的最小順序：

Read Work Contract and Required StateRef
  -> Resolve and Validate State Descriptor
  -> Check Existing Valid Local Replica
  -> Enumerate Legal Materialization Alternatives
  -> Reject Candidates Violating Hard Constraints
  -> Estimate Full Critical-Path Cost and Memory Pressure
  -> Reserve Budget and Required Device/IO Dependencies
  -> Revalidate Versions at the Admission Boundary
  -> Materialize or Recover to a Candidate Replica
  -> Verify Content, Freshness, Generation and Access Rights
  -> Publish a Versioned Read Handle
  -> Maintain Lease Until Work/Device Completion
  -> Optionally Retain Warm / Release by Safe Eviction

這是一份候選演算法流程，而不是已測的最優規劃器。不合法的來源不能因速度快被選中；若沒有合法可行路徑，應回覆 typed failure 而不是默默使用舊資料。

13.3 先借用可用副本，再決定是否配置新副本

對同一份不可變的 StateRef，若 RAM 已存在可信、可共享且滿足同步條件的副本，建立新 allocation 未必必要。可透過 shareable handle、reference count、copy-on-write 或只讀映射來避免多份完全相同的實際內容。

然而當工作需要獨立寫入候選結果、裝置布局不同、alignment 不同或生命周期衝突時，建立獨立副本可能合理。所有權或借用權不應被效能要求任意跳過。

13.4 稀疏與局部物化

例如城市模型每個 NPC 都有 40 個欄位，但一次區域市場模擬只需職業、消費需求與可用收入，不必載入整個 NPC blob。可建立單獨的 SoA 欄位、稀疏查詢索引或壓縮投影。

須保留此投影的來源 revision、欄位 schema、成員版本與缺值語義。若工作後來需要 NPC 真實姓名或個人債務，不得把市場需求向量當成完整 NPC 物件。

13.5 複合物化計畫的原子責任

若一項行動需要 A、B、C 三份資料，可能不存在一次全部配置的空間。Planner 可評估串流、小批次或部分重建，但若契約要求同一世界快照，就必須使各資料處於相容的修訂與時間切面。

分段完成 A 後世界已改變，B／C 不能不經檢查便合成一份虛構的單一權威快照。若必須取得一致快照，應 pin 相關版本、使用 MVCC／snapshot 或重新規劃。

13.6 Admission 的失敗是正常結果

一份合理系統可以明確回答：

BUDGET_HARD_EXCEEDED
RESOURCE_RESERVATION_CONFLICT
DEADLINE_UNSATISFIABLE
REQUIRED_STATE_UNRECOVERABLE
STALE_SOURCE_REVISION
DEVICE_UNAVAILABLE
MATERIALIZATION_CANCELLED_BY_CAUSAL_INVALIDATION

與其承諾不可能的零延遲載入後在玩家面前崩潰，不如在合法範圍內做可觀測降級、延遲回應或保留停機恢復紀錄。

14. 成本模型與可證偽的保留決策

14.1 單純最小化 RAM 用量不是總效用最大化

設 $C_{hold}$ 為資料駐留占用所帶來的容量／機會成本， $C_{load}$ 為從存儲取回成本， $C_{rebuild}$ 為重新計算成本， $C_{transfer}$ 為資料跨層搬移成本， $C_{sync}$ 為同步與等待， $C_{schedule}$ 為治理自身開銷， $C_{deadline}$ 為違反期限可能造成的代價。

對一個給定工作請求的總成本，可用工作性拆分：

其中不同方案不一定同時發生所有項目，有些成本同時並行而不直接相加成延遲；此式是資源成本帳而非一個自動正確的 wall-clock critical-path 方程。正式量測需區分總 CPU 時間、總 GPU 時間、實際延遲及重疊部分。

14.2 回收與保留的比較

對某可安全回收的狀態 $s$，可定義在預測時間窗 $H$ 的兩個候選方案：

僅當所有硬條件通過，而且在指定成本權重下預估 $J_{evict}$ 較佳，回收才是合理候選。這個決策不能憑未知概率寫成通用最優式；應靠記錄實際再次使用率、重新載入尾端成本與回收次數校準。

14.3 因果預記載的價值和浪費

承接 GCCF 05，未來因果前沿可提示一個區域快要需要哪些資料。提前保留或載入可能節省互動延遲，也會造成預載未命中、VRAM 占用、重複搬移或搶走渲染資源。

因此必須至少記錄：

• preload_hit：在合法時間與版本下，資料確實被使用；
• preload_waste：到期或回收前未被實際需求使用；
• preload_late：需要時尚未完成準備；
• preload_invalidated：世界因果改變使已準備資料失效；
• avoidable_transfer：因規劃造成的可避免搬移；
• render_impact：GPU 世界預載對 frame time 尾端的影響。

14.4 Footprint、Fragmentation 與 Peak

除平均 RAM／VRAM 用量外，需區分：

以及可比較的 committed bytes、resident bytes、allocated bytes、external fragmentation、allocator overhead、scratch peak、recovery-source bytes。這些指標不能互相替代；平台 API 提供的值可能有不同統計意義，報告須標明。

14.5 管理成本大於工作成本時應放棄精細治理

對只有幾十個極輕量且每次都需要更新的數值，建立昂貴依賴圖、保存大量 metadata、反覆做 lease 和版本查詢，可能更慢。可選擇區域粗粒度配置、arena 一次釋放、固定 cache 或成熟預設 allocator；不要求為每個 scalar 都配置獨立 Residency Contract。

14.6 多目標政策與 GCM 的接口

效能、能耗、記憶體容量、延遲、渲染品質、世界正確性及回復能力不能隨意全部折成單一無條件分數。先排除違反硬約束的方案，再在可行集合中比較延遲、峰值與穩定性；若呈 Pareto trade-off 應如實保留候選，而不是聲稱某一分數永遠代表最佳。

本篇可借用 GCM Phase B 的 Capacity Vector 與 deterministic admission 概念，但不聲稱已實作或覆寫 GCM 的正式 allocator。

15. 遊戲 Runtime 的示意資料介面

15.1 型別重心：一切可被驗證的邏輯引用不可直接等同裸位址

以下 Rust 只是概念性接口草案，未編譯、未實測、未凍結 API，其功能是顯示記憶體分配、租約、世界修訂及重新建構間應存在的資料邊界。

// Conceptual contracts only; NOT compiled or API-stable.
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
struct WorldRevision(u64);
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
struct ReplicaId(u64);
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
struct AllocationGeneration(u64);
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
struct RegionId(u32);

#[derive(Clone, Debug, PartialEq, Eq)]
struct StateRef {
    world: String,
    domain: String,
    entity: String,
    field: String,
    revision: WorldRevision,
    schema_revision: u32,
    rule_revision: u32,
}

enum MemoryTier {
    CpuRam,
    GpuLocal { device_id: u32 },
    HostVisible { device_id: u32 },
    PersistentStorage,
}

enum RetentionKind {
    Durable,
    VerifiedRebuildable,
    Ephemeral,
}

enum PermissionKind {
    ReadOnlyShared,
    ExclusiveMutation,
    SnapshotRead,
    DeviceScoped,
}

struct RegionContract {
    id: RegionId,
    tier: MemoryTier,
    soft_budget_bytes: u64,
    hard_budget_bytes: u64,
    guard_bytes: u64,
    retention: RetentionKind,
    permission: PermissionKind,
}

struct VersionedReplicaHandle {
    replica_id: ReplicaId,
    generation: AllocationGeneration,
    state_ref: StateRef,
    region: RegionId,
}

struct RecoveryPlanRef {
    plan_id: String,
    source_revision: WorldRevision,
    validation_policy: String,
}

struct EvictionEvidence {
    replica_id: ReplicaId,
    generation: AllocationGeneration,
    source: Option<RecoveryPlanRef>,
    live_lease_count: u32,
    device_work_complete: bool,
    temporal_duties_preserved: bool,
    world_history_preserved: bool,
}

struct MaterializationRequest {
    state_ref: StateRef,
    preferred_tiers: Vec<MemoryTier>,
    required_fields: Vec<String>,
    deadline_class: String,
    precision_contract_id: String,
    requesting_work_id: String,
}

enum MaterializationFailure {
    StateUnrecoverable,
    StaleSource,
    BudgetUnavailable,
    DeadlineUnsatisfiable,
    DeviceNotAvailable,
    PermissionDenied,
    ValidationFailed,
}

正式實作至少還需要無法被任意複製的存取租約、執行緒／GPU 同步、取消安全性、配置器擁有權、持久性處理與提交門檻。目前的資料型別並不保證所有 invariants，不能拿它當作安全已經形式證明完成的證據。

15.2 Materialize 的概念程序

function materialize(request, world_snapshot, allocator_snapshot):
    descriptor = lookup_state_descriptor(request.state_ref)
    if descriptor is absent: return STATE_NOT_ADDRESSABLE
    if !access_allowed(request, descriptor): return PERMISSION_DENIED
    if !semantic_contract_valid(descriptor, world_snapshot, request):
        return STALE_SOURCE

    reuse = find_compatible_verified_replica(descriptor, request)
    if reuse exists and acquire_lease_atomically(reuse):
        if revalidate(reuse, world_snapshot): return READ_HANDLE(reuse)
        release_lease(reuse)

    candidates = construct_typed_plans(descriptor, request)
    candidates = filter_hard_constraints(candidates, allocator_snapshot)
    plan = choose_admissible_plan(candidates)
    if plan absent: return TYPED_FAILURE

    reservation = reserve_capacity(plan)
    if reservation fails: return BUDGET_UNAVAILABLE
    if !revalidate_input_revisions(descriptor, world_snapshot):
        cancel(reservation); return STALE_SOURCE

    candidate_replica = execute_materialization(plan, reservation)
    if !validate_materialization(candidate_replica, request):
        quarantine_or_release(candidate_replica)
        return VALIDATION_FAILED

    handle = publish_versioned_read_handle(candidate_replica)
    return handle  // world commit authority is NOT granted

重點是容量預留前後有版本驗證，而且 publish_versioned_read_handle 只給合適用途的存取權，不代表可修改世界。

15.3 安全回收的概念程序

function propose_evict(replica_id, expected_generation):
    record = lock_replica_metadata(replica_id)
    if record.generation != expected_generation: return STALE_HANDLE
    mark_evict_pending_without_racing_new_leases(record)

    if has_live_nonrevocable_users(record): return EVICT_BLOCKED
    if has_unfinished_device_or_io_fences(record): return EVICT_BLOCKED
    if !has_verified_recovery_or_safe_redundant_copy(record): return EVICT_BLOCKED
    if !all_temporal_and_world_obligations_preserved(record): return EVICT_BLOCKED
    if !current_policy_allows_eviction(record): return EVICT_BLOCKED

    evidence = build_eviction_evidence(record)
    if !revalidate(evidence): return EVICT_CANCELLED
    release_physical_allocation(record)
    invalidate_old_generation_handles(record)
    return EVICTED(evidence)

上述偽碼沒有實作鎖、fence、耐久存儲或 concurrent readers。Paper 07 應用具體 allocator／device backend 使每個抽象操作具有可測語義。

15.4 Memory Manager 和 Commit Gate 分權

15.5 Godot、EveWorld 與舊遊戲移植

本篇不要求直接替換遊戲引擎內建配置器。更容易驗證的做法是：讓 CWSR 管理一組獨立的世界資料／衍生緩衝，經 Adapter 向引擎提供只讀或經適當授權的版本化結果；引擎仍使用原有 texture／scene／rendering lifetime 管理。

在原始碼可取得的 C／C++ 老遊戲中，可以漸進引入 typed handle、dirty tracking、checkpoint 與 arena，不必假設一次將整個程式轉為 Rust 才能獲益。逆向二進位通常更難證明 hidden state 和 side effect 的依賴完整性，應另外列為風險。

16. 三個具體世界情境的端到端推演

16.1 情境 A：靜止選單、不中止世界時間

玩家打開遊戲選單，畫面暫時不變。渲染與 UI 可以按需要停止重做部分快取，但若規則定義世界時間仍推進，已到期的商隊、農作物和 NPC 行程必須繼續由 Paper 02 觸發。

• RAM 可以保留必要事件索引與世界摘要；
• 沒有立即互動的遠方詳細 NPC 行為緩衝可以回收；
• 不可刪除 pending obligation 的唯一副本；
• 玩家重新進入世界時按合法 StateRef 物化細節；
• 用過期 UI cache 顯示數值不等於世界實際停止演化。

驗收： 選單停留 10 分鐘後，世界時間與事件結果符合指定規則，且同等內容的 RAM／VRAM 工作集可能下降；不可只用 FPS 或桌面畫面不變來宣稱成功。

16.2 情境 B：兩座城市、橋樑斷裂與物資流量

設城市 A、B 各有商店、供需摘要與部分具名商人。玩家破壞連接道路的橋樑時：

1. Commit Gate 在微觀世界提交橋樑失效事件；
2. Paper 02 喚醒中觀物流、期限及跨域依賴；
3. Paper 03 以合法時間切面更新城市的物流、庫存與價格摘要；
4. 本篇決定是否只保留兩城的相關路網／需求／供應資料；
5. 若 GPU 執行群體更新，由 Paper 05 再決定批次與設備後端；
6. 更新成功後依版本與權威提交，相關 cached route 視依賴 stamp 失效。

若玩家之後進入城市 B，系統可細化需要的市場及商人資訊，但不得僅因重新載入詳細資料就把已中斷的商隊貨物加回市場。

驗收： 資源總量、身份、路徑可達性和劇情義務在卸載／重載後一致；同時報告峰值用量與回收／重新物化造成的延遲。

16.3 情境 C：遠方具名 NPC 的長期休眠與重逢

一名曾與玩家簽約的 NPC 離開玩家可視範圍。系統保存其 identity anchor、合約義務、規則版本與可恢復來源，並將當前無需求的行為資料緩衝移出熱 RAM。世界時間流逝期間，其確定到期的交易與行程仍依規則觸發。

重逢時系統須驗證：身份同一、已發生事件未重做、可用道具數量正確、合約到期是否完成、關係與對話可依正確版本重建。若原本的個體背景並未被實際模擬，不能生成一個與過去已提交事實相衝突的「回憶」。

驗收： 反覆離開／返回 100 次並經存讀檔之後，不出現重複 NPC ID、重複資產、遺失合約及錯誤隨機重播；量測 metadata 與詳細資料所占的資源成本。

17. 條件命題、必要前提與可檢驗邊界

17.1 命題 P04-1：安全釋放不改變邏輯世界

若副本 $r$ 的全部必要世界事實在獨立、已驗證的合法來源中仍可取得，且沒有活躍借用、未完成裝置工作、漏遷移事件義務或未提交變動，則釋放 $r$ 的實體配置可以保持目前已提交世界狀態不變。

此命題不等於保證下次 materialization 沒有延遲，也不保證某些外部存儲故障後仍可恢復。必須分別檢驗語義安全與可用性。

17.2 命題 P04-2：條件化快取重用可省略部分工作

若某派生結果的來源版本、依賴、規則、時間、精度與存取政策都符合新工作契約，重用合法物理副本可避免重新計算與配置；但建立、驗證與維護 metadata 可能產生額外成本。

若重算本身非常便宜、驗證很貴或工作高頻變化，這個方案可以在總效能上失敗。

17.3 命題 P04-3：邏輯世界擴大不必線性拉高同時駐留量

在特定工作負載與可合法摘要／可重建結構存在時，世界已定義狀態量的成長未必要求 RAM／VRAM 同比例成長。這是 條件性可擴展性假說，不是對任意開放世界或無限規模的複雜度上界證明。

如果所有 NPC 都必須在同一時刻具有獨立不可壓縮記憶且被隨機訪問，則常駐需求可能接近世界總資料量；本篇不能以因果治理魔術般消除該下界。

17.4 命題 P04-4：資源預算有可能提高整體穩定性

若固定或受控成長的 Region 能減少分配抖動、減低高峰碎片、保留渲染緊急緩衝、減少不必要資料傳輸，則有機會改善最差幀時間、重大 page fault 或 out-of-memory 發生率。但必須在品質等價、相同工作負載與現有成熟 baseline 下實測。

17.5 命題 P04-5：語義安全不等於效能優勢

就算一個安全回收方案能正確恢復全部世界狀態，也不必然比直接常駐更快。若磁碟頻寬不足、頁面搬移昂貴、恢復須重做大量工作，正確性成立而性能不佳是合法且重要的研究結果。

17.6 命題 P04-6：更少 RAM 不一定更少總能耗

頻繁壓縮、解壓、I/O、GPU 傳輸與重建可能增加 CPU/GPU／SSD 活動。若節省常駐量使時間、能耗與功率尖峰上升，必須完整報告，不可只引用單一記憶體指標作為優化成功。

18. 可證偽測試矩陣與實驗設計

18.1 對照組不可只選最差實作

至少建立四種可比較基線，對同一遊戲世界規則、資料量、場景、視覺品質與硬體設定測試：

不得對 CWSR 啟用高度精簡尺度、卻讓基線承擔更完整的 NPC／經濟規則；若比較的是不同精度模型，必須另列品質／誤差／規則語義差異。

18.2 測試工作負載

工作負載規模需逐步提升；若成本已不可接受，應記錄具體上界與失敗模式，而不是假定世界可無限放大。

18.3 語義正確性指標

最低要求包括：

1. Identity Integrity： 已提交 NPC／物件身份不重複、不漂移。
2. Canonical State Equivalence： 按指定精確或可容誤差契約比較世界修訂。
3. Event Obligation Preservation： 到期任務、Wake Ticket 與事件日誌游標沒有遺失。
4. Temporal Alignment： 不同尺度讀取落在合法時間切面；不憑時間快進創造新的歷史。
5. Ledger Closure： 庫存、貨幣、商隊、人口等已指定守恆或帳務一致性。
6. No Stale Commit： 過期 candidate／GPU result 無法越過 Commit Gate。
7. Recovery Fidelity： 在已標明的恢復模式中達到承諾的精確性或誤差界。
8. No Illegal Reuse： 舊 generation、無效 lease、已釋放指標不能再使用。
9. Durability： 相關世界事實在指定崩潰／存讀檔模型下具備恢復途徑。
10. Observation Contract： 明確要求最新資料的查詢不能無標示地提供過期摘要。

18.4 效能與資源指標

至少記錄：

• RAM／VRAM 的 allocated、committed、resident、peak 與 fragmentation 指標；
• 每 Region soft／hard 超越次數，以及 admission failure 原因；
• allocation／deallocation、page fault、cache miss、disk I/O 與 checkpoint 量；
• state materialization p50／p95／p99 latency；
• reload、rebuild、GPU transfer、copy-on-write 成本；
• eviction／re-materialization 每秒次數與 churn ratio；
• world simulation tick 時間、CPU 主執行緒和工作執行緒時間；
• 遊戲幀時間 p50／p95／p99、GPU render queue 的瓶頸與 VRAM pressure；
• GPU 世界運算批次的實際核時間與完整路徑 latency；
• 帶 checkpoint／日誌之後的磁碟佔用與寫入放大；
• 如可取得，功率與能耗，並明示量測來源及誤差。

這些度量應與相同視覺品質、世界規則、NPC 活性要求、資料量及硬體條件配對。不能以 GPU 使用率變低就宣稱世界算得更精確，或以 CPU 使用率降低就宣稱 frame time 必然改善。

18.5 預期「改善」也要定義受測邊界

至少事先註明：

• 哪些事件及狀態應 bitwise 一致，哪些只要求語義等價；
• 哪些玩家可觀察結果允許延遲或暫時未知；
• 哪些資產、身份、庫存及期限不得近似；
• 哪些資料對規則版本敏感；
• 哪些模擬尺度可以近似，允許誤差如何累積；
• 哪些資源使用量是 driver estimate，哪些可直接量測；
• 哪個負載區間 CWSR 值得啟用，哪個區間退回成熟 baseline。

18.6 重現性

保留引擎版本、OS、CPU／GPU 型號、GPU driver、VRAM/RAM 容量、渲染設定、編譯器／Rust 工具鏈、遊戲模組、資料集 hash、世界 seed、PRNG 模式、快取初始狀態與量測腳本。若無法用完全相同的隨機序列比較，須以多 seed 的統計等價與規則不變量補充。

在 Paper 07／08 尚未執行前，本篇沒有任何可宣稱已量測通過的改善百分比。

19. 必須正視的反例與失敗條件

19.1 反例 R04-A：所有資料都很熱

若幾乎全部世界物件每個更新窗口都被隨機訪問，壓縮、索引與跨層換頁的成本可能大幅超越收益。此時可以採連續陣列、既有 ECS 與固定 memory pool，不必啟用全套選擇性物化。

19.2 反例 R04-B：唯一資料誤判可重建

角色已完成不可逆對話、玩家進行選擇，但資料只有 RAM 中一份。因為一個錯誤 rebuildable 標籤而刪除它，即使節省了記憶體，世界正確性亦告失敗。此錯誤應讓 recovery validation 或硬 gate 直接阻擋。

19.3 反例 R04-C：預載汙染 render budget

系統預測玩家將進入大型城市，提早把大量 world buffer 搬入 GPU，結果渲染 texture 無法準時載入或 frame time p99 顯著上升。即使世界 kernel 更快，此預載策略仍可能對玩家不利。

19.4 反例 R04-D：硬體預算快照過期

遊戲開始時 VRAM 顯示充裕，之後 OS／driver／背景應用使可用量下降。若 Runtime 把啟動時容量當永久權利，則靜態 hard limit 不能保證不超過當下真實容量。需採保守 guard、週期性觀測與 failure-aware admission。

19.5 反例 R04-E：GPU Buffer 被過早覆寫

工作 A 的 GPU dispatch 還在讀取 staging ring 第 3 頁，CPU 將它發給工作 B 重寫。即使 Rust CPU 端引用看似合法，裝置側仍可能 data race。Fence 與裝置同步不可由 Rust lifetime 自動推出。

19.6 反例 R04-F：依賴版本已變而快取未失效

世界已提交一筆經濟交易，某個價格快取仍存在 RAM 且 hash 與舊值相同；因依賴版本不完整而直接使用，可能導致劇情條件錯誤。需重新驗證 Rule-Causal Dependency，不允許 resident status 替代 valid status。

19.7 反例 R04-G：時鐘義務被資料釋放一併刪除

NPC 細節回收時誤刪下次薪資日、商隊到達時間或城鎮疫情事件。玩家不在現場仍應發生的規則事件因而消失。這是 Paper 02 語義違反，不得被記為正常的「休眠節省」。

19.8 反例 R04-H：細化變成新歷史

系統用統計人口摘要在玩家到訪時生成一名 NPC，卻將其虛構背景偽稱過去十年逐步實際演化的世界事件，並覆蓋與既有具名角色的關係。這違反 Paper 03 的 Anchor First 與 Refinement 範圍。

19.9 反例 R04-I：總駐留量降低但卡頓增加

RAM 從 3 GB 降到 1.5 GB，卻頻繁從 SSD 重載，使角色移動時互動延遲與 p99 幀時間顯著增加。若研究目標是更好的單機遊戲性能，不得只用記憶體占用減半宣稱成功。

19.10 反例 R04-J：規則熱更新使 Recovery Plan 失效

Mod 改變物品欄位／腳本版次，舊 cache 仍可解碼但新的世界規則已改。若沒有 schema／rule version 檢查，資料可能在不崩潰的情況下造成隱蔽錯誤。須失效、遷移或拒絕，不能靜默強行沿用。

19.11 反例 R04-K：回收治理比計算本身還慢

為一個少量固定的數值更新建立每 scalar 的存取租約、時間證書和回收清單，metadata 高於資料本身。系統應能關閉精細追蹤，選擇更粗顆粒、固定池或原引擎成熟機制。

19.12 反例 R04-L：恢復與存檔成為 I/O 寫入放大器

為了證明任何 state 隨時可回復，每次簡單移動都寫入大量完整快照。即使 RAM 更少，SSD 壓力與恢復耗時亦可能不可接受。應比較 snapshot interval、delta、event journal、壓縮及故障風險，不能假設 durable source 免費。

19.13 反例 R04-M：壓力處理犧牲世界權威

當容量不足時，系統為了讓畫面保持 60 FPS，默默丟棄未提交但不可重複的玩家操作，或跳過不可容許省略的世界事件。此方案即使效能大幅改善，也不是 CWSR 語義下的合法候選。

19.14 反例 R04-N：同一實體配置被多次扣預算

共用只讀 buffer 同時被世界模擬與渲染引用；若各 Region 都按全部 bytes 重複計數，系統可能不合理地拒絕有效工作。反之，不計入實際底層複製則可能低估容量。需維護物理實體／共享所有者的唯一計量。

20. 最小工程實作路線與正式交接

20.1 第一個原型先不碰全世界

Paper 07 最小實作應先建立：

1. World Descriptor Store： StateRef、版本、來源、時間與必要依賴；
2. Region Allocator Adapter： CPU RAM 的 bounded allocation 與 generation handle；
3. Replica Table： 哪個 StateRef 在何處有哪個版本副本；
4. Wake／Obligation Adapter： 接 Paper 02 的事件與期限責任；
5. Scale Adapter： 接 Paper 03 的 anchor／summary／detail 與 ledger；
6. Recovery Plan Executor： checkpoint／journal 或可驗證的純計算重建；
7. Eviction Gate： lease、fence、rebuild、durability、期限檢查；
8. Commit Gate Bridge： 候選與 canonical state 嚴格分離；
9. Telemetry Recorder： 容量、配置、回收、重建與錯誤的可回放紀錄。

先在 RAM 模擬兩個 tier 的搬移策略，驗證模型安全後，再加入實際 GPU 後端；否則一開始便把模型錯誤與 GPU 同步錯誤混在一起，很難定位問題。

20.2 三個連續工程里程碑

M1 — Memory Contract Core： 預宣告區域、容量約束、版本引用、generation handle、借用／釋放、拒絕策略及 typed failures。最低交付為單元測試可檢測 stale handle、hard limit 與唯一副本安全。

M2 — State Residency / Recovery： 以兩城市／具名 NPC／橋樑為固定 world fixture，驗證 checkpoint、journal、世界期限與跨尺度資料恢復。最低交付為多次卸載／重載後語義一致及 fault injection 記錄。

M3 — GPU Residency Adapter： 只挑選可以實際用 GPU 運行的批次世界資料，量測 staging、copy、fence、resident buffer、render contention，並保證 candidate/commit 隔離。最低交付是與純 CPU 同等規則的可重現比較。

以上是工作規格，不是當前實作狀態。

20.3 Paper 05 的直接輸入

本篇交給 Paper 05：

• typed StateRef、ReplicaRef 及 generation；
• CPU／GPU tier 與容量、保留、lease、fence 契約；
• 可被合批的同類資料 layout 候選；
• buffer read/write、input revision、candidate output 與 commit 權限；
• 預載、保留、搬移、重建的成本模型與收縮策略；
• 渲染保留預算、pressure feedback 與 device loss；
• 不允許未驗證 GPU 輸出改寫世界的硬性界線。

Paper 05 必須自行解決 Compute Shader／CUDA／Vulkan 等後端的 kernel 型態、dispatch 批次、非同步同步與設備選擇；本篇不能替它宣稱 GPU 已經加速。

20.4 Paper 06 的直接輸入

Paper 06 可以將此處的硬體／記憶體約束作為計算 24／72 形態路由的 resource vector，但不得將 24／72 格直接解釋為特定 RAM／VRAM 佈局。Runtime 必須先檢查安全與容量，再在候選計算形態中選擇具體執行方案。

20.5 Paper 07 的實作責任

Paper 07 才是編譯、可執行原型、裝置同步 API、Godot／EveWorld adapter、測試治具、故障注入、生成檔案與打包測試的責任篇。它要以實作結果判定本篇草案是否需修訂。

20.6 Paper 08 的證偽責任

Paper 08 要拿成熟 streaming／memory allocator／ECS／event-driven 基線比較，不可只對不最佳化的 B0。須公開結果中符合與不符合假說的情境，包含 p99 frame latency、VRAM 壓力、世界義務漏失率、恢復時間、CPU 開銷與資料重建成本。

20.7 不應提早延伸出新的獨立母理論

CWSR 原則上以 Paper 00–08 九篇形成第一輪閉環。本篇的記憶體契約是局部世界執行的工程延伸，不單憑術語命名就成立新的記憶體本體論。若後續發現不適用現有 GCCF／GCM 定義的新反例，可回報上游研究，但不應預設每次工程補強都需要另立一篇母論文。

21. 研究原稿與成熟背景來源

21.1 CWSR 直接前篇（本篇已核對原始 UTF-8 Markdown）

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。

21.2 EveMissLab 上游研究（繼承，不重寫原義）

5. Neo.K × Aletheia，GCCF 04｜全域可尋址狀態：大內存之外的選擇性物化模型，v0.1，2026-09-22。GCCF_04_Globally_Addressable_State_and_Selective_Materialization_v0.1_zh-TW.md。
6. Neo.K × Aletheia，GCCF 05｜因果流計算與預記載：面向未來需求的分散式執行，v0.1，2026-09-22。GCCF_05_Causal_Flow_and_Predictive_Preloading_v0.1_zh-TW.md。
7. Neo.K × Aletheia，GCCWT Paper 04｜計算場與資源激發：跨 CPU／GPU／Memory／Agent 的動態執行域，Draft v0.2。GCCWT_Paper04_Draft_v0.2.md。
8. Neo.K × Aletheia，GCCWT Paper 06｜AI 原生全域調度：從 Task Scheduler 到 World Computation Planner，Draft v0.2。GCCWT_Paper06_Draft_v0.2.md。
9. EveMissLab，GCM Phase B：Deterministic Compute Allocator 技術白皮書，v0.1，2026-08-27。GCM Phase B：Deterministic Compute Allocator 技術白皮書 v0.1.md。
10. Neo.K × Aletheia，全域計算方法論：異質計算的全域一致組合，v0.1，2026-08-23。01_全域計算方法論_異質計算的全域一致組合_v0.1.md。
11. Neo.K × Aletheia，《從有序計算到全域耦合計算》統合母論文，v0.1，2026-09-22。Global_Coupled_Computation_Integration_Mother_Paper_v0.1_2026-09-22.md。
12. Neo.K，《計算的二十四重範式》，v4.0，2026-07-19；及 Neo.K × Aletheia，《從二十四重計算形態學到七十二格計算動力學》，v0.1，2026-07-19。本篇不重定義此分類。

以上為本篇實際取用的研究系列原稿來源，不代表外部同儕審查或實驗證成。正式投稿前須按作者審定版次與公開來源另行補齊可核實書目。

21.3 成熟外部工程概念（不歸為 CWSR 原創）

本篇參照的常見工程構造與比較基礎，包括 Rust Ownership／Borrowing／Lifetime、allocators／arenas／pools、virtual memory、paging、LRU／LFU、copy-on-write、reference counting、generational handle、checkpoint／event sourcing、MVCC、cache coherence、GPU command queue 與 timeline synchronization、DMA／staging buffer、GPU device loss recovery、simulation LOD 及 ECS 資料布局。

這一節列出技術類別供後續比對，不偽造任何未實際查閱的外部論文條目；若對特定演算法主張做外部學術引用，應在下一輪文獻驗證後補入可信來源。

22. 結論

CWSR Paper 04 的核心不是「把記憶體用量壓得愈低愈好」，而是建立邏輯世界、計算需求與實體駐留之間具備合法性、容量、版本、時間、恢復及授權責任的映射。

靜態與動態不應只是兩個互斥記憶體池名稱：資料可以在語義上不變，卻在資源上可回收；資料可以經常變動，卻長時間穩定駐留；某副本可以仍在 RAM，卻因依賴版本改變而不可使用；某世界事實可以不在 RAM，卻因存在經驗證的可恢復來源而繼續有效。這些維度必須分離，才能避免一個表面上高效的系統在背後遺失世界。

預宣告動靜態資源區提供的是容量與生命週期的顯式契約，不是要求預先佔據全部實體空間。可尋址世界允許按需物化，但只有滿足恢復來源、因果義務、時間切面、授權與同步要求的回收才是合法的。GPU 可以保留、處理甚至更新大量世界計算候選；不過裝置側運算完成不等於權威提交，VRAM 的可見剩餘量也不等於任何時刻可任意借走的資源。

因此，本篇的工作性總結可以表達為：

也可以將核心工程責任濃縮為：

全域可尋址、局部有據駐留；可重用則保留，有證據才回收；有限硬體預算不應透過遺失世界因果來取得性能。

此規格尚待 Paper 07 的可執行實驗與 Paper 08 的對照實測。若某些負載使用成熟 LRU／pool／streaming 已更快、更穩定，本篇應承認並縮小 CWSR 的適用域；這不影響其作為一套可測試工程研究問題的價值。

下一篇：CWSR Paper 05｜CPU／GPU 異質世界計算與因果小流。 它承接本篇的版本化資料、設備存放、預算、buffer lifetime 與 candidate／commit 邊界，進一步回答哪些世界狀態工作應當交給消費級 GPU、如何形成有效的小流批次，以及如何避免渲染競爭與重複記憶體搬移。

版本紀錄

• v0.1（2026-10-16）： 建立單機開放世界的動靜態 Memory Region Contract、StateRef／ReplicaRef／Residency Contract、RAM／VRAM 硬預算與壓力治理、安全回收與重建、Rust 概念接口、跨尺度資料安置、GPU 駐留邊界、條件命題、M04 測試矩陣及 Paper 05–08 交接。
• 源檔規則： 本 Markdown 是 canonical UTF-8 source artifact；數學原始碼只採 $...$ 與 $$...$$；聊天呈現或轉成其他格式的結果不得逆向取代本檔。
• 驗證聲明界線： 本篇原稿文字與格式可以進行靜態驗證；工程假說與程式片段仍須獨立實作及實機測試，不因文件格式通過而自動成立。

End of CWSR Paper 04 v0.1