Catalog — the reference data the whole operation runs on¶

What this covers. Before stock can move, the business has to describe what it buys, holds, makes, uses, and sells. That slow-changing description is the catalog. Its one identity is the item: flour, a bottle of cola, a paper cup, a made-to-order carbonara, or an oven all begin on the same spine and acquire different behavior from explicit policy facts. This chapter explains that spine; the product card that gives a sellable item one customer-facing face; the category that groups and seeds items; the measures, units, suppliers, and supplier products that surround them; and the recipe that states how a producible item is made. The chapters linked below teach what those facts do to stock, cost, sales, and food safety.

1. The catalog is the noun layer¶

Start with the cleanest possible distinction. A restaurant's data splits into what exists and what happened. The catalog holds the first kind — the nouns. A sale, a goods receipt, a transfer, and a stock count are verbs in the stock books. Every verb acts on a noun. Flour must exist as an item before it can be received; carbonara must exist as a sellable item before a sale can resolve its recipe.

The catalog is therefore the standing description of the business: its items, their recipes and presentation, and the measures and vendors around them. It changes deliberately while the faster world of stock movements reads it constantly.

One boundary shapes everything here: the catalog does not depend on the stock books, on sales, or on an outside system. Reading an item or product card never reaches into the ledger, a delivery platform, or a till. The catalog describes; the verbs act. That separation lets an operator improve a description or prepare a new recipe without disturbing a single number already in the books.

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. One item spine, with a product card where presentation matters¶

At the center of the catalog is one identity: the item. An item is anything the business buys, holds, makes, uses, or sells — flour, a bottle of cola, a paper clamshell, a carbonara made to order, an hour of a meeting room, or a stand mixer. Measurement, purchasing, recipes, food attributes, and stock behavior all meet on that one identity. The different examples behave differently because their policy facts differ, not because they belong to separate catalogs.

Selling has two honest depletion behaviors. A stocked item leaves its warehouse one-for-one in a stated unit: a bottle of cola or a retail bag of coffee. A made-to-order item is producible but not stocked; its sale quantity counts the recipe's portions, and the recipe is exploded into the materials that actually leave. An item outside those two behaviors is not a sale target. This keeps a counted consumable, a small tool, and a fixed asset in the accounting world they belong to instead of forcing a sales meaning onto them.

The restaurant word dish survives as useful everyday vocabulary, not as a second identity. A dish is a made-to-order sellable item — a phantom, the treatment with nothing of its own to account for — owning a recipe and wearing a product card. The definition follows those stable facts, never the category name. The seeded Dishes category simply supplies the usual defaults for a new dish: the phantom treatment and its own recipe. Services is the same preset under a different heading — a room hour, a session, a delivery fee — where the recipe may run down to nothing. An operator may rename either category or create a differently named one with the same defaults; neither act changes what the item is.

A product card is the customer-facing face of one item. It gives the product one authored name and description, an ordered photo gallery, and supporting documents, so presentation is written once instead of drifting across every place the item is sold. Its public serving measure defaults to one portion of the item's recipe in force on the relevant company date, such as 250 g or 330 ml. An authored serving measure takes precedence until cleared; recipe changes never overwrite it. The authored amount has one decimal place and names either a company-shared catalog unit or a customer-facing unit label, such as “slices”. The catalog unit belongs to the item's dimension or the recipe portion's dimension: a dish sold in pieces may have a public portion in grams. Comparison with the recipe requires a unit in the recipe portion's dimension. An authored label declares no conversion, so it does not support numerical comparison with the recipe. An unavailable recipe portion stays unknown; stock units, batch output weight and nutrition bases do not supply it. Published menus retain the serving declaration in force at publication. The card may also carry an ordered ingredient display list authored for the customer. Those words describe the product; they neither identify recipe components nor determine allergen facts. An unstated list remains unknown, while an explicitly empty list declares no ingredient labels. The card also owns which customer choices the product offers — the modifier groups it attaches and their default picks. Those picks form the product's standard configuration for storefront presentation and menu food cost; they are not production defaults. Where production has variability, composition and quantities remain in the recipe matrix. The boundary is taught with the menu surface in Menus & storefronts. It carries no commercial guidance, selling price, channel, station, recipe portions, nutrition, or allergens: price belongs to the menu item that puts the product on a menu; the station belongs to the catalog item; portions belong to the recipe; and food facts remain on the item and its composition. A stocked resale item may gain a card when it needs customer-facing presentation. A made-to-order dish wears one as part of being sellable.

Tags classify items through a per-company taxonomy. Each tag has a stable key, an authored localized name, and a category that says whether it expresses flavor, dietary discovery, marketing, or a compliance assertion such as alcohol, a certification, or spice level. The stable key carries the meaning integrations may rely on; the editable name is presentation. Tags do not move stock and do not own visual styling.

A catalog photograph serves two purposes at once: evidence of the real thing and quick recognition. The captured source therefore remains available even when a selected enhancement improves the surroundings, framing, lighting, or perspective. Enhancement may improve presentation but not rewrite evidence: an item's label, physical proportions, meaningful colors, and defects remain true; a dish keeps its complete food, portion, arrangement, and serving vessel; and a preparation image keeps the visible action, state, hands, tools, quantities, and displays. Returning to the source changes presentation only, never identity.

Worked example. Carbonara is one item with the Dishes preset: it owns a recipe, is not held in stock. Its product card carries the customer-facing name, description, and plated photograph; its station says the work belongs to the kitchen; its recipe declares the ingredients and portions. Spaghetti, guanciale, egg, and pecorino are items too, but stocked ingredients. One spine, different policies, one plate.

3. What an item carries¶

An item is the busiest catalog noun because it sits where measurement, purchasing, recipes, the books, presentation, and food safety meet. Most of those concerns are taught elsewhere; this is the map.

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 products 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, 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.
Production and routing — a producible item may own a recipe, and a made-to-order item may name a station whose per-restaurant mapping guides where its recipe leaves are drawn from (Scope & locations).
Presentation — an optional one-to-one product card holds the customer-facing name, description, gallery, and documents. It is a face over the same item, never another identity.
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 away is that an item is a hub. The catalog keeps one identity; the surrounding facts explain how that item is measured, bought, made, shown, sold, counted, and kept safe.

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.

The category is also the item's one classifier. It is where the vocabulary of the trade lives — dishes, services, ingredients, prep items, small tools — and it is the single question a person answers when they file something new. The policy facts sit a rung below it, as the fine print of how the thing is accounted for; a card states them in a line and opens them only when someone means to change them. Which makes the next rule easy to mistake, so it is worth being exact about.

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. Classifying and governing are two different jobs, and only the first belongs to the label.

A new business does not start with an empty tree. Nine categories are laid down at registration, each carrying the presets its family needs: Raw Materials, Packaging, Prep Items, Goods, Consumables, Small tools, Equipment, Dishes, and Services. They are ordinary categories from the moment they exist — rename them, re-translate them, delete the ones the business does not use, add ten more.

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 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, but the same record also carries how the thing is made and serves the whole operation.

A scheduled recipe belongs to one producible item. That item may be made to order, like carbonara, or produced ahead and stocked, like peeled carrots or base sauce. The owner is still one item in both cases. A version may begin ownerless while the composition is being developed, but joining an item's dated recipe timeline gives the recipe the identity whose output it describes.

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, cooking time, and portion facts: the how-to a bare parts list can't hold. Packing is expressed as packaging variants: each holds a localized description, packaging materials, steps, and media — the content that actually tells a cook how this packing differs. A recipe keeps at most one variant per fulfillment — one for dine-in, one for delivery — and at most one general variant that names no fulfillment and packs every sale the other two do not claim. Variants are optional, and none of them makes the recipe know anything about a sales channel. 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 product 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 a closed period has priced is never edited again. 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. Descriptive text, steps, photos, and notes stay editable on any version; the ingredient list and portion facts — the parts that drive cost and yield — stay editable while the books are open, and correcting them re-explodes the open-period sales that posted through the version in the same stroke, so a mistyped quantity is fixed in place and the books follow. While a close in force has priced consumption through a version, that composition stays fixed: changing a gram of an ingredient means a new version, each carrying a short change note saying what changed. This is what makes the cost of a past sale attributable — every close retains its original evidence, and every explosion names the version that explained it.

Recipe actuality: one recipe in force per item per date. Because versions are dated, "which recipe governed this item on date D?" has exactly one answer: the scheduled version with the greatest effective date at or before D. This is the recipe actuality rule, and it is the lookup the stock side uses whenever a made-to-order sale must be costed.

Worked example — recipe actuality. The made-to-order item "Roast Carrot Plate" has three scheduled versions: v1 effective 10 Jan, v2 effective 1 Mar, v3 effective 15 May. A customer 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.

Scheduling may even be backdated: a version's effective date may lie in the past — the deliberate escape hatch for a made-to-order item that started selling before its recipe was recorded; the held sales resolve it and post through it, and open-period sales the new date covers re-explode to it in the same stroke (see Recipes & production). A recipe that was wrong rather than missing is repaired with the schedule itself — the mistaken version unscheduled, the corrected one taking its date (Recipes & production).

A recipe also has an advisory completeness reading — a rough sense of how finished it is (does it have ingredients, steps, the header facts, a photograph). It counts as photographed whether the image lives on the recipe, one of its steps, or the owning item's product card: what matters is whether a cook can see the intended result. Packing sits outside the reading, since it applies only where the product is packed and would hold every other recipe permanently short. It is a helpful nudge for an operator, never a gate: completeness never blocks a recipe version from being scheduled. 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.

A deterministically composed producible item has two recorded recipe-cost readings. Its reference cost says what it costs to make on that date, pricing each input at the reference chosen by its price policy: the newest market fact, a manual reference, one chosen supplier product, or the input's blended stock cost. Its stock-valuation cost reads the weighted-average value of ingredients already held. The two may agree while prices are steady and part company when policy or markets move.

Each producible item can accumulate dated cost points carrying those food and packaging costs, the recipe version priced, and the date they describe. They are company-level recipe-cost facts, not a second stock pool: when the produced item is itself stocked, its sale still consumes the output at that warehouse's own average cost. A cost point records cost only; selling price and margin belong to the menu item that puts it on sale.

A recipe matrix authors every possible composition, not one resolved build, and therefore has no single cost point. Its base or concrete builds can be priced on demand. When menu defaults select a made-to-order sold item, its standard configuration prices the resulting concrete build. A point recorded before the recipe became a matrix ceases to describe the current recipe.

Pure replacement cost remains a separate calculation. It asks what every input would cost to re-buy from the market on a chosen date. Dated market facts are enough to derive that answer whenever it is needed. Reference cost is the history worth preserving because a pricing policy or manual reference can later change without leaving the old answer recoverable.

Saved lists arrange plans without changing catalog or stock¶

A saved list is a shared, reusable plan in the operator's own order. Its immutable SVL-... code identifies it; an operator-authored name is optional, and an unnamed list needs no substitute name. Independently, the operator orders sections and chooses whether each is about items or exact recipe versions. An authored section title is optional: its structured item or recipe type preserves the section's meaning in every language without an invented English title. Each entry names something by pointing at one of those catalog records, carrying free text, or doing both: “tomatoes from the Saturday stall” can remain useful before it is resolved to an item. Quantity and an entry note are optional. Repeating a section type or the same need is allowed because the operator's grouping and order are the point of the list.

The whole list may carry an overall note, supporting attachments, and any number of plain-text labels, including none. Labels are a lightweight company vocabulary for finding and grouping lists, not catalog records and not workflow states. A new company begins with Shopping as its only configured suggestion; operators may replace that vocabulary. Suggestions combine those exact configured labels with each distinct label used by any of the company's lists, including soft-deleted tombstones. One list may carry several labels, and no accounting or stock behavior may ever depend on an editable label.

Saving the material totals from a production calculation creates a new list with one item section. It is an independent copy of the calculated plan, editable afterward, while each linked entry still opens the current catalog record. A goods receipt may likewise cite a saved list as the source that helped prepare a market run, but the receipt records what was actually bought and does not consume or close the list. A saved list never schedules a recipe, approves a plan, moves stock, or becomes a purchase document. It has no open, closed, or cancelled lifecycle: it remains reusable until it is soft-deleted. Soft deletion hides it from active use without erasing its authored plan or the provenance already kept by a receipt. Restoring it returns that same list, with the same SVL-... identity and contents, to active use.

6. Measures, units, and supplier products — 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 product (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 product — the optional catalogue line that prices an item, in a chosen unit, for one supplier:

Supplier products — how you buy an item from a vendor, and at what. A supplier product 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 line read off the supplier's paper be matched to it. The same item from two vendors (or priced two ways by one vendor) is simply two lines. Reducing each line's price to a price per base measure is what lets a buyer compare two vendors honestly. The supplier product 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 product 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 products are what make the two prices comparable at all.

A separate, smaller measurement concept belongs to the recipe rather than the stock book: its portion declaration says how many servings an output makes and may describe one serving in a friendly unit such as one plate or a 250 ml bowl. Portions answer how a made-to-order item is served; stock units answer how an item is bought, held, and counted. The two questions remain separate even when both happen to use 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, expensed 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 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. A consumable is not held in stock — its cost is expensed when received (oil, salt). A counted consumable is expensed the same way and still keeps a quantity book worth zero (gloves, printed menus). A small tool — a pan, a knife — is pooled at cost and expensed the day it dies. A fixed asset is a durable asset routed to a separate asset ledger (an oven, a mixer). And a phantom never materializes: neither held nor bought, so there is nothing of its own to account for — a made-to-order carbonara, an hour of a meeting room. A sale of it, an internal use of it and a write-off of it all explode its recipe and spend the materials instead, and if its recipe is empty they spend nothing.
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 with a recipe of its own (on screen, own recipe — a batch of dough, a carbonara, a meeting-room hour), packaging (rides out with a prepared product; counted as ordinary stock, costed into a packaging bucket kept apart from food cost), or none (small tools, fixed assets, resale goods, plain consumables — never recipe material). Once an item owns a recipe or a recipe relies on it, the role may change only to one those recipes still accept (item model §5); authoring a product card alone holds nothing.

One thing the treatment deliberately does not gate is buying. Any item that materializes can be ordered and received — there is no separate "procurable" switch — and the treatment routes what the received line does: a stock line lands in stock, a consumable line goes straight to expense, and a fixed-asset line creates an entry in the asset register with no stock movement at all. The one item nobody ever receives is the phantom — you do not buy a meeting-room hour, you sell one — and an order or a receipt naming one is refused rather than left to arrive at nothing. (Reorder pars belong to the books that keep a countable quantity — stock and counted consumables.)

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 a stock item — something you make from its own recipe and then hold in stock (peeled carrots, a base sauce). And the two axes are independent: a consumable 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. One catalog holds flour (stock, role ingredient — counted, valued), salt (a consumable, role ingredient — not counted, yet a real recipe ingredient at a reference price), a kraft clamshell (stock, role packaging — counted like the flour, rides on a recipe, rolls into packaging cost), and a combi oven (fixed asset, role none — received on an ordinary goods receipt, then standing on the asset register's own books, never counted as stock). Four items in one catalog, four different behaviors — every one of them read from the item's own policy facts. The catalog is one for the whole business; where each of them may then land is not, because a warehouse admits one family of item and only one.

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 producible item above a leaf 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 made product'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 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 made-to-order item 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. Review findings¶

The chat agent, Dough, can review a catalog record — 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.)

10. The catalog, in one pass¶

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

The item "Carbonara" carries the Dishes preset: a phantom that owns a recipe. It is made to order and never held as a stock balance.
Its product card carries the customer-facing name, description, and plated photograph. The item's station says which kind of work prepares it.
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 ingredient 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 product 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 five 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; Carbonara's versions of them are derived from its 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 customer 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.