# Phase 1 Data Model: Foundations in Inventory (047)

## Existing Entities

### `InventoryItem`
Represents the last observed state for a tenant-scoped Intune object.

**Key fields (existing schema)**
- `tenant_id` (FK)
- `policy_type` (string)
- `external_id` (string)
- `display_name` (nullable string)
- `category` (nullable string)
- `platform` (nullable string)
- `meta_jsonb` (jsonb, safe/whitelisted)
- `last_seen_at` (timestamp)
- `last_seen_run_id` (FK to `InventorySyncRun`)

## New Semantics (no schema change)

### Foundation Nodes
A foundation node is an `InventoryItem` where:
- `policy_type` is one of `config('tenantpilot.foundation_types')[*].type`
- `category` is set from the foundation type config (MVP expects `Foundations`)

**In-scope foundation types (MVP)**
- `roleScopeTag` (Scope Tag)
- `assignmentFilter` (Assignment Filter)
- `notificationMessageTemplate` (Notification Message Template)

## Relationships

- Tenant isolation: all foundation nodes are strictly tenant-scoped.
- Dependencies (Spec 042) can reference foundations via edges, and Spec 042.2 can resolve their display names locally by matching `(tenant_id, policy_type, external_id)`.

## Validation / Invariants

- Idempotency: repeated sync runs update `last_seen_at` and `last_seen_run_id` deterministically without creating duplicates.
- Data minimization: foundation sync must not store non-whitelisted payload data in `meta_jsonb`.