假設有人昨天說：「最近因為考試睡不好。」今天又說：「考試結束了，但還是睡不好。」這是說明設計的假想例子，不是真實使用者紀錄。如果系統只是把兩段話一起塞回提示詞，它要如何知道，哪些資訊仍有效，哪些需要重新理解？

我今天要處理的，就是這種「記得之後怎麼辦」的問題。對心理支持而言，保存更多文字並不足夠；舊資訊若一直被當成現在的事實，後面的建議也可能跟著過期。

Day 02 留下的模型身分問題仍受外部證據阻塞。這篇沒有取得新的模型資格，而是整理 2026-08-31 到 2026-09-01 凌晨，以 Phase 2I 封存為主要終點的工程：先把不依賴模型的狀態、保存與資料契約做清楚，再談心理介入。本文引用既有測試紀錄，寫作時沒有重跑產品測試或呼叫模型。

對話不能只有不斷追加的文字

Phase 2A 建立了 conversation state，也就是「此刻有哪些資訊可以使用」的結構化狀態。更新由 reducer 處理：給它原狀態、事件與明確時間，它依規則產生下一個狀態。相同輸入得到相同結果，不靠模型臨場決定要留下什麼。

我把來源、效期和修訂關係放進契約。Provenance 是來源紀錄，區分使用者明說、系統推測與安全規則產生的訊號；expiry 表示有效期限；supersession 則記錄哪一筆取代了哪一筆。

拿開頭的例子來說，可以用下面這個概念表理解。它不是實際 JSON，也不是程式已經能自動理解兩句話的證明。

目前主題與修訂對象由呼叫端明確提供，reducer 不會自行從自然語言推論「考試已經不重要」。它能檢查修訂是否合法，還不能替我理解整段人生。

安全狀態也獨立保存。一般資訊被修正，不應順便抹去仍有效的危機或高度困擾訊號。另一方面，過期只是停止把資料當成有效上下文，並不等於原始文字已被刪除；真正的刪除，還需要儲存層處理。

寫進記憶體，還不等於重啟後可信

Phase 2B 先以 RAM，也就是程序執行中的記憶體，建立有容量上限的參考儲存。每筆資料有擁有者、保存同意與版本限制。兩個更新若都拿舊版本來寫，後到的更新不能悄悄蓋掉前一筆。

這讓我能檢查狀態更新的規則，卻還不能回答：程序關掉，再打開呢？

Phase 2D 接上 SQLite 本機資料庫，把對話狀態、同意與控制資料放在同一個交易裡，提交完成才回報成功。交易的意思是，這批互相依賴的更新必須一起成立，不能只存了對話，卻漏掉已撤回的同意。

重啟後也不是讀到東西就算成功。資料損壞時，一般讀寫先拒絕繼續；受控的破壞式恢復另有權限與流程，不能假裝把遺失內容修好了。撤回則要走到資料移除與完成回條，不能只改一個畫面上的標記。

這些證據支持的是有界對話資料的本機保存與恢復語義，不是所有未來心理物件都能持久保存，也不是備份、磁碟抹除或正式環境的全面保證。

模型可以換，狀態與安全不能跟著失去規則

儲存之外，還要有人決定誰能讀、誰能改。Phase 2C 的可信協調層要求由受信任的解析器提供身分，不能只因請求帶了一個 owner 名稱就相信它；同意、版本與資料歸屬仍交由既有契約檢查。

Phase 2E、2F 再把這些元件組合起來，建立本機服務的設定、生命週期與供應端邊界。模型供應端負責生成文字，不因此取得修改核心狀態或安全規則的權力。外部傳輸回報成功，也不能變成使用者同意或心理狀態已改善的證據。

這裡的 production composition 指的是朝正式服務形狀組裝元件，驗收仍限於離線參考實作。正式身分與存取管理（IAM）尚未接入，Luna 的正式模型資格也沒有因此通過。必要條件不明時拒絕放行的 fail-closed 原則，仍然保留。

加入知識之前，先決定資料怎麼失效

接著是 Phase 2G。RAG 會先檢索資料，再讓模型參考；但找到相似文字，只回答了「找到了什麼」，沒有回答「現在還能不能使用」。

我在這一層先建立資料導入、統一表示、向量整合與 embedding 的契約。Embedding 是供相似度搜尋使用的數值表示；它不能替來源授權背書。資料仍須保留來源、版本、效期、撤回狀態與 provenance，不同用途也要透過 namespace，也就是資料命名空間，維持隔離。

同一段文字，即使內容完全相同，也可能來自不同來源版本。若後續只能依文字找到資料，卻無法指出是哪個版本，就可能不知道該撤回哪一筆。這是先做版本契約的理由，不是宣稱心理學資料庫已經建好。

當時的 ARCI mapping 只是離線對應契約。ARCI 是預計整合的檢索與治理系統；我把不能丟失的來源資料放在 mandatory sidecar，也就是必須隨資料保留的附加結構中。問題在下一輪才真正浮現。

接得上格式，不一定接得上語義

Phase 2H 實際檢查 ARCI 的 R2H、R2I 契約時，原生入口拒絕這個附加結構。拒絕發生在資料入口，還沒進入檢索排序。

刪掉 sidecar，看似可以往前走。但診斷也顯示：來源版本不同、其餘內容相同的資料，拿掉它後會變成完全相同的原生文件。資料可以送入，版本差異卻消失了。

所以那一輪留下 BLOCKED_ACCEPTANCE。意思是驗收受阻，不是診斷沒有做完。我不能一面要求版本可撤回，一面在接線時把版本資訊丟掉。

故事也沒有停在這裡。後續 2H-R1 在隔離的 ARCI 工作副本加入有明確型別的 source_context 擴充，從心出發再用 bridge 轉換完整來源資訊；舊使用方式未提供擴充時，仍保留原行為。它取得的是離線契約相容性 READY，沒有回頭改寫前一輪的失敗。

截至 2I 封存，跨專案 live 驗收所需的 2H-R2 READY 證據仍未取得。契約修訂、真實後端驗收、正式移轉，是不同的完成條件；這裡沒有 live vector 整合或上線的宣稱。

從一段回答，走向可以被檢查的介入候選

做到這裡，產品方向也更明確了。我想做的是「數位心理支持＋結構化自助介入系統」：降低不知道從哪裡開始的門檻，幫助人整理困擾、形成可修正的問題假設、確認目標，再逐步走向練習、生活中的行動、結果觀察與必要時尋求真人支持。

這是願景。Phase 2I 實際提供的是離線 foundation：知識與介入契約、版本化 registry、適用條件、禁忌、求助升級、目標、嘗試和結果紀錄的表示方式。Registry 像一份有版本規則的目錄；登記其中，不代表已允許拿來對真人執行。

以下實線只表示離線參考流程，虛線是尚未接入的產品目標。圖中省略各檢查的內部先後順序，不能把它當作已部署架構。

flowchart TD
    A[已確認目標與有界情境] --> B[版本化 registry：合成資料]
    B --> C[來源、版本、效期、適用性與安全檢查]
    C --> D[不合格：空集合或拒絕]
    C --> E[合格候選：離線輸出前重驗]
    E -. 尚未接入 .-> F[真人練習與生活行動：規劃]
    F -.-> G[結果追蹤與問題模型修訂：規劃]

候選不能只靠相似度高就被選中：未知資訊不當成肯定，來源撤回或版本失效就不放行；沒有合格項目可以回空集合。輸出前還會重新檢查，避免把先前拿到的候選當成永久許可。這些參考行為目前只接受合成資料，候選的 production_use_allowed 固定為 false。

問題假設也保留推測身分。使用者確認一個解釋，不會把 AI 推測自動改成使用者原本陳述的事實；假設可以拒絕或修訂。結果觀察則只描述自報變化，不把變化歸因成介入療效。

2I 最終紀錄是 focused tests 50/50、全 repository tests 817/817，前者包含在後者內；另有 500 次離線情境重播。重播涵蓋目錄解析、適用性、撤回、版本取代與輸出重驗，各自重複檢查結果是否一致。這些都是工程結果，10 組 synthetic 範例也不是心理學實證資料庫，更不是臨床試驗。

這還不是心理支持產品的完成

目前能分開說的是：願景已有方向，架構已有契約，離線參考行為有實作與測試；取得資格的範圍，仍限於那些受控條件。

2I 封存時，新介入物件的持久保存與重啟恢復尚未實作，也沒有執行練習的引擎或完整追蹤循環。封存之後，工作區已有 2J 的實作與測試紀錄，所以不能再籠統寫「2J 尚未開始」；本篇不替那項後續工作宣布完成。

大規模心理學知識導入、live ARCI／向量驗收、正式模型資格與正式部署，也都不能從這份離線成果推得。系統尚未做臨床療效驗證，沒有證明能診斷或治療心理疾病，更不取代心理師、精神科醫師或醫療服務。

下一個問題因此很具體：當目標、假設與練習紀錄開始被保存，重啟、修訂或撤回之後，它們能否繼續遵守同一套規則？要往介入前進，我還得先讓每一筆紀錄說清楚，自己憑什麼仍然有效。