NGC2: US Army’s Push to Build a Data-Driven Battlefield

Editor’s Note

The Next Generation Command and Control (NGC2) marks a fundamental shift in how the US Army approaches command and control. NGC2 seeks to replace fragmented C2 systems with a common digital architecture. It puts data, AI and interoperability at the heart of battlefield decision-making. However, vendor dependence, data control and contested networks remain major challenges. This piece examines whether NGC2 can turn that architecture into a genuine battlefield advantage.

How Data Is Becoming the New Backbone of US Army C2

For decades, military command-and-control systems have primarily been developed as separate entities. The fires system operated independently, as did the intelligence, air defence, and logistics systems, each with its own applications, databases, hardware, and communication arrangements.

Integration was frequently something attempted afterwards. The result was predictable: stovepipes, duplicated data, multiple versions of the battlefield and considerable effort simply moving information between systems.

The US Army’s Next Generation Command and Control (NGC2) effort is attempting to reverse this logic. Instead of developing another C2 application and subsequently connecting it to everything else, NGC2 starts with the digital architecture itself.

The Army describes it not as a single programme or technology but as a full-stack ecosystem intended to integrate information previously trapped within separate warfighting systems and make it available to commanders, applications and increasingly AI-enabled decision tools.

This is more consequential than simply replacing ageing command-post software. Traditional C2 systems were principally designed to collect information, construct a Common Operating Picture and present it to commanders and staffs. The emerging battlefield demands something more dynamic.

Thousands of sensors, UAVs, radars, electronic warfare systems, intelligence feeds, and weapons are continuously generating data. AI can increasingly interpret that data, identify patterns and recommend courses of action.

Effectors may need to be dynamically matched to targets, while communication routes change as networks are disrupted. NGC2 is therefore moving C2 from primarily a collection of applications to a digital environment that connects sensing, understanding, deciding, and acting.

The Four Layers of NGC2

The Army normally describes NGC2 as a four-layer technology stack comprising Transport, Infrastructure, Data and Applications. Some operational Army descriptions use “Integration” in place of infrastructure, reflecting the important function of ingesting and integrating information into the common data environment.

The terminology is still evolving, but the architectural idea is consistent: instead of procuring vertically integrated systems for individual warfighting functions, separate the digital stack into layers with defined interfaces so that individual components can evolve without forcing replacement of the entire C2 system.

Transport: Moving Data Across the Battlefield

The Transport Layer provides the pathways through which information moves. Tactical radios, satellite communications, terrestrial networks, private 5G and other communications technologies can contribute to this layer. The important change is that applications should not remain permanently tied to particular communications systems.

The network should provide multiple threat-informed ways to move information based on connectivity, bandwidth, electromagnetic conditions, and mission priority.

In contested environments, therefore, the requirement is not simply more bandwidth but resilient transport capable of continuing to move critical information despite cyberattack, jamming, physical disruption or intermittent connectivity.

Infrastructure: Where the Digital Fight Runs

The Infrastructure Layer provides the compute, storage and hardware environment on which the NGC2 software ecosystem operates. That includes servers, cloud resources, tactical edge compute devices, and end-user equipment. Importantly, computing cannot reside only in large headquarters or distant data centres. Processing and storage must extend towards the tactical edge so formations can continue operating when connectivity to higher headquarters or cloud infrastructure is degraded.

NGC2 therefore combines enterprise and cloud capabilities with distributed tactical computing, allowing applications and data services to operate closer to where information is generated and decisions are required.

Data: Creating a Common Digital Language

The Data Layer is arguably the architectural centre of NGC2. Different sensors and warfighting systems generate information in different formats and frequently attach different meanings to it. The data layer is intended to create a shared environment in which information can be integrated, tagged, transformed, synchronised, discovered and made available to authorised applications.

A target identified by an intelligence system should therefore be understandable by a fires application; ammunition expenditure generated by that engagement can simultaneously inform logistics applications. Instead of each warfighting system maintaining its own version of reality, data becomes a shared operational resource.

Applications: Turning Data into Decisions

The Application Layer is what commanders and soldiers ultimately interact with. Instead of every warfighting function depending upon a tightly coupled hardware-software system, specialised applications can operate against the common data environment.

Consequently, fires, intelligence, logistics, manoeuvre, air defence, and planning applications can be updated or replaced far more rapidly. AI-enabled analytics and decision-support tools can similarly be introduced without rebuilding the underlying architecture. The analogy with the commercial smartphone ecosystem is imperfect but useful: maintain a relatively stable digital foundation while allowing applications above it to evolve continuously.

In simple terms, therefore:

Infrastructure provides the compute. Transport provides connectivity. Data provides the common language. Applications turn that data into decisions and actions.

The Common Data Baseline

This explains why the Army’s June 2026 decision to establish an NGC2 Common Data Layer Baseline is so significant. The baseline does not mean that every piece of battlefield information is dumped into one enormous central database. Rather, it establishes the common foundation through which different systems can work with data: common models and semantics, registries, transformation mechanisms, interfaces, federation and associated services.

Anduril was selected to lead the common data baseline initiative, working with Palantir to provide an edge-to-cloud data mesh using Lattice and Foundry, while Raft provides data and service registries, transformation tools and data federation capabilities.

Nor does this eliminate the requirement for data lakes or lake houses. Large persistent repositories remain important for historical ISR, imagery, intelligence holdings, mission logs, telemetry, analytics, mission replay and AI training. But they need not sit in the critical path of every tactical transaction.

A UAV detecting a target may need to pass that information through edge processing to a fires or targeting application within seconds; forcing that transaction through a distant central repository could increase latency, bandwidth consumption and vulnerability. Tactical data stores, edge computing, event streams, data fabrics and enterprise repositories can therefore coexist.

The better architectural principle is to standardise the data, federate the storage, distribute the compute, and move only what the mission requires.

From Common Operating Picture to Combat Orchestration

Once this common data environment exists, the significance extends beyond creating a better Common Operating Picture. Sensors can publish information into the environment, AI services can interpret it, different applications can consume it, and commanders can use it to coordinate effects.

Over time, C2 begins to resemble a continuous flow of sensors → edge processing → common data environment → AI and applications → combat orchestration → command decision → effectors.

The battlefield data architecture consequently becomes the connective tissue through which sensors and weapons that were never originally designed to work together can contribute to the same mission.

This is particularly important in an era of rapidly proliferating unmanned systems. A formation may eventually operate thousands of relatively inexpensive sensors and effectors from multiple manufacturers. Trying to integrate every sensor directly with every potential shooter creates an impossible integration problem.

A common data architecture changes the equation: sensors publish usable data into the ecosystem, and authorised applications and effectors consume what they require. The architecture, rather than individual platform-to-platform connections, increasingly creates the kill web.

MOSA: Open Architecture Does Not Mean Open Source

NGC2 must also be understood in the context of the US Department of Defence’s Modular Open Systems Approach (MOSA). An open architecture does not require every component to be open-source software. Anduril, Palantir, Lockheed Martin and other companies can retain proprietary intellectual property while participating in an open architecture.

What matters is whether components are modular, interfaces are sufficiently defined, and the government possesses the standards and rights required to add, upgrade or replace individual capabilities without redesigning the entire system.

The objective is therefore not to eliminate commercial intellectual property but to prevent proprietary technology from becoming an unavoidable architectural dependency.

This distinction matters because software and AI evolve much faster than traditional defence acquisition cycles. An AI model that is highly capable today may be overtaken within months. A new communications technology, UAV, or targeting application may similarly emerge long before the existing C2 programme reaches its next upgrade.

MOSA is ultimately about maintaining freedom to change. If the interfaces between NGC2’s layers remain genuinely open and under Army architectural control, the technologies within those layers can be continuously competed and replaced.

MOSA addresses tomorrow’s systems, but the Army must still deal with yesterdays. Operation Jailbreak and the associated Right to Integrate approach seek to unlock legacy systems whose proprietary interfaces have historically made integration slow, expensive or dependent upon the original vendor. Rather than replacing every existing sensor, weapon or business system, Army engineers and vendors are exposing interfaces and enabling their data to enter the emerging NGC2 environment.

Jailbreak can therefore be viewed as the bridge between the Army’s legacy stovepipes and its future open architecture. It also provides an important warning: if NGC2 is genuinely built around MOSA and government-controlled interfaces, the Army should never have to jailbreak NGC2 itself.

Why Anduril if the Architecture Is Open?

That raises an obvious question: if NGC2 is supposed to be modular and open, why place Anduril in such an influential position? Because openness does not remove the integration problem. Publishing APIs does not magically make hundreds of sensors, databases, applications, networks and weapons operate together. Someone still has to engineer the integration environment, implement data services, manage registries, translate between formats, integrate identity and security services, deploy software and ensure the ecosystem works under battlefield conditions.

Anduril provides an existing integration environment via Lattice, as well as the ability to integrate heterogeneous sensors and effectors rapidly. The Army is therefore exploiting commercial engineering capability rather than spending years building every element of the software stack itself. The 4th Infantry Division continues to have Anduril as its full-stack operational implementation lead, while Lockheed Martin serves in that role for the 25th Infantry Division.

But this creates the central architectural risk in NGC2. An architecture can have published APIs and still become deeply dependent upon the company implementing its integration layer. The important distinction is between using proprietary technology and surrendering architectural control to proprietary technology. The real test is therefore not whether Anduril’s source code is open. It is much simpler:

Can the Army replace Anduril without replacing NGC2?

If the answer is yes, the architecture is genuinely modular. If removing the company means losing the data models, interfaces, integration mechanisms, or ability to operate the ecosystem, legacy programme lock-in may have been replaced by modern platform lock-in.

Who Should Own the Architecture?

This leads to perhaps the most important governance question surrounding NGC2: who decides the architecture? Industry has the engineering expertise and commercial technologies required to move rapidly, but architectural authority must ultimately remain with the Army.

The Army should determine the operational architecture, authoritative data semantics, interoperability requirements, security boundaries, mandatory interfaces, data rights, and the criteria by which systems are admitted into the ecosystem.

Industry should propose, engineer and continuously improve solutions within that framework. Put differently, government should remain the architectural authority while industry acts as the engineering accelerator.

There is an even deeper reason why this authority cannot be outsourced. The Common Data Baseline will contain not merely technical definitions but military meaning. What constitutes a track, target, threat, friendly force, priority, confidence level or engagement state is not simply a software question.

These definitions increasingly encode operational concepts and elements of doctrine. As AI becomes involved in identifying threats, prioritising information, and recommending actions, the underlying ontology begins to influence machine-supported military decisions.

Industry can implement that ontology, but the military must remain the authority on its meaning. Control of the data model can increasingly become control of the decision model.

The MOSA test should therefore be stronger than simply asking whether interfaces have been documented. The Army must be able to change the integrator without changing the architecture.

Building with Soldiers Rather Than for Them

The manner in which NGC2 is being developed is almost as interesting as the technology itself. Rather than defining a complete architecture over several years and then delivering it to formations, the Army has been developing it alongside operational units.

The 4th Infantry Division has conducted the Ivy Sting and Ivy Mass experimentation series with an Anduril-led industry team, while the 25th Infantry Division has pursued Lightning Surge with a Lockheed Martin-led team. Soldiers and commanders have therefore become participants in development rather than simply recipients of a finished system.

The two divisions have also exchanged lessons and reused capabilities, allowing the Army to identify common components rather than letting either commercial implementation become the default architecture.

This represents a significant change in acquisition philosophy: prototype with soldiers, exercise at operational scale, discover what fails, establish what should become common, and then scale what works. It also acknowledges that software-intensive C2 can never realistically reach a permanent finished configuration.

Threats, communication technologies, AI models, and applications will continue to change; NGC2 therefore has to become a continuously evolving capability rather than another system delivered at the end of a conventional procurement cycle.

From Proof of Principle to Scaling: Where NGC2 Stands

The programme’s speed illustrates this approach. NGC2 was exercised as a proof of principle during Project Convergence–Capstone 5 in early 2025, and in April 2025 the Army formally established the effort under a programme office. In July 2025, it awarded an approximately $99.6 million, 11-month prototype agreement to an Anduril-led team to provide a full-stack prototype to the 4th Infantry Division. By September, the division had begun the Ivy Sting experimentation series.

The 25th Infantry Division subsequently became the second major operational test bed, working with a Lockheed Martin-led industry team through the Lightning Surge series.

During the first half of 2026, both efforts moved towards division-scale operational validation. In May, Ivy Mass stressed the 4th Infantry Division’s NGC2 implementation across Fort Carson and Piñon Canyon, including operations under simulated cyber and electromagnetic attack.

During the same month, Lightning Surge 3 connected activity across Hawaii, the continental United States, and the Philippines, demonstrating integration of sensors, fires, and airspace management through a unified data environment. These parallel experiments provided the evidence the Army needed to begin deciding what should become common across NGC2.

The decisive architectural milestone came on 22 June 2026, when the Army announced the establishment of the Common Data Layer Baseline and said NGC2 was moving from prototyping towards delivery. The 4th and 25th Infantry Divisions began implementing common components while retaining different full-stack implementation leads. Project Convergence–Capstone 6 in July was intended as the culminating division-scale force-on-force validation at the National Training Centre before broader scaling.

The FY2026 Army plan itself envisaged commercially based NGC2 infrastructure and transport capabilities supporting two divisions and a corps, illustrating that the objective is already moving beyond isolated experimentation.

NGC2 should nevertheless not be mistaken for a finished system. It is better understood as an architecture that moves from experimentation to continuous delivery and progressive scaling. That distinction is important. The real test will come when the architecture must accommodate thousands of users, legacy systems, multiple security domains, an enormous number of unmanned sensors and effectors, rapidly changing applications and operations, and sustained cyber and electromagnetic attack.

A successful demonstration of sensor-to-shooter connectivity is one thing; maintaining a coherent digital ecosystem during prolonged large-scale combat is considerably harder.

The Larger Transformation

NGC2 is therefore significant not because the US Army has discovered another sophisticated command-post application, but because it is attempting to change the organising principle of military command and control. Instead of acquiring complete systems for individual warfighting functions and then trying to integrate them, the Army is building a common digital foundation into which continuously evolving sensors, applications, AI models, and effectors can be integrated.

Data becomes infrastructure; applications become more replaceable; commercial technologies can be introduced more rapidly; and operational formations participate continuously in development.

The approach also exposes difficult questions that will determine whether the experiment ultimately succeeds. Can the Army exploit Anduril, Palantir, Lockheed Martin and other commercial technologies without becoming dependent upon them? Can it maintain authoritative control over its data architecture while allowing industry to innovate at speed? Can MOSA produce genuine substitutability rather than simply published interfaces? Can a distributed data architecture continue operating when networks are fragmented and contested? And can an acquisition system built around programmes adapt to an architecture that is never really finished?

The future C2 question may consequently no longer be “Which command-and-control system should we procure?”

It may instead be:

“What digital architecture must we control so that any authorised sensor, application, AI model or effector can rapidly become part of the fight?”

That is the larger promise and the real test of NGC2.

Brig Narendra Pratap Singh (Retd)