The standard facts every rule reads — everything except the order it happens to be scoring — computed fresh rather than read from a cache: the Orchestrator itself never keeps one lying around between passes. This is a diagnostic only. It sets the computed data beside what a person can observe happening in the restaurant; it changes nothing.
What the restaurant is doing right now, per sale channel — built from every order the Orchestrator itself is currently tracking, in its pending queue and its production registry. Not a fresh poll of ClerkMaster: this reads memory, the same rule the probe below follows.
The scoring dials currently saved to disk, per sale channel — exactly what settings.drive.* and friends resolve to for a rule right now. Edit them from the Settings page.
Deliberately not part of the snapshot above: an order fact exists per order, not restaurant-wide. Paste the UUID of an order the Orchestrator is currently tracking — pending or already in production — to see exactly what a rule would read as order.* for it.
Ask the Print Server, right now, what one order would put on the production screens, and see the exact request and response. Only orders the Orchestrator is currently tracking can be asked about — pending or already in production. Each probe is a real call to the Print Server. Nothing on this page polls it: a probe happens when you click, and it changes nothing — not the gate, not the queue, and not the predicted footprint the dashboard reports.
| ORB | Order | Where | Channel / state |
|---|