Locations

A virtual location is a place stock notionally sits when it is not at a physical site we operate. A custody or condition stock type is a state stock is in at a real location. Both describe stock that is ours and countable; only one of them answers "where would you go to look for it".

A new concept becomes a location only when all three hold:
a. a party outside i3 is accountable for loss while the stock is there;
b. a physical count at any site we operate cannot find it;
c. no single one of our locations can be held accountable for chasing it.

Otherwise it is a stock type at the location that is accountable. When in doubt, make it a stock type. A stock type is one more column in this matrix. A location is a count policy, an alias set, a permitted-type row per stock type, a roll-up rule, an opening-balance signature and a foreign key that all fourteen other modules post against.

Worked verdicts. IN_PRODUCTION and GIT_INBOUND fail test (c): HQ_319 chases the PO milestone and the DHL shipment, so they are stock types held at HQ_319, not locations. i2 modelled them as locations and the v2 mockup showed IN_PRODUCTION as a row with 47 SKUs and AED 890K, which makes the same unit countable twice. SUPPLIER_HOLD passes all three: it may be credited and never return, and no warehouse owns it. TRANSIT passes all three: the origin has released it and the destination has not received it.

Customer shipments stay at the dispatching site. IN_TRANSIT_CUSTOMER fails (c) because the dispatching site owns the NDR and RTO chase, so it posts at HQ_319 or the store, never at TRANSIT and never at the customer.

Four different canonical location lists exist across the estate today and none of them reconcile.

The i2 seed carries HQ, ZAH, JIMI, ARAMEX with Shopify ids verified against the admin API on 19-04-2026. The i2 PRD lists HQ_319, CCZ, AJM and five consignment partners. The v2 mockups add ONL and RTL, label HQ_319 as BOM-319, and in one row link to ?code=AJM while rendering the label JIMI.

i3 keeps one register and one alias table. Every historical spelling resolves; nothing is renamed in place; nothing is guessed. Without the alias table the i2 replay of 587K ledger rows cannot map its HQ rows onto HQ_319 at all.

Two register facts that no v2 page shows: 3PL_ARAMEX is bound to a live Shopify location and appears in no dashboard anywhere, and RTL was a balance-bearing row in v2, which would have double counted the whole retail estate. In i3 roll-ups are derived, never stored.