跟踪订单从解析到权限的全过程
这些保留的画面来自实际的本地演示。订单、车道图像和后厨显示屏均为合成或模拟；供应商和菜单品牌标签属于测试用例样式，并非集成、客户或背书的证据。
即使价格为零，水订单仍需等待
抽屉面板展示了传入的 18,000 杯水、上限 8 以及单笔订单件数边界。建议数量为 8。该提议来自规则证据，且与 HOLD 决策保持独立。
普通订单仍旧通过
在正常测试用例中，两份薯条和一个汉堡通过了核验。PASS 与异常情况一样都会保留收据，因此复核界面不依赖模型生成的解释。
不确定的含义理应得到确认
在合成解析中，重复的原始标记生成了三个汉堡。重复以及供应商置信度 0.71 低于配置的 0.85 阈值导致了 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 件的边界。更正算法更改了相对数量超标最严重的一项：薯条降至其上限 4，但汽水仍为 40。汽水数量依然超出了其自身上限 6。因此，视觉上规模变小的订单并不能作为整个提议订单均能通过的证据。
| 订单状态 | 薯条 | 汽水 | 权限 |
|---|---|---|---|
| 传入订单 | 40 | 40 | HOLD；模拟提交被暂扣 |
| 建议修改 | 4 | 40 | 未重新提交或重新核验 |
| 单品上限 | 4 | 6 | 保存的合成配置文件边界 |
Approve Correction 和 Escalate 仅更改其标签并停用自身。它们并不记录人工操作、重新提交、重新核验、解除 HOLD、更改收据，也不向真实销售点系统发送订单。生产交接在授予提交权限之前，需要确认顾客意图、对完整修订订单做出新的核验决策，并记录操作日志。
