# TANRAIL ONE — Phase 3.2 Inventory Security & Isolation

## 1. Business Unit Isolation
Inventory must strictly obey the Phase 2 Context Architecture.

**The Chain of Custody:**
1. An `Item` belongs to a `Business Unit`.
2. An `InventoryLocation` belongs to a `Branch`.
3. A `Branch` belongs to a `Business Unit`.
4. Therefore, `StockBalance` and `StockMovement` are transitively locked inside a specific Business Unit.

**Isolation Rule:**
A user authenticated into the context of `Business Unit A` cannot:
- View `InventoryLocation`s belonging to `Business Unit B`.
- View `StockBalance`s belonging to `Business Unit B`.
- Execute a `StockMovement` involving locations outside their authorized Business Unit scope.

## 2. Global Scope Enforcement
Similar to the Phase 3.1 Remediation, all Inventory models must implement a `BusinessUnitScope`.
Because `InventoryLocation` is mapped via `branch_id`, the global scope will automatically join or filter against the `branches` table to verify `business_unit_id === active_context`.

## 3. Authorization Permissions Model
The Reusable Core Authorization (Policies) will govern actions based on the user's assigned Phase 2 Roles.

**Required Generic Permissions:**
- `inventory.view`: Can view balances and locations.
- `inventory.receive`: Can execute `RECEIVE` movements.
- `inventory.issue`: Can execute `ISSUE` movements.
- `inventory.transfer`: Can initiate and complete internal transfers.
- `inventory.adjust`: Can perform manual discrepancy corrections.

**Hierarchy Verification:**
When creating a `StockMovement` (e.g., `ISSUE`), the `ItemPolicy` and `InventoryLocationPolicy` will both independently verify:
`$user->hasAccessToScope(BusinessUnit::class, $item->business_unit_id)`
AND
`$user->hasAccessToScope(BusinessUnit::class, $location->branch->business_unit_id)`

This double-verification prevents an attacker from supplying an Item from BU A and a Location from BU B in the same HTTP request.