The AirIndex Identifier registry.

AIX identifiers are stable, opaque, machine-readable references to AAM assets — markets, heliports, vertiports, corridors, operators, bills, and federal programs. They are designed as the canonical join key the ecosystem can adopt: when a Skyports site report, a TruWeather corridor score, an underwriter policy application, or a UTM service references the same asset, they can all join on the same AIX id.

Why this exists

AAM data is fragmented across federal registries (FAA NASR, FAA OEAAA, SEC EDGAR, Federal Register), state legislatures, municipal records, operator press, and dozens of vertical tools. Each system uses its own internal identifiers. There is no canonical join key the way FIGI works in financial securities, ISBN in publishing, or DOI in academic citation.

AIX fills that gap for AAM. AirIndex maintains the registry; partners adopt the IDs by emitting them in their published artifacts. Once an AIX id is in a public document, it remains valid and resolvable forever — even if the underlying asset is renamed, replaced, or retired.

Format

An AIX identifier is a colon-separated string with three components:

aix:<type>:<suffix>

  type    2–5 lowercase letters from the type vocabulary (see below)
  suffix  4–16 characters from Crockford base32 alphabet
          [0-9 A-H J-K M-N P-T V-Z]  (no I, L, O, U — visual ambiguity)

Validation regex: ^aix:([a-z]{2,5}):([0-9A-HJKMNP-TV-Z]{4,16})$

Example: aix:hp:5KN8R3J2 (a heliport)

The suffix is opaque. It is not derived from the display name, the internal database row id, or any external reference. This is intentional — names change, rows get renumbered, external references break. The suffix never changes.

Type vocabulary

v1 defines the following type prefixes. New types may be added in future versions, but no v1 prefix will ever be reused for a different asset type.

Resolution

Every AIX id resolves at two surfaces:

• Human-readable: https://www.airindex.io/aix/<id> — the canonical landing page for an AIX id. Renders the display name, internal type, cross-references, and a deep link to the relevant AirIndex surface. Public, no auth required.
• Machine-readable JSON: https://www.airindex.io/api/internal/resolve/<id> — returns the canonical record + cross-references + a light-touch payload from the source table. Currently internal-only; the public v1 partner API exposes the same shape under /api/v1/aix/<id>/resolve with bearer-token auth.

Cross-references

Every AIX id carries an xrefs object mapping known external identifiers to their values for this asset. Common keys:

Additional xrefs keys may be added at any time. New keys are non-breaking — existing keys never get renamed or removed without a deprecation notice in this spec and a migration window of at least 12 months.

Lifecycle: rename, replace, retire

AIX identifiers are stable. The suffix never changes when:

• The asset is renamed (display name changes).
• The asset moves between owners.
• The internal database row id changes.
• External references (e.g. FAA site number) are updated.

When an asset is split, replaced, or merged, a new AIX id is minted and the old id is marked retired with a successorId pointing to the replacement. The old id remains resolvable forever — its resolver page shows the retirement reason and links to the successor.

Adopting AIX in your system

Three patterns for external systems:

1. Cite IDs in published artifacts. When you publish a site assessment, audit report, weather analysis, or policy filing that references an AAM asset, include the AIX id in monospace next to the asset name. Readers can click through to the canonical record.
2. Join on AIX in your data pipeline. Store the AIX id alongside your internal identifier for the same asset. When you ingest AirIndex data (via the v1 API or a licensed feed), join on AIX rather than fragile name-matching or coordinate-proximity logic.
3. Emit AIX-keyed payloads from your own products. If your product produces facility-level outputs (compliance scores, weather forecasts, risk ratings, design feasibility analyses), keying those outputs to AIX makes them immediately joinable to every other AAM tool that does the same — and to AirIndex's own data layer.

Spec versioning

This document defines AIX v1. Future versions will be additive: new type prefixes, new xrefs keys, new resolver fields. Breaking changes (regex tightening, prefix re-purposing, removal of resolver fields) will not happen at v1.

Major version bumps (v2, etc.) would only happen if the underlying model changed in a way no additive change can express. Any such bump would be announced at least 12 months in advance via the published methodology page and direct partner notification.