NGC2: Too Command to Control

Saturday, 04 October, 2025

I skimmed a Reuters article saying that a battlefield communications prototype has deep flaws.
Painfully relatable: comms-system flaws (a subset of the painfully relatable topic of “system flaws”). The real question is whether they’re embarrassing, catastrophic, or just the kind you fix after a weekend of debugging. When I was working on airline reservation systems, it was always a relief to note that if I screwed up the system, planes wouldn’t crash; the airline would just lose millions of dollars and make the network news.

I have zero experience with battlefield communications, but I’ve worked as a ham-radio volunteer with the Wasatch Front 100 Mile Endurance Run. We’re currently modernizing the runner-tracking system. The “legacy” system is built on AX-25 packet radio, but even that system relies more and more on Internet links — basically substituting telnet for the packet-radio interface. More than one aid station connected over Starlink at the 2025 race.

Scanning the article, the acronym NGC2 stood out. It means “next-generation command and control.”
Searching for that term led me to peoc3n.army.mil (a real “.mil” URL? Bad-ass — pardon my French).

The briefs seem very buzzword-compliant to this Seasoned Software Engineer: simplify networks, adopt open architecture, modular systems, build from a data backbone. The Army even talks about iterative prototyping.
At the same time, the Army is collapsing multiple legacy funding lines into this portfolio (DefenseScoop).
And to prototype, they awarded Team Anduril an OTA for $99.6 million over 11 months (Breaking Defense).
The Army’s total portfolio ask for NGC2 is around $2.95 billion — commonly rounded to ~$3 billion (DefenseScoop).

And here’s where the plot thickens:
An internal Army memo (authored by CTO Gabriele Chiulli) calls the current prototype “very high risk,” citing security gaps: unrestricted data access, missing activity logs, unclear user boundaries, and code vulnerabilities in third-party modules.
Palantir pushed back, saying the memo snapshot is outdated and that vulnerabilities are being addressed.

So what am I trying to say? A few takeaways:

• This is familiar territory. The core engineering problems — degraded ops, bandwidth prioritization, chaotic integration — are ones I’ve sweated over on a smaller scale. That makes this story less about hype and more about scaling tough trade-offs.
• Prototyping is smart. Spending ~$100 million to test real-world behavior is a risk, but the real risk is not that the system doesn’t work; it’s that they don’t learn anything from its failures.
• Open architecture is the only sane path. If they actually deliver modular APIs, a shared data layer, vendor on-ramps, etc., then this might break the legacy-vendor trap. But that’s the $2.95 billion question.
• Buzzwords are cheap; execution is expensive. “Agile,” “data-centric,” “interoperability” — sure, get the slide deck approved. Executing those buzzwords in “contested environments” (a favorite euphemism I just learned) is another story entirely: challenges include power limits, hardware failure, organizational inertia, and (cover your manager’s ears) key distribution.

Being in the Accenture universe for a few years gave me the flavor of gigantic projects and contracts. But government — let alone military — contracts are out of my league. I just skimmed the article (I couldn’t find the actual memo… Reuters cited it as “an internal Army memo”).
Still, if I want to be a l33t 21st-century h4x0r, I’d better learn the new colors of Crayola books.

Bibliography & Further Reading

• Reuters: Anduril and Palantir battlefield communication system ‘very high risk’