稽核
稽核不是最後一步。
九個階段裡有三個是稽核，而且它們坐在管線內部、不是接在管線後面。一本帳可以每一格都局部正確，卻作為整體失敗 —— 那正是矩陣層存在的理由。
三種範圍
- 局部
- 每筆交易對上它自己宣告的來源、運算子定義域、數值與相依。
- 矩陣
- 跨版面的列、欄、區塊與區域約束。
- 全域
- 把整本帳當成一個物件，依文件宣告的稽核政策檢查。
三種範圍分開回報，因為它們失敗的原因不同，修它們的人也不同。
有號抵消
audit_policy 裡有一個欄位值得單獨一段：signed_global_cancellation_allowed。正負相反的錯誤可以加總成零。單看全域檢查，會判這本帳是乾淨的。
在 Erdős–Straus bench 中，32 個有號殘差案例在全域層面加總恰好為零，而每一個局部錯誤仍然被定位出來。precision 與 recall：1.0 與 1.0。
這就是「即使全域數字平了，局部稽核仍必須是強制的」的完整論證。
污染與根因
出事的時候，Runtime 沿相依圖往回走，回報哪些交易可能造成它 —— 被污染的集合、根節點，以及兩者之間的路徑。
- 反向查詢權重反向因果
- 局部正確的計算可信的計算 —— 它仍然可能吃進一條不可信的宣告通道
修復
修復分析提出與約束一致的最小變更集。它是一份提案，而且交到人手上。
- 一份修復提案自動就是那個唯一的真實世界根因
- 最小支持集修復對歷史錯誤的識別
補帳只追加
corrections 區段只追加。一筆補帳不會去改它所修正的那筆交易，它是一筆參照對方的新紀錄。原始紀錄留在帳裡、也留在可稽核狀態 —— 這正是它之所以叫「帳本」的原因。
雜湊
每次執行都產出正規化 JSON、一個語意雜湊、一個執行雜湊、一份事件日誌與一份清單。在同一個 runtime 與運算子鎖、決定性模式下重跑，雜湊可以重現。
當語意、正規化或稽核輸出的缺陷被修掉時，Runtime 升級可能刻意改變某個雜湊。相容性要用清單、runtime 版本、運算子鎖與遷移快照來檢查 —— 不要只看一個雜湊。
- 雜湊鏈區塊鏈共識、可信時戳，或獨立公證
雜湊讓一次執行可以跟它自己比對。它們沒有任何一點讓一次執行可以拿去跟關於外部世界的主張比對。
退出碼
這支 CLI 是設計來被接進別的東西裡的。失敗依種類區分。
| 代碼 | 意義 |
|---|---|
0 | 指令完成 |
2 | 用法、驗證、遷移或明確的組態錯誤 |
3 | 稽核或比對失敗，且指令要求傳播失敗 |
4 | 未預期的內部錯誤 |
代碼 3 存在的意義是：不要把「稽核沒過」跟「指令打錯」混在一起。--fail-on-audit 就是把稽核結果轉成行程退出狀態的那個開關。