Army MAPS Gen II: The IP Shift That Matters for AI

A single line in a recent Army request for information (RFI) says more about the future of defense AI than a dozen glossy strategy decks: for the next iteration of MAPS Gen II, the Army wants the prime contractor to hand over the intellectual property—enough drawings, documentation, and software source code to create a true “build-to-print” package.

That’s a big deal. Not because “IP” is a contract buzzword, but because AI-enabled defense systems don’t age like traditional hardware. They improve (or degrade) based on data, model updates, patching speed, and the ability to integrate new sensors and algorithms under pressure. When the government can’t access the guts of a system, it can’t fully secure it, sustain it, or adapt it.

MAPS Gen II—Mounted Assured Position, Navigation, and Timing—is about keeping ground forces oriented when GPS isn’t reliable. That’s already mission-critical. Layer AI into mission planning, autonomy, EW threat detection, and contested navigation, and the policy question becomes blunt: Who controls the system’s evolution during a fight—the military or the vendor?

MAPS Gen II and why “assured PNT” is an AI problem

Assured PNT is no longer just a navigation problem. It’s an information advantage problem.

MAPS Gen II is designed to deliver accurate position, navigation, and timing to Army ground vehicles, especially in GPS-denied environments. In practice, that means operating through jamming, spoofing, interference, terrain occlusion, and degraded satellite visibility.

Here’s where AI shows up, even if the word “AI” isn’t printed on the label:

• Sensor fusion: Combining inertial measurement units (IMUs), vehicle odometry, terrain maps, signals-of-opportunity, and other inputs to maintain a trustworthy solution.
• Anomaly detection: Flagging spoofing or subtle navigation drift before it becomes catastrophic.
• Adaptive filtering: Adjusting models dynamically as conditions change (speed, vibration, weather, EW intensity, urban canyon effects).
• Assurance scoring: Estimating confidence in the current PNT solution so downstream systems (fires, autonomy, mission command) can behave safely.

If you’ve worked AI programs in defense, you’ve seen the pattern: the “model” is only part of the system. The integration surface is the product. And that’s exactly why MAPS Gen II’s IP posture is suddenly center stage.

Why the Army is demanding IP now (and why it’s rare)

The Army’s RFI states it lacks rights to the detailed drawings, technical documentation, and software source code needed to provide a build-to-print package to a third party. Translation: even if the Army wants competition, repair at scale, or rapid modernization, it may be boxed in.

This is unusually direct language for a major program because it’s effectively saying: we’re not doing that again.

There are three drivers behind the shift:

1) Sustainment speed beats perfect procurement

The battlefield punishes slow repair cycles. If a vehicle-mounted system becomes a bottleneck—because only one supplier can build or modify it—operational readiness takes the hit.

Army leaders have been increasingly vocal about the cost of not owning what you buy. Lt. Gen. Christopher Mohan has argued that when the Army doesn’t own IP, it becomes difficult or expensive to reverse engineer parts or use methods like additive manufacturing (3D printing) to replace them quickly.

2) AI systems need updates like cybersecurity needs patches

For anything software-defined, delays aren’t just annoying—they’re dangerous.

A MAPS-like system sits at the intersection of navigation, mission command, networking, and cyber. If vulnerabilities are discovered, the government needs the ability to:

• inspect critical code paths,
• validate fixes,
• patch across fleets,
• and re-certify quickly.

Owning (or at least licensing) the right IP artifacts makes that feasible.

3) Congress didn’t deliver “right to repair” language

Right-to-repair provisions were debated but ultimately stripped from final legislative language this cycle. That matters because acquisition reform pressure didn’t vanish—it just moved.

If broad policy won’t force repair rights, program offices will increasingly do it the hard way: write IP expectations into solicitations.

Open IP isn’t “open source”—it’s operational control

There’s a common misunderstanding in industry conversations: “The government wants our IP” gets interpreted as “they want to publish it” or “they want to give it to competitors.”

That’s not what this is.

A practical open IP framework in defense usually means structured government-purpose rights (or negotiated equivalents) so the service can:

• compete production,
• compete sustainment,
• integrate third-party components,
• and avoid dead-end vendor lock.

For AI-enabled systems, open IP has a second benefit: you can separate the innovation layers.

• The government can own the interfaces, data rights, and integration documentation.
• Vendors can still protect proprietary optimizers, manufacturing secrets, or internal tooling.
• The program gains the freedom to swap sensors, retrain models, or add a new EW detection module without rewriting the entire architecture.

Here’s the stance I’ll take: If a defense system is mission-critical and software-defined, the government should treat data rights as a readiness requirement, not a contracting preference.

What the RFI signals about scale: 150 systems/month (surge 300)

The Army also states it wants 150 systems per month, with surge capacity to 300 per month within 12 months of award.

That production tempo matters for two reasons:

1. Supply chain resilience becomes part of the technical design. If you can’t diversify manufacturing because of IP restrictions, surge is a promise you can’t keep.
2. Cyber risk scales with deployment. A vulnerability in a widely fielded PNT subsystem isn’t a niche engineering problem—it’s a fleet-wide operational risk.

At scale, you need repeatable installation, consistent configuration management, and disciplined software baselines. IP access supports all three.

Cybersecurity and AI in PNT: where vendors get tripped up

If you’re building AI-adjacent PNT, your biggest risk usually isn’t “the model isn’t accurate enough.” It’s that the system isn’t assurable.

What “assurable” means in contested PNT

Assurance is the ability to prove—under stress—that the output can be trusted.

In a GPS-denied environment, cybersecurity and AI safety overlap:

• Spoofing is both cyber and perception. If your system can’t detect subtle deception, autonomy and mission planning will ingest lies.
• Timing errors cascade. Timing feeds comms, fires synchronization, network coordination, and sensor fusion. Small errors become big operational failures.
• Updates are an attack surface. The more software-defined the system, the more you must harden the update pipeline (signing, SBOM discipline, provenance).

A vendor partnership that restricts code visibility can slow down vulnerability response and independent verification. If the government is serious about Zero Trust principles, it can’t accept black boxes in core navigation and timing indefinitely.

What smart vendors will propose instead of fighting the IP request

Some companies will see the Army’s IP requirement and walk away. The smarter move is to respond with a structure that protects commercial value while meeting operational needs.

If I were advising a vendor team, I’d suggest packaging an offer around three negotiables:

1) Rights by layer (hardware, firmware, software, AI components)

Not everything needs identical treatment.

• Provide build-to-print for mechanical/electrical assemblies.
• Provide escrow or controlled access for sensitive source code modules.
• Provide documented APIs and data schemas as government-purpose rights.

2) A reference architecture the Army can maintain

Give the program office enough system architecture diagrams, interface control documents, and test vectors to support third-party sustainment.

This is where AI integration lives: interfaces, telemetry, logs, and confidence metrics.

3) A secure modernization pipeline the government can trust

For AI-enabled systems, modernization is continuous. Propose a pipeline that includes:

• signed build artifacts,
• reproducible builds,
• rigorous configuration management,
• red-team testing hooks,
• and update rollback capabilities.

That’s the kind of proposal that turns an “IP surrender” narrative into an “operational partnership” narrative.

People also ask: does owning IP actually make the Army faster?

Yes—when it’s paired with an engineering plan.

Owning rights without the ability to integrate, test, and certify changes is paperwork. But with the right technical approach, IP access enables:

1. Competition at the sustainment layer (lower cost, faster parts)
2. Rapid vulnerability response (fewer approval chokepoints)
3. Modular AI upgrades (swap components without a full redesign)
4. Training and field support independence (less reliance on one OEM)

The MAPS Gen II RFI is a sign the Army wants those outcomes, not just better contract language.

What this means for AI in Defense & National Security in 2026

MAPS Gen II is “just” a vehicle PNT program—until you recognize PNT as a backbone for autonomy, mission command, surveillance, and electronic warfare.

The more the military relies on AI to fuse sensor data, prioritize targets, route logistics, and support commanders under time pressure, the more it needs systems that can be inspected, secured, repaired, and upgraded without permission slips.

This RFI points toward a future where:

• open IP frameworks accelerate AI development by enabling multi-vendor experimentation,
• cybersecurity becomes a first-order selection criterion in AI vendor partnerships,
• and government acquisition treats data rights as part of operational resilience.

If you’re building or buying defense AI, this is the question worth arguing about internally: Which parts of your mission stack can you afford to treat as proprietary black boxes?

If your answer is “navigation, timing, and the trust layer that feeds everything else,” you’re probably pricing in risk you don’t want.

---

If your team is evaluating AI-enabled defense systems (PNT, autonomy, ISR, cyber), we can help you map IP and data-rights decisions to real operational outcomes—competition strategy, security posture, and upgrade velocity. What part of your stack would you want to rebuild in a surge scenario: hardware, software, or trust?