Menu & Catalog — the reference data the whole operation runs on¶

What this covers. Before any stock can move, the business has to describe itself: what it sells, what it buys, what those things are made of, and how they are measured. That description is the catalog — the slow-changing reference data every stock process reads. This chapter is the tour of it: the dish (a menu item with a price and a place on the menu), the item (anything material the business holds or uses — flour, a bottle of Coke, a paper cup, an oven), the category that groups items, the measures that size them and the units they come in, the supplier and the supplier article that price an item, and the recipe (the versioned record that says what a prepared thing is made of). It is the lighter, descriptive layer; the behavior that rides on these records — how cost moves, how a sale depletes stock, how a recipe is exploded — lives in the chapters this one points to.

1. The catalog is the noun layer¶

Start with the cleanest possible distinction. A restaurant's data splits into two kinds of thing: what exists and what happened. The catalog is the first kind — the nouns. A sale, a goods receipt, a transfer, a stock count: those are the second kind, the verbs, and they live in the stock books. Every verb acts on a noun. You can't receive flour until "flour" exists as an item; you can't sell a carbonara until "carbonara" exists as a dish with a recipe.

So the catalog is the standing description of the business: the dishes it offers, the materials it stocks, the recipes that connect them, and the measures and vendors that surround them. It changes slowly and deliberately — an operator adds a dish, edits a recipe, onboards a supplier — and the much faster world of stock movements reads it constantly.

One boundary is worth stating up front because it shapes everything here: the catalog does not depend on the stock books, on sales, or on any outside system. Reading a dish or an item never reaches into the ledger, a delivery platform, or a till. The catalog describes; the verbs act. Keeping the noun layer free of the verb layer is what lets an operator edit the menu at noon without disturbing a single number in the books — and what lets the books trust the catalog as stable ground.

This chapter is mostly about what each noun is. Wherever a noun carries behavior — a policy that decides how money or stock moves — that behavior is taught in its own chapter, and this one only points at it. The catalog holds the facts; the other chapters explain what the facts do.

2. The two things you describe: dishes and items¶

At the center of the catalog are two record types, and almost everything else hangs off one or the other.

A dish is a menu item — the thing a guest orders and pays for. "Carbonara", "Negroni", "Roast Carrot Plate". A dish carries its catalog facts: a price, a status (is it live on the menu?), photos, descriptive text, and approved tags for classification and discovery. A dish also carries a station tag — kitchen, bar, from a small per-company vocabulary — naming where it is prepared; the stock side uses it to route a sale's consumption to the right warehouse of the selling restaurant (Scope & locations). Critically, a dish by itself holds no stock and depletes nothing — it is a thing you sell, and a sale of it only turns into ingredients leaving stock by way of its recipe (§5, and Sales & consumption).

A draft dish may be incomplete while the operator is still authoring it. The sale price and serving facts can be missing on a draft, but activation requires a positive price, a positive serving weight, and a serving-weight unit before the dish is eligible for menus.

Dish tags are a per-company taxonomy for classifying and discovering dishes. Each tag has a stable key, an authored name the operator types in their own language (the system keeps machine-made renditions in the company's other reading languages alongside it), a category that says what role it plays (flavor, dietary, browse, marketing, and so on), and optional classifier guidance for automation. A new company starts with the standard seeded tag catalog so operators can browse, filter, and curate dishes without inventing the baseline vocabulary from scratch. Tags do not carry storefront presentation: colors, images, badge tones, and visual styling belong to the future storefront model, not to the taxonomy record.

An item — in full, an inventory item — is anything material the business holds, buys, makes, or uses: a raw material like flour, a bought-in good sold as-is like a bottle of Coke, a paper clamshell, a stand mixer. An item is where measurement, purchasing, and — for most items — a real stock balance attach. Where a dish lives on the menu, an item lives in the warehouse (or, for a fixed asset, the asset register).

The two are deliberately different shapes because they answer different questions. A dish answers "what does a guest order, and at what price?" An item answers "what do we hold, how is it measured, and how does it behave in the books?" The recipe (§5) is the bridge between them: it says this dish is made of these items, in these quantities.

Worked example. "Carbonara" is a dish: it has a menu price, a status, a photo, and is offered at two restaurants. "Spaghetti", "guanciale", "egg", and "pecorino" are items: each is held in a warehouse, measured in its own units, and valued in the books. The carbonara recipe is what ties the dish to those four items — 110 g spaghetti, 45 g guanciale, 1 egg, 18 g pecorino per portion. Three record types, one plate.

3. What an item carries¶

An item is the busiest record in the catalog, because it sits at the meeting point of measurement, purchasing, the books, and the food-safety layer. Most of what it carries is taught in detail elsewhere; here is the map of what is on the record and where each part is explained.

Identity and grouping — a name, a code, and the category it's filed under (§4). These are how an operator finds and organizes items.
Measurement — a base unit that anchors the item to one physical dimension (mass, volume, or count), plus the units it is measured and bought in and the supplier articles that price it (§6). Everything quantitative about the item is denominated against its base unit.
Stock-behavior policy — a small set of stable facts (its accounting treatment, how finely it's tracked, its default storage condition, whether it's packaging, whether it's producible) that decide how the item behaves in the books and shelf-life defaults. This is the heart of the item model and is taught in full in Item model & policies; §7 below gives the one-paragraph orientation.
Food attributes — an optional nutrition profile, declared allergens, and a shelf-life. The catalog holds this state; how it's sourced and rolled up the recipe tree is the food-safety layer (Food attributes). §8 below says what lives where.

The thing to take from this section is that an item is a hub: a single record that measurement, purchasing, the books, and food safety all attach to. The catalog keeps these facts together on the item; the chapters that own each concern explain what they mean.

4. Category — a label for grouping, never a switch for behavior¶

Items are organized into a tree of categories — "Dairy", "Produce", "Packaging", "Cleaning" — that an operator extends freely. A category is a human-facing classification: it's how you browse your stock, filter a list, and sort a report. Operators add their own, rename them, and — because the system speaks more than one language — the same category reads "Packaging" in English and "Упаковка" in Russian.

Here is the one rule about categories that matters more than any other, and it's important enough that it has its own chapter: an item's behavior is never decided by the name of its category. A category that an operator can rename or re-translate must not be allowed to move money or stock. Instead, behavior rides on explicit policy facts carried on the item (§7). A category does exactly three legitimate jobs: it's a grouping label, it lends a code prefix to item codes (packaging items get codes like PKG-001), and it carries the default policy values copied onto a new item the moment it's created under that category. After that, the item owns its own policy; renaming the category changes nothing about items that already exist.

The full reasoning — why a renamed label silently re-routing money is the bug this prevents, and the precise test for "may a rule read the category?" — is in Item model & policies. The catalog-level point is simply: categories group and seed; they never govern.

Worked example. An operator creates a "Compostable packaging" category and sets its defaults so that items filed under it are expensed on receipt, untracked, and marked as packaging. Every item they add there is born with those policies — ready to ride on a recipe and roll into packaging cost — with no extra setup. Renaming the category to "Eco packaging" next week changes how things are grouped and nothing about how any existing item is costed: each item already carries its own copy of the policy.

5. Recipe — the company's recipe knowledge base¶

A recipe is the company's recipe knowledge base, not merely a parts list. At its core is the structured list of what goes into one prepared thing and in what quantities — the catalog record that connects a dish (or a made-in-house item) to the materials behind it — but the same record also carries how the thing is made and serves the whole operation (see the roles below).

A recipe is owned by one of two things:

A dish — "the carbonara recipe", which says what one portion of carbonara is made of. This is the bridge that lets a sold dish become ingredients leaving stock.
A producible item — the recipe for something the business makes and then holds in stock, like peeled carrots or a base sauce. An item you make from its own recipe and then stock is a prep item (§7), and its recipe says what one batch of it is made of.

Each ingredient line on a recipe points at either an item (flour, oil) or a nested recipe version (a specific version of "dough"), so a recipe is really a small tree that bottoms out in raw materials. But that structured tree is only one facet — the same record carries the rest of how a thing is made and how it is put to work across the operation:

The craft — authored text, free-form preparation steps, photos, packaging lines, cooking time, and portion facts: the how-to a bare parts list can't hold. Whoever writes it types in their own language and never tags it as a language; the system quietly keeps translated renditions for the company's reading languages so a line cook can read the method in theirs. On request the system also offers a copy proposal — a cleaner rewrite of the prose in the company's kitchen voice — which the writer reviews and accepts before anything changes.
The evidence food calculations read — nutrition, shelf-life, and allergens are worked out by reading the recipe (its ingredients and its preparation steps), so a richer recipe yields better answers (Food attributes).
The training and reference — a new cook learns a dish from its recipe and is attested on it (answering questions about its details), and a cook preparing a batch opens it on a tablet to remind themselves of the method.

Two properties of recipes are load-bearing enough to state here, though the mechanics live in Recipes & production:

A recipe is versioned, and a version is never edited once it's in force. A recipe changes over time — a supplier swap nudges an ingredient, a portion is re-sized. Rather than overwrite the old recipe, the system keeps each version as its own record. You edit a draft freely; when you activate it, you stamp it with an effective date and the parts that drive cost and yield lock. The descriptive text, steps, photos, and notes stay editable; the ingredient list and portion facts do not. To change a gram of an ingredient, you make a new version, and every version after the first carries a short change note saying what changed. This is what makes the cost of a past sale computable forever, against the recipe that was actually in force that day, while still leaving a readable trail of why the recipe moved.

Recipe actuality: one recipe in force per owner per date. Because versions are dated, "which recipe governed this dish on date D?" has exactly one answer: the active version with the greatest effective date at or before D. This is the recipe actuality rule, and it's the same lookup the stock side uses to cost a sale on its business date.

Worked example — recipe actuality. The dish "Roast Carrot Plate" has three activated versions: v1 effective 10 Jan, v2 effective 1 Mar, v3 effective 15 May. A guest ordering on 20 Feb is served — and later costed against — v1 (the latest version at or before that date); an order on 1 Mar resolves v2 (the effective-date boundary belongs to the newer version); an order on 1 Jun resolves v3. One date, one recipe, always.

Activation may even be backdated: a new version's effective date must come strictly after the latest active version's, but it may lie in the past — the deliberate escape hatch for a dish that started selling before its recipe was recorded, with already-posted consumption never re-exploded (see Recipes & production). Backdating also anchors the fix for a recipe that was wrong rather than missing: the corrected version takes effect from when the error began, and a separate correction document — never a re-explosion — trues up the journals (Recipes & production).

A recipe also exposes an advisory completeness reading — a rough sense of how finished it is (does it have ingredients, steps, the header facts, its authored text, photos). It's a helpful nudge for an operator, never a gate: completeness never blocks a recipe version from being activated. It measures the authored document the operator writes, not how many languages a translation reaches — reading in another language is a convenience the system arranges in the background, not a box the author has to tick.

What a dish costs: one number to price by, a second to tie to the books. The same recipe can be costed in two worlds, and a good menu decision needs to know which. The menu cost is what the dish would cost to make today, built from each item's current price — the trade also calls it the replacement cost, what re-buying everything would cost right now — and it is the number you set and defend a menu price with. The stock-valuation cost is what the ingredients you already hold actually cost the business — the figure that ties back to the books, explains past margin, and is kept as history. The two agree while prices are steady and part company when they move: if flour has climbed from €0.50 to €0.80 a kilo but the warehouse still holds the cheaper sacks, the stock-valuation cost still reads €0.50 while the menu cost already reads €0.80 — the signal to re-price the menu while the cheaper sacks last, not after they run out. A component the kitchen makes fresh and never stocks has no price of its own, so under either world it is costed by looking through to the raw materials it is made from. A prep item — one you make and then hold in stock — is itself a stocked ingredient, and over it the two worlds part just as they do over the flour.

Steadying the menu cost at the item. Because the menu cost is built from item prices, a single noisy event — one odd walk-in receipt, a mistyped invoice line — would otherwise drag every dish that uses that item. The answer lives on the item, once, for every dish: an item carries a price policy, and the classic answers to price drift are to freeze, to pin, or to average. Left automatic, the price is simply the newest market fact seen — a supplier's current catalogue price or the last actual purchase, whichever came later. Typing a manual price outright freezes it: "blueberries run about €12/kg", entered in whatever unit reads naturally and shown back exactly as typed. The everyday small shop knows its prices by heart long before it has a single supplier article, and a costed menu should not have to wait on paperwork — so the hand-typed figure is right for an item with no purchasing record yet, or to overrule noisy records by hand. Pinning freezes not the number but the source: the price follows one chosen supplier's article and holds there against other, newer prices until it is unpinned — right when one supplier is the reference for that item. And the stock price averages: for a stock-tracked item, the menu price is simply what the stock on hand is worth per unit on average, blended across every warehouse that holds it (falling back to the average as last observed when the stock runs out), so one odd receipt moves the price only in proportion to the quantity it added — right for a shop that runs stock, trusts that number, and wants the menu to follow it. Neither the pin nor the stock price ever borrows from elsewhere when it has nothing to say: a pin whose article is deleted or re-aimed at another item, or a stock price on an item whose stock has never said anything, reads as unpriced — loudly — rather than quietly slipping back to the newest market fact or a hand-typed figure. And all of these knobs are for things you buy: a made-in-house component is never purchased, so a price opinion set on it simply sits unused — it is costed by the look-through above. Steadying a raw material by any of the three protects every prep and every dish above it at a stroke; there is nothing to set per dish, and these knobs shape the menu world alone — they never touch stock valuation, which stays a plain record of what the stock on hand is worth (a stock price reads that record into the menu world; nothing flows back). So a dish has one cost to lead with — the menu cost — with the stock-valuation figure kept as the accounting-world second opinion for the screens that want it; showing both side by side by default would only muddy a pricing call.

6. Measures, units, and supplier articles — how an item is measured and priced¶

An item has to be measured, and a food business names the same physical amount a dozen ways: flour arrives as a "case of six 2 kg bags", a recipe asks for "300 g", a stock count reads "4.5 kg". The catalog carries what reconciles all of those into one honest number — and, separately, what records how it is bought. The full conversion machinery is Units of measure; here is what the catalog holds, in two layers that are deliberately kept apart: the unit (measurement) and the supplier article (price).

A unit is a measure — how much of something there is. Every unit belongs to one physical dimension — mass, volume, or count — and units only convert within a dimension (the system never guesses a density to turn milliliters into grams). A few kinds sit in the catalog:

Standard measures — a small, company-shared dictionary of generic units (gram, kilogram, ounce, pound; milliliter, liter, fluid ounce, quart, gallon; piece). They belong to no single item and can't be edited — they're the fixed anchors every other unit is expressed against. (Operators may also add their own company-shared custom measures, like a house scoop.)
Per-item units — a factor true for one item. One shape is a density-like measure: "a cup of this flour = 120 g" is an item-scoped mass measure, never an implicit volume-to-mass conversion, something you portion in. The other shape is the bundle the item is bought in — "a 2 kg bag", "a case of 6 × 2 kg". A bundle is not a separate kind of thing: it is a per-item unit storing one flattened conversion number (a case of 6 × 2 kg = 12 000 g, no nesting), plus the manufacturer's barcode and an optional photo so a buyer can recognize it. Like every unit it is supplier-free and priceless on its own — the same 2 kg bag is the same bag whoever sells it.

The commercial facts live one layer up, on the supplier article — the optional catalogue line that prices an item, in a chosen unit, for one supplier:

Supplier articles — how you buy an item from a vendor, and at what. An article references an item and the unit it is priced in — though a freshly imported line may sit unresolved, naming the vendor's own words for what it sells until someone matches it to one — and hangs a price, the practical buying details (minimum order quantity, lead time, photos), the recorded price history, and the recognition keys — the supplier's code and the free-text descriptions it has used before — that let a delivery's invoice line be matched to it. The same item from two vendors (or priced two ways by one vendor) is simply two articles. Reducing each article's price to a price per base measure is what lets a buyer compare two vendors honestly. The article is never required to bring stock in — that is the procurement side's concern (Procurement).

An item's base unit is chosen once and names the item's dimension — flour is a mass item, so its base unit is the gram, and every number the books keep about it (on-hand, cost) is in grams. A supplier article carries one more piece of catalog metadata worth naming: a last-received timestamp, a display-only note of when this vendor last delivered the item on a goods receipt. It's informational; it doesn't drive a receiving flow.

Worked example — comparing two flour vendors. Vendor A sells flour at €18.00 per case of 6 × 2 kg (a unit that flattens to 12 000 g): 18.00 ÷ 12 000 = €0.0015 per gram. Vendor B sells it at €2.40 per 2 kg bag (2 000 g): 2.40 ÷ 2 000 = €0.0012 per gram. Side by side, Vendor B is cheaper per gram — even though its sticker price looks smaller only because its unit is smaller. The supplier articles are what make the two prices comparable at all.

A separate, smaller measurement concept belongs to the menu side, not the stock side: a dish and a recipe describe their serving size in a portion-facing unit — a friendly vocabulary for "one plate", "250 ml bowl". This portion unit is deliberately kept apart from the units an item is bought and counted in: a dish's serving size and an item's stock quantity are different questions, even when both happen to be grams.

7. The behavior an item carries — a pointer, not the lesson¶

An item isn't only described — it behaves. Whether it's counted and valued, written off the day it arrives, or treated as a durable asset; whether it can ride on a recipe; whether it's something you make. All of that is decided by a small set of stable policy facts on the item, and it is the subject of an entire chapter: Item model & policies. This section is only the orientation a catalog reader needs.

The facts that matter most for understanding the rest of the catalog:

Accounting treatment decides the item's whole stock life. A stock-tracked item has a perpetual on-hand balance and a value (flour, a bottle of Coke). Perpetual means the balance is kept continuously correct as movements happen, rather than figured out only at a month-end count. An expensed-on-receipt item is not held in stock — it goes straight to expense when received (oil, salt, gloves). An expensed-on-write-off item is a durable smallware — a pan, a knife — pooled at cost and expensed the day it dies. A capitalized item is a durable asset routed to a separate asset ledger (an oven, a mixer).
Recipe role decides what the item may be inside a recipe — exactly one of: an ingredient (an atom line that never decomposes — flour, oil), a producible item you make (the candidate for owning a recipe — you make dough, not raw flour), packaging (rides out with the dish; counted as ordinary stock by default, costed into a packaging bucket kept apart from food cost), or none (gloves, smallwares, fixed assets, resale goods — never recipe material). The role can be changed freely until the item is actually used in a recipe; from the first card, ingredient line, or packaging line that relies on it, the role freezes — just as base unit and treatment freeze on first stock movement.

One thing the treatment deliberately does not gate is buying. Any item can be ordered and received — there is no separate "procurable" switch — and the treatment routes what the received line does: a stock-tracked line lands in stock, an expensed-on-receipt line goes straight to expense, and a capitalized line creates an entry in the asset register with no stock movement at all. (Reorder pars remain a stock-tracked-only concern.)

From these, two derived ideas recur across the catalog. A prep item — formally, a semi-finished good — is an item that is both producible and stock-tracked — something you make from its own recipe and then hold in stock (peeled carrots, a base sauce). And the two axes are independent: an expensed-on-receipt item like salt, carrying the ingredient role, is a perfectly valid ingredient, costed in a recipe at a reference price (its last-purchase or a standard price) even though it's never counted as stock. What an item may be in a recipe is the role's question; how its money flows is the treatment's.

The reason these live in their own chapter and not here is the same reason §4 keeps behavior off the category: the what of an item belongs in the catalog, but the rules that move money and stock are precise enough to deserve a dedicated, careful treatment.

Worked example. A warehouse holds flour (stock-tracked, role ingredient — counted, valued), salt (expensed-on-receipt, role ingredient — not counted, yet a real recipe ingredient at a reference price), a kraft clamshell (stock-tracked, role packaging — counted like the flour, rides on a recipe, rolls into packaging cost), and a combi oven (capitalized, role none — received on an ordinary goods receipt, then living in the asset register, never counted as stock). Four items in one catalog, four different behaviors — every one of them read from the item's own policy facts.

8. Food attributes the catalog holds: nutrition, allergens, shelf-life¶

The catalog is also where an item's food facts live: an optional nutrition profile, declared allergens, and a shelf-life. These are open to any item — including a resale good like a bottle of Coca-Cola, which carries nutrition and allergens even though no one cooks it. None of them is gated by an item's category or its stock policy.

The line to draw — and it's the one the catalog cares about — is between state and computation. The catalog holds the state: the nutrition numbers on an item, the allergens it declares, the shelf-life it carries. How those facts are sourced (from a label, a barcode, a nutrition reference) and how they roll up a recipe tree to every dish that uses an item is the food-safety layer, taught in Food attributes. The catalog stores; that layer computes.

Why does the catalog hold the state rather than the food-safety layer owning it end-to-end? Because nutrition, allergens, and shelf-life are facts about an item, sitting naturally on the item record alongside its name and units — and because a dish's nutrition or allergens are derived from the items in its recipe, so the leaf facts have to live on the items for the rollup to have something to roll up. The catalog provides the leaves; the food-safety layer walks the tree.

Worked example. A bottle of Coca-Cola is a stock-tracked resale item — bought to sell as-is, never cooked. It still carries a nutrition profile and an allergen declaration on its catalog record, because nutrition and allergens are ungated: any item may hold them. A dish that includes that bottle inherits its allergens through the recipe rollup — but that inheritance is the food-safety layer's job; the catalog's job is simply to hold the bottle's own declared facts.

9. Findings, status, and what a catalog read returns¶

Two smaller catalog behaviors round out the picture.

Review findings. The chat agent, Dough, can review a catalog record — a dish, an item, a recipe — and leave findings: notes about something that looks off or incomplete. The catalog holds those findings and the timestamp of the last review, so a list can show a "needs attention" marker. The catalog stores this review state; it doesn't generate the findings — that's Dough's work. (A finding is always framed as a Dough finding — not to be confused with a stock count's overage or shortage adjustments, which are ledger facts.)

Status and visibility. Catalog records have a lifecycle, and reads respect it. Browsing a list shows live records and hides archived ones by default. A picker that must offer only selectable things — the ingredient picker, say — narrows further to live (non-archived) items with an eligible recipe role (an ingredient picker offers atoms and producible items, never gloves or fixed assets). And a record that's been soft-deleted is never returned at all. The guiding idea is that the catalog is a working surface: a read returns what an operator can actually act on right now, not the full archive.

10. The catalog, in one pass¶

Putting the pieces together, here is the whole noun layer behind one plate of carbonara:

The dish "Carbonara" is a menu item: a price, a status, a photo, a station tag, the restaurants that offer it. It holds no stock.
Its recipe — 110 g spaghetti, 45 g guanciale, 1 egg, 18 g pecorino per portion — versioned and dated, so the recipe that governed any past sale is always recoverable (recipe actuality, §5).
The four items behind it — spaghetti, guanciale, egg, pecorino — each carry a name, a category, a base unit and the units it is bought in, a stock-behavior policy, and optional food attributes.
A bundle unit on the spaghetti names how it comes packed, and a supplier article for that item-and-unit names a vendor and a price — so the spaghetti can be priced and reordered, and vendors compared per gram.
Categories group all four items for browsing and lend defaults to new ones, without ever deciding how any of them behaves.
Food facts — nutrition, allergens, shelf-life — sit on the items as state; a dish's versions of them are derived from the recipe by the food-safety layer.

Every one of these is reference data: slow-changing, self-contained, free of the stock books and the outside world. When a guest finally orders the carbonara, the verbs take over — the sale explodes the recipe into the four items leaving stock — but the catalog is what made that plate describable in the first place.