開場： 上週我後來覺得我沒有把新版跟舊版真正差在哪裡講清楚。 這次我想先把整條流程攤開，特別回答三件事： 1. 哪些地方是 LLM？ 2. 哪些地方是 static / deterministic？ 3. 如果兩個問題很像，系統怎麼不套錯規則？

這頁不要先講版本名或 H2X/H2Y。 這一頁只負責導覽：今天會回答哪三個問題。 真正的結論留到後面比較完舊版流程、失敗案例和新版流程再講。

把這頁當成一條完整 pipeline 看： 上半部是法規端，通常在規則庫建立時預先處理； 下半部是 runtime 的使用者案件。 兩條線不是兩套系統，而是規則判定所需要的兩個輸入。 下一頁開始固定左邊規則端，只放大 user input → facts 這一段，比較舊版和新版的差異。

用精簡 JSON 回答老師「Schema 實際長什麼樣子」。 不是完整 schema dump；Rule 只留下 subject + condition，Facts 留下三個直觀欄位。 實際 Rule Schema 還有 source / effective / effect / citation / evidence_span 等欄位，口頭補充即可。 下一頁再進入舊版：這些 runtime facts 到底怎麼從 user input 建立？

舊版核心 runtime 可以很簡單地說成兩次 LLM： 1. 選 topic。 2. 把使用者原文抽成這個 topic 所需 facts。 接下來才是 deterministic rule engine。

這頁先只回答 runtime authority path，不在這裡解釋 grammar coverage。 講法： LLM 還是有用，負責從自然語言找出可能重要的 exact span。 但 evidence nomination 本身沒有 semantic authority。 後面還要經過 reviewed semantic grammar、case/request ownership proof， 最後才由 static applicability 決定精確 scope 是 MATCH / NO_MATCH / UNKNOWN。 V1 的 topic / facts 一旦由模型產生，就已經能影響後面的 deterministic rule engine； V2 把這個 authority 拆開，模型只保留 proposal/evidence nomination 的角色。

老師如果問「關鍵詞怎麼來」： 目前是 reviewed finite semantic grammar，不是 runtime 由 LLM 自己定義。 例如 BC08 登錄口試相關 target、amount/headcount question forms， 並且有限制排列、連接與 guard。 這裡要主動承認 trade-off： 目前設計提高可驗證性，但 coverage 是 partial。 不能宣稱 arbitrary natural language 已經解決，也不能宣稱 V2 end-to-end 一定比 V1 準。 未支援 mapping 保持 UNKNOWN。 後續值得研究的方向是： LLM 可以重新負責 semantic proposal 或離線 paraphrase discovery， 但 online proposal 必須再被 deterministic validation 或 clarification 確認後才取得 authority。

這頁用來回答：為什麼要把 semantic authority 從 LLM 拆出來？ 先看上面： 第一句問博士口試費金額。 第二句雖然多了「國科會計畫」，真正的 question 還是金額標準； 不能因為文字出現國科會，就自動增加 funding scope。 第三句才真的在問「國科會經費能不能支付」，因此 exact legal issue 才換成 funding eligibility。 Batch03 fresh 36 cases： family exact 36/36； exact scope 31/36。 5 個原本應維持 family-only / exact scope 未決的案例，模型 5/5 全部 over-nominate 相近 scope。 重點不是說 LLM 不會分類。相反地，大類判斷非常好。 危險在於它會在資訊不足時多走最後一步 semantic inference： 「看起來很像」被轉成「法律上就是這個 scope」。

講法： 上一頁發現 LLM 在 scope 未決時會多推一步。 第一個合理修法不是拿掉 LLM，而是把任務拆細： LLM 不直接選 scope，只逐條回答 requirement 是否成立，再由 server deterministic 組 scope。 但 replay 後 31/36 -> 26/36，而且原本最想修的 5 個 overreach case 5/5 全部仍存在。 所以 failure mode 沒被修掉。 關鍵：即使 scope ID 最後由程式組出來， 「這句話是否滿足 funding / amount / headcount requirement」仍是 semantic judgment， 而這個 yes/no 還是 LLM 在拍板。

這頁不要再重講完整新版 pipeline；前面已經講過。 只講 H2V3 實驗帶來的 architecture conclusion： 如果 requirement 的 semantic yes/no 還是 LLM 拍板， 即使後面 projector 是 deterministic，authority 問題仍然存在。 所以真正改的是 authority boundary： LLM 保留自然語言的 proposal / evidence nomination 能力； typed semantics、ownership、exact applicability 必須另外取得 reviewed/static proof。 接下一頁： 既然「使用者在問什麼」「案件事實是什麼」「這個值屬於誰」不能再混在同一個模型理解結果， Schema 本身也必須拆開。

這頁接前一頁 authority boundary。 舊版 topic + facts 並不是沒有 schema，而是一次模型理解會同時承擔多個 semantic responsibility。 新版把它們拆成： 1. request_intent：使用者此刻在問什麼。 2. scenario_facts：案件本身有哪些事實。 3. ownership proof：某個值是否真的屬於目前 case / request。 例子： 「這筆口試費每人 2000 元，我只想問委員人數標準。」 2000 是 scenario fact，但 request_intent 是 headcount，不是 amount。 另外： 「另一組博士口試費每人 2000 元，我這組委員人數標準是多少？」 2000 雖然存在於原文，但不能借給目前案件。 因此 schema 拆分不是為了資料結構漂亮，而是把 authority boundary 寫進資料模型。

這頁回答老師上週最核心的問題之一： 如果兩條規則字面很像，怎麼避免配錯？ 系統不是把兩條規則拿去算 similarity，然後選最像的一條。 前面已經把使用者問題拆成 typed observations： target = 論文口試 degree = 博士班 question = 金額標準 接著每個 reviewed exact scope 各自跑自己的必要條件。 博士金額/人數 scope 的條件成立，所以 MATCH。 funding scope 不只需要看到「國科會」，還需要證明使用者真的在問「國科會經費能否支付」。 這個 observation 不存在，所以 NO_MATCH。 如果必要資訊不足則是 UNKNOWN，不挑最近的一條。

收尾不要把目前研究講成已經 qualification complete。 目前 accepted 的是 architecture boundary： LLM 不擁有 legal semantics / scope / claim / rule / verdict / ownership。 缺少 positive proof 時 fail closed / UNKNOWN。 ownership 分開證明。 但 finite semantic grammar 仍 partial，Level 1/2 尚未 closed，Level 3/V3 no-go， 所有 executable families 目前也沒有 activation qualification。 所以不能說任意自然語言已覆蓋，也不能說新版 end-to-end accuracy 已經證明優於舊版。 185 structured rules 也不等於 185 條都完成 source-to-rule semantic equivalence proof。

這頁是 discussion，不是宣稱已有解法。 目前 finite semantic grammar 的研究結論仍是 partial。 如果看到一個新句型就補一個 pattern，會逐漸走向 corpus tuning / overfitting， 因此不能把「繼續補 grammar」當成完整研究路線。 可以固化的是可泛化的機制，例如： - reviewed numeric normalization - request focus / negation 等一般 relation - case / request ownership relation 真正想討論的下一步： 是否讓 LLM 保留 semantic proposal 的泛化能力， 但 proposal 本身沒有 authority，必須有另一個獨立 validation boundary 才能接受。 meeting 後另一個決策問題： 先做 coverage research，還是先用 development preview 做 exploratory / unseen testing， 收集 failure taxonomy 後再決定 bounded checkpoint。

這頁只講執行順序，不再新增 architecture。 如果老師接受前一頁的研究問題： 1. 下週先 demo 現有 development prototype。 2. 若基本效果可用，開始小規模 internal exploratory testing，再逐步做受控外部測試。 3. 使用者不要被教成 schema-friendly 問法；要保留自然表達。 4. 收集 trace 與 failure taxonomy，不把 pilot 當即時 training loop。 5. 工程 bug 可以修；semantic failure 先累積，判斷能否抽象成一般機制。 6. 再用真實 failure distribution 決定 finite grammar coverage research 或 semantic proposal + validation checkpoint。 這仍是 research prototype / exploratory pilot，不宣稱正式報支權威或 qualification。