First-of-a-Kind by Design: Systems Engineering Inside Nuclear Microreactor Licensing

Nuclear microreactors — broadly defined as designs producing between 1 and 50 MWe — are not incremental improvements on existing technology. Kairos Power’s KP-FHR uses a fluoride salt coolant at near-atmospheric pressure. X-energy’s Xe-100 is a pebble-bed high-temperature gas-cooled reactor. Oklo’s Aurora is a sodium fast reactor built around a heat-pipe passive decay heat removal concept. None of these designs has a licensed predecessor in the United States. All of them are pursuing NRC approval under a regulatory framework built, over sixty years, almost entirely around pressurized and boiling light-water reactors.

This is not a criticism of the NRC’s framework. 10 CFR Part 50 and Part 52 are detailed, technically rigorous, and grounded in operational experience from a substantial fleet. The problem is that the experience base they encode — loss-of-coolant accident phenomenology, pressurized boundary leak-before-break behavior, emergency core cooling system design — is specific to light-water physics. When a vendor applies those regulations to a reactor that has no liquid water, no high-pressure primary boundary, and passive safety behavior governed by entirely different phenomena, the regulatory process becomes a translation problem. Translating it requires systems engineering infrastructure that most nuclear programs have historically not needed to build.

What “First-of-a-Kind” Actually Means for the Design Basis

In a conventional light-water reactor licensing project, a substantial fraction of the design basis is inherited. An applicant for a new Westinghouse AP1000 COL does not need to re-derive the neutronic behavior of UO₂ fuel in light water. The phenomena are characterized, the codes are validated, and the NRC has accepted the methodology. The applicant’s systems engineering task is to demonstrate that their specific plant configuration conforms to an already-accepted design envelope.

FOAK microreactor programs have no such starting point. When Kairos Power filed its construction permit application for the Hermes test reactor, the company was simultaneously defining what the design basis events for a fluoride-salt-cooled pebble-bed reactor should be, defending the phenomenological models used to analyze those events, and demonstrating that its license basis documents were internally consistent. These are normally sequential activities. In FOAK licensing, they are concurrent — and they interact. A revision to the accident progression model for a loss-of-forced-flow event changes which structures, systems, and components are credited in the safety analysis, which changes their safety classification, which changes the design requirements applied to them, which may change the accident progression model.

This circular dependency is manageable when the design is stable and the analysis codes are validated. It is genuinely difficult when both are still maturing. The systems engineering response — the only viable one — is to make the dependency explicit and traceable so that when any element in the loop changes, the downstream effects propagate automatically and completely. That requires a requirements management architecture that is more sophisticated than what most nuclear programs currently operate.

The Safety Classification Problem for Novel Components

Safety classification under 10 CFR 50 Appendix B determines which quality assurance requirements apply to a given structure, system, or component. For light-water reactors, safety classification of major SSC categories is largely settled by precedent: reactor coolant pressure boundary, emergency core cooling, containment isolation — these have established classification rationale that vendors and the NRC both understand.

For microreactor designs, even major functional classifications must be constructed from scratch. Consider Oklo’s heat pipe arrays. Heat pipes are the passive mechanism by which decay heat is removed from the Aurora core. They are not active components — they contain no pumps, no valves, no moving parts. They are also, functionally, the equivalent of an emergency core cooling system. Their failure would directly threaten fuel integrity. So are they safety-related or not? The answer is not obvious from the regulations, and it is not obvious from any existing approved design. Oklo’s engineers had to develop a classification rationale, document it, defend it in pre-application meetings with the NRC, and then make every downstream design requirement that depends on that classification traceable to the rationale — because if the NRC disagrees with the classification, every requirement in the chain changes.

Kairos Power faces an analogous challenge with its FLiBe coolant boundary. FLiBe — a lithium-fluoride/beryllium-fluoride eutectic — is chemically stable, operates at low pressure, and has favorable neutronic properties. It is also not a substance with an established nuclear safety pedigree. The containment function for FLiBe leakage involves different phenomena than water leakage: it solidifies at room temperature, which is both a containment advantage and a source of thermal-stress design challenges. The safety classification of the primary salt boundary, and the design requirements derived from it, cannot be copied from any existing approved design. They must be derived, documented, and defended.

Defense-in-Depth Without Established Barriers

The defense-in-depth concept in nuclear safety is typically implemented through a layered barrier model: fuel matrix, cladding, primary boundary, and containment. For light-water reactors, this model has specific physical embodiments with well-characterized failure modes and acceptance criteria.

For non-LWR designs, each barrier must be defined, characterized, and argued for. X-energy’s Xe-100 uses TRISO fuel particles — microscopic fuel kernels coated with successive layers of pyrolytic carbon and silicon carbide. The fuel particle itself is the first two barriers. TRISO has decades of development history and reasonable characterization data, but the NRC’s existing guidance on fuel failure criteria was written for metallic or ceramic pellet fuel in zircaloy cladding. X-energy must demonstrate not only that TRISO maintains its barrier function under design-basis conditions, but that the NRC’s methodology for evaluating fuel integrity is applicable — or must propose and defend an alternative methodology.

This is defense-in-depth analysis as a first-principles engineering exercise. Every barrier must be defined functionally, its failure modes characterized, the phenomena that threaten it analyzed, and the design features that preserve it identified. That analysis structure becomes the skeleton of the safety case — and it must be internally consistent from the top-level safety functions all the way down to individual component design requirements.

Regulatory Framework Gaps and How Programs Are Navigating Them

The NRC has made genuine efforts to adapt its framework for advanced reactors. The Advanced Reactor Policy Statement, the 10 CFR Part 53 rulemaking (the new framework for licensing of advanced nuclear reactors), and NRC’s efforts to develop technology-inclusive regulatory guidance all reflect institutional recognition that the existing framework was not built for these designs. Part 53, if finalized, would allow vendors to define their own licensing basis using a technology-inclusive framework rather than importing LWR-specific requirements by default.

But Part 53 is not finalized. The programs currently in licensing — Kairos’s Hermes construction permit, Oklo’s combined license application for its first commercial plant, X-energy’s design certification effort — are operating under Part 50 or Part 52 today. That means navigating explicit regulatory gaps through a combination of pre-application engagement, alternative analysis methodologies accepted under 10 CFR 50.55a or 50.59, and, in some cases, explicit exemption requests.

Each of these pathways has systems engineering implications. A regulatory gap — a place where the regulation references a phenomenon, method, or component type that does not exist in the subject design — must be identified, documented, and resolved before it appears as a deficiency in an NRC review. Identifying those gaps requires reading the applicable regulations against the actual design with enough specificity to see where they fail to connect. That is not primarily a regulatory affairs task. It is a systems engineering task, and it requires the design and requirements information to be organized in a way that makes regulatory mapping tractable.

Requirements Hierarchy Structure for COL and DC Applications

A combined license application under 10 CFR Part 52 Subpart C requires a Final Safety Analysis Report incorporating the design-specific portion, an emergency planning basis, and a set of inspections, tests, analyses, and acceptance criteria — the ITAAC — that the NRC uses to confirm the as-built plant matches the licensed design. The ITAAC are, in practice, the terminal end of a requirements chain. They are acceptance criteria. Everything above them in the licensing structure — safety functions, functional requirements, design requirements, performance requirements — must connect to them.

The programs that are performing best in NRC pre-application review are the ones treating this chain as a genuine engineering artifact rather than a documentation artifact. The difference is significant. A documentation artifact is a set of documents produced after design decisions are made, organized to satisfy a review checklist. A genuine engineering artifact is a structured model in which requirements have defined attributes — source, rationale, verification method, status — and in which changes propagate through defined dependency relationships.

The practical implication: when the NRC issues a Request for Additional Information challenging a specific safety analysis assumption, an engineering-artifact approach lets the team immediately identify which requirements depend on that assumption, which design features implement those requirements, and which ITAAC verify those features. A documentation artifact approach requires a manual search through thousands of pages of FSAR content to reconstruct the same information.

How Modern Tools Are Closing the Gap

Traditional requirements management in nuclear programs has been dominated by IBM DOORS and, more recently, DOORS Next. Both tools are capable of managing large, complex requirements sets with formal attributes and link types, and DOORS in particular has decades of nuclear industry deployment history. The institutional knowledge embedded in large nuclear programs’ DOORS databases is not trivial — it represents real configuration management discipline.

The limitation is that DOORS and DOORS Next are fundamentally document-centric tools adapted for requirements management. Their traceability model works well when the requirements hierarchy is stable and the primary task is maintenance. In FOAK licensing, where the hierarchy itself is being constructed concurrently with the design, the rigidity of a document-centric approach becomes a liability. Reorganizing a requirements hierarchy as the design basis evolves — as it must in FOAK programs — is operationally painful in DOORS Next. Cross-linking safety analysis conclusions to design requirements to ITAAC in a way that supports rapid impact analysis when any element changes requires workflow discipline that the tools do not enforce automatically.

Tools like Flow Engineering (flowengineering.com) represent a different architectural approach: graph-based requirements models in which every element — requirement, design decision, safety function, verification record — is a node with typed relationships, queryable in real time. For FOAK licensing work specifically, this matters because the regulatory gap analysis, the safety classification rationale, and the ITAAC traceability all need to be part of the same connected model. When a classification rationale changes, the impact propagates immediately to downstream requirements. When a new RAI arrives from the NRC, the team can query the model to scope the response before reading a single document.

Flow Engineering is deliberately focused on systems engineering teams rather than program-scale document management — it does not attempt to replace the full PLM stack or integrate directly with nuclear QA records management systems. For programs that need a heavyweight enterprise integration across procurement, construction records, and corrective action programs, that scope boundary is relevant. But for the front-end work — building the requirements hierarchy, establishing the safety classification rationale, structuring the defense-in-depth argument, and maintaining ITAAC traceability through design evolution — the graph-native approach handles the concurrent, evolving nature of FOAK development more naturally than document-centric alternatives.

Honest Assessment

Nuclear microreactor licensing is genuinely hard, and the systems engineering challenge is not primarily a tools problem. It is a conceptual problem: how do you build a safety case for a design when the regulatory framework was not written for it, the analysis codes are not yet validated to NRC’s satisfaction, and the design itself is still evolving? The answer is rigorous, explicit, traceable requirements engineering — not because traceability is a compliance checkbox, but because it is the only mechanism that makes the concurrent, interdependent evolution of design and licensing basis manageable.

The programs that will succeed in NRC licensing — Kairos Power’s trajectory through the Hermes CP review is instructive — are the ones treating their safety case as a structured engineering model from day one, not as a document to be written once the design is settled. The regulatory framework will continue to evolve, Part 53 will eventually be finalized, and NRC’s guidance for non-LWR designs will mature. None of that changes the underlying requirement: the argument that a novel design is safe must be internally consistent, completely traceable, and resilient to the questions regulators will inevitably ask. Building that argument is a systems engineering problem, and solving it requires treating it like one.