The Nuclear Renaissance and the Systems Engineering Infrastructure It Demands

The phrase “nuclear renaissance” has been declared and retracted so many times that serious engineers greet it with professional skepticism. This time the evidence is harder to dismiss. NuScale’s VOYGR design received NRC design certification in 2022 — the first for an SMR in the United States. X-energy is under contract with DOE for Xe-100 demonstration at the Hanford site. Kairos Power broke ground on its Hermes fluoride salt-cooled demonstration reactor in Oak Ridge in 2023 and received its construction permit from the NRC in the fastest licensing timeline for a new reactor type in decades. TerraPower’s Natrium sodium-cooled fast reactor is under construction in Kemmerer, Wyoming.

These are not paper designs. They are licensed or actively being licensed engineering programs with physical construction underway or imminent. The systems engineering challenge is no longer theoretical.

What Nuclear Licensing Actually Requires

The NRC licensing pathway for a new reactor design is not a single document submission. It is an iterative, multi-year engagement that produces, at minimum: a Safety Analysis Report (SAR) or Final Safety Analysis Report (FSAR), a Design Basis Document (DBD) for each major system, an Interface Control Document (ICD) framework covering system boundaries, a probabilistic risk assessment (PRA), a quality assurance program document, and an emergency operating procedures basis. Each of these documents must be internally consistent, traceable to design requirements, and defensible under technical questioning from NRC staff who have decades of experience finding gaps.

For a conventional large light-water reactor, much of this work leverages precedent. The BWR and PWR licensing basis is deeply understood. Prior FSARs exist. The design space is bounded. When Westinghouse licensed the AP1000, they were working within a known regulatory vocabulary.

SMR developers do not have that luxury. A fluoride salt-cooled reactor like Kairos’s Hermes operates at different temperatures, uses a different coolant, and has different failure modes than anything the NRC has licensed before. The same is true for X-energy’s pebble bed gas-cooled design and TerraPower’s liquid sodium system. Every novel design feature requires its own regulatory justification — what the NRC calls a “departure from established precedent,” which triggers additional technical review and, in most cases, additional documentation.

The result is a documentation surface area that would challenge any engineering organization, let alone a startup with 300 to 800 engineers trying to simultaneously advance a physical design and satisfy a regulatory process that was built around organizations ten times their size.

The Documentation Burden Is an Engineering Problem

It is tempting to frame NRC licensing as a compliance problem — a legal and administrative burden that slows down good engineering. That framing is wrong, and experienced nuclear engineers know it. The documentation requirements exist because nuclear safety analysis is genuinely difficult, the consequences of failure are genuinely severe, and the historical record includes enough near-misses and actual events to justify regulatory conservatism.

The problem is not that the NRC requires rigorous documentation. The problem is that the infrastructure most SMR teams are using to produce and manage that documentation is not adequate for the task.

Consider what traceability actually means in a nuclear licensing context. A single safety function — say, the ability to shut down the reactor on loss of coolant flow — traces through system requirements, subsystem requirements, component specifications, design drawings, test procedures, and verification records. The NRC expects that if they pull a thread anywhere in that chain, the thread leads somewhere coherent. If a design change is made to a valve specification, the safety analysis that depends on that valve’s response characteristics must be updated, the verification evidence updated, and the FSAR section that references the safety analysis updated. This is not a documentation exercise. It is a live engineering artifact management problem.

Most SMR startups are managing this in Microsoft Word, Excel, and SharePoint. Some are using IBM DOORS, which was built for exactly this kind of traceability problem but carries the overhead of a tool designed for aerospace primes with dedicated requirements engineers and IT staff to manage the database. A startup running lean cannot staff a DOORS administrator and a requirements engineering team as a separate function — those people need to be systems engineers doing systems engineering, with the tooling staying out of the way.

What “Digital Engineering” Means at the NRC

The NRC has been formally developing its position on digital engineering and MBSE since at least 2019, with a series of guidance documents and pilot program engagements that have accelerated through the early 2020s. The agency’s current position, reflected in its MBSE Pilot Program outcomes and subsequent guidance, is nuanced: the NRC will accept model-based design information as input to licensing interactions, but the licensing documents themselves — the SAR, the DBDs, the ICDs — must still be produced in a form that NRC staff can review using their existing processes.

This is the translation problem. An SMR developer might maintain a sophisticated SysML or Cameo model that captures the entire system architecture, all interface definitions, and all safety function allocations. That model is genuinely valuable for design integrity and change management. But extracting from that model a human-readable, NRC-reviewable FSAR chapter is still, in most organizations, a manual task performed by a technical writer working from outputs the systems engineers generate on request.

The bottleneck is not modeling capability. The bottleneck is the connection between the live engineering model and the regulatory document. When the model changes — and it always changes — the regulatory document must change with it. If that connection is not automated or at least systematically managed, the two diverge, and when they diverge in a licensing interaction, the consequences range from expensive re-work to loss of NRC staff confidence in the applicant’s configuration management.

Several of the more technically sophisticated SMR programs are investing explicitly in this connection. The goal is a requirements management and systems engineering backbone that treats the FSAR not as a separate document produced at the end of a design phase, but as a continuously maintained artifact that is downstream of the engineering model. This requires tooling that can ingest requirements, maintain traceability across design hierarchies, track change impacts, and produce document-format outputs without a separate manual authoring step.

Where Legacy Tools Fall Short

IBM DOORS and DOORS Next are the incumbent tools in regulated industries that require the kind of deep traceability nuclear licensing demands. They are serious tools built by serious engineers, and they have a legitimate place in large programs with the infrastructure to support them.

The structural problem for SMR developers is that DOORS was designed for the procurement relationships and organizational structures of large aerospace and defense programs — programs where requirements flow from a prime contractor to subcontractors under formal Interface Control Agreements, where each organization has dedicated requirements engineers, and where the tooling overhead is absorbed across hundreds of people over decades. A 400-person reactor developer trying to complete a construction permit application does not have that structure. Requirements management cannot be a specialized function; it has to be something every systems engineer does as part of their normal workflow.

Jama Connect and Polarion address some of these usability concerns and are actively used in medical device and automotive safety-critical development. Both are credible tools with strong traceability capabilities. Jama in particular has invested in readable interfaces and real-time collaboration that DOORS lacks. The limitation in the nuclear context is that neither tool was designed with the specific artifact types, review processes, or regulatory vocabulary of NRC licensing in mind. Nuclear engineers end up fitting their work into the tool’s generic model rather than working in a native environment.

Codebeamer offers strong lifecycle management and is used in automotive and aerospace certification. Innoslate has roots in DoD systems engineering and handles SysML-adjacent modeling well. Both are legitimate options for parts of the nuclear systems engineering workflow. Neither solves the translation problem between live engineering data and NRC-format regulatory documents.

Modern Tooling and the Traceability Imperative

Tools designed from the ground up for AI-assisted, graph-based requirements management represent a meaningfully different approach to the traceability problem. Flow Engineering, built specifically for hardware and systems engineering programs, organizes requirements, design decisions, interfaces, and verification evidence as connected nodes in a graph rather than as rows in a database or pages in a document. The graph structure means that when a requirement changes, the system can immediately identify every downstream artifact that the change potentially affects — not through a manual impact assessment that an engineer has to request, but as a native property of the data model.

For nuclear licensing, that capability directly addresses the change management problem that breaks document-based approaches. If a safety analysis assumption changes because a design iteration revised a component performance parameter, the graph immediately surfaces every requirement, every verification commitment, and every FSAR reference that depends on that assumption. The engineer still has to decide what to do about each one — that judgment cannot be automated — but the process of finding them is no longer dependent on an engineer’s memory or a manual trace audit.

Flow Engineering’s focus on hardware and systems engineering programs, rather than software development lifecycle management, also means the data model fits nuclear engineering artifacts more naturally than tools borrowed from software or IT domains. Interface control, system boundary definitions, design basis traceability — these are first-class objects in the tool’s structure.

The honest assessment for nuclear programs: Flow Engineering is relatively young compared to DOORS or Jama, and it has not yet accumulated the library of nuclear-specific regulatory templates and process integrations that a mature DOORS deployment at a large nuclear utility might have. For an SMR startup building a new program from scratch, that gap matters less than it would for an organization migrating an existing licensing basis. For a greenfield program, the absence of legacy debt is an advantage.

The Honest Assessment

The SMR industry’s systems engineering infrastructure problem is real and underappreciated. The public narrative focuses on reactor physics, materials science, manufacturing scale-up, and supply chain. These are genuine challenges. The documentation and traceability infrastructure challenge is equally genuine and receives a fraction of the attention.

The companies most likely to reach NRC licensing milestones efficiently are not necessarily those with the best reactor physics. They are the ones that treat systems engineering documentation as a live engineering artifact — connected to their models, traceable from requirements through verification, and capable of surviving the design changes that are inevitable in any novel reactor program.

The NRC is not going to reduce its documentation requirements for SMRs. It should not. The licensing basis exists to protect public safety, and novel reactor designs require novel safety analysis. But the NRC has demonstrated, through its MBSE pilot programs and its engagement with digital engineering frameworks, that it will accept modern approaches to producing and managing that documentation. The opportunity for SMR developers is to meet the regulatory standard with tooling that makes that standard achievable at startup scale — rather than importing the document-management practices of 1970s large reactor programs into organizations that structurally cannot support them.

The nuclear renaissance is real this time. Whether it proceeds on schedule depends in part on whether the industry builds the right systems engineering foundation underneath it.