On a typical EPC engagement for an industrial facility - a cell assembly plant, a BESS installation, a pharmaceutical manufacturing building - a significant fraction of the engineering hours are spent on problems that have been solved before. Structural grid selection, power distribution architecture, HVAC zoning logic, utility tie-in sequencing, fire protection system design - these are not novel engineering challenges on the third or fifth or tenth project of the same type. They are reruns of decisions that were made, documented, and then filed in a project folder that the next team does not know exists.
The EPC model as currently practiced treats each project as a discrete engagement. A team is assembled, discovers the requirements, produces the design, hands off to construction, and disperses. The institutional knowledge generated - the engineering rationale, the value engineering decisions, the supplier qualification data, the lessons from the field - exists somewhere between the project archive and the memories of the engineers who worked on it. On the next project of the same type, a new team reassembles and begins the same discovery process.
This is not inevitable. It is a consequence of organizing around project delivery rather than around product engineering. Software companies do not reassemble a team to rediscover how to build a web server every time they need to deploy one. They have a reference architecture, a configuration system, and a deployment pipeline. The question is whether the industrial construction industry is willing to adopt a structurally similar approach.
The resistance to factory standardization is always the same argument: every project is unique. Site conditions vary. Utility availability varies. Local codes and AHJ interpretations vary. Product mix and throughput requirements vary. None of this is wrong - and none of it invalidates the standardization argument.
The insight is not that all factories should be identical. It is that a large fraction of every factory design covers ground that does not actually vary meaningfully across sites. The structural grid logic for a given building type does not change because the site is in Nevada versus Texas. The electrical distribution architecture for a 20MW manufacturing facility is not fundamentally different in Phoenix versus Cincinnati. The HVAC approach for a given process environment has a small number of valid configurations that are established by physics and code, not by site-specific creativity.
When a design team spends engineering hours redeveloping a structural grid for a facility type they have built four times, they are not adding value; they are spending money to reproduce a decision that has already been made and validated. Standardizing that decision into a reference specification frees the engineering hours for the genuinely variable work: adapting the standard to the actual site, solving the interface problems between systems, optimizing the configuration for the specific production process.
A Factory Operating System is not a single drawing or a specification binder. It is the layered intellectual property that defines how a facility of a given type is structured, from site boundary to production floor.
The reference architecture defines the fixed decisions: how the building structural system relates to the process equipment layout, how power distribution is organized by zone, how utility systems are zoned and controlled, what the standard equipment module interfaces look like. These decisions are made once, validated in the field, and then locked, not because they can never change, but because changing them requires a formal revision process rather than an individual engineer's preference.
The configuration layer defines the variable parameters: site footprint, production capacity, specific equipment selection within a qualified vendor list, local utility interconnect specifications, AHJ-specific code adaptations. A configuration file that captures these parameters drives customization of the reference architecture without custom engineering.
The digital twin layer maintains a living model from design through operations - a structured dataset that reflects the as-built state, supports commissioning, and feeds operational analytics without requiring manual survey and reconstruction when the facility needs an upgrade.
Your phone runs on an operating system. Your car runs on an operating system. Your factory should too, not because it makes the factory simpler, but because it makes the engineering repeatable and the improvements cumulative.
The economic argument for Factory OS is clearest at multi-site scale. A manufacturer planning to deploy 8 BESS facilities over three years under a conventional EPC model faces 8 essentially independent engineering programs. The cost of engineering scales roughly linearly. The risk profile of each facility reflects the learning from previous ones only informally.
Under a Factory OS model, the engineering investment is front-loaded. The first facility is expensive to design because the reference architecture is being established. The second facility benefits from the validated architecture and costs 30-40% less in engineering. By the fifth facility, the engineering program is largely configuration management and site adaptation - the reference design has been validated, the equipment is qualified, the construction methodology is documented, and the primary variable is site-specific execution.
Tesla's Gigafactory expansion strategy depends on this arithmetic. Each new facility is not a new design problem, it is a deployment of a mature architecture to a new site. The engineering cost per facility decreases. The construction predictability increases because the same design has been built before. The commissioning timeline compresses because the control system architecture is identical and the startup team has done it before.
Software engineering manages design evolution through version control: every change to the codebase is tracked, attributed, and reversible. The history of why a design decision was made, what it replaced, and what tradeoffs were considered is preserved in the commit log. A new engineer joining a team can understand the design's evolution without interviewing the people who made the original decisions.
Industrial facility design has no equivalent practice. Drawing revisions are tracked at the document level - rev A, rev B, rev C, but the rationale for each revision is rarely preserved in a structured way. The lesson that drove a change to the standard electrical distribution layout is documented in a project close-out report that no one reads, or it is in the head of the engineer who made the change and who has since moved to a different firm.
Applying version control discipline to a Factory OS means treating the reference architecture as a codebase: changes are tracked, rationale is documented, revisions are tagged with the project that generated the lesson, and the full history is searchable. When the next project team needs to understand why the standard HVAC zoning approach is configured the way it is, they do not need to find the person who made the original decision. They look at the version history.
Battery manufacturing, energy storage system installation, semiconductor fabrication, advanced pharmaceutical manufacturing - these are the facility types where market windows are short, capital is competitive, and time-to-production is the primary variable separating winning organizations from also-rans. They are also the facility types where conventional EPC delivery timelines are most misaligned with business requirements.
The organizations that are winning in these sectors are, to varying degrees, operating on Factory OS principles - whether they call it that or not. Their competitive advantage is not lower construction cost per square foot. It is lower time from site selection to production, lower engineering cost per facility at scale, and higher predictability of performance because they are deploying a validated design rather than a novel one. Those advantages compound with each facility deployed. The gap between them and firms still operating on bespoke project delivery models widens with every additional site.
The construction and engineering industry has accepted for too long that custom design on every project is an unavoidable feature of the work. It is not. It is a methodology choice - and the industries that most need rapid, reliable, repeatable facility deployment are already forcing the choice in a different direction.