假設有一段用來測試的文字：「我最近不太想說話。」這句話沒有交代原因，也沒有說明對方希望得到什麼回應。如果系統把它整理成「使用者因人際挫折而情緒低落，希望獲得建議」，摘要雖然更完整，卻多出了原文沒有提供的資訊。

這是我在設計「從心出發」時想避免的情況：輸入仍然模糊，到了回覆階段卻已經變成一個確定的故事。後面的元件可能照著摘要認真工作，問題卻從前面的資料轉換就開始了。

上一篇談 Counselor / Supervisor 的審查設計，留下「審查者還無法判斷時，系統要怎麼辦」這個問題。今天我想先往資料裡看：不確定性（Uncertainty）要如何被記錄，才不會在摘要、決策與改寫之間消失？

空白需要有自己的意思

在目前檢查的 PsychologicalState 中，意圖與風險都有明確的 UNKNOWN 值。從空資料建立狀態時，這兩個欄位會維持未知；輸入未被列舉的意圖或風險名稱，也會保留為未知，不猜成某個已知分類。

這個選擇會影響下一步能做什麼。使用者沒有表達需求，與使用者明確希望整理問題，是兩種不同的輸入。若為了讓流程容易繼續，就把缺少的意圖補成「解決問題」，後續回覆可能直接開始給建議。

不過，只有一個 UNKNOWN 還不夠。尚未提供、解析失敗、資料互相衝突，以及舊資訊可能已失效，都可能使流程無法判斷，但它們需要的處理方式不同。我規劃讓未知狀態帶著原因與對應欄位，避免接手的元件只看見一個空值，卻不知道缺了什麼。

例如，未提供的需求可以等待使用者補充；兩段內容不一致時，應先保留各自的來源與時間。這些是接下來的設計方向，今天沒有完整的未知原因傳遞測試可以證明它們已經串起來。

先記清楚，這句話是誰說的

現有的 StateSignal 把一項訊號拆成 value、source 與 confidence。其中 source 能區分使用者陳述與系統推測，序列化輸出也會留下這個欄位。

以開頭的合成例子來說，原文只支持「最近不太想說話」。若系統推測可能與人際互動有關，這個推測就應保留推測身分。即使下一輪又引用它，也不應因為多轉述了一次，就變成使用者親口確認的事實。

我希望未來的摘要流程能保留這種差別：哪些是原始陳述、哪些是系統整理、哪些仍待確認。摘要的任務是縮短內容；我不希望它順便替缺失資訊作決定。

目前的來源欄位提供了一個起點。但欄位存在，還需要後續程式正確使用。今天的局部測試能確認兩種來源可被區分與輸出，尚未驗證經過模型摘要、資料儲存與重新讀取後，這個區別仍然完整。

一個小數不能代替解釋

資料契約也有 uncertainty 欄位，預設為 1.0，並檢查輸入是否位於零到一之間。這讓程式能明確接收不確定程度，不必把它藏在一段自由文字裡。

但在這次檢查的契約與測試中，我沒有取得這個數值經過校準的證據。因此，我不會把它換算成模型答對的機率，也不會把它當成對一個人心理狀態的測量。通過數值範圍檢查，只能說資料符合程式要求。

我更在意的是：系統究竟對哪一件事不確定？它可能不清楚使用者的需求，也可能缺少來源，或者還沒有完成回覆審查。即使都填入相同數值，下一步需要補的資料也可能完全不同。

因此，我規劃讓數值旁邊保留可追溯的原因：對應哪個問題、目前依據什麼、還缺少什麼。至於各欄位是否需要數值，以及數值如何產生，仍須各自驗證。先有一個欄位，不能直接推導出它適合呈現給使用者。

不確定增加時，權限要跟著收緊

如果未知只被記錄，卻完全不影響行為，系統仍可能照常送出確定的建議。目前的 authority_for() 已有局部的限制規則：未知風險會對應受限回覆；不確定數值缺失或不合法時，也會採保守的預設。

以下片段來自 src/psychological_support/safety/policy.py，是現有函式的一部分：

    if normalized_risk is RiskLevel.UNKNOWN:
        return AuthorityLevel.LEVEL_4_RESTRICTED_RESPONSE
    if normalized_uncertainty >= 0.75:
        return AuthorityLevel.LEVEL_4_RESTRICTED_RESPONSE

這裡的門檻是目前程式的政策設定，這次檢查沒有證據支持它是經驗證的最佳數值。這段程式值得保留的設計意圖，是資訊不足時縮小可採取的動作，而不是讓流程自行補出一個肯定結論。

這次重新執行的 7 項既有本地測試全部通過，涵蓋未知值、來源區別、不確定數值限制，以及風險與不確定性對權限的影響。它們使用合成資料，支持的是資料契約與政策函式的特定行為。

要證明完整流程確實遵守限制，還必須檢查呼叫端是否使用這份決策，以及最後送出的文字是否仍符合它。今天沒有執行從輸入、生成到畫面呈現的完整驗證，也沒有真實模型或使用者效果結果。

把不知道的範圍說清楚

本日尚未完成此部分，以下先整理目前設計與下一步。完整的不確定性傳遞與對外說明仍為 Planned；目前可確認的是上述資料與政策層的局部行為。

我規劃的回覆方式，會指出缺的是哪一塊資訊，再依當下允許的範圍決定如何繼續。對開頭的合成例子，可以設計一個回覆測試：它是否承認尚不清楚原因，並讓使用者選擇要繼續說、整理想法，或暫時停下？這是待驗證的互動設計，沒有實測效果可供宣稱。

接下來也需要刻意測試限制被省略的情況：摘要是否刪掉「尚未確認」、重新載入是否把未知改成預設分類、審查逾時是否被當成沒有異議。我要追查的，是每一次轉換之後，缺少的資訊是否仍然被視為缺少。

「從心出發」的這些狀態只服務於非診斷性的支持流程，不能延伸為心理治療或專業判斷能力。對我而言，讓系統說清楚判斷的範圍，是後續設計能被檢查的前提。

而當對話跨到下一天，昨天留下的推測又該怎麼保存？如果記憶只留下結論，卻遺失來源、時間與尚未確認的部分，不確定就可能在下一次對話中悄悄消失。這也讓下一個問題自然浮現：長期記憶應該留下什麼，又有哪些內容根本不該保存？