The Future of PNT Is Multi-Source. The Data Architecture Has to Keep Up.

‍

For decades, GPS has provided the foundation for positioning, navigation and timing across military, commercial and civilian systems. But in contested environments, relying too heavily on any single source creates risk.

Jamming, spoofing, signal obstruction and other disruptions are driving the Department of Defense toward more resilient PNT architectures. The U.S. Space Force's recently published NAVWAR Objective Force makes that direction clear: future PNT will be built around a hybrid, multi-layered architecture that combines sovereign GPS capabilities with allied systems, commercial SATNAV, SATCOM-delivered PNT and complementary onboard sensors.

At the 2026 Space Symposium, Chief of Space Operations Gen. Chance Saltzman described the same direction, calling for diverse allied and commercial navigation and timing systems to augment GPS, supported by interoperable data standards.

The goal is resilience. But adding more PNT sources introduces another challenge: How do you make all of those different sources work together?

Alt-PNT Is Becoming a Multi-Source Data Problem

There may not be a single replacement for GPS that works for every mission or every operating environment. Instead, emerging Alt-PNT architectures increasingly combine multiple technologies and data sources.

We're already seeing this reflected in government-funded development programs.

A Space Force Phase II SBIR for Alternative Position, Navigation, and Timing Sensor Integration in Space-Based Environments, for example, combines high-precision inertial measurement units, multiple GNSS receivers, radar-based navigation and sensor-data integration algorithms into a hybrid PNT solution.

Other programs are exploring high-frame-rate astronomical imagery, atomic clocks and astrometric measurements. A Navy SBIR describes a modular open architecture capable of incorporating multiple PNT sensors and integrity algorithms while identifying and rejecting faulty measurements.

Different technologies, but the same underlying architectural challenge: multiple sources have to become a coherent, trustworthy input to the algorithms producing the PNT solution.

And those sources don't necessarily speak the same language.

They can produce different data formats, at different measurement rates, through different interfaces. They can have different levels of accuracy and confidence. One source may become degraded or unavailable while the others continue operating.

Before the PNT algorithm can make sense of those sources, the data has to make sense together.

Synchronization Is Fundamental to PNT

Timing adds another layer of complexity.

When measurements are coming from multiple sensors or systems, it isn't enough simply to get all the data to the same destination. The system also needs to understand when each measurement occurred and how measurements from different sources relate to one another in time.

Otherwise, the resulting position or timing calculation can be wrong.

In a multi-source architecture, that means either synchronizing time across the different hosts or aligning incoming measurements to a common time reference at the point where the analytics are being performed.

This is one area where a common data-processing layer becomes particularly important.

Necara's Osteo Data Processing Engine (DPE)™ can preserve multiple timestamps associated with incoming data, providing a consistent way to understand when data originated from different sensors and when it moved through the processing pipeline.

That gives downstream algorithms the timing context they need to measure offsets and make the appropriate adjustments.

Multiple sources don't create resilience simply because they're available. Their data has to be aligned well enough to be used together.

Resilience Also Means Knowing When Not to Trust a Source

Multi-source PNT introduces another important requirement: data quality.

Imagine an architecture drawing from several sources. One begins providing degraded information because of interference, loss of lock, sensor error or another condition.

If the system assumes every input is equally trustworthy, adding more sources doesn't necessarily make the solution more resilient. It may simply introduce another opportunity for bad data to influence the result.

The processing architecture therefore needs a way to carry information about the quality of incoming data through the pipeline.

With Osteo, metadata associated with a source can travel with the data through subsequent processing stages. That might include whether a source is locked, an estimated error, confidence information or whether a measurement has moved outside defined error bounds.

Downstream processing and PNT algorithms can then use that context to determine how the data should be handled.

Osteo isn't making the final PNT determination, it's helping ensure the algorithms making that determination have the data and context they need.

Where Osteo Fits in an Alt-PNT Architecture

Osteo isn't an Alt-PNT solution or navigation algorithm.

It is the data-processing foundation that can sit between multiple PNT sources and the algorithms that use them.

Conceptually, the architecture can look something like:

GPS / GNSS + Inertial + Radar + Optical + Quantum Timing + Other Sources
↓
OSTEO: INGEST → TIMESTAMP → ALIGN → PROCESS → ASSESS
↓
PNT / SENSOR-FUSION ALGORITHMS
↓
ASSURED PNT OUTPUT

Because Osteo is plugin-based, different data sources and interfaces can be brought into a common processing architecture without necessarily redesigning everything downstream.

If a new sensor uses a different format, for example, an appropriate plugin can handle that interface while the analytics or other downstream applications continue working against a consistent interface.

The same architecture can also host additional processing algorithms as plugins, allowing teams to change algorithms, configurations or coefficients as the system evolves.

That flexibility matters in a PNT environment that is itself still evolving.

From the Lab to an Operational System

There's also a less obvious challenge in Alt-PNT development: the hardware you ultimately need may not all exist yet.

Engineering teams frequently have to prototype with only some of the sensors and interfaces that will eventually make up the operational system. Other components may still be under development, unavailable for testing or unable to produce data at the rates expected in the final architecture.

That can create a gap between the system developed in the lab and the system that ultimately has to operate in the field.

Osteo can simulate data based on interface specifications and pass it through the same processing pipelines and algorithms intended for production. Teams can begin testing how components interact before every piece of hardware is available.

As the actual sources come online, those simulated interfaces can be replaced with live ones.

The goal is to make the lab flow look more like the production flow, allowing teams to prototype against an architecture that is closer to what they ultimately intend to deploy.

That can mean handling more data together, testing at more realistic rates and avoiding the need to repeatedly build custom integration software from scratch.

The Architecture Has to Evolve as Fast as the Sources Do

The Space Force's PNT roadmap isn't pointing toward one technology replacing GPS. It's pointing toward a more diverse ecosystem of sources and pathways designed to continue delivering trustworthy PNT even when one layer is degraded or denied.

The Space Force NAVWAR Objective Force is already looking beyond today's sources, identifying quantum timing devices and optical crosslinks as potential future technologies for improving timing stability and constellation synchronization.

That means the data architecture underneath PNT can't be rigid.

New sensors will emerge. Algorithms will change. Interfaces will evolve. Sources will be added, removed or replaced as missions and threats change.

The challenge is building an architecture capable of bringing those sources together, keeping them synchronized, preserving their context and delivering trustworthy data to the algorithms that ultimately determine where you are and when.

That's the data-processing problem behind resilient PNT and one that Osteo DPE can solve. If your PNT mission depends on multiple data sources working together, Osteo can help provide the data-processing foundation. Let’s talk.

‍