AIXM 5.1.1 Integration: Why Time Slices Are Not Live State

AIXM 5.1.1 integration turns structured aeronautical information into records another system can use. The critical distinction is between reading an assertion and establishing what applies at a particular time. A runway closure, a revised airspace definition and an airport baseline are not interchangeable updates. Their identities, validity periods and interpretation must survive translation before a consumer can determine the relevant state.

The Aeronautical Information Exchange Model (AIXM) expresses aeronautical features through a data model, XML schemas and temporal rules. Its 5.1.1 specification provides the context for this article. SynapseCommand's published implementation illustrates both the value of a precise ingest contract and the work that remains downstream.

At a glance

The AIXM governance description explains the specification's change-control role. SynapseCommand's current adapter catalogue identifies its AIXM 5.1.1 implementation as ingest-only, L3 and VERIFIED, with a declared path ledger. Those labels describe different aspects of a bounded implementation; they should not be combined into an unrestricted compatibility claim.

The feature persists while its assertions change

A feature and a document element need different identities. A runway may appear in several deliveries as its properties change. Treating each delivery as a new runway would fragment its history; treating every element identifier as a permanent feature key would create a different problem.

The AIXM feature-identification guidance distinguishes `gml:identifier`, used for feature identity, from the document-local `gml:id`. It also explains that consistent identification across systems depends on information-management processes. A UUID is not, by itself, proof that two independent providers have reconciled their records.

For an integrator, that creates two separate responsibilities: preserve the source's persistent identity during translation, then establish how identities from different sources will be governed. Name matching or coordinate proximity should not silently replace that agreement.

This differs from the surveillance-message problem discussed in the ADS-B integration analysis. Here, the central question is how a published feature's assertions relate over time, rather than how an aircraft report becomes a position-bearing record.

A baseline, a change and a snapshot answer different questions

The AIXM Temporality Concept 1.1 distinguishes several interpretations of a time slice. The following table gives their practical reading, rather than a replacement for the specification's full rules.

A temporary change ending does not mean that every property becomes available or returns to an assumed default. It means the applicable baseline matters again. The period, interpretation and correction information therefore belong in the consumer contract alongside the visible status.

Arrival time cannot safely substitute for this model. “Last message wins” is a delivery policy; it does not establish which assertion is valid. A delayed baseline, an early correction or an out-of-order temporary change can all expose that mistake.

What the SynapseCommand adapter actually produces

The published AIXM 5.1.1 adapter source describes a stateless translation boundary. It produces an Entity for each time slice in its supported feature families. Several slices of the same feature retain the same feature identity while representing separate assertions.

The typed reading carries temporal interpretation, sequence and correction information, validity and the supported feature properties. Unconsumed source content remains inspectable in a structured residual. Residual preservation is valuable, but it is not equivalent to assigning every field an operational meaning.

The implementation distinguishes absent, nil, unchanged and withdrawn property states. Collapsing them into a single null would discard information that a later resolution step may need. Consumers should validate the typed block they read, rather than assuming that a generic Entity contains a complete, timeless feature description.

For a supported, projectable airspace geometry, translation can also produce a control-measure PlanObject containing an Area. That output is conditional on what the slice actually states. An Entity without a drawable area is not permission to invent one. The canonical data model documentation explains the object types a consumer receives.

The website's architecture overview places the public integration layer within the wider system. Inspecting this adapter does not expose or validate the private decision runtime.

Resolution needs history and an explicit instant

There is a separate public AIXM temporality resolver. It takes translated objects, a feature identifier and an explicit “as-of” instant. The caller supplies the records to consider; the resolver does not maintain a history store between calls.

That separation is useful because it makes missing context observable. The resolver can report an unresolved or ambiguous result instead of manufacturing certainty. It is bounded processing of availability and activation assertions, not a general flight-planning engine or a complete reconstruction service for every AIXM property.

Consider a synthetic example. A supplied baseline states normal availability. A temporary assertion states a closure from 09:00 to 10:00 UTC. Assume one unambiguous feature, no corrections, no schedules and no competing records. A query at 09:30 can apply the closure. At 10:00, the temporary interval has ended and the supplied baseline becomes relevant again. Remove the baseline from the input and the same calculation no longer has the context to establish normal availability after the closure.

Now add two competing temporary assertions affecting the same property over overlapping intervals. The published resolver can report ambiguity rather than choosing whichever document arrived last. That outcome is useful evidence about the input set, not a defect to conceal from the consuming application.

Schedules introduce another boundary. This resolver retains Timesheets as structured information; it does not evaluate their day-and-time rules into a definitive status. Downstream software must preserve that distinction. A broad validity window containing a daily schedule does not mean the feature has the same status continuously throughout the window.

This example is an editorial illustration of the documented contract, not a result from an operational airport feed or a newly executed test.

Geometry and references have their own boundaries

A time-correct record can still be spatially misleading. Coordinate order, vertical units, vertical reference and the supported geometry forms each affect what a consumer may draw or compare.

The adapter's published tests include cases for EPSG:4326 and CRS84 axis interpretation, unsupported curves, vertical references and unresolved references. These are separate concerns. Converting a length unit does not transform an altitude datum, and preserving a source shape does not establish that it can be projected into the target Area model.

The current implementation refuses specified unsupported geometries by default. An optional reporting mode can retain the affected slice and identify the unsupported form without creating a PlanObject. Composed airspace volumes can likewise remain represented without being drawn as a single canonical volume. Consumers need to distinguish an absent display projection from an absent source feature.

Reference handling is also deliberately bounded. The adapter resolves references within the document and a caller-supplied reference table, one hop. It does not fetch a URL over the network merely because that URL appears in a reference. An integration service must therefore decide what reference material to provide and how unresolved references will be exposed.

These boundaries belong in acceptance examples. A visually convincing map is insufficient if a withheld geometry, unresolved reference or incompatible vertical reference has disappeared from the accompanying record.

Digital NOTAM support is a pinned subset

A Digital NOTAM represents a change using structured aeronautical data. That does not make “Digital NOTAM support” one indivisible capability. The official scenario overview organises the work into specific coding scenarios and identifies their development status.

SynapseCommand's AIXM 5.1.1 manifest pins Event Schema 2.0.m and four scenario profiles: RWY.CLS, ATSA.ACT, SAA.ACT and NAV.UNS. It identifies the referenced Digital NOTAM Specification 2.0 guidance as draft. The article does not upgrade that pinned guidance to an approved final standard.

The implementation reads event bindings and records applicable findings. Reading a cancellation or replacement assertion is distinct from resolving its effect against prior state. The adapter does not become a NOTAM generator, publisher or aviation authority through those capabilities.

Version selection remains explicit. AIXM 5.2 is a published specification, so 5.1.1 should not be presented as the latest release. SynapseCommand has a separate 5.2 adapter. This article's temporal-ingest case study does not establish migration equivalence, interchangeability of namespaces or coverage of 5.2 extensions.

What the published evidence establishes

The technical baseline examined here is the public code at the synapse-cdm 3.3.0 release. This is an implementation analysis, not an announcement that AIXM 5.1.1 support has just launched.

The manifest declares L3 provenance evidence and a path-bound preservation ledger for the shipped fixtures. That ledger records where supported source values are represented, including residual content. It provides a more specific inspection basis than a generic statement that XML was parsed successfully.

The same manifest explicitly withholds L4. This adapter is ingest-only, so a reverse AIXM round trip is inapplicable, not a passed egress test. Its schema-validation evidence also depends on the pinned schema resources and validation dependencies being available. A blocked check must remain visibly blocked.

The trust and assurance boundary should remain explicit when these results are used in a procurement or integration review.

Engineering teams can use the open integration package to inspect and reproduce the relevant checks. This article reviewed published source and evidence descriptions; it does not claim a fresh test run, external certification or deployed-system acceptance.

A practical acceptance handover

The following handover is an editorial synthesis for evaluating a bounded AIXM ingestion contract. It separates the questions that a successful parser alone cannot answer.

For organisations assessing system compatibility, these records turn a broad format claim into an inspectable delivery contract. The useful outcome is a consumer that can tell what the source asserted, what the software derived and what remains unresolved at the requested instant.