How the Nuclear New Build Wave Is Reshaping Systems Engineering Practice

The last time the nuclear industry had to think hard about systems engineering tooling, the dominant requirements platform was IBM DOORS running on Windows NT. The plants being built today — or in most cases, the plants being licensed today, with construction to follow — are a different problem entirely.

Small modular reactors, high-temperature gas-cooled reactors, molten salt concepts, microreactors for remote sites: these are not evolutionary iterations of the Westinghouse AP1000. They are architecturally novel designs with passive safety systems, new fuel forms, unconventional instrumentation and control topologies, and in some cases no direct precedent in the regulatory database. The engineering teams building them are being asked to satisfy safety standards that weren’t written with their designs in mind, using regulatory frameworks that are themselves still being finalized, while competing for a talent pool that barely existed a decade ago.

This is not a crisis. But it is a forcing function — and it’s reshaping what systems engineering practice looks like in nuclear development.

The Regulatory Touchpoint Problem

The NRC’s licensing structure for new reactor designs has two main paths. Large light-water reactors have operated under 10 CFR Part 50 and Part 52 for decades. These rules assume you’re building something that looks, broadly, like a pressurized water reactor or a boiling water reactor. The safety analysis methods, the I&C qualification frameworks, the operator licensing requirements — all calibrated to that baseline.

In 2024, the NRC finalized 10 CFR Part 53, the technology-inclusive commercial nuclear plant rule. The intent was to create a framework that doesn’t presuppose reactor architecture. In practice, Part 53 shifts the burden of proof significantly toward the applicant. If you’re operating under Part 50, decades of precedent tell you what “safe” looks like for your reactor type. Under Part 53, you have to construct that argument from first principles, using a risk-informed, performance-based approach, and demonstrate it through a licensing basis that the NRC is evaluating largely without precedent.

For requirements engineering, this has a direct implication: every design basis claim needs a traceable justification chain that can survive regulatory scrutiny from reviewers who may not have deep familiarity with your reactor concept. The RTM isn’t a convenience — it’s your primary instrument for demonstrating that you haven’t left a gap between the safety requirement and the design that’s supposed to meet it.

The pre-application engagement process, where developers submit white papers and hold technical meetings with NRC staff before formal license application, is generating detailed requests for additional information (RAIs) that often center on exactly this kind of traceability. How did you derive this design parameter from this safety function? What’s the failure mode this design feature is addressing, and where does that requirement come from? Answering RAIs without a coherent requirements model isn’t impossible, but it’s expensive and slow.

IEC 61513 and IEEE 603: Standards Written for a Different Reactor

IEC 61513 and IEEE 603 are the two load-bearing standards for nuclear I&C safety systems. They establish the requirements for safety system design, classification of safety functions, independence and diversity requirements, and the qualification criteria for safety-related I&C equipment. Every new nuclear project, regardless of architecture, is expected to address them.

The problem is that both standards were developed with large light-water reactors as the implicit reference. Their language assumes certain things: active safety systems that require I&C actuation to function, defined categories of design basis events drawn from LWR operating experience, and instrumentation architectures that look broadly like what you’d find in a 1970s vintage plant updated with digital I&C.

Apply those standards to an SMR with fully passive safety systems — a design where the safety function is achieved by natural circulation and gravity, not by pump actuation — and you encounter genuine interpretive ambiguity. If a safety function is passive, what does IEEE 603’s requirement for “automatic initiation” mean? If your design basis event list doesn’t map cleanly to the LWR event categories in the standard, how do you demonstrate coverage?

The Nuclear Energy Institute has published guidance documents (NEI 18-04, NEI 21-07) that attempt to bridge some of this gap for Part 53 specifically, and the NRC’s own regulatory guides are being updated. But the honest answer is that the industry is still working out the interpretive framework in real time, often through the pre-application process itself.

For systems engineers, this means that requirements derivation in an advanced reactor program is not a mechanical exercise. It requires engineering judgment, regulatory expertise, and the ability to document that judgment in a form the NRC can audit. You can’t just import a requirements template from an AP1000 program and apply it to your molten salt design. The functional requirements, the safety classification logic, the I&C architecture assumptions — all of it needs to be rederived from your specific safety case.

What the Talent Gap Actually Looks Like

There is a widely cited nuclear talent shortage, and it’s real. But the specific shortage that’s hitting systems engineering practice in new build programs is more precise than the general narrative suggests.

There are experienced nuclear safety engineers who understand how to develop a licensing basis, how to classify structures systems and components, how to write a Probabilistic Risk Assessment, and how to navigate the NRC. Most of them learned their craft on large LWR programs, often at utilities or Tier 1 contractors. They carry decades of institutional knowledge about what the regulator expects and how to give it to them.

There are also experienced systems engineers and requirements managers who understand MBSE, model-based approaches to requirements, traceability architecture, and modern tooling. Many of them have worked in aerospace, defense, or automotive. They’re comfortable with SysML, with graph-based requirements models, with AI-assisted analysis.

The overlap between those two populations is small. Engineers who can write a nuclear safety analysis and build a coherent requirements model in a modern platform, who understand both IEC 61513 and what a good ontology for requirements traceability looks like — that is a genuinely scarce combination. SMR developers are competing for maybe a few hundred people in the United States who sit at that intersection, and those people are being offered equity compensation by startups that want them badly.

The practical consequence is that most new build programs are running with split teams: nuclear safety experts who drive the technical content of requirements, and systems engineering infrastructure people who build and maintain the tooling. This works, but it creates a coordination surface where requirements can lose their safety rationale if the two groups aren’t tightly coupled. A requirement that reads “the reactor protection system shall initiate a scram within 200ms of detecting a neutron flux exceedance above 120% rated power” has a safety basis that needs to be traceable in the model — not just in someone’s head.

New Entrants and the Legacy Toolchain Question

Companies that built nuclear plants in the 1980s and 1990s carry an enormous amount of legacy toolchain debt. DOORS installations with tens of thousands of requirements, each with compliance attributes, review histories, and change records going back decades. That infrastructure is hard to leave, even when the limitations are obvious. Migrating a mature nuclear program from DOORS to anything else requires reconciling that entire history, re-establishing traceability, and getting regulatory acceptance for the change. Most established nuclear programs don’t attempt it.

New entrants don’t have that problem. A company founded in 2018 to develop a molten salt reactor hasn’t inherited a DOORS installation. They’re selecting their requirements infrastructure from scratch, often before they have a formal license application in preparation. This is creating a cohort of nuclear developers that are adopting modern systems engineering platforms from day one — and the difference in operational posture is visible.

Graph-based requirements platforms, where requirements, design artifacts, verification records, and hazard analyses exist as nodes in a connected model rather than as rows in a flat database, are a natural fit for nuclear safety cases. The safety case for a nuclear plant is inherently a graph: safety functions connect to design features, which connect to verification tests, which connect to qualification records, which connect to operating procedures. Maintaining that structure in a document or a flat requirements database forces you to recreate it manually at every review cycle.

Modern platforms like Flow Engineering are built on exactly this kind of connected model, where requirements trace to system architecture, hazards, and verification evidence in a live graph rather than a static export. For a team building a nuclear safety case from scratch, the ability to query “show me every requirement that derives from this safety function” or “show me all open verification gaps for Category I SSCs” without manually hunting through spreadsheets is operationally significant. Flow Engineering’s AI-assisted requirements analysis — surfacing conflicts, gaps in coverage, and derivation chains — is particularly valuable in a domain where every gap in the safety argument is a potential RAI.

The deliberate focus of platforms like Flow Engineering on requirements and systems engineering depth, rather than broad program management, means nuclear teams are sometimes pairing them with separate document management systems for formal submittals. That’s a real workflow consideration. The NRC’s document submission requirements are specific, and the interface between a live requirements model and a formal regulatory submission document is a process that teams need to design explicitly.

The Traceability Imperative

In most engineering domains, requirements traceability is an audit artifact. You build it because your customer’s contract requires a Requirements Traceability Matrix, you maintain it with varying levels of rigor, and you produce it at program milestones.

In nuclear, this framing is wrong in a way that causes problems. The traceability structure in a nuclear safety case is not evidence that you did engineering — it is the engineering. The argument that a given design is safe runs through the chain from regulatory requirement to safety function to design parameter to physical design to verification test to operating procedure. A gap anywhere in that chain is not a paperwork deficiency; it’s a potential path to an unsafe condition that wasn’t analyzed.

This has practical implications for how requirements engineering is resourced and managed in nuclear programs. Treating requirements management as a documentation function that trails behind design engineering is a failure mode that the NRC’s review process will eventually surface — usually in the form of RAIs that arrive late in the review cycle when they’re maximally disruptive.

Teams that have migrated from aerospace and defense to nuclear often adapt to this faster than teams coming from commercial industrial backgrounds. The aerospace safety case mentality — where the requirements structure is the product, not the byproduct — translates well. Teams that have spent years working to DO-178C or ARP4754A understand that traceability is a design discipline, not a reporting function.

Honest Assessment

The nuclear new build wave is real, and the systems engineering implications are significant. The combination of novel reactor architectures, an evolving regulatory framework, genuine talent scarcity, and the absence of inherited toolchain constraints for new entrants is creating conditions where the practices adopted now will shape how the industry operates for decades.

The optimistic reading is that the cohort of new nuclear developers has an opportunity that established players didn’t have: to build a requirements engineering infrastructure from scratch using modern, graph-based, AI-assisted tools that the legacy nuclear industry never had access to. Done well, this could produce license applications that are more coherent, more traceable, and more defensible than anything the previous generation of nuclear development produced.

The cautious reading is that modern tooling is necessary but not sufficient. The regulatory expertise to navigate IEC 61513 interpretation for a novel architecture, the safety culture to treat traceability as a design discipline rather than overhead, and the coordination infrastructure to keep nuclear safety judgment coupled to requirements model structure — those things don’t come from selecting a better platform. They come from how the engineering team is organized, what it values, and how it works.

The companies that get this right will have a durable advantage in an industry where licensing timelines are the primary constraint on market entry. The ones that treat requirements engineering as a compliance exercise will find out the hard way, at RAI time, that the NRC disagrees.