FIELD BY FIELD · PROPOSED CARD vs THE API
What exists, and what does not
Every figure on the proposed card, checked against the AssetGroup DTO the grid already binds to. Seven are re-dressing. Eight are new work, and they are not evenly sized.
- Already served
- 7no API change
- New, cheap
- 4aggregates and rollups
- New, expensive
- 4new sources or history
- Blocked on time
- 1the 90-day trend
Already in the DTO7 — presentation only
These are what Jaya means. The card can be rebuilt around them with no backend change at all.
count, modelCountfleetHealthPctatRisk / countonContract / counttotalReplacementCostclinicalImportancetopEquipment[]Not in the API8 — new work
Four are ordinary additions to the group query. Four need something that does not exist yet.
fleetHealthPct, so this needs a snapshot and a daily job — and shows nothing until 90 days of it exist.AssetGroup.atRisk is a single number; this needs past-end-of-support, beyond-useful-life, unsupported-OS and open-recall counted apart.topEquipment carries the name and manufacturer only.modelCount minus the four shown. Cheap, but needs the rollup’s own figures.↓4 pts 90d is not expensive to write — it is expensive to have. Nothing in the schema records what fleet health was yesterday, so the work is a snapshot table plus a daily job, and then ninety days of waiting before the card can show a real number. Anything promised on it should be dated from when the snapshot starts, not from when the code merges.
347 open work orders · 62 past SLA appears nowhere near AssetGroup, and “past SLA” is not defined anywhere in the card. Before this is scheduled, someone has to confirm the product holds work-order data at all, and what an SLA breach counts as. It is the single largest unknown in the document.