Start with the dependency, not the product
The Army's PM PNT description says nearly every Army ground combat system relies on PNT information, mostly provided by GPS. That is a substantial dependency. It does not mean every military AI application, autonomous platform, or precision munition relies on GPS in the same way.
Position, navigation, and timing also should not be treated as interchangeable. A platform may require location information for one function and a stable clock for another. An application may receive both indirectly through another subsystem. Its developer can therefore miss the dependency if the assessment stops at equipment with a GPS antenna.
For a program manager, the first useful deliverable is a dependency map: where the information originates, which interfaces carry it, which functions consume it, and who is responsible when its quality changes. Include supporting services and stored data. A replacement receiver cannot correct a downstream application that treats an old coordinate as current or discards the uncertainty information supplied with it.
Avoid importing a demanding performance number from another program simply because both use AI. Accuracy, availability, integrity, and timing requirements belong to the particular function and operating conditions. A fixed installation, a moving platform, and an administrative application need different evidence. Equally, the existence of an inertial backup does not establish how long any particular system can remain useful. That has to be demonstrated for the intended use.
The NIST foundational PNT profile provides a risk-management framework for organizations using PNT. It is helpful for structuring that assessment; it is not a product certification or a substitute for a program's applicable requirements.
Three complementary approaches—and the limits of each
A useful way to discuss the technology is to separate protected reception, alternative sources, and integration. This is an explanatory model, not a single mandated architecture for every Defense Department platform.
Protected GPS reception seeks to preserve access to authorized signals under difficult conditions. Military GPS modernization includes M-Code, but the capability depends on compatible equipment and the wider system. In its September 2024 review, GAO described delays and risks across ground control, receiver development, testing, and integration. Those are dated findings, not a claim that every reported problem remains unchanged today. They illustrate why satellite capability and usable capability on an installed platform are different milestones.
A buyer should ask which configuration was evaluated and which dependencies remain outside the proposed delivery. A modernization label alone does not establish that a receiver, its software, installation, and receiving applications have completed the necessary integration. It also does not establish immunity to interference.
Alternative sources reduce reliance on a particular external reference. Inertial sensing, terrain or visual references, and other available signals belong in this discussion, but their constraints differ. Visual odometry is a sensing method, not a radio signal of opportunity. A terrestrial service such as eLoran depends on available infrastructure; it cannot simply be assumed present wherever a platform might operate. An alternative that is useful in one environment may contribute little in another.
The acquisition question is whether the alternative provides sufficiently independent, usable information for the approved application. Two nominally separate feeds may share an upstream dependency. Additional sources also bring installation, calibration, software, maintenance, and support obligations. Counting sources is a poor substitute for understanding them.
Integration and estimation determine how information becomes a usable output. Conventional estimation methods as well as machine learning may have a role; sensor fusion is not inherently an AI problem. A fallback architecture is not automatically defective, and continuous fusion is not automatically reliable. Both must be assessed against their intended use and failure behavior.
The important evidence concerns what happens when inputs disagree, become stale, or disappear. Does the receiving application understand the changed quality? Can the responsible operator distinguish a valid restricted operating state from an unrecognized failure? Those questions belong in the system evaluation, alongside accuracy under favorable conditions.
Loss of service and misleading service are different risks
Jamming and spoofing should not be reduced to a simple hierarchy in which one is always obvious and the other always silent. Their effects and detectability depend on the system and conditions. The distinction worth preserving is between losing useful information and continuing to receive information that should not be trusted.
For a non-sensitive illustration, consider a maintenance coordination dashboard that shows equipment positions and the time of their last update. If a feed stops, the dashboard may visibly mark the equipment unavailable. If an old position is repeatedly displayed with a fresh processing timestamp, the same dashboard can appear healthy while misleading its users. More connectivity would not necessarily solve that problem. The application must preserve the meaning of the source data and its age.
That example is not a reported incident or a description of a particular military system. It shows why integration review needs more than a demonstration that messages continue arriving. Source time, receipt time, validity, and uncertainty may carry different meanings. Interface documentation and application behavior must agree on those meanings.
Cross-checking sources can help identify inconsistency, but disagreement does not automatically identify which source is right. Nor does agreement prove independence. The responsible engineering team needs evidence for its interpretation and the approved response. Procurement language should seek that evidence rather than promise that adding a fusion engine eliminates deception risk.
What the Army programs establish
The Army's PM PNT portfolio includes mounted and dismounted capabilities under Capability Program Executive Intelligence and Spectrum Warfare. MAPS addresses mounted applications; DAPS addresses dismounted requirements. The program describes modular sources, integrity, and alternative navigation as elements of its approach.
An Army announcement published March 4, 2025 reported a successful full-rate production decision for MAPS Gen II. The Army subsequently reported fielding to units in September 2025. These are concrete acquisition and fielding developments. They do not prove compatibility with every receiving platform or complete coverage of the force.
Organizational history also needs a clear boundary. The Army announced the All-Domain Sensing cross-functional team in March 2024, following the earlier A-PNT/Space team's work. A changed charter does not mean every PNT engineering problem has been solved.
The same caution applies to organizational proximity. TITAN and PNT capabilities can raise related data-quality questions, but placement within an acquisition organization does not establish a particular TITAN requirement, an approved interface, or a required MAPS installation. Those conclusions require the actual program documents. For contractors, the defensible path is to trace the relevant requirement and interface for the specific opportunity rather than generalize from the organizational chart.
DARPA's contribution is research history, not an active program claim
DARPA's Adaptable Navigation Systems page is an archive for a completed program. It describes final demonstrations planned for fiscal 2017 and explicitly warns that the page is no longer maintained. Presenting ANS as a current effort would misstate its status.
Its research themes remain useful context. PINS explored precision inertial navigation, including cold-atom approaches. ASPN addressed combining available sources and reducing the difficulty of integrating different sensors. These strands illustrate two distinct burdens: improving the underlying measurement and making heterogeneous sources usable together.
Research results should still be separated from a deployable acquisition offering. A historical demonstration does not establish current product maturity, manufacturing capacity, qualification, or support. A supplier drawing on that lineage should identify the actual deliverable and the evidence that applies to it. Buyers should be able to distinguish a promising research direction from a configuration they can evaluate, acquire, and sustain.
Timing deserves its own review
A location-focused assessment can miss the clock. Networks and applications may need a common time reference even when their immediate task is not navigation. Loss of that reference can affect how information is ordered, compared, or judged current.
GPS timing capability is often summarized with a very small error figure. The official GPS accuracy explanation qualifies its timing discussion with receiver and operating assumptions, including specialized fixed time-transfer equipment. That figure should not be copied into a requirement as though it describes every deployed receiver, local clock, or application timestamp.
Local oscillators, including chip-scale atomic clocks where appropriate, and alternative timing arrangements are candidates for evaluation. Their inclusion does not automatically establish acceptable holdover—the period during which local time remains usable without its external reference. The allowable deviation and duration must follow the receiving application's need.
Timing review should follow the information all the way to the consumer. Which clock supplied a timestamp? Does a processing delay change how the application interprets it? Who owns the policy for stale data? If the reference returns, how is restored service established? The purpose is to define supportable behavior and responsibility, not to impose one clock technology on every system.
Read acquisition signals at their actual level of authority
Autonomous ground systems, collaborative aircraft, and air-defense systems are reasonable places to ask about position and timing dependencies. Naming those programs, however, is not evidence that they all contain the same A-PNT requirement. Neither “AI-enabled” nor “contested environment” supplies a universal interface specification.
The introduced text of S. 2277, the GPS Resiliency Report Act, dated July 15, 2025, proposes reporting on vulnerabilities, threats, and alternatives. That text is evidence of a legislative proposal. It is not an enacted procurement mandate, a fielding assessment, or proof that every solicitation requires a particular design.
Industry should therefore separate three things in capture and proposal work: the operational concern, the applicable solicitation requirement, and the contractor's proposed means of satisfying it. Blending them can produce an attractive description that the buyer cannot evaluate—or an unnecessary design commitment that raises cost without addressing the actual requirement.
What to bring to the technical review
A useful review package answers six questions:
- What depends on PNT? Identify the receiving functions and indirect dependencies, including timing and supporting services.
- What is the accepted operating envelope? State the conditions and limits supported by evidence, and distinguish proposed capability from demonstrated capability.
- What does the receiving application know? Explain how validity, age, and uncertainty reach it and how those meanings are preserved across interfaces.
- Which claims depend on outside services? Identify assumptions about coverage, configuration, availability, and genuinely independent sources.
- Who accepts and supports the integrated result? Separate component delivery from system acceptance, training, configuration control, and maintenance responsibility.
- What change requires another review? Define how a new receiver, software revision, alternative source, or receiving application affects the evidence supporting acceptance.
These are recommended review questions, not a claim of a universal Defense Department checklist. The applicable contract, platform, security requirements, and authorized test process remain controlling.
Spend against the demonstrated gap
There is a real budgeting choice behind this discussion. An organization can invest in a new source, improve an existing integration, restrict an application to a supported use, or defer a function until adequate evidence exists. The right choice depends on the gap actually demonstrated. Buying more equipment before locating that gap can leave the receiving software's mistaken assumptions intact.
A disciplined first step is to select one consequential dependency and follow its acceptance evidence from source to user. Record the supported conditions, unresolved assumptions, responsible owner, and next decision. If the evidence supports only limited use, say so. If a proposed upgrade removes an important limitation, show exactly which evidence supports that conclusion. This gives acquisition leaders a basis for comparing cost and benefit without pretending every program needs the same solution.
Sources and further reading
- NIST foundational PNT risk-management profile
- Army PM PNT: mounted and dismounted programs
- GAO's September 2024 GPS modernization review
- DARPA Adaptable Navigation Systems: completed-program archive
- GPS.gov: accuracy and timing assumptions
- S. 2277: introduced bill text, July 15, 2025
Spartan X's work on edge computing and operation in disconnected, degraded, intermittent, and limited-bandwidth environments brings a relevant systems perspective to this problem. The useful discipline is connecting infrastructure behavior to application behavior: knowing what the data can support, making uncertainty visible, and ensuring the delivered capability remains supportable when the assumptions behind a clean demonstration no longer hold.
