Day 23,我把 5 種情境、15 組案例整理成同一個 evidence bundle,也保留了工具原分類。今天輪到 AI 報告:Day 11、13、15、17、19 都曾把實驗證據整理成固定 JSON 結構,也留下 validation.json。問題是,那個「通過」屬於當時的檔案與當時的程式;如果我只把舊布林值搬進作品,無法知道報告現在是否仍符合現行規則。
Day 24,我固定 5 個報告批次,逐案重跑各日 validator,並將報告、證據、Schema、舊驗證紀錄與驗證程式本身的 SHA-256 綁在一起。同時,我另外索引 5 份作者語意核對,避免把「格式可解析」寫成「內容已核准」。
每個報告日可能有多次執行紀錄。Day 11 就保留第一次與第二次回答;若發布流程只依檔案修改時間挑最新資料,複製檔案或還原備份都可能改變選擇。因此,我在 release.json 明確指定 5 個批次:Day 11 的 live-v2-20260925、Day 13 的 live-20260927、Day 15 的 live-20260929、Day 17 的 live-20260930,以及 Day 19 的 20260930-011610-9f86cb4f。
工作台先讓 Day 20 找到和實驗摘要 SHA-256 相符的 API 批次,再要求該路徑必須等於 release.json 固定的來源。路徑不一致就停止,不會悄悄換成另一份也曾通過的回答。每個批次的 run-summary.json 也會重新計算 SHA-256,寫進 bundle。
15 組案例各自載入:
evidence.json:模型當時收到的結構化證據。schema.json:報告預期符合的資料結構。report.json:模型產生並解析後的報告。validation.json:當時留下的自動驗證紀錄。我先確認舊 validation.json 的 passed 為 true,但不在這裡停下。工作台接著載入現在的 run_reports.py,Day 11 呼叫 check_day11_report(),Day 13 呼叫 check_day13_report(),Day 15、17、19 則呼叫各自的 check_report(),將 report、schema 和 evidence 重新送進現行檢查函式。只有錯誤清單仍為空,案例才得到 status: revalidated。
這次 15 組全部重驗通過。每組結果都保存 4 份輸入檔的路徑與 SHA-256,也保存 validator 路徑與 SHA-256。總計有 60 筆 artifact 綁定,以及 5 支 validator 的版本指紋。以後若報告文字、證據、Schema、舊驗證檔或驗證程式其中之一改變,bundle 就會跟著改變,不能再用同一個完整性識別碼冒充原結果。
每個固定批次旁都有一份 semantic-review.md。工作台確認檔案存在,記錄路徑與 SHA-256,狀態寫成 author_review_recorded。我故意沒有把它命名為 approved,也沒有因為檔案存在就把內容轉成通過。
實際打開紀錄,差異很明顯。Day 11 的弱點組雖然分類與雙重訊號正確,作者仍將過度擴大的可能影響標為 changes_required。Day 13 除了弱點組影響寫得太廣,也指出純文字組把實際雙引號字串描述成單引號。Day 15、17、19 同樣保留「固定探針」和「可能影響」之間的界線。這些都是 JSON 結構通過後才看得出來的問題。
因此,bundle 同時呈現 automatic_report_validation.status: revalidated 和 semantic_review.status: author_review_recorded,但兩者沒有誰自動升級誰。讀者若要引用模型的自由文字,仍要沿著 review 路徑閱讀作者判斷,而不是看到自動驗證通過就直接發布。
我沒有沿用先前產生的 dist/ 當作本日答案,而是把現行程式輸出到新的暫存目錄,再對同一個目錄執行 verify。驗證器會重讀來源、重建 bundle、Markdown 與 HTML,逐位元比對輸出,再核對 manifest 的檔案 SHA-256 與 release ID。
本次暫存建立與驗證通過,15 組報告均重新驗證,5 份作者紀錄也都被索引。正式 dist/ 留到作品完成日再建立,避免 Day 24 的階段性結果提前冒充最後發布版。
Day 24 的成果,是替 AI 報告建立可回查的自動層與語意層:前者能重跑、能比對雜湊,後者保留人對措辭和證據範圍的判斷。明天,我會把這些資料收進單一操作流程與安全的離線報告,開始替 Day 26 的作品完成日做準備。
那就…
明天見!