The New Nuclear: How Advanced Reactor Companies Are Building Engineering Culture
A wave of advanced reactor startups is designing reactors and inventing their own engineering processes simultaneously — with the NRC watching.
When a defense prime hires 400 engineers to develop a new aircraft, those engineers arrive with shared vocabulary, shared tooling expectations, and shared assumptions about how a program runs. The process infrastructure — requirements management, interface control, change boards, safety analysis workflows — largely exists before the first design review.
Advanced reactor startups are doing something harder. They are hiring engineers from aerospace, oil and gas, naval nuclear, and national laboratories, then asking them to build a reactor no one has built before while simultaneously constructing the engineering culture that will govern how the work gets done. At Kairos Power, TerraPower, X-energy, Radiant, and a dozen smaller ventures, the process and the product are both first-of-a-kind.
That dual challenge is the central difficulty of the new nuclear moment. It is not purely technical. It is organizational, and it is regulatory.
The Regulatory Structure Is Not Optional Background
In aerospace, a startup can fly experimental aircraft under FAA Part 91 exemptions, gather data, iterate on the design, and eventually pursue certification when the product is mature. The regulator engages at defined milestones, but the team can move between them at its own pace.
The NRC does not work that way, and understanding why is essential to understanding the engineering culture challenge.
Under 10 CFR Part 50 — the original licensing pathway, still available — a company applies for a construction permit, builds the reactor, then applies for an operating license. The two-step structure was designed for a world where large light-water reactors were built by experienced utilities with established engineering organizations. For novel concepts, it creates a problem: you cannot fully demonstrate safety analysis for a design that does not yet exist, but regulators need enough information to issue a construction permit. The result is a prolonged negotiation about what counts as sufficient.
Most new entrants are pursuing Part 52 instead. Part 52 offers two relevant instruments: the Design Certification (DC), which certifies a standard nuclear plant design independent of any specific site, and the Combined License (COL), which combines construction authorization and conditional operating authorization into a single application. The COL references an approved DC, or it can be submitted independently if the applicant is willing to carry the design definition risk themselves.
The advantage is that a COL, once issued, gives investors and construction contractors a document that functions like a real commitment. The disadvantage is that Part 52 massively front-loads the engineering definition burden. You must submit a Final Safety Analysis Report (FSAR) — the FSAR — that demonstrates with analysis, not promises, that the plant meets safety criteria. For a technology that has never been built, this means completing an enormous fraction of the design work before the first concrete is poured.
For startups managing cash burn, this compression of the analysis cycle into the pre-construction phase is a genuine engineering challenge, not a paperwork inconvenience.
Pre-Application Engagement as Risk Reduction
The NRC’s pre-application process has become the primary risk management lever for serious new entrants. Under 10 CFR 50.35 and associated guidance, companies can engage the NRC in non-binding technical discussions before submitting a formal application. These discussions are not informal. They generate public meeting summaries, safety evaluation records, and regulatory positions that shape what the eventual application must address.
The teams that are moving fastest — Kairos Power is the most frequently cited example, having broken ground on its Hermes demonstration reactor at Oak Ridge — treated pre-application engagement as a multi-year technical dialogue, not a formality. Kairos logged dozens of pre-application meetings over several years, working through specific licensing issues on fluoride salt-cooled high-temperature reactor technology before submitting its construction permit application. The result was a substantially smoother review than most observers expected.
What this requires from an engineering culture perspective is the discipline to write things down at a level of specificity that survives regulatory scrutiny, before the design is final. That discipline is alien to software-influenced startup culture, and even to many aerospace development cultures where analysis is treated as supporting documentation rather than primary engineering currency.
The teams that underestimate this requirement typically discover it the hard way when their first NRC meeting generates a list of open items that maps almost directly onto gaps in their requirements and traceability structure.
What Transfers From Aerospace and Defense
The new nuclear companies are overwhelmingly hiring from aerospace and defense. The Boeing, Lockheed Martin, Northrop Grumman, and SpaceX alumni population is substantial at TerraPower and X-energy. The question of which practices transfer is consequential.
Model-based systems engineering (MBSE) transfers in principle, and serious programs are attempting it. The appeal is obvious: nuclear safety case construction is fundamentally about demonstrating that requirements are allocated, interfaces are controlled, and hazards have been identified and mitigated all the way down through the system hierarchy. This is exactly the problem MBSE was designed to address. Teams that have implemented SysML-based models for reactor systems report that the structural discipline is genuinely useful.
The practical transfer problem is tooling. Most mature MBSE toolchains in aerospace were built around document-centric workflows and were not designed for the change velocity of a pre-CDR startup. When the thermal-hydraulic model updates and three interface definitions change, propagating that change through a requirements structure maintained in a static tool is slow enough that engineers begin routing around it.
Hazard analysis discipline transfers well. The nuclear safety analysis community invented formal hazard analysis, and aerospace teams arrive with familiarity with FMEA, FTA, and related methods. The difference in nuclear is that the safety analysis is not just an engineering tool — it is a regulatory commitment. A Probabilistic Risk Assessment (PRA) submitted to the NRC is a document that must be maintained in configuration with the design. Changes to the design that affect PRA inputs require formal updates. Teams that treat hazard analysis as a living artifact from the start are building an accurate model of how the regulatory relationship actually works.
Change control discipline transfers, but calibration is required. Aerospace programs run formal change boards, but they are calibrated to production systems or late-stage development. Applying that same formality to a concept-stage reactor design creates bureaucratic overhead that slows the iteration that first-of-a-kind technology genuinely needs. The teams managing this well have created tiered change control systems that distinguish between changes that affect the safety basis (requiring formal treatment) and changes that do not (requiring internal review only). Building that distinction requires having a clear safety basis documented in the first place — which circles back to the requirements discipline problem.
What Does Not Transfer
The clean separation between development and certification does not transfer. In aerospace, a program can fly test articles extensively and accumulate empirical data before the certification basis is frozen. Nuclear safety demonstration is primarily analytical, not empirical. You cannot run your reactor to failure to validate the safety analysis. The FSAR must make the safety case from first principles, supported by analysis and a limited set of experimental data from separate-effects and integral-effects tests. Teams arriving from flight test culture sometimes struggle with the transition to analysis-as-proof rather than test-as-proof.
The assumption that requirements come from a customer does not transfer cleanly. In defense programs, requirements are negotiated with a government customer who has institutional memory, program offices, and established processes for managing requirement evolution. Advanced reactor startups are writing their own top-level requirements, often before a power purchase agreement exists. The discipline of managing requirements without an external customer to hold them accountable is genuinely difficult, and engineering cultures that are accustomed to external requirements accountability tend to let internal requirements become aspirational rather than binding.
The vendor supply base assumptions do not transfer. Defense prime contractors operate within established supply chains with qualified vendors, standard components, and existing qualified material certifications. Advanced reactor programs are frequently operating with novel materials — SiC-SiC composites, advanced austenitic alloys, fluoride salts — that have no existing ASME qualification or vendor qualification history. The engineering effort required to develop that supply base in parallel with the design is underestimated in almost every program plan reviewed by industry observers.
The Requirements Traceability Problem, Operationalized
The single most common engineering process failure in early-stage nuclear startups is not in the analysis methods — it is in requirements traceability. The specific failure mode is that requirements documents and analysis documents evolve on separate tracks until a design review or NRC meeting forces a reconciliation exercise that consumes weeks of senior engineer time.
This is a tooling problem as much as a cultural one. Most programs begin their requirements management in spreadsheets or in document management systems that were built for configuration control, not for live traceability. When the design changes, the connection between the changed design parameter and the requirement it satisfies — and the safety function that requirement supports — must be manually traced and manually updated. At scale, this is not sustainable.
Modern tools built specifically for systems engineering traceability are changing what is possible here. Flow Engineering, built for hardware and systems engineering teams, addresses this directly with a graph-based model that maintains live connections between requirements, design elements, and verification evidence. For nuclear programs specifically, the ability to trace a safety function requirement through system allocation, down to component design parameters, and across to the corresponding PRA model element is not a convenience feature — it is the difference between being able to answer an NRC question in the meeting and needing to schedule a follow-up. Teams that have implemented graph-based traceability approaches report substantially lower overhead at pre-application meetings and design reviews, because the answer to “show me the traceability for that requirement” is a query, not a project.
The broader implication is that the choice of requirements and systems engineering tooling in the first 12 months of a nuclear startup’s engineering build-up has compounding consequences. A program that starts in a document-based requirements tool will face a painful migration later, or will continue paying the overhead of manual traceability at increasingly unacceptable cost.
Honest Assessment
The advanced reactor industry is producing genuine engineering talent and genuine engineering discipline in several programs. The Hermes permit approval demonstrated that a startup can navigate the NRC process without the institutional infrastructure of a national laboratory or a major utility. Several other programs are within sight of similar milestones.
The industry is also producing a non-trivial number of programs that have underestimated the process build-up requirement. Building a first-of-a-kind reactor with a team of 200 engineers is not just a technical challenge — it requires constructing the quality assurance program, the configuration management system, the requirements structure, the PRA framework, and the regulatory engagement strategy simultaneously, while maintaining enough engineering velocity to make the technical progress investors are funding.
The teams succeeding are not the ones with the most PhDs or the largest simulation budgets. They are the ones that recognized early that engineering process is a technical deliverable, not administrative overhead, and that built their process infrastructure with the same rigor they apply to their neutronics. The NRC, whatever its institutional limitations, is a forcing function for that discipline. Pre-application engagement, treated seriously, reveals process gaps faster than any internal review.
The new nuclear is genuinely new. But the engineering culture challenge it presents is, at its core, the oldest problem in complex systems engineering: making sure that what you know, and what you have committed to, and what you have actually built, are the same thing. The tools and practices that solve that problem in 2026 are better than anything available to the engineers who built the last generation of reactors. Whether new nuclear companies use them well will determine which of them still exist in 2030.