No hyperscaler is looking to build a single AI Factory. Every hyperscaler wants to build quickly, inexpensively, repeatably. There is obvious tension there, because, while a campus may offer exceptional homogeneity (see Richland Parish in Louisiana), the portfolio presents heterogeneity.
The key is to develop a collection of first principles and approaches that can be consistently applied over time.
If each new AI factory requires the organization to redesign its electrical architecture, cooling strategy, control model, supplier stack, commissioning sequence, and operating procedures, on-top of unavoidable geographical variations it simply can’t scale efficiently. You effectively start over each time.
The fastest AI factory, then, is not simply the one with the most aggressive schedule. It is the one whose hardest decisions have already been made, tested, and converted into a platform - and whose next deployment inherits that evidence and lesson-learned.
It is rare to get another identical building - but it is very common, indeed it is best practice to re-apply first principles. The fastest and best build comes when qualified decisions and evidence are transferred without requiring another fresh design.
This post looks at that approach and sets the table for a three part series on modular architecture/prefab. Those subsequent posts will cover 1. Electrical modularity 2. Building shell modularity 3. White space modularity.
A portfolio cannot run on heroics
It is possible to make one project move very quickly. We saw that in Memphis. A company can concentrate its best people, expedite equipment, carry extra inventory, accept temporary workarounds, and have senior leadership actively engaged at the most detailed level.
And you will still end up with exponential capex increases to solve, which, if speed is your ultimate objective, is fine but it does not set a stable foundation for portfolio growth.
But those heroics do not compound. They consume scarce management oversight and obscure the true cost of delivery. The relevant question for a hyperscaler is not only, “How fast did this campus reach ready for service?” It is, “What does the next campus no longer have to discover?”
We also saw this in Memphis where Colossus and Colossus 2 are fairly different (existing factory retrofitted running H100 vs. modular build, gas-powered, B200 transitioning to BTM power). Of note is that Colossus took 122 days and Colossus 2 took 91 days.
This question is becoming more urgent because compute and infrastructure increasingly run on different clocks. NVIDIA now describes an annual cadence for new AI supercomputer generations. The electrical, mechanical, civil, supply-chain, and permitting systems that support them move on multiyear timelines.
In a more realistic timeline, a platform designed as a fixed answer to one rack generation can arrive already constrained. It is feasible that if you don’t know what you are doing and suffer some delays that your project, which costs billions of dollars, is obsolete or at least impaired at RFS. A platform redesigned at every generation never develops a learning curve.
The strategic problem is not about schedule compression, rather it is about, ironically, re-inforcement learning.
Repeatability is not replication
Every site is different. This is true within a campus and certainly across them.
One campus begins with a strong utility interconnection. Another begins with constrained grid capacity and onsite generation. Voltage, fault levels, grid codes, protection requirements, climate, water, geology, seismic conditions, permitting, labor, logistics, and available suppliers all change by location.
While the industry has a tendency to use the word modularity loosely, the truth is that a “copied building” would either fail those conditions or bury the organization in exceptions.
The opposite error is to let those differences propagate through the entire facility.
A different power source should not automatically force a new compute topology. A different heat-rejection system should not require the rack-side liquid loop to be reinvented. A local code requirement should not reopen every control sequence and acceptance test.
The best, more repeatable architectures have to separate two things: what must adapt and what should repeat.
Some things are simply going to be different at every site: how power arrives, what the grid requires, the civil conditions, the climate, the water available, and the resilience strategy. The architecture has to absorb those differences without allowing them to redesign the entire factory.
The repeatable core is everything that should transfer from one site to the next: interface requirements, qualified power and cooling blocks, compute neighborhoods, network patterns, control systems, factory and site acceptance tests, commissioning sequences, spares strategy and operating telemetry.
The boundary between those domains is where you can earn scale, compress timelines and lower costs.
This is a product-architecture problem, not a real-estate problem. In complex systems, the interfaces determine whether one change stays contained or forces everything around it to change. That principle is well established in manufacturing, where product architecture determines how effectively a platform can support variation, upgrades and reuse. The same logic applies here. The question is not whether every facility looks alike. It is whether local variation is contained, or allowed to trigger non-recurring engineering everywhere downstream.
The 80 percent design ambition
Radiant’s working ambition is that roughly 80 percent of an AI-factory architecture (the DC & the whitespace) should be reusable and no more than roughly 20 percent should require site-specific adaptation.
That is not a measured industry constant. It is not a promise that 80 percent of drawings, equipment, or labor will be identical. The useful definition is more demanding: maximize the share of engineering decisions, interfaces, qualified configurations, test evidence, and operating logic that can move to the next site without reopening first principles.
The ratio will change by market and project. A campus with an unusual generation mix or severe water constraints may carry more adaptation work. The job is to identify what really needs to change, contain it, and keep it from forcing changes across the rest of the factory.
Product-platform research makes the tradeoff clear. Commonality creates leverage across a family of products, but too much can compromise the performance of individual variants.[3] The goal is not maximum sameness. It is minimum reinvention consistent with the site’s real requirements.
Site uniqueness is not the enemy of repeatability. Uncontained uniqueness is.
Stable interfaces create useful freedom
Standardization and optionality can reinforce each other. As Baldwin and Clark describe, defined interfaces allow modules to be improved, substituted, or deferred without reopening the entire system. Preserving those choices requires upfront investment in architecture, qualification, and governance.
For AI factories, the useful approach is bounded optionality: a limited set of tested variants at the interfaces most likely to change. Preparing for every imaginable input, technology, and supplier adds capacity, complexity, and qualification work that may never earn its keep.
Power is a practical example. In August 2026, OCP described collaboration among Google, Microsoft, and NVIDIA on common interfaces and requirements for 800 VDC infrastructure. The work accommodates different migration paths: a side power rack connecting to existing 480 VAC infrastructure, and a future path converting medium-voltage AC directly to 800 VDC. Operators can retain different upstream arrangements while working toward common downstream requirements.
The objective is to lower the cost of repeated deployment while keeping future changes manageable. That requires deciding where variation is useful and qualifying the alternatives.
The repeatable unit is evidence, not a box
The industry often reduces modularity to containers, skids, or prefabricated rooms. Those are genuinely useful delivery formats, but they are not the strategy.
A power skid without a stable control interface is a component. A compute pod without a proven commissioning sequence is an assembly. A repeatable production unit joins a defined quantity of conditioned power, heat-removal capacity, compute and network configuration, integrated controls, and a system-level acceptance test.
That is evidence.
The evidence behind that unit includes the validated one-lines and calculations, the permissible substitutions, the supplier qualification, factory-acceptance results, installation sequence, software configuration, alarm taxonomy, commissioning scripts, known failure modes, corrective actions, and operating data. When a defect is found at one site, the fix should enter the platform so that every future build - and, where practical, every existing one - benefits.
Current reference architectures show the market moving in this direction. NVIDIA’s Vera Rubin DSX reference design spans compute, networking, storage, power, cooling, controls, and digital-twin validation in pursuit of repeatable, scalable cluster performance.
DSX-aligned electrical reference architecture connects a nominal 34.5 kV utility supply through medium-voltage distribution and modular low-voltage power blocks to the rack interface. Suppliers say the pattern can scale from tens to hundreds of megawatts without fundamental redesign and links prefabrication and factory testing to lower onsite complexity and more repeatable commissioning.
Accepting that those are vendor design claims, not universal outcome data, it does not change the strategic significance: the unit of design is expanding from equipment selection toward an integrated, versioned system.
The platform needs an owner to manage releases, approve variants and component substitutions, and carry corrective actions across the fleet. Teams need a clear distinction between selecting a qualified configuration and introducing a design change. A local improvement should enter the platform only when its value across the fleet justifies the complexity it adds.
Measure inheritance and the cost of change
Most programs can report construction progress. Fewer can say how much of one deployment the next has inherited.
I would start with three portfolio measures:
- New engineering effort. How much design, analysis, and qualification does each comparable deployment require?
- First-time-right commissioning. How much passes acceptance without redesign or retest?
- Cost of change. What time, engineering effort, and capital are required to accommodate a new power input, rack generation, cooling regime, or supplier?
The 80 percent ambition belongs here as a management target. It should make teams explicit about which decisions carry forward and why each exception justifies the additional work. Tracking those outcomes help us show whether reuse is reducing delivery effort and making changes more manageable.
The second deployment is the proof
The first AI factory proves that a design can work. The second gives us a better view of how much delivery capability carries forward.
A shorter schedule is encouraging. To assess repeatability, we also need to know what the next deployment inherited: qualified designs, supplier experience, factory tests, commissioning procedures, and corrections from the first site.
If the answer is yes, the organization has created more than a facility. It has created an institutional capability.
This is the manifesto for the series that follows.
We will move from the outside in: first, the power boundary that absorbs different inputs; next, the powered shell that moves integration and verification off the critical path; and finally, the compute-ready interior that preserves economical choices across technology generations.
Every AI factory will sit on different land and connect to a different energy system. The objective is not to erase those differences. It is to design them out of the parts of the factory that should repeat.
The fastest AI factory is the one you build twice because the second is where a project becomes a platform - and where speed stops depending on heroics.
