Initial commit: add .gitignore and README

docs/purchasing-feedback-loop.md

@@ -0,0 +1,29 @@
+# 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`.