Joint All-Domain Command and Control (JADC2) is the Department of Defense's concept for connecting every sensor to every shooter across every warfighting domain - air, land, maritime, space, cyber, and the electromagnetic spectrum. The idea is that modern threats don't respect domain boundaries, so the command and control systems used to detect and defeat them shouldn't either. A coordinated attack today might combine drone swarms, electronic warfare, cyber effects, and information operations executed simultaneously. No single-domain C2 system sees the full picture. JADC2 is supposed to fix that.
The vision is right. The way most of it is being built is wrong.
For quick-reference answers on JADC2 programs, JADO doctrine, and service-level implementations, see the JADC2 FAQ.
The vision, accurately stated
An air defense battery tracks inbound missiles on one system. The EW section monitors the spectrum on another. The intelligence shop builds the threat picture on a third. The cyber team watches network alerts on a fourth. Each domain has its own sensors, its own data schemas, its own COP, and its own chain of command. The convergence between them - the bit that tells you a drone swarm, a jammer, and a social media campaign are one coordinated action rather than three separate events - goes undetected because no single system sees across all of them.
JADC2 answers this by fusing every available sensor across every domain into a unified picture, flowing from the tactical edge up to the combatant command, with cross-domain correlation happening at machine speed instead of at the speed of a weekly brief.
That is genuinely what should be built. The argument isn't with the vision. The argument is with how we're getting there.
The top-down problem
The dominant JADC2 programs - ABMS, Project Overmatch, and their joint descendants - are architected for the COCOM. They aggregate classified intelligence, model force disposition, and enable strategic decision-making for the theater commander and the joint force component commanders. This is genuinely hard engineering. Fusing national technical means with theater ISR and presenting it coherently to a four-star in a SCIF is a serious problem and the primes who built the current platforms solved it.
But here's what nobody in the SCIF wants to say out loud: the decisions that determine whether people live or die are not being made in that SCIF.
A Patriot battery commander has somewhere between 8 and 15 seconds to decide whether to engage an inbound ballistic or cruise missile. An infantry company commander taking contact has less. A destroyer's combat information center evaluating an inbound track in a strait has maybe 30 seconds before geometry makes the decision for them. A force protection team watching an unidentified quadcopter approach a data center perimeter has seconds.
These are the people who actually execute the kill chain. What does the current JADC2 architecture give them?
A filtered-down intelligence brief. A COP that was current hours ago. A chat window to request fires from an authority three echelons up. Maybe a Link 16 feed if the network is cooperating. Maybe a satellite downlink that drops every time the weather changes or the adversary decides they'd prefer you didn't have it.
The fundamental disconnect: the platforms optimize for the consumer of intelligence when the system should be optimizing for the producer and executor of action. The sensor operator, the battery commander, the fire team leader who just watched a drone drop a grenade on his position and needs to know if there are more and where they're coming from. Building JADC2 from the cathedral down, expecting the parish churches to wire in later, is how this gets implemented. It doesn't work.
The connectivity lie
Every major JADC2 architecture assumes persistent, reliable, high-bandwidth connectivity to a cloud or data center. That assumption does not survive five minutes past the FOB gate.
DDIL - Denied, Degraded, Intermittent, Limited - is not a corner case. It is the operating assumption for any contested environment. Russian EW systems (Krasukha-4, Murmansk-BN, Zhitel) degrade SATCOM, GPS, and tactical data links at theater scale. Ukraine's experience has validated this at depressing resolution. Russian tactical UAS units and specialized detachments such as Rubikon and Svarog's Swarm deliberately target antennas, repeaters, relays, and EW equipment - sometimes more than they target personnel. Chinese A2/AD doctrine explicitly targets communications infrastructure as a precursor to kinetic operations; it is not a stretch to assume every radome, radar, and AD emplacement from Formosa to Maui is mapped.
Cyber and information warfare widen the aperture further. What happens when a tired, underpaid lower-enlisted soldier accepts a few thousand dollars from someone on Discord in exchange for photos of a TYP-2 or an ECS-132? That's not a hypothetical - variants of that exact attack pattern have already occurred against the IDF.
And that's the adversarial failure mode. Absent any adversary action, terrain, weather, and physics conspire against reliable long-haul connectivity. An expensive FHSS L-band link between your naval fires and your PAC-3 battery can be severed by an errant thunderstorm or a $30K fiberglass delta-wing drone with barely more explosive payload than a bouquet of M67s. What happens then?
You get a very expensive brick. A Patriot battery that can still shoot - the fire control radar and engagement control station still work because Raytheon built them that way - but has lost every fused track, every cross-domain correlation, and every piece of context that was supposed to make the engagement decision better. The sensor-to-shooter link survives. The sensor-to-understanding link dies. Understanding was the whole point.
Sensor-up, not intel-down
There is a different architecture. Start at the sensor. Start with the person next to it. Build up from there.
A Patriot battery has an MPQ-65A radar. It might have a TRML-4D if the host nation brought one. It probably has an AN/MPQ-64F1 Sentinel for low-altitude coverage. Maybe an IBCS node nearby with additional tracks. Each of these operates on a different frequency band, with a different scan pattern, at a different update rate, with a different detection envelope. The MPQ-65A is a C-band phased array staring at a 120° sector. The Sentinel is an X-band mechanical rotation at roughly 30 RPM with a 3° beam. They see different things at different times in different ways.
Right now, fusion of these sensors happens in one of two places: inside the proprietary fire control system (which only fuses its own organic sensors), or up in the cloud where some platform ingests everything and eventually sends back a fused picture. The first is too narrow. The second requires the connectivity you cannot rely on.
The third option: fuse at the battery. On hardware that deploys with the battery. Software that operates the same whether the satellite link is up or down. Software the battery commander can see, understand, and trust because it's showing them what their sensors are seeing right now - not what a fusion center 500 miles away thought they were seeing 45 minutes ago. And it doesn't have to be just the organic sensors either: mission-specific low-cost COTS hardware like acoustic arrays, passive radar from SUAS, EO/IR/SWIR turrets, PTZ cameras, and high-performance SDRs across the EMSO spectrum further enrich the ground truth.
This is what sensor-up architecture means. You don't start with the national intelligence picture and push it down. You start with the organic sensors at the edge and build understanding from the ground up. When connectivity exists, the local fused picture propagates upward and the unit accepts tracks from adjacent units and higher echelons. When connectivity degrades, the unit retains a functional operational picture because fusion, policy enforcement, and decision support are all local.
The degradation model matters: when you go DDIL, you lose breadth (cross-domain, cross-theater) but you don't lose depth (your organic sensors, your local fusion, your engagement authority). The current model inverts this - you lose depth when the cloud goes away, because all of the "intelligence" was up there.
The physics of sensor fusion
Fusion is not summarization. One does not simply throw detections at an LLM and ask what it thinks - even though a disturbing amount of current marketing talks about it that way. Sensor fusion is a physics problem with mathematical solutions that are decades old, load-bearing, and in some cases written in blood.
A rotating radar paints a target once every 2 seconds. Between paints, there is no measurement - just a prediction propagating forward from the last known state with increasing uncertainty. A Kalman filter handles this: predict forward using the kinematic model, update when a new measurement arrives, manage the covariance. It's freshman state estimation. The complication is that it has to run continuously, at sensor rate, against every track in the picture, across all of the physics-grounded limits of every sensor, in milliseconds.
When you fuse across sensors, the complexity multiplies. The MPQ-65A updates every 100 ms on its sector. The Sentinel paints once every 2 seconds. An EO/IR tracker updates at 30 Hz but only inside a narrow field of view. Each sensor has different measurement noise, different detection probabilities, different false alarm rates. The fusion engine must associate detections across sensors (is this the same target?), manage track initiation and deletion, handle conflicting classifications, and produce a single fused track with a meaningful confidence score.
This is computationally cheap per track. Matrix multiplication, matrix inversion, gating logic, scoring. The problem is that it has to happen at the sensor's update rate, not at the cloud's query rate. If your Sentinel completes a sweep and you round-trip to a data center to fuse it with the MPQ-65A, you've added 200 ms to 2 seconds of latency. That's fine for an intelligence picture. It's not fine for a fire control solution where the target is moving at Mach 3 and the engagement window is closing.
The fusion engine belongs at the edge because physics says so. The speed of light is a hard constraint. The sensor update rate is a hard constraint. The engagement timeline is a hard constraint. The only variable is where the compute sits, and the answer is as close to the sensors as possible. For a deeper walk through the fusion math itself, see What is Sensor Fusion?.
What "the edge" actually means
The edge is another term the industry has diluted into meaninglessness. Let me be specific.
The edge is not a ruggedized server rack in a company CP. That's a FOB. The edge is not an AWS Snowball in a CONEX. That's a portable data center. The edge is the COTS compute box that sits in the same vehicle as the radar. It's the SBC in the dismounted operator's ruck. It's the ruggedized tablet attached to the Silvus or similar tactical radio that forms the mesh. The edge is anywhere you can run a container that has a network interface to the sensors.
Deploying sensor fusion at the edge means four things:
No cloud dependency. The system operates identically whether it has a satellite link or not. Connectivity is additive - it enriches the picture with cross-domain data - but its absence does not degrade the core capability.
Sensor-native ingest. Talk to sensors directly on their native protocols at their native update rate. No waiting for a data pipeline to batch, transform, and forward. When the Sentinel completes a rotation, those detections are in the fusion engine before the next sweep begins.
Operator-facing. The person making the engagement decision sees the fused picture, understands why a track is classified the way it is, sees the confidence score, sees which sensors are contributing. Not through a reach-back to an analyst - on their display, updating live. The difference between decision support and decision making is that the operator owns the picture.
Same software everywhere. The fusion engine that runs on the edge node is the same code - same algorithms, same policy logic, same UI - that runs at the battalion TOC, the JOC, the COCOM. The difference is scale, not capability. The battery sees its organic sensors. The battalion sees every battery's fused picture. The COCOM sees the theater. But the software is identical at every echelon and every echelon can operate independently.
Doing this well is hard. A few of the problems the cloud-first platforms never had to solve:
- State management without a database server. Fused tracks live in memory. Policy engine state lives in memory. If the process crashes, you cold-start. If the node loses power and recovers, you re-acquire from sensors, not from a database. Architecture has to be stateless enough to survive restarts but stateful enough to maintain track continuity across sensor update cycles.
- Multi-node consistency over lossy mesh networks. Two edge nodes fusing the same sensor data should converge to the same result. Over tactical mesh with 30% packet loss and variable latency, they need to agree without creating duplicate tracks or contradictory classifications. The FAANG world solved this for reliable links with Paxos and Raft. Tactical mesh doesn't give you reliable links.
- Policy enforcement without reach-back. ROE, weapon-target pairing, no-fire zones, airspace deconfliction - all evaluated locally. If the policy engine can't reach an authoritative server, it still has to enforce rules. Policy has to be distributed, versioned, and conflict-resolved at the edge. Merge conflicts in policy are an operational safety issue.
- Trust calibration. Operators trust the system because they've trained on it. If the system produces a fused track that contradicts what their Mk. I Eyeball is telling them, they have to understand why and have the authority and interface to override. Trust is earned in training and validated in operation - not asserted by a vendor in a slide deck.
Training and operations have to be the same software
If operators train on a simulation platform and deploy with a different operational platform, the training is wasted. Muscle memory doesn't transfer. Interface familiarity doesn't transfer. Trust doesn't transfer. The operator who trained on System A and goes to war with System B is starting from zero in the worst possible moment.
The simulation engine should run the same fusion pipeline, the same policy logic, the same operational picture, against synthetic sensor data that behaves like real sensor data - beam-gated radars that paint targets intermittently, sensors with real noise models, threats with real kinematics. When an operator transitions from training to a live operational picture, the only thing that changes is the data source. The interface, the workflows, the decision patterns are identical.
An operator who has run 50 simulated engagements on the same software they'll use in combat has a calibrated understanding of what the system can and can't do. They know when to trust the fused track. They know when to demand multi-sensor confirmation. They know what a degraded sensor looks like in the picture. That judgment was built in training and it transfers because the training tool and the operational tool are the same thing. That's the only way edge-deployed sensor fusion becomes trustworthy in combat.
Stop building top-down
The JADC2 vision isn't wrong. Connecting every sensor to every shooter across every domain is the right goal. The implementation path - build the cathedral first and wire the parish churches later - is backwards.
Start at the edge. Start with the sensor. Build fusion that works on hardware that deploys with the warfighter, without requiring a 10kW genset, proprietary cabling, and a multi-million-dollar MANET. Make it work without connectivity. Make it work over tactical mesh. Make it trainable with the same software the operator will actually use. Then connect upward: battery to battalion, battalion to brigade, brigade to theater, theater to COCOM. Each echelon adds breadth. None of them is a single point of failure.
The operator on the ground with a radio, a radar, and a decision to make in the next 10 seconds - that's who JADC2 is for. Build for them first. Everything else follows.
Where Empyrean fits
Empyrean was built around the sensor-up thesis. The Fusion & Decision Engine runs multi-hypothesis tracking with optimal global assignment at the edge, on hardware that deploys with the unit. The COP provides the shared operational picture across all domains. The Policy & Decision Layer enforces ROE and escalation logic locally with a full audit trail, whether connected or not. The EMSO, SSA, Narrative Intelligence, and CUAS workspaces all consume the same fused tracks from the same engine. The Simulation & Wargaming engine runs on the same stack so training transfers directly to operations.
Same software everywhere. Edge-first, not edge-afterthought.
Going deeper
For the long-form version of this argument with full implementation detail and specific operational examples, read Why JADC2 Needs Sensor Fusion at the Edge. For the mathematical foundation of multi-sensor fusion itself, see What is Sensor Fusion?. For how these principles apply in the counter-UAS mission specifically, see What is Counter-UAS? and The Ultimate Guide to Counter-UAS Operations.
