Fusion Energy’s Systems Engineering Problem: Why Building a Tokamak Is Also a Requirements Management Problem

Commonwealth Fusion Systems expects to demonstrate net energy gain with SPARC by the end of this decade. Helion has a contractual delivery commitment to Microsoft. TAE Technologies is pursuing its own confinement approach on investor timelines that don’t accommodate the decade-long schedule slips that characterized government fusion programs. Zap Energy is trying to eliminate the magnets entirely.

Each of these companies is building a system of extraordinary physical complexity — and each of them is discovering, at varying stages of development, that the hardest part of fusion engineering is not just the plasma physics. It’s knowing what every subsystem requires from every other subsystem, and knowing it accurately, in real time, as the design changes.

This is a requirements management problem. Fusion startups are now facing it directly.

What Makes Fusion Systems Architecturally Different

The interdependency density in a fusion device is not just high — it is structurally different from most complex systems. In an aircraft, most subsystems interact through well-defined interfaces: mechanical load paths, electrical buses, data buses, hydraulic lines. The interfaces are physical and separable. A change to the avionics architecture does not typically alter the structural loads.

In a tokamak or other confinement device, the subsystems interact through physics. The magnetic field configuration determines where the plasma sits and how it behaves. The plasma behavior determines the neutron flux distribution. The neutron flux distribution determines the shielding requirements. The shielding requirements constrain the geometry available to the magnet coils. The magnet coil geometry feeds back into the magnetic field configuration.

This is not a linear dependency chain — it is a loop, and there are dozens of these loops entangled in a working fusion device.

Consider a specific example. Commonwealth Fusion’s SPARC design uses high-temperature superconducting (HTS) magnets operating at fields above 20 Tesla — substantially higher than any previous tokamak. That field strength is central to their compact-device strategy. But it imposes requirements that cascade immediately: the magnet structural systems must handle the mechanical forces, the cryogenic systems must maintain the operating temperature, and the shielding must protect the HTS tape from neutron-induced degradation that would raise the critical current threshold and change the achievable field.

Change the shielding thickness, and you change the available bore. Change the available bore, and you change the plasma geometry. Change the plasma geometry, and the entire physics basis for the device shifts. Every one of those dependencies is a requirement relationship, and every one of them needs to be traceable if you want to understand the impact of a design decision before you commit to it.

TAE Technologies operates under a different physics model — their approach pursues a field-reversed configuration rather than a tokamak, which changes the specific interdependency map but does not reduce its density. Zap Energy’s sheared-flow-stabilized Z-pinch eliminates superconducting magnets as a major subsystem, which genuinely simplifies parts of the dependency structure. But it introduces other coupling: the pulsed power system that drives the pinch has its own demanding requirements on electrical storage, switching, and structural integrity under repetitive high-energy discharge. Helion’s approach, which aims for direct energy conversion from the plasma, adds another layer — the recovery system must be integrated with the confinement system in ways that a pure-fusion-for-heat design does not require.

Each architecture has its own interdependency topology. None of them is simple.

Requirements Volatility: The Fusion-Specific Problem

In aerospace, requirements volatility — the rate at which requirements change over the program lifecycle — is considered a major program risk factor. The F-35 program is the canonical cautionary tale: requirements growth and instability contributed directly to cost and schedule overruns that exceeded initial estimates by factors of two or three.

Aerospace programs, however, deal with requirements that are primarily driven by operational need, regulatory mandate, and manufacturing capability. The physics of flight are well understood. Engineers know how wings work. The uncertainty is in integration and manufacturing, not in whether the underlying physics will behave as modeled.

Fusion programs face a qualitatively different kind of requirements volatility. The physics are not fully understood. Plasma confinement at the conditions required for net energy gain has never been sustained for commercially relevant durations. When the physics surprises you — when the plasma exhibits an unexpected instability mode, or when neutron activation produces an isotope that wasn’t fully accounted for in the shielding model — requirements do not just change. They change in ways that propagate through the interdependency loops described above.

This means that fusion programs will experience requirements churn that is not a sign of poor planning. It is a structural feature of developing at the frontier of known physics. The question is not whether requirements will change, but whether the program has the infrastructure to track those changes and understand their downstream implications before they manifest as integration failures.

This is exactly the condition under which requirements traceability transitions from a documentation bureaucracy to an operational engineering capability.

How Fusion Startups Are Approaching the Tooling Question

The four major private fusion companies are not taking uniform approaches to systems engineering tooling, and the differences are instructive.

Commonwealth Fusion, which emerged from MIT’s plasma science program and has the deepest ties to traditional academic and government fusion research culture, has approached systems engineering with a level of rigor that reflects both its institutional heritage and its investor profile. The company has attracted engineering talent from aerospace and defense — sectors where formal requirements management is standard practice — and that has influenced their tooling choices. Reports from engineering job postings and conference presentations suggest use of formal MBSE (Model-Based Systems Engineering) practices, though the specific toolchain is not publicly disclosed.

Helion, which operates more like a technology startup in its internal culture, has been more internally focused in its systems engineering approach. The company has grown rapidly and its contractual commitment to Microsoft creates an external forcing function for schedule and performance accountability that many fusion programs have never faced. That external pressure creates natural incentives for traceability — when you have a signed power purchase agreement, “we weren’t tracking that dependency” is not an acceptable explanation for a delay.

TAE Technologies, which has been developing its approach for more than two decades and has had multiple generations of experimental machines, has a more mature internal systems engineering practice simply by virtue of having been through multiple design-build-test cycles. Institutional memory of previous design decisions is real and valuable, but it is also exactly the kind of knowledge that lives in documents, spreadsheets, and people’s heads — and that is most at risk when a program scales, accelerates, or loses key personnel.

Zap Energy is the youngest and smallest of the four companies profiled here. Their simplified magnet architecture reduces some interdependency density, but their pulsed power approach creates its own requirements complexity. As a smaller team moving quickly, the temptation to defer formal requirements management is high — and the consequences of that deferral are highest at integration time, which is exactly when schedule pressure is also highest.

What Aerospace Learned, and What Fusion Can Apply

The aerospace industry’s experience with complex systems engineering is the closest relevant analog fusion companies have, even though the physics are different. Several specific lessons transfer directly.

Interface control documents are not enough. ICDs define what subsystems exchange at a boundary. They do not capture why those exchanges are specified as they are, or what requirement upstream drove the specification. When the upstream requirement changes, the ICD may need to change too — but without traceability, you don’t know the ICD needs to change until someone discovers the mismatch in hardware.

Requirements drift is invisible until it isn’t. In long-duration programs, requirements accumulate informal modifications. Engineers make local decisions that make sense given their subsystem view but violate assumptions in adjacent subsystems. In aerospace, this has produced integration surprises on programs including the James Webb Space Telescope, which required hundreds of post-environmental-test rework activities, and various DoD programs where late-discovered requirements conflicts drove significant cost growth. Fusion programs running on investor timelines do not have the government program’s cushion to absorb those surprises.

Change impact analysis must be systematic, not heroic. In well-run aerospace programs, a change request triggers a formal impact analysis that traces through the requirement structure to identify all affected elements. In programs without that infrastructure, impact analysis becomes a function of who happens to know the right connections — which means it is inconsistent, schedule-dependent, and vulnerable to personnel turnover.

Verification traceability closes the loop. Requirements traceability isn’t just about requirements — it includes the link from requirement to verification activity. If a requirement exists but has no verified test or analysis, it is, operationally, an unconfirmed assumption. Fusion programs that are building first-of-kind hardware need to know exactly where their assumption-to-verification gap sits, because those gaps are where integration surprises live.

What Modern Tooling Actually Enables

The shift from document-based requirements management to graph-based, AI-assisted tooling is directly relevant to fusion’s interdependency problem. Traditional tools — IBM DOORS and its successors, spreadsheet-based RTMs — store requirements as lists or hierarchies. They can express parent-child relationships and can link requirements to test cases, but they represent the requirement structure as documents. The interdependency topology of a fusion device is not a document. It is a graph.

Graph-based platforms allow requirement relationships to be modeled as they actually exist: a neutron shielding requirement can carry explicit traced links to the magnetic field configuration requirement that constrains geometry, to the cryogenic system requirement that depends on shielding effectiveness, and to the verification activity that confirms shielding performance. When the physics model updates and the shielding requirement changes, the graph makes the propagation visible.

Tools like Flow Engineering are built specifically for this kind of connected traceability in hardware and systems programs. Rather than treating requirements as rows in a document, Flow Engineering models them as nodes in a dependency graph — which is structurally aligned with how fusion subsystem interdependencies actually work. For a fusion program where a single physics discovery can ripple through dozens of downstream requirements, the ability to ask “what else does this change affect?” and receive a complete, automated answer is not a convenience feature. It is the difference between discovering a requirements conflict during design review and discovering it during integration test.

The AI-native aspect matters for another reason specific to fusion: requirements often emerge from physics analysis, simulation results, and experimental data rather than from stakeholder interviews. A tool that can connect structured requirements to the analyses that derived them — and flag when updated analysis implies a requirement change — is better suited to fusion’s requirements volatility than a tool designed around stable, human-specified requirements that change slowly.

The Stakes of Getting This Wrong

Fusion’s investor community has been patient, but not infinitely so. Commonwealth Fusion has raised over $2 billion. Helion has raised more than $500 million and has a signed contract. TAE has raised comparable amounts over its history. Zap Energy has attracted significant capital on a promise of simplicity.

At these funding levels, the cost of an integration failure that traces back to an untracked requirements conflict is not just financial. It is existential for programs operating on private timelines without the government backstop that the large national labs historically provided.

The plasma physics is hard and will remain hard. But the systems engineering is tractable. The tools exist to manage interdependency at fusion’s scale. The lesson aerospace learned over fifty years of complex systems development is available now, and fusion startups have the opportunity to apply it before integration, not after.

The programs that treat requirements management as an engineering discipline rather than a compliance activity will be better positioned to absorb the physics surprises that are guaranteed to come. The ones that defer it will pay for that decision at the worst possible time.