The Briefing Room Problem
JADC2. Joint All-Domain Command and Control. The Department of Defense has spent the better part of a decade and tens of billions of dollars trying to connect every sensor to every shooter across every domain. The vision is seductive: a unified operational picture that flows from space to seabed, every data point fused, every decision informed by the full weight of the joint force's sensing capacity.
It's a great vision. It's also being built upside down.
The dominant JADC2 architectures - and we all know who builds them - are designed for the COCOM. For the Theater Commander. For the Joint Force Air Component Commander sitting in a hardened ops center with SIPR, JWICS, and a room full of analysts turning sensor feeds into PowerPoint slides. These platforms do a genuinely impressive job of aggregating classified intelligence, modeling force disposition, and enabling strategic decision-making. The ability to fuse national technical means with theater-level ISR and present it coherently to a four-star is a hard engineering problem and they solved it.
But here is the issue that nobody in a SCIF wants to talk about: the people making the decisions that determine whether people live or die are not in that ops center.
Where the Decisions Actually Happen
A Patriot battery commander has somewhere between 8 and 15 seconds to decide whether to engage an inbound ballistic missile or cruise missile. An infantry company commander taking contact in a contested urban environment has less than that. A destroyer's combat information center officer evaluating an inbound track in a strait has maybe 30 seconds before geometry makes the decision for them.
These are the people who actually execute the kill chain. And what does JADC2 give them?
A filtered-down intel brief. A Common Operational Picture that was current days to months ago. A chat window to request fires from an authority three echelons up. Maybe a Link 16 feed if they're lucky and 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.
This is the fundamental disconnect: we're building JADC2 top-down when the decisions that matter happen bottom-up. We're architecting for the consumer of intelligence when we should be architecting for the producer and executor of action. The sensor operator, battery commander, or fire team leader who just watched a quadcopter drop a grenade on his position and needs to know if there are more and where they are coming from.
The Connectivity Lie
Every JADC2 architecture I've reviewed - and I've reviewed a lot of them, including several I can't talk about - makes an assumption that falls apart the moment you leave the FOB: persistent, reliable, high-bandwidth connectivity to a cloud or data center.
We've all heard of DDIL: Denied, Disrupted, Intermittent, or Limited. It's not a corner case anymore, but an operating assumption for any contested environment. Russian EW capabilities demonstrated in Ukraine - Krasukha-4, Murmansk-BN, Zhitel - can degrade or deny satellite communications, GPS, and tactical data links across theater-scale areas. Tactical UAS units deployed with Russian motor rifle battalions and specialists such as Svarog's Swarm and Rubikon target patch antennas, repeaters, relays, and other EW and signals equipment even more than they target "living forces".
Chinese A2/AD doctrine explicitly targets communications infrastructure as a precursor to kinetic operations, it's not a stretch to imagine that the PLAN has every single radome, radar, and AD emplacement from Formosa to Maui mapped out. Cyber effects and information warfare is downplayed, we already see members of the IDF who are coerced or bribed into providing targeting information to the IRGC, Chinese information warfare and cyber operations are far more complex, asymmetric, and capable. What happens when an underpaid and tired lower enlisted accepts $5K USD from his "Discord girlfriend" in exchange for snapping photos of a few TYP-2s or ECS-132s?
Even absent adversary action, terrain, weather, and physics conspire against reliable long-haul connectivity. So what happens to your cloud-dependent JADC2 system when the cloud goes away? What happens when your expensive FHSS L-Band link connecting your naval fires to your PAC-3 battery is severed by an errant thunderstorm or a $30,000 fiberglass delta wing drone with barely anymore explosive payload than a boquet of M67s?
You get a very expensive brick. You get a Patriot battery that can still shoot - the organic fire control radar and engagement control station still work - but has lost every fused track, every cross-domain correlation, every piece of context that was supposed to make the engagement decision better. The sensor-to-shooter link still works because Raytheon built it that way, but the sensor-to-understanding link is gone. And understanding is the entire point of JADC2.
Sensor-Up, Not Intel-Down
There is a different way to build this. Start with the sensor. Start with the person standing next to it. Build up from there.
A Patriot battery has an MPQ-65A radar. It has a TRML-4D if the host nation brought one. It might have an AN/MPQ-64F1 Sentinel for low-altitude coverage. If there's an IBCS node nearby, there might be additional tracks from sensors it's never met. Each of these sensors operates on a different frequency band, has a different scan pattern, a different update rate, 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 30 RPM with a 3° beam. They see different things at different times in different ways.
Right now, the 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 sends back a fused picture. The first is too narrow. The second requires the connectivity we just established you can't rely on.
The third option: fuse at the battery. On hardware that deploys with the battery. Running software that operates the same whether the satellite link is up or down. Software that 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 not just their organic sensors, but mission-specific, low-cost COTS hardware such as acoustic arrays, SUAS passive radar, EO/IR/SWIR sensor packages, PTZ cameras, high-end Software Defined Radios that can further enrich their ground truth.
This is what sensor-up architecture means. You don't start with the national intelligence picture and push it down to the edge. You start with the organic sensors at the edge and build understanding from the ground up. When connectivity exists, you push your local fused picture up to the next echelon, and you accept fused tracks from adjacent units and higher. When connectivity degrades, you still have a functional operational picture because your fusion engine is local, your policy engine is local, your decision support is 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 your "intelligence" was up there.
The Physics of Sensor Fusion
Fusion isn't summarization! One does not simply throw detections at an LLM and ask what it thinks, which seems to be all the marketing talks about now. Sensor fusion is a (complex) physics problem with mathematical solutions.
A rotating radar paints a target once every 2 seconds. Between paints, you have no measurement - just a prediction from the last known state, propagating forward with increasing uncertainty. A Kalman filter handles this: predict the state forward using the kinematic model, update when a new measurement arrives, manage the uncertainty covariance. This is freshman-level state estimation, but it has to run continuously, at sensor rate, against every track in the picture across all of the physics-grounded limitations of every sensor in under a second or less.
When you fuse across sensors, you add complexity. The MPQ-65A updates every 100ms on its sector. The Sentinel paints once every 2 seconds. An EO/IR tracker updates at 30Hz but only within a narrow field of view. Each sensor has different measurement noise characteristics, different detection probabilities, different false alarm rates. The fusion engine has to 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. It's a matrix multiplication and an inversion, some gating logic, some 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 paints a target and you have to round-trip to a data center to fuse it with the MPQ-65A track, you've added 200ms to 2 seconds of latency depending on your link. 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 you put the compute, and the answer is: as close to the sensors as you can get it.
What Edge Deployment Actually Means
Let me be specific about what "the edge" means, because it's another term the industry has diluted beyond recognition. 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 MSI EdgeExpert or equivalent COTS compute 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 the Silvus radio that forms the mesh. It's anywhere you can run a container that has a network interface to the sensors.
Deploying sensor fusion at the edge means:
- 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 doesn't degrade the core capability.
- Sensor-native ingest: You talk to the sensors directly, on their native protocols, at their native update rate. You don't wait for a data pipeline to batch, transform, and forward. When the Sentinel completes a rotation, those detections are in the fusion engine before the beam completes its next sweep.
- Operator-facing: The person making the engagement decision can see the fused picture, understand why a track is classified the way it is, see the confidence score, see which sensors are contributing. Not through a reach-back to an analyst, but on their display, updating live. This is the difference between decision support and decision making. The operator owns the picture.
- Same software, everywhere: The fusion engine that runs on the edge node is the same code - the same algorithms, same policy rules, same UI - that runs at the battalion TOC, at the JOC, at 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 the same at every echelon, and every echelon can operate independently.
Edge deployment sounds great in a whitepaper. Actually doing it requires solving problems that the cloud-first platforms never had to think about. Doing it in a cost-effective and mass-deployable manner is even more difficult when the procurement apparatus incentivizes the exact opposite, because having long-running programs at cost-plus is what makes a company money but isn't to the benefit of the warfighter or the non-combatant population that their actions will protect.
It's doable, but it's not easy, some of the reasons include:
- State management without a database server: Your fused tracks live in memory. Your policy engine's rule state lives in memory. If the process crashes, you cold-start. If the node loses power and comes back, you need to re-acquire from sensors, not from a database. The 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 produce the same result. When they share tracks over a tactical mesh with 30% packet loss and variable latency, they need to converge without creating duplicate tracks or contradictory classifications. This is a distributed systems problem that the FAANG world solved with Paxos and Raft, but those algorithms assume reliable links. Tactical mesh doesn't give you reliable links.
- Policy enforcement without reach-back: Engagement authority rules - ROE, weapon-target pairing constraints, no-fire zones, airspace deconfliction - have to be evaluated locally. If the policy engine can't reach the server that holds the rules, it still has to enforce them. This means policy has to be distributed, versioned, and conflict-resolved at the edge. When connectivity returns, local decisions sync up with authoritative state. Merge conflicts in policy are an operational safety issue.
- Trust calibration: An operator at the edge trusts the system because they've trained on it. They've watched it fuse tracks in simulation, seen it handle sensor dropouts, understood why it classified a target the way it did. This trust is earned in training and validated in operation. It's not asserted by a vendor. If the system produces a fused track that contradicts what the operator's Mk.1 eyeball and their own sensor display are telling them, the operator has to understand why and be armed with the authority and the interface to override.
The Training-Operations Continuum
This brings us to the piece that ties everything together: the training environment and the operational environment have to be the same software. If your operators train on a simulation platform and operate on a different platform, you've wasted their training. Muscle memory doesn't transfer. Interface familiarity doesn't transfer. Trust doesn't transfer. The operator who trained on System A and deploys with System B is starting from zero in the worst possible moment.
The simulation engine should run the same fusion pipeline, the same policy engine, 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 the operator transitions from the training scenario to a live operational picture, the only thing that should change is the data source. The interface, the workflows, the decision patterns must all be identical, or the closest axiomatic (and physiscs-based) representation of "identical".
It's the mechanism by which edge-deployed sensor fusion becomes trustworthy. 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. They built that judgment in training, and it transfers because the training tool and the operational tool are the same thing.
We Must Stop Building Top-Down
The JADC2 vision isn't wrong. Connecting every sensor to every shooter across every domain is the right goal. But the implementation path - build the cathedral first, then wire the parish churches - is backwards.
Start at the edge. Start with the sensor. Build fusion that works on hardware that deploys with the warfighter that doesn't require a 10K genset and 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. Then connect upward: battery to battalion, battalion to brigade, brigade to theater, theater to combatant command. Each echelon adds breadth. None of them should be 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.
For a deep dive into how these principles apply to the counter-UAS mission specifically - from sensor modalities and fusion architecture to effector selection and layered defense planning - read our comprehensive guide: The Ultimate Guide to Counter-UAS Operations.
Stay Dangerous.
