# 驗證義務膨脹與 Completion Drift v0.1
## ——Review 如何把完成線推向無限遠

**English Title:** *Verification Obligation Inflation and Completion Drift*  
**系列：**《綠燈錯置：AI 操作意圖不對齊與完成失真》05 / 08  
**作者：** Neo.K × AI 協作  
**版本：** v0.1  
**日期：** 2026-09

**機構：** EveMissLab／一言諾科技有限公司  

---

## 摘要

Review、red-team、lint、security scan、architecture critique 與多 Agent debate 可以提升品質，但也可能形成另一種完成失真：每輪 review 都把新發現、新想像、新 hardening 建議或新產品需求升格為 blocking obligation，使原始任務的 completion frontier 持續後退。

本文將此現象稱為**驗證義務膨脹（Verification Obligation Inflation）**與**Completion Drift**。核心問題不是 reviewer 找到問題，而是 reviewer 是否無授權地取得了 product scope 的改寫權。

---

## 1. Review 並不擁有產品範圍

原始任務意圖定義 scope：

$$
\Omega_0.
$$

reviewer 可能發現集合：

$$
F=
\{f_1,\dots,f_n\}.
$$

但：

$$
F
\not\subseteq
\Omega_0
$$

完全可能。

因此：

$$
\boxed{
\text{Finding}
\neq
\text{Blocking Obligation}
}
$$

---

## 2. 五類 Review Finding

至少區分：

1. **Spec violation**：已違反明確規格；
2. **In-scope defect**：規格未明寫但確屬原任務必要行為；
3. **Optional hardening**：品質增強，但不阻礙原 scope 完成；
4. **New scope**：合理但屬新需求；
5. **Runtime-only validation**：需要真實環境或特定 runtime 才能確認。

只有前兩類預設直接阻擋：

$$
\text{Block}(f)
=
1
\quad
\text{iff}
\quad
\text{Class}(f)\in\{1,2\}
$$

其他類別應 defer、escalate 或 route 到後續驗證，而不是自動併入當前 completion set。

---

## 3. Infinite Obligation Generator

最危險的 loop：

$$
\text{Review}
\rightarrow
\text{Fix}
\rightarrow
\text{Review}
\rightarrow
\text{NewRequirement}
\rightarrow
\text{Fix}
\rightarrow
\cdots
$$

若每一輪 review 都使 obligation set：

$$
|O_t|
$$

增加，且增加並非來自原 scope 或新 evidence，而只是 imagined possibility，則：

$$
\boxed{
\frac{d|O_t|}{dt}>0
\quad
\text{without authorized scope growth}
}
$$

這就是 completion failure mode。

---

## 4. Completion Frontier Drift

令原始完成邊界為：

$$
F_0.
$$

每輪 review 後，若邊界變成：

$$
F_1,F_2,\dots,F_n
$$

而：

$$
F_{t+1}
\supset
F_t
$$

並非因使用者增加需求，而是 review 自動升格建議，則完成條件發生 drift。

極端情況：

$$
\lim_{t\to\infty}|F_t|=\infty.
$$

此時系統可以永遠「還差一點」。

---

## 5. 想像風險不等於現實阻擋

高能力模型非常擅長生成：

- hypothetical attack；
- edge case；
- future requirement；
- possible scaling issue；
- possible refactor；
- possible platform difference。

這些能力如果沒有 scope gate，會造成：

$$
\text{Possibility Generation}
\gg
\text{Obligation Closure}.
$$

因此：

$$
\boxed{
\text{ImaginedPossibility}
\not\Rightarrow
\text{MandatoryImplementation}
}
$$

除非它具有：

- concrete mechanism；
- material relevance；
- in-scope consequence；
- required invariant violation；
- authorized risk policy。

---

## 6. Review Authority

Reviewer 的 authority 應該是：

$$
A_R
=
\{
\text{Inspect},
\text{Challenge},
\text{RequestEvidence},
\text{ClassifyFinding}
\}.
$$

通常不自動包含：

$$
A_R
\not\ni
\text{RedefineProductScope}.
$$

所以：

$$
\boxed{
\text{ReviewAuthority}
\neq
\text{ProductAuthority}
}
$$

---

## 7. Completion Supervisor

需要維持明確 obligation ledger：

```text
OPEN
RESOLVED
BLOCKED_EXTERNAL
DEFERRED_BY_SCOPE
OUT_OF_SCOPE
```

每個新 finding 都先進 classification，而不是直接進 OPEN。

任務完成可定義為：

$$
\text{Complete}(T)
=
1
$$

若：

$$
O_{\text{critical}}^{\text{open}}=\varnothing
$$

且必要 evidence 足夠，並不存在未處理的 in-scope blocker。

完成不等於：

$$
\text{Imperfection}=0.
$$

---

## 8. Validation Budget

昂貴 validation 的重新執行必須有：

$$
\text{NewInformation}
\lor
\text{PropagationReason}
\lor
\text{RequiredGate}.
$$

否則 validation 只是重複消耗。

停止條件：

$$
\text{CriticalObligationsClosed}
$$

$$
\land
\text{RequiredEvidenceSufficient}
$$

$$
\land
\text{MarginalInformationGain}\approx0.
$$

此時：

$$
\boxed{
\text{STOP}
}
$$

本身也是工程能力。

---

## 9. 核心命題

$$
\boxed{
\textbf{P1: A review finding is not automatically a blocking obligation.}
}
$$

$$
\boxed{
\textbf{P2: Reviewer authority does not imply product-scope authority.}
}
$$

$$
\boxed{
\textbf{P3: Unbounded review can create completion drift.}
}
$$

$$
\boxed{
\textbf{P4: Optional hardening and new scope must remain class-distinct from defects.}
}
$$

$$
\boxed{
\textbf{P5: A mature agent must know when additional validation has low information value.}
}
$$

---

## 10. 結論

真正好的 review 不是讓任務永遠做不完，而是提高：

$$
\frac{
\text{Useful Error Discovery}
}{
\text{Scope Distortion + Verification Cost}
}.
$$

當 reviewer 不斷產生 obligation，卻沒有新的 authorized scope 或 material evidence 時，系統不再是「更嚴謹」，而是在改寫任務。

下一篇把焦點移到另一種失衡：即使流程與 scope 都合理，AI 生成候選變更的速度仍可能遠快於驗證、架構理解與治理速度。