How Should a Fusion Energy Company Approach Requirements When the Physics Is Still Being Characterized?

The requirements management challenge facing a fusion energy company is genuinely unlike anything encountered in aerospace or automotive development. A satellite manufacturer writing thermal requirements can pull from decades of on-orbit telemetry. An automotive OEM writing crashworthiness requirements is working within a well-established regulatory envelope, refined over generations of physical testing. The physics is known. The question is execution.

Fusion programs in 2026 do not have that luxury. Whether the approach is tokamak, inertial confinement, field-reversed configuration, or any of the other configurations currently under development, programs are attempting to define performance requirements against physical regimes that have not yet been fully characterized — and in some cases, against phenomena that have not yet been reproducibly demonstrated at engineering scale. The requirement uncertainty is not a symptom of poor systems engineering. It is structural. Any requirements methodology that does not account for this will produce either a frozen specification that becomes wrong as the science matures, or a specification so loosely written that it cannot guide design decisions.

The answer is neither. There is a rigorous, operational approach to managing requirements under deep uncertainty — one that has been refined in other first-of-kind domains and is now being implemented by the most technically sophisticated fusion development programs.

The Core Problem: You Are Writing Requirements for a System You Cannot Yet Fully Model

In a conventional development program, requirements flow from a validated operational concept through a physics model that is, at worst, empirically calibrated. The model uncertainty is bounded. Margins are sized to cover manufacturing variation, environmental variation, and model inaccuracy — all of which are reasonably well-characterized.

On a fusion program, the model uncertainty itself is often the dominant term. Plasma confinement scaling relationships, tritium breeding ratios in candidate blanket materials, neutron flux distributions in geometries that have never been built — these are active research questions. A systems engineer writing a requirement for tritium breeding ratio in a lithium-ceramic blanket module is, in part, writing a requirement for a physical quantity that theory predicts but experimental validation has not yet confirmed at the required scale and operating condition.

This is the defining challenge: how do you write requirements that are useful for engineering design when the underlying physics is still being characterized?

Classifying Requirements by Epistemic Status

The first operational practice is to stop treating all requirements as epistemically equivalent. On a mature program, a structural load requirement derived from well-validated finite element methods and a plasma-facing component heat flux requirement derived from transport codes that have not been validated at the target plasma parameters are not the same kind of requirement. Treating them identically — applying the same change control processes, the same margin policy, the same verification approach — produces a specification that is either over-constrained where the physics is actually uncertain or under-constrained where the physics is well understood.

Effective systems engineering on first-of-kind fusion programs explicitly distinguishes between:

Physically well-understood requirements. These are requirements that derive from physical regimes where the governing equations are validated, the material properties are well-characterized, and the uncertainty is dominated by engineering execution rather than physics knowledge. Structural requirements in well-understood load regimes, heat transfer requirements in regimes where the relevant fluid dynamics is validated, electrical insulation requirements where the relevant failure modes are documented — these belong in this category. They can be specified with conventional margin policies and verified against well-established models.

Knowledge-limited requirements. These are requirements that derive from physical regimes where either the governing physics is incompletely characterized, the material behavior at the relevant conditions is poorly constrained, or the system interactions are complex enough that first-principles modeling has not been validated. Plasma-facing material erosion rates under burning plasma conditions, tritium permeation rates through structural alloys under neutron irradiation, thermal-hydraulic behavior in breeding blanket designs that have not been tested at scale — these belong here. They cannot be specified with the same confidence as the first category, and a specification that presents them as equally certain is misleading.

The practical implication: knowledge-limited requirements must be explicitly flagged as such in the requirements management system, they must carry a stated confidence level or uncertainty bound, and they must be linked to the specific experimental campaigns or analyses that are expected to mature them. If that linkage does not exist, the program has no systematic way to know when a requirement should be revisited, tightened, or relaxed as knowledge improves.

Design Margins as Uncertainty Placeholders

On mature programs, design margin is sized to cover manufacturing variation and model inaccuracy within a known distribution. The margin is a buffer against execution uncertainty.

On fusion programs with knowledge-limited requirements, margin must additionally cover physics uncertainty — and that uncertainty is often not characterized well enough to assign a confident probability distribution. In this context, design margin is functioning as an explicit placeholder for unresolved knowledge, not just a buffer against execution variance.

This changes how margin decisions must be documented. Every significant margin applied to a knowledge-limited requirement should trace directly to the specific physics uncertainty it is covering. What phenomenon is not yet characterized? What is the current best estimate, and what is the range of physically plausible values? What is the consequence to the design if the actual value is at the adverse end of the plausible range?

Without this traceability, margin decisions are opaque. When the experimental campaign that was expected to characterize the relevant physics delivers results, the systems engineering team has no systematic way to determine which margins are now adequately justified and which should be revisited. The margin becomes disconnected from the knowledge that is supposed to inform it.

Traceability from margin decisions to the experimental or analytical basis — including the expected maturation pathway — is not optional bookkeeping. It is the mechanism by which a first-of-kind program converts scientific progress into engineering decisions.

Probabilistic Requirement Specification

For knowledge-limited requirements where enough information exists to characterize the uncertainty distribution — even roughly — probabilistic specification is a more honest and more useful approach than single-point specification with an unstated margin.

Rather than specifying a tritium breeding ratio of ≥ 1.05 as a hard requirement, a program operating under genuine physics uncertainty might specify a required probability that the as-built system achieves self-sufficiency, conditional on the current state of knowledge about blanket performance. The requirement then carries an explicit statement of the knowledge basis: which models were used, what the validation status of those models is, and what experimental results would shift the probability estimate.

This approach has several concrete advantages. It forces the program to be explicit about what it knows and does not know. It creates a natural decision framework: as experimental campaigns deliver results, the probability estimate is updated, and requirements are tightened or relaxed accordingly. It prevents the requirement from being treated as a design truth when it is actually a design hypothesis.

Probabilistic specification is not appropriate for all requirements, and it is not a substitute for eventually converging on deterministic specifications as knowledge matures. But for knowledge-limited requirements on early-stage fusion programs, it is more intellectually honest and more practically useful than presenting false precision.

Staged De-Risking Campaigns as the Requirements Maturation Mechanism

The structured approach to managing requirement uncertainty on first-of-kind programs is to define an explicit de-risking campaign sequence — a set of experiments, analyses, and sub-scale demonstrations whose purpose is specifically to mature knowledge-limited requirements.

This means the requirements management system must connect forward to the experimental roadmap, not just backward to the requirements baseline. Each knowledge-limited requirement should have an explicit maturation pathway: what experiment or analysis is expected to reduce the uncertainty, when is it scheduled, and what result would be required to justify tightening the requirement to a specific value?

Without this connection, de-risking campaigns can succeed technically while failing to update the requirements basis. A program might complete a materials irradiation experiment that significantly narrows uncertainty on tritium permeation, but if the results are not systematically fed back into the requirements that depend on that physical quantity, the engineering design continues to operate against an outdated uncertainty envelope.

The connection is bidirectional. Requirements should reference the experimental campaigns that are expected to mature them. And when campaign results arrive, the requirements management system should surface which requirements are now ready for re-evaluation. This is not how most requirements management tools work — they are built for stable specifications, not for specifications that are expected to evolve as knowledge improves.

How Modern Tools Support Uncertainty-Aware Requirements Management

Traditional requirements management tools — DOORS, Polarion, Jama — were designed for programs where the requirements are fundamentally stable after baselining. Their change management workflows are oriented toward controlling deviation from a fixed baseline, not toward systematically tracking requirement maturation over time.

Flow Engineering takes a different structural approach that maps more naturally to the fusion development context. Requirements in Flow Engineering are represented as nodes in a graph model, which means the relationships between requirements, their derivation basis, their verification activities, and their knowledge sources are first-class objects in the system — not manually maintained cross-reference tables or traced documents.

For fusion programs specifically, this matters because it enables two practices that are difficult to implement in document-based tools. First, requirements can be tagged with confidence metadata — a structured attribute that captures the epistemic status of the requirement, distinguishing between physically well-understood specifications and knowledge-limited ones. This is not a free-text note; it is a structured property that can be queried across the requirements set, allowing program leadership to understand at a glance how much of the requirements basis is well-established versus tentative.

Second, those knowledge-limited requirements can be linked directly to the experimental campaigns or analyses expected to mature them. When a campaign delivers results, the link surfaces the requirements that are ready for re-evaluation. When a requirement is updated based on new knowledge, the graph model propagates the dependency — surfacing which downstream requirements, design constraints, and verification approaches are potentially affected.

Flow Engineering’s deliberate focus on connected traceability over document management means it does not replicate the document approval workflows or the change notice infrastructure that legacy-heavy programs sometimes require. For a fusion company operating primarily in the pre-regulatory environment of an early private program, this is typically not a limitation that matters. For a program that has contractually committed to a DOORS-based documentation structure with a government customer, the integration path is worth evaluating explicitly.

Practical Starting Points

For a fusion systems engineering team building out their requirements practice under genuine physics uncertainty, the concrete starting points are:

Separate the requirements set into physically well-understood and knowledge-limited categories from the beginning. This classification should be explicit in whatever tool the program uses, not inferred from context. The distinction drives different margin policies, different change control rigor, and different verification approaches.

Establish explicit maturation pathways for every knowledge-limited requirement. What campaign matures it? What result is needed? When is it scheduled? If you cannot answer these questions for a knowledge-limited requirement, the requirement is not yet fully specified.

Size design margins with explicit traceability to the physics uncertainties they cover. When experimental results arrive, margins should be revisitable because they are documented against specific uncertainties — not frozen because the program has lost the thread of why they were set.

Use probabilistic specification where the uncertainty distribution can be meaningfully characterized. Reserve single-point specifications with hard margins for requirements where the physics is well-enough understood to justify them.

Choose a requirements management tool that treats requirement metadata and traceability as first-class objects. A tool that models requirements as nodes in a graph — with confidence levels, maturation links, and dependency propagation — will support the iterative re-evaluation that first-of-kind programs require. A tool that models requirements as rows in a document will resist it.

Fusion development is not uniquely difficult because the engineering is hard. It is uniquely difficult because the engineering and the science are proceeding simultaneously, and the requirements must carry that uncertainty explicitly rather than hiding it behind false precision. Programs that build their requirements practice around that reality will be better positioned to make rational design decisions as the physics matures — and to know, systematically, when it has.