How Fusion Startups Are Reinventing Systems Engineering From Scratch

Commercial fusion energy is not a moonshot anymore. It is an engineering program. Commonwealth Fusion Systems is assembling SPARC. Helion has a contractual power delivery obligation with Microsoft. TAE Technologies has been running field-reversed configuration experiments for over a decade. Zap Energy is compressing plasma with sheared-flow stabilization and essentially no external magnets. These are distinct technical approaches, distinct risk profiles, and distinct systems engineering problems—but they share one structural reality: there is no established regulatory framework, no qualification precedent database, and no standard systems engineering methodology that maps cleanly onto what they are building.

That is both the opportunity and the hazard. Legacy fission programs operate under decades of NRC precedent, 10 CFR regulatory structure, and a quality assurance culture built around NUREG-0800. Fusion startups inherit almost none of that. They are free to be faster. They are also free to make category errors that won’t surface until they are trying to license a device that was never designed with regulatory engagement in mind.

What Fusion Startups Are Actually Borrowing

The honest answer is: a lot from aerospace, some from defense primes, and almost nothing from commercial fission—by choice.

Aerospace MBSE practices, particularly those formalized around SysML and the NASA Systems Engineering Handbook, have become the primary intellectual framework at several fusion companies. The logic is sound: fusion devices are cyber-physical systems with deeply integrated subsystems, high consequence failure modes, and an iterative design cycle that needs to track requirement changes across disciplines simultaneously. That describes a spacecraft or a launch vehicle as much as it describes a tokamak.

Commonwealth Fusion Systems has been explicit about applying aerospace-style gate reviews and interface control discipline to SPARC development. The company hired systems engineers with backgrounds at Northrop Grumman and SpaceX, not at Westinghouse or BWXT. That hiring pattern is visible across the sector. Helion’s engineering team includes people with satellite system and defense program backgrounds. The cultural default is: define your interfaces rigorously, version your requirements, trace your design decisions to those requirements, and treat an untraced design choice as a defect—not a judgment call.

Defense prime practices contribute something different: program structure for managing first-of-a-kind development under contractual scrutiny. Programs like DARPA-funded development or DOE fusion pilot plant awards carry milestone-based oversight that forces documentation discipline. Companies receiving DOE milestone-based funding under the Milestone-Based Fusion Development Program have had to demonstrate systems engineering artifacts—preliminary design reviews, technical baseline documents, interface control documents—to satisfy government review teams. That external forcing function is accelerating SE maturity faster than internal motivation alone would.

What fusion startups are deliberately not borrowing from fission is the document-centric quality assurance culture. NQA-1, the nuclear quality assurance standard, imposes procedural overhead that fission utilities and their contractors have absorbed over decades. For a startup with 200 engineers trying to reach net energy gain, adopting NQA-1 wholesale is not a viable path. The procedural burden would exceed the engineering bandwidth. Most fusion companies are treating NQA-1 as a future-state target for the back end of their commercial development, not as a day-one operating condition.

The Four Engineering Challenges That Break Standard Practice

Plasma-Facing Materials Qualification

Every fusion concept that achieves net energy gain will expose structural and functional materials to conditions that have no terrestrial qualification database. Neutron fluence from D-T fusion is approximately 14 MeV—higher energy than fission neutrons, and producing helium-generating (n,α) reactions in structural metals that fission data doesn’t fully characterize. Tungsten and tungsten alloys are the primary plasma-facing material candidates at CFS and most tokamak-adjacent approaches. The qualification path for tungsten under fusion-relevant neutron spectra does not currently exist at scale.

This is a systems engineering problem as much as a materials science problem. The requirement chain from “plasma-facing component must survive N full-power operating cycles” down to “material coupon must demonstrate X dpa (displacements per atom) tolerance at Y helium appm co-generation rate” has no established qualification test facility behind it. The US Material Plasma Exposure eXperiment (MPEX) at ORNL and the proposed fusion neutron sources like IFMIF-DONES in Europe are the planned qualification infrastructure—but they are not yet operational at the required scale. Fusion startups building toward pilot plants in the early 2030s are designing to requirements they cannot yet fully verify. Tracing those requirements forward to test plans, and flagging which verification methods are “analysis pending facility availability” versus “test complete,” is exactly the kind of structured ambiguity management that separates mature systems engineering from wishful thinking.

Superconducting Magnet System Integration

CFS’s REBCO high-temperature superconducting magnets achieved 20 Tesla in 2021 and represent a genuine technical milestone. The systems engineering challenge is not the magnet performance—it is the integration. A high-field tokamak like SPARC has superconducting coils that must be mechanically assembled around a vacuum vessel, cooled to operating temperature, instrumented for quench detection, and interfaced with power supplies, structural supports, and plasma control systems—all while maintaining the tolerances required for plasma position control.

Interface control between the magnet system and the balance of plant is where combinatorial complexity becomes dangerous. A tokamak has no clean modular decomposition. The cryostat interacts with the structural system, which interacts with the vacuum vessel, which interacts with the first wall, which interacts with the plasma control coils, which share cryogenic infrastructure with the main field coils. An interface change in one subsystem propagates through multiple others in non-obvious ways. Document-based interface control—the approach most fission programs use, with ICDs stored as PDFs under configuration management—breaks down under this level of interconnection. When an interface changes, you need to know immediately which requirements are affected, which subsystems are implicated, and which verification activities need to be replanned. That requires a connected graph of relationships, not a folder of documents.

Tritium Handling

D-T fusion produces tritium as a fuel and requires tritium breeding from lithium blankets at commercial scale. Tritium is a regulated radiological material, permeates metals at elevated temperature, and has a 12.3-year half-life. The tritium inventory management, accountancy, and confinement requirements for a commercial fusion plant will likely trigger NRC or Agreement State licensing even in the absence of fusion-specific regulation—tritium handling facilities are regulated today.

Zap Energy’s sheared-flow Z-pinch approach and TAE Technologies’ proton-boron fuel cycle are both designed to operate without tritium, which eliminates this challenge at the cost of higher plasma performance requirements. For D-T programs, tritium systems engineering requires integration between the fuel cycle, the breeding blanket, the vacuum system, and the tritium processing and accountancy systems. Each of those is a major subsystem with its own requirements baseline. Tracing the system-level tritium inventory requirement down through breeding ratio, permeation loss rates, processing throughput, and storage capacity—and keeping that trace current as design margins evolve—is not optional. It is the kind of work that determines whether you can satisfy a regulator.

Balance-of-Plant Interfaces

Fusion startups frequently describe their technology challenge as “getting to Q>1.” The systems engineering challenge is getting from Q>1 to electricity on the grid, which requires a balance of plant: heat exchangers, turbines, generators, electrical interconnection, cooling water systems, and control systems that interface with the fusion island. None of this is novel technology. All of it is mature industrial engineering. The interface between the fusion island and the BOP is where two engineering cultures collide.

The fusion engineering team has been operating with high tolerance for design fluidity. The BOP engineering team—typically industrial or power plant engineers—expects frozen interface specifications. Plasma output power fluctuates. Thermal interface temperatures depend on first wall and blanket design choices that may still be evolving. Helion’s direct energy conversion approach eliminates the thermal cycle entirely, which sidesteps some of this interface complexity—but introduces different integration challenges between the compression coils, the plasma, and the electrical output circuit. Managing that interface boundary, and keeping requirements on both sides of it consistent as the design evolves, requires deliberate interface management infrastructure.

The Maturity Curve That’s Coming

Fusion companies are currently distributed across a wide range of systems engineering maturity. Some have invested seriously in requirements management, interface control, and verification traceability from early in their programs. Others treated systems engineering as a compliance exercise and are now confronting what that choice means when a DOE review team or a Series D investor asks to see their technical baseline.

The forcing functions are real and approaching fast. Pre-application meetings with the NRC for fusion pilot plants require demonstrating that you have a coherent safety case structure—which requires traceability from safety functions to design features to verification methods. The NRC’s Advanced Nuclear Reactor guidance, and the fusion-specific draft regulatory framework under development, will establish expectations that fusion companies need to be ready for. Investors funding at the hundreds-of-millions to billion-dollar level are beginning to hire technical advisors who know what a PDR artifact package looks like and will ask for it.

Companies that built their requirements baseline in spreadsheets, or in general-purpose tools not designed for interconnected system models, are going to face reconstruction work. Requirements that were written to describe physics experiments don’t automatically scale into pilot plant system requirements. The gap between “our HTS magnets achieved design field” and “our magnet system satisfies requirements FR-MAG-001 through FR-MAG-047 with verified traceability to SPARC pilot plant system requirements” is not trivial to close retroactively.

Modern tools built for this kind of connected requirements and interface management—Flow Engineering is one example, purpose-built for hardware and systems engineering teams working on complex first-of-a-kind systems—offer graph-based models that can represent the interconnection between plasma physics requirements, subsystem design requirements, interface control documents, and verification status in a single queryable structure. That matters specifically for fusion because the interdependencies between subsystems are not hierarchical—they are networked. A tool that treats requirements as rows in a spreadsheet or pages in a document will not surface the propagation paths when a design change occurs. A tool that models them as nodes in a connected graph will.

Honest Assessment

The commercial fusion sector is doing systems engineering better than it gets credit for in the popular press, which tends to frame fusion as perpetually ten years away from anything useful. Several of these companies have real systems engineering infrastructure, real interface control discipline, and real verification planning. They are not operating at the maturity level of a mature defense prime or a licensed fission utility—but they are also not required to, yet.

The risk is the word “yet.” The companies that treat the upcoming regulatory engagement and investor scrutiny as an opportunity to formalize what they already know will be in a strong position. The companies that treat it as a documentation exercise to be done after the real engineering are setting themselves up for expensive reconstruction work at the worst possible time—when capital deployment decisions are being made and regulatory clocks are running.

Fusion is an engineering program now. Systems engineering is not overhead. It is how you prove the engineering is real.