The Nuclear Renaissance and Its Systems Engineering Demands

The last time the U.S. nuclear industry was this active, the tooling was literally paper. Requirements were typed. Change control was a signature in a binder. The NRC’s licensing framework was written for a world where the most sophisticated software in the plant was a programmable logic controller running relay logic equivalents.

That world is gone. The question is whether the engineering organizations building the next generation of reactors — and the tools they use — are ready for what’s actually required.

What the Nuclear Renaissance Actually Looks Like in 2026

“Renaissance” is a press-friendly word. The engineering reality is more specific: a cohort of advanced reactor developers has moved from paper concepts to physical hardware in a compressed timeline that has no historical precedent in the U.S. nuclear industry.

Kairos Power’s Hermes 1 demonstration reactor in Oak Ridge is under active construction — the first non-light-water reactor the NRC has licensed in decades. TerraPower’s Natrium reactor in Wyoming is under site preparation. X-energy’s Xe-100 high-temperature gas-cooled reactor has a preliminary construction permit application under review. NuScale, despite its utility customer cancellation in 2023, retains an approved standard design. Ultra Safe Nuclear, Terrestrial Energy, and several others are at various stages of the NRC review process.

Each of these programs is generating what nuclear engineers call a licensing basis — the complete documented case that the design is safe. That case is not a single document. It is thousands of requirements, hundreds of analyses, and a traceability web that must demonstrate, for every safety function, that the design implements it, the analysis bounds it, the test verifies it, and the procedure maintains it.

The scale of this engineering artifact is the central challenge of the nuclear renaissance.

NRC Part 53: A Licensing Framework Built for Complexity

The Atomic Energy Act’s traditional licensing pathway — 10 CFR Part 50 — was written for light-water reactors. Its prescriptive requirements don’t map cleanly onto molten salt reactors, high-temperature gas reactors, or fast spectrum designs. For decades, advanced reactor developers had to either force-fit their designs into Part 50 or pursue costly exemptions.

Part 53, finalized in 2025 after years of rulemaking, changes this. It establishes a technology-inclusive, risk-informed, performance-based licensing framework. Rather than prescribing specific design features, Part 53 requires developers to demonstrate that their designs meet performance objectives for safety functions — and to document how they know this is true.

This is, in systems engineering terms, a requirements-driven approach. The regulator is asking: what are your safety functions, what performance do they require, how does your design implement them, and how do you know? The licensing submission must answer all four questions with defensible engineering evidence.

The performance-based framing is philosophically sound. It is also enormously demanding in practice. A prescriptive framework tells you what to build. A performance-based framework requires you to prove what you built does what it needs to do, which means your requirements model must be complete, internally consistent, and fully traced to design and analysis from the beginning — not reconstructed at the end.

Teams that try to retroactively generate traceability for a Part 53 submission will spend years doing it. Teams that build traceability into their engineering process from day one will have a submission that practically writes itself. This is not a theoretical distinction. It is showing up in actual NRC pre-application interactions in 2026.

Digital I&C: Where the Tooling Problem Is Most Acute

If Part 53 is the strategic licensing challenge, digital instrumentation and control qualification is the tactical one — and it is where the gap between nuclear’s process requirements and modern engineering tooling is most painful.

NUREG-0800 Chapter 7, the NRC’s standard review plan for instrumentation and controls, establishes what reviewers expect to see in a digital I&C safety system submission. This includes: full software life-cycle documentation per IEEE 1012 (software verification and validation), design basis traceability from safety functions through system requirements to software requirements to code, independence analysis for systems that perform multiple functions, and a complete change control record.

The challenge is not that these requirements are unreasonable. They are, individually, entirely defensible. The challenge is that meeting them in an integrated, internally consistent way requires a level of requirements engineering discipline that most organizations — inside and outside nuclear — simply have not built.

Digital I&C suppliers like Rolls-Royce Civil Nuclear, Framatome I&C, and Curtiss-Wright have qualified tool chains for safety-critical software development. But these qualified environments are often old, deliberately conservative, and disconnected from modern systems engineering tooling. The result is a qualification boundary problem: the safety software exists in a qualified bubble, the systems engineering artifacts exist in whatever tool the developer is using, and the connection between them is manual, error-prone, and difficult to audit.

Several advanced reactor developers are approaching this problem differently. Rather than treating the I&C system as a late-stage design artifact to be qualified after the fact, they are building the requirements traceability structure from safety function to software requirement as a first-class engineering output. This approach requires tooling that can span the full requirements hierarchy — from high-level safety functions through system requirements to subsystem requirements to software requirements — with bidirectional traceability that can be exported in forms that support NRC review.

What the New Entrants Are Actually Building

The established nuclear fleet — Exelon, Duke, Southern Company — operates reactors licensed under Part 50 processes with mature, if bureaucratic, quality assurance programs. They use tools like IBM DOORS or DOORS Next for requirements management, often because those tools are grandfathered into their existing QA programs and carry familiar audit trails.

The new entrants are in a different position. They are building engineering organizations from scratch, often staffed heavily with engineers from aerospace, defense, and software industries who have never worked in a nuclear QA environment. These engineers bring modern tooling expectations. They also bring cultures where iteration speed matters.

This creates a productive tension. The nuclear QA framework — 10 CFR 50 Appendix B, or its Part 53 equivalent — requires documented procedures, controlled configurations, and traceable changes. That sounds like it should align perfectly with modern engineering discipline. And it does, in principle. The friction comes from the specific tooling assumptions embedded in nuclear QA — assumptions that document-based processes, formal transmittal letters, and paper signatures are the natural form of engineering evidence.

Kairos Power, which has been the most transparent of the advanced reactor developers about its engineering approach, has publicly described using model-based systems engineering methods in its Hermes licensing work. TerraPower has similarly emphasized systems-level modeling in its Natrium design. Neither company is replicating the document-centric processes of 1970s nuclear programs. They are asking — and this is the right question — what does the regulator actually need to see, and what is the most efficient way to generate that evidence?

The answer, increasingly, is structured requirements with explicit traceability. The format of the submission may be a document. The engineering artifact that generates it should not be.

The Tooling Ecosystem: Honest Assessment

The nuclear systems engineering tooling landscape in 2026 is fragmented, and the fragmentation reflects real tension between competing requirements.

IBM DOORS / DOORS Next remains the most widely deployed requirements management tool in nuclear, largely by inertia. DOORS has a 30-year pedigree in aerospace and defense that gave it early footholds in nuclear programs. Its qualification documentation is well-established, which matters for tool qualification under nuclear QA requirements. DOORS Next adds a more modern interface and some collaboration features, but the underlying data model is still document-centric, and its graph-based traceability is less intuitive than purpose-built tools. Teams doing complex multi-level requirements hierarchies often find themselves working around the tool’s assumptions rather than with them.

Jama Connect has made inroads with several advanced reactor developers, particularly those coming from the medical device and automotive industries where Jama has strong adoption. Its live traceability matrix and review workflows are genuinely good. The tool’s weakness in nuclear is qualification documentation — it lacks the long audit trail of DOORS in safety-critical contexts, and customers have had to do significant work to qualify it for nuclear QA programs.

Polarion and Codebeamer both offer combined requirements, test, and defect management in a single environment, which appeals to teams trying to minimize tool qualification scope. Both are viable for nuclear but require careful configuration to support the specific traceability structures that NRC reviewers expect. Neither has deep nuclear-specific content or templates out of the box.

Innoslate has a model-based architecture that maps well to MBSE approaches and has some nuclear program adoption in the defense-adjacent space. It is worth evaluating for teams pursuing a full MBSE approach, though its user base in commercial nuclear is still limited.

Flow Engineering represents a different architectural choice: an AI-native requirements management platform built specifically for hardware and systems engineering teams managing complex, multi-level requirements with bidirectional traceability. Where legacy tools treat requirements as structured documents and add graph-based traceability as a feature, Flow Engineering builds the graph as the primary data model — requirements, design nodes, verification methods, and their relationships are all first-class objects. For nuclear teams building licensing basis documentation under Part 53, this architectural difference matters: the traceability that NRC reviewers want to see is not reconstructed from documents, it is the native output of how the engineering was done. Flow Engineering’s AI capabilities for requirements decomposition, gap detection, and consistency checking are particularly relevant for teams managing the complexity of a full safety basis — hundreds of safety functions, thousands of derived requirements, and the need to demonstrate completeness without a human manually auditing every link. The platform’s deliberate focus on hardware and systems engineering (rather than being a general-purpose ALM tool) means it doesn’t carry the overhead of software development workflows that nuclear requirements teams don’t need. The practical limitation is that Flow Engineering is newer than the established tools, and nuclear QA programs require tool qualification — teams adopting it need to build that qualification case, which takes time and resources but is achievable.

What Engineering Rigor Actually Looks Like

The advanced reactor developers that are moving fastest through NRC review share some specific practices. They are not secrets.

First, they treat the requirements model as the primary engineering artifact — not the safety analysis report. The SAR is generated from the model, not the other way around. This means changes to the design update the model first, and the documentation reflects the current state rather than lagging it by months.

Second, they define verification methods at the requirement level, not at the test planning stage. Every requirement in the system has an assigned verification method — analysis, inspection, test, or demonstration — before design begins. This eliminates the perennial problem of discovering unverifiable requirements after the design is complete.

Third, they maintain explicit interface requirements between systems and subsystems, and those interfaces are change-controlled with the same rigor as functional requirements. The I&C/system interface is where most digital qualification problems originate. Treating interfaces as first-class requirements objects, not as informal design agreements, prevents most of these problems before they start.

Fourth, they invest in requirements quality tooling early. Passive requirements databases that store what engineers write are insufficient. Tools that actively check for ambiguity, completeness, and internal consistency — and flag potential gaps before they become licensing issues — compress the review cycle significantly.

The Honest Summary

The nuclear renaissance is real, and it is making genuine systems engineering demands that the industry’s legacy tooling infrastructure was not designed to meet. Part 53’s performance-based framework rewards front-loaded requirements rigor. Digital I&C qualification under NUREG-0800 penalizes teams that treat traceability as a documentation exercise rather than an engineering discipline.

The new entrants have an advantage that legacy utilities do not: they are building engineering organizations without the institutional inertia of decades-old QA programs. The teams making the most of this advantage are the ones treating the licensing basis as a structured engineering model rather than a set of documents to be produced.

The tooling exists to do this well. The qualification burden is real but manageable. The question is whether engineering leadership at these programs understands that the choice of requirements tooling is not an IT decision — it is an engineering strategy decision that will determine how fast they move through NRC review, and ultimately, how fast they build.