Live Inventory

Every number here is a projection over ledger_entries. Nothing on this page can change one.

Three checks run on every write: qty = SUM(quantity_delta), qty = last balance_after, and entry_count > 0. A key that fails any of them renders as a chain-mismatch cell and drops out of every total. That is the check i2 never had, which is how its sellable reached minus 140,753.

A fourth identity comes from module 03 and is adopted here verbatim rather than restated: balance(composite_sku, any_location, any_stock_type) = 0, always. It is structural, not aspirational: the projection joins skus.is_composite = FALSE, the cache carries a CHECK, and a nightly assertion raises P1 on breach. What a derived row shows instead is min over components of floor(available / component_qty), excluded from every footer sum because its components are already counted.

Recipe versions are pinned per sale. The derived numbers above use the active recipe, because that is what a new sale would decompose with. Every backward-looking trace and every reversal replays the recipe_id stamped on the original recipe_transform rows. A view that mixes the two disagrees with the ledger for any SKU whose recipe was edited, and the disagreement looks exactly like stock drift.

IN_PRODUCTION and GIT_INBOUND are stock types held against the destination location, never locations. The virtual location set is exactly three: TRANSIT, SUPPLIER_HOLD, DISCONTINUED.