# TANRAIL ONE — Phase 3.2 Inventory Architecture

## 1. What is Inventory Responsible For?
The Inventory Core is responsible for tracking the physical presence, movement, and reservation of items across physical or logical locations within the enterprise.
- Tracking exact current quantities (Balance).
- Providing an immutable, auditable ledger of how stock arrived or left (Movements).
- Facilitating the movement of stock between internal locations (Transfers).
- Correcting discrepancies between system quantities and physical reality (Adjustments).

## 2. What is Inventory NOT Responsible For?
- **Production / Recipes (Bill of Materials):** The concept of combining 3 Ingredients to make 1 Finished Product belongs to a Reusable Production Module, not Core Inventory. Core Inventory only cares that 3 units were ISSUED and 1 unit was RECEIVED.
- **Selling or Pricing:** Inventory does not know how much an item costs to the customer. That is the Sales/Catalog domain.
- **Business Specifics:** Inventory has no concept of a "Kitchen", "Table", "Passenger", or "Water Bottle". 

## 3. Core Entities
The following entities belong strictly to the Inventory Core:
- `InventoryLocation`
- `StockBalance`
- `StockMovement`
- `StockTransfer`

Entities belonging OUTSIDE Inventory:
- `Item` (Belongs to Core Catalog)
- `Supplier` (Belongs to Core Identity/Procurement)
- `Branch` (Belongs to Core Business Units)

## 4. Architectural Boundaries and Interactions

- **Item Catalog:** Inventory maps its balances strictly to `Item` IDs. It relies on the Catalog for naming, typing, and the Base Unit of measure.
- **Business Unit & Branch:** Inventory Locations are physically mapped to a `Branch`. Because a Branch belongs to a Business Unit, all inventory is strictly structurally isolated to a Business Unit.
- **Sales:** The Sales module interacts with Inventory by requesting an `ISSUE` movement when an order is completed.
- **Procurement:** The Procurement module interacts with Inventory by requesting a `RECEIVE` movement when a Purchase Order is delivered.
- **Finance:** Inventory movements (especially Adjustments and Receipts) trigger financial ledger events (Cost of Goods Sold, Inventory Asset Value) which Finance consumes.

## 5. Core / Module / Extension Boundary Table

| Capability | Classification | Justification |
| ---------- | -------------- | ------------- |
| Item | CORE (Catalog) | Universal to all businesses. |
| Inventory | CORE | Universal tracking of assets. |
| Stock Movement | CORE | Universal audit requirement. |
| Warehouse/Location | CORE | Physical placement of assets. |
| Fleet | REUSABLE MODULE | Vehicles/Routes are common to Water/Catering, but not required for Restaurant. |
| Delivery | REUSABLE MODULE | Last-mile tracking. |
| Kitchen | BUSINESS EXTENSION | Strictly Restaurant/Catering workflow. |
| Tables | BUSINESS EXTENSION | Strictly Restaurant dine-in logic. |
| Catering Events | BUSINESS EXTENSION | Strictly Catering logic. |
| Water Batch Tracking | BUSINESS EXTENSION | Specific FDA/compliance tracking for Water. |
| POS | BUSINESS EXTENSION | Specific high-speed UI for front-of-house. |

## 6. Multi-Business Future Extension Test

**"If TANRAIL launches a completely new business tomorrow, what percentage of the Inventory architecture must change?"**

**Scenario A — Restaurant (Rice, 100kg, Main Kitchen)**
Core processes this as: Location X, Item Y, Quantity 100.
**Scenario B — Catering (Rice, 250kg, Catering Store)**
Core processes this as: Location Z, Item Y, Quantity 250.
**Scenario C — Water Distribution (Water 500ml, 10,000 bottles, Depot A)**
Core processes this as: Location W, Item V, Quantity 10,000.
**Scenario D — Transport (Spare Part, 50 units, Garage B)**
Core processes this as: Location T, Item S, Quantity 50.

**Result:** 0% of the Core Inventory Architecture must change to support a new business. The Core mathematically tracks `Item + Location = Quantity`. The Business Extensions handle *why* the stock is moving.