Menus and Storefronts — what the business sells, where, at what price¶
What this covers. The selling surface of the business: the menu an operator composes from the catalog, the modifier choices that ride its menu items, the publication that freezes it into the exact document customers are shown, the storefront — a concrete selling point such as "our Glovo page" or "the dining hall" — and the placement rule that decides which menu each storefront serves and at what prices. It also covers the stop (the "86") that takes one item off sale for a while, and how a sales ticket records which storefront it sold through without that record ever gating the books. Read Sales & consumption for what happens to stock when a sale arrives; this chapter is about the selling side — what stands for sale before anyone buys it.
1. Optional layers that never lock each other¶
The selling surface is built as a ladder of independent layers, each one useful without the next:
catalog items → exist without any menu
menus → composed without ever publishing
publications → frozen without any storefront to serve
storefronts → recorded without any integration behind them
sales tickets → post without any of the above
A business may run its whole inventory life — receipts, production, sales, counts, closes — and never create a menu. Another may author menus purely to print them. A third places menus on marketplaces and lets late-arriving marketplace sales resolve against the exact document that was in force. Each layer is a deliberate, manual setup act; nothing on this surface is ever created automatically, and the absence of any layer never degrades the ones below it. The ledger is the spine; the selling surface is enrichment layered over it.
2. Channel — the vocabulary of ways to sell¶
A channel is an entry in a small company-authored vocabulary naming a way sales reach the business: Glovo, Wolt, the hall, the till. Each channel carries one fulfillment nature — dine-in or delivery — which determines how the dish is packed at sale time. Delivery means packed to leave, whether a courier or the customer collects the order. An order's actual fulfillment takes precedence over the channel's default. When a made-to-order sale posts, its recipe's packaging is resolved from that fulfillment: the packaging variant the recipe keeps for it, otherwise the recipe's general variant, otherwise nothing is packed. A recipe holding only a delivery variant thus packs a Glovo order and leaves a plate in the hall bare. The sale keeps a record of which packaging it actually resolved, so a later recipe edit never rewrites what a past sale consumed. The menu never selects packaging — the recipe owns how a product is packed, the channel says only which fulfillment the sale is.
A channel is a grouping and pricing axis and nothing more: never a stock location, never a valuation axis (see Scope & locations). Two identical plates sold through two channels deplete the same warehouse pool at the same cost; only the reporting slice differs.
3. Storefront — a named selling point¶
A storefront is one concrete place a specific restaurant sells through a specific channel, with a name: "Nonna — Glovo", "Burger Bar — Glovo", "The hall". It is the recorded fact "this site sells there" — created in half a minute, carrying no technical machinery. A marketplace integration, where one exists, attaches to the storefront from the side as a sync (§10); the storefront itself never depends on one.
One restaurant may run several storefronts on the same channel. That is the virtual brand pattern — one restaurant selling on Glovo as both "Nonna Pasta" and "Burger Bar", two pages, two menus, one warehouse depleting for both. The model has no separate notion of a brand: the brand is the storefront's name, and the menu it serves is just a menu. Naming, not structure, is what distinguishes virtual brands — which is exactly how the marketplaces themselves see them.
4. Menu — the working document¶
A menu is a document the operator composes: sections in display order (Starters, Mains), each holding menu items in display order. A menu item puts one catalog item on sale at a hand-authored price. Nothing ever suggests or seeds that price: pricing is a commercial decision, and the gate that certifies a menu item is fit to sell runs at publish, not at authoring.
A menu item's presentation — name, description, photos — defaults to the catalog item's product card, the one home of customer-facing presentation (see Catalog). The menu item may override any of it for this menu alone: a card sells as "Spaghetti alla Carbonara" in the hall and "Carbonara" on the delivery page. Photos are three-way: the menu item can inherit the card gallery, carry its own, or deliberately show none. One catalog item may stand in a menu several times — a large and a small pour are two menu items on one card, told apart by their names and prices.
Customer-facing taxonomy follows the catalog item: a drink remains in its browsing group wherever its product card appears. Operator-only classifications stay private. A publication freezes those classifications together with the menu item's marketing labels; later catalog tagging changes belong to the next publication.
Two more things ride the menu item and its section:
- Availability windows — day-of-week plus start and end times, crossing midnight when the end is earlier than the start ("Friday 22:00–02:00" is one window). A section's windows bound all its menu items; a menu item's own windows can only narrow the section's. Empty means always. Windows are information carried by the document; only the storefront view evaluates them, because only there does a venue — and therefore a local clock — exist (§9).
- Marketing labels — what the customer sees called out beside a menu item. Shared meanings ("New", "Spicy", "Vegan") come from the company's tag vocabulary so every menu says them identically and clients can localize them; a one-off ("Chef's pick this week") is authored text living on that menu item alone.
A menu leaves freely only while nothing durable references it: no publication, no placement routing it anywhere, no sale recorded against one of its menu items. Until then it is a private draft; past any of those facts, the document has entered the record, and menu items are archived rather than deleted (§11). Customer-facing text on menus is translated into every language the company configures, in the background, as the operator edits — the operator never manages translations by hand.
5. Modifiers — the choices that ride a menu item¶
Customers customize: milk in a latte, toppings on a bowl, "no cheese". The company authors this once, as a modifier library of reusable modifier groups — «Milk», «Toppings» — each an ordered set of options. A group carries its selection bounds: a minimum (above zero, the group is required — a constructor bowl must pick a base) and an optional maximum. A repeatable group allows multiple units of the same option; a unique group allows each option once. A maximum of one permits one choice either way. The library is vocabulary, not menu content: one «Milk» group serves every coffee the company sells, and its customer-facing names are translated in the background like all customer text — the group and its options as one document.
An option is one choice: a name the customer reads, an optional photo, a signed price delta, and — where it has stock meaning — the catalog item it talks about and what it does to that item. It never carries a quantity or unit. Those are production truths owned by the recipe matrix, where the item stands in exactly one place.
There are four meanings:
- A choice selects a slot candidate, includes an addable line, or applies a positive multiple to the one recipe line it names: oat milk, avocado, double cheese. A choice with no catalog item is text-only and changes presentation or price without changing the build.
- A removal takes a removable recipe line out: no onion means no onion leaves stock.
- An add-on sells the named item as a separate line beside the dish: cola with a burger is still cola, costed and depleted as itself. A side add-on is a simple product without slots; something with choices of its own is a combo item with its own matrix.
- A variant sells the named item instead of the menu target. Sizes are therefore separate items, each following its own stock or recipe behavior — small, medium, and large cappuccino — not multipliers over one hidden recipe.
The option remains a commercial choice with no catalog identity of its own. Its named item is the shared point between menu and recipe; it may also be a perfectly ordinary stocked product when the meaning is add-on or variant.
The product card owns which choices a product offers. The card attaches groups from the library — which ones, in what order, with bounds narrowed where this product is stricter than the library's — and picks each group's default options. Together they describe the standard configuration: the representative way the product is sold — the latte as whole-milk, the bowl with its usual three toppings. Every menu item built on that card, on every menu, inherits its choices. The defaults first determine the sold item — the target unless a variant replaces it. A made-to-order sold item resolves to a recipe build; a stocked one remains itself. Storefronts present the configuration first and menu food cost reads it, but it is not a production default: the recipe's slots still have none. That same sold item sets the row's base food cost; default add-ons remain separate additions, and non-default variants are choices rather than fallback subjects for that answer. Whether the row can be sold at all is the one question the sold item does not settle by itself — every size has a say.
A required group may deliberately have no default: the customer must choose, and the standard configuration's cost is incomplete rather than invented. A hidden option can never remain a default. A variant group — most often size — is stricter: it contains only variants, requires exactly one choice, and always has exactly one default. A menu item carries at most one such group, its own target is one of the group's items, and every made-to-order referent has a recipe in force. A stocked referent is equally legal; it sells as itself and costs at its reference price. With no variant chosen the menu target remains the sold item; one variant replaces it, while two variants cannot describe one sale.
A menu may amend the card's choices per menu item, for display and price only: add a group the card does not carry, drop one, narrow the bounds, re-pick the defaults, adjust an option's delta or hide it on this menu alone. The card keeps the standard choice offering; the menu item states how this menu presents and prices it. Re-picked defaults form that position's standard configuration at the right price.
The card's attachment of a group may also declare an included allowance: «pick five toppings, three included, extras +€0.80». An included allowance declares how many choices carry no charge, and it may never exceed how many the attachment lets a customer pick — an allowance of five where only two can be chosen promises a discount no build can reach. A group with an included allowance carries one price: every option the customer can see has the same effective price, rounded to cents, however many picks the group permits. Then «three included, extras +€0.80» has one meaning regardless of which toppings the customer chooses. A group without an allowance may price each option differently. To offer a capped free choice among toppings with different ordinary prices, give that choice its own zero-priced group and a maximum number of picks.
Hidden and archived options do not participate. A temporary stop leaves the commercial declaration intact, as does choosing different defaults. Negative price adjustments remain credits and remain valid; under an allowance they follow the same one-price rule.
Choice availability is derived from stops (§8): an option whose named item is stopped goes unavailable, carrying the stop's lapse moment and reason. A stopped default stays in the document with its verdict — never silently substituted: the customer sees the standard configuration with the truth attached. A stop on a variant works the same way — it darkens that size's choice and nothing more, whether or not that size is the default, and whether or not it is the menu item's own target.
A row with a size group sells whichever size still lives, so it goes unavailable only once every one of them is stopped — the target and each variant alike. A row without variants goes unavailable when its target is stopped. Either way, a row also goes unavailable when a required group has no live choice left. A row that has fallen states when it returns: the moment the first of its stopped sizes lapses.
Size — pick exactly 1: small · medium (default) · large
Cappuccino 3.50 standard configuration = medium → shown at 3.50
86 medium → the medium choice goes dark; the row stays up,
small and large still sell
86 small, medium
and large → nothing is left to sell — the row goes down
6. Publication — the frozen document on a moment timeline¶
Publishing freezes the working document into a menu version: resolved names, descriptions and their translations, prices, windows, labels, photo membership, and each menu item's resolved choices — groups, options, deltas, defaults — exactly as they stood. The frozen document is history — it never changes. Later edits to cards, items, the choice library, or the working menu leave every publication untouched; that is what lets a sale arriving a week late resolve against what the customer actually saw.
Each publication takes effect at a moment — publish now, or stage one for Friday 18:00. Commerce time is not recipe time: recipes live on business dates because costing is daily-grained, but a menu legitimately changes mid-service — lunch prices at 11:00, dinner at 17:00, a correction three minutes later. So versions order by their effective moment, the one in force is the latest whose moment has arrived, and publishing into the past is refused — sales have already resolved against the timeline as it stood, and a document nobody could have seen must not pretend it was ever in force.
A version is always in exactly one of four derived states, and nothing stores them:
staged its moment has not arrived yet
effective in force right now
superseded a later version's moment has arrived
withdrawn taken back while still staged — terminal
Only a staged version can be withdrawn; a document that has served customers is superseded by publishing anew, never unpublished. The working menu can always answer whether it has drifted from its newest publication — authored edits count, including an edit to a shared library group that reaches the document through its cards; background translation work does not, and a staged future version already carrying the edits keeps the answer quiet.
Publish certifies, then freezes. The gate refuses — naming each failing menu item — when the menu is empty, a menu item's presentation does not resolve to a name, a target is not sellable, a made-to-order target has no recipe in force on the effective moment's date, or a menu item's choices contradict what they promise — a default no longer belongs to its live group, too many defaults, more than one variant group, a variant group without exactly one default or without the target among its items, or a made-to-order referent without a recipe in force. A non-variant required group may have no default: that is an honest instruction that the customer must choose. And because customers read menus in their own languages, publish completes every configured language before freezing: missing translations are produced as part of the act, and if translation fails the publish refuses and is simply retried. A frozen document is therefore always complete — there is no such thing as a half-translated publication, and the operator never has to think about translations to publish.
The recipe the publish looks for is a recipe in force, not a recipe with ingredients in it. A menu may carry an item whose sale spends nothing — a room hour, a cover charge — and the way to say so is an empty recipe, authored deliberately and put in force like any other. The gate then passes: it was never asking what the sale costs, only whether somebody had answered. What it refuses is the item nobody has answered for yet — the dish put on a menu before its recipe was written, which would otherwise sell all week at a cost of nothing and be discovered at the close.
Publication is the one place that considers the target together with every offered variant referent: it certifies the full set of items the menu may sell. Once the row is resolved, availability and derived facts follow only its standard sold item.
7. Placement — which menu a storefront serves¶
A placement is the mapping rule that puts a published menu on sale. It targets either a whole channel — covering every storefront of that channel — or one storefront. The storefront-grain rule beats the channel-grain rule; each exact target carries at most one placement.
placements: Delivery menu → Glovo (channel)
Nonna menu → "Nonna — Glovo" (storefront)
"Nonna — Glovo" serves the Nonna menu (specific wins)
"Burger Bar — Glovo" serves the Delivery menu (covered by the channel rule)
Deleting the storefront-grain rule lets the channel-grain one cover that storefront again. A placement is a plain mapping — re-pointed or deleted at will, with no history of its own (§9 explains what that means for backdated views).
The price band rides the placement, at either grain — "+30% everywhere on Glovo" is one channel-grain band, not a copy per storefront. The band is an uplift ratio plus a rounding rule (a step and an ending), and rounding snaps strictly upward to the nearest price on the grid — never below the band, because the band exists to make sure the uplift covers what the channel costs, and silent under-pricing is the one failure it must not have:
menu price 10.00 → ×1.30 = 13.00 → grid (step 1.00, ending .90) → 13.90
The placement also carries an override sheet: per menu item, an explicit price (which wins untouched — no uplift, no snap), a hidden mark, or replacement photos. Bands and overrides never stack across grains — the one placement that resolves for a storefront applies whole.
8. Stop — the 86¶
A stop takes one item off sale at one restaurant: "86 the burrata" — or "86 the oat milk", an item customers only ever meet inside a choice. It may carry a lapse moment ("until tomorrow 10:00") and an authored reason, and may be scoped to specific channels — delivery only, while the hall still serves. An empty scope means every channel. Whether a stop is live is always derived — it has been neither cleared nor lapsed — and a stop is never erased, so yesterday's stops still explain what a storefront showed yesterday.
A stop acts on the item, so its effect lands everywhere that item stands. Every choice naming it carries the verdict wherever it is offered (§5). A menu row follows one standard sold item — its default variant referent, or otherwise its target — and carries that item's stop verdict. Stopping another variant darkens that option but neither takes the row down nor rescues it from a stopped standard sold item. That is why stopping lives at the item grain, not the menu grain. And a stop only shapes what storefronts show: it never blocks a sale from posting. A marketplace that sold the burrata before the page refreshed produced a real sale, and the books record reality (see Sales & consumption).
9. What a storefront serves — one resolution, two views¶
Everything above converges in one question: what does this storefront serve right now? The answer is one resolution — most-specific placement, version in force at the asked moment, that placement's band and overrides, live stops, availability windows evaluated in the restaurant's own timezone (the only place windows are ever evaluated) — and the resolved document keeps a deliberate split:
- Hiding is the only pruning. A menu item hidden by the placement is absent, and a section with nothing left disappears with it — a competitor-priced item simply does not exist on that page.
- Everything else stays, carrying its verdict. A stopped menu item stays in the document together with the stop's lapse moment and reason; a stopped choice stays inside its group the same way; an out-of-window menu item stays with its windows. A marketplace needs the 86'd dish present so it can be snoozed rather than deleted; filtering it out and re-deriving visibility on the other side would be a second copy of the rule.
This resolved document is what a sync delivers (§10): same pruning, same verdicts, one read. Preview and delivery can never disagree, because they are the same resolution.
Each resolved menu item also shows the derived food-cost share — the current cost of its standard configuration divided by the effective (post-band, post-override) price. Defaults first resolve the sold item — the target or its selected variant. A made-to-order sold item resolves into one concrete recipe build; a stocked one costs at its reference price. Default add-ons are priced as their own products, with a made-to-order add-on using its base build. A carbonara costing €3.10 in ingredients reads 31% in the hall at €10.00 and 22% on Glovo at €13.90. It is a fact about today, derived on the spot, never stored — and it is a cost share, not COGS, which remains the period aggregate of actual sales. When a default choice's item cannot be priced, a required group has too few defaults, or the defaults leave a slot unanswered — or name something the recipe does not hold — the share says it is incomplete rather than quietly understating. Whether the row can be sold is the wider question, asked of every size at once (§5).
A menu can also be viewed without a venue — the version in force, or the working state, rendered as a plain document for printing or for hand-mirroring into a marketplace the business maintains manually. No venue means no band, no overrides, no stops, and no clock to evaluate windows against, so windows ride as information.
A backdated storefront view reconstructs what held at that moment from the two things that keep history — the version timeline and stop intervals. Placements, bands, and overrides are deliberately unversioned (they are live commercial tuning, not record), so a backdated view applies today's band to the version then in force, and says so.
10. Sync — a platform's copy, kept honest¶
A sync records the copy of a storefront's offer held by a particular sales platform destination. A storefront may serve several destinations: the same menu can appear on a brand's own site and on a site collecting several brands. Each copy has its own delivery progress, because one site accepting a menu says nothing about whether another site has received it. The menu remains independent of those copies.
The sync's state is a comparison. The record remembers what the platform last accepted; the menu module knows what the storefront resolves to right now; pending is the drift between the two. Nothing marks a menu "dirty" when it changes — a publish, a price move, a stop, a lifted stop each change what resolves, and therefore what the comparison says, by construction. Synced means the platform has acknowledged the current offer; failed means the last delivery broke, and the record says why. Repeating a delivery preserves the same offer, and a delayed older delivery cannot replace a newer one. If a stop is set and lifted before acknowledgement returns, the lifted stop still needs to reach the platform: matching an earlier accepted menu alone does not prove the latest offer arrived.
What travels is the resolved document itself (§9) — prices, choices, windows, and stop verdicts included, because an 86 reaching the platform is much of the point — with one deliberate cut: internal economics. The food-cost share and its verdicts never leave the house; they are the operator's facts, not the platform's. A storefront that currently resolves to nothing syncs an honest empty catalog carrying the coded verdict — the platform would show nothing, and now both sides say so.
Penne carries the company's own sales channel through online stores — distinct websites or apps, each with its own identity. A company can operate several stores, and each store can contain several points. A point serves one Noir storefront; inside a store, a storefront appears at most once. For example, two restaurants may share one brand site, while another site offers several brands. A storefront can participate in both sites. Each store has its own customer cart and order history, even when the customer has one account with the company.
The point chooses whether to offer pickup, delivery, both, or neither while being prepared. The restaurant supplies the corresponding operating rules. Menus come from Noir, with prices in the company's currency and availability in the restaurant's timezone. Every connected storefront belongs to one company and restaurant; publication preserves that ownership.
A restaurant also has state that moves during a shift, and it belongs to the restaurant, not to any menu. Its working hours are a weekly pattern of windows in the restaurant's own local time. A window that ends earlier than it starts runs past midnight and belongs to the day it starts on: "Monday 18:00–02:00" keeps the kitchen open at half past midnight on Tuesday even when Tuesday itself is closed. Two windows on one day are a split shift, a day with no window is closed, and a restaurant with no windows at all is closed for its own online ordering — hours nobody entered are not hours. A pause stops external ordering for a while: until a stated moment, or until someone resumes. It covers every external channel, or only the delivery or only the pickup of the restaurant's own online store; with both paused, the own channel is paused as a whole. A pause concerns orders not yet placed: an order a marketplace already took is a real order and is still received, and the dining room keeps serving. Kitchen busy adds minutes to what the kitchen promises for as long as it lasts.
This state is true the moment it is set, so it never waits for a publication and never changes a published offer. Platforms differ in what Noir can do for them, and the answer is given per kind of change — the menu, an 86, a pause, the hours, the busy state. A change is managed where Noir carries it to the platform, and manual where someone must repeat it in the platform's own back office. A change can also not concern a destination at all: a delivery pause says nothing to a marketplace, which runs its own delivery, and an 86 scoped to one channel says nothing to the others. A destination whose menu is manual holds no copy for Noir to compare, so it is never pending — only kept by hand.
Changing a point's source starts a new offer relationship. Earlier orders retain the offer and source they were sold against. Retiring a point ends new sales there; its earlier orders and published offers remain part of the business's history. Marketplace menus maintained by hand remain separate from this publication flow.
The sandbox delivers nowhere and always accepts, so the whole loop — publish, watch pending appear, sync, watch it settle — can be rehearsed without changing a customer-facing menu.
11. The ticket records where it sold — and nothing gates it¶
A sales ticket may record the storefront it sold through. That attribution is enrichment, never a gate: a ticket ingests, posts, and is corrected identically with or without one, because a business may sell through channels never connected to the menu module at all, and the fact of a sale — lines, quantities, money — must never be held hostage to the selling surface's adoption. The ticket's money comes from the ticket and its depletion from the catalog and recipes, never from the menu, so pointing a ticket at the right storefront later — even a fully posted one — changes only how the sale reports: no stock moves and nothing is recorded again.
Channel reporting derives through the chain ticket → storefront → channel, and follows a re-point. For tickets never attributed, the free-text source label the feed carried remains the reporting fallback. What a re-point never rewrites is provenance: when a sale line resolved while a menu was in force, it remembers which menu item it sold as — that stamp records the resolution that actually happened and stays as written (how attribution narrows name matching, and why holding a line answers ambiguity but never absence, is taught in Sales & consumption).
That provenance is also why a menu item's identity outlives its menu: a menu item never frozen into a publication and never sold can be deleted outright, but once either fact exists — and marketplace sales arrive late, sometimes re-fed weeks later through an integration keyed to it — the menu item is only ever archived: gone from the working document and future publications, permanent in history.
See also¶
- Catalog — items, product cards (the presentation home menu items default to), recipes and packaging variants.
- Sales & consumption — how an arriving sale resolves names, depletes stock, and is held; the sale-side half of attribution.
- Scope & locations — the four attribution axes and why a channel is never a stock or valuation axis.
- Recipes & production — the recipe timeline, packaging variants, and made-to-order explosion.