Kairos Power: Systems Engineering at the Frontier of Nuclear Licensing

When engineers talk about requirements management in complex systems, they usually mean managing requirements that are hard to satisfy. Kairos Power has a different problem: managing requirements that do not fully exist yet, for a reactor technology that has no direct regulatory precedent, licensed by an agency that is still building the framework it will use to evaluate it.

That is not a criticism of Kairos or the NRC. It is a precise description of what first-of-kind nuclear development actually looks like in 2026, and it makes Kairos one of the most instructive case studies in applied systems engineering currently operating in the United States.

What Kairos Is Building

The Kairos Power Fluoride Salt-Cooled High-Temperature Reactor — KP-FHR — uses a solid fuel pebble bed cooled by Flibe, a molten fluoride salt mixture of lithium and beryllium fluoride. The design operates at low pressure and high temperature, targeting outlet temperatures around 600°C. The passive safety characteristics of the design, including a strongly negative temperature coefficient of reactivity and natural circulation cooling, are among its principal claimed advantages over conventional light-water reactors.

None of these system characteristics map cleanly onto the regulatory structures the NRC developed over five decades of light-water reactor oversight. The existing body of NRC guidance, from Standard Review Plans to design-basis accident methodologies to coolant system classification, was built on the assumption of water as both coolant and moderator. Flibe is neither. The fuel — TRISO particles in graphite pebbles — comes from a heritage of high-temperature gas-cooled reactor development, not the zircaloy-clad uranium oxide pellets that populate the NRC’s analytical toolbox.

This is not a regulatory gap Kairos discovered late. It is the core engineering and systems challenge the company organized itself around from inception.

The Hermes Strategy: De-Risking Requirements Before They Become Commitments

In 2023, the NRC issued a construction permit for Hermes, a 35 MWth non-power demonstration reactor to be built at the East Tennessee Technology Park in Oak Ridge. This was the first construction permit the NRC issued for a new reactor design in more than fifty years. Hermes 2, a twin-unit follow-on, has received NRC approval to proceed as well.

From a systems engineering perspective, Hermes is worth understanding precisely for what it is not. It is not a scaled prototype on a path to commercial certification. It is an instrument for retiring requirements uncertainty before that uncertainty becomes embedded in a commercial design commitment.

The KP-FHR concept carries a class of technical risks that cannot be resolved analytically. Salt chemistry behavior at scale, tritium management in Flibe systems, pebble handling mechanics under operating conditions, instrumentation performance in a high-temperature fluoride environment — these are phenomena where the uncertainty is irreducible without operational data. The commercial design cannot be fully specified until that data exists, because the specifications that would govern safety analysis, material qualification, and I&C design all depend on empirical knowledge the industry does not yet have.

Hermes forces that knowledge into existence before the commercial plant enters detailed design. The requirements that will govern the commercial design are being shaped, in part, by what Hermes demonstrates. This is a deliberate sequencing decision, not a hedge against schedule pressure.

That sequencing logic is sound systems engineering: identify the requirements with the highest parametric uncertainty, build the smallest system that can resolve that uncertainty, use the results to sharpen the downstream requirements before the cost of changing them becomes prohibitive.

Licensing a Reactor While the Licensing Framework Is Written

The more structurally unusual challenge Kairos faces is the regulatory one. The NRC’s traditional licensing pathway under 10 CFR Part 50, and the later combined license process under 10 CFR Part 52, were written for light-water reactors. The agency has been developing 10 CFR Part 53, a technology-inclusive framework for advanced nuclear reactors, since 2019. As of mid-2026, Part 53 has not been finalized.

Kairos is not waiting. The company has been engaging the NRC through pre-application interactions, topical report submissions, and licensing modernization project participation — essentially working through the technical bases of its safety case with the agency before a formal design certification application is submitted. This approach, encouraged by the NRC’s advanced reactor program office, allows both sides to identify where existing guidance applies, where it needs adaptation, and where entirely new analytical methods need to be established and validated.

From a requirements management standpoint, this creates a category of requirement that practicing engineers rarely encounter in civil programs: the negotiated regulatory requirement. These are safety requirements where the technical basis for the requirement itself is under active development, where the NRC’s own staff are working through what constitutes adequate protection in the context of a reactor that is not a light-water reactor.

The practical consequence is that Kairos’s requirements baseline cannot be treated as static. A topical report that the NRC accepts in 2025 establishes a technical basis that may be superseded or refined as Part 53 rulemaking progresses. A safety analysis method agreed upon in pre-application engagement becomes a commitment with traceable implications for instrumentation design, operational limits, and emergency operating procedures. Managing this requires distinguishing clearly between three categories of requirement: those that are fixed (site boundary dose limits, for instance, are not changing), those that are settled by agreement but remain subject to regulatory evolution, and those that are genuinely open pending either Hermes data or NRC rulemaking.

Conflating these categories is one of the most common ways that complex first-of-kind programs generate rework at the worst possible time — late in detailed design when the cost of re-deriving a safety analysis margin is measured in months, not days.

What Good Requirements Infrastructure Looks Like Here

The requirements management challenge at Kairos is not exotic in its fundamentals. It is an extreme case of the standard problem: how do you maintain a coherent, traceable requirements baseline when the inputs — customer needs, regulatory requirements, technical constraints, and design decisions — are all changing, and when changes in one layer have non-obvious implications for layers above and below?

The specifics of the nuclear domain add several complications. The NRC requires that a license applicant demonstrate that safety functions are identified, that the design satisfies those functions, and that the analysis supporting that claim is traceable and auditable. This is requirements traceability in its most legally consequential form. A gap in the traceability chain — a safety function that cannot be traced to a specific design feature, or a design feature whose qualification basis cannot be traced to an accepted analytical method — is not a process deficiency. It is a licensing vulnerability.

This is one of the reasons that systems like Flow Engineering, which treat requirements as graph-structured entities with explicit dependency relationships rather than as flat document hierarchies, are architecturally better suited to this kind of problem than traditional document-based tools. When a regulatory requirement changes — say, the NRC issues a request for additional information that requires revising the thermal-hydraulic analysis basis for a safety limit — the ability to propagate that change through the requirement graph and immediately identify every design parameter, analysis, and verification activity that inherits from it is the difference between a controlled change and a discovery process. At Kairos’s level of licensing exposure, controlled changes are the only acceptable kind.

The traceability demands of nuclear licensing also penalize document-centric requirements management in a specific way: documents version. When the topical report for pebble fuel behavior gets revised, a document-based system captures that a new version exists. A model-based system with graph traceability captures which safety functions, design requirements, and analysis commitments have inheritance relationships to that topical report — and therefore need to be reviewed in light of the revision. The difference is not cosmetic when the reviewer is an NRC staff engineer preparing a Safety Evaluation Report.

The Broader Signal

Kairos is one of several advanced reactor developers — alongside X-energy, TerraPower, and Terrestrial Energy — pursuing NRC licensing for non-light-water designs. Each of these programs is, in its own way, navigating the same structural challenge: building a requirements baseline for a novel technology while the regulatory acceptance criteria for that technology are being negotiated in real time.

This is a condition that will not resolve quickly. Part 53 rulemaking is proceeding, but finalization timelines have slipped before and will plausibly slip again. The NRC’s advanced reactor program has genuine institutional will to enable new technology, but it also has statutory obligations and organizational risk tolerance that constrain how fast the framework can move. The developers who succeed will be those who have built requirements infrastructure capable of absorbing regulatory evolution without losing traceability coherence.

Kairos’s structured approach — using Hermes to retire empirical uncertainty, engaging the NRC through topical reports and pre-application interactions to establish negotiated technical bases, and sequencing its commercial design work to depend on data rather than assumptions — is a reasonable model for how to do this. It is not without risk. Hermes has a construction and operations program that will generate its own surprises. Part 53 may finalize in ways that require re-derivation of some safety bases. The commercial timeline remains ambitious.

But the fundamental systems engineering logic is sound: identify what you do not know, design an instrument to find out, maintain a requirements baseline that accurately reflects the difference between what is settled and what is not, and do not let schedule pressure collapse those categories into each other.

First-of-kind nuclear development has historically failed when programs treated uncertain requirements as fixed, made design commitments before the empirical basis existed, and then spent the back half of the program paying for the rework. Kairos, so far, is trying to fail differently.