Why Nuclear New Build Programs Keep Facing Requirements Instability

Nuclear new build should be an engineering triumph. The physics is understood. The safety case is mature. The workforce — while depleted — exists. Yet the two flagship Western nuclear construction programs of the last decade, Vogtle Units 3 and 4 in Georgia and Hinkley Point C in Somerset, have between them absorbed tens of billions in cost overruns and added years of delay to their schedules. Vogtle finished at roughly $35 billion, more than double its original estimate. Hinkley Point C has revised its completion date and cost ceiling multiple times, with EDF’s latest estimates placing the total north of £35 billion.

The conventional explanations — labor shortages, supply chain disruption, post-Fukushima regulatory tightening — are real. But they are symptoms. The underlying disease is requirements instability: a pervasive inability to define, lock, communicate, and trace what a plant needs to be before the concrete is poured. By the time problems surface on the construction site, the requirements failure that caused them is already two or three years old and buried in documents that no one has fully cross-referenced.

What Requirements Instability Actually Looks Like at Scale

A nuclear plant is not a large building with some complicated equipment inside. It is a system of systems with interdependency density that rivals aerospace — except the project runs for fifteen years instead of five, involves hundreds of suppliers across multiple countries, and must satisfy a regulatory body that is itself interpreting evolving standards.

At Vogtle, the AP1000 design was Westinghouse’s first-of-a-kind passive safety system deployment in the United States. The NRC had certified the design, but certification of a reference design is not the same as a finished requirements baseline for a specific site. Site-specific departures — from seismic conditions, from local electrical grid characteristics, from state utility commission requirements — each required formal deviations and design changes. Each design change touched multiple systems. At Vogtle’s scale, the rebar and concrete modules were being fabricated in Lake Charles, Louisiana while design changes were still being processed in Pittsburgh and Atlanta. The modules didn’t fit. Not because someone made a fabrication error, but because the requirements governing the module interfaces were still moving when the modules were being built.

Hinkley Point C faces a structurally different but functionally identical problem. The EPR design — also a first-of-a-kind deployment at this scale for EDF — had already been built at Flamanville in France and Olkiluoto in Finland, both of which ran massively over schedule and budget. The UK version was supposed to incorporate lessons learned from both. In practice, the design carried forward a document-based requirements architecture that could not propagate change decisions fast enough. When UK regulators at the ONR issued updated interpretations of safety system independence requirements, the impact assessment took months because there was no live traceability model showing which systems were affected. By the time affected drawings were revised, some physical work had to be redone.

The Document-Based Requirements Trap

Both programs were managed, at the requirements level, primarily through documents: requirements specifications, interface control documents, design basis documents, and safety analysis reports — each maintained by different organizations, often in different document management systems, cross-referenced by document number rather than by semantic relationship.

This architecture has a fatal flaw: it cannot represent change impact in real time. When a requirement changes — whether because of a regulatory interpretation, a supplier capability limitation, or a late design decision — the people who need to know about it are identified by searching document cross-reference tables or by institutional knowledge. In a program employing thousands of engineers across dozens of companies, neither mechanism is reliable at scale.

The result is systematic latency: requirements changes that take weeks or months to propagate through the supplier network, with inconsistencies accumulating in the gap. By the time an inconsistency surfaces — usually as a physical rework order on site — the cost of resolution has multiplied by an order of magnitude compared to what it would have cost to catch it at the requirements review stage.

It is worth being precise about what “requirements instability” means here. It does not mean the requirements were wrong. Many of the changes at Vogtle and Hinkley were appropriate responses to real conditions. The failure was not having a system that could absorb those changes rapidly, propagate them accurately, and surface the downstream impacts before commitments were made.

Regulatory Interpretation as a Moving Baseline

One of the least-discussed drivers of nuclear requirements instability is regulatory interpretation drift. Nuclear regulators do not — and arguably should not — freeze their safety standards over a fifteen-year construction program. New research, operational experience from other plants, and post-incident reviews all legitimately update what regulators expect.

The problem is that regulatory interpretation updates arrive as guidance documents, regulatory information summaries, or informal correspondence, and must be mapped back to a technical requirements baseline that is itself distributed across hundreds of documents. In a graph-based requirements model, a new regulatory interpretation could be linked directly to the affected system requirements, generating an impact report within hours. In a document-based system, the mapping is manual, slow, and incomplete.

Post-Fukushima requirements at Vogtle illustrate this precisely. The NRC’s FLEX requirements — new mandates for diverse and flexible mitigation strategies against beyond-design-basis events — were issued while Vogtle was under construction. They were well-reasoned safety improvements. But incorporating them required changes to multiple systems whose interfaces were already partially designed and in some cases already physically installed. The cost of that change was not primarily the engineering redesign. It was the work required to find every place in the requirements baseline where FLEX touched, and then re-validate all the downstream commitments.

What the SMR Wave Is Doing Differently

The small modular reactor developers entering the market now — NuScale, X-energy, Kairos Power, and others — had the advantage of watching Vogtle and Hinkley unfold in near real time. They have drawn a consistent lesson: requirements architecture is a first-principles engineering problem, not an administrative function to be organized later.

NuScale pursued NRC design certification for its SMR design with a degree of upfront requirements discipline that traditional programs did not apply. The company’s standard design certification strategy explicitly aimed to resolve regulatory interface questions before site-specific construction began — shifting the regulatory uncertainty from the construction phase to the design phase where changes are cheap. Their requirements baseline was structured to support modular deployment, meaning each plant instance needed to be a traceable derivative of the certified standard design, not a custom build. This modularity is only possible if the requirements architecture is itself modular — with clean interface definitions between subsystems that can be parameterized for site-specific conditions without invalidating the certified design.

X-energy is developing the Xe-100 pebble bed high-temperature gas reactor, targeting industrial heat and power markets. Their engineering challenge is managing requirements across a genuinely novel fuel form — TRISO pebble fuel — and novel materials operating at high temperatures, while pursuing DOE licensing frameworks that are themselves still being developed. X-energy has structured their requirements management around model-based systems engineering (MBSE) principles from the program’s inception, maintaining a live system architecture model that connects regulatory requirements, design requirements, and supplier interface requirements in a single navigable structure. When the NRC issues updated guidance on high-temperature reactor materials qualification, X-energy can query which parts of their requirements baseline are affected. That query takes minutes, not months.

Kairos Power is building the KP-FHR, a fluoride salt-cooled high-temperature reactor. Their approach to requirements stability has a distinctive feature: they completed construction of a non-nuclear test reactor — Hermes — specifically to validate key design and requirements assumptions before the licensing basis for the commercial plant was locked. This is a form of requirements validation that traditional large-plant programs cannot afford and rarely attempt. By physically building and operating Hermes, Kairos converted uncertain requirements — particularly around salt chemistry, heat exchanger behavior, and fuel handling — into tested, confirmed requirements before they became embedded in the commercial design basis.

All three companies are also notably smaller and more vertically integrated than traditional nuclear EPC consortia. This matters for requirements management because interface control documents between organizations are where requirements instability most frequently originates. A company that controls more of its own design, supply chain, and construction execution has fewer inter-organizational interfaces where requirements can diverge silently.

Modern Tooling Entering Nuclear Engineering

The tooling available to SMR developers today is categorically different from what was available when Vogtle’s design was frozen. Modern requirements management platforms built on graph-based data models — where requirements, design artifacts, test cases, and regulatory citations are nodes connected by live semantic relationships — can represent the interdependency structure of a complex system accurately and query it dynamically.

Flow Engineering, for example, represents requirements as a connected graph rather than a document hierarchy. In a nuclear context, this means a change to a safety classification requirement can immediately surface every downstream design requirement, interface requirement, and test requirement that derives from it — before any physical commitment is made. The traceability is not a manually maintained cross-reference table that goes stale; it is a structural property of how requirements are stored. For programs where regulatory interpretation can arrive mid-execution and must be absorbed without cascading rework, this architecture is not a convenience. It is a prerequisite for schedule integrity.

Flow Engineering’s current focus is on the earlier stages of systems engineering — requirements definition, decomposition, and traceability — rather than on the full configuration management and document control workflows that characterize a mature nuclear QA program. SMR developers are using it where it is strongest: to build and maintain the requirements architecture during the design and pre-licensing phase, where graph-based traceability provides the most leverage.

The Structural Fixes That Make Tooling Matter

Better tooling alone will not prevent the next Vogtle. The structural conditions that created requirements instability at large plants — first-of-a-kind designs, fragmented EPC contracting, regulatory interfaces resolved during construction rather than before — are the root causes. Tooling provides leverage only when the engineering process creates the right artifacts at the right time.

The SMR model addresses the structural issues directly. Standardized designs reduce first-of-a-kind uncertainty. Factory fabrication of modules shifts manufacturing quality control from construction sites to controlled industrial environments. Smaller plant sizes reduce the absolute interdependency count. And design certification before construction begins converts regulatory uncertainty from a construction-phase risk into a design-phase cost — which is where it belongs.

An Honest Assessment

Nuclear new build in the West is expensive primarily because it is complex, and complex systems require requirements management equal to their complexity. The legacy programs failed not because nuclear engineering is impossible, but because they attempted to manage gigawatt-scale system interdependencies with document-based tools that could not represent those interdependencies accurately or respond to change rapidly enough.

The SMR developers have structural and tooling advantages that large-plant programs did not. Whether those advantages translate into on-budget, on-schedule deployments remains to be demonstrated — no Western SMR has yet completed construction and entered commercial operation. NuScale canceled its Carbon Free Power Project in Utah in late 2023, a genuine setback that illustrates how difficult the economics remain even when the engineering approach is sound.

But the requirements management trajectory is clearly different. Programs that start with graph-based traceability models, modular design architectures, and regulatory pre-engagement strategies are at least solving the right problem. The programs that finished at twice their estimated cost and years late were not solving the wrong problem. They were solving it with tools that were never equal to the task.