Nuclear’s Second Act: How Advanced Reactor Developers Are Rebuilding Systems Engineering from Scratch

The last commercial nuclear power plant to enter service in the United States — Vogtle Unit 4 — achieved full power operation in April 2024, completing a project that ran approximately $17 billion over budget and seven years behind schedule. It was built largely the same way the previous generation was built: a massive workforce, a document-heavy licensing process, and a regulatory framework designed around light water reactors in the 1970s.

The companies now building America’s next nuclear plants are trying to do something structurally different. X-energy is working toward deploying its Xe-100 pebble bed high-temperature gas reactor. TerraPower’s Natrium sodium fast reactor is under construction in Kemmerer, Wyoming. Oklo has received an NRC license for its Aurora compact fast reactor — the first non-light-water advanced reactor license ever issued. Kairos Power is building a test reactor in Tennessee using fluoride salt coolant. These are not incremental improvements on Vogtle. They are different reactor physics, different safety architectures, different fuel forms, and in several cases, different regulatory pathways.

They are also being built by engineering organizations that range from roughly 200 to 800 people — a fraction of the tens of thousands employed on a traditional nuclear megaproject. That workforce constraint is not a bug to be engineered around. It is a design parameter that is reshaping how nuclear systems engineering gets done.

What the Legacy Playbook Actually Looked Like

To understand what these companies are replacing, it helps to be precise about what legacy nuclear systems engineering actually involved. The process was document-centric by design. A traditional Final Safety Analysis Report (FSAR) — the central licensing document submitted to the NRC — runs tens of thousands of pages. Requirements were managed in enormous word processing documents or early-generation requirements management tools like IBM DOORS, with traceability maintained manually across design bases, safety analyses, and engineering change notices.

This was not irrational. The regulatory framework required it, and the engineering workforce in the 1970s and 1980s was large enough to sustain it. But the institutional knowledge that made it work lived in people, not in systems. Experienced engineers understood which requirements linked to which safety functions, which design changes required updated safety analyses, and which interfaces between systems were load-bearing from a licensing perspective. When those engineers retired — and in the 2000s and 2010s, they retired in large numbers — much of that knowledge retired with them.

The tools did not help. A DOORS database or a SharePoint folder of Word documents cannot answer the question “if I change this valve’s actuation logic, what safety functions are potentially affected?” A human had to answer that question, and increasingly, the humans who could answer it were gone.

Borrowing From Aerospace: MBSE Arrives in Nuclear

The model-based systems engineering (MBSE) methodology that aerospace and defense programs have been developing for two decades is now entering nuclear at a faster rate than most observers expected. The drivers are structural. Small teams building complex systems with high regulatory stakes cannot afford to carry requirements knowledge in people’s heads. They need models that can answer interface questions, propagate change impacts, and generate licensing artifacts from a single source of truth.

X-energy has been explicit about its aerospace-influenced approach. The company hired systems engineers with backgrounds in satellite development and defense programs, and it has built its requirements management and design assurance processes around model-based frameworks rather than document workflows. The goal is a design model where safety classification, functional requirements, design requirements, and verification methods are linked — so that when a design change enters the process, its upstream and downstream implications are traceable without manual reconstruction.

TerraPower, with its deeper institutional history, has taken a hybrid approach: working within existing nuclear QA frameworks (specifically 10 CFR 50 Appendix B) while introducing model-based tooling to manage the complexity of sodium fast reactor safety analysis. The Natrium design involves a molten salt thermal storage system integrated with the reactor — a first-of-a-kind system integration challenge that document-based traceability would struggle to handle cleanly.

Kairos Power has arguably gone furthest in adopting an iterative, test-driven development philosophy. The company built the Hermes test reactor specifically to derisk the licensing process incrementally — demonstrating safety case arguments in hardware before committing to the commercial plant design. This mirrors the developmental test philosophy in aerospace programs. It is also a systems engineering argument: the safety case is not just a document, it is a body of evidence, and evidence from physical tests is more credible to the NRC than analysis alone.

Oklo’s path is different again. The Aurora microreactor is small enough — approximately 1.5 MWe in its initial form — that the safety case can be argued on passive safety characteristics and decay heat removal without the complex active safety systems that drive most traditional nuclear licensing complexity. The systems engineering challenge shifts from managing thousands of safety function interfaces to demonstrating that a small, passively safe system can be licensed under a framework designed for much larger, more complex plants.

The NRC as a Systems Engineering Forcing Function

The Nuclear Regulatory Commission’s pre-application engagement process — formally organized through regulatory audits, topical reports, and pre-application meetings — has become an unexpected systems engineering forcing function for advanced reactor developers.

The mechanism is straightforward. The NRC staff evaluating a novel design need to understand the design’s safety basis before they can identify applicable regulatory requirements. That understanding requires the developer to have a clear, internally consistent model of what safety functions their design performs and how. Developers who arrive at pre-application meetings with traceable, model-based safety cases — where the connection between a design feature and the safety function it supports is explicit and auditable — move through the engagement process faster than those presenting document stacks.

This is not formally required. The NRC has not mandated MBSE. But the regulatory incentive structure rewards it. An NRC reviewer who can query a model to understand “what maintains decay heat removal if this pump fails?” is a faster reviewer than one who has to read three chapters of an FSAR to reconstruct the same logic.

The agency has also been developing its own framework for advanced reactor licensing — notably through the 10 CFR Part 53 rulemaking, which creates a new licensing pathway specifically for non-light-water reactors. Part 53 takes a more risk-informed, performance-based approach than the existing framework, which means the safety case is explicitly organized around demonstrated safety functions and their supporting evidence. That structure maps naturally to model-based requirements management. A developer who has built a graph of safety functions, design requirements, and verification evidence already has the architecture that Part 53 licensing demands.

What a Modern Nuclear Safety Case Actually Looks Like

The phrase “safety case” is used loosely in the industry. In the context of modern advanced reactor development, a rigorous safety case has a specific structure worth being precise about.

At the top level, the safety case argues that the design meets its safety objectives — typically defined in terms of limiting radiation dose to the public under normal operation and accident conditions. Supporting that top-level claim are a hierarchy of safety functions: the functions the plant must perform to prevent or mitigate accidents. Each safety function is allocated to design features — specific systems, components, or passive characteristics. Each design feature has design requirements. Each design requirement has a verification method — analysis, test, inspection, or review of design. Each verification method has evidence — a completed analysis, a test result, an inspection record.

That structure is a graph, not a document. The connections between nodes carry safety meaning. A change to a component that performs a safety function propagates upward through that graph to the safety function level, potentially requiring updated analysis or new testing. A change that does not connect to any safety function is, by definition, not safety-significant — a conclusion that has to be defensible to the NRC.

Legacy document-based tools handle the flat representation of this information adequately. They fail at the graph traversal — the “what else does this affect?” question that is central to change management in a complex, regulated design. This is precisely where modern AI-native tools built around graph data models show genuine value over document repositories or traditional hierarchical requirements managers.

Tools like Flow Engineering, built specifically for systems and hardware engineering teams managing complex requirements graphs, provide the connection traversal that nuclear safety case management requires. Rather than storing requirements in a flat database with manually maintained link tables, graph-native tools make the traceability relationships first-class objects — queryable, visualizable, and maintainable as the design evolves. For a small nuclear development team managing thousands of requirements across safety analysis, design, and verification, the difference between a tool that answers “what does this change affect?” in seconds versus one that requires a manual impact assessment is operationally significant.

The Workforce Problem Is a Knowledge Management Problem

The nuclear workforce challenge is real and well-documented. The engineers who designed, built, and licensed the last generation of plants are retired or retiring. The pipeline of new nuclear engineers shrank dramatically during the decades when new plant construction was not economically viable. Advanced reactor developers are hiring from aerospace, defense, and software — disciplines where MBSE, model-driven design, and iterative development are normal practice.

This is largely a positive dynamic. It imports rigor and tooling that legacy nuclear needed. But it creates a specific knowledge management challenge: the institutional knowledge of nuclear-specific regulatory requirements, safety analysis methods, and licensing precedents does not transfer automatically from aerospace experience. A systems engineer who has built an impeccable MBSE model on a satellite program still needs to understand what the NRC means by “defense in depth,” how probabilistic risk assessment integrates with deterministic safety analysis, and what level of design maturity is required at each licensing stage.

The companies managing this transition well are investing in structured knowledge capture — not just hiring experienced nuclear engineers, but encoding their knowledge into the requirements models and system architectures so that it is accessible to the team rather than locked in individual contributors. This is one of the more operationally concrete arguments for model-based tooling over document-based: a model that embeds safety classification, regulatory basis, and design rationale directly in the requirements structure is less dependent on any individual knowing where to look.

Honest Assessment: What’s Still Hard

The new entrant nuclear companies face real challenges that systems engineering methodology does not fully solve.

First, schedule. MBSE and modern tooling improve the quality of requirements management and reduce rework, but they do not eliminate the fundamental difficulty of first-of-a-kind nuclear construction. Natrium is currently tracking against its 2030 deployment target, but sodium-cooled fast reactor construction at commercial scale has no recent U.S. precedent. Surprises happen.

Second, supply chain. The companies that manufactured nuclear-grade components in the 1980s largely exited the business. Rebuilding qualified supply chains for novel fuel forms (Xe-100’s TRISO pebbles, Kairos’s fluoride salt), exotic structural materials, and specialized instrumentation is a multi-year effort that runs in parallel with, and sometimes constrains, the design process. A requirements model does not manufacture a component.

Third, regulatory bandwidth. The NRC is staffed to review a limited number of novel reactor applications simultaneously. The agency has improved its advanced reactor review capacity, but the queue is filling. Developers who submit incomplete or poorly organized safety cases create delays that affect not just themselves but the entire review pipeline.

None of these challenges argues against the MBSE approach. They argue for realistic expectations about what better systems engineering practices can and cannot accelerate.

The Broader Implication

The nuclear power renaissance, if it sustains, will be the most technically demanding commercial engineering undertaking of the 2020s. It involves novel reactor physics, first-of-a-kind fuel forms, a skeptical regulator operating under a framework designed for different technology, a depleted workforce, and commercial pressure to hit cost and schedule targets that legacy nuclear never approached.

The companies navigating this successfully are treating systems engineering not as a compliance overhead but as the primary mechanism for managing complexity under uncertainty. They are building traceable safety cases from the start rather than reconstructing traceability for licensing submissions. They are engaging the NRC with model-based artifacts rather than document stacks. They are encoding institutional knowledge into systems rather than people.

That is not just a better way to build nuclear plants. It is the only viable way to build them at the speed and cost these companies need to be commercially relevant. The tooling and methodology that aerospace and defense developed to manage complex system development under regulatory oversight is now, somewhat belatedly, arriving in nuclear. The industry’s ability to capitalize on this moment depends substantially on whether engineering teams can adopt that discipline quickly enough to matter.