inventory — a sub-ledger whose COGS is derived

Cost lots held as state, the cost of a shipment derived from those lots by the item's costing method, and no custody of anything.

A general ledger takes the amount from its caller, so it cannot tell a correctly costed shipment from a flattering one. This realm never takes an amount: Ship takes a quantity and returns the cost it derived. That is the whole product, and it proves arithmetic — not truth. Nothing here ties a cost figure to a real holding.

State

registers opened: 0
chain height: 810298

The chart is three accounts and is fixed

code	name	kind	normal
`1300`	Inventory	asset	debit
`5000`	Cost of goods sold	expense	debit
`3900`	Inventory contributed	equity	credit

A receipt is debit 1300 / credit 3900. A shipment is debit 5000 / credit 1300 for the derived cost. There is no way to open a fourth account.

3900 is a plug. A debit to inventory needs a credit leg, and every candidate asserts something this realm cannot observe — a payable it would never relieve, a cash balance it does not hold, or a contribution. The contribution was chosen because it is the only one that stays coherent with no follow-up event, not because it is true. A register whose goods were bought on credit understates liabilities by exactly this balance.

Costing methods

entrypoint	method	lots held
`AddFIFO`	fifo	one per live receipt
`AddLIFO`	lifo	one per live receipt
`AddWAVG`	weighted-average	always exactly one

Fixed at creation. Changing an item's method mid-life would recost nothing already charged but would change what the next shipment costs, which is a restatement a sub-ledger must not be able to make silently.

"Always exactly one" does not mean unconstrained. A weighted-average item escapes the live-lot bound and gains a refusal the other two never evaluate: merging a receipt into the single lot can breach that lot's own overflow precondition, and whether it does depends on the item's accumulated history rather than on the receipt. So LotCapacity is the wrong headroom figure for a weighted-average item — it reports the one limit that cannot bind there.

Bounds

bound	value
items per register	64
live lots per item	64
entries per register	8192
sku length	32
name length	64

The entry bound is register-wide and shared, not per item, and that is the one bound here with a blast radius wider than the thing it limits. Every costed receipt and every costed shipment of every SKU spends one entry out of the same 8192, and entries are never freed — exhausted lots are dropped, postings are not. So a single high-turnover SKU can spend the whole budget and leave the other 63 items unable to receive or ship, each with capacity of its own to spare. There is deliberately no archive and no reset — either would destroy the record the cross-foots are checked against — so the remedy is a second register under a second address, and busy SKUs are worth separating before they are busy. Watch Capacity's second figure, which counts down for the register and not for one item.

A SKU may use only letters, digits, ., _ and -: it is an index key, a page path and a table cell at once, and a charset checked on the way in beats escaping at three use sites. Case is significant.

There is no write-off: goods cannot leave without being charged to 5000, so shrinkage is indistinguishable from a sale. A real limitation, named rather than hidden.

Reading a register

/r/g1ut6uspuh73e02yauxpmyt8g3wwddaq8utagvm3/inventory:<address>

/r/g1ut6uspuh73e02yauxpmyt8g3wwddaq8utagvm3/inventory:<address>/<sku>