Files
sankofa-hw-infra/docs/purchasing-feedback-loop.md
defiQUG 93df3c8c20
Some checks failed
CI / lint-and-test (push) Has been cancelled
Initial commit: add .gitignore and README
2026-02-09 21:51:50 -08:00

1.6 KiB
Raw Permalink Blame History

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 sovereigns 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 sovereigns 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 orgs compliance profile (allowed_generations, approved_skus).

So operations (what we have and whats supported) drives procurement (what were 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.