Notes from the utility backbone.
How we think about designing, delivering, and keeping optimal the mechanical and electrical utilities of semiconductor fabs — written by the team that runs the model.
Balance the trains: one train per tool, every model across them all
Trains only buy redundancy if each tool sits on one train and each tool model is spread across all of them. Most fab designs don't even take that into consideration, because by hand it's too complex to achieve. The Optimizer enforces it on every run.
Read the post →
Your agent can now read the model: the FacilityConnect MCP server
FacilityConnect speaks MCP, so an assistant can query the living model and load data into it. The interesting part is not the connection — it is what the server refuses to do without asking.
Read the post →
Auto-design and auto-assign: watching the Optimizer place a panel set
Two short walkthroughs of the runs behind optimized utility design: candidate panels become the smallest set that serves every tool, and unassigned demands are matched to their nearest feasible utility connections in seconds.
Watch the runs →
792 panels down to 534: what optimized utility design changes
Fabs routinely over-build their utility distribution — not because anyone is careless, but because manual design under uncertainty rewards margin on top of margin. Here's what happens when an optimizer sites and sizes the distribution instead: on a large European fab, 792 panels down to 534.
Read the post →
White-glove was the bar. Self-serve just cleared it.
We ran the loop as a service until the system could catch input problems the way our engineers do. It can — FacilityConnect is now self-serve.
Read the post →
A snapshot goes stale. A living model doesn't.
Every fab utility design is obsolete the moment a tool moves — unless the design lives in a model that absorbs the change. Why we build living models instead of deliverables, and what that changes for owners.
Read the post →