從靜態檔案到生成資料生命週期

論現代應用程式的可移除性標記、風險轉嫁與作業系統資料治理

作者：Neo.K
版本：v1.0 概念論文／系統設計命題稿 日期：2026 年 7 月

摘要

現代應用程式早已不再只是「讀取檔案—執行程式—輸出結果」的簡單系統。編譯器、瀏覽器、開發工具、遊戲引擎、套件管理器、AI 應用、本機模型、代理系統與多媒體軟體，會持續生成大量快取、索引、中間表示、編譯產物、更新包、回復快照、模型權重、服務工作者資料、崩潰傾印、暫存工作區、推理快取與其他衍生物。然而，現代檔案系統與多數應用程式仍主要以「檔案存在」為核心管理單位，缺乏對資料之生成來源、依賴關係、可重建性、可移除性、重建成本、保留期限與任務完成狀態的明確描述。

本文提出一個核心命題：凡由應用程式自動生成之資料，資料生成者原則上應負責聲明其生命週期與可移除性，而不應將判斷成本與刪除風險轉嫁給使用者。 本文進一步區分使用者原始資料、不可重建資料、可重建資料、可重新下載資料、任務中間產物、效能快取、歷史回復資料、診斷資料、更新殘留與孤兒資料，並提出「生成資料生命週期宣告」與「衍生資料回收區」之系統架構。

本文主張，當代軟體已進入「大量生成資料時代」，但作業系統仍停留在「靜態檔案時代」。真正需要被管理的，已不只是檔案，而是資料之生成關係、資訊價值、可再生性與刪除後果。若此問題未被處理，AI 與 Agent 時代將使個人電腦、工作站與雲端環境逐步演化為不可理解的資料考古遺址。

關鍵詞

生成資料、資料生命週期、可移除性、可重建性、檔案系統、應用程式責任、快取治理、衍生資料、作業系統、AI Agent、資料本體論

1. 問題的起點：為何刪除 C 槽資料像拆炸彈？

對許多使用者而言，作業系統碟是一個特殊區域。

使用者可能知道：

有些檔案可以刪；
有些快取刪除後只會重建；
有些資料刪除後只是重新下載；
有些資料一旦刪除，程式會損壞；
有些資料若被誤刪，甚至可能導致作業系統無法正常啟動。

這導致一個極為現實的使用者行為：

在作業系統區，不確定的東西就不敢刪。

這不是無知，而是合理的風險規避。

尤其對曾經因誤刪系統檔案而造成無法開機、被迫重灌作業系統的使用者而言，C 槽中的未知資料夾不只是「雜亂」，而是一種實際風險。此後每一次清理，都必須面臨同一個問題：

這個 5 GB 的資料夾到底是什麼？
它能不能刪？
刪了只是變慢，還是程式損壞？
刪了只是重新下載，還是永久遺失？
這是使用者資料，還是可重建產物？
這是系統依賴，還是更新殘留？

而現代應用程式往往沒有回答。

這構成本文的第一個基本問題：

應用程式知道資料是如何生成的，為何使用者卻必須自己猜哪些資料可以刪？

2. 現代應用程式已不是「程式＋檔案」

早期的軟體直覺相對簡單：

程式
├── 執行檔
├── 設定檔
└── 使用者文件

但現代應用程式的資料鏈更接近：

原始輸入
↓
解析結果
↓
中間表示
↓
索引
↓
快取
↓
編譯產物
↓
增量編譯資料
↓
模型下載
↓
模型轉換
↓
預處理結果
↓
縮圖
↓
Shader Cache
↓
Checkpoint
↓
Workspace Snapshot
↓
Crash Dump
↓
Update Package
↓
Rollback Package
↓
Service Worker Cache
↓
Telemetry Buffer
↓
Temporary Corpus
↓
Vector Index
↓
Inference Cache
↓
未知殘留

這裡的核心變化是：

現代軟體會大量生成「不是原始資料，但又長期存在」的資料。

其問題不在於生成本身。

很多資料確實能提升：

效能；
回復能力；
穩定性；
離線使用；
編譯速度；
模型載入速度；
網頁回應速度；
推理效率；
使用體驗。

真正的問題是：

生成之後，應用程式往往不再向使用者解釋這些資料的狀態。

3. 核心命題：資料生成者應負責聲明資料生命週期

本文提出第一核心命題。

命題 1：生成者生命週期責任命題

設應用程式 (A) 生成資料物件 (d)，則在合理可行範圍內，(A) 應聲明：

L(d)= \langle o,r,x,c,t,p,s \rangle

其中：

(o)：Origin，生成來源；
(r)：Reconstructability，可重建性；
(x)：Removability，可移除性；
(c)：Reconstruction Cost，重建成本；
(t)：Retention，建議保留時間；
(p)：Dependency，依賴關係；
(s)：State，當前生命週期狀態。

換句話說，對一個由應用程式生成的資料而言，至少應能回答：

誰生成我？
我由什麼生成？
我能否重建？
刪除我會損失資訊，還是只損失時間？
我是否仍被使用？
誰依賴我？
我的任務是否已完成？
我應保留多久？
我是否已成為孤兒資料？

4. 問題的本質不是垃圾，而是資訊不對稱

傳統磁碟清理將問題理解為：

「垃圾太多。」

但本文認為更精確的問題是：

資料生成者與資料承擔者之間存在資訊不對稱。

應用程式知道：

這是快取。
這是更新殘留。
這是模型下載。
這是可重建索引。
這是已完成任務的中間產物。
這是失效工作區的孤兒資料。

使用者只看到：

C:\Users\...\AppData\Local\...
C:\ProgramData\...
.cache
.workspace
.models
.blobs
objects
packages
artifacts
snapshots
storage
CacheStorage
GPUCache
Code Cache

於是產生極不對稱的責任結構：

K_A(d) > K_U(d)

其中：

(K_A(d))：應用程式對資料 (d) 的生成知識；
(K_U(d))：使用者對資料 (d) 的生成知識。

通常：

K_A(d) \gg K_U(d)

然而刪除決策卻由使用者承擔：

R_U(d) \approx 1

其中 (R_U(d)) 表示使用者承擔主要風險。

因此形成矛盾：

K_A(d) \gg K_U(d) \quad \land \quad R_U(d) \gg R_A(d)

即：

知道最多的人不負責判斷，知道最少的人承擔刪除風險。

這是本文所稱的：

資料刪除風險轉嫁

5. 為何「事情做完就標示可移除」不是困難問題？

本文不主張所有生成資料都要立即刪除。

真正需要的是：

狀態聲明。

例如某工作完成後，應用程式可以把資料標記為：

ACTIVE

表示仍在使用。

任務完成後改為：

RECONSTRUCTABLE

若不再被引用：

DISPOSABLE

若來源專案已不存在：

ORPHANED

若超過保留期限：

EXPIRED

因此可定義生命週期狀態集合：

S_d \in { \text{ACTIVE}, \text{RETAINED}, \text{RECONSTRUCTABLE}, \text{DISPOSABLE}, \text{ORPHANED}, \text{EXPIRED}, \text{UNKNOWN} }

這並不要求作業系統理解所有應用程式內部邏輯。

只要求：

生成者告知系統。

6. 生成資料的基本分類

本文提出以下最低限度分類。

6.1 使用者原始資料

例如：

原始碼；
文稿；
圖像原件；
影片原件；
使用者手動建立之專案；
使用者匯入之壓縮檔。

特徵：

R(d)=0

即不可由系統可靠重建。

原則：

禁止自動刪除。

6.2 不可重建資料

某些資料未必由使用者直接建立，但一旦遺失即無法恢復。

例如：

未同步之工作狀態；
唯一 checkpoint；
未提交之本機資料；
未備份之臨時錄音；
某些一次性擷取結果。

此類資料應被明確標為：

NON_RECONSTRUCTABLE

6.3 可重建資料

例如：

索引；
某些 build artifacts；
可重新生成縮圖；
向量索引；
編譯中間結果。

特徵：

R(d)=1

但重建成本可能不同。

因此：

C_r(d) \in [0,\infty)

不能只標「可刪」，還應標示重建成本。

6.4 可重新下載資料

例如：

模型權重；
套件快取；
遊戲資源快取；
已知來源的安裝包。

此類資料不一定可由本機重建，但可從遠端重新取得。

因此可定義：

D(d)=1

其中 (D(d)) 表示可重新下載。

6.5 任務中間產物

例如：

轉檔中間檔；
編譯暫存；
解析快取；
臨時語料；
AI 前處理產物。

其生命週期應與任務綁定：

d \rightarrow T

當：

State(T)=Completed

且不存在後續依賴時：

State(d)\rightarrow Disposable

6.6 效能快取

例如：

Shader Cache；
Browser Cache；
GPU Cache；
Code Cache；
推理快取。

其本質是：

用空間交換時間。

因此應明確顯示：

刪除後果：效能暫時下降，資料可自動重建。

6.7 歷史回復資料

例如：

Undo Snapshot；
Autosave；
Rollback；
Recovery Copy。

此類資料不能簡單視為垃圾。

但應有期限：

T_{expire}(d)

例如：

保留 7 天；
保留 30 天；
保留最近 10 個版本。

6.8 診斷資料

例如：

Crash Dump；
Log；
Trace；
Debug Symbol Cache。

應預設有衰減與過期機制。

6.9 更新殘留

例如：

舊 installer；
patch package；
rollback artifact；
OTA artifact。

應在系統穩定後轉為：

DISPOSABLE_AFTER_STABILITY_WINDOW

6.10 孤兒資料

孤兒資料定義為：

Parent(d)=\varnothing

或：

Reference(d)=0

例如：

原專案已刪除；
原版本已卸載；
原任務已不存在；
原模型已替換；
原 workspace 已失效。

這類資料應成為高優先提醒對象。

7. 靜態檔案系統的本體論不足

現代檔案系統通常關心：

檔名
大小
建立時間
修改時間
存取權限
擁有者
路徑

但在大量生成資料時代，更重要的是：

生成者
來源
可重建性
可重新下載性
依賴關係
重建成本
任務狀態
保留期限
最後必要時間
刪除後果

因此本文提出：

現代檔案系統缺少生成關係。

傳統檔案系統回答：

「這個檔案在哪裡？」

未來資料治理系統還必須回答：

「這個檔案為什麼存在？」

這是兩個完全不同的問題。

8. 從檔案本體轉向生成關係本體

設原始資料為 (S)，衍生產物為：

S \rightarrow A_1 \rightarrow A_2 \rightarrow A_3 \rightarrow A_4

其中：

$A_1$ ：解析產物；
$A_2$ ：編譯中間結果；
$A_3$ ：最佳化結果；
$A_4$ ：執行快取。

若每一層皆可由上游重建，則：

A_i = f_i(A_{i-1})

在理論上：

I(A_i) < I(S)

這裡的 (I) 不是檔案大小，而是「不可替代資訊價值」。

因此：

兩個同為 5 GB 的檔案，其保存價值可能完全不同。

例如：

5 GB 唯一研究資料；
5 GB 可重新下載模型；
5 GB Shader Cache；
5 GB 更新殘留。

檔案系統只看到：

Size=5GB

但使用者真正需要的是：

Value(d), Rebuild(d), Risk(d)

9. 可移除性不是二元問題

資料不應只有：

可刪
不可刪

而應存在光譜。

定義可移除性：

M(d)\in[0,1]

其中：

(M(d)=0)：不可移除；
(M(d)=1)：完全可安全移除。

可進一步定義：

M(d)= F(R,D,P,C,T)

其中：

(R)：可重建性；
(D)：可重新下載性；
(P)：依賴程度；
(C)：重建成本；
(T)：時間敏感度。

例如：

使用者唯一原稿

M(d)\approx0

Shader Cache

M(d)\approx1

可重新下載 20 GB 模型

M(d)\approx0.8

因為可移除，但重新下載成本高。

最近 24 小時 Autosave

M(d)\approx0.2

90 天前 Crash Dump

M(d)\approx0.95

10. 提案一：Application Data Lifecycle Manifest

本文提出：

Application Data Lifecycle Manifest

應用資料生命週期清單

每個應用程式應聲明其資料類型。

例如：

application: ExampleApp
version: 3.4

data_classes:
  - id: user_project
    category: USER_OWNED
    removable: false
    reconstructable: false

  - id: shader_cache
    category: PERFORMANCE_CACHE
    removable: true
    reconstructable: true
    rebuild_cost: low

  - id: local_model
    category: REDOWNLOADABLE
    removable: true
    redownloadable: true
    download_size: 4GB

  - id: old_update
    category: UPDATE_RESIDUE
    removable_after: 14d

  - id: crash_dump
    category: DIAGNOSTIC
    retention: 30d

11. 提案二：衍生資料回收區

本文區分：

傳統垃圾桶

表示：

使用者已決定刪除。

衍生資料回收區

表示：

應用程式已聲明該資料可被移除，但使用者尚未決定。

例如：

衍生資料回收區

Chrome
- 一般快取：1.4 GB
- 本機模型：4.0 GB
- 離線網站資料：2.6 GB

NVIDIA
- Shader Cache：3.2 GB
- 更新殘留：5.3 GB

開發工具
- npm cache：3.2 GB
- uv cache：2.5 GB

[安全回收 7.8 GB]
[可重建資料 5.7 GB]
[可重新下載資料 4.0 GB]
[進階檢視]

12. 提案三：刪除後果必須被描述

現代系統常只問：

「確定要刪除嗎？」

這是極度低資訊量的警告。

更合理的介面應該是：

刪除後果：

✓ 不會刪除使用者文件
✓ 不會影響登入狀態
✓ 不會影響作業系統
△ 下次啟動將重新生成約 2.8 GB 快取
△ 預估重建時間 3–12 分鐘

是否繼續？

這才是真正有意義的風險告知。

13. 提案四：任務完成後自動降級資料狀態

設任務 (T) 產生資料集合：

D_T={d_1,d_2,\dots,d_n}

當：

State(T)=Completed

系統應重新評估：

State(d_i)

若：

Dependency(d_i)=0

則：

State(d_i)\rightarrow Disposable

也就是：

事情做完了，就把檔案標示為可移除。

這不是複雜的哲學要求，而是最基本的生命週期治理。

14. 提案五：未知資料本身也應被視為風險

若應用程式未聲明資料狀態：

UNKNOWN

系統不應假裝它不存在。

反而應顯示：

此應用程式有 8.2 GB 未聲明生命週期資料。

這可以形成新的軟體品質指標：

G(A)= \frac{ DeclaredData(A) }{ GeneratedData(A) }

其中 (G(A)) 為應用程式資料治理率。

若：

G(A)\rightarrow1

表示應用程式對其生成資料有高透明度。

若：

G(A)\rightarrow0

則應用程式實際上把硬碟當成無責任垃圾場。

15. 為何遊戲盤與影片盤反而更乾淨？

這是一個極具諷刺性的現象。

許多使用者的遊戲碟可能是：

F:\
├── SteamLibrary
├── Games
├── Emulator
└── Mods

影片碟可能是：

D:\
├── Movies
├── Anime
├── Documentary
└── Projects

即使資料量巨大，使用者通常仍能理解：

這是什麼；
為什麼存在；
刪了會發生什麼；
是否可重新下載。

反而是專業工具、開發環境、瀏覽器與 AI 軟體：

AppData\Local\xxx
ProgramData\xxx
.cache
.workspace
.models
.blobs
objects
packages
artifacts
snapshots
storage
CacheStorage
Code Cache
GPUCache

使用者無法判斷其意義。

因此產生一個諷刺：

資料越簡單，使用者越有控制權；系統越先進，資料生命週期反而越不透明。

16. AI 時代將使問題急遽惡化

AI 應用可能生成：

Embedding Cache；
Vector Index；
Local Model；
Quantized Model；
Checkpoint；
Agent Trace；
Browser State；
Generated Preview；
Multimodal Preprocessing；
Temporary Corpus；
RAG Index；
Compiled Graph；
Inference Cache；
Tool Output；
Session Snapshot。

其中許多資料：

可重建；
可重新下載；
有期限；
僅屬任務中間產物；
可能在任務完成後失去價值。

若仍沿用傳統檔案邏輯，使用者設備最終將變成：

資料考古遺址。

17. Agent 時代的進一步問題

Agent 系統可能長期執行任務。

設 Agent (G) 在時間 (t) 生成資料：

D_G(t)

若生成速率：

\frac{dD_G}{dt}>0

而清理與生命週期治理速率：

\frac{dC_G}{dt}\approx0

則長期：

D_G(t)\rightarrow\infty

即使單次任務只留下少量資料，大量 Agent 任務仍會形成累積污染。

因此 Agent 應內建：

Generate \rightarrow Declare \rightarrow Use \rightarrow Complete \rightarrow Downgrade \rightarrow Archive/Delete

而不是只有：

Generate \rightarrow Forget

18. 應用程式責任原則

本文提出：

原則 1：生成即聲明

凡自動生成資料，應聲明其類型。

原則 2：完成即重評估

任務完成後，應重新評估衍生資料。

原則 3：可重建必標示

若資料可重建，應告知使用者。

原則 4：刪除後果透明

不得只顯示「確定刪除」。

原則 5：不可重建優先保護

唯一資料必須被區分。

原則 6：孤兒資料可見

來源失效之資料不得永久沉默存在。

原則 7：更新殘留有期限

更新完成後應進入保留窗口。

原則 8：未知即技術債

未聲明資料應視為資料治理缺陷。

19. 作業系統責任原則

作業系統也不能完全推給 App。

它至少應提供：

統一生命週期 API；
統一資料分類介面；
可移除資料檢視；
刪除後果說明；
孤兒資料掃描；
安全回收模式；
空間壓力下的排序；
依賴關係顯示。

例如：

空間不足

建議回收：

A. 可安全重建資料：12.4 GB
B. 可重新下載資料：8.2 GB
C. 超期診斷資料：3.1 GB
D. 孤兒資料：6.8 GB
E. 未聲明資料：9.7 GB

不建議自動處理：
- 使用者原始資料
- 不可重建工作區

20. 一個簡化的形式模型

對任意資料 (d)，定義：

\Phi(d)= \langle R_d, D_d, P_d, C_d, T_d, U_d \rangle

其中：

$R_d$ ：可重建性；
$D_d$ ：可重新下載性；
$P_d$ ：依賴強度；
$C_d$ ：重建成本；
$T_d$ ：時間敏感度；
$U_d$ ：使用者唯一性。

定義移除分數：

M(d)= \alpha R_d + \beta D_d \gamma P_d \delta C_d \epsilon T_d \zeta U_d

其中權重依系統策略調整。

當：

M(d)\ge \theta

則系統可將其列入：

RECOMMENDED_FOR_CLEANUP

但不必自動刪除。

這保留了：

使用者控制權；
系統透明度；
風險可解釋性。

21. 與相對不可逆性之關係

現代軟體資料鏈具有高度非對稱性。

原始資料到衍生資料：

S\rightarrow A

通常容易。

但：

A\rightarrow S

可能困難、昂貴，甚至不可能。

因此不能把所有資料都視為等價檔案。

例如：

原始碼；
編譯後檔案；
中間表示；
快取；
日誌。

它們之間存在：

可生成性不對稱
可逆性不對稱
保存價值不對稱

因此資料生命週期管理實際上是在回答：

哪些資料是源，哪些資料是影？

這也是傳統檔案系統最缺乏的資訊。

22. 使用者恐懼並非錯誤，而是系統失敗的訊號

當使用者面對 C 槽資料時不敢刪除，軟體工程常將其理解為：

使用者不懂電腦。

本文反對這種簡化。

若使用者無法知道：

資料來源；
刪除後果；
是否可重建；
是否屬系統依賴；

那麼「不刪」其實是理性策略。

也就是：

Uncertainty\uparrow \Rightarrow DeletionRisk\uparrow \Rightarrow UserConservatism\uparrow

因此使用者保守，不一定代表能力不足。

反而可能代表：

系統沒有提供足夠資訊。

23. 設計倫理：誰製造資料，誰應解釋資料

本文提出一個最簡單的設計倫理：

應用程式製造資料，不應把理解資料的責任全部丟給使用者。

若 App 可以：

自動生成；
自動更新；
自動快取；
自動下載模型；
自動建立工作區；
自動保存快照；

它也應該可以：

自動標記；
自動分類；
自動過期；
自動聲明；
自動提示。

因此問題不是：

做不做得到？

而是：

為什麼長期沒有被視為產品責任？

24. 更高層命題：從檔案治理轉向資訊生命週期治理

本文最終主張：

未來作業系統不應只管理檔案，而應管理資料之生成、依賴、可再生性與死亡。

傳統系統：

File = Bytes + Path

未來系統：

Data = Bytes + Origin + Dependency + Reconstructability + Lifecycle + Risk

這代表：

檔案不再只是存在物。
檔案同時是生成鏈中的節點。

25. 結論

現代應用程式已進入大量生成資料時代。

但我們仍使用靜態檔案時代的管理思維。

今天真正的問題不是：

硬碟為什麼會滿？

而是：

為什麼明明是應用程式自己生成的資料，最後卻要使用者自己考古、猜測與承擔刪除風險？

本文提出：

生成者生命週期責任；
可重建性聲明；
可移除性標記；
衍生資料回收區；
任務完成後狀態降級；
孤兒資料識別；
刪除後果透明化；
作業系統級生命週期 API。

最終命題可以濃縮為：

現代應用程式最大的資料管理缺陷之一，不是生成了太多資料，而是拒絕向使用者聲明生成資料的生命週期、可重建性與可移除性。

再更直接一點：

應用程式製造資料，卻把理解資料的責任丟給使用者。

而在 AI 與 Agent 時代，這個問題只會更嚴重。

若仍不改變，未來的個人電腦與工作站將不是智慧系統，而是：

由無數未知生成物堆積而成的資料考古遺址。

附錄 A：建議狀態標準

ACTIVE
仍在使用

RETAINED
保留中

RECONSTRUCTABLE
可重建

REDOWNLOADABLE
可重新下載

DISPOSABLE
可移除

ORPHANED
來源關係失效

EXPIRED
超過生命週期

NON_RECONSTRUCTABLE
不可重建

USER_OWNED
使用者原始資料

UNKNOWN
應用未聲明

附錄 B：最小生命週期宣告格式

{
  "data_id": "cache-2026-07-08-001",
  "origin": "ExampleApp",
  "category": "PERFORMANCE_CACHE",
  "reconstructable": true,
  "redownloadable": false,
  "removable": true,
  "rebuild_cost": "low",
  "depends_on": [],
  "retention_days": 14,
  "state": "DISPOSABLE"
}

附錄 C：一句話版本

當代軟體已進入大量生成資料時代，但作業系統仍停留在靜態檔案時代；凡由應用程式生成之資料，生成者應負責聲明其生命週期、可重建性與可移除性，而不應將判斷成本與刪除風險轉嫁給使用者。

附錄 D：特別聲明

本文並不主張所有快取、工作區、更新包或衍生資料都應被自動刪除，也不主張作業系統應越權替使用者做決策。

本文主張的是：

可見性、可解釋性、可分類性與可選擇性。

真正的目標不是讓系統更積極地刪除，而是讓使用者終於知道：

什麼可以刪，為什麼可以刪，刪了會發生什麼。

從靜態檔案到生成資料生命週期_論現代應用程式的可移除性標記、風險轉嫁與作業系統資料治理

從靜態檔案到生成資料生命週期

論現代應用程式的可移除性標記、風險轉嫁與作業系統資料治理

摘要

關鍵詞

1. 問題的起點：為何刪除 C 槽資料像拆炸彈？

2. 現代應用程式已不是「程式＋檔案」

3. 核心命題：資料生成者應負責聲明資料生命週期

命題 1：生成者生命週期責任命題

4. 問題的本質不是垃圾，而是資訊不對稱

資料刪除風險轉嫁

5. 為何「事情做完就標示可移除」不是困難問題？

6. 生成資料的基本分類

6.1 使用者原始資料

6.2 不可重建資料

6.3 可重建資料

6.4 可重新下載資料

6.5 任務中間產物

6.6 效能快取

6.7 歷史回復資料

6.8 診斷資料

6.9 更新殘留

6.10 孤兒資料

7. 靜態檔案系統的本體論不足

8. 從檔案本體轉向生成關係本體

9. 可移除性不是二元問題

使用者唯一原稿

Shader Cache

可重新下載 20 GB 模型

最近 24 小時 Autosave

90 天前 Crash Dump

10. 提案一：Application Data Lifecycle Manifest

Application Data Lifecycle Manifest

應用資料生命週期清單

11. 提案二：衍生資料回收區

傳統垃圾桶

衍生資料回收區

12. 提案三：刪除後果必須被描述

13. 提案四：任務完成後自動降級資料狀態

14. 提案五：未知資料本身也應被視為風險

15. 為何遊戲盤與影片盤反而更乾淨？

16. AI 時代將使問題急遽惡化

17. Agent 時代的進一步問題

18. 應用程式責任原則

原則 1：生成即聲明

原則 2：完成即重評估

原則 3：可重建必標示

原則 4：刪除後果透明

原則 5：不可重建優先保護

原則 6：孤兒資料可見

原則 7：更新殘留有期限

原則 8：未知即技術債

19. 作業系統責任原則

20. 一個簡化的形式模型

21. 與相對不可逆性之關係

22. 使用者恐懼並非錯誤，而是系統失敗的訊號

23. 設計倫理：誰製造資料，誰應解釋資料

24. 更高層命題：從檔案治理轉向資訊生命週期治理

25. 結論

附錄 A：建議狀態標準

附錄 B：最小生命週期宣告格式

附錄 C：一句話版本

附錄 D：特別聲明