本文聚焦 harness engineering 信任鏈的核心：Evidence（證據） 與 Attestation（獨立確認）。兩者分別回答「在已定義的檢查條件下，結果是否符合預期」與「這些證據是否足以支持產出符合需求意圖」。
前言
有了綁定好的合約之後，下一個問題是：agent 交出東西之後，如何證明它真的符合合約？
這時很容易想到：既然 LLM 可以產出程式碼，那就再請另一個 LLM 進行 review，協助找問題、補充測試方向，或提供審查意見。這種做法有價值，但不能單獨成為最終放行依據。
換另一個 LLM，不會自動把帶有機率性的判斷（probabilistic judgment）變成可重現的 Evidence。不同模型、prompt 與工具仍然可能提供有價值的 review，但判斷也可能受到模型版本、context、推論結果與提示方式影響。
LLM 的審查是判斷，不是證明。它可以參與 Attestation，但不能只因為它說 OK，就把這句話直接當成 Evidence。
所以驗收這件事，可以拆成兩個角色不同的半場：可重現的檢查負責產出 Evidence，與產出角色分離的審查者或審查機制負責 Attestation。兩者都不能被繞過，也不能互相取代。
上半場：驗收即證據（Evidence）
先講機器這半場。這裡的重點是可重現性。
為什麼要可重現
證據的價值，來自它能在固定版本、執行環境與參數下重跑，得到可以比較的結果。驗收檢查需要把這些條件固定下來：
- Evidence 要綁定實際被驗收的 source revision，例如對應的 commit / tree 與必要的 diff，不只是假設某個 branch HEAD。
- 固定工具與 runtime 版本、依賴版本、執行參數、設定、輸入與必要的環境條件，並把這些資訊記錄進 Evidence。
- 必要 gate 的通過與否，不由單一 LLM 判斷決定；LLM review 可以作為審查輸入或輔助。
Evidence 可以證明產出在已定義的檢查條件與範圍內符合預期；這個結論只涵蓋被指定的版本、環境、輸入與驗收條件，不能證明所有未被覆蓋的情境都正確，也不能延伸成整個系統完全正確。
證據要綁定確切版本
每份 Evidence 都應該綁定實際被驗收的 source revision，例如對應的 commit / tree、必要的 diff，以及工具與 runtime 版本、執行參數和相關的環境條件。若工作目錄仍有未納入版本控制的變更，這些狀態也必須被拒絕或明確記錄。
如果證據跟實際被驗收的 source revision 脫鉤，就會出現「拿舊證據闖新關卡」的漏洞：驗收結束後又修改程式碼，卻繼續沿用剛剛那份「通過」的證據。只要對應的 source revision 改變，舊 Evidence 就不再對應目前版本，不能直接沿用。
fail-closed：必要 gate 有疑慮就擋下
對被治理規則定義為必要 gate 的驗收項目，如果結果缺失、執行失敗或狀態無法確認，預設應該擋下（fail-closed），不能把未知狀態當成通過。哪些項目屬於 blocking gate，仍然要由風險與治理規則決定；屬於 advisory 的檢查，即使 timeout，也不一定要阻擋所有流程。
下半場：審查即獨立確認（Attestation）
機器證據很重要，但它的適用範圍仍然取決於已定義的檢查條件：
Evidence 能證明產出在已定義的檢查條件與範圍內符合預期，但不能延伸成整個系統都正確。
測試全綠，不代表需求被完整滿足；靜態檢查通過，也不代表架構沒有走歪。判斷「這份產出是否真的達成了合約的意圖」，仍然需要由與產出角色分離的審查者或審查機制進一步確認。這半場稱為「獨立確認（Attestation）」。
LLM reviewer 可以參與這個階段，提供 findings、風險提示或補充測試方向；但產出方的自我評分，不能成為唯一的 Attestation。
「獨立確認」跟「隨手按個 approve」的差別，在於它要求留下可被檢驗的紀錄：
- 帶引用的 findings（cited findings）：審查者指出的問題，要指到具體的檔案與行號，不能只留下一句「感覺怪怪的」。
- 產出方的回應：每一條 finding 是否已處理，以及採取了什麼處理方式。
- 逐條的需求覆蓋（requirement coverage）：對需要正式 Attestation 的變更，應能確認每項受治理需求都有對應的 Evidence、審查結果，或明確標示為不適用（N/A）。
合約裡寫下的 acceptance criteria，這時候成為審查時的對照清單。高風險變更可以要求完整覆蓋；風險較低的工作則可以採取較輕量的方式，但例外與 N/A 都要留下清楚紀錄。
一個實務難題：重審循環
一個下游任務已經完成審查並核可，但上游合約出現實質變更，原本的 Evidence 與核准結果就不能直接視為仍然適用。是否需要全部重跑，應該透過影響分析與治理規則判斷，不能只看「上游有沒有改過」。
如果上游只修改不影響合約的 metadata，卻機械式觸發下游整條鏈重新審查，治理就會變成負擔。這也呼應上一篇提到的原則：合約要綁在對的層級，實際影響範圍則要先判斷清楚。
總結
驗收流程裡有兩個不同的部分，放行則是另一個問題：
- Evidence（證據）：由可重現檢查產出，綁定實際被驗收的 source revision 與執行條件；回答「在這些已定義條件下，檢查結果是什麼」。
- Attestation（獨立確認）：由與產出角色分離的審查者或審查機制進行，確認 Evidence 是否足以支撐受治理需求，並補足 mechanical checks 沒有完整覆蓋的設計、意圖與風險判斷。
- Authority（授權）：決定誰有權 merge、publish、deploy 或正式放行；即使 Evidence 與 Attestation 都完整，也不會自動取得這些權限。
審查通過不等於可以合併或上線，因為驗收與授權是兩個不同的決定。