Inteldefense
JADC2 Data Fabric: Where the Schedule Actually Dies
JADC2 is not one system. It is a stack of accreditation decisions and data rights agreements, and that stack is where the schedule dies.
Every JADC2 briefing has the same slide. A Navy radar, an Army launcher, an Air Force aircraft, arrows between them, and a caption about the speed of relevance. The arrows are the easy part.
The hard part is the page after it. Who is allowed to see that track. Which accreditation boundary it crosses to get there. Who owns it once two services hold a copy. What happens to the firing decision when the link drops for ninety seconds.
I have spent years on federal data integration where the stakes were audit findings rather than missiles. The pattern is the same. The technology is rarely the thing that stops the program. The agreements are.
JADC2 is a set of agreements wearing a system diagram
Strip the acronym and JADC2 asks for four things: sensors that publish in a common vocabulary, transport that survives a contested electromagnetic environment, translators for systems that will never be rebuilt, and a command authority that accepts a track it did not generate.
Only the second item is primarily a networking problem. The other three are policy, contracts, and metadata.
Take the vocabulary. An Air Force radar track and a Navy surface track do not agree on what a track is. They carry different confidence measures, different time references, different notions of what counts as the same object. Neither is wrong. Both were built for a consumer that no longer exists.
A data fabric can translate between them. What it cannot do is decide which service's confidence number is authoritative when the two disagree at the moment somebody has to shoot.
Accreditation is the long pole
Adding a sensor feed to an accredited system is not a data engineering task. It is a security decision with a review board, a boundary diagram, and a schedule measured in months.
That is true inside one service. Across services, every new data path crosses at least one boundary that was drawn for a reason. Crossing it means a cross-domain solution, a security control assessment, and a signature from someone who is accountable if the path leaks.
The result is predictable. The pilot connects three systems in a lab and works. The program then spends a year getting that same connection authorized for operation, and by the time it is approved the operational requirement has moved.
This is not bureaucratic stupidity, which is the lazy explanation. It is the correct response to a real risk. The controls exist because the alternative is a data spill that ends careers and programs. The problem is that the approval process was designed for a small number of large, stable systems, and JADC2 wants a large number of small, changing connections.
Programs that understand this spend their early money on the accreditation path rather than the demo. Programs that do not get a great demo and no fielding.
The narrow programs work because someone owns the outcome
The capabilities that exist today are narrow, and that is why they exist.
The Army's Integrated Battle Command System links sensor types that were previously separate into one air defense picture. Naval Integrated Fire Control-Counter Air lets a ship engage using targeting data from an aircraft, beyond the ship's own radar horizon. Project Convergence exists to break the integration assumptions in public once a year, with joint and allied participants in the room.
Those efforts share three properties. One operational sponsor owns the result. The decision the data supports is specific, which limits how much data has to cross a boundary. And there is a shooter at the end, which means the requirement has a deadline that is not a slide.
Compare that with the general ambition: all sensors, all services, all domains, continuously. No sponsor owns that sentence. Nothing in it can be tested. It is a direction, not a program.
The lesson is not that the ambition is wrong. It is that the ambition has to be reached through a sequence of narrow things that somebody is accountable for delivering.
Data rights are the argument nobody wants to have
The technical community talks about schemas. The fight is about ownership.
When a service publishes a track into a shared layer, it has not given the track away in any legal sense, but it has created a copy it does not control. Now there are questions. May a second service retransmit it to a third. May it be fused with a commercial feed. May it be stored, and for how long, and where. May an algorithm trained on it be reused outside the boundary where it was collected.
None of those questions have a technical answer. They have a contractual one, and the contract is usually written years before anyone asks.
I have watched two financial systems inside the same command take a year to agree on a transaction format, with no classification involved and no adversary. JADC2 asks five services, dozens of major systems, and a coalition to agree on what a track means while somebody is shooting at the network.
The fabric is the easy half. The rights to the data inside it are the hard half.
What to build if you are in this market
Four tests separate a useful contribution from a demo.
Can you show, for any record, who is allowed to see it and why. Not a role name. The clause or control that authorizes it.
Can you prove where a track came from, through every transformation, after the fact. Lineage is not a dashboard. It is a record you can hand an assessor.
Can you degrade honestly. When the link drops, the system should say what it no longer knows rather than presenting a stale picture with a fresh timestamp.
Can you express confidence in a form a commander can act on. A track with no confidence measure forces the human to invent one, and humans invent optimism.
Vendors that answer those four questions will get used inside narrow programs, which is where the money and the fielding actually are. Vendors that answer the architecture question will get invited to briefings.
JADC2 will be delivered in pieces, by programs with unglamorous names, over a decade, with allied participation bolted on later and badly. That is not a failure of vision. It is how every large integration in this department has ever happened.
The parts that will move fastest are the ones where a single commander can point at a decision and say that decision used to take twenty minutes and now takes two. Everything else is a diagram, and diagrams do not cross accreditation boundaries.