Nuclear Fission’s Engineering Renaissance: Why New Reactor Programs Are Reinventing Their Systems Engineering Approach

There are roughly two dozen advanced fission reactor concepts in active development in the United States right now, depending on how you count. They span a remarkable range: high-temperature gas reactors, molten salt designs, heat pipe microreactors, sodium fast reactors, and several concepts that don’t map cleanly onto any legacy category. What they share — beyond the physics — is a collision with a regulatory and engineering infrastructure that was built for something else entirely.

The U.S. nuclear regulatory framework, anchored by 10 CFR 50 Appendix B and the NQA-1 quality assurance standard, was codified in the 1970s around the engineering practices of gigawatt-scale pressurized and boiling water reactors. Those plants were designed by large contractor organizations using drawing boards, updated through formal document change processes, and reviewed by the NRC over multi-year cycles. The framework that emerged from that era is conservative, document-centric, and deeply waterfall in its assumptions.

Companies like X-energy, TerraPower, Kairos Power, and Oklo are not building those plants. They are smaller teams, using modern software tooling, targeting shorter licensing timelines, and in several cases pursuing genuinely novel reactor physics. The gap between how they work and what the regulatory framework expects is not theoretical — it is showing up concretely in pre-application meetings, license application drafts, and safety basis documentation reviews.

What the Regulatory Framework Actually Requires

Before diagnosing the friction, it’s worth being precise about what Appendix B and NQA-1 actually demand — because the requirements are often mischaracterized in both directions.

Appendix B establishes 18 criteria covering design control, document control, procurement control, instructions and procedures, inspection, test control, corrective action, and records. NQA-1 expands these into detailed implementation requirements. What neither document specifies is the tooling. They require that design changes are controlled and traceable; they do not require that control to happen in a particular document management system or requirements database.

This matters because it means the regulatory requirements are, in principle, tool-agnostic. A team using a graph-based requirements model can satisfy Appendix B criterion III (Design Control) as fully as a team using a 1990s document management system — provided the team can demonstrate that design inputs are identified, design outputs are verified against them, and changes are controlled and traceable.

In practice, however, the NRC review culture was built around specific artifact types: Design Basis Documents, Safety Analysis Reports structured to Regulatory Guide 1.206, and Requirements Traceability Matrices organized as flat tables cross-referencing document numbers. Reviewers know how to audit these artifacts. They have less familiarity with — and in some cases explicit skepticism of — SysML models, graph databases, or AI-generated traceability summaries.

This is the practical gap. The regulation is flexible; the review process is not.

Where the New Reactor Programs Are Hitting Friction

Design control across iterating concepts. Companies like Kairos Power, which is building fluoride salt-cooled high-temperature reactors, and Oklo, pursuing compact fast reactors, are not working from a stable, mature design that happened to need regulatory approval. They are iterating — running tests, updating thermal-hydraulic models, revising passive safety system designs — while simultaneously developing their licensing basis. This is normal for hardware programs of this complexity. It is structurally difficult for Appendix B design control, which was designed around change-order-style document control rather than continuous design evolution.

The underlying problem is that document-centric design control creates an artificial separation between the living design and the controlled record of that design. Every time a design evolves, teams must manually propagate changes through a document hierarchy, update traceability records, and verify consistency — work that is both labor-intensive and error-prone. For a program iterating its design monthly rather than annually, this overhead becomes genuinely prohibitive.

Safety basis traceability. The NRC expects licensing applications to demonstrate a clear chain from regulatory requirements (10 CFR 50, applicable Regulatory Guides, Standard Review Plan sections) down through design requirements, system requirements, component specifications, and test results. For a conventional LWR, this chain is well-understood; the Standard Review Plan was written with LWR safety systems in mind, and the regulatory basis for every major system is established by precedent.

For advanced reactor concepts, this chain has to be constructed from first principles. TerraPower’s Natrium reactor — a sodium-cooled fast reactor with a molten salt thermal storage system — cannot simply inherit LWR precedents for its decay heat removal system or its secondary boundary requirements. The safety basis has to be argued from fundamental principles, alternative approaches to defense-in-depth, and often from new analysis methods. Demonstrating that argument in a traceable, auditable form, to a standard NRC reviewers can evaluate, is a significant systems engineering challenge.

Software QA under 10 CFR 50.55a and Appendix B. Modern reactor programs use computational tools for everything from neutronics to structural analysis to safety system functional modeling. The QA requirements for safety-related software — rooted in NRC’s NUREG/CR-6101 and the IEEE 7-4.3.2 standard — are detailed and demanding. They require documented verification and validation, configuration management of specific software versions, and restrictions on the use of commercial off-the-shelf tools in safety-related calculations without qualification. For programs that rely on modern computational environments, managing this software QA layer is a distinct and persistent burden.

How Advanced Reactor Companies Are Adapting

The adaptation strategies vary, but several patterns are visible across the sector.

Proactive pre-application engagement. The NRC’s pre-application process — which allows developers to meet with staff, submit white papers on specific issues, and get informal feedback before filing a formal license application — has become a genuine engineering tool for advanced reactor programs, not just a regulatory courtesy. Companies are using these meetings to establish shared understanding of how novel features map to existing regulatory categories, which precedents apply, and where new approaches need to be justified.

Oklo’s experience is instructive here, though complicated. Their first application for the Aurora microreactor was denied in 2022 — the NRC cited insufficient information on fuel failure consequences and accident source terms. The denial was painful, but Oklo’s response was to re-engage systematically, address the identified gaps, and resubmit. Their subsequent license application approval in 2025 reflected a more mature understanding of what the NRC needed to see and how to present it. The lesson is not that the NRC is impenetrable — it is that the process requires sustained, structured engagement.

Modular licensing strategies. Several SMR developers, including X-energy with its Xe-100 pebble bed reactor, are pursuing standard design approvals or design certifications before securing construction and operating licenses for specific sites. This allows the engineering and regulatory work on the reactor design itself to proceed separately from site-specific work, and it creates a reusable licensed design that can be deployed at multiple locations without full re-review. The systems engineering implication is that the standard design must be defined with sufficient rigor and traceability to support site-independent review — a high bar, but one that pays dividends across a fleet.

Re-implementing QA requirements in modern tooling. The most technically sophisticated adaptation strategy involves building modern requirements management and traceability infrastructure that satisfies the substance of Appendix B and NQA-1 requirements while giving engineering teams the agility they need to iterate. This means using model-based systems engineering approaches to maintain a living requirements model, then generating the controlled document artifacts that NRC reviewers expect from that model — rather than trying to maintain those artifacts directly.

The key insight is that the regulatory artifacts — the RTM, the design basis summary, the interface requirements document — should be outputs of the engineering model, not the model itself. When they are the model, every design change becomes a documentation project. When they are outputs, the documentation reflects actual design state continuously.

This is where modern AI-assisted requirements management tools are starting to have practical impact. Tools like Flow Engineering, which is built specifically for hardware and systems engineering programs, support graph-based requirements models with explicit traceability relationships and AI-assisted impact analysis. When a design parameter changes — say, a revised core outlet temperature driven by updated thermal-hydraulic analysis — the tool can propagate that change through the requirements graph and flag every downstream requirement, interface, and verification activity that may be affected. For a team managing thousands of requirements across a nuclear system design, this capability is not a convenience feature. It is the difference between change control that is actually tractable and change control that exists on paper but breaks down in practice.

The regulatory translation layer still requires human engineering judgment — deciding which flagged impacts are material, how to update affected documents, and how to present changes to NRC reviewers. But the analysis burden that previously required manual RTM reviews measured in weeks can be reduced to structured engineering decisions measured in days.

The Regulatory Negotiation

Describing the current situation as a “negotiation” is accurate but requires care. The NRC is not a party that makes deals. It is a technical regulator with statutory authority and a safety mandate. The negotiation is better understood as a technical discourse: developers proposing approaches, NRC staff evaluating them against regulatory requirements and safety principles, and both sides working toward a common understanding of what constitutes adequate demonstration of safety.

What has changed in the last five years is that the NRC has developed regulatory frameworks specifically intended to support advanced reactors. The Part 53 rulemaking — a new licensing framework explicitly designed for non-LWR reactor concepts — is the most significant structural change. Part 53 moves away from prescriptive LWR-specific requirements toward a more performance-based and risk-informed approach, explicitly accommodating diverse reactor technologies. It is not finalized, and its eventual form remains uncertain, but its development signals genuine regulatory recognition that the existing framework is a poor fit for the technology landscape emerging from the private sector.

The Accelerated Non-Light Water Reactor Review Initiative and the NRC’s ongoing work with the National Reactor Innovation Center reflect the same recognition. The regulatory system is not static — it is being actively revised by people who understand the problem.

What the advanced reactor community needs to avoid is the assumption that regulatory modernization will happen fast enough to solve current program problems. For companies with active license applications or pre-application engagement today, the framework in place now is the relevant one. Waiting for Part 53 to rationalize requirements management obligations is not a strategy.

An Honest Assessment

The new reactor companies are not being naive about the difficulty of what they are attempting. The systems engineering challenge they face — novel reactor physics, constrained teams, iterative design, and an inherited regulatory framework — would be demanding with perfect tooling. It is genuinely hard with the tooling that currently exists.

The companies making the most progress are those treating systems engineering and regulatory engagement as core program functions rather than overhead. That means dedicated systems engineers involved in design decisions, not just documentation. It means requirements management infrastructure built to support iteration, not just to produce artifacts. And it means sustained, technically credible engagement with NRC reviewers — not to minimize scrutiny, but to make the path to adequate demonstration of safety as efficient as possible.

The reactor concepts being developed now are, in several cases, technically compelling. High-temperature gas reactors with passive decay heat removal, molten salt systems that operate at low pressure, heat pipe microreactors with no active cooling systems — these designs address legitimate limitations of the LWR technology base. Whether they reach commercial deployment depends substantially on whether the engineering organizations developing them can navigate the systems engineering and regulatory challenges described here.

That is not a physics problem. It is an engineering execution problem — and it is solvable.