A drive-thru voice system can express an order with high confidence while the restaurant still needs to ask whether that order should proceed. For technology and operations teams, this creates a distinct design responsibility: decide what authorizes submission to the kitchen after the words have become a structured order.
We built the Drive-Thru Order Firewall to illustrate that decision. It checks synthetic vendor JSON before a simulated kitchen display. It does not capture audio, recognize speech or connect to a restaurant's point-of-sale system. The example lets us examine the permission boundary without claiming a deployed integration.
An order can be confident, free and outside the quantity rule
One synthetic fixture contains 18,000 cups of water, a vendor confidence score of 0.97 and a customer menu total of zero. The saved profile, derived from synthetic order history, gives water a quantity cap of 8. The engine holds the order because its quantity exceeds that cap. A second check also finds that its total units exceed the configured boundary for one order.
Each input answers a different question. The confidence score is supplied by the fixture and is not a calibrated probability that the order is correct. Menu price determines what the customer would be charged. Neither establishes whether the requested quantity fits the configured policy. Raising confidence or keeping the price at zero would leave the quantity violation intact.
The detail view makes the decision inspectable: the incoming quantity and saved cap appear together, the outcome is HOLD, and the proposed quantity is 8. That is the value of separating the checks. A reviewer can identify what requires confirmation instead of relying on a general claim that the system is confident.
In this recorded synthetic order, the quantity rule produces a hold despite the zero menu total. Eight cups is a suggestion for review, not a submitted replacement order.
The recording uses cached real Codex advisory responses. Its vendor input and kitchen routing are simulated. The background cost counter is an illustrative synthetic estimate, and the timer covers rules plus gate only, excluding the model and delivery. Those displays do not establish restaurant savings or complete pipeline latency.
The explanation should not grant permission
In this engine, deterministic rules run before a separate policy gate. The gate decides whether the order may proceed to the simulated kitchen display. Advisory model text arrives after that decision and cannot change it. The water order stays held even though the note explains the problem and recommends a smaller quantity.
For a restaurant team evaluating an architecture, the useful question is who owns the decision to submit. If explanatory prose can release a hold, then the permission rule depends on another interpretation. We prefer a design in which advice helps the operator understand the decision while the configured gate retains authority over submission.
That separation also makes the policy easier to challenge. A team can disagree with the cap, inspect its basis and change the approved policy through a defined process. It need not ask a model to reinterpret a quantity exception into an approval. The cap of 8 is an example from seeded synthetic history, not a recommendation for every restaurant or evidence that a real chain's thresholds have been validated.
A hold leaves a decision to complete
The water fixture receives HOLD, meaning confirmation is needed. It is not labelled an attack merely because the quantity is unusual. In the demo's policy, only the configured injection rule causes BLOCK; other triggered rules cause HOLD. That preserves a distinction between an order needing review and a configured adversarial signal.
The suggestion of 8 cups also has a narrower meaning than a correction. It reflects the saved quantity cap, not verified customer intent. An operator would still need to establish what the customer wanted. Automatically replacing 18,000 with 8 would convert a policy limit into an assumption about the order.
The interface illustrates this unfinished handoff. Its Approve Correction and Escalate buttons change their labels and disable themselves. They do not release the hold, resubmit an order or update a receipt. A production design would need to define how confirmation is recorded, how the revised order is checked and what authorizes its eventual delivery. Those are requirements we would inspect, not completed capabilities of this demonstration.
The full order-validation breakdown explains the example and its boundaries. For a restaurant team, the decision to carry into an evaluation is concrete: require evidence of order permission separately from recognition confidence, then follow an exception through confirmation, revalidation and submission. A useful explanation earns attention. The confirmed, checked order must earn permission.