How it works
A kitchen is not one screen either. The moment an order carries more than one kind of item, something has to decide which station sees which line. Here is exactly how that decision gets made in your kitchen.
Five states. Each control names a physical act, not a database word — a cook is not advancing a status, they are pulling a pie and boxing it.
Accepted, nobody has touched it. It sits on the board with its channel badge, its age, and any allergy callout already visible — before a cook has read a single topping.
A maker has it. Size, crust, sauce, cheese and toppings read as a labelled list rather than a run-on parenthetical, and the two halves of a split pie are kept apart as Left and Right.
Tracked on the oven board rather than bumped on the make line — a real oven, a real deck, a real slot, with elapsed bake time computed live from the moment it went in.
Out, cut, wrapped. This is the stage the rest of the shop is waiting on: it is what flips the order to ready for the counter, the tracker and dispatch.
Off the board. Nothing downstream is told separately, because nothing downstream is reading a separate record.
Because the order record cannot express it. Making and oven both persist as the same underlying status, so that bump would write a value, read the same value back, verify itself as successful, and leave the card exactly where it was — with the control re-armed for a pie already baking. The board therefore offers only bumps the record can actually carry, and oven time is tracked on the oven screen where it is real. A control that fakes progress is worse than a missing one.
The routing decision
Routing is a pure function of the item — no clock, no network call, no side effect. It runs on the same order feed the make-line board reads, and it splits that feed so each station receives only its own lines, once, in the order they were rung.
Matched first against the shop’s station map. Pizza to the oven line, wings to the fryer, salad to the cold station — whatever the shop actually calls them.
An order line does not carry a category today, so in practice this arm is skipped and step 2 decides. It is real code waiting on one column, not a plan.
No category match — or no category at all — and the menu item’s own identifier is matched next. This is the arm that runs today, and it is also how one outlier is redirected without inventing a category for it.
Nothing matched. The line goes to the default station rather than nowhere. Even a station identifier the roster does not recognise resolves to a printer rather than vanishing.
This is the arm that matters most, and it is the one nobody publishes. A line that matches no rule is the line that goes missing on a busy Friday.
The routing engine drives per-station kitchen printing. Each station with a printer gets a ticket carrying its own lines and its own name in the header, printed exactly once per station per order — a retry after a paper jam does not double-fire the line. Stations on a screen are the board’s job and are never printed. We are naming what it drives rather than implying it drives every screen in the kitchen.
Stations are configuration
A station is data — an identifier, a label, and how it is served — not a compiled-in list of six names every shop has to bend to. One shop runs a single all-purpose kitchen printer and no display at all. Another runs a hot line on paper, a cold station on a screen, and an expo that gets both. Neither needs a different build of the app.
The station’s lines print on its thermal printer. A station may name the specific printer it is bonded to, or take the terminal’s default.
The station’s lines render on the kitchen board and are not printed. The board is the record of what is working.
Screen and paper. For a station that wants a durable ticket in hand and a live view of the queue at the same time.
One implicit kitchen station on a printer, catching every line. The roster, the item map, the mode and the catch-all all default to empty on purpose: an unconfigured shop that prints every ticket to one printer is a working kitchen, and an unconfigured shop that drops tickets is not. Naming a station type the system does not recognise is refused outright rather than accepted and quietly pointed at nothing.
The kitchen screens
The ticket board. The allergy callout renders above the item name, so a cook cannot start the pie without seeing it. A split pizza shows Left and Right as separate lists. Every ticket carries a badge for the channel it arrived on — counter, phone, kiosk, web, aggregator — coloured by family so it reads across the room.
Your ovens, decks and slots, read from configuration; there is no compiled-in oven and an unconfigured shop is told so rather than shown a fictional one. Each pie is tracked through a real slot with a live timer. The deck’s target temperature is labelled a target — actual temperature needs a probe, and with no probe attached the board says that instead of printing a number.
Forecasting for dough, sauce, cheese and toppings, with waste logging and par-level alerts. The forecast is a server-side model reading today’s real order context; nothing on the screen is a number typed into the app.
Average ticket time, order count, late orders and on-time percentage for this location — read from the same order feed the board reads. One feed, one set of numbers, nothing to reconcile between two systems at close.
Failure modes, stated
A kitchen display fails quietly or not at all. These are four quiet failures we went and made loud, because every one of them has a shape that looks exactly like a calm kitchen.
The make line used to read the order feed once, at mount, and then sit there. A cook watching an empty board had no way to tell a genuinely quiet kitchen from a screen that stopped updating forty minutes ago — and the calm one is the dangerous one, because it is believed. A stale feed now carries a banner, and no setting suppresses it.
Orders older than the shop’s active window leave the make line so a flooded board stays readable. Their count does not leave with them: a chip on the header says how many, and it stays visible even when the filtered board is empty.
Advancing a ticket is permission-checked, then verified against what the record reads back. A response echoing the old status is treated as a failure. Otherwise the write appears to land, the card never moves, the control re-arms, and the same pie goes in the oven twice.
Setting up a location creates stations, then routes menu items to them. Stations alone produce zero tickets, so "stations created" is not reported as success — the step passes only when a station exists AND something routes to it. A failed routing write stops on the first failure and names the item it stopped at, rather than leaving half the menu quietly unreachable.
Ask PizzaOS
Answers come straight off this site
Ask me anything about how PizzaOS works. I only know what is on this site, so I will not make anything up — and if you would rather talk to a person, just say so.