30 lines
1.6 KiB
Markdown
30 lines
1.6 KiB
Markdown
|
# 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`.
|