跟隨訂單從解讀走向權限
這些保留的畫面畫面來自實際的本地演示。訂單、車道影像與廚房顯示螢幕均為合成或模擬；供應商與菜單品牌標籤僅為測試案例樣式，並非整合、客戶或背書的憑證。
水杯訂單處於等待狀態，即使價格為零
抽屜面板顯示傳入的 18,000 杯、上限八杯以及單筆訂單件數邊界。建議數量為八杯。該提議來自規則依據，且與 HOLD 決定保持分開。
一般訂單依然順利通過
兩份薯條和一個漢堡在正常測試案例中通過驗證。無論是 PASS 還是例外情況都會保留收據，因此審查介面並不依賴模型產生的解釋。
含糊意圖理應獲得確認
重複的原始標記在合成解讀中產生了三個漢堡。重複標記加上低於配置之 0.85 閾值的供應商信心度 0.71 產生了 HOLD，並附帶一個漢堡的建議。確認依然必要：引擎尚未確定顧客的真實意圖。
不熟悉的自訂配料是疑問，而非攻擊
該合成訂單要求在冰淇淋甜筒上加培根。已儲存的已觀察自訂配料集合包含巧克力醬與糖彩，但不包含培根。因此組合檢查產生 HOLD 並建議移除該自訂配料。這是要求確認的理由，而非證明該組合在實體上不可能或顧客懷有惡意。
這種區別會影響審查設計。正式生產策略需要權威菜單以及營運人員確認合法例外的途徑。示範的設定檔來自 5,000 筆植入的合成訂單，而非連鎖餐廳的營運歷史。
數量、價格與總件數為分開的檢查
260 塊雞塊測試案例超過了每項品項數量上限 20。其 $117 菜單總額亦超過配置的價格邊界 $116.76，且其 260 件品項超過了單筆訂單邊界 44。三項檢查一致認同該訂單應當等待；這些常規策略例外均不會單獨產生 BLOCK。
價格規則取已儲存歷史總額統計數據的三倍與 $100 中的較大者：max(3 × $38.92, $100) = $116.76。總件數規則採用 max(2 × 22, 40) = 44。抽屜面板中顯示的較小歷史統計數據是這些公式的輸入，而非最終觸發邊界。這兩個邊界均為配置的示範策略，而非營運餐廳的校準限制。
識別出的字詞仍需進行供應狀態檢查
在 11:15 點選的早餐捲餅被保留，因為此測試案例設有 10:30 的早餐截止時間。品項與價格雖可被理解，但該請求超出了配置的供應時段。移除建議揭示了該衝突；它並未確認顧客會接受何種替代品。
本範例根據傳入測試案例時間檢查一項配置的早餐時段。它並未建立即時庫存、門市專屬時間表、時區處理或整合的菜單服務。在真實提交路徑依賴它們之前，這些環節需要獨立的設計與驗證。
低信心度可使原本正常的訂單暫時保留
一份辣味雞肉三明治的供應商信心度為 0.62，低於配置的 0.85 閾值。其常規數量無法消除不確定性，因此引擎返回 HOLD。與重複標記範例不同，此案例分離出了低信心度，無需數量更正。
下一個適當的問題是解讀出的品項是否與請求相符。示範將該不確定性引導至審查；它不進行語音診斷、不評估聲學錄音，也不證明該閾值能提供可接受的生產錯誤率。
配置的攻擊訊號會產生不同的結果
包含指令的轉錄文字要求忽略先前的指令並包含 500 塊雞塊。注入模式被觸發並產生 BLOCK。數量、價格、品項件數與低信心度亦被觸發，但只有注入規則將此結果從 HOLD 轉變為 BLOCK。有限的模式集合無法證明具備徹底的抗注入能力。
收據在陳述的邊界內檢查完整性
收據保留了訂單、全部八項規則評估、決定、建議的更正與建議文字。未更改的水杯收據透過真實本地端點進行驗證；將 HOLD 更改為 PASS 同時保留原始簽章則會驗證失敗。
HMAC-SHA256 使用相同的共享密鑰進行簽署與驗證。預設金鑰為公開的示範資料，因此任何知曉該金鑰的人都可以對更改後的內容重新簽章。這展示了有邊界的本地完整性檢查，而非獨立保管、不可變儲存或已完成人工操作的記錄。
建議並非已放行的訂單
大訂單測試案例包含 40 份薯條與 40 杯汽水，總計 80 件品項，超出 44 件的邊界。更正演算法更改了單一相對數量違規最嚴重的項目：薯條降至其上限四份，但汽水仍維持 40 杯。汽水數量依然超過其自身的上限六杯。因此，視覺上較小的訂單並非整個提議訂單能夠通過的依據。
| 訂單狀態 | 薯條 | 汽水 | 權限 |
|---|---|---|---|
| 傳入訂單 | 40 | 40 | HOLD；模擬提交被扣留 |
| 建議修改 | 4 | 40 | 未重新提交或重新驗證 |
| 每項品項上限 | 4 | 6 | 已儲存的合成設定檔邊界 |
Approve Correction 和 Escalate 會更改其標籤並停用自身。它們不會記錄人工操作、重新提交、重新驗證、解除 HOLD、更改收據或將訂單發送至真實銷售點（POS）系統。生產環境交接需要確認顧客意圖、對完整的修改後訂單做出新的驗證決定，並在授予提交權限前記錄操作。
