這條規則管用嗎？由個案中找答案，經有名字的程序去改

GembaOS 是企業 AI Agent 的治理執行平台：以政策判定權限、以綁定參數的單次放行令授權每一個動作、以可追責的簽署鏈記錄人的審批，部署於企業本地機房或私有 VPC。

自動檔位是公司下的一個判斷：金額在這個數以下、風險在這個水平以下，就不必有人簽批。「大部分退款都按規則放行了」，是檔位運作良好時的樣子，也是檔位已經不再把關時的樣子。單看數字分不出來。這篇說明 GembaOS 怎樣幫對規則負責的人分辨是哪一種，以及需要改的時候怎樣改。

界線和〈可被查詢的公司〉那篇一樣：在獲授的權限之內，Agent 可以愈做愈好；權限本身——誰簽、甚麼條件下可以不經簽批便放行、可以碰甚麼——只經第二人批准的發佈改變。下面每一樣都是為那個人準備材料，沒有一樣會自己改變權限。

1. 問負責這項決定的人

GembaOS 以雜湊抽出無人簽批而放行的決定，逐宗交給負責的職位。抽查人看到的是決定當時面前的資料：操作、參數、讀到的風險與事實、放行它的規則，以及確認這條規則的人。之後發生的事不會顯示，因為要問的是當時的決定，而不是結果。

問題每次都一樣：如果當時由你判斷，你會同意不經簽批便放行嗎？答案只有三種：會同意、不會同意、無法判斷。答「不會同意」要從 playbook 宣告的理由清單選一項，再寫一句話。答案以抽查人的名字記錄；兩人意見不同，就是兩條紀錄，不投票。提出這張工單的人不能抽查它。

答案不會改變任何規則，只會被點算。

2. 看個案結束之後的事

以往個案的紀錄在執行那一刻就結束。現在 playbook 可以寫明結束後要看甚麼，來源只有三種：結束後若干日讀一次系統的某個欄位、同一對象其後再來的工單數，或由指定職位的人錄入。未到期、讀不到、判斷不了的，維持未知，不當作好結果；同一個結果不會重複計，也不會觸發任何動作。

3. 跨個案發問，限於自己能讀的範圍

「上個月的退款做得怎樣、抽查人怎麼說？」由唯讀操作回答，以提問者的權限執行。答案按業務分組，從不按個人或客戶分組；只數提問者本來就能讀其資料的業務。公司可以設定最少顯示宗數，低於這個數就不顯示；沒有設定的話，答案會註明。每個答案都寫明看不到的部分：GembaOS 未接入的渠道、提問者看不到的業務，以及抽查是雜湊抽樣、不是比率。

4. 留意輸入變了

檔位條件只能經發佈改變，而發佈會經過檢查和簽批。發佈看不到的，是條件不變、輸入卻變了：上游系統重新校準風險分數，落在界線以下的個案多了，無人簽批的比例就會上升——和檔位運作良好時一模一樣。

playbook 可以寫明這個比例容許變動多少。GembaOS 每天逐條路線，比較最近一段時間與前一段時間無人簽批而放行的比例；越過幅度，就在缺口登記冊給業務負責人開一條紀錄，列出兩個比例，並寫明兩段時間的規則版本是否相同——相同就是輸入變了；不同就是發佈移動了檔位，負責人要確認這是否本意。它不會收緊任何東西。

5. 讓規則自己寫明何時停下

紀錄與答案都只是意見，負責人閱讀的期間，檔位照樣運作。所以檔位條件可以讀兩個由 GembaOS 從缺口登記冊推出的事實：近期「不會同意」的次數，以及沒有人處理的比例變動。參考退款裏，30 日內有兩次「不會同意」，或有一條未解決的比例變動，小額退款就不再按規則放行，改由客戶服務主管簽批；答案過期、比例變動處理完畢之後，自動恢復。要提早恢復或改數字，就是一次發佈。

這是公司發佈、第二人批准的條件，和其他條件一樣畫在路線圖上。它只朝一個方向起作用：抽查人的答案只會關閉檔位，從不打開。

6. 由路線讀出每一檔由誰做

常有人想要一條由「人做」拉到「AI 做」的滑桿。GembaOS 沒有，因為一格刻度會把誰做事、誰簽批、涵蓋甚麼一併推動。路線圖改為逐檔讀出：誰準備要決定的事（AI、某個職位的人，或 GembaOS 按紀錄準備）、誰決定（已確認的規則、按次序的簽批人，或為自己的動作自簽的人）、誰執行。它由路線本身讀出，旁邊沒有另一個會互相矛盾的設定。由人負責的步驟，可以在按項修改表單交還 AI，選用設定裏已有的指引檔，簽批人維持不變；要讓某一檔重新免簽，是另一項須具名確認的修改。

7. 看出大家一直在簽甚麼

規則交給人簽的決定，同樣可以點算。GembaOS 按業務與檔位分組，再按 playbook 宣告的每個特徵——事實、宣告為選項或「是／否」的參數、風險標記——分開，列出批准、駁回、退回、逾期各有幾宗。金額與分數只顯示範圍。每個特徵旁邊都寫明檔位條件有沒有讀它；這個答案由規則本身讀出，不交給模型判斷。

沒有人寫下來的規律，就是這樣浮現的。例如客戶服務主管幾乎把所有附有照片的小額退款都批了，而退款規則從來不看有沒有附件。點算會列出這一組，也會註明規則沒有讀它。

業務檢討可以把它變成一條規則候選：放寬或收緊，每次檢討最多三條，寫明依據哪一組、還有甚麼不知道。GembaOS 核對這一組確實是那次讀取傳回來的、沒有因為低於最少顯示宗數而被隱藏、而且規則還沒有讀這個特徵，然後親自把數字抄到候選上；模型不寫任何宗數。參考公司每月跑一次這樣的檢討。

候選送到負責該業務的職位，由那個人確認或不採納。確認不改任何規則，只是讓組織設計助手可以連同數字，把它引作草稿的依據；草稿和其他發佈一樣，要在已記錄的決定上重判，並由第二人批准。確認的人可以在自己的工作台撤回確認，撤回之後，依據它的草稿就不能批准。

大家一致批准，本身不是理由。他們可能沒有細看就簽，每個答案都會這樣註明。

8. 改規則：先檢查，再試，然後擴大

改規則就是一次發佈。檢查會在草稿規則下重判已記錄的決定，不重發任何東西。草稿加入了新事實——例如個案上有多少份檔案——GembaOS 就按每宗個案作出決定當時的紀錄，重新推出這個事實；紀錄給不出的，列為「無法比較」，不當作改變。

另外兩步要管理員選用才有，預設都是關閉的：

• 在近期真實個案上試行草稿。 草稿涉及的業務最近結束的個案，由已綁定的模型在草稿規則下再處理一次。所有讀取都按該個案當時讀到的紀錄回答，個案沒讀過的紀錄不會去讀，也不作任何寫入、傳送或執行。頁面把每次重跑提出的第一個處理和實際處理並列；由排程或規則開啟的個案、附有檔案的個案、在提出處理之前停下的重跑，會另外列出並寫明原因。個案內容會再傳給模型供應商，並會收費。跑一次不是統計結論，這一步也不會阻止批准。
• 先只對部分個案生效。 發佈可以帶一個範圍——按申請人比例，或按某些團隊與部門——與檔案一起簽批。範圍生效期間，現行版本原封不動，其餘個案繼續按它處理。新工單在開始時分到其中一個版本，之後一直沿用；按比例的話，分到哪一邊由發佈與申請人計算出的雜湊決定，任何人都能重算，同一申請人總在同一邊。發佈頁把兩組在同一段時間並列：處理宗數、按規則放行與由人決定的數目、抽查答案與結果。擴大範圍或擴大到全部個案，是另一次須第二人批准的發佈；縮小範圍或收回，寫明理由就可以直接執行。收回之後，按草稿版本處理的個案由下一個決定起按現行規則處理，仍未有人簽批的審批單會退回，已經執行的事不會撤銷。另見有限發佈。

它不做的事

• 不會自己放寬任何東西。宗數、答案、結果都不會放寬檔位，也沒有任何機制會自動收回一份發佈。
• 只對部分個案生效的發佈，只能帶 playbook 定義檔。指引與用語由兩個版本共用，要改就要對全部個案發佈；生效期間，同一業務不能再有別的發佈。
• 同一段時間內，兩位申請人可能按不同規則處理。對此敏感的業務，應按團隊與部門劃分範圍。
• 只點算宣告過的特徵。寫在自由文字裏、或附件內容裏的規律，點算看不到；要讓它可以點算，就是一次宣告新事實的發佈。
• 總覽、抽查工作台與跨個案的答案仍合併統計；按版本分開來看，放在作比較的發佈頁。