Before the Model: What AI in the National Airspace System Needs From Its Data Exchange

Most discussion of AI in air traffic management starts with the model: what it predicts, how accurate it is, who certifies it. Our work starts further upstream. Concept Solutions supports FAA systems on both sides of System Wide Information Management (SWIM), the network that carries flight, weather, and airspace data across the National Airspace System (NAS). Some of those systems consume SWIM feeds and turn them into durable analytical records. Others publish operational data that other systems and airspace users act on. From that position, the limiting factor for AI in the NAS looks less like model quality and more like whether the data moving between systems can be trusted, understood, and traced to its source.

Two disciplines decide that. The first is schema discipline: service contracts that machines can read and validate. The second is governed two-way access, so that partners who publish into the exchange are held to clear rules. The FAA is already moving SWIM toward both, which makes this a good time to look at what each one takes.

Where ESCS fits

The FAA has been working toward both disciplines for several years. In May 2022 it briefed industry on Enhanced SWIM Cloud Services (ESCS), a cloud-based exchange for aviation mission partners and international users that supports two-way data exchange and a self-service portal with automatic provisioning, and it is delivering ESCS in releases. The FAA already distributes SWIM data through Solace messaging, and in September 2026 Solace announced an extended partnership with the agency. In that announcement, Solace said ESCS will replace Word-file documentation with machine-readable APIs built on the AsyncAPI standard, give FAA Data Partners a path to publish data back into SWIM, and set the stage for AI decision support.

Those are the right priorities. Machine-readable service descriptions won’t remove access agreements, security reviews, or connection approvals, but they can cut the time teams spend reading documents and reconciling details by email. What has not been described publicly yet is how partner publishing will be governed, and that is where the hardest decisions sit.

Schema discipline is the real AI story

A model consuming live event streams is only as reliable as its understanding of what each message means.

A human analyst can read a footnote in an interface document and adjust. A decision-support agent cannot. If a field is renamed, if an optional element starts arriving populated, or if a message structure changes between versions, the model does not raise its hand. It quietly reasons over bad input, and in aviation, quiet errors are the expensive kind.

If ESCS adopts AsyncAPI as Solace describes, that change deserves more attention than it will probably get. Message payloads already come with XML schemas, published on the FAA’s NAS Service Registry and Repository (NSRR) and often built on FIXM or AIXM. What has lived in Word files is everything around them: channels, connections, versioning, and behavior. AsyncAPI makes that layer machine-readable too, so the service contract becomes the source of truth instead of a document that drifts from the code. Channels, message structures, and versions become things software can inspect, validate against, and alert on. You can test a consumer against a contract before it ever touches production traffic. You can detect breaking changes in a pipeline rather than in an incident review. Contracts have limits, though. A field that switches units, or two producers reading a status code differently, can pass a schema check as long as the data type holds. Shared definitions of what the data means still have to be agreed separately.

Schema discipline is what turns a firehose into a dataset. Without it, every AI program built on SWIM would spend its first year reverse-engineering the feed. With it, teams can spend that year on the decision problem itself.

Two-way access has to be governed, not just opened

Bidirectional publishing is the more ambitious half of ESCS, and the half that needs the most care. Once partners can write into the national exchange, the questions change. Who is authorized to publish which message types? How does a consumer know whether a message came from an authoritative FAA source or a partner? What happens when a partner’s feed degrades, duplicates, or contradicts another source?

We haven’t seen a published governance model for partner publishing, so here is our view. These are governance questions, but they get answered in architecture. Topic-level publish permissions, provenance carried in every message, schema validation at the point of entry, and clear ownership of each stream are what make two-way access safe to scale. Collaborative decision-making only works when every participant trusts the shared picture, and trust is something the platform has to enforce rather than assume.

This matters doubly for AI. A model that acts on live streams inherits every weakness in how those streams are governed. If provenance is ambiguous, the model’s recommendations are too. Governed two-way access is what lets an operator put an AI recommendation in front of a controller or dispatcher with confidence.

What we see from inside the pipe

Here is what supporting both sides of the exchange looks like at Concept Solutions (CS). On the consuming side, we support FAA systems that ingest SWIM feeds into long-term data stores, where live operational messages become a durable analytical record. On the producing side, we support FAA systems that publish airspace status data to SWIM, so the consumers who plan around restricted and military airspace know when it is active. That combination gives us an honest view of where the friction lives. Three lessons stand out:

First, ingestion is the easy part; interpretation is the hard part. Moving messages off SWIM and into an analytics platform is well-understood engineering. Most of our effort goes into normalizing message variants, handling schema evolution without breaking downstream queries, and preserving the context an analyst or model needs to trust a record months later. Machine-readable AsyncAPI contracts should narrow that cost, though agreeing on what each field means will remain separate work.

Second, publishing is a responsibility, not just a capability. When the systems we support put airspace status data on SWIM, other systems act on it. That has shaped how we validate before publishing, how we version our messages, and how we monitor delivery. Every partner that gains publish rights under ESCS will learn the same lesson, and the ones who design for it early will move faster later.

Third, the warehouse and the stream need each other. AI decision support will run on live events, but it will be trained, tested, and audited against history. A program that treats real-time exchange and long-term data management as separate efforts risks ending up with models it cannot explain. In our view, keeping the two connected is what will make any AI-readiness claim credible.

Building ahead of demand

Infrastructure that arrives after demand gets built in a hurry, and hurried data infrastructure is where shortcuts become permanent. Partner publishing is still ahead of demand. ESCS is designed to standardize service contracts and open write access before most partners are ready to publish, which gives the FAA a chance to set the rules first.

AI is not ahead of demand. On September 21, 2026, the FAA put the Strategic Management of Airspace, Routes and Trajectories (SMART) platform into limited operation around Washington, D.C. SMART centralizes 200 data streams, including weather, flight paths, traffic flow, and controller staffing, into one decision-support view. An AI tool now in FAA operations depends on fusing feeds it has to trust. For AI, data discipline is not ahead of schedule. It is overdue.

Timing matters for new entrants too. Advanced air mobility operators, vertiport developers, and drone service providers will all depend on airspace data that flows through FAA exchanges, whether directly or through gateways, at volumes and cadences the current NAS was not built around. Each of them, or the gateways serving them, will either plug into a disciplined exchange or bolt on a one-off integration. ESCS is designed to make the first option the easier one. For operators and integrators, the practical takeaways are straightforward:

Treat AsyncAPI specs as code: version them, test against them, and wire contract checks into your pipelines.

Design for provenance from day one, so every message you consume or publish can answer where it came from.

Plan publish capability as an operational commitment, with validation, monitoring, and ownership defined before the first message goes out.

Keep the stream and the archive connected, because the models you build on one will be judged against the other.

The airspace of the next decade will be shared by more kinds of aircraft and more kinds of software than today’s. Making it intelligent depends less on any single algorithm than on whether the data underneath is trustworthy, discoverable, and governed in both directions. ESCS gives the FAA the foundation. Whether AI can stand on it depends on the discipline every publisher and consumer brings to the exchange. At CS, that discipline is the work we do every day.