What Microreactor Development Actually Demands
Building a nuclear reactor is not primarily a physics problem. The physics of fission is well understood. What makes nuclear development hard — genuinely, structurally hard — is the engineering discipline required to take that physics, enclose it in a system that cannot fail in ways that harm people, prove that to a regulator with jurisdiction over every design decision, and then do all of that faster and cheaper than the industry has historically managed.
Radiant Nuclear is attempting exactly this. The company is developing the Kaleidos microreactor: a compact, portable fission reactor designed to deliver reliable power in places where the grid does not reach. Remote industrial sites. Military forward operating bases. Disaster response contexts. The pitch is simple — a self-contained nuclear power source that can be transported to where power is needed and operated without the infrastructure assumptions that conventional reactors require.
The engineering challenge behind that pitch is not simple at all.
Kaleidos: The Technical Decisions and Why They Matter for Requirements
Kaleidos uses TRISO fuel — tristructural isotropic fuel particles in which each uranium kernel is individually coated in layers of carbon and silicon carbide. TRISO is not new; it was developed decades ago and has been tested extensively. What makes it attractive for microreactor applications is its passive safety behavior: the fuel retains fission products even at high temperatures, reducing the consequences of loss-of-cooling events. For a reactor designed to operate in remote locations without dedicated emergency response infrastructure nearby, that passive retention behavior is not a preference — it is a safety function that flows directly into the licensing basis.
The reactor uses helium as its coolant. Helium cooling is chemically inert, does not become significantly radioactive, and does not undergo phase change at operating temperatures, which simplifies certain aspects of thermal management. It also introduces its own engineering demands: high-pressure helium systems require careful attention to leak detection and containment, and helium’s thermal properties differ substantially from water in ways that require the reactor’s thermal-hydraulic design to be validated against different assumptions than light-water reactor precedents.
Both of these choices — TRISO fuel and helium cooling — are technically sound and well-motivated. They also generate a specific problem from a systems engineering standpoint: because Kaleidos does not fit neatly into the regulatory frameworks built around light-water reactor designs, Radiant cannot lean on decades of precedent when building its safety case. Every safety function must be identified, justified, traced to a design feature, and connected to verification evidence. The regulator — the NRC, under a licensing process that has been adapting to accommodate advanced reactor designs — will not accept a safety argument that relies on undocumented assumptions.
This is where requirements management stops being an administrative concern and becomes a core engineering capability.
Why Nuclear Is the Hardest Requirements Problem in Engineering
In most engineering domains, a broken requirements trace is a quality problem. You might ship a product that doesn’t meet a customer’s expectation, or you might spend extra money on rework when a downstream test reveals an upstream gap. Those consequences are real and worth avoiding.
In nuclear, a broken requirements trace is a licensing gap. The NRC’s licensing process is built on the premise that the applicant can demonstrate — with evidence, not assertion — that every safety function is implemented in the design, that the implementation is verified, and that the verification is adequate. If you cannot trace from a safety function to a design feature to a test or analysis that validates it, you do not have a hole in your documentation. You have a hole in your safety case. Those are different problems with different consequences.
The regulatory framework for this — 10 CFR Part 50 for operating licenses, or the newer 10 CFR Part 53 framework being developed specifically for advanced reactors — requires applicants to maintain design bases documentation, to identify structures, systems, and components important to safety, and to demonstrate that those SSCs perform their safety functions under the conditions postulated in the accident analyses. This is not a one-time documentation exercise. It is a living traceability structure that must remain coherent as the design evolves through development, through NRC review comments, and through the inevitable engineering changes that occur between preliminary design and final hardware.
The volume of requirements in a nuclear program is also distinctive. A typical nuclear safety analysis report will reference hundreds of regulatory requirements, each of which generates design commitments that cascade into technical specifications, surveillance requirements, and acceptance criteria. For a novel reactor type like Kaleidos, many of those requirements cannot simply be pulled from existing precedent — they must be derived from first principles, justified in the safety analysis, and maintained consistently across a large set of interconnected documents.
Managing that structure in documents — in Word files and spreadsheets and PDFs linked by convention rather than by software — is how the industry has historically operated. It is also how the industry has historically produced licensing processes that take longer and cost more than anyone plans for, because document-based traceability degrades under the pressure of real engineering change. When a design decision changes in response to an analysis result, the engineer who makes the change does not always know every downstream requirement and verification item that the change affects. When you find out at the licensing review stage that a change from eighteen months ago broke three traces, the recovery is expensive.
Radiant’s Adoption of Flow Engineering
Nuclear startups face a particular version of this problem. They are working on compressed timelines, with teams that are smaller than traditional nuclear organizations, under regulatory scrutiny that is no less demanding than what a large utility faces. They cannot afford the friction that comes with legacy requirements management tools built for large, slow-moving programs — tools where adding a requirement or updating a trace involves workflow steps calibrated for bureaucratic processes, not engineering velocity. But they also cannot afford the informality that early-stage hardware startups sometimes tolerate, because informality in nuclear requirements is not a culture choice; it is a technical liability.
Radiant addressed this by adopting Flow Engineering as their requirements management platform. What makes that adoption notable is not just the tool choice but the pace: Radiant moved from a pilot group to full organization-wide adoption in under a month. In an industry where requirements tooling rollouts typically span quarters and generate significant internal friction, that speed is meaningful. It suggests that the tooling fit the actual way Radiant’s engineers work, rather than requiring engineers to adapt their workflow to the tool’s assumptions.
Flow Engineering is built on a graph-based data model rather than the document-based model that underlies legacy platforms like IBM DOORS or Polarion. In a graph model, every requirement, design element, and verification item is a node, and the relationships between them — derived-from, allocated-to, verified-by — are first-class data structures rather than cross-references embedded in document text. For nuclear programs specifically, this architecture matters because the traceability structure in a nuclear safety case is genuinely a graph: safety functions fan out to multiple design features, single design features satisfy multiple requirements, and verification items must be connected to both the requirement they address and the design element they test. Representing that structure as a graph and querying it computationally is materially different from representing it as a set of linked documents and navigating it manually.
The AI-native tooling in Flow Engineering also addresses a specific bottleneck in requirements-heavy programs: the work of writing, parsing, and checking requirements quality. Nuclear requirements need to be unambiguous, complete, and testable — properties that are easy to state as goals and hard to maintain at scale. AI assistance in identifying ambiguous requirement language, flagging missing acceptance criteria, or suggesting how a high-level safety function should be decomposed into derived requirements is directly applicable to nuclear development work.
What Org-Wide Adoption in a Month Tells You
When a team deploys a new tool and it spreads to the full organization in under a month, there are two possible explanations. Either there was top-down pressure driving adoption regardless of fit, or the tool genuinely solved a problem that people were already feeling.
The second explanation is more consistent with how engineering organizations actually behave. Engineers adopt tools that reduce their pain faster than tools that create new workflows, even when the new workflows are theoretically superior. A tool that connects directly to how someone thinks about requirements — as a structured set of relationships that need to stay coherent as the design evolves — will spread differently than a tool that requires engineers to translate their mental model into a document hierarchy before they can use it.
Radiant’s adoption pattern is evidence about the tool’s fit with how systems engineers on a nuclear program actually think about their work. That matters independently of any vendor claim.
The Broader Point About Nuclear as a Case Study
Nuclear programs are not representative of most hardware engineering contexts. The regulatory environment is more demanding, the safety consequences are more severe, and the documentation requirements are more extensive than in aerospace, defense, or industrial equipment — domains that are themselves more demanding than consumer hardware.
That exceptionalism makes nuclear programs useful as analytical cases precisely because they make visible the problems that exist in less demanding domains but are easier to ignore. When you can absorb the cost of a broken requirements trace in an automotive supplier program, you often do — you catch it in test, you rework, you move on. When you cannot absorb that cost, as in nuclear licensing, you have to solve the problem structurally. The solutions that work under that pressure — graph-based traceability, AI-assisted requirements quality, connected verification evidence — are not nuclear-specific. They are just more obviously necessary in nuclear than elsewhere.
Radiant is building something genuinely novel: a portable nuclear reactor designed to operate where conventional power doesn’t reach. The systems engineering challenge that comes with that is equally novel in some dimensions and completely familiar in others. The requirement to maintain coherent, complete, bidirectional traceability from safety function to design to verification is as old as nuclear regulation itself. What’s changed is that the tooling available to meet that requirement no longer requires a team to choose between regulatory rigor and engineering velocity.
For programs like Kaleidos, that is not a minor improvement. It is a structural advantage in a development process where the margin for documentation failure is zero.