Fusion Energy Is Learning to Model Itself

When engineers at ITER in southern France need to understand how a planned modification to the blanket cooling system affects the tritium breeding ratio, the neutron shielding margins, the remote maintenance access paths, and the plasma-facing material certifications simultaneously, they cannot simply run a search across a SharePoint library. The interactions are too deep, too bidirectional, and too consequential. A change in one domain is a change in a dozen others — often in ways that become visible only when someone has manually traced through three specification documents and two interface control documents that were last updated in different years.

This is the central engineering problem of fusion energy: not plasma physics, not materials science, not even neutron flux — those are hard, but they are disciplined fields with mature analytical tools. The hardest problem in fusion is keeping the engineering model of a fusion machine coherent across the organizations, disciplines, and time horizons required to build one.

Model-Based Systems Engineering (MBSE) is the field’s answer to that problem. Adoption is uneven, the tooling remains imperfect, and the gap between MBSE aspiration and daily practice is large. But the trajectory is clear. Fusion programs — government and private — are beginning to build the systems engineering infrastructure that a working fusion power plant will eventually require.

The Interface Complexity Problem Is Unique to Fusion

Most complex engineering programs have disciplinary silos. Fusion programs have disciplinary silos that are also physically coupled in ways that are unusual even by aerospace and nuclear standards.

Consider the interface matrix of a tokamak:

  • Plasma physics drives first-wall geometry, which drives blanket design, which drives tritium breeding, which drives tritium processing, which is itself a major chemical engineering and safety subsystem.
  • Superconducting magnets impose cryogenic infrastructure requirements that conflict with neutron shielding geometry and remote maintenance access — simultaneously.
  • High-voltage power systems for the central solenoid and poloidal field coils interact with plasma disruption scenarios in ways that require coordinated analysis across electromagnetic engineering, structural analysis, and control systems.
  • Remote maintenance systems — the robotics and tooling required because no human can enter the activated vessel — must be designed to tolerances that feed back into structural requirements on the components being maintained.

The interface count in a tokamak design is not dozens. It is hundreds, potentially thousands, depending on the level of decomposition. ITER’s formal interface register has exceeded 1,200 defined interfaces across its seven domestic agencies. That number is not an artifact of bureaucracy. It reflects the physics.

Document-based engineering manages this through ICDs — Interface Control Documents — supplemented by requirements databases and change control boards. The system works, in the sense that buildings have been built using slide rules. But it works slowly, it accumulates inconsistency, and it has no mechanism for propagating the downstream consequences of a change. When an ICD is updated, the systems that depend on it do not know they have been affected until a person notices and tells them.

Where MBSE Adoption Is Strongest: ITER and the Government Programs

ITER is the most formally MBSE-engaged fusion program in the world, which is saying something modest given where the bar is set. The organization has been building out a systems engineering function for more than a decade, drawing standards from nuclear safety (IEC 61508, ISO 19443), aerospace systems engineering (NASA SE Handbook, INCOSE SE Handbook), and defense acquisition practices. Their requirements management infrastructure uses IBM DOORS — the industry-standard tool in nuclear and aerospace — and their configuration management practices are among the most rigorous of any civilian engineering program.

The practical limitation at ITER is that DOORS is a document-oriented database that predates the kind of graph-based, behavior-modeling-first approach that MBSE methodologies like SysML were designed to support. ITER has MBSE aspiration and documentation infrastructure. What it has not yet fully built is a living system model — a connected representation of the machine in which requirements, behaviors, interfaces, and verification evidence are explicitly linked and maintained as an integrated whole. The DOORS installation captures requirements. It does not model the system.

There are exceptions. The remote handling program has developed some of the most sophisticated MBSE practice in the ITER ecosystem, partly because remote handling is a domain — robotics and automated systems — where model-based design is more culturally native. The magnet systems group has similarly applied model-based approaches in coil design and qualification. But these are subsystem islands, not a connected system model.

The National Ignition Facility (NIF) and broader ICF programs at Lawrence Livermore, and the U.S. fusion program at large — Princeton Plasma Physics Laboratory, MIT’s Plasma Science and Fusion Center, Commonwealth Fusion Systems’ public-sector collaborators — have varying MBSE maturity. The Department of Energy’s Milestone-Based Fusion Development Program, which funds several private ventures, has begun requiring more formal systems engineering deliverables from grantees, creating a compliance pressure that is slowly pulling MBSE practices upstream.

Where Adoption Is Fastest: The Private Fusion Ventures

The private fusion sector is a useful natural experiment. Commonwealth Fusion Systems (CFS), TAE Technologies, Helion Energy, and their peers are building complex machines on timelines and budgets that cannot absorb the overhead of traditional document-based systems engineering at scale. They also have no legacy institutional tooling to protect.

CFS has been the most public about its systems engineering approach, partly because its SPARC device — a high-field compact tokamak using REBCO superconducting tape — required aggressive design iteration that document-centric processes would have blocked. The high-temperature superconductor approach introduced new design parameters (field strength, quench behavior, coil assembly tolerances) that cascaded through the machine in ways that demanded fast, traceable change management. Their systems engineering team has invested in model-based approaches, drawing from aerospace supply chain practices — not surprisingly, given how many CFS engineers came from the defense and aerospace sectors.

Helion’s approach is structurally different — field-reversed configuration rather than tokamak — but the systems engineering problem is similar: a small team managing a large interface matrix under time pressure. Helion’s engineering culture leans heavily on computational modeling, which creates a natural affinity for MBSE thinking even when the formal methodology hasn’t always been named as such.

TAE Technologies, operating with fusion-plus-accelerator physics, has one of the more unusual interface matrices in the sector — high-energy particle beam physics intersecting with plasma confinement intersecting with power electronics at a level of coupling that has few precedents. Their systems engineering approach has been less publicly documented, but the engineering challenge is an MBSE problem by definition.

The private sector pattern is consistent: faster adoption, less formal standards compliance, more tool flexibility, and — critically — a shorter feedback loop between systems engineering decisions and engineering outcomes. When you have 200 engineers instead of 2,000 and a five-year runway instead of a 35-year construction schedule, the cost of a bad requirements decision is visible faster.

The Standards Gap

Fusion programs borrowing from nuclear, aerospace, and defense standards are borrowing from frameworks that were not designed for fusion’s specific combination of challenges.

Nuclear safety standards (NRC 10 CFR 50, IEC 61508, EUR standards) are mature and rigorous but oriented toward fission reactor safety cases, where the dominant hazard model — loss-of-coolant, reactivity insertion — differs from fusion’s dominant hazards (tritium release, activated dust, magnet quench, disruption loads). The safety function decomposition that nuclear standards assume does not map cleanly onto fusion machine architecture.

Aerospace systems engineering standards (NASA/SP-2016-6105, MIL-STD-882, DO-178C for software) are conceptually well-matched to fusion’s design decomposition and verification challenges, but assume a mission profile — a defined operational life, a launch constraint, a mass budget — that fusion machines replace with a continuous operational availability requirement and a fuel cycle that has no aerospace analog.

Defense acquisition standards (MIL-STD-31000, the INCOSE SE Handbook) provide the most generally applicable frameworks for complex system development, and are probably the dominant influence on how MBSE is actually being practiced in private fusion ventures. But they were designed for systems with defined adversarial requirements, which introduces traceability structures that do not quite fit a physics-driven machine.

The honest answer is that fusion does not yet have its own systems engineering standard. What exists is a patchwork of borrowed frameworks, applied with varying rigor and adapted with varying skill. The ITER Organization has done more than anyone to develop fusion-specific systems engineering guidance, but that guidance is internally focused and not yet codified in a way that the broader community draws from.

Where the Practice Actually Lags

Being precise about where MBSE adoption in fusion is weakest is more useful than a general critique.

Cross-domain system-level traceability is the largest gap. Individual subsystems — magnets, blanket, remote handling, tritium systems — often have defensible internal requirements traceability. What almost no fusion program has is a connected model that traces from top-level system requirements (plasma performance, availability, safety case) through functional architecture, physical architecture, interface definitions, and down to component specifications, with bidirectional linkage maintained. That model, if it existed, would let an engineer ask “what is affected if I change the first-wall tile geometry?” and get a traceable, comprehensive answer. It does not exist in any fusion program at scale.

Verification and validation planning connected to the system model is similarly immature. Fusion programs have V&V plans. Those plans are mostly documents, not model artifacts. Closing a requirement requires a human to update a document. The connection between verification evidence and the requirement being verified is indirect, fragile, and frequently stale.

Interface management across organizational boundaries — the multi-party problem at ITER, or the supply-chain problem at CFS — remains largely document-dependent. The interface register exists. Dynamic interface analysis, where the system model propagates the implications of an interface change across affected requirements, does not.

Modern Tooling and the Direction of Travel

The tooling gap in fusion MBSE is closing, though not uniformly. The pattern in aerospace and defense — where tools like Jama Connect and Polarion replaced pure document workflows, and where graph-based, AI-native platforms are now entering the space — is beginning to repeat itself in fusion.

The shift matters because the specific capabilities fusion needs — bidirectional traceability across hundreds of requirements, impact analysis on interface changes, AI-assisted requirement consistency checking, integration with CAD and simulation models — are not capabilities that first-generation requirements databases were designed to provide. IBM DOORS is coherent and reliable for what it was designed to do: store and version requirements text. It was not designed to model a system.

Platforms built around graph data models, where requirements, functions, interfaces, and verification artifacts are nodes and relationships in a connected graph rather than rows in a database, are better suited to fusion’s interface complexity. Tools like Flow Engineering, which was designed for hardware and systems engineering teams working with dense interdependency, represent the direction the tooling needs to go: model-first rather than document-first, with AI assistance for consistency analysis and impact assessment, and traceability that is structural rather than manually maintained.

The fusion programs moving fastest — CFS and Helion most visibly — are the ones most likely to adopt tooling in this category. The programs with the longest institutional history are the ones most constrained by existing tool investments.

Honest Assessment

Fusion energy’s MBSE adoption is real, uneven, and at an inflection point. The conceptual case for MBSE in fusion is overwhelming — no one who understands both the engineering and the methodology disputes that document-based systems engineering cannot manage fusion complexity at scale. The practical adoption curve is slower than the conceptual case warrants, for reasons that are familiar from every other complex engineering domain: legacy tooling, institutional inertia, workforce capability, and the genuine difficulty of transitioning a live program to new engineering practice mid-stream.

The most important near-term development is not a tooling choice or a standards decision. It is whether the fusion sector develops shared systems engineering reference architectures and ontologies — common ways of decomposing and naming the system — that allow programs to build from accumulated knowledge rather than starting the model from scratch. Aerospace took decades to build that shared infrastructure. Fusion does not have decades.

The programs that get to a working fusion power plant first will almost certainly be the ones that solved the systems engineering problem alongside the physics problem — not after it.