General Atomics: Systems Engineering Across Drones, Fusion, and Nuclear
How one of America’s most technically diverse defense and energy companies maintains engineering discipline when the physics changes with every program
There are defense contractors, and there are energy companies, and occasionally a company tries to be both. General Atomics occupies a category of its own: a privately held, San Diego-based organization that builds operational military drones for the U.S. Air Force, manufactures superconducting magnets for an international fusion experiment in southern France, and produces uranium fuel for commercial and government nuclear reactors. These are not adjacent businesses. They share almost no regulatory framework, almost no technical vocabulary, and almost no common failure mode.
Understanding how General Atomics maintains engineering discipline across those three domains is a useful lens for any systems engineering organization grappling with portfolio breadth—whether that’s a Tier 1 defense prime managing both space and ground systems, or a smaller organization that has grown faster than its engineering process framework.
The Three Domains, Stated Plainly
Before analyzing the organizational challenge, it helps to be precise about what General Atomics actually builds in each domain.
Unmanned Aircraft Systems. General Atomics Aeronautical Systems, Inc. (GA-ASI) is the company’s most publicly visible division. The MQ-9 Reaper has flown over 1 million flight hours in U.S. Air Force service. Its successor, the MQ-9B SkyGuardian, is designed to meet NATO STANAG 4671 airworthiness standards, which positions it for operation in non-segregated airspace. The Mojave and Avenger programs extend the product line into turboprop STOL and stealthy jet configurations respectively. GA-ASI is, by any measure, the world’s most experienced developer of persistent surveillance and strike UAS.
Fusion Energy. General Atomics operates the DIII-D National Fusion Facility in San Diego under contract to the U.S. Department of Energy—the only tokamak-class experiment in the United States dedicated to fusion science. Beyond operating that machine, the company is a major U.S. supplier to ITER, the international fusion project under construction in Cadarache, France. GA’s contribution includes manufacturing the Central Solenoid, a roughly 60-foot-tall, 1,000-ton superconducting magnet that will generate the strongest pulsed magnetic field of any fusion device ever built. The Central Solenoid modules have been shipping since 2021.
Nuclear Technologies. General Atomics’ nuclear division covers uranium fuel fabrication, reactor design (including the Energy Multiplier Module, or EM², a helium-cooled fast reactor concept), and nuclear materials work under DOE program sponsorship. The company also has a long history in TRIGA research reactor design, with over 70 reactors built across decades.
Three businesses. Three different physics regimes. Three different regulatory bodies. One corporate engineering organization that has to maintain coherent systems engineering standards across all of them.
What’s Actually Different Between These Domains
The natural temptation when describing multi-domain engineering organizations is to assert that “good engineering is good engineering”—that requirements discipline, verification traceability, and hazard analysis translate cleanly from drones to fusion to nuclear. This is partly true and mostly misleading.
Risk vocabulary doesn’t translate. In the UAS world, MIL-STD-882E defines mishap risk in terms of probability and severity against human casualties and equipment loss. The system safety process produces hazard tracking logs, fault tree analyses, and failure mode and effects criticality analyses calibrated to flight operations. In nuclear fuel operations, the NRC regulatory framework under 10 CFR Part 50 and related appendices defines safety basis documentation, design basis accidents, and licensing-basis events against a completely different consequence space—one where the hazard of primary concern is radiological release, not aircraft mishap. In fusion, the ITER Organization’s quality assurance framework (IO/QA/01) is an ISO 9001-derived system overlaid with nuclear-adjacent safety protocols, because ITER handles tritium and activated materials, but it is not a licensed nuclear facility.
These frameworks are not interchangeable. An engineer moving from GA-ASI to the ITER magnet program would need to relearn not just the technical content but the risk language, the documentation hierarchy, and the definition of what a “safety-critical requirement” means in the new context.
Verification methods diverge sharply. Aircraft get flown. Flight test programs generate empirical data against performance specifications, and that data is the primary verification artifact. Fusion magnets cannot be tested at full operating conditions until the entire ITER machine is commissioned—which means the Central Solenoid modules must be verified through analysis, reduced-scale testing, and manufacturing process controls to a degree that would be unusual in a flight test culture. Nuclear fuel requires entirely different verification: radiochemical characterization, burnup testing in operating reactors, and regulatory review of quality assurance records going back years.
Configuration management timescales differ by an order of magnitude. A UAS program might release a major software update in weeks. The ITER Central Solenoid has a manufacturing schedule measured in years, with change control processes that reflect the physical irreversibility of winding superconducting coils. Nuclear facilities operate under licensing documents that may bind engineering decisions for the life of the installation.
These aren’t superficial differences. They represent genuinely distinct systems engineering cultures that have evolved for good reasons.
The Organizational Answer: Federated Standards with Domain Autonomy
General Atomics’ structural response to this challenge follows a pattern common among technically diverse primes: corporate-level engineering standards that define process expectations at an abstract level, with domain-level implementation standards that translate those expectations into domain-appropriate practices.
GA-ASI operates its own engineering development process framework, calibrated to DAL (Design Assurance Level) classifications from the UAS airworthiness standards and CMMI process maturity requirements from DoD acquisition. The fusion and nuclear divisions operate under separate quality management systems that reference the relevant regulatory and customer-imposed standards.
This federated approach has genuine advantages. It prevents the category error of trying to apply NRC-derived safety basis documentation requirements to a software avionics update process, or applying DO-178C software life cycle data requirements to a superconducting coil winding procedure. Domain experts maintain the standards that govern their work, which is appropriate given how much specialized knowledge those standards encode.
The costs are real, however. Federated standards with domain autonomy create three persistent problems.
Requirements format and structure diverge. When requirements are written to different templates, at different levels of abstraction, with different acceptance criteria formats, cross-domain reuse becomes difficult and cross-domain audit becomes nearly impossible. A corporate chief engineer trying to assess requirements quality across all three domains has no common ledger.
Traceability architectures are incompatible. If the UAS programs manage requirements in one toolchain and the fusion programs use another, and nuclear uses a third (or, as is common in mature nuclear work, a document-controlled paper system), there is no path to cross-program traceability analysis without manual data extraction and reconciliation. Shared lessons learned about requirements failure modes cannot be surfaced programmatically.
Talent mobility is structurally impeded. Engineers who want to rotate between domains—which is genuinely valuable for an organization that needs breadth—face steep ramp-up costs partly because the engineering process infrastructure looks so different. This isn’t unique to General Atomics, but it’s a real cost.
What’s Actually Happening vs. the Hype
The defense and energy industry generates substantial noise about “digital thread” and “model-based systems engineering” as solutions to exactly this kind of cross-domain integration problem. The honest assessment is that the reality of implementation lags the rhetoric considerably, for reasons that are structural rather than merely political.
True digital thread across domains as different as UAS, fusion, and nuclear requires not just common tooling but common data models—agreement on what a “requirement,” a “verification event,” a “hazard,” and a “configuration item” mean across contexts that were never designed to share those definitions. That is a harder problem than selecting a platform.
What is actually happening at technically diverse organizations is more incremental: efforts to standardize requirement writing quality at the sentence level (well-formed, singular, verifiable), investments in requirements tooling that can host multiple domain-specific schemas without forcing false uniformity, and gradual movement from document-based to model-based practice within individual domains before attempting cross-domain integration.
The tooling landscape is beginning to support this more nuanced approach. Modern requirements and systems engineering platforms have moved away from the document-centric model that legacy tools like IBM DOORS or Polarion were built around. Graph-based tools that represent requirements, components, tests, and hazards as nodes in a connected model—rather than as rows in a database or sections in a Word document—are better suited to expressing the genuine structural complexity of multi-domain programs. When a requirement for a superconducting coil quench protection system needs to trace simultaneously to an international technical specification, an ITER quality assurance procedure, and a manufacturing test record, a flat document hierarchy fails to capture those relationships in a way that is navigable or auditable.
Platforms like Flow Engineering, which were designed from the ground up for model-based requirements and traceability rather than having graph-based features bolted onto a document tool, represent a different approach to this problem. The architecture allows domain-specific schemas and requirement types to coexist within a connected model, which matters for an organization where “safety-critical” means something different in every building on the campus. Whether that architectural difference translates to adoption in heavily regulated nuclear and aerospace contexts—where legacy toolchains are entrenched and regulatory precedent favors familiar artifacts—remains a practical question that organizations like General Atomics would have to answer through their own qualification processes.
Practical Implications for Engineering Leadership
For the systems engineering and technical leadership at an organization with General Atomics’ breadth, the practical challenges resolve into a small number of hard decisions.
Where to standardize and where to allow divergence. The answer is not uniform. Requirement quality criteria (atomicity, testability, absence of ambiguity) can and should be standardized across domains. Verification method taxonomies, safety classification frameworks, and configuration management timescales should not—at least not without substantial domain-specific adaptation. Organizations that try to standardize everything end up with frameworks so abstract they provide no practical guidance; organizations that standardize nothing lose the organizational learning that cross-domain breadth should generate.
How to move knowledge across domain boundaries. The most valuable thing a multi-domain organization can do with its breadth is transfer hard-won engineering judgment across contexts. Lessons from UAS software certification about requirements completeness have genuine applicability to fusion instrumentation and control development. NRC experience with aging management has applicability to long-duration aerospace programs. Capturing and routing that knowledge requires deliberate process—not just informal hallway conversations—and tooling that can represent cross-domain relationships.
How to recruit and retain engineers who can hold breadth. The engineers who are most valuable to an organization like General Atomics are those who can function competently in one domain while having genuine curiosity about others. The engineering process infrastructure either supports or impedes that kind of breadth. A systems engineer who finds that moving between divisions means learning an entirely new toolchain, documentation culture, and requirements language every time has less incentive to develop cross-domain competence than one who finds that the underlying process logic is consistent even when the domain-specific content differs.
Honest Assessment
General Atomics is not solving the cross-domain systems engineering problem definitively. No organization with this range of technical work has. What the company has done is build domain-level engineering capability that is genuinely world-class in each area—a UAS development operation that has produced more operational flight hours than any competitor, a fusion engineering team that delivered one of the most technically demanding magnet fabrication projects in history, and a nuclear division with decades of regulatory and operational experience.
The cost of that excellence is real fragmentation at the portfolio level. Requirements consistency, cross-domain traceability, and talent mobility across the three major technical domains remain genuine organizational challenges, not solved problems.
The direction of travel in the tooling industry—toward graph-based, model-native platforms that can host domain-specific schemas without abandoning the possibility of cross-domain analysis—is the right direction for organizations with this structure. Whether General Atomics or its peers move fast enough in that direction to capture the organizational benefits before the next generation of complex multi-domain programs arrives is the operative question.
The engineering breadth General Atomics has assembled is genuinely rare. Making full organizational use of it requires systems engineering infrastructure that is currently not fully adequate to the task. That gap is worth naming clearly, because closing it is achievable—and the cost of leaving it open is measured in duplicated effort, missed lessons, and requirements failures that a connected model would have surfaced.