The Nuclear Renaissance and Its Requirements Challenge

Small Modular Reactors Face a Familiar Problem

In 2023, NuScale Power became the first SMR developer to receive NRC design approval — and then, less than a year later, watched its flagship Carbon Free Power Project collapse when projected costs made the economics unworkable. The approval itself was a genuine engineering and regulatory achievement. The collapse had nothing to do with the reactor and everything to do with the world the reactor was trying to enter.

The SMR industry has not been deterred. X-energy is advancing its Xe-100 pebble bed design under a Department of Energy cost-share agreement. Terrestrial Energy is pursuing licensing for its Integral Molten Salt Reactor in both the United States and Canada. Kairos Power broke ground on a fluoride salt-cooled demonstration reactor in Tennessee. Last Energy, Oklo, and a dozen other developers are at various stages of NRC engagement. The pipeline is real, and for the first time in decades, it feels like the nuclear industry is moving rather than waiting.

But every one of these programs runs into the same wall: demonstrating, to a regulator’s satisfaction, that a novel reactor design meets safety requirements written for reactors that don’t look anything like theirs.

What the Regulatory Framework Actually Requires

The NRC’s regulatory framework for nuclear power plants is built on several interlocking layers. 10 CFR Part 50 establishes the licensing basis — the set of requirements a design must meet to receive a construction permit and operating license. Appendix A to Part 50 contains the General Design Criteria, which define the functional safety requirements that nuclear power plants must satisfy: reactivity control, residual heat removal, emergency core cooling, containment, and so on.

Regulatory Guide 1.168 addresses verification and validation of software used in safety systems, but its scope reflects a broader principle: that safety functions must be traceable from high-level requirement to implementation to verification evidence. For hardware-heavy safety systems, the equivalent traceability burden is addressed through a combination of design basis documentation, safety analysis reports, and the Final Safety Analysis Report (FSAR) that forms the core of a license application.

IEEE 603 defines the criteria for safety systems in nuclear power generating stations. It specifies requirements for independence, redundancy, single-failure criteria, and testability — requirements that were developed with active safety systems in mind. Active systems use pumps, valves, and motors that require external power and operator action. You can test them by running them. You can demonstrate their function by actuating them. The regulatory framework knows how to talk about active systems because active systems are what existed when the framework was written.

Passive safety systems are different. They rely on physical phenomena — gravity, natural circulation of coolant, stored thermal or chemical energy — that operate without external power or active operator intervention. NuScale’s reactor module sits submerged in a pool of water; in an emergency, decay heat is removed by natural circulation to that pool, which then evaporates to atmosphere. No pumps required. No active intervention required. The system works as long as water is present and the laws of thermodynamics continue to apply.

This is genuinely safer in important ways. It is also genuinely harder to license under a framework that asks whether your safety system has the required redundancy, independence, and single-failure tolerance — because those concepts translate awkwardly to phenomena that don’t have actuators you can fail individually.

The Interpretive Burden on SMR Developers

When an SMR developer submits a license application, they are not just demonstrating compliance with existing requirements. They are constructing an argument — a detailed, technically rigorous argument — about how their novel design satisfies the intent of requirements that weren’t written with their design in mind.

This interpretive burden has several specific manifestations.

Passive system qualification. IEEE 603’s single-failure criterion requires that a safety system must be capable of performing its function with any single active failure present. For passive systems, developers must argue either that passive systems are not subject to this criterion (because they have no active components to fail) or that they satisfy an analogous criterion under a different analytical framework. The NRC has engaged with this question on a case-by-case basis, but there is no settled regulatory position that developers can simply cite.

Probabilistic Risk Assessment integration. Modern SMR licensing increasingly relies on PRA — probabilistic risk assessment — to demonstrate that a design achieves acceptable safety levels even when it departs from deterministic regulatory requirements. But PRA models for passive systems are genuinely difficult to build. Passive system reliability depends on thermal-hydraulic phenomena whose failure modes are not characterized in the same component-level databases that support active system PRA. Developers must construct phenomenological models, validate them against experimental data, and defend them against NRC staff review — all while the regulatory guidance on how PRA evidence should be weighted against deterministic requirements is still being developed.

Design basis event coverage. 10 CFR Part 50 Appendix A defines the design basis events a reactor must be able to withstand: loss of coolant accidents, loss of offsite power, main steam line breaks, and dozens of others. For a conventional light water reactor, the mapping from design basis event to required safety function to safety system is well-established. For an SMR with integral primary systems, factory fabrication, and passive cooling, that mapping must be reconstructed. Events that are physically impossible for a given design (a large-break LOCA in a reactor with no large coolant pipes, for example) still require explicit treatment — typically an argument that the event is not credible for the design, supported by analysis.

Software and I&C qualification. Modern SMR designs use digital instrumentation and control systems. RG 1.168 and its companion guides establish V&V requirements for safety-related software that are demanding under any circumstances. When the safety system the software controls is itself a novel design, the qualification burden compounds: you are qualifying software to control a system whose behavior must itself be argued, not simply tested against established performance curves.

The Requirements Management Dimension

None of these challenges are purely technical. They are also, in a very practical sense, requirements management challenges.

A license application for a nuclear power plant is one of the most complex technical documents that exists. The FSAR for a large light water reactor runs to tens of thousands of pages. An SMR FSAR is smaller, but the interpretive complexity is higher — more arguments to construct, more novel territory to cover, more places where the standard answer doesn’t apply and a custom answer must be developed and defended.

The requirements that an SMR must satisfy form a complex, interconnected graph. A single General Design Criterion — say, GDC 34, which requires that residual heat can be removed following anticipated operational occurrences — spawns derived requirements that flow down through the safety analysis, through the passive cooling system design, through the instrumentation that monitors system status, through the procedures that operators follow, through the tests that will be performed before startup. Change the design of the cooling pool and you may affect the thermal-hydraulic analysis that supports the passive cooling argument that supports the GDC 34 compliance claim. You need to know that. You need to know it before you submit, not during the NRC’s review.

In practice, many nuclear engineering programs manage this complexity with a combination of spreadsheet-based requirements traceability matrices, legacy document management systems, and human expertise accumulated over years on a program. This works, in the sense that programs do eventually get licensed. It works badly, in the sense that it makes change enormously expensive, review cycles slow, and the detection of traceability gaps dependent on individual human knowledge rather than systemic visibility.

The problem is not new. The nuclear industry has been running large-scale hardware programs with complex regulatory requirements for sixty years, and it has been managing requirements with inadequate tools for most of that time. What is new is the pace and variety of SMR programs, the relative inexperience of some developer organizations, and the fact that several of these companies are fundamentally technology startups — organizations that have built cultures around iteration and speed, and are now colliding with a regulatory process that moves on geological timescales.

What Modern Tools Can Actually Do

The nuclear industry has been slow to adopt modern systems engineering tooling, for reasons that are partly cultural, partly practical (regulatory bodies have views about what constitutes an acceptable requirements baseline), and partly because the dominant tools — IBM DOORS, DOORS Next, Jama Connect, Polarion — were designed to manage requirements at scale in document-centric environments. They do that adequately. They do not naturally support the kind of live, graph-based traceability that makes a complex nuclear program navigable.

The operational problem is not storing requirements. It’s answering questions like: if I change this design parameter, what safety arguments are affected? Which regulatory requirements are currently covered only by a single analysis? Where are the gaps in my verification evidence? Document-centric tools answer these questions badly, because the relationships between requirements, design features, analyses, and evidence are implicit in documents rather than explicit in a model.

Tools that represent requirements as a connected graph — where the relationships between requirements, derived requirements, design features, verification methods, and evidence are first-class objects — make these questions answerable systematically rather than through manual review. Flow Engineering has built specifically for this kind of connected traceability in hardware and systems engineering contexts, with an architecture that maintains relationships as the design evolves rather than treating the requirements trace as something you update periodically when someone has time. For an SMR program working through a multi-year NRC review where design changes propagate through hundreds of interconnected safety arguments, that kind of live traceability is not a nice-to-have. It is the difference between understanding your compliance posture and guessing at it.

The nuclear industry’s standards bodies are beginning to acknowledge this. NUREG/CR-6901 and related guidance documents on software-intensive systems engineering for nuclear applications have moved toward model-based language, though implementation guidance remains sparse. The NRC’s own Advanced Reactor Program has made noises about accepting model-based safety cases as an alternative to traditional FSAR structure — a change that would be significant if it materializes.

An Honest Assessment

The SMR wave is real, and the engineering being done by the leading developers is serious. These are not vaporware projects. NuScale’s design approval, whatever happened to the business case afterward, demonstrated that novel reactor designs can navigate the NRC process to a successful technical conclusion. Kairos Power’s construction permit for its Hermes demonstration reactor, issued in 2023, demonstrated it again for a fluoride salt-cooled design.

But the requirements challenge is not solved, and the tools and practices that most nuclear programs use to manage it are not adequate to the complexity they face. The programs that are moving fastest are those that treat requirements management as an engineering function — staffed by engineers who understand both the technical content and the regulatory framework — rather than a documentation function delegated to a compliance team after the engineering is done.

The passive safety licensing question will get answered, iteratively, through the dialogue between developers and the NRC. The physics is not in dispute. The regulatory translation of that physics is still being worked out, and the programs that document that translation with sufficient rigor and traceability will be the ones that get through review without the extended back-and-forth that has plagued previous advanced reactor applications.

There is no version of this problem where the requirements work is easy. The question is whether it’s hard and visible — where gaps are found before they become NRC questions — or hard and opaque, where they aren’t.