Nuclear Energy’s Engineering Renaissance: How New Build Programs Are Modernizing Their Requirements Practices
The last time the United States built a commercial nuclear power plant from first concrete to operating license, the engineering team used binders. Thick ones. Room-sized archives of design basis documents, safety analysis reports, and interface control documents organized by tab dividers and updated by hand, with revision histories tracked in margins. That approach worked — eventually — but it produced plants that took fifteen years and billions of dollars over budget to license and construct.
The nuclear industry is now attempting to do this again, faster, with reactor designs that have never been built, under a regulatory framework that has grown substantially more complex since the 1970s, and with investor timelines that assume commercial operation within a decade of program launch. The gap between those ambitions and the documentation practices most nuclear organizations still rely on is where the modernization pressure is concentrated.
What Stayed the Same and What Changed
The regulatory foundation for commercial nuclear construction in the United States is the Nuclear Regulatory Commission’s dual licensing pathway: 10 CFR Part 50, the original construction permit and operating license framework, and 10 CFR Part 52, which introduced combined licenses (COLs), standard design certifications, and early site permits as a path toward more predictable licensing timelines.
Neither framework is optional. Both require that applicants demonstrate, through documented analysis, that the plant’s design satisfies the General Design Criteria (GDC) established in Appendix A to 10 CFR Part 50. Those criteria — 55 of them — define safety function requirements at a level of generality that gives designers flexibility but demands rigorous traceability between the criteria, the facility’s design basis, and every safety-related system and structure. The NRC’s review process tests that traceability explicitly. Reviewers follow the chain from GDC to Final Safety Analysis Report (FSAR) to system design descriptions to component specifications. Any broken link in that chain becomes a Request for Additional Information (RAI) — and RAIs are where schedules die.
What changed is the nature of the designs now seeking licenses. Light water reactors of the 1970s had decades of operational data, established vendor supply chains, and NRC staff with deep familiarity with the technology. A pressurized water reactor license application in 1975 was a documentation challenge; the underlying physics and safety case were well understood. An application for a pebble bed fluoride-salt-cooled reactor in 2025 is a different problem. The safety functions are different, the design basis events are different, and in some cases the analytical tools needed to model accident sequences have to be developed alongside the reactor itself.
The New Entrants and Their Documentation Challenge
NuScale Power, Kairos Power, and X-energy represent three distinct reactor technology families — small modular light water, fluoride salt-cooled high temperature, and pebble bed high temperature gas — and three distinct approaches to the licensing and documentation problem.
NuScale completed its NRC design certification review for the VOYGR plant design in 2022, a process that took over a decade and required responding to more than 2,000 RAIs. The volume of RAIs was not primarily a technology problem; it was a documentation coherence problem. Requirements that were specified at one level of the design hierarchy were not consistently reflected at the next level down, and the connections between safety function requirements and specific system parameters required manual reconstruction across thousands of pages of the design control document.
Kairos Power has taken an explicitly iterative approach, pursuing a construction permit for its Hermes demonstration reactor under 10 CFR Part 50 before attempting to license a commercial plant. This strategy is partly about validating the technology, but it is also about validating the documentation and licensing process itself. Kairos has been public about treating the Hermes licensing campaign as an opportunity to develop the requirements and safety analysis infrastructure for the commercial plant before the commercial plant’s schedule is on the line.
X-energy’s Xe-100 pebble bed reactor is pursuing a standard design approval, and the company has made significant investments in model-based systems engineering (MBSE) methods partly because the reactor’s passive safety case — which relies on the physics of graphite pebble fuel at high temperatures rather than active cooling systems — requires a traceable connection between neutronic design requirements, fuel performance requirements, and safety function claims that is difficult to maintain in a document-centric system.
Why Document-Based Tools Break at Nuclear Scale
The challenge of requirements management in nuclear programs is not simply one of volume, though volume is real. A complete FSAR for a large reactor design runs to tens of thousands of pages across multiple volumes. The challenge is relational density.
Nuclear safety cases depend on functional containment: every safety-related function must be traceable to a regulatory requirement, allocated to one or more systems, verified through analysis or test, and validated as sufficient to support the licensing claim. Each of those relationships — requirement to function, function to system, system to analysis, analysis to licensing basis — must be maintained consistently as the design evolves. When a design changes, the safety analyst needs to know immediately which requirements are affected, which analyses need to be rerun, and which sections of the FSAR need to be updated.
Document-based requirements management tools, including word processors, spreadsheets, and even dedicated requirements management platforms built around document metaphors, represent these relationships as text references between documents. When the design changes, a human being follows those references manually. At the scale of a first-of-a-kind nuclear program, with dozens of design disciplines working concurrently, that manual process cannot keep pace. The result is an FSAR submitted to the NRC with internal inconsistencies that reviewers find before the applicant does.
This is the structural reason why the nuclear industry is now paying attention to graph-based and model-based approaches to requirements management. In a graph model, the relationships between requirements, functions, systems, analyses, and verification activities are first-class objects in the data model. A change to a requirement propagates visibly through the graph. An engineer can query: what systems implement this safety function? What analyses support this licensing claim? What requirements are currently unverified? Those questions cannot be answered reliably in a document collection. They can be answered in a connected model.
Risk-Informed Regulation and the Performance-Based Shift
The NRC’s move toward risk-informed, performance-based regulation adds another dimension to the documentation challenge. Traditional deterministic regulation — the approach codified in the General Design Criteria — specifies what safety functions must exist and how they must be designed. Risk-informed regulation, as reflected in regulatory guides like RG 1.174, allows applicants to use probabilistic risk assessment (PRA) to justify design decisions that might not satisfy prescriptive requirements but can be shown to achieve equivalent or superior safety outcomes.
For advanced reactor developers, this is both an opportunity and a requirement engineering challenge. The opportunity is flexibility: a reactor with passive safety characteristics may be able to make licensing claims that a light water reactor could not, because the PRA can demonstrate that the core damage frequency is orders of magnitude lower than the regulatory thresholds even without certain active safety systems. The challenge is that the connection between the PRA model and the design requirements must be maintained explicitly and traceably. When a design parameter changes — a fuel enrichment level, a coolant flow rate, a control rod worth — the PRA model must reflect that change, and the licensing claims that depend on the PRA must be reassessed.
This creates a direct dependency between requirements management and safety analysis that did not exist at the same intensity under purely deterministic regulation. The requirements tool is no longer just a place to store what the design must do; it is the integration point between design intent, safety analysis, and regulatory commitment.
Tooling Investments in the Advanced Reactor Industry
The tooling landscape for nuclear requirements management is evolving from several directions simultaneously.
Legacy nuclear utilities and their engineering contractors built their document management infrastructure around IBM DOORS, which was the industry standard for configuration-controlled requirements databases through the 2000s and 2010s. DOORS provides version control, baseline management, and some traceability linking, but its document-centric data model makes cross-system impact analysis difficult, and its user experience creates barriers to adoption across large, multidisciplinary teams. DOORS Next, IBM’s web-based successor, addresses some usability issues but retains architectural assumptions from the document era.
Jama Connect and Codebeamer have gained some adoption in nuclear-adjacent industries — aerospace and defense, medical devices — and some advanced reactor programs have evaluated them for nuclear applications. Both offer better collaboration features than legacy DOORS and support bidirectional traceability more cleanly. The limitation in highly regulated contexts is that neither was designed for the depth of functional decomposition and safety case structure that nuclear licensing demands.
The more significant shift is among new entrant programs that are building their requirements infrastructure from scratch and have deliberately chosen platforms designed for connected, graph-based engineering. Tools like Flow Engineering, built for hardware and systems engineering teams working on complex first-of-a-kind programs, implement requirements as nodes in a connected graph where relationships between requirements, functions, components, and verification activities are maintained automatically as the design evolves. For a program like Hermes or Xe-100, where the design is changing rapidly in parallel with the licensing campaign, the ability to propagate change impact through a connected model — rather than chasing references through documents — has direct value in maintaining the coherence of the safety case.
The specific advantage in nuclear contexts is the ability to maintain live traceability between regulatory requirements (the GDC, NRC regulatory guides, technical specifications) and the evolving design basis without the manual reconciliation cycles that consume engineering time in document-centric programs. When an NRC RAI arrives asking for clarification of how the design satisfies GDC-17 (electric power systems), the team can answer from a connected model rather than reconstructing the argument from scattered documents.
The Schedule Pressure Forcing Modernization
Advanced reactor programs are operating under a form of schedule pressure that the original commercial nuclear industry never faced in quite the same way. The first generation of nuclear plants had no prior art to compete against and no investor return timeline. Today’s advanced reactor developers are competing against each other, against natural gas, against large-scale renewable buildouts, and against the clock of climate policy windows that may or may not remain open depending on the political cycle.
That schedule pressure is forcing requirements modernization decisions that the nuclear industry might otherwise have deferred indefinitely. Programs that start their licensing campaign with document-based requirements infrastructure and then discover its limitations during NRC review cannot easily switch tools mid-campaign. The cost of inadequate requirements infrastructure is measured in RAI response cycles, each of which can consume months of engineering time and push the operating license further into the future.
The programs that are getting this right are making the tooling investment before the license application, during the design phase, when there is still time to build the connected model correctly. They are also recognizing that requirements management is not a documentation function; it is a systems engineering function that sits at the center of the design process and must be owned by engineers, not technical writers.
Honest Assessment
The nuclear industry’s requirements modernization is real but uneven. Some advanced reactor programs have made serious investments in connected, model-based requirements infrastructure and are beginning to see the benefits in licensing campaign coherence. Others are still working from SharePoint folders and DOORS databases that were configured for a different generation of nuclear engineering problems.
The regulatory framework has not changed in ways that mandate any specific tooling approach. The NRC cares about the quality and consistency of the safety case, not the software that produced it. But the complexity of first-of-a-kind advanced reactor licensing — the depth of functional decomposition required, the integration between PRA and deterministic requirements, the speed of design evolution — creates conditions where document-based approaches are structurally inadequate, not just inconvenient.
The programs that license on schedule in the next decade will have made the right tooling decisions in the design phase. The programs that discover the limitations of their requirements infrastructure during NRC review will learn the lesson at a much higher cost.