# 局部正確與全域失敗 v0.2
## ——投影閉合、跨邊界錯位與宏觀完成缺口

**English Title:** *Local Correctness, Global Failure: Projection Closure, Boundary Failure, and the Gap to Macro Completion*  
**系列：**《綠燈錯置：AI 操作意圖不對齊與完成失真》03 / 08  
**作者：** Neo.K × AI 協作  
**版本：** v0.2  
**日期：** 2026-09-16  
**文件性質：** AI 工程／軟體工程／系統工程／Agent 系統／跨邊界驗證／宏觀完成語義  
**承接：** A01〈綠燈錯置〉、A02〈表觀成功與實質完成的分離〉  
**後續接口：** A04〈流程代理錯置〉、A07〈能力—視角啟動不對稱〉、Series B〈宏觀個體導向的動態全域觀察方法論〉

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

---

## 摘要

大型軟體、遊戲、Agent 系統與一般複雜產品，幾乎從來不是由單一表示、單一專業或單一驗證器完整描述。前端、後端、資料、基礎設施、安全、UX、程式、美術、企劃、玩家、營運與外部環境，都只能觀察或承擔整體系統的一部分。這些局部視角可以各自建立高品質規格、測試、型別、schema、CI、review、benchmark 與形式化驗證；然而，即使所有局部角色都能合理地宣稱「自己的部分是正確的」，整體產品仍然可能失敗。

本文將此現象正式表述為**投影閉合不推出宏觀閉合（Projection Closure Does Not Imply Macro Closure）**。令宏觀對象為 $X$，不同角色、工具、模態與工程層形成觀察或責任投影：

$$
O_i:X\rightarrow Y_i.
$$

若每一個局部驗證器只在自己的投影上工作：

$$
V_i(O_i(X))=1,
$$

則一般不存在：

$$
\forall i,\;V_i(O_i(X))=1
\Rightarrow
V_G(X,I)=1.
$$

原因在於宏觀對象不只由元件組成，也由元件間的**關係、邊界、時序、共享狀態、權限、環境耦合與跨角色語義**共同構成。局部 verifier 可以正確驗證 vertex，卻完全沒有驗證 edge；可以驗證 declared contract，卻沒有驗證 effective interaction；可以驗證 source-level correctness，卻沒有驗證 runtime、human、visual、operational 或 external-world consequence。

本文提出四層完成結構：

$$
\boxed{
C_{\mathrm{macro}}
=
C_{\mathrm{local}}
\land
C_{\mathrm{boundary}}
\land
C_{\mathrm{cross\text{-}perspective}}
\land
C_{\mathrm{intent}}
}
$$

並進一步加入 environment / runtime 條件，建立局部閉合、邊界閉合、跨視角閉合與宏觀意圖閉合之間的區分。本文同時提出 **Projection Closure Fallacy、Boundary Blindness、Relation Failure、Cross-Perspective Contradiction、Homogeneous Green、Productive Friction** 等概念，將遊戲開發中的程式／企劃／美術、軟體中的前端／後端／X 端，以及 AI Agent 中同模型多角色 review 統一到同一個架構。

本文與既有 systems engineering、product integration、interface management、end-to-end V&V、component composition、contract-based design 與 emergent behavior 研究相容。NASA Systems Engineering Handbook 明確將 product integration、interface management、complete-system integration 與 end-to-end validation 視為不同於單一 end-item verification 的必要工程活動；軟體工程中的 emergent behavior 研究也指出，系統級錯誤可能來自多個正確元件之間的互動，而非單一元件本身。

本文的新命題不在於重新發明 integration testing，而是將問題推進到 AI-native engineering：**當 AI 能快速生成大量局部正確的 artifact，而且同一模型可以同時扮演 implementer、reviewer、tester 與 architect 時，最危險的失敗不一定是「沒有驗證」，而可能是「所有驗證都停留在同一投影」。**

---

# 1. 問題：每一個人都對，產品還是錯

複雜系統中存在一種很常見、但在 AI 自動化時代會被放大的狀態：

```text
Frontend: PASS
Backend: PASS
Database migration: PASS
Schema: PASS
CI: PASS
Security scan: PASS
Deployment: PASS
```

最後：

```text
User clicks checkout
→ spinner never ends
→ payment already captured
→ UI still shows "processing"
```

這時不能簡單地說：

> 前端測試是假測試。

也不能直接說：

> 後端一定錯。

完全可能出現：

$$
C_F=1,
$$

$$
C_B=1,
$$

$$
C_D=1,
$$

而：

$$
C_{F\leftrightarrow B}=0
$$

或：

$$
C_{B\leftrightarrow \mathrm{Payment}}=0.
$$

最後：

$$
\boxed{
C_{\mathrm{product}}=0.
}
$$

這表示錯誤的所在不是某一個單獨 component，而是：

$$
\boxed{
\text{Relation}.
}
$$

A01 已指出「局部正確不推出全域意圖對齊」。A02 進一步指出 `PASS / DONE / SUCCESS` 只是一種帶 scope 的成功聲明。本文則把問題往中間補完整：

> **局部與宏觀之間不是一個空白，而是一組必須被獨立驗證的關係結構。**

---

# 2. 宏觀產品不是局部 artifact 的集合

令系統中的構件集合為：

$$
V=\{v_1,v_2,\ldots,v_n\}.
$$

如果只把產品寫成：

$$
X=V,
$$

則系統會被錯誤地理解成「一堆東西的集合」。

但真實產品至少包含：

$$
\boxed{
X_t=(V,E,S_t,\Gamma_t,\mathcal E_t).
}
$$

其中：

- $V$：元件、模組、服務、資產、角色、文件、模型；
- $E$：依賴、呼叫、資料流、時序、控制、契約、handoff、語義關係；
- $S_t$：時間 $t$ 的有效狀態；
- $\Gamma_t$：權限、責任、治理與可執行 action 邊界；
- $\mathcal E_t$：部署環境、使用者、外部服務、網路、設備與其他有效環境條件。

因此產品不是：

$$
\text{Components}.
$$

而是：

$$
\boxed{
\text{Components}
+
\text{Relations}
+
\text{State}
+
\text{Authority}
+
\text{Environment}.
}
$$

這一點與既有 systems engineering 的 integration 觀完全一致。NASA 將 product integration 描述為對 subsystem interaction 以及 subsystem 與 system environment interaction 的工程活動，並特別要求檢查整合後是否產生 adverse emergent behaviors。也就是說，低階產品被組裝成高階產品後，新的驗證對象已經出現。

所以：

$$
\forall v_i\in V,\quad V(v_i)=1
$$

仍不能推出：

$$
V(X_t)=1.
$$

因為：

$$
E,\;S_t,\;\Gamma_t,\;\mathcal E_t
$$

仍可能失敗。

---

# 3. 投影：每一個角色看到的都是真的，但都不是全部

令完整宏觀對象為 $X$。

不同專業、工具與感知模式建立：

$$
O_i:X\rightarrow Y_i.
$$

 $O_i$ 可以是：

- frontend projection；
- backend projection；
- database projection；
- security projection；
- performance projection；
- visual projection；
- UX projection；
- game-design projection；
- art projection；
- player projection；
- runtime trace projection；
- source-code projection；
- infrastructure projection；
- organizational projection。

重要的是：

$$
\boxed{
O_i(X)\neq X.
}
$$

這不代表投影是錯誤。

相反地，一個好的專業視角通常正是因為它**主動忽略大量與目前責任無關的資訊**，才能提高局部解析度。

例如後端工程師可能忽略：

- 字體；
- 動畫節奏；
- UI 對比；
- 玩家是否直覺理解技能效果。

這並不表示後端工程師失職。

同樣，美術工作也不需要在每一張角色立繪上重新推導資料庫 isolation level。

問題只在於：

> **局部投影何時被錯誤地冒充成宏觀對象本身？**

---

# 4. 投影閉合謬誤

本文將以下推論稱為：

# Projection Closure Fallacy
## 投影閉合謬誤

若：

$$
\forall i,\quad
V_i(O_i(X))=1,
$$

就推論：

$$
V_G(X)=1.
$$

這個推論一般不成立。

原因至少有五類。

第一，projection 可能不完備：

$$
\bigcup_i O_i
$$

沒有覆蓋某些有效世界狀態。

第二，projection 間可能存在未驗證關係。

第三，不同 projection 的語義可能互相矛盾。

第四，所有 projection 可能共享同一個 blind spot。

第五，宏觀層可能產生任何單一 projection 中都不存在的 emergent behavior。

所以：

$$
\boxed{
\text{Projection Completeness}
}
$$

與：

$$
\boxed{
\text{Projection Consistency}
}
$$

都必須被獨立處理。

---

# 5. Relation Failure：錯誤可以只存在於「之間」

最容易被局部驗證遺漏的，不是 node，而是 edge。

令：

$$
e_{ij}\in E
$$

表示：

$$
v_i\rightarrow v_j
$$

之間的一個有效關係。

例如：

- API contract；
- event sequencing；
- schema mapping；
- file format；
- transaction boundary；
- cache invalidation；
- animation-event timing；
- authority transfer；
- model-tool protocol；
- human handoff；
- retry semantics；
- deployment dependency。

若：

$$
V(v_i)=1,
\qquad
V(v_j)=1,
$$

但：

$$
V(e_{ij})=0,
$$

則：

$$
\boxed{
\text{Correct Components}
+
\text{Incorrect Relation}
=
\text{Incorrect System Path}.
}
$$

這就是 relation failure。

既有 component-based software 研究早已指出：即使 components 對 domain interface specification 分別正確，runtime binding 之後的 system correctness 仍不自動成立。contract-based design 也因此需要 assumptions / guarantees 與 composite refinement，而不是只證明每個 component 自己成立。

---

# 6. Static Interface 正確，不代表 Behavioral Interaction 正確

跨邊界錯誤不能只理解成：

```text
field name mismatch
```

或：

```text
wrong API version
```

因為 interface 可以在 static schema 層完全一致，但 behavioral assumptions 不一致。

例如：

```text
Frontend assumption:
POST /checkout 回傳 200
→ payment 已完成且 UI 可立即顯示成功

Backend guarantee:
POST /checkout 回傳 200
→ payment job 已被接受，最終狀態稍後由 event 決定
```

兩邊 schema 都合法。

HTTP status 也合法。

甚至各自 unit test 全綠。

但：

$$
\mathrm{Semantics}_F
\neq
\mathrm{Semantics}_B.
$$

因此：

$$
\boxed{
\text{Syntactic Compatibility}
\neq
\text{Behavioral Compatibility}.
}
$$

再例如：

```text
Service A:
retry is safe

Service B:
operation is not idempotent
```

單獨看：

$$
A=\mathrm{correct},
\qquad
B=\mathrm{correct}.
$$

組合後：

$$
A\circ B
$$

可能造成重複扣款。

所以真正需要驗證的是：

$$
\boxed{
\mathrm{Assumption}_i
\subseteq
\mathrm{Guarantee}_j
}
$$

是否成立。

---

# 7. 時序本身是一種邊界

許多局部正確／全域失敗不是 value mismatch，而是 time mismatch。

例如：

```text
Backend state:
updated

Cache:
old

Client:
old

Event:
delayed

UI:
renders stale snapshot
```

每一個 subsystem 都可能在自己的 consistency model 下合法。

但使用者看到：

```text
付款成功
+
訂單仍顯示未付款
```

此時 failure domain 不是：

$$
\text{Value}.
$$

而是：

$$
\boxed{
\text{Temporal Relation}.
}
$$

可以定義某一 boundary 的時序契約：

$$
B_{ij}^{\text{time}}
=
(
t_{\min},
t_{\max},
\text{ordering},
\text{freshness},
\text{retry},
\text{timeout}
).
$$

若兩端對：

- ordering；
- freshness；
- timeout；
- eventual consistency；
- retry window；

的理解不同，則 component-level pass 不足以保證產品行為。

---

# 8. Shared State：兩個正確模組可以讀到不同的世界

令兩個 subsystem 的世界模型為：

$$
W_i(t),
\qquad
W_j(t).
$$

若：

$$
W_i(t)\neq W_j(t),
$$

並不必然表示其中一個壞掉。

它可能只是：

- replication lag；
- cache；
- snapshot；
- eventual consistency；
- stale browser state；
- delayed event；
- local optimistic update。

真正問題是：

$$
\boxed{
\text{當 action 需要跨模組一致判斷時，這個差異是否仍被允許？}
}
$$

所以 boundary contract 不應只有 schema，也需要：

$$
\text{State Synchronization Semantics}.
$$

這一點在 Agent 系統尤其重要。

兩個 agents 可能：

- 使用不同 memory snapshot；
- 讀到不同 artifact version；
- 使用不同 authority state；
- 一個讀到新 intent，另一個仍沿用舊 intent。

兩邊都可以對自己的 context 推理得完全正確。

最後仍然：

$$
\boxed{
\text{Globally Wrong}.
}
$$

---

# 9. 權限也是跨邊界語義

工程系統常把 authorization 當 security 的獨立議題。

但在 Agentic runtime 中，authority 本身會直接影響「全域完成是否成立」。

例如：

```text
Planner:
正確產生 deploy plan

Executor:
正確執行 local build

Verifier:
正確驗證 artifact

Deployment:
沒有 production authority
```

則：

$$
C_{plan}=1,
$$

$$
C_{build}=1,
$$

$$
C_{verify}=1,
$$

但：

$$
C_{mission}=0
$$

如果原始任務明確是：

> deploy to production。

反過來，若 Agent 沒有 authority 卻自行 promotion，也不是「更完整」，而是：

$$
\boxed{
\text{Authority Boundary Violation}.
}
$$

因此宏觀 closure 必須包含：

$$
C_{\Gamma}.
$$

也就是：

> 該完成路徑是否在正確 authority chain 內成立？

---

# 10. 遊戲：程式、企劃、美術為什麼必然互相吐槽

遊戲提供一個非常直觀的例子。

令完整遊戲為：

$$
G.
$$

程式的工作投影：

$$
O_P(G)
=
\text{State}
+
\text{Logic}
+
\text{Runtime}
+
\text{Performance}
+
\text{Architecture}.
$$

企劃投影：

$$
O_D(G)
=
\text{Rules}
+
\text{Balance}
+
\text{Progression}
+
\text{PlayerExperience}
+
\text{ContentLogic}.
$$

美術投影：

$$
O_A(G)
=
\text{VisualForm}
+
\text{Readability}
+
\text{Animation}
+
\text{Style}
+
\text{AssetCost}.
$$

玩家投影：

$$
O_U(G)
=
\text{Interaction}
+
\text{Perception}
+
\text{Feedback}
+
\text{Difficulty}
+
\text{Meaning}.
$$

如果：

$$
V_P(O_P(G))=1,
$$

$$
V_D(O_D(G))=1,
$$

$$
V_A(O_A(G))=1,
$$

仍然不能推出：

$$
V_G(G)=1.
$$

例如：

```text
程式：
技能狀態機正確。

企劃：
技能數值合理。

美術：
動畫品質很好。

玩家：
根本看不出何時能閃避。
```

這不是：

> 美術錯。

也不一定是：

> 程式錯。

更可能是：

$$
\boxed{
\text{AnimationTiming}
\leftrightarrow
\text{GameplayWindow}
\leftrightarrow
\text{PlayerPerception}
}
$$

這個 cross-projection relation 沒閉合。

所以傳統遊戲團隊中大量「互相吐槽」其實具有兩種性質：

$$
F_h
=
C_{\mathrm{coordination}}
+
V_{\mathrm{cross\text{-}projection}}.
$$

一部分是協作摩擦。

另一部分卻是重要的異質驗證。

---

# 11. 軟體：前端、後端與 X 端只是不同投影

同理，「前端」「後端」「資料端」「Infra」「Security」「ML」「Mobile」「DevOps」不是完整軟體本體的自然分割線。

它們更接近：

$$
\boxed{
\text{Responsibility Projection}.
}
$$

前端常關心：

$$
O_F(S)
=
\text{Interaction}
+
\text{Presentation}
+
\text{ClientState}
+
\text{PerceivedLatency}.
$$

後端：

$$
O_B(S)
=
\text{BusinessLogic}
+
\text{Persistence}
+
\text{Concurrency}
+
\text{ServiceReliability}.
$$

Infra：

$$
O_I(S)
=
\text{Deployment}
+
\text{Capacity}
+
\text{Networking}
+
\text{RuntimeHealth}.
$$

Security：

$$
O_S(S)
=
\text{TrustBoundary}
+
\text{Authority}
+
\text{AttackSurface}
+
\text{DataExposure}.
$$

Data：

$$
O_D(S)
=
\text{Schema}
+
\text{Lineage}
+
\text{Consistency}
+
\text{Quality}
+
\text{Transformation}.
$$

每一個都是：

$$
O_i(S).
$$

但：

$$
\boxed{
O_i(S)\neq S.
}
$$

因此「某一端已完成」是局部狀態。

產品完成必須穿過：

$$
O_F
\leftrightarrow
O_B
\leftrightarrow
O_I
\leftrightarrow
O_D
\leftrightarrow
O_S
\leftrightarrow\cdots
$$

的有效關係。

---

# 12. Full-stack 不等於 Global-stack

Full-stack engineer 或 full-stack Agent 的重要價值之一，是降低：

$$
\text{Boundary Translation Cost}.
$$

因為同一 observer 可以看到：

$$
\text{Frontend}
\leftrightarrow
\text{Backend}.
$$

但這不能推出：

$$
\boxed{
\text{FullStack}
=
\text{GlobalStack}.
}
$$

至少有四個原因。

第一，front/back 只是整體中的兩類 projection。

第二，同一 observer 同時負責兩側，可能提高 coherence，也可能降低異質反證。

第三，full-stack knowledge 並不自動包含：

- production operations；
- security；
- UX；
- visual perception；
- data governance；
- performance；
- legal / compliance；
- organizational workflow；
- external service behavior。

第四，宏觀問題不只需要「知道更多 layer」，也需要：

$$
\boxed{
\text{知道自己目前沒有看見什麼。}
}
$$

所以：

$$
\text{Broad Knowledge}
\neq
\text{Global Observational Closure}.
$$

---

# 13. Productive Friction：不是所有摩擦都該消失

工程自動化常有一個直覺：

$$
\text{Coordination Friction}\downarrow
\Rightarrow
\text{Productivity}\uparrow.
$$

很多時候成立。

但若某種 friction 同時承擔：

$$
\text{Cross-Perspective Challenge},
$$

則把它全部消除可能同時降低：

$$
\text{Error Detection Diversity}.
$$

因此本文定義：

# Epistemically Productive Friction
## 認知上有生產力的摩擦

它指：

> 因角色、表示、責任、觀測模態或失敗模型不同，而迫使系統重新檢查原先未被看見的假設。

例如：

企劃問：

> 這個功能真的好玩嗎？

程式問：

> 這個組合狀態空間真的能維持嗎？

美術問：

> 玩家真的看得懂嗎？

Security 問：

> 這個 trust boundary 真的成立嗎？

SRE 問：

> production failure 時怎麼恢復？

這些問題不是重複 verifier。

它們改變的是：

$$
O_i.
$$

因此理想方向不是：

$$
F_h\rightarrow0.
$$

而是：

$$
\boxed{
\text{RedundantFriction}\downarrow,
\qquad
\text{EpistemicallyProductiveFriction}\uparrow.
}
$$

---

# 14. Cross-Perspective Contradiction：多個真局部可以互相衝突

令兩個 projection 對同一宏觀狀態產生局部 assertion：

$$
a_i\in O_i(X),
$$

$$
a_j\in O_j(X).
$$

兩者可以各自在局部證據下成立：

$$
\operatorname{Support}_i(a_i)\ge\tau_i,
$$

$$
\operatorname{Support}_j(a_j)\ge\tau_j,
$$

但在 joint model 中：

$$
a_i\land a_j
$$

可能不可同時成立。

例如：

```text
Backend:
order finalized

Frontend:
order still editable
```

或者：

```text
Security:
session revoked

Client:
token still treated as active
```

因此需要定義：

$$
\boxed{
K_{ij}
=
\operatorname{Consistency}(O_i,O_j).
}
$$

並且：

$$
K_{ij}=0
$$

時，不能用：

> 兩邊測試都通過。

來結案。

---

# 15. Projection Coverage：有多少重要視角根本沒被啟動

如果系統有潛在觀察算子集合：

$$
\mathcal O
=
\{O_1,O_2,\ldots,O_n\},
$$

當前任務實際啟動：

$$
\mathcal O_t^{active}
\subseteq
\mathcal O.
$$

可以定義概念性的 projection coverage：

$$
PC_t
=
\frac{
\sum_{O_i\in\mathcal O_t^{active}}w_i
}{
\sum_{O_i\in\mathcal O_t^{relevant}}w_i
}.
$$

其中：

$$
\mathcal O_t^{relevant}
$$

不是所有可能 modality，而是對當前宏觀任務真正具有因果或驗證價值的視角。

這個限制很重要。

本文不主張：

$$
\mathcal O_t^{active}
=
\mathcal O
$$

永遠成立。

因為那會造成：

$$
\text{TokenCost}
+
\text{ToolCost}
+
\text{Latency}
+
\text{CoordinationCost}
\rightarrow
\text{excessive}.
$$

真正需要的是：

$$
\boxed{
\text{Sufficient Relevant Projection Coverage}.
}
$$

這一點將在 Series B 與 APR-driven dynamic observation 中進一步展開。

---

# 16. Boundary Coverage：測了多少關係，而不是只測多少元件

令重要邊界集合：

$$
\mathcal B
=
\{b_1,b_2,\ldots,b_m\}.
$$

每一 boundary 具有重要度：

$$
w(b_k).
$$

定義：

$$
BC
=
\frac{
\sum_{b_k\in \mathcal B_{\mathrm{verified}}}w(b_k)
}{
\sum_{b_k\in \mathcal B_{\mathrm{required}}}w(b_k)
}.
$$

這比單純：

$$
\text{Test Count}
$$

更接近 integration completeness。

因為 1000 個 unit tests 可能都集中在一個 component。

而一條沒有驗證的高權重 boundary：

```text
payment → ledger
```

就足以讓：

$$
C_{\mathrm{macro}}=0.
$$

所以：

$$
\boxed{
\text{Test Volume}
\neq
\text{Boundary Coverage}.
}
$$

---

# 17. Boundary 不只存在於程式模組之間

本文將 boundary 擴張成至少九類。

## 17.1 Structural Boundary

```text
module A ↔ module B
```

## 17.2 Data Boundary

```text
schema A ↔ schema B
```

## 17.3 Temporal Boundary

```text
producer time ↔ consumer time
```

## 17.4 Authority Boundary

```text
proposal ↔ allowed action
```

## 17.5 Representation Boundary

```text
internal state ↔ UI
```

## 17.6 Human Boundary

```text
system ↔ operator
```

## 17.7 External-System Boundary

```text
product ↔ payment provider
```

## 17.8 Modality Boundary

```text
code state ↔ visual state
```

## 17.9 Intent Boundary

```text
implemented behavior ↔ requested outcome
```

因此 integration testing 只是 cross-boundary closure 的一個子域。

AI-native system 需要更大的 boundary model。

---

# 18. Effective Dependency：真正的邊界可能不在 import graph

作者既有「宣告架構／有效架構」系列提出：

$$
D_e
\supseteq
D_{\mathrm{static}}.
$$

也就是 effective dependency 可以來自：

- API；
- DB；
- event；
- config；
- schedule；
- human；
- external service；
- compatibility behavior；
- recovery procedure。

因此若 AI 只從 source dependency graph 建 boundary map：

$$
B_{\mathrm{source}},
$$

就可能漏掉：

$$
B_{\mathrm{effective}}.
$$

例如：

```text
nightly reconciliation job
+
finance operator
+
Excel correction
```

可能沒有出現在主要 service architecture 中，卻是真正維持產品承諾的有效結構。

所以：

$$
\boxed{
\text{Declared Boundary Map}
\neq
\text{Effective Boundary Map}.
}
$$

---

# 19. Emergent Behavior：宏觀錯誤不一定能向下歸因成單一壞元件

軟體工程對 emergent behavior 的研究指出，某些 behavior 不能歸因到單一 subsystem，而是來自多個 component 或 system 的 interplay。

這意味著：

$$
\text{Failure}(X)
$$

不必然存在：

$$
\exists v_i:
\text{Failure}(v_i)=1.
$$

完全可能：

$$
\forall i,\quad
\text{Failure}(v_i)=0,
$$

但：

$$
\text{Failure}(X)=1.
$$

其來源是：

$$
\boxed{
\text{InteractionTopology}
+
\text{State}
+
\text{Environment}.
}
$$

這與本文的 relation-first view 完全一致。

因此「找到哪個檔案錯」不是所有 failure analysis 的合法問題。

有些問題真正需要問：

> 哪一個關係組合使宏觀狀態進入失敗域？

---

# 20. NASA Integration 對本文的工程支持

NASA Systems Engineering Handbook 將：

- product implementation；
- product integration；
- product verification；
- product validation；

明確分成不同技術流程。

其中 product integration 的核心不是把檔案放在一起，而是：

> 將 lower-level products 組裝成 higher-level product，工程化 subsystem interaction 以及 subsystem 與 environment 的 interaction，並檢查 integrated product 是否正常、是否產生 adverse emergent behavior。

其 V&V plan 也從：

```text
end item
→ end-item integration
→ complete system integration
→ external interfaces
→ end-to-end integration
```

逐層提高。

這提供一個非常重要的既有工程對照：

$$
\boxed{
\text{Element Verification}
\neq
\text{Integrated-System Verification}.
}
$$

本文只是將這個原理推廣到 AI Agent 與多視角工程：

$$
\boxed{
\text{Projection Verification}
\neq
\text{Macro-Object Verification}.
}
$$

---

# 21. Contract-Based Design：局部保證必須帶著假設

在 contract-based design 中，component 不只具有：

$$
\text{Guarantee},
$$

還具有：

$$
\text{Assumption}.
$$

可表示為：

$$
C_i=(A_i,G_i).
$$

當 component 被組合時，需要檢查：

$$
A_i
$$

是否真的被其他 component / environment 的：

$$
G_j
$$

滿足。

因此：

$$
G_i=1
$$

不是充分條件。

因為：

$$
A_i=0
$$

時，component 的「正確」可能只是在不存在的前提下成立。

這與 AI coding 有直接關係。

AI 常能生成：

```text
function correct under expected input
```

卻沒有檢查：

```text
does real upstream actually guarantee expected input?
```

所以：

$$
\boxed{
\text{Implementation Correctness}
\neq
\text{Assumption Satisfaction}.
}
$$

---

# 22. Cross-Boundary Closure

本文將 boundary closure 定義為：

對所有 required boundary：

$$
b_{ij}\in\mathcal B_{\mathrm{required}},
$$

存在足夠 evidence：

$$
E_{ij}
$$

使：

$$
V_{ij}
(
O_i(X),
O_j(X),
E_{ij}
)=1.
$$

因此：

$$
\boxed{
C_B
=
\bigwedge_{b_{ij}\in\mathcal B_{\mathrm{required}}}
V_{ij}.
}
$$

但工程上不需要對宇宙中所有 pair 做：

$$
O(n^2)
$$

驗證。

只需要對：

$$
\mathcal B_{\mathrm{causal/relevant}}
$$

進行 risk-weighted closure。

因此：

$$
\boxed{
\text{Boundary Closure}
\neq
\text{All-Pairs Testing}.
}
$$

這與 Global-First / APR 的 resource governance 一致。

---

# 23. Cross-Perspective Closure

Boundary closure 側重：

$$
\text{interaction}.
$$

Cross-perspective closure 則處理：

$$
\text{interpretation}.
$$

例如同一個 feature：

```text
Backend:
correct

UX:
misleading

Security:
unsafe

Legal:
not allowed

Player:
unreadable
```

因此需對 relevant projections 建立：

$$
K_{ij}.
$$

並在存在重大 contradiction 時 reopen。

定義：

$$
C_P
=
\mathbf 1[
\text{all material cross-perspective contradictions resolved or explicitly bounded}
].
$$

這裡的 resolved 不要求所有角色喜歡同一方案。

而是要求：

- contradiction 被看見；
- trade-off 被承認；
- authority owner 做出決定；
- 結果被寫回 canonical intent / specification；
- verifier 不再拿舊假設驗新產品。

---

# 24. 宏觀完成的五層模型

A03 v0.1 提出四層 closure。v0.2 將它細化為五層：

$$
\boxed{
C_{\mathrm{macro}}
=
C_L
\land
C_B
\land
C_P
\land
C_E
\land
C_I.
}
$$

其中：

## 24.1 Local Closure

$$
C_L
$$

必要局部 component 是否達到自己的 required correctness。

## 24.2 Boundary Closure

$$
C_B
$$

重要 interaction / relation 是否成立。

## 24.3 Cross-Perspective Closure

$$
C_P
$$

不同觀察／責任投影的重大矛盾是否被處理。

## 24.4 Environment Closure

$$
C_E
$$

在真正目標環境、runtime、external system、human operation 下是否仍成立。

## 24.5 Intent Closure

$$
C_I
$$

整體是否完成原始任務意圖。

因此：

$$
C_L=1
$$

只代表第一層。

---

# 25. Partial Closure Vector

在真實工程中，不一定所有 closure 都是純布林值。

因此可以使用：

$$
\mathbf C
=
(
c_L,
c_B,
c_P,
c_E,
c_I
),
$$

其中：

$$
c_k\in[0,1].
$$

例如：

$$
\mathbf C
=
(
1.0,
0.92,
0.55,
0.80,
0.60
).
$$

這比單一：

```text
92% complete
```

更有意義。

因為同樣的：

$$
0.92
$$

可能代表：

- 局部 code 幾乎都完成；
- 但 cross-role / environment 根本沒有 closure。

因此：

$$
\boxed{
\text{Scalar Completion Percentage}
}
$$

很容易隱藏 topology。

---

# 26. Minimum Macro Completion Certificate

本文提出一個概念性的 Macro Completion Certificate：

```yaml
macro_completion:
  intent:
    id: checkout-v3
    status: aligned

  local:
    required_components: 12
    verified_components: 12

  boundaries:
    required_weighted: 9
    verified_weighted: 9
    unresolved: []

  perspectives:
    activated:
      - frontend
      - backend
      - ux
      - payment
      - operations
    material_conflicts: []

  environment:
    target: production-like
    runtime_replay: PASS
    external_dependencies: PASS

  remaining_obligations:
    blocking: []
    deferred:
      - optional animation polish

  claim:
    status: COMPLETE
```

它不是要求所有產品都使用 YAML。

而是說：

> `COMPLETE` 應該有 topology-aware evidence，而不是只有一個字串。

---

# 27. AI 時代第一個放大器：局部 artifact 生成速度暴增

傳統工程中，局部施工本身很慢。

這形成天然節流：

$$
V_{\mathrm{local\ production}}
$$

有限。

AI coding agent 讓：

$$
V_{\mathrm{local\ production}}\uparrow\uparrow.
$$

因此一個 agent 很容易短時間產生：

- frontend；
- backend；
- tests；
- schema；
- docs；
- deployment；
- migration。

表面上：

$$
C_L
$$

快速上升。

但若：

$$
V_{\mathrm{boundary\ verification}}
$$

沒有同步提高，會出現：

$$
\boxed{
C_L\uparrow
\quad\text{while}\quad
C_B
\text{ remains low}.
}
$$

這就是 AI-native integration debt 的一個來源。

---

# 28. AI 時代第二個放大器：同一模型可以扮演所有角色

傳統團隊中：

```text
programmer
designer
artist
QA
security
operations
```

通常具有不同：

- training；
- responsibility；
- tools；
- incentives；
- representations；
- failure priors。

AI 時代可能變成：

```text
same model
→ programmer persona
→ reviewer persona
→ QA persona
→ architect persona
```

表面上形成：

$$
N_{\mathrm{roles}}>1.
$$

但 epistemic diversity 未必增加。

若：

$$
O_1\approx O_2\approx\cdots\approx O_n,
$$

那麼：

$$
\boxed{
\text{Many Roles}
\neq
\text{Many Perspectives}.
}
$$

甚至可能出現：

$$
\forall i,\quad V_i=1
$$

只是因為所有 verifier 共用：

- 同一誤解；
- 同一 specification；
- 同一 context；
- 同一 test fixture；
- 同一 completion definition。

這將在 A08〈同質綠燈〉完整展開。

---

# 29. AI 時代第三個放大器：多模態能力存在，但沒有被呼叫

前沿 AI 可能同時具備：

- code reasoning；
- image understanding；
- UI inspection；
- document understanding；
- logs / traces；
- natural-language requirements reasoning。

但 coding workflow 可能只啟動：

$$
O_{\mathrm{code}}
+
O_{\mathrm{test}}.
$$

所以：

$$
\boxed{
\text{Multimodal Capability Available}
\neq
\text{Multimodal Evidence Acquired}.
}
$$

結果就是：

> 模型理論上看得懂 UI，實際工作流卻從頭到尾沒讓它看 UI。

此時「低級 UI 錯誤」未必表示：

$$
Capability_{\mathrm{vision}}=0.
$$

更可能：

$$
Activation_{\mathrm{vision}}=0.
$$

這將在 A07 與 Series B 的 resolution / APR routing 中完整形式化。

---

# 30. Homogeneous Green

本文先引入一個後續會獨立展開的概念：

# Homogeneous Green
## 同質綠燈

若多個 verifier：

$$
V_1,V_2,\ldots,V_n
$$

實際共享高度相似的：

$$
\text{Projection},
\text{Specification},
\text{Evidence},
\text{ModelPrior},
\text{FailureModel},
$$

則：

$$
V_1=\cdots=V_n=1
$$

提供的獨立資訊量可能遠低於 verifier 數量。

概念上：

$$
\boxed{
N_{\mathrm{green}}
\neq
N_{\mathrm{independent\ evidence}}.
}
$$

因此「三個 Agent 都同意」本身不是強證據。

---

# 31. Cross-Boundary Replay

對高重要度 path，本文建議不要只做 component test，而做：

$$
\boxed{
\text{Cross-Boundary Replay}.
}
$$

例如：

```text
User intent
→ UI action
→ client state
→ API
→ service
→ database
→ external provider
→ event
→ backend state
→ API refresh
→ UI visible outcome
```

並取得：

$$
E_0,E_1,\ldots,E_n.
$$

這與 APR 的 post-action independent observation 具有相同精神：

> 不要把「預期結果」直接寫成「已觀察結果」。

而是重新取得 machine / world evidence。

---

# 32. Boundary Witness

每一個高權重 boundary 最好存在至少一個正 witness：

$$
w^+_{ij}
$$

證明：

> 合法交互確實能成功。

以及在適當情況下存在負 witness：

$$
w^-_{ij}
$$

證明：

> 不合法交互會被拒絕或被發現。

因此：

$$
\boxed{
\text{BoundaryEvidence}
=
\text{PositiveWitness}
+
\text{NegativeWitness}
}
$$

可以比單純：

```text
request returned 200
```

更能證明 semantic boundary。

---

# 33. Relation-Centric Failure Clustering

若 integration validation 發現大量錯誤，不應立刻逐 ticket 修。

先將 failure 依 relation class 聚類：

$$
F
\rightarrow
\{
F_{schema},
F_{timing},
F_{state},
F_{authority},
F_{representation},
F_{environment},
F_{semantic}
\}.
$$

若多個 symptom 指向同一 boundary：

$$
b^\ast,
$$

則優先修：

$$
b^\ast
$$

而不是：

$$
\text{every downstream symptom}.
$$

這與作者既有的：

$$
\text{Maximum Local Precision}
+
\text{Minimum Global Disturbance}
$$

以及 responsibility-layer diagnosis 相容。

---

# 34. 全域不是「所有東西都一起看」

本文必須避免一個反向錯誤。

既然：

$$
\text{Local}\neq\text{Global},
$$

不代表：

$$
\text{Global}
=
\text{ReadEverything}.
$$

也不代表：

$$
\text{Global}
=
\text{AlwaysUseAllAgents}.
$$

更不代表：

$$
\text{Global}
=
\text{RunEveryTest}.
$$

真正的全域是：

$$
\boxed{
\text{知道宏觀對象的必要結構、重要邊界、可用視角與當前未知。}
}
$$

然後：

$$
\text{按風險與不確定性提高局部解析度}.
$$

所以：

$$
\boxed{
\text{GlobalAwareness}
+
\text{TargetedObservation}
}
$$

優於：

$$
\text{UniformMaximumObservation}.
$$

這就是本文與第二系列的橋。

---

# 35. Global-First 與本文的關係

Global-First Completion 已提出：

```text
Global implementation
→ Global/integration validation
→ Root-cause clustering
→ Batched repair
→ Affected-area validation
→ Final relevant global validation
```

本文為這個方法補上一個更精確的理由。

全域第一版的價值不只在於：

$$
\text{Coverage}\uparrow.
$$

更在於：

> **只有當足夠多的節點同時存在，真正的邊界與 relation failure 才會開始顯現。**

若一直：

```text
component A
→ polish
→ verify
→ polish
→ verify
```

在 component B 尚未存在時，很多：

$$
e_{AB}
$$

根本無法被觀察。

所以：

$$
\boxed{
\text{Global Instantiation}
}
$$

也是：

$$
\boxed{
\text{Boundary Discovery Mechanism}.
}
$$

---

# 36. 宏觀個體與有效架構

作者既有的 Effective Architecture 理論主張：

$$
A_{\mathrm{effective}}(t)
=
\Psi(
A_{\mathrm{code}},
A_{\mathrm{runtime}},
A_{\mathrm{data}},
A_{\mathrm{ops}},
A_{\mathrm{human}},
A_{\mathrm{external}},
A_{\mathrm{compat}}
)_t.
$$

這正好說明：

> 軟體的宏觀個體不是 source tree。

Source code 是：

$$
O_{\mathrm{code}}(X).
$$

UI 是：

$$
O_{\mathrm{visual}}(X).
$$

runtime 是：

$$
O_{\mathrm{runtime}}(X).
$$

operation 是：

$$
O_{\mathrm{ops}}(X).
$$

真正的系統是：

$$
X.
$$

因此 A03 的 failure theory 與 Series B 的 macro-object methodology 形成直接接口：

$$
\boxed{
\text{A03: projection closure can fail globally}
}
$$

$$
\Downarrow
$$

$$
\boxed{
\text{Series B: dynamically reconstruct sufficient macro-object resolution}
}
$$

---

# 37. 反例：不是所有跨角色 disagreement 都值得保留

Productive Friction 不代表：

> 人越多越好。

也不代表：

> 每一個 role 都要否決一次。

如果兩個角色：

$$
O_i\approx O_j
$$

且沒有新的：

- evidence；
- failure model；
- authority；
- observation modality；

則額外 review 可能只是：

$$
\text{Redundant Friction}.
$$

因此可定義概念性的 marginal perspective value：

$$
MPV(O_j)
=
\frac{
\Delta U^{-}
+
\Delta FailureDetection
}{
Cost(O_j)
}.
$$

其中：

$$
\Delta U^{-}
$$

表示 uncertainty reduction。

如果：

$$
MPV(O_j)\approx0,
$$

則沒有理由只為「多一個角色」而多一輪 ceremony。

---

# 38. 反例：不是每一個局部缺陷都阻止宏觀完成

同樣：

$$
LocalImperfection>0
$$

不代表：

$$
C_{\mathrm{macro}}=0.
$$

例如：

- 非必要動畫可再 polish；
- 文件 typo；
- 不影響目標平台的 low-priority warning；
- out-of-scope enhancement。

所以本文不主張：

$$
C_L=1
$$

必須意味：

$$
\text{zero defect}.
$$

而是：

$$
\boxed{
\text{all critical in-scope local obligations closed}.
}
$$

也就是 closure 仍需與：

$$
\text{Scope}
+
\text{Risk}
+
\text{Intent}
$$

綁定。

---

# 39. 反例：跨邊界 closure 也不能自動證明意圖正確

即使：

$$
C_L=1,
$$

$$
C_B=1,
$$

$$
C_P=1,
$$

$$
C_E=1,
$$

仍可能：

$$
C_I=0.
$$

例如整個系統完美地實作：

> password login。

但使用者真正要的是：

> OAuth-only login。

因此 A03 不是 A01 的替代。

它只解決：

> 局部如何組成宏觀。

而最終仍需：

$$
\boxed{
\text{IntentClosure}.
}
$$

---

# 40. 典型 Failure Taxonomy

本文暫定將「局部正確與全域失敗」分成十類。

## F1 — Interface Contract Failure

資料格式、欄位、version、ABI 不一致。

## F2 — Behavioral Assumption Failure

schema 一致，但對行為的前提不同。

## F3 — Temporal Boundary Failure

ordering、freshness、timeout、retry、eventual consistency 不一致。

## F4 — Shared-State Divergence

各 subsystem 使用不同世界狀態。

## F5 — Authority Boundary Failure

誰可以 proposal / execute / promote / commit 不一致。

## F6 — Representation Failure

內部狀態正確，但外部呈現錯誤或不可理解。

## F7 — Environment Failure

local / test 環境成立，目標環境不成立。

## F8 — Human / Operational Boundary Failure

軟體流程與人類操作、SOP、support、handoff 不閉合。

## F9 — Emergent Interaction Failure

單一 component 均正確，但 interaction topology 產生未預期結果。

## F10 — Intent Boundary Failure

整合系統工作正常，但不是原始需求所要的宏觀行為。

---

# 41. 一個更完整的驗證拓撲

對 AI-native engineering，本文建議將驗證拓撲從：

```text
unit tests
→ done
```

改成：

```text
Local Closure
↓
Boundary Closure
↓
Cross-Perspective Contradiction Check
↓
Target-Environment Replay
↓
Intent Closure
↓
Completion
```

形式上：

$$
C_L
\rightarrow
C_B
\rightarrow
C_P
\rightarrow
C_E
\rightarrow
C_I.
$$

注意這不是要求所有任務都用五個昂貴 pipeline。

低風險、小範圍任務可以將某些層：

$$
\text{trivially satisfied}
$$

或：

$$
\text{not applicable}.
$$

核心要求只是：

> **不能把未檢查的層偷偷壓成 PASS。**

---

# 42. Verification Routing

令 failure hypothesis 為：

$$
H_f.
$$

系統應根據：

$$
Domain(H_f)
$$

路由 verifier。

例如：

```text
code correctness
→ compiler / unit test

API integration
→ contract / integration test

visual layout
→ visual observation

interaction
→ UI replay

performance
→ profiler / benchmark

security
→ security validation

runtime consistency
→ trace / telemetry

user experience
→ human/user-oriented evaluation
```

因此：

$$
\boxed{
\text{One Universal Verifier}
}
$$

不是理想。

而是：

$$
\boxed{
\text{Verifier chosen by failure domain}.
}
$$

---

# 43. 宏觀完成的停止條件

本文的目的不是製造無限驗證。

停止條件可以表示為：

$$
\text{Stop}
=
C_L
\land
C_B
\land
C_P
\land
C_E
\land
C_I
\land
\neg O_{\mathrm{blocking}}.
$$

其中：

$$
O_{\mathrm{blocking}}
$$

是尚未閉合的、可行動且在 scope 內的 blocking obligations。

如果：

- critical boundaries 已閉合；
- required perspectives 已覆蓋；
- environment evidence 足夠；
- intent 已對齊；
- 其餘 findings 已被分類為 deferred / out-of-scope / nonblocking；

則應：

$$
\boxed{
\text{Stop}.
}
$$

而不是：

```text
再找一個 reviewer
→ 再找一個 hypothetical issue
→ 再增加一個 requirement
```

這將直接接入 A04 / A05。

---

# 44. 本文的核心命題

本文將 v0.2 壓縮為十二條核心命題。

## P1 — Projection Non-Identity

$$
\boxed{
O_i(X)\neq X.
}
$$

角色、工具、模態看到的是宏觀個體的投影，不是完整宏觀個體。

## P2 — Projection Closure Non-Implication

$$
\boxed{
\forall i,\;V_i(O_i(X))=1
\nRightarrow
V_G(X)=1.
}
$$

## P3 — Relation-First Failure

$$
\boxed{
V(v_i)=V(v_j)=1
\nRightarrow
V(e_{ij})=1.
}
$$

## P4 — Composition Requires Assumption Closure

$$
\boxed{
Guarantee_i=1
\nRightarrow
Assumption_i\text{ is satisfied}.
}
$$

## P5 — Boundary Is Multi-Domain

$$
\boxed{
\text{Boundary}
\neq
\text{APIOnly}.
}
$$

它可以是 state、time、authority、representation、human、environment 或 intent。

## P6 — Full-Stack Non-Globality

$$
\boxed{
\text{FullStack}
\neq
\text{GlobalStack}.
}
$$

## P7 — Productive Friction

$$
\boxed{
RedundantFriction\downarrow
\quad\land\quad
EpistemicallyProductiveFriction\uparrow
}
$$

是比「所有摩擦都消失」更合理的目標。

## P8 — Test Volume Non-Coverage

$$
\boxed{
\text{TestCount}
\neq
\text{BoundaryCoverage}.
}
$$

## P9 — Multi-Role Non-Diversity

$$
\boxed{
\text{ManyRoles}
\neq
\text{ManyIndependentPerspectives}.
}
$$

## P10 — Available Modality Non-Activation

$$
\boxed{
\text{CapabilityAvailable}
\neq
\text{ObservationActivated}.
}
$$

## P11 — Macro Completion Vector

$$
\boxed{
C_{\mathrm{macro}}
=
C_L
\land
C_B
\land
C_P
\land
C_E
\land
C_I.
}
$$

## P12 — Globality Is Structured Awareness, Not Maximum Observation

$$
\boxed{
\text{Global}
=
\text{MacroAwareness}
+
\text{BoundaryAwareness}
+
\text{PerspectiveAwareness}
+
\text{TargetedResolution}.
}
$$

而不是：

$$
\text{ReadEverything}.
$$

---

# 45. 與 A01、A02、A04 的位置關係

A01 問：

> 為什麼 verifier 全綠，意圖仍可能沒有完成？

A02 問：

> 為什麼 SUCCESS / DONE 只能是一個帶 scope 的狀態聲明？

A03 問：

> **為什麼所有局部都可以正確，而組合後的宏觀產品仍然錯？**

下一篇 A04 將問：

> **當 AI workflow 不斷 planning、review、verification 時，這些活動何時開始取代真正的任務進展？**

因此前四篇形成：

$$
\text{Green Misalignment}
$$

$$
\Downarrow
$$

$$
\text{Observable Success Separation}
$$

$$
\Downarrow
$$

$$
\text{Local Correctness / Global Failure}
$$

$$
\Downarrow
$$

$$
\text{Process Proxy Misalignment}.
$$

---

# 46. 與第二系列的橋

A03 是第一系列中最直接通往第二系列的一篇。

第一系列到此得出：

$$
\boxed{
\text{局部投影的完整成功，不能保證宏觀個體成功。}
}
$$

第二系列將反過來研究：

> 那麼 Agent 如何在有限 token、有限工具、有限感知成本下，維持對宏觀個體的足夠解析度？

因此：

$$
\boxed{
\text{Failure Theory}
\rightarrow
\text{Observation Methodology}.
}
$$

A03 給出：

$$
O_i(X)\neq X.
$$

Series B 將研究：

$$
\boxed{
\{O_i\}
\rightarrow
\text{dynamic reconstruction of sufficient macro-object state}.
}
$$

這也是 APR、多模態、角色觀察算子與動態全域視角真正開始匯合的位置。

---

# 47. 結論

複雜產品最危險的工程幻覺之一，是：

> 每一個局部都過了，所以整體應該也過了。

這個推論在簡單、完全可組合的系統中可能成立；但在具有 state、timing、authority、external dependency、human interaction、multimodal representation 與 emergent behavior 的系統中，它通常需要額外條件。

因此：

$$
\boxed{
\text{Local Correctness}
\neq
\text{Boundary Correctness}
\neq
\text{Macro Correctness}.
}
$$

真正的完成不能只問：

> 哪些 component 是綠的？

還必須問：

> 哪些重要 boundary 已經閉合？

> 哪些 perspective 仍可能看到不同的世界？

> 真正 target environment 是否已重放？

> 宏觀對象是否完成了原始意圖？

在 AI 時代，這個問題更加重要，因為 AI 可以極快地產生大量局部正確 artifact，也可以用同一模型快速模擬多個工程角色。若工作流只是增加 role label、review 次數與局部 verifier，而沒有真正擴張觀察投影與 boundary evidence，就可能產生大量：

$$
\boxed{
\text{Homogeneous Green}.
}
$$

因此本文留下的最終工程原則是：

$$
\boxed{
\textbf{Do not ask only whether every part is correct. Ask whether the relations that make the parts one product are correct.}
}
$$

中文即：

> **不要只問每個部分是否正確；要問那些使所有部分真正成為同一個產品的關係是否正確。**

---

# 參考文獻

## A. 外部研究與工程資料

1. NASA. *NASA Systems Engineering Handbook*. 特別參見 Product Integration、Interface Management、Product Verification、Product Validation、Verification and Validation Plan、End-to-End Integration 等章節。  
   https://www.nasa.gov/reference/system-engineering-handbook-appendix/  
   https://www.nasa.gov/reference/5-2-product-integration/

2. NASA. *NPR 7123.1B — NASA Systems Engineering Processes and Requirements*. Interface management、integration、verification / validation requirements.  
   https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001B_&page_name=ALL

3. Binder, C., et al. (2020). *A systematic map on verification and validation of emergent behavior in software engineering research*. Future Generation Computer Systems, 112, 1010–1037.  
   https://doi.org/10.1016/j.future.2020.06.049

4. Mogul, J. C. (2006). *Emergent (Mis)behavior vs. Complex Software Systems*. ACM SIGOPS Operating Systems Review / EuroSys 2006.

5. Fiadeiro, J. L., Maibaum, T. S. E. (1995). *On the correctness of modular systems*. Theoretical Computer Science, 140(1), 139–177.

6. Cimatti, A., Demasi, R., & Tonetta, S. (2018). *Tightening the contract refinements of a system architecture*. Formal Methods in System Design, 52, 88–116.  
   https://doi.org/10.1007/s10703-017-0312-9

7. Inverardi, P., Wolf, A. L., & Yankelevich, D. (1995/1997 proceedings lineage). *Checking assumptions in component dynamics at the architectural level*. Coordination Languages and Models.

8. Dong, J., Alencar, P., & Cowan, D. D. (2000). *Ensuring structure and behavior correctness in design composition*. Proceedings of the IEEE Conference and Workshop on Engineering of Computer-Based Systems.

## B. Neo.K / EveMissLab 既有研究

9. Neo.K. 〈綠燈錯置——AI 時代「通過驗證」不等於「完成意圖」的新型不對齊〉，2026.

10. Neo.K. 〈表觀成功與實質完成的分離——從軟體表觀完好到 Agent 完成狀態語義〉，v0.2, 2026.

11. Neo.K. 〈真正的系統在哪裡？宣告架構與有效架構的分離〉，《表觀完好系統》系列，2026.

12. Neo.K. 〈從靜態 MSSP 到動態 MSSP：讓架構角色成為可觀察狀態〉，2026.

13. Neo.K. *Global Completion Theory: From Local-First Execution to Global-First Instantiation in the AI Era*, 2026.

14. Neo.K. *Global-First Completion Skill v2.x*, 2026.

15. Neo.K. *APR / Agentic Perception Runtime* 系列與統一技術白皮書，2026.

16. Neo.K. *AI-Native Game Runtime Series 08 — MSSP × TDD × APR for Autonomous Game Agents*, 2026.

17. Neo.K. 〈MSSP 的對偶：全域擾動、局部責任與結構化失敗投影〉，GACEI-02, 2026.

---

**End of A03 v0.2**