properties /availability

The quantitative on-hand stock of the product, as a count of the priced atom in a PURE COUNTING UNIT (a numeral on the QuantityUnits dimension — each/piece, discrete item count only). The count NEVER carries a pack/sale unit: pair/dozen/set/case/carton are content-defined derived reads of the `contains` relation (b81), never stored on a raw count — this is D1-Delta2 (the sale-unit word is a read of contains, can never contradict the count; a stored '12 dozen' with no contains would read 'each' on the shelf and self-contradict, so it is now unsayable). A product carries many inventory quantities (cardinality many): each named state is a distinct statement, self-correlating its count with its quantity_state qualifier (available 47, committed 12, incoming 100). A carton-sold product is a carton VERSION whose contains(base, N) states the pack; its stock is counted in each (each = one carton) and 'how many base pieces' derives (count x N), or when the base is separately stocked the carton's availability derives from the base (min over parts, b81) — the pool re-states neither the pack count nor the sale-unit word. The pool declares the bundle's grammar — that stock can be reported as a count by named state in a counting unit; the realised magnitudes are the data layer's offer/instance rows (L1), exactly as list_price's realised amount is downstream. Distinct from availability_status (the single buyable-state token in-stock/out-of-stock that this count sits behind). The 'only N left' urgency, low-stock bar, and 'selling fast' badge a surface prints are PRESENTATION over these counts (A10), never stored.