NuScale Power: The SMR That Went Through NRC Design Certification
What the first SMR to receive NRC design approval reveals about requirements management at nuclear scale
In August 2020, the U.S. Nuclear Regulatory Commission completed its Final Safety Evaluation Report for NuScale Power’s small modular reactor design — the first SMR in U.S. history to clear that threshold. The certification rule itself was published in the Federal Register in January 2023. By any measure, this was a landmark technical achievement. It was also an exhausting, expensive, and structurally revealing demonstration of what it takes to manage requirements at nuclear scale.
NuScale eventually shelved the first deployment project — the Carbon Free Power Project in Idaho — in November 2023, citing rising cost estimates and insufficient utility subscriptions. That commercial setback does not diminish the engineering record. The NRC docket for NuScale’s Design Certification Application (DCA) is public, detailed, and instructive. For any advanced reactor company now navigating the NRC process, it is the closest thing available to a worked example.
This article examines what NuScale actually had to do — not at the physics level, but at the requirements, documentation, and design-control level — and what that experience implies for the companies now in queue behind them.
Current State: What the NRC Design Certification Process Demands
Design Certification under 10 CFR Part 52 is distinct from a combined construction and operating license. It certifies a standard nuclear plant design independent of any specific site. An applicant submits a Design Control Document (DCD) — a structured technical specification that becomes the legal reference design if the rule is finalized. Anyone who later wants to build that design references the DCD rather than repeating the full safety review.
The NuScale DCD, as submitted and revised across its review lifecycle, ran to thousands of pages across multiple chapters covering reactor design, accident analysis, instrumentation and control, human factors, and more. The NRC review process — called a Safety Evaluation — involves agency staff issuing Requests for Additional Information (RAIs). NuScale’s docket shows hundreds of RAI rounds across multiple review phases. Each RAI typically required a formal written response that either answered the question, committed to a DCD revision, or both.
The documentation load this creates is not incidental. It is the process. The NRC’s job is to verify, with formal written evidence, that every safety-significant claim in the DCD is supported by analysis, that every analysis is based on defensible methods, and that every method has been validated. The applicant’s job is to maintain a version-controlled, internally consistent technical package while simultaneously answering questions about it, revising it, and managing the downstream effects of every revision.
What NuScale’s Process Actually Revealed
The passive safety architecture raised novel traceability questions
NuScale’s design eliminates active cooling systems in favor of passive safety — the reactor sits in a pool of water and relies on natural circulation for decay heat removal. This is the core innovation. It is also, from an NRC review standpoint, a source of novelty that the existing regulatory framework was not fully calibrated for.
When a design departs from the LWR precedent that underlies most NRC guidance, the applicant cannot simply point to existing approved analyses. They must establish the analytical basis from the ground up, which means the requirements traceability chain is longer at every node. A functional requirement like “remove decay heat following loss of coolant accident” maps to a safety system, which maps to specific thermal-hydraulic behavior, which must be demonstrated by analysis using validated codes. For novel passive systems, code validation becomes its own documentation campaign — one that must be linked, traceably, back to the original functional requirement.
NuScale’s docket reflects this. The FSER’s thermal-hydraulic and accident analysis chapters are extensive, and the RAI history shows the NRC pushing repeatedly on the adequacy of the analysis methods and their applicability to a design without precedent. The lesson is direct: novel safety systems compress your schedule at the back end, not the front. The work of establishing the traceability chain for novel functional requirements is almost always underestimated at program initiation.
Design changes propagate — and the documentation must follow
The NuScale design changed materially during the review. The most visible change was a power uprate: the original design was rated at 50 MWe per module; NuScale subsequently pursued a 77 MWe-per-module uprate (the VOYGR-12 configuration). This required a new or substantially revised safety analysis for affected chapters — and, crucially, required demonstrating that all previously satisfied requirements still held under the new design parameters.
From a requirements management standpoint, this is the scenario that breaks document-based systems. When requirements are managed as text in chapter files, a design change triggers a manual hunt for every requirement that might be affected. The hunt is never complete. Engineers know this, and they compensate by being conservative — but conservatism in documentation takes the form of added pages, added qualification language, and added review cycles, all of which add cost and calendar time.
NuScale’s uprate added years to the review schedule and required extensive supplemental filings. The NRC’s RAI activity on the uprated design was substantial. This is not a criticism of NuScale’s engineering — the underlying physics worked, and the design was certified. It is a structural observation about what happens when you change a design that is already in regulatory review, and why the architecture of your requirements management system matters as much as the content of your requirements.
The human factors engineering process is a model worth studying
One area where NuScale’s docket is particularly instructive is Human Factors Engineering (HFE). The NRC’s HFE review process under NUREG-0711 requires a structured, iterative process — task analysis, function allocation, interface design, procedure development, and integrated system validation — all of which must be documented in a form that supports traceability to the Human Factors Engineering Program Plan (HFEPP).
NuScale’s HFE documentation, and the RAI exchanges around it, show an applicant working through a genuinely rigorous iterative design process in a regulatory context. The NRC staff’s questions on HFE were detailed and technically substantive. What NuScale’s responses demonstrate is that defensible HFE documentation is not a summary of design decisions — it is a record of a process, including the alternatives considered and the rationale for each choice. That framing — requirements as the record of a reasoning process, not just a list of specifications — is worth internalizing well before a company begins its formal application.
What’s Actually Happening in the Advanced Reactor Pipeline
NuScale’s certification created a proof of concept, not a template. The companies now in various stages of NRC engagement — Kairos Power, TerraPower, X-energy, Oklo, and others — are pursuing designs that differ from NuScale’s in coolant type, fuel form, operational profile, and safety approach. Each faces its own version of the novel-analysis problem.
The NRC has been working to adapt its review framework through the ADVANCE Act and associated guidance development. The agency’s position on non-LWR technologies has evolved, and new review pathways like Part 53 are being developed specifically to accommodate advanced designs. But the fundamental requirement — traceable, auditable evidence that the design satisfies every applicable safety requirement — does not change with the regulatory pathway. The form of the evidence may vary; the standard of evidence does not.
What this means practically is that the documentation architecture decisions made at program initiation compound over time. A company that begins its pre-application engagement with the NRC using document-based requirements management will, by the time it reaches formal DCA submission, have accumulated a technical debt in requirements traceability that is extremely difficult to retire. The NuScale experience puts a rough cost on this: years of review schedule and hundreds of millions of dollars in engineering labor.
Practical Implications for Advanced Reactor Programs
Build the traceability model before the design matures
The NRC review process is fundamentally an audit of traceability. Every safety-significant claim must trace to analysis; every analysis must trace to an approved method; every method must trace to validation data; and all of it must trace back to the applicable regulatory requirement. A requirements management system that imposes this structure from day one — rather than reverse-engineering it for submission — is not a documentation overhead. It is a risk reduction tool.
Modern graph-based requirements platforms allow engineering teams to define relationships between requirements, design artifacts, analyses, and verification evidence as the work happens. When a design change occurs, the impact on downstream requirements and analyses is immediately visible. This is not a luxury feature; it is the structural difference between knowing and guessing which analyses need to be redone after a power uprate.
Tools like Flow Engineering, built on a connected graph model, reflect exactly this architectural principle — linking requirements to design decisions, analyses, and verification artifacts in a live model rather than a document archive. For a program facing NRC scrutiny, that connected model is the difference between a change management process and a change management crisis.
Treat RAIs as requirements signal, not compliance burden
The NRC’s RAI process is sometimes perceived as adversarial. Experienced nuclear engineers understand it differently: RAIs are the agency telling you, precisely and in writing, what evidence gap exists in your submission. Each RAI is a requirement — not one you wrote, but one you must satisfy.
Advanced reactor programs can use NuScale’s RAI history, which is publicly available on the NRC ADAMS system, to anticipate the questions the agency is likely to ask about novel passive systems, alternative fuels, non-LWR thermal-hydraulics, and other features common to Generation IV designs. That anticipation should feed directly into the requirements architecture: if you know the NRC will ask for specific analysis, that analysis should be a first-class requirement in your system, with traceability to the design feature it supports and the regulatory basis it satisfies.
Plan for the design to change
NuScale’s power uprate was driven by commercial pressure — higher power output improved the economics of a per-module design. Commercial pressure does not stop at design certification. Advanced reactor programs should assume their design will change during the review period and design their requirements management architecture to absorb change with minimum disruption to the traceability record.
This means investing in configuration management tooling early, establishing formal change impact assessment procedures before they are needed, and maintaining explicit bi-directional traceability so that any design change can be rapidly evaluated against the full set of requirements and analyses it might affect.
Honest Assessment
NuScale’s NRC design certification is a genuine engineering milestone. The company assembled a technical case for a novel reactor concept and took it through the most rigorous civilian safety review process in the world. The docket is a testament to the scale of that effort.
The commercial outcome is a separate question with its own causes. What the engineering record establishes is the floor — in terms of documentation rigor, traceability discipline, and requirements management maturity — for any advanced reactor program seeking NRC design certification.
The companies now in the pipeline are working with NRC staff who have now seen one SMR through a full design review. The agency’s institutional knowledge of what adequate documentation looks like has increased. That cuts both ways: reviewers who have worked a prior novel design review are faster to identify gaps, and they are also more willing to engage with truly novel technical approaches when the documentation is in order.
The lesson NuScale’s experience offers is not that the process is too hard. It is that the process rewards investment in requirements architecture and punishes improvisation. Programs that begin with a coherent model of how requirements connect to design, analysis, and verification — and that maintain that model through every design change — will find the NRC review process navigable. Programs that treat documentation as something produced after the engineering is done will find it nearly impossible.
That is not a new lesson. NuScale just made it the most expensive and public demonstration in the history of commercial nuclear energy.