Golden Dome's Digital Brain
Inside the command and data fusion systems connecting sensors to shooters for hypersonic defense.
Heads up: This one’s a bit more technical than usual, as we’re unpacking some of the engineering and algorithmic details behind how these systems actually work. I’ve tried to keep things readable, but if you’re curious or want to dig deeper, feel free to reach out. I’d love to hear your thoughts or questions.
In my last post, we examined the vast, multi-layered sensor network behind America’s “Golden Dome” initiative, exploring the satellites and radars designed to detect and track hypersonic threats. But finding the needle in the haystack is only the first part of the problem. How does the U.S. military take that sensor data, make sense of it, and guide an interceptor to a target moving at over a mile per second?
This is where the command and control (C2) and data fusion systems come in—the digital “brains” of the operation that pull everything together. Let’s try to unpack that C2 architecture. We will explore the immense requirements, the key technologies and systems like the Army’s IBCS, and how they are being tested in practice.
System Requirements
First a recap of the operational and technical requirements for hypersonic missile defense: The entire C2 architecture for Golden Dome is shaped by the brutal reality of time. Unlike traditional ballistic missiles, which follow predictable parabolic arcs and allow defenders tens of minutes to react, hypersonic glide vehicles fly lower, faster, and maneuver unpredictably. This compresses the engagement timeline from detection to interception to mere tens of seconds.
To guide an interceptor to a kill, the C2 system needs a track file of exceptionally high quality. This means positional data must be accurate to within meters and updated in near real-time to account for the target’s maneuvers. Any latency in the system (the time it takes to hand off data between sensors, fusion centers, and weapon systems) erodes the already minuscule window for a successful intercept.
This speed necessitates reliance on automation. Humans cannot manually parse multi-sensor data, correlate tracks, and assign weapons at the required machine speed. Consequently, algorithms must handle much of the decision cycle, from identifying the threat to recommending an engagement. This raises the critical issue of AI autonomy, or the degree of machine-driven control that commanders are willing to accept. While a human will likely retain ultimate launch authority in most cases, the system is being designed to tee up that decision almost instantly, a model often described as “human-on-the-loop” rather than “in-the-loop.”
From Data to Decision
At the heart of the C2 challenge is “data fusion,” a term for the process of combining information from multiple sources to create a single, coherent picture of the battlefield. For Golden Dome, this means taking disparate data from a network of satellites, ground-based radars, and other sensors and fusing it into a fire-control-quality track that can guide a weapon.
In this context, I find the classic Joint Directors of Laboratories (JDL) model useful for breaking down the task. The process begins with initial object detection and evolves to higher levels, such as situation assessment (e.g., identifying a coordinated raid) and impact assessment (predicting the threat’s target). Key tasks for Golden Dome include hypothesis generation, where the system recognizes that sensor signals correspond to a new threat, and sensor correlation, which associates tracks from different sensors with the same physical object.
This is far from simple. A space-based infrared sensor and a ground-based radar will see the same target differently. The C2 system must be able to recognize these different inputs as the same object and create a composite track that is more accurate and reliable than any single sensor could produce.
To achieve this, DoD is investing in several key research efforts. DARPA’s STITCHES (System-of-systems Technology Integration Tool Chain for Heterogeneous Electronic Systems) program, for instance, develops software that automatically creates links between disparate military systems, essentially writing its own code to make them interoperable. This is critical for plugging new sensors into the network on the fly. On the Army side, Project Linchpin is creating a standardized pipeline for developing and deploying AI and machine learning models, which will allow for the rapid upgrading of the fusion algorithms at the core of Golden Dome’s C2 systems.
A Team of Systems
There is no single “Golden Dome” system. Instead, the architecture is a system-of-systems, a federation of key programs from across the services that must work in concert.
Integrated Battle Command System (IBCS): Led by the Army with Northrop Grumman as the prime contractor, IBCS is the cornerstone of the Army’s air and missile defense modernization. Its core function is to fuse data from Army sensors (like Patriot and THAAD radars) into a single integrated air picture. This allows any sensor to cue any shooter, a paradigm that breaks down the stovepipes of legacy systems. For example, IBCS can use a THAAD radar to guide a Patriot missile, significantly expanding the defended area.
Command and Control, Battle Management, and Communications (C2BMC): Developed by the Missile Defense Agency (MDA) with Lockheed Martin as the lead, C2BMC serves as the global backbone for U.S. missile defense. It integrates data from sensors across different domains and geographical boundaries, from Space-Based Infrared System (SBIRS) satellites to forward-deployed radars. For Golden Dome, C2BMC is being upgraded to handle hypersonic threats specifically, integrating data from new sensors like the Hypersonic and Ballistic Tracking Space Sensor (HBTSS) and passing fire-control information to Navy and Army shooters.
Aegis Combat System: The Navy’s contribution, developed by Lockheed Martin, is the Aegis weapon system aboard its destroyers and cruisers. Traditionally reliant on its own powerful SPY-series radars, Aegis is evolving into a more networked system. With the latest software baselines, an Aegis ship can now take tracking data from an external source, like an HBTSS satellite via C2BMC, to engage a threat that is beyond its own radar’s horizon. This ability to conduct “launch on remote” is fundamental to the Golden Dome concept.
The Architecture in Practice
These capabilities are being actively tested and proven. Two examples highlight how the C2 architecture is coming together in practice.
First, in 2019 MDA conducted Flight Test Ground-based Midcourse Defense-11 (FTG-11). Two Ground-Based Interceptors, guided by the global C2BMC network and cued by a mix of space-, sea-, and ground-based sensors, destroyed an ICBM surrogate in successive strikes. The lead interceptor eliminated the re-entry vehicle; the trail interceptor autonomously discriminated the debris and struck the next most lethal object. FTG-11 was the first successful salvo engagement of an intercontinental-range target, proving the United States can execute a layered homeland defense against ICBM threats.
A second, more recent example is the Navy’s FTX-40 “Stellar Banshee” test in March 2025. In this event, space-based HBTSS prototypes detected and tracked a maneuvering hypersonic target. This tracking data was passed through the C2BMC network to the USS Pinckney, an Aegis destroyer. The Aegis system used this space-based cue to detect and track the target and perform a simulated engagement with an SM-6 missile. This was a major event, proving the viability of the entire space-to-sea kill chain, from satellite detection to a ship-based fire control solution, all within the compressed timeline required for hypersonic defense.
Challenges and Implications
In our previous article, we explored the immense physical and technical hurdles at the sensor level: the “dim and fast” nature of hypersonic targets, the plasma sheaths that can blind radars, and the adversary’s use of decoys. While advanced sensors and on-orbit processing are being developed to collect better data, the ultimate burden of making sense of that imperfect, often-conflicting information falls squarely on the C2 and data fusion layer. The challenges ahead are less about physics and more about logic, code, and collaboration.
Technological: The core problem here is algorithmic. The fusion engines within systems like C2BMC and IBCS must be sophisticated enough to weigh intermittent data streams (for instance, a faint IR track from an HBTSS satellite and a temporary radar track from an Aegis ship) and correctly fuse them into a single, trusted, and persistent track file. This is the definition of a high-stakes judgment call, and it must be made by software in seconds. The ongoing challenge is to develop, test, and validate these complex algorithms to a point where commanders trust their outputs, especially when they are recommending the launch of a multi-million-dollar interceptor. This involves a massive investment in high-fidelity digital modeling and simulation, as live-fire testing at the scale needed to prove the system against a peer adversary is simply not feasible.
Architectural: This challenge is one of scale and speed. As the Space Development Agency builds out its Proliferated Warfighter Space Architecture, the C2 network will need to ingest and de-conflict data from hundreds of satellites, not just a handful of prototypes. The “data fabrics” being developed by the Air Force’s Advanced Battle Management System and the Navy’s Project Overmatch are designed to handle this, but ensuring this firehose of information doesn’t create new processing bottlenecks is a monumental software and network engineering task. Every component must be optimized for minimal latency, because in a hypersonic engagement, the kill chain is only as strong as its slowest link.
Organizational: Forging a truly integrated “any sensor, any shooter” network requires a level of inter-service and cross-agency cooperation that has historically proven difficult. It demands that the Army’s IBCS, the MDA’s C2BMC, and the Navy’s Aegis systems not only share data, but also align on complex command relationships and rules of engagement. This requires breaking down cultural and budgetary stovepipes. The success of programs like Army’s Project Linchpin in creating open standards is critical, as it provides a pathway to force interoperability and avoid being locked into proprietary systems that hinder integration.
A Final Thought on Golden Dome and What's Next
And that brings our two-part deep dive on the Golden Dome architecture to a close. From my perspective, this effort is a grand, high-stakes experiment in systems integration. And frankly, it’s an experiment I find deeply concerning. Its staggering price tag, questionable effectiveness against inevitable countermeasures, and potential to trigger a destabilizing arms race on Earth and in space make it, in my view, a strategic misstep. This isn’t to say all investment in missile defense is a bad idea. On the contrary, developing more affordable, scalable, and theater-focused defenses (especially those designed to counter the growing threat of drone swarms and China’s massed precision-strike capabilities) is more critical than ever.
And it’s precisely that architectural challenge—countering massed, autonomous threats—that I want to explore next. We’ve just examined a massive, top-down system. Now, we will pivot to the chaotic, bottom-up world of drone warfare. Inspired by recent operations like Ukraine's “Spider Web” operation, my next piece will dissect the C4ISR architecture that enables drone swarms, from tactical networking to AI-driven targeting, and compare the evolving approaches of China and the United States in the race to master these new weapons of war.
Thank you for joining me on this deep dive. If you found this analysis valuable, the best way to support this work is to like and share it with others. And for more frequent thoughts and discussions, you can always follow me on X/Twitter at @mcasey_asia, connect on LinkedIn, or reach out if you’d like to collaborate.