When a consultant finishes a fab's utility design, they hand over a deliverable: drawings, schedules, load calculations. It's accurate the day it's issued. It starts going stale the day after — because the fab it describes keeps changing, and the deliverable can't.
The freeze problem
Fab construction runs on a brutal schedule, and the utility design sits on the critical path. The tool set — the thing the whole design serves — firms up late and keeps shifting. Every change ripples: move a tool and the load moves with it, on power, process cooling, exhaust, and make-up air all at once.
A design that exists as documents gives the project two bad options. Freeze early, and every subsequent change becomes rework — engineering hours spent re-deriving numbers that a model could have propagated in seconds, or worse, changes that never make it into the documents at all. Freeze late, and the trades downstream wait on a design that isn't ready. Most projects split the difference and get a bit of both: rework and waiting, plus a set of documents nobody fully trusts by hook-up.
The problem isn't that the design is wrong. It's that the design is a photograph of a thing that moves.
What "living model" actually means
FacilityConnect holds the fab's utility reality as structured, connected data rather than documents: every demand, every supply, and every connection between them, with capacity pools, diversity factors, and scenario timing that profile load across the build.
Concretely, that means:
- Demands come from tool templates — each tool type carries its utility requirements, so an equipment list becomes a structured, diversity-corrected demand model. Generic templates stand in before the real tools land.
- Supplies and distribution — every system and piece of equipment, mechanical and electrical — carry their capacity limits, so utilization is a computed fact, not a spreadsheet cell someone maintains.
- Connections tie the two together. They're the record of what gets built, and they keep changes tracked and auditable.
- Scenarios and revisions let the model hold time: what's installed when, what's planned against what's confirmed, so change is versioned instead of destructive.
When a tool moves or a demand changes, the model absorbs it and every downstream number updates. Nobody re-derives anything. The design moves with the build instead of going stale — and because our engineers re-run the Optimizer against the updated model, the design doesn't just stay current, it stays optimal.
What this changes for owners
The practical difference shows up in the questions you can afford to ask. Against documents, "what happens if this tool row moves?" is a study — weeks of consultant time, answered as of last month's data. Against a living model, it's a query. That changes the economics of change itself: when evaluating a layout revision is cheap, you're free to keep improving the plan late into the project instead of defending a freeze that everyone knows is fiction.
It also means nothing has to be over-built to protect what comes next. A snapshot design carries margin because nobody knows which assumptions will still hold in six months. A living model doesn't need that insurance — when an assumption changes, the model tells you exactly what it touches.
And the model doesn't stop when the design is issued. After hook-up, Installed Insights keeps watching the same model in operation — live utilization and headroom by system — so the assumptions behind the design stay visible in the running fab, not just on paper.
One model, from first tool spec to hook-up and beyond. Everything we do — the Optimizer, Installed Insights, our data-management services — plugs into it. That's the bet Basesite is built on.