Item Model & Policies — how an item knows how to behave¶

What this covers. Every item in the warehouse — flour, salt, a paper cup, a combi oven, a bottle of Coke — behaves differently: some are counted and valued, some are written off the day they arrive, some are never inventory at all. This explains what decides that behavior. The answer is a small set of stable, explicit policy facts carried on the item itself — its accounting treatment, how finely its stock is tracked, its default storage condition, and its recipe role (what, if anything, it may be inside a recipe) — plus a handful of plain yes/no facts derived from them. It explains why behavior must never be decided by an item's category name; why "is this held in stock?" is one question that a whole cluster of capabilities collapses into; what the four accounting treatments are and how they route what receiving an item does; how the recipe role and the accounting treatment combine — including the combinations that look exotic but are deliberate; and which capabilities remain open to any item (carrying nutrition, declaring allergens, having a shelf-life).

1. Behavior rides on policy facts, never on the category name¶

The single most important rule in this chapter: an item's behavior is decided by stable, explicit policy facts carried on the item — not by the name of the category it sits under.

To see why, you have to know what a category is. A category is just user-extensible classification: a label an operator picks to group and find things ("Dairy", "Produce", "Packaging", "Cleaning"). Operators add their own categories freely, rename them, and — because the system speaks more than one language — the same category reads "Packaging" in English and "Упаковка" in Russian. A category name is therefore a moving, translated, operator-owned label.

Now imagine the books decided "should this be written off immediately, or counted as on-hand stock?" by looking at whether the category was called "Consumables". Rename that category to "Misc supplies", translate it to Russian, or split it into two — and money silently re-routes. An item that used to be expensed starts being counted, or the reverse, with nobody touching the item at all. A label an operator can rename must never be allowed to move money. That is the whole reason behavior rides on explicit policy facts instead.

This is not a Sizl invention — it is the textbook pattern every serious inventory-and-accounting system follows. They all do the same three things: keep an explicit, fixed-vocabulary policy on the item; default that policy from the item's grouping when the item is first created; and lock the accounting part once the item has any history. The category seeds the policy; it never decides behavior after the fact.

The one test for any rule. If picking the wrong category name would silently produce wrong money or wrong stock movement, the rule must read a policy fact. If the wrong category name only mislabels or mis-sorts something an operator can fix with no money consequence, reading the category is fine. "Is this packaging?" must be a policy fact. "Show me everything filed under Dairy" can read the category all day long.

Worked example. Two operators each create a salt item. One files it under "Seasonings", the other under "Dry goods". Both salts behave identically — expensed on receipt, never counted, usable in a recipe at a reference price — because behavior comes from each item's accounting treatment and recipe role, not from the category label above it. Later, an operator renames "Seasonings" to "Spices & salt" and translates it to Russian. Nothing about how either salt is costed or counted changes, because no rule was ever reading that name.

2. The small set of policy facts¶

An item's behavior is fully pinned down by four settings, each with a fixed list of choices, plus a handful of derived facts computed from them. They are a small, bounded vocabulary on purpose: a person, the chat agent, and the books all reason about an item the same way, and there is no free-text field where a typo or a hallucinated value could leak in.

2.1 What's carried on the item (seeded from the category, then its own)¶

Policy fact	The choices	What it governs
Accounting treatment	stock-tracked · expensed-on-receipt · expensed-on-write-off · capitalized-and-depreciated	The master decision — the whole "is it held in stock?" cluster (§3) lands here, and so does what receiving the item does (§4). The four values are simply when the cost hits the books: at consumption, at receipt, at write-off, or over time.
Tracking granularity	none · by lot · by serial	Whether stock is tracked in anonymous bulk, in dated batches (lots, for expiry), or as individually numbered units (serials). Only meaningful where something physically moves (§5.3).
Storage condition	ambient · chilled · frozen	The default condition used by shelf-life policy when stamping expiry for lots and produced prep items.
Recipe role	none · ingredient · producible · packaging	What the item may be inside a recipe — exactly one of: not recipe material at all; an atom ingredient line that never decomposes; a made thing with its own recipe; or a packaging row that travels out with the dish (§5).

That is the whole stored set: four settings. Notice what is not here. There is no stored "is it stocked?" flag — "is this item held in stock?" is a derived fact read off the accounting treatment (§2.2), not something stored and kept in sync by hand. And whether an item is edible or usable as food is not a stock policy at all — those belong to the food/nutrition side of the catalog and must never be consulted by a rule that moves stock.

Why the recipe role is one choice, not several switches. The roles are mutually exclusive by construction — an item is an atom, or a made thing, or packaging, or none of those, and can never be two at once. The reason isn't tidiness; each forbidden pair would break something real:

Ingredient + producible would give costing two contradictory instructions. When a recipe line points at an item, the system must know what to do: stop and price the item itself (an atom), or follow the item's own recipe (a made thing). An item can't be both a leaf and a branch of the same tree.
Ingredient + packaging (or producible + packaging) would break a money guarantee. Everything a packaging item costs lands in the packaging cost bucket, always — that's what keeps a dish's food-cost percentage honest (§5.2). An item that could appear as food in one place and packaging in another would turn that guarantee into a hope.

Because the role is a single choice, the guarantee "gloves and pans are never part of cost of goods" is structural — there is no combination of settings that could put them there.

"Seeded from the category, then its own." A category carries defaults for these facts. When you create an item under a category, those defaults are copied onto the item and from then on are the item's own values. Editing, renaming, or re-translating the category later does not reach back and change items already created — which is exactly what guarantees re-categorizing can never silently change an item's accounting.

The accounting treatment locks once there's history. As soon as an item has any stock or accounting history, its accounting treatment is frozen. You can't re-base how an item is treated half-way through its life: its past movements were valued under the old treatment, and flipping it would make the books contradict themselves. (This is the same immutability every mature accounting system enforces once transactions exist.)

2.2 The derived facts (computed, not stored)¶

These are plain yes/no facts computed from the policy above. They aren't stored — storing them would risk them drifting out of step with the truth they're derived from — but they are the convenient names everything else reasons in.

Derived fact	True when	Meaning
is-stocked	treatment is stock-tracked	Has a perpetual on-hand balance that movements deplete and a count reconciles.
is-an-implement	treatment is expensed-on-write-off	Holds an on-hand pool of durable smallwares: countable, transferable, wastable — never consumed into dishes, never depreciated (§4).
is-capitalized	treatment is capitalized-and-depreciated	Lives in the fixed-asset sub-ledger, not the stock ledger.
owns-a-recipe	a recipe exists that produces this item	A structural fact, read across the recipe relation.
is-a-prep-item	recipe role is producible and is-stocked	A prep item — formally, a semi-finished good: a stockable item you make from its own recipe (§6).

Notice there is no "can it be bought?" fact. Nothing gates buying: every item may be a line on a goods receipt — flour, salt, the combi oven alike. What varies is not whether you can receive an item but what receiving it does, and that routing is the accounting treatment's job (§3, §4).

"Perpetual inventory", by the way, is the textbook name for the idea behind is-stocked: the on-hand balance is kept continuously correct as each movement happens, rather than being figured out only at a month-end stock count. A stock-tracked item lives in that world; the other treatments don't.

2.3 The food attributes have no gate¶

Three capabilities are open to every item — no policy fact decides them, any item simply has them:

Carrying nutrition. Any item can hold a nutrition profile — including a resale item bought to sell as-is, like a bottle of Coca-Cola.
Declaring allergens. Any item can declare allergens, which then roll up the recipe tree to every dish that uses it.
Having a shelf-life. Any stocked perishable carries one — raw chicken included — though the automatic recalculation of shelf-life helps most for things you produce yourself.

The food attributes are taught in their own chapter; the point here is only that none of them is gated by a category or a "kind". Being part of a recipe is different: that is gated, by the recipe role (§5) — which is exactly what makes "cleaning supplies never reach cost of goods" a guarantee instead of a convention.

3. The is-stocked collapse — one question, many capabilities¶

Here is the biggest simplification in the model, and the one most worth internalizing.

A whole cluster of capabilities looks like separate questions but is really one question asked five ways:

Can I use this up ad-hoc (consume it directly in production or write it off)?
Can I record wastage of it?
Can I transfer it between warehouses?
Can I count it at a physical stock count?
Does it take part in the period close — the month-end reconciliation, the theoretical-vs-actual variance, the weighted-average-cost roll-up?

Every one of these collapses to the same underlying fact: does this item have a perpetual on-hand balance? — i.e. is-stocked. You can only use up, waste, transfer, count, or reconcile something that the system is actually holding a running quantity of. An item that was expensed the day it arrived has no on-hand balance to do any of those things to; a produce-to-order dish that's never held in stock has none either.

The capability	What it does	Comes down to
use-up / consume ad-hoc	draw stock straight into production or scrap	is-stocked
waste	record a wastage (stock leaves to scrap)	is-stocked or is-an-implement
transfer	move stock between your own warehouses	is-stocked or is-an-implement
count	assert an absolute quantity at a stock count	is-stocked or is-an-implement
reconcile at close	join the period close, variance, and cost roll-up	is-stocked

Why collapsing them matters. When these are five separate switches, they can disagree — an item marked countable but not wasteable, or one that's reconciled at close but not transferable. Disagreements like that are exactly how books go quietly wrong. Saying them as one fact makes it impossible for them to fall out of step: the answers come from the accounting treatment, never from per-capability switches. (Implements — §4 — are the one deliberate refinement: they hold an on-hand pool, so the physical-handling capabilities extend to them, while consumption and the food-cost reconciliation stay stocked-only.)

A capitalized asset is not an exception to any of this, though it can look like one. It does appear on a count and it does ride a transfer — but neither is the quantity gesture above. Its count row is a checkbox against a serial, asserting presence rather than an amount, and its transfer moves which warehouse's books carry the unit, not a quantity between two pools. Same documents, different verbs, because an identified unit and a kilogram of flour are different kinds of thing (see Fixed assets).

There's a subtle bonus. A prep item you make and then keep — say a batch of prepped dough — is held in stock, so is-stocked correctly includes it in counting and the close. A produce-to-order final dish, which is never held at all, is correctly excluded. One predicate gets both right without anyone special-casing "is this a product?".

Two close neighbors — buying and reordering. Two more capabilities look like they belong in this cluster, and the model answers each differently:

Can it appear on a goods receipt (can I buy it)? — anything you buy. There is no gate here at all: every item may be a line on a goods receipt, because everything in the building was bought at some point — the flour, the salt, the combi oven. What varies is what receiving the line does, and the item's accounting treatment routes it (§4): a stock-tracked line posts a stock movement, creates lots, and feeds the cost pool; an expensed-on-receipt line goes straight to expense; a capitalized line creates an asset-register entry — and no stock movement at all (§7).
Can it auto-reorder to a par level? → tied to is-stocked. You can't reorder-to-par something that has no on-hand balance to compare against the par. An expensed-on-receipt item is still orderable — but only by manually adding it to an order, never by automatic par logic.

Worked example. A warehouse holds flour (stock-tracked), salt (expensed-on-receipt), and a combi oven (capitalized). Ask the five stock questions of each: flour answers yes to all five (count it, waste it, transfer it, use it up, reconcile it). Salt answers no to all five — there's no on-hand balance to act on — yet salt is bought on goods receipts like anything else (each line routes straight to expense) and, carrying the ingredient role, is still a valid recipe ingredient. The oven answers no to all five too — and it is also bought through normal purchasing, ordered and received like the flour; what differs is what receiving it does: an asset-register entry in a different ledger, never a stock movement.

4. The four accounting treatments¶

The accounting treatment is the master decision. Its four values route an item into separate accounting worlds — and, at the receiving dock, they decide what a goods-receipt line for the item does.

Stock-tracked (perpetual inventory)¶

The item has a perpetual on-hand balance and a value, both derived from the record of stock movements — never kept as a single mutable number someone edits. Receiving it posts a stock movement, creates lots for by-lot items, and feeds the warehouse's cost pool. It is counted, valued at the warehouse's weighted-average cost (the blended average price of everything currently on hand — abbreviated WAC), and reconciled at the period close. This is the world of food raw materials, of stockable prep items, and — by default — of packaging. Everything in the is-stocked collapse (§3) applies.

Worked example. Flour is stock-tracked, tracked by lot, with the ingredient recipe role — and is-stocked by derivation (no separate flag). You receive 50 kg; you draw it down as dough is produced; you count it at month-end; the count reconciles against the on-hand the movement record derives. Its value blends into the warehouse's weighted-average cost.

Expensed-on-receipt¶

The item is not held in stock: it goes straight to expense the moment it's received — no on-hand balance, no count, no valuation, no variance. It is still something you buy — a perfectly ordinary goods-receipt line, whose receipt simply routes to expense — and, carrying the ingredient role, it can still be a recipe ingredient (§5). This is the world of oils, salt, and cleaning supplies: things consumed so steadily, or so cheap to track, that counting each gram would cost more than it's worth.

Worked example. Salt is expensed-on-receipt with the ingredient role. It's expensed on receipt and never counted — yet it is a genuine recipe ingredient. In a recipe it's costed at a reference price (its last purchase price, or a standard price), and it's excluded from physical counts and from actual-usage variance, contributing only to the theoretical side of the math. This is the load-bearing separation of the two axes: the recipe role says what an item may be in a recipe; the accounting treatment says how its money flows. Salt's role makes it an ingredient; salt's treatment makes its cost hit the books on receipt (§5.1).

Expensed-on-write-off (implements)¶

Between the consumables and the fixed assets sits a tier both of its neighbors fit badly: implements — the durable smallwares a kitchen runs on. Frying pans, knives, cutting boards, gastronorm trays, mixing bowls. They are not consumed (a pan doesn't deplete as you cook), so stock-tracking's consumption story is wrong. They are not worth a depreciation schedule (a €40 pan's monthly slice is ceremony), so the asset register is wrong too — and a drawer of forty pans would drown that register. But simply expensing them on receipt loses the thing an operator actually wants to know: how many pans do we own, where are they, and how fast do they die?

The implements treatment answers exactly that. Receiving implements posts a stock movement like any stocked item, so a per-warehouse pool accumulates quantity and value at cost — purchases pile in, nothing drains out through sales. An implement is never a recipe ingredient and never consumed by a dish (its recipe role is always none); its only ways out are a write-off (broken, lost, worn out — an ordinary wastage), a transfer to another warehouse, or a count shortage when the periodic count (commonly once a year) finds fewer pans than the book says. Each outflow is valued at the pool's average and recognized as implement write-off expense — its own bucket, never food cost, never shrinkage — so the cost of a pan hits the books on the day the pan dies, not the day it was bought and not smeared over the years in between. In one phrase: a fixed asset with zero depreciation, kept out of the asset register.

Implements are counted on the warehouse's ordinary walk, alongside the flour, and the count records whatever the walk saw. Nine pans against a book of ten is a write-off. Eleven pans against a book of ten is recorded just as faithfully — and then it waits: the surplus posts no overage, because the two extra pans get their cost from the receipt that bought them, not from the sheet that found them (§4.1).

Worked example. Twelve frying pans at €40 arrive: the implements pool gains 12 pans / €480; no expense yet. Two burn out in March and are written off: €80 of implement write-off expense, ten pans remain on the books. The next count finds nine — one short: another €40 writes off as a count shortage. Food cost never noticed any of it.

Capitalized-and-depreciated¶

The item is a durable asset routed to a separate fixed-asset sub-ledger (§7), entirely apart from the stock ledger: capitalized when acquired, depreciated straight-line over its useful life, disposed of with a gain or loss, and verified serial by serial on the count of the warehouse whose books carry it. It is bought through normal purchasing like anything else — ordered on a purchase order, received on a goods receipt — but the capitalize-treatment line creates an asset-register entry instead of a stock movement, and it participates in the order-vs-invoice match like any other line (a €4,500 oven invoice is precisely the one worth checking). This is the world of ovens, mixers, and other durable assets, and such items are always tracked by serial (an individual numbered unit you can point to) — the register holds one row per unit, so a "3 ovens" line has nowhere to live.

Two different "serials" — don't conflate them. For stock, the by-serial tracking granularity means each unit is a batch-of-one in the stock ledger's lot machinery — received, counted, and consumed like any lot. A capitalized item never enters the stock ledger, so that machinery never runs for it: each physical unit (this oven, that mixer) is one asset-register entry with its own code, serial number, cost, and depreciation clock, and the register entry — not a lot — is its identity for life. Rule of thumb: does it depreciate? → register row. Is it consumed? → stock, and tracking granularity decides whether you care about batches. (See Fixed assets.)

Worked example. A combi oven is capitalized-and-depreciated, tracked by serial. It is ordered and received like a sack of flour; what receiving it does is different: the receipt line creates an asset-register entry, not a stock movement. The oven never appears in an on-hand count or in any weighted-average cost pool; it depreciates month by month; and selling it later is an asset disposal (§7), not a stock movement out of inventory.

The four treatments, side by side¶

Everything the four subsections above teach, in one matrix:

	Stock-tracked	Expensed-on-receipt	Expensed-on-write-off	Capitalized-and-depreciated
The idea	held, counted, consumed gradually	too cheap to track — cost it the day it arrives	durable smallwares — serve until they die	a durable asset that wears down over years
Typical items	flour, milk, meat, wine, prep items, cups	napkins, gloves, cleaning supplies, oil, salt	pans, knives, trays, cutting boards	oven, mixer, fridge
What receiving does	a stock movement: supplier → warehouse	no movement — the line's cost goes straight to expense	a stock movement into the implements pool	no movement — creates an asset-register entry
On-hand exists?	yes — a live quantity per warehouse	never	yes — quantity and value accumulate by purchases	never (it is not stock at all)
How it is counted	quantity rows on the warehouse's count, as many sightings as the walk produced; rows may be added freely	excluded from counts entirely	quantity rows, offered from the book; rows may be added	one row per serial, a checkbox, in its own section — offered from the register, no rows may be added
May the count find more than the book?	yes — the surplus posts as an overage at the pool's average	—	yes — but the surplus posts nothing; it is put right by the priced receipt that was never entered	not applicable — the register is the roster
What verification produces	overage or shortage; variance explained at the close	nothing	shortage → implement write-off expense; surplus → a transfer or a receipt owed	a confirmed serial, or a close blocker resolved by finding it or disposing it
When the cost hits the P&L	when consumed (sold dish, waste) — cost of goods at the warehouse's blended average	on the receipt date, in full	at write-off — the day it breaks, is lost, or wears out	in monthly slices over the useful life (straight-line depreciation)
Where the cost lands	food cost / packaging cost (COGS)	expense-on-receipt expense (recipe ingredients also cost into dishes at reference price)	implement write-off expense — never food cost, never shrinkage	depreciation expense
Valuation	the warehouse's cost pool, blended average	none — expensed and done	its own pool, blended average — never depreciated	book value = capitalized cost − accumulated depreciation
Unit identity	optional, via tracking granularity (lots / serials)	none	rarely needed (the pool is quantities)	always — one register row per physical unit, with its serial
How it leaves the books	consumption, waste, count shortage	already gone at receipt	write-off, transfer out, count shortage — never a sale or a recipe	disposal (sale or retirement), with a gain or loss

And the same five life events, told four ways — the clearest way to feel the difference:

Event	Stock item (flour)	Expensed item (napkins)	Implement (frying pan)	Asset (oven)
Receive €100 worth	+€100 of stock; you owe €100	€100 expense; you owe €100	+€100 in the implements pool; you owe €100	€100 asset on the register; you owe €100
Use it	a movement out; cost of goods at the current average	nothing — already expensed	nothing — cooking with a pan is not an event	nothing — usage is not an event
A month passes	nothing automatic	nothing	nothing	one depreciation slice posts (e.g. €1.67 on a 60-month life)
Count / check	counted; any gap posts as overage or shortage	not counted	counted; a shortfall = the dead and the lost, written off; a surplus = a receipt never entered	its serial ticked on the same walk: found, or gone
Get rid of it	a waste or sale movement at average cost	— (nothing held to get rid of)	write-off at pool average → implement expense	disposal: proceeds − book value = gain or loss

One line to remember it all by: stock answers "how much do I have, and what did consuming it cost?"; expensed-on-receipt deliberately answers nothing; implements answer "how many do we own and how fast do they die?"; the asset register answers "which unit is this, and how much of its cost is still unrecognized?"

4.1 Why a found implement is recorded but not valued¶

Three of the four treatments appear on a warehouse's count, and not one of them argues with the counter about what is really there. Where they part company is what the books then do about a surplus — and that difference looks arbitrary until you follow the money one step further than the count.

A sack of flour nobody recorded is an ordinary find. It enters as an overage at the pool's running average — the price of flour that was, in all likelihood, genuinely paid for and merely mis-journaled — and if the pool happens to be empty it enters at zero value, gaining quantity and no money at all. Either way, no value is created out of nothing, and the row is settled.

Now try the same move one tier up. Let a frying pan the book never knew about join the implements pool at no cost, and it leaves the books the way its tier leaves the books: as an implement write-off expense the day it breaks. Let a serial appear on the register at no cost, and it leaves as a loss on disposal the day it is retired. Follow either chain and you have manufactured a deductible expense with no purchase behind it:

value on the books at zero cost  →  write-off / disposal  →  expense
     ↑                                                         ↓
nothing was ever bought                    the books claim a cost

That shape has a name in every tax authority's playbook, and no honest system should offer it as a convenience. But the answer is not to argue with the storekeeper. The eight pans the walk found are a fact, and a document that refuses to hold facts only teaches people to write down what the book wants instead of what they see — which costs far more than it saves. So the observation is free and the valuation is guarded: an implement surplus is recorded, posts nothing, and stays an open reconciliation row until the thing that was really missing turns up — the priced goods receipt for that delivery. Entering it lifts the book to eight and gives the two extra pans their cost in one gesture; a transfer from another warehouse does the same job when the pans came from down the road. The count's job is to say what is there, and the correction's job is to say what it cost.

Fixed assets need no such split, because there is nothing for the walk to record: the register is the roster of identified units, so an asset the books have never heard of has no row to be ticked. It enters by explicit registration, stating what it cost and when it went into service, and shows up on the next walk by itself.

(One case stands apart, and it proves the rule: an opening count asserts the very boundary where a warehouse's books begin, so every pool is empty by definition and everything — implements included — opens by assertion at the operator's stated costs. See Period close.)

5. The recipe role — what an item may be inside a recipe¶

The recipe role is the second axis of the model, and it answers a different question than the accounting treatment. The treatment asks how does this item's money flow? The role asks what may this item be inside a recipe? Keeping the two axes independent is what lets oil be expensed on receipt and still cost into every dish that fries in it.

5.1 The four roles¶

None — not recipe material. Gloves, towels, a combi oven, a resale bottle of Coke. The item can be bought, held (if stocked), sold directly (if stocked) — but it can never be picked onto a recipe, which is precisely what guarantees it never reaches cost of goods through the kitchen.
Ingredient — the atom. The item may sit on a recipe as a line that never decomposes: when costing meets it, it stops and prices the item itself — at the warehouse's weighted-average cost if it's stocked, at its reference price (last purchase or a set standard) if it's expensed on receipt. Flour, salt, oil, raw chicken. An atom must be stock-tracked or expensed-on-receipt — implements and capitalized assets can never be atoms, because neither has a consumable cost a recipe could absorb.
Producible — the made thing. The item may own a recipe of its own, may be the output of a production run, and may sit on another recipe as a line. What happens when costing meets it depends on whether it's stocked — the two cases are different enough to deserve their own section (§6).
Packaging — rides out with the dish. The item may sit on a recipe's packaging rows — the cup, the lid, the clamshell that leave with the food. Its cost always lands in the packaging cost bucket, never food cost (§5.2). By default packaging is stock-tracked — cups are real countable stock that depletes as dishes sell — though an operator can expense a negligible wrapper.

An item carries exactly one role. The pairs you might expect to combine are deliberately impossible — an atom that decomposes, food that is also packaging — because each would make costing ambiguous or break the food-vs-packaging split (§2.1). One borderline case is worth naming: packaging an operator produces in-house (assembling branded boxes from cardboard and stickers). The model keeps this out — packaging is something you buy — and if a real operation ever needs it, it arrives as its own explicit role, not by stacking two roles together.

The role is freely chosen — and freely changed — until the item is actually in use: the moment it owns a recipe or sits on an ingredient or packaging line, the role freezes, the same way the accounting treatment freezes once the item has history (§2.1). Changing what an item is inside recipes would strand the lines already built on it. The same wiring freezes the item's base unit: every quantity on those recipe lines was proven against that base when the recipe was saved, and re-dimensioning the item afterwards would silently mis-scale costing, yields, and nutrition at once.

5.2 Why packaging is a role, not a treatment¶

A package is two things at once, and neither follows from the other facts:

Recipe-attachable — it travels out the door with the dish, so it must be placeable on that dish's recipe (as a packaging row, not an ingredient line); and
A separate cost bucket — its cost must roll up as packaging cost, kept apart from food cost, so a dish's food-cost percentage isn't polluted by the price of the box it ships in.

Worked example. A kraft clamshell is stock-tracked with the packaging role: received and counted like flour, depleted as dishes sell. On a dish's recipe it sits as a packaging row, and its cost rolls into the dish's packaging cost, not its food cost. So a €3.20 dish made of €2.40 food + €0.80 packaging reports a food-cost basis of €2.40, not €3.20 — the food-cost percentage stays honest.

5.3 How the three axes combine¶

The role, the treatment, and the tracking granularity are three independent settings — but not every combination means something, and a few are forbidden outright. The whole picture:

 role ↓ · treatment →   │ stock-tracked        │ expensed-on-receipt   │ write-off (implements) │ capitalized (assets)
────────────────────────┼──────────────────────┼───────────────────────┼────────────────────────┼─────────────────────
 none                   │ resale goods (Coke)  │ gloves, towels        │ pans, knives, trays    │ oven, mixer, fridge
 ingredient (atom)      │ flour, meat, milk    │ oil, salt             │ ✗ forbidden            │ ✗ forbidden
 producible (made thing)│ PREP ITEM — made,    │ decomposing           │ ✗ never recipe         │ ✗ never recipe
                        │ held, pool-priced    │ intermediate (§6)     │   material             │   material
 packaging              │ cups, clamshells     │ negligible wrappers,  │ ✗                      │ ✗
                        │ (the default)        │ costed at reference   │                        │

The rules the matrix encodes:

The two right-hand columns always carry role none. Implements are never recipe material (a pan is not consumed by a dish), and a fixed asset can be neither food nor packaging. The forbidden cells aren't conventions — recipes refuse such items outright.
The ingredient role lives only in the two left columns, because an atom must have a consumable cost: a pool average (stocked) or a reference price (expensed).
Every cell in the two left columns is real. Even the quiet ones: a stock-tracked item with role none is a resale good — counted and valued, sold as-is, never inside a recipe; an expensed item with role none is a pure consumable, the gloves-and-towels case whose cost can never touch a dish.
Tracking only matters where something physically moves. Lots and serials live on stock movements and the asset register: by lot gives a stocked item dated batches (expiry, first-expired-first-out issue); by serial makes each stocked unit a batch of one; capitalized items are always by serial (one register row per unit); and for expensed-on-receipt items tracking is inert — there are no movements to pin a lot to.

Read column-by-column and the matrix collapses into four one-liners: stocked items take any role; expensed items take any role but pay at the door; implements and assets take none.

6. The producible role — prep items and decomposing intermediates¶

A producible item is one you make. Whether you also keep it decides which of two quite different things it is — same role, two behaviors, told apart by is-stocked.

6.1 A prep item is a derived fact, not a "kind"¶

A prep item is an item that you produce from its own recipe and then hold in stock — "Peeled Carrots", a base sauce, commissary dough. It is not a stored category or "kind". It is simply the derived fact role producible and is-stocked (and, structurally, it owns a recipe).

The stored input is the producible role — the candidate filter that surfaces an item as something you could attach a recipe to (you make dough, not raw flour). Crucially, "producible" is not the same as "owns a recipe": being a candidate to receive a recipe is different from actually having one. An item can be marked producible long before anyone writes its recipe.

A prep item is where dish costing stops: a batch was produced, its cost went into the warehouse's pool, and a dish that uses it consumes the prep item at the pool's blended average. The dish does not re-derive back down to whole carrots, because the peeled carrots were already made and costed when they were produced.

And "final dish-ness" lives nowhere on the item at all. A final dish — produced to order, never held in stock — lives in the recipe/menu layer, has no on-hand balance, and is therefore simply not is-stocked. This cleanly separates the two: a stockable prep item (held, counted) and a produce-to-order final dish (never held) are told apart by is-stocked, not by lumping them under one "product" label.

Worked example. Peeled Carrots is stock-tracked and producible, so it derives as a prep item: you make a batch from its recipe (whole carrots in, peeled carrots out), and the batch is held in stock and counted. Peeling 124 g of whole carrot yields 100 g peeled — an 81% yield — and that yield is an emergent fact of the recipe (output ÷ inputs), not a number anyone types in. A dish that uses peeled carrots simply consumes the prep item directly. (See Recipes & production.)

6.2 The decomposing intermediate — producible but never held¶

Mark an item producible but give it the expensed-on-receipt treatment and you get the other behavior: a named sub-recipe that is never physically made ahead. It can never be a production run's output (production only yields stocked items) and it never has an on-hand balance. It exists purely as recipe structure: when a dish uses it, costing and consumption pass through it to its components, as if the dish had listed them directly.

Worked example. A house spice mix is producible and expensed-on-receipt, with its own recipe: paprika 5 g + cumin 3 g + salt 2 g per 10 g of mix. Nobody ever blends a jar ahead of time. A dish lists "spice mix, 10 g" as one tidy line — but when that dish sells, the ledger sees paprika, cumin, and salt leaving stock, never "mix":
dish line: spice mix 10 g        ← one named line on the recipe
           └─ decomposes →  paprika 5 g + cumin 3 g + salt 2 g
cost = the components' own costs (their pools / reference prices)
on-hand of "spice mix": never exists — there is nothing to count
Compare the prep item: if the kitchen did blend jars ahead each morning, the mix would instead be stock-tracked + producible — a prep item with a pool, made by production runs, counted like any other stock, and consumed at its blended average. Same recipe either way; is-stocked decides whether the explosion stops at the jar or passes through it.

The pair of cases is the whole story of the producible role: stocked producible = make it, hold it, count it, price from its pool; non-stocked producible = a named shorthand that dissolves into its components. Which one a given prep deserves is an operational choice — does anyone actually make batches ahead? — not an accounting one.

7. Capitalized assets — the fixed-asset branch¶

The capitalized-and-depreciated treatment is the doorway into a separate fixed-asset sub-ledger, kept entirely apart from the stock ledger (the same separation every mature accounting system draws between stock and property/plant/ equipment). A capitalized item is:

Bought through normal purchasing — ordered on a purchase order and received on a goods receipt like anything else; the receipt line creates the asset-register entry (no stock movement) and takes part in the order-vs-invoice match like any other line.
Capitalized on acquisition — recorded as an asset at the full cost to put it into service, always tracked by serial: one register row per physical unit.
Depreciated straight-line — its value written down evenly over its useful life by a monthly depreciation run.
Disposed with a gain or loss — when retired or sold, the asset leaves the register and any difference from its remaining book value lands as a gain or loss.
Placed on one warehouse's books, and verified by that warehouse's count — registering a unit records that the company owns it; placing it names the warehouse whose period close answers for it, and from then on its serial is ticked off on that warehouse's ordinary walk. Until it is placed, no walk lists it and it does not depreciate. Fixed assets end up verified yearly not because they have a private ritual, but because a warehouse holding only assets sensibly closes once a year.

This matters for the item model because a durable tool must not be smuggled into the stock ledger as if it were a perishable. An oven is not "used up" gram by gram; it wears down over years. Giving it the capitalized treatment routes it to the right accounting world. A durable-but-immaterial tool — a pan, a knife — takes the expensed-on-write-off implements treatment instead (§4); a cheap, short-lived supply that isn't even worth counting is simply expensed-on-receipt.

The fixed-asset world here is deliberately slim: the register, straight-line depreciation, disposal with a gain or loss, and the serial confirmation on the warehouse's count — nothing more. Jurisdiction-grade depreciation machinery (accelerated methods, book-vs-tax schedules) is the external accountant's territory: it lives in the operator's accounting system, and the boundary export carries the figures it needs. (Full detail in Fixed assets; where the depreciation expense and the disposal gain or loss land is in Financial boundary.)

Worked example. A stand mixer is capitalized-and-depreciated, by serial. It is ordered on a purchase order and received on a goods receipt like a sack of flour — but the receipt line creates an asset-register entry and a straight-line depreciation schedule, not a stock movement. Each month it depreciates a little. It never shows up in a count or a cost pool. Two years on it's sold second-hand: that's an asset disposal with a gain or loss against its remaining book value — never a stock movement out of inventory.

8. What a category is allowed to do¶

So if a category never decides behavior, what is it for? Three legitimate jobs:

A human-facing label for grouping, filtering, and sorting. Read it freely to show things; never branch behavior on it.
A code prefix for item codes — items in the packaging category get codes like PKG-00001, PKG-00002. That prefix is identity and display, not behavior. (A package behaves like packaging because its recipe role is packaging, not because its code starts with those letters.)
The policy defaults — the values copied onto a new item when it's created under the category: the accounting treatment, the tracking granularity, the storage condition, and the recipe role.

Because that's the whole list, adding or renaming a category is a data operation — it changes how things are grouped and what a future item will inherit, and nothing else. No behavior shifts for any item that already exists.

Worked example. An operator creates a new "Compostable packaging" category and sets its defaults to stock-tracked, tracking none, storage ambient, recipe role packaging. Every item they file under it is born counted and packaging-roled — ready to ride on recipes and roll into packaging cost — with no further setup. Renaming that category next week changes nothing about those items' behavior; they already carry their own copies of the policy.

9. The worked items, side by side¶

A summary of the items used through this chapter. "Is it held in stock?" is the derived is-stocked fact and shows up under behaves as, never as a stored fact. Every one of these items can be a goods-receipt line; the behaves as column includes what receiving it does.

Item	Accounting treatment	Tracking	Recipe role	Behaves as
Flour	stock-tracked	by lot	ingredient	is-stocked — receiving posts a stock movement and creates lots; counted, valued (WAC), reconciled; an atom on recipes at the pool's average
Peeled Carrots	stock-tracked	none	producible	prep item (producible ∧ is-stocked) — made from its own recipe, held & counted; dishes consume it at the pool's average
House spice mix	expensed-on-receipt	none	producible	decomposing intermediate — a named sub-recipe with no on-hand; dishes that use it consume its components directly
Salt	expensed-on-receipt	none	ingredient	not stocked: receiving routes straight to expense; an atom on recipes at a reference price, never counted
Kraft clamshell	stock-tracked	none	packaging	is-stocked — counted like flour, depleted as dishes sell; rides recipes as a packaging row; cost lands in packaging cost, never food cost
Nitrile gloves	expensed-on-receipt	none	none	pure consumable — expensed at the door, never on a recipe: structurally unable to reach cost of goods
Frying pan	expensed-on-write-off	none	none	is-an-implement — receiving fills the implements pool; never a recipe/sale target; counted and transferable, a shortfall written off and a surplus left for a receipt to price; write-off at death → implement expense, never food cost
Combi oven	capitalized-and-depreciated	by serial	none	is-capitalized — ordered and received like anything else, but receiving creates an asset-register entry on the line's warehouse (no stock movement); its serial is ticked on that warehouse's count; never valued or sold as stock
Coca-Cola (resale)	stock-tracked	none	none	is-stocked — counted & valued; sold as-is, never inside a recipe; can carry nutrition + allergens

The pattern to take away: every row's behavior reads straight off its policy facts, and not one reads off the category it happens to be filed under.