---
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 的嚴格關係

| 來源 | 既有責任 | Paper 04 的新操作性責任 |
|---|---|---|
| Paper 00 | 不把世界存在等同運行；資源與效能研究邊界 | 明確定義動靜態區、預算、駐留成本 |
| Paper 01 | State Descriptor；Identity／Version；Candidate／Canonical | 把邏輯描述符映射到可替換的物理副本 |
| Paper 02 | Wake Ticket；Dormancy Certificate；期限、事件與漏喚醒控制 | 回收不得破壞訂閱、喚醒及任何未履行義務 |
| Paper 03 | Scale View；Anchor；Aggregation／Refinement；Ledger | 不同尺度所需資料可以分層駐留或合法重建 |
| GCCF 04 | Exists／Addressable／Recoverable／Materialized／Observed／Pinned 分離 | 單機 RAM／VRAM 與遊戲存讀檔的局部具體化 |
| GCCWT Paper 04 | Memory Region；Resource Excitation；Data／State Gravity | 擬定單機資源與 GPU 移動的最低契約 |
| GCM Phase B | Capacity-Constrained Allocation；多目標規劃 | 把容量檢查轉譯為本機配額與保守後退 |

**不變原則：** 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 R_t\subseteq\bigcup_{n\in\mathcal N_t}\mathrm{Copies}_n(\mathcal S_t).
$$

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

可能有：

$$
|\mathcal R_t|\ll |\mathcal S_t|,
$$

但此比較僅適合量測已定義世界狀態；不應拿未定義、未實例化的可能內容偽裝成已存在的一兆個 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$，沿用：

$$
\mathrm{sid}(s)=(world,domain,entity,field).
$$

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

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

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

$$
\mathrm{PhysicalLocation}=(\mathrm{device},\mathrm{heap},\mathrm{offset},\mathrm{allocation\_generation}).
$$

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

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

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

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

$$
\mathrm{Valid}(s,t)\not\Leftrightarrow\mathrm{Resident}(s,n,t).
$$

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

---

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

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

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

| 維度 | 候選值 | 要回答的問題 |
|---|---|---|
| Mutability | Immutable／Mutable／Versioned | 誰能變更內容，變更是否生成新版本？ |
| Retention | Durable／Checkpointed／Rebuildable／Ephemeral | 撤銷唯一物理副本後還能恢復嗎？ |
| Residency | Pinned／Warm／Cold／Streaming／Transient | 何時應保留，是否允許被驅逐？ |
| Allocation | Fixed／Reserved-Capacity／Bounded-Growth／Borrowable | 區域用量怎麼成長，何時拒絕？ |
| Access | Exclusive-Write／Shared-Read／Snapshot／Device-Restricted | 什麼權限及同步允許讀寫？ |

另外，狀態具有 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、冷資料回收，以及規則容許的解析度降低。

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

$$
\forall t,\quad \mathrm{ResidentBytes}(t)<\infty.
$$

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

## 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 等成熟技術實現。

定義最低工作性記錄：

$$
M_r=\langle id,tier,class,owner,B_{soft},B_{hard},B_{guard},growth,evict,recover,telemetry\rangle.
$$

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

## 3.2 建議的區域類別

| Region | 典型內容 | 預設保留策略 | 回收前須檢查 |
|---|---|---|---|
| `core-static` | schema、規則索引、必要 metadata | 版本期間保留 | rule/schema revision、Mod |
| `world-anchors` | 具名 NPC、已提交任務、身份定位 | Durable／Protected | 唯一副本、checkpoint、ledger |
| `event-obligations` | 未完成事件、期限、Wake Ticket、journal cursor | Protected | 已履行與持久化證據 |
| `scale-summaries` | 城市級人口、資源、價格摘要 | Warm／Rebuildable-when-proven | 版本、守恆、依賴、時間切面 |
| `active-details` | 玩家附近 NPC、交互與物理資料 | Bounded Growth | 未完成寫入、期限、觀察需求 |
| `derived-cache` | 派生值、尋路結果、UI 數值 | Evictable | 原始依賴、重算能力 |
| `gpu-world-buffers` | 批次世界狀態與中間結果 | Explicit Device Contract | GPU fence、版本、候選／權威分離 |
| `render-working` | 影格 texture／buffer | Render-Reserved | Frame in flight、swapchain 規則 |
| `transfer-staging` | CPU／GPU upload、readback、I/O | Recyclable | DMA 完成、同步、generation |
| `scratch-temporary` | 排序、壓縮、工作 scratch | Epoch-Bounded | 作用中借用與未完結工作 |
| `save-checkpoints` | 存檔、snapshot、manifest、journal | Durable Storage | durable flush、校驗、世代切換 |

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

## 3.3 預宣告範例

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

```yaml
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 的物件、可恢復性、回收成本、預測重用、已提交歷史與資料依賴。

```text
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$，定義：

$$
R(s^{(k)},n)=\langle rid,ref,n,bytes,gen,dirty,epoch,lease,fence,freshness,policy\rangle.
$$

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

| 欄位 | 作用 |
|---|---|
| `rid` | 本物理副本的不可混淆身份 |
| `ref` | 對應已提交／候選世界 StateRef，含 revision 和 schema |
| `n` | RAM／VRAM／Storage／staging 等層及設備 ID |
| `bytes` | 容量、對齊與實際計數大小 |
| `gen` | 配置世代，防止 offset 重用誤認同一份資料 |
| `dirty` | 是否有尚未經持久化或可恢復途徑處理的變動 |
| `epoch` | 建立時的資料／世界／執行 epoch |
| `lease` | 是否有合法使用者阻止暫時回收 |
| `fence` | GPU／I/O 非同步工作完成責任 |
| `freshness` | 與權威修訂、依賴、時間窗口的一致性 |
| `policy` | 存取許可、保留等級與恢復政策版本 |

欄位不必同樣放入所有 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。

```text
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(t)+Q_n(t)+G_n(t)\le B_n(t).
$$

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

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

## 5.2 軟目標與硬限制

定義每個區域：

$$
0\le B_r^{soft}\le B_r^{hard}.
$$

超過 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 記憶體壓力分級

閾值須以硬體實測決定：

| 壓力級別 | 性質 | 合法候選處置 |
|---|---|---|
| Normal | soft 目標內或具充分 margin | 保留熱集、容許低成本預熱 |
| Pressure | 接近 hard 或出現延遲風險 | 停止投機預載、縮短 cache lease、回收已驗證冷集 |
| Critical | 可能違反硬資源或世界期限 | 拒絕可選工作、降級合法尺度、保留提交及恢復義務，必要時停機報錯 |

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

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

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

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

```text
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$，定義一個契約物件：

$$
C_R(s,q,I)=\langle ref,needs,tier,deadline,precision,keep,recover,authority,evidence\rangle.
$$

其作用不是替代 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$，工作性的可回收判定可寫成：

$$
\mathrm{CanEvict}(r,t)=\mathrm{Unused}(r,t)\land\mathrm{FenceDone}(r,t)\land\mathrm{RecoverableOrRedundant}(r,t)\land\mathrm{DutiesPreserved}(r,t)\land\mathrm{PolicyAllows}(r,t).
$$

其中 `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

定義最小回收證據：

$$
E_r=\langle rid,ref,gen,epoch,recovery,leases,fences,duties,ledger,decision\rangle.
$$

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

```text
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、是否涉及觀察結果、執行期限及出錯後如何回退。

```yaml
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 中正確反映。

可工作性要求：

$$
K_{total}=K_{aggregate\_residual}+K_{materialized\_detail},
$$

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

## 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 傳輸成本不可省略

候選計算路徑至少包含：

$$
T_{gpu\_path}=T_{prepare}+T_{upload}+T_{dispatch}+T_{kernel}+T_{sync}+T_{readback}+T_{verify}+T_{commit}.
$$

並非每個 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 候選路由與決策順序

本篇建議的最小順序：

```text
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 的失敗是正常結果

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

```text
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}$ 為違反期限可能造成的代價。

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

$$
C_{total}=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_{keep}(s,H)=C_{holding}(s,H)+C_{pressure}(s,H),
$$

$$
J_{evict}(s,H)=C_{evict}(s)+\mathbb E[C_{next\_materialize}(s,H)]+C_{risk}(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 用量外，需區分：

$$
M_{peak}=\sup_{t\in I} M_{used}(t),
$$

以及可比較的 `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**，其功能是顯示記憶體分配、租約、世界修訂及重新建構間應存在的資料邊界。

```rust
// 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 的概念程序

```text
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 安全回收的概念程序

```text
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 分權

| 操作 | 允許的責任主體 | 不可偷渡的權力 |
|---|---|---|
| 為合法 StateRef 找可用副本 | Memory Manager／State Resolver | 不可創建新已提交世界事實 |
| 分配、複製、壓縮、回收 | Allocator／Residency Controller | 不可自行消除任務或期限 |
| 產生計算候選 | CPU／GPU Executor | 不可直接修改 canonical world |
| 驗證世界修訂 | Commit Gate | 不可忽視依賴及跨尺度帳本 |
| 提供觀察投影 | Observer／Renderer | 不可將畫面效果當世界提交 |
| 預測未來熱資料 | Predictor／GCCF Hint Adapter | 不可覆蓋 hard budget／safety 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 對照組不可只選最差實作

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

| Baseline | 方法 | 用途 |
|---|---|---|
| B0 | 天真常駐／無條件建立所有詳細資料 | 只作為問題顯示及下界比較，不能單獨證明 CWSR 優勢 |
| B1 | 成熟引擎常見 streaming、LRU、texture／asset manager | 公平檢驗是否優於既有記憶體管理 |
| B2 | 預分配 pool／arena、ECS 稀疏資料與成熟存檔流程 | 評估新增契約所付出的治理成本 |
| B3 | 既有事件驅動＋多尺度 Summary＋安全 checkpoint／cache | 檢驗 CWSR 的整合責任是否有額外價值 |
| CWSR-04 | 多維資源契約、版本化副本、因果／期限感知駐留 | 本篇的候選架構，須在 Paper 07/08 實現後實測 |

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

## 18.2 測試工作負載

| 測試代號 | 工作負載 | 要觀察的主要問題 |
|---|---|---|
| M04-01 | 一千至大量具名／非具名 NPC，反覆進出視線 | Anchor 留存、細節回收、身份一致性 |
| M04-02 | 城市遠近切換、頻繁快速旅行 | Cache churn、預熱浪費、p99 互動延遲 |
| M04-03 | 橋樑斷裂與多城市供應鏈傳播 | 因果失效、跨尺度 ledger、summary 存放 |
| M04-04 | 長時間選單／靜止畫面，世界時間持續 | 期限未漏、冷熱集改變、CPU/RAM 壓力 |
| M04-05 | 玩家存讀檔、checkpoint、意外中止 | Durability、唯一事實、不重播副作用 |
| M04-06 | GPU 世界 compute 與高畫質渲染同時運作 | VRAM 預算、render p99、fence 正確性 |
| M04-07 | 人為收縮可用 RAM／VRAM 預算 | Admission、保守後退、OOM 防護 |
| M04-08 | 大量相同 StateRef 的讀取與多版本寫入 | Shared replica、COW、generation、race |
| M04-09 | Mod 熱更新、schema 修改、規則重編譯 | 快取失效、不可重建判定、舊版兼容性 |
| M04-10 | 隨機生成世界、切換算法或 PRNG 版本 | Rebuildability 證據、錯誤回放偵測 |
| M04-11 | 高頻細碎工作，近乎全量資料常用 | 細粒度契約超額開銷、承認失敗情境 |
| M04-12 | GPU device loss／工作取消／staging 回收 | Candidate 失效、Fence、typed recovery |
| M04-13 | 硬預算被其他進程擠壓 | 動態 $B_n(t)$ 、安全餘裕及退化策略 |
| M04-14 | 冷資料只剩唯一未持久化副本 | Eviction Certificate 必須拒絕回收 |
| M04-15 | 訂閱註冊與釋放同時競爭 | 防止 lease／generation 競態與漏喚醒 |
| M04-16 | 長時間運行與反覆開關地圖 | Heap 碎片、配置抖動、記憶體洩漏 |

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

## 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 的可見剩餘量也不等於任何時刻可任意借走的資源。

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

$$
\mathrm{WorldState}\neq\mathrm{ResidentMemory}\neq\mathrm{RunningComputation}\neq\mathrm{CommittedMutation}.
$$

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

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

此規格尚待 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**