Fleet operations: 170+ semantic models, refresh, rebinding, and cost control
outcome near-daily capacity upgrades stopped the week it shipped
Problem
Every client report ran off one giant semantic model holding every company’s data, and it was eating the Fabric capacity alive: manually bumping the capacity from F32 to F64 had become an almost daily routine, solved by throwing money at it. The obvious fix, one model per client, had always been dismissed as unmanageable: a single change would need applying to 170-plus models by hand. Rebinding reports, orchestrating refreshes, and controlling capacity spend were all hand-work too.
What I built
AI-assisted, five pieces:
- A baseline-model architecture that makes the “unmanageable” option manageable: 171 per-client semantic models maintained from one baseline, so a change is made once and propagated to the whole fleet instead of edited 171 times
- A confidence-tiered report rebinding tool: exact matches applied automatically, fuzzy matches queued for human review
- Self-contained model-refresh notebooks wired into the daily pipeline; the first full production run refreshed 171 of 171 models
- A shortcut-based storage layer so serving stays cheap when the source capacity is paused
- A capacity orchestrator that owns the pause and resume lifecycle of a second cloud capacity, cutting cost without risking the overnight run
Outcome
Fleet-scale BI operations run by pipelines and agents, with cloud spend actively managed rather than passively accrued. The near-daily F32 to F64 capacity upgrades stopped the week the per-client models were released. The full saving lands as the remaining reports migrate onto them; the target is running the whole estate on an F16, a quarter of the peak capacity.