Inventory

You are setting stock policy: how much to hold, when to reorder, how much to reorder. You are not buying it (that is procurement) and not moving it (that is logistics-ops). You decide the numbers that tell the buyer what to order and when.

Leave behind two checkable artifacts every time:

1. Reorder-policy table — one row per SKU: sku, abc_class, avg_demand, lead_time, safety_stock, reorder_point, order_qty, review_mode. This is the standing policy.
2. Replenishment trigger list — the subset of SKUs whose on_hand <= reorder_point right now, with a suggested order quantity. This is the action.

scripts/verify.sh checks both for shape and the structural invariants (ROP ≥ safety stock, order_qty > 0, no false triggers). Run it before you hand anything off. It validates structure, not whether the buffers are commercially smart — that judgment is yours.

Pick the job

The flow genuinely branches. Find the row that matches the ask before doing anything else.

Ask sounds like	Job	You produce
"which SKUs deserve tight control", "run ABC"	Classify	ABC×XYZ class per SKU → the abc_class column + a policy posture per class
"how much safety stock", "we keep running out / sitting on dead stock"	Size the buffer	safety_stock per SKU, chosen Z, chosen formula
"what's my reorder point", "set up min/max", "weekly or continuous"	Set policy	reorder_point, order_qty, review_mode → the full policy table
"is our stock policy working", "turnover", "cut dead stock"	Track	KPI panel against the business's own history + cycle-count cadence

Classify before you size, size before you set policy. A uniform policy across every SKU is the original sin (anti-patterns table).

Classify first: ABC × XYZ

Rule: never apply one uniform service level or review mode to every SKU — control is a budget, spend it where the value and the volatility are. Bad: 95% service on all 800 SKUs. Good: 99% on the high-value/stable AX items, make-to-order or near-zero buffer on the low-value/erratic CZ items.

• ABC = Pareto split by annual consumption value (annual_demand × unit_cost), sorted descending and cumulated. A ≈ top ~80% of value (usually ~20% of SKUs), B the next band, C the long low-value tail.
• XYZ = split by demand variability via coefficient of variation CV = σ_demand / mean_demand. X = stable (low CV), Y = fluctuating, Z = erratic.

The 9-cell matrix maps to policy: AX → tight automated min/max, highest service; CZ → manual, minimal buffer or make-to-order; AZ → high value but erratic, the candidate for DDMRP (below). Full cumulative-value worked sort, CV cut points, and the 9-cell→(review mode, service level, buffer posture) matrix are in references/abc-xyz.md.

Safety stock

Rule: match the formula to which thing actually varies. Picking the demand-only formula when the supplier's lead time swings is the most common under-buffering mistake — you buffer the wrong variance and still stock out.

demand varies, lead time stable:     SS = Z · σ_demand · √LT
both vary, independent:              SS = Z · √(LT · σ_demand² + avg_demand² · σ_LT²)
both vary, correlated (King):        SS = Z · σ_demand · √LT + Z · avg_demand · σ_LT

Z is set by your target service level, never picked by feel:

Service level	Z
90%	1.28
95%	1.65
97.5%	1.96
99%	2.33

Higher service costs disproportionately more buffer — the tail is fat, so each extra point past ~98% buys a chunk of cash you reserve for A/critical items and deny to C items. Bad→Good: supplier "usually 5 days but sometimes 12" + you used Z·σ_demand·√LT → switch to the independent or King formula so σ_LT is in the buffer. How to estimate σ_demand and σ_LT from sales/receipt history, all three formulas worked with numbers, and the diminishing-returns curve are in references/safety-stock.md.

Reorder point and order quantity

These are two separate decisions — conflating them is the classic beginner error. ROP answers when, order quantity answers how much.

ROP = (avg daily demand × lead-time days) + safety_stock        ← when to trigger
EOQ = √(2 · D · S / H)                                          ← how much to order
        D = annual demand, S = cost per order, H = annual holding cost per unit

EOQ minimizes ordering + holding cost under stable demand. It is an order-size lever and never a trigger — you do not "wait until you can order an EOQ." Keep reorder_point and order_qty as separate columns.

Continuous vs periodic review is a real branch:

Mode	How it works	Use when	Cost
Continuous (min-max / s,S)	Order the moment on-hand hits ROP s, bring up to S	A items, perpetual stock visibility	Fastest reaction, needs live counts
Periodic	Check on a fixed cadence (e.g. every Friday), order up to target	B/C items, batched POs, no live system	Needs a bigger buffer to cover the extra review-interval exposure

Periodic review adds Z · σ_demand · √(review_interval) of exposure on top of lead-time exposure — budget for it. Worked ROP/EOQ examples, the review-interval buffer adjustment, and the exact policy-table + trigger-list schemas (the columns verify.sh checks) are in references/reorder-policies.md.

Demand-driven option (DDMRP)

When a static ROP keeps whipsawing on erratic demand — you re-tune it monthly and it is still wrong — switch that SKU to buffer zones instead of a fixed point.

• Red = safety/critical, sized off lead-time and demand variability.
• Yellow = demand coverage over the lead time.
• Green = order cycle / order frequency.

Trigger fires when net flow position = on_hand + on_order − qualified_demand drops from green into yellow. The zones recalculate as demand ramps, so you are not hand-editing safety stock every cycle.

Decision rule: reach for DDMRP only on erratic (Z-class), long-lead, or strategic SKUs — never for steady C items where a flat ROP is cheaper to run. Zone sizing and the net-flow trigger are in references/ddmrp.md. Set review_mode = ddmrp for these SKUs.

Track it

Prove the policy works with a KPI panel — and recompute every metric against the business's own history; the benchmarks below are sanity rails to flag against, not numbers to hallucinate or paste as targets.

KPI	Formula	Rough rail
Inventory turnover	COGS / avg inventory	≈6–8×/yr (consumer goods)
Days of inventory on hand	avg inventory / COGS × 365	≈30–60 days
GMROI	gross margin / avg inventory cost	target > 2.5
Sell-through	units sold / units received	≈70–85% / mo
Stockout rate	stockout events / order lines	target < 5%
Fill rate	lines filled complete / total lines	target > 95%
Dead-stock flag	SKUs with zero movement over a defined window	flag, don't reorder

Cycle counting, not an annual full count. Count in a rolling sequence frequency-tiered off ABC: A items often (monthly/quarterly), C items rarely (annually). The warehouse never stops, and errors on high-value items surface fastest.

Anti-patterns

Anti-pattern	Why it bites	Do instead
One uniform service level / review mode across all SKUs	Overspends on C, under-protects A	ABC×XYZ → differentiated Z and review mode
Demand-only SS when lead time is volatile	Buffers the wrong variance, still stocks out	Independent or King formula so σ_LT is in the buffer
Treating ROP and order quantity as one number	"Wait to order a full batch" → late triggers	Separate reorder_point (when) and order_qty (how much) columns
Using EOQ as a reorder trigger	EOQ is a size lever, not a signal	Trigger on ROP; size with EOQ
Picking Z by feel	Service level is undefined and indefensible	Set service level → read Z from the table
Static safety stock on erratic demand	Re-tuned monthly and still wrong	DDMRP buffer zones, review_mode = ddmrp
Annual full physical count	Warehouse stops; high-value errors found too late	ABC-tiered rolling cycle counts
Placing/negotiating the PO here	Wrong skill owns the buy	Hand the trigger list to procurement

Hand-offs

• Raising/negotiating the purchase order, supplier choice, payment terms, PO approval, three-way match → procurement (see ../procurement/SKILL.md). You hand it the trigger list; it executes the buy.
• Warehousing, picking, packing, shipping, carriers, returns flow → logistics-ops. You set the on-hand target; it physically fulfills.
• Statistical/ML demand forecast, seasonality decomposition → forecasting. You consume a demand estimate and its variability; you do not own the model.
• Live KPI dashboard → dashboard. Recurring KPI report → reporting.
• Pivot tables, ABC cumulative-value sort mechanics in a sheet → spreadsheet-ops.