Drive-Thru Order Firewall
Nel nostro esempio sintetico per il drive-thru, arrivano 18.000 bicchieri d'acqua gratuiti con una confidenza del fornitore di 0.97. Il limite massimo di quantità è pari a otto. Il gate pone l'ordine in HOLD prima dell'invio alla cucina simulata.
Panoramica guidata di 7 min 39 sec. JSON sintetico del fornitore e punto vendita (POS) simulato; risposte consultive memorizzate nella cache generate dal vero modello Codex.
18.000
Bicchieri d'acqua trattenuti
Un singolo ordine sintetico
8
Limite massimo configurato per la quantità d'acqua
Profilo di ordini sintetici salvato
0.97
Dato di confidenza del fornitore
Un punteggio, non una probabilità calibrata
Separiamo l'interpretazione di un ordine dall'autorità di inoltrarlo. Costruiamo Vera Intelligenza.
Un punteggio di confidenza descrive l'interpretazione del fornitore. Non risponde alla domanda se il ristorante consenta o meno tale quantità. Nel fixture dell'acqua, il totale del menu è pari a $0.00, per cui un controllo basato esclusivamente sul prezzo non ha motivo di opporsi. Il controllo sulla quantità invece sì: 18.000 supera il limite salvato di otto.
Questa distinzione fornisce al team operativo un utile quesito di revisione: quale regola del ristorante concede l'autorizzazione all'inoltro, e dove può un operatore ispezionare il motivo per cui è stata trattenuta? La demo preserva l'ordine in entrata e mostra l'evidenza determinante anziché considerare un'interpretazione apparentemente sicura come un'autorizzazione.
Il motore locale normalizza il JSON strutturato del fornitore, valuta otto controlli deterministici e applica un gate di policy. I controlli coprono la quantità degli articoli, i modificatori osservati, il prezzo, la fascia oraria (daypart), le unità complessive in un singolo ordine, i token ripetuti, la bassa confidenza del fornitore e i pattern di injection configurati. Il profilo storico salvato proviene da 5.000 ordini sintetici iniziali; non costituisce lo storico operativo di una catena di ristoranti.
Nessuna regola si attiva. Il motore autorizza l'invio al display simulato.
Si attiva una regola diversa da quella di injection. L'inoltro resta trattenuto in attesa di conferma.
La regola configurata per l'injection si attiva. Il motore rifiuta l'invio simulato.
L'ordine dell'acqua attiva sia il limite di quantità per articolo sia il controllo sulle unità totali. Quest'ultimo prevede una soglia limite di 44 unità per un singolo ordine. L'etichetta nella UI indica Rate limit, ma non misura gli ordini attraverso le sessioni o in un arco temporale.
Per gli ordini contrassegnati, la nota consultiva segue il gate e non può modificarne la decisione. Questa registrazione riproduce risposte memorizzate nella cache dal vero modello Codex configurato. Gli ordini contrassegnati con PASS saltano la valutazione del modello. Il timer visualizzato copre solo le regole più il gate; l'elaborazione del modello è sincrona all'interno della richiesta complessiva, e il timer esclude tale elaborazione e la trasmissione.
Questi fotogrammi conservati provengono dall'effettiva dimostrazione locale. Gli ordini, le immagini della corsia e il display della cucina sono sintetici o simulati; le etichette con i marchi del fornitore e del menu sono elementi stilistici del fixture, non prove di integrazioni, clienti o approvazioni.
Il drawer mostra i 18.000 bicchieri in arrivo, il limite massimo di otto e la soglia di unità per singolo ordine. La quantità suggerita è pari a otto. Tale proposta deriva dall'evidenza delle regole e rimane distinta dalla decisione di HOLD.

Due porzioni di patatine e un hamburger superano la convalida nel fixture normale. Una ricevuta viene conservata sia per il PASS che per le eccezioni, cosìché la superficie di revisione non dipenda da una spiegazione generata dal modello.

I token grezzi ripetuti producono tre hamburger nell'interpretazione sintetica. La ripetizione e la confidenza del fornitore pari a 0.71, inferiore alla soglia configurata di 0.85, generano HOLD, con il suggerimento di un solo hamburger. La conferma rimane necessaria: il motore non ha stabilito l'effettiva intenzione del cliente.

L'ordine sintetico richiede bacon su un cono gelato. Il set salvato dei modificatori osservati include salsa al cioccolato e zuccherini, ma non il bacon. Il controllo sulla combinazione genera quindi HOLD e propone la rimozione del modificatore. Questo è un motivo valido per richiedere conferma, non una prova che la combinazione sia fisicamente impossibile o che il cliente stia agendo con intenzioni malevole.

Questa distinzione influisce sulla progettazione della revisione. Una policy di produzione richiederebbe un menu autorevole e una procedura che consenta a un operatore di confermare un'eccezione legittima. Il profilo dimostrato proviene da 5.000 ordini sintetici iniziali, non dallo storico operativo di una catena di ristoranti.
Il fixture da 260 nugget supera il limite massimo di quantità per articolo pari a 20. Anche il suo totale di menu pari a $117 supera la soglia di prezzo configurata di $116.76, e le sue 260 unità superano la soglia di 44 unità per singolo ordine. Tre controlli concordano sul fatto che l'ordine debba attendere; nessuna di queste ordinarie eccezioni di policy da sola genera BLOCK.

La regola sul prezzo adotta il valore maggiore tra tre volte il totale statistico storico salvato e $100: max(3 × $38.92, $100) = $116.76. La regola sulle unità totali adotta max(2 × 22, 40) = 44. I dati statistici storici inferiori mostrati nel drawer sono parametri di input per queste formule, non le soglie definitive di attivazione. Entrambi i limiti rappresentano policy configurate della demo, non limiti calibrati per un ristorante operativo.
Un burrito per colazione richiesto alle 11:15 viene trattenuto perché questo fixture prevede un orario limite per la colazione fissato alle 10:30. L'articolo e il prezzo possono essere compresi correttamente anche se la richiesta ricade al di fuori della finestra oraria di servizio configurata. Il suggerimento di rimozione evidenzia tale conflitto; non conferma quale alternativa il cliente sarebbe disposto ad accettare.

Questo esempio verifica una singola fascia oraria per la colazione configurata rispetto all'orario del fixture in arrivo. Non istituisce un inventario in tempo reale, orari specifici per punto vendita, gestione dei fusi orari o un servizio di menu integrato. Tali aspetti richiederebbero una progettazione e una convalida separate prima che un reale percorso di inoltro vi faccia affidamento.
Un panino al pollo piccante presenta una confidenza del fornitore pari a 0.62, inferiore alla soglia configurata di 0.85. La sua quantità del tutto ordinaria non elimina l'incertezza, pertanto il motore restituisce HOLD. A differenza dell'esempio con token ripetuti, questo caso isola la bassa confidenza senza richiedere alcuna correzione sulla quantità.

La successiva domanda appropriata consiste nello stabilire se l'articolo interpretato corrisponda alla richiesta originaria. La dimostrazione instrada tale incertezza alla revisione umana; non diagnostica il parlato, non valuta una registrazione acustica né dimostra che questa soglia garantisca tassi di errore accettabili in produzione.
La trascrizione contenente istruzioni richiede di ignorare le istruzioni precedenti e include 500 nugget. Il pattern di injection si attiva e produce BLOCK. Anche quantità, prezzo, volume di unità e bassa confidenza si attivano, ma solo la regola di injection modifica l'esito da HOLD a BLOCK. Un insieme finito di pattern non può garantire una resistenza esaustiva alle injection.

La ricevuta conserva l'ordine, tutte le otto valutazioni delle regole, la decisione, le correzioni suggerite e il testo consultivo. La ricevuta non alterata dell'acqua supera la verifica tramite l'effettivo endpoint locale; la modifica da HOLD a PASS mantenendo la firma originale fallisce la verifica.


HMAC-SHA256 utilizza il medesimo segreto condiviso per la firma e per la verifica. La chiave predefinita è materiale pubblico dimostrativo, pertanto chiunque ne sia a conoscenza può firmare nuovamente un corpo modificato. Questo illustra un controllo locale e delimitato di integrità, non una custodia indipendente, uno storage immutabile o una registrazione di azioni umane completate.
Il fixture ad alto volume contiene 40 porzioni di patatine e 40 bibite, per un totale di 80 unità al di sopra del limite di 44 unità. L'algoritmo di correzione modifica la singola anomalia quantitativa relativa più grave: le patatine scendono al loro limite di quattro, ma le bibite restano a 40. La quantità di bibite supera ancora il proprio limite di sei. Un ordine visivamente ridotto non dimostra pertanto che l'intero ordine proposto verrebbe approvato.

| Stato dell'ordine | Patatine | Bibite | Autorità |
|---|---|---|---|
| Ordine in arrivo | 40 | 40 | HOLD; inoltro simulato trattenuto |
| Modifica suggerita | 4 | 40 | Non reinoltrato né riconvalidato |
| Limiti massimi per articolo | 4 | 6 | Limiti salvati del profilo sintetico |
Approve Correction ed Escalate modificano le proprie etichette e si disabilitano. Non registrano azioni umane, non reinoltrano, non riconvalidano, non rimuovono uno stato di HOLD, non modificano la ricevuta né inviano un ordine a un vero sistema point-of-sale. Un passaggio alla produzione richiederebbe la conferma dell'intenzione del cliente, una nuova decisione di convalida sull'intero ordine revisionato e un'azione registrata prima di concedere l'autorità all'inoltro.
Sull'insieme etichettato e salvato di 43 ordini sintetici, il motore produce 35 PASS, 7 HOLD e 1 BLOCK. Tutti gli otto fixture etichettati per revisione o blocco vengono intercettati; nessuno dei 35 fixture normali viene erroneamente trattenuto. Il confronto seguente utilizza due semplici baseline di codice locale sugli stessi identici fixture.

Interpreta i contatori nel loro rispettivo ambito. La cifra mostrata di $1,251 è una stima illustrativa e arrotondata del costo degli articoli di $1,250.80 su quattro specifici fixture trattenuti, non una riduzione misurata degli sprechi o risparmi effettivamente realizzati. Il timer registrato misura unicamente le regole e il gate, escludendo l'elaborazione del modello, la firma della ricevuta, la rete e la trasmissione; non costituisce una latenza end-to-end. La chiamata al modello è sincrona all'interno della richiesta complessiva anche se il suo parere consultivo non può alterare il gate.
Sui display piccoli, scorri la tabella di confronto in orizzontale.
| Approccio decisionale locale | Fixture di revisione/blocco intercettati | Cosa verifica |
|---|---|---|
| Drive-Thru Order Firewall | 8 su 8 | Otto controlli più il gate PASS/HOLD/BLOCK |
| Baseline con quantità superiore a 100 | 3 su 8 | Trattiene l'ordine se una qualsiasi riga di quantità grezza supera 100 |
| Baseline Always-PASS | 0 su 8 | Consente il passaggio di ogni fixture |
Questo risultato certifica il comportamento testato su un flusso finito ed etichettato. Non stima l'accuratezza sul campo, i falsi positivi di sospensione in produzione o le prestazioni di un altro fornitore. Il report viene restituito dall'endpoint locale di valutazione; non è presente alcun tabellone visibile dei benchmark o interruttore OFF nel dashboard.
Non riconosce l'audio, non acquisisce un feed reale da fornitori, non si connette a un POS reale e non conclude la revisione umana. Le soglie non sono state validate per un ristorante in effettiva attività. Non viene dimostrata alcuna implementazione per i clienti, risparmio effettivo misurato o risultato sui livelli di servizio di produzione.
Il contatore dello spreco a schermo somma i costi illustrativi degli articoli sintetici per ordini selezionati e trattenuti, non risparmi effettivamente realizzati. Il timer misura esclusivamente le regole e il gate. Consigliamo di eseguire test su menu locali rappresentativi e sul traffico reale degli ordini, confermando il passaggio di consegne all'operatore e convalidando il perimetro di autorizzazione POS prima che un'architettura di produzione si affidi a questo approccio.
Drive-Thru Order Firewall dimostra un livello di convalida per l'output strutturato degli ordini fornito da terze parti. Elabora JSON sintetico prima di un sistema point-of-sale e di un display di cucina simulati; non acquisisce audio, non esegue il riconoscimento vocale e non si collega a un fornitore reale.
Qualsiasi regola attivata diversa dalla regola di injection genera uno stato di HOLD e sospende l'inoltro simulato. Quantità, prezzo, disponibilità, modificatori non riconosciuti, token ripetuti, bassa confidenza e unità totali possono richiedere la revisione; il controllo sulle unità totali misura un singolo ordine, non il traffico nel corso del tempo.
Il modello consultivo non può modificare la decisione deterministica del gate in questo percorso del motore. La registrazione adotta risposte consultive reali memorizzate nella cache dal modello Codex successivo al gate; non esegue una nuova inferenza a ogni riproduzione.
Approve Correction ed Escalate modificano unicamente le proprie etichette dei pulsanti e si disabilitano all'interno di questa demo. Non sbloccano uno stato di HOLD, non reinoltrano un ordine, non registrano l'azione umana né scrivono su un sistema point-of-sale reale.
La verifica HMAC-SHA256 locale verifica che il corpo di una ricevuta corrisponda alla propria firma con il medesimo segreto condiviso. Modificare la decisione senza generare una nuova firma rende non valida la verifica; la chiave pubblica dimostrativa consente a chiunque la conosca di firmare nuovamente, per cui non si tratta di custodia indipendente o archiviazione immutabile.
La valutazione impiega 43 ordini sintetici predefiniti: 35 PASS, 7 HOLD e 1 BLOCK. Tutti gli otto fixture etichettati per revisione o blocco vengono intercettati senza falsi blocchi tra i 35 fixture normali; le semplici baseline sono confronti di codice eseguiti in locale, non misurazioni effettuate presso fornitori o ristoranti.
Discuti le regole e i percorsi di revisione di cui la tua operatività necessita.
Possiamo aiutarti a valutare dove l'interpretazione del fornitore diventa autorità transazionale e a progettare un approccio di convalida mirato per il tuo menu e per il flusso di lavoro del point-of-sale.
Esplora le ricerche correlate per ottenere un quadro più ampio su questa dimostrazione.
Soluzione completa
Esplora la soluzione ingegneristica QSR Drive-Thru Voice AI →