Nuclear Power’s Engineering Comeback
How new reactor programs are rebuilding systems engineering capability after decades of institutional atrophy
The last time the United States completed a new nuclear power plant from scratch, the Berlin Wall was still standing. The Watts Bar Unit 1 reactor, licensed in 1996 after construction that began in 1973, was less a demonstration of modern nuclear engineering than a completion of unfinished Cold War infrastructure. For the better part of thirty years, the practical knowledge of how to design, license, and build a commercial reactor in America existed primarily in the heads of engineers who were aging out of the workforce — and in documents that were poorly organized, incompletely captured, and scattered across utilities, contractors, and national laboratories.
That is the inheritance the current generation of nuclear developers is working with. And the scale of the systems engineering challenge they face is only partly about the reactors themselves.
The Knowledge Gap Is Real, and It Has Engineering Consequences
The atrophy is not metaphorical. When TerraPower, X-energy, Kairos Power, and their peers talk about rebuilding nuclear engineering capability, they mean something specific: the structured, disciplined practice of translating safety goals into system requirements, decomposing those requirements across subsystems, tracing them through design decisions, and maintaining that traceability through regulatory review and design revision.
Nuclear engineering in the United States, during the construction era of the 1960s and 1970s, was not notable for rigorous systems engineering. It was notable for massive engineering effort, enormous contractor workforces, and a regulatory environment that was itself learning in real time. Requirements were often captured in narrative safety analysis reports that mixed design description with regulatory commitment with operational assumption — documents that grew to tens of thousands of pages and that almost no one could navigate coherently.
When construction stopped, that institutional practice stopped being transmitted. The engineers who knew how a Final Safety Analysis Report related to a design basis, who understood how a Technical Specification flowed from a safety function, who could trace a licensing commitment back to a physical design decision — they retired. The utilities that operated existing plants retained operational expertise, but operational expertise is not the same as design and licensing expertise. These are different disciplines, and the second one went largely dormant.
New entrants now face a double problem. They must develop novel reactor technologies — sodium-cooled fast reactors, pebble bed high-temperature gas reactors, molten fluoride salt reactors — while simultaneously rebuilding the SE infrastructure that turns a reactor concept into a licensable, buildable system. There is no shortcut on either dimension.
What Aerospace and Defense Practice Offers
The intellectual transfer that is currently underway in nuclear development is worth examining in detail, because it is deliberate and consequential.
TerraPower, which is developing the Natrium sodium-cooled reactor with GE Hitachi, has drawn heavily on aerospace and defense systems engineering practice — specifically, the model-based systems engineering (MBSE) frameworks that have become standard in programs governed by MIL-STD-882, NASA NPR 7123, and similar standards. The core insight borrowed from those domains is that requirements are engineering artifacts, not documentation products. They live in a structured model, they decompose hierarchically, they are allocated to physical elements, and they are verified by defined methods. This is not how nuclear engineering historically worked.
X-energy, developing the Xe-100 pebble bed reactor, has been similarly explicit about importing defense acquisition discipline. Their engineering leadership has described their requirements management approach in terms that would be immediately recognizable to anyone who has worked on a major defense program: a system requirements document that drives a preliminary design, a verification and validation matrix that is maintained throughout, and a structured interface with NRC that treats each regulatory commitment as a traceable requirement with an owner.
Kairos Power, whose Hermes test reactor at Oak Ridge represents the first non-light-water reactor to receive an NRC construction permit in decades, has pushed further into the tooling question. Their engineering teams have been public about the fact that legacy nuclear SE tools — largely built around document management and change control for existing designs — are inadequate for a greenfield development program. The problem is not document management. The problem is maintaining live, navigable relationships between safety goals, design requirements, physical implementations, and regulatory commitments across a design that is changing rapidly.
This is precisely the gap that aerospace and defense recognized in the 1990s and addressed with model-based approaches. Nuclear development is now having the same reckoning, twenty-five years later.
The NRC’s Part 53 Changes the SE Calculus
The regulatory dimension of this engineering revival deserves specific attention, because it is materially different from what nuclear developers faced in previous eras.
10 CFR Part 53 — the NRC’s new licensing framework for advanced reactors, still being finalized but already shaping how developers structure their programs — is built around a technology-inclusive approach that requires applicants to define their own safety functions and demonstrate how their design achieves them. This is fundamentally different from the prescriptive Part 50 framework, which specified what nuclear plants had to do in considerable detail.
Part 53 is, in systems engineering terms, a performance-based framework. The applicant defines the safety goals, decomposes them into safety functions, allocates those functions to structures, systems, and components, and demonstrates that the allocation achieves the goals. This is exactly the structure of a well-formed MBSE program — and it requires exactly the kind of requirements formalism and traceability that the industry largely abandoned.
For experienced aerospace or defense systems engineers, this looks familiar: it resembles the relationship between a customer’s Statement of Requirements, a contractor’s System Requirements Document, and the verification matrix that closes the loop. For nuclear engineers trained on existing plant operations, it is a genuinely new discipline.
The NRC’s pre-application engagement process — which TerraPower, X-energy, and Kairos have all used extensively — is also more structured than its predecessor. Topical reports on specific technical topics, white papers on licensing approaches, and public meetings that generate formal question-and-answer records all create a documented regulatory history that must remain consistent with the eventual license application. Maintaining that consistency requires the same traceability infrastructure as requirements management: you need to know what you told the regulator, when, and how your current design relates to that commitment.
Teams that are managing this through document repositories and spreadsheet traceability matrices are already finding the limits of that approach. The volume of regulatory correspondence alone, across a multi-year pre-application engagement, generates traceability requirements that exceed what manual document management can reliably support.
Fusion Is a Different Problem with the Same SE Challenge
The fusion programs currently in development — Commonwealth Fusion Systems, TAE Technologies, Helion, and others — face a variant of the same challenge. Their regulatory situation is different: fusion devices have historically been regulated by the NRC only if they produce significant quantities of tritium, and a new regulatory framework is still being developed. But the SE challenge of turning a physics demonstration into an engineered system, with defined safety functions and licensable requirements, is identical in structure.
Commonwealth Fusion’s SPARC device and the subsequent ARC commercial reactor concept represent perhaps the most aggressive timeline in the sector. Their engineering teams have been clear that the path from “we demonstrated net energy gain” to “we have a licensable power plant” requires building systems engineering infrastructure that simply does not exist in the fusion research community. The physics expertise is there. The SE practice is not, and it must be built.
This is not a criticism of fusion researchers. It reflects the difference between science and engineering, and between engineering and systems engineering. Fusion programs are now hiring systems engineers from aerospace and defense backgrounds specifically because those engineers bring the decomposition, allocation, and verification discipline that physics-trained teams do not develop organically.
What Modern Tooling Needs to Provide
The tools question matters more in this context than it might appear. Nuclear and fusion development programs are not like aerospace programs in one important respect: they are generally smaller, faster-moving, and less able to absorb the overhead of enterprise SE tools designed for programs with thousands of engineers and decade-long development cycles.
IBM DOORS and DOORS Next have deep nuclear sector penetration, primarily through legacy plant programs. They provide robust change management and have well-understood regulatory acceptance. They are also architecturally document-centric in ways that create friction for teams trying to work in a genuinely model-based mode. Jama Connect and Polarion offer more modern interfaces and better support for iterative development workflows, but neither was designed for the specific demands of nuclear licensing — where traceability to regulatory commitments is as important as traceability to technical requirements.
Tools like Flow Engineering, built on a graph-based model rather than a document hierarchy, are finding traction in advanced reactor programs precisely because the graph model maps naturally onto the structure of a Part 53 safety case: safety goals as top-level nodes, safety functions as decomposition layers, SSC allocations as leaf nodes, and regulatory commitments as relationships that cut across the hierarchy. The ability to query that structure — to ask “what regulatory commitments does this design change affect?” or “which safety functions are allocated to this system?” — is operationally valuable in a way that document-centric tools cannot replicate without significant manual overhead.
Flow Engineering’s intentional focus on requirements and traceability, without attempting to be an enterprise PLM or configuration management system, makes it appropriate for the stage of development where these programs currently are. When Kairos or X-energy move into detailed design and manufacturing, their tooling ecosystem will need to expand — but the requirements and traceability foundation built in early development will determine how navigable that expansion is.
The Honest Assessment
The nuclear engineering comeback is real, but it is also fragile. The programs currently in development are genuinely ambitious — novel technologies, new regulatory pathways, compressed timelines, and a workforce being assembled from aerospace, defense, and the thin residue of nuclear design experience that survived the long gap.
The systems engineering discipline being built at TerraPower, X-energy, Kairos Power, and their peers is more rigorous than what the industry had in its previous construction era. That is not a low bar to clear, but clearing it matters: the NRC’s licensing process, particularly under Part 53, will surface requirements formalism failures during pre-application engagement rather than after a license application is filed. Getting the SE infrastructure right early is less about regulatory compliance and more about engineering integrity — knowing that your design actually achieves its safety functions, that your requirements are complete and traceable, and that your regulatory commitments are consistent with your current design.
The aerospace and defense lessons being imported are the right ones. The tools being adopted — graph-based, AI-assisted, built for traceability rather than documentation — are more appropriate than their predecessors. The workforce being built, drawing on multiple engineering disciplines, is more diverse in its SE experience than the nuclear workforce of the 1970s.
Whether that is sufficient to close a thirty-year gap in institutional knowledge, on timelines measured in years rather than decades, is the real question. The engineering work being done now suggests that the industry understands what it lost. Whether it can rebuild it fast enough is something only the construction records of the next decade will answer.