# Purchasing feedback loop

How UniFi telemetry and product intelligence drive approved buy lists, BOMs, and support-risk views.

## Data flow

1. **UniFi device sync** — Devices are synced from each sovereign’s controller; device list includes model/SKU.
2. **Product catalog lookup** — Each device model/SKU is matched against `unifi_product_catalog` (generation, EoL, support horizon).
3. **Outputs:**
   - **SKU-normalized BOM** per sovereign/site: which exact hardware is deployed, with generation and support status.
   - **Support-risk heatmap:** devices near EoL or with short support horizon.
   - **Firmware divergence alerts:** when firmware versions drift from policy (see compliance profiles).
   - **Approved purchasing catalog:** only SKUs that meet the sovereign’s compliance profile (allowed generations, approved_skus).

## Approved buy list

The “approved buy list” is the intersection of:

- Devices in use or recommended (from UniFi + catalog), and  
- Catalog entries with `approved_sovereign_default` or matching the org’s **compliance profile** (allowed_generations, approved_skus).

So operations (what we have and what’s supported) drives procurement (what we’re allowed to buy), not the other way around.

## Optional API

- `GET /api/v1/reports/bom?org_id=&site_id=` — Aggregate assets + UniFi mappings + catalog for a BOM.
- `GET /api/v1/reports/support-risk?org_id=&horizon_months=12` — Devices with EoL or support horizon within the next N months.

These can be implemented as thin wrappers over existing schema, `unifi_product_catalog`, and `integration_mappings`.