The AirIndex Facility Identifier System

1. Executive Summary

The infrastructure layer of Advanced Air Mobility — heliports, vertiports, candidate remediation sites, charging networks, regulators, operators, suppliers, and the relationships between them — has no canonical, persistent, third-party identifier system. FAA heliport data is incomplete and known to diverge from independent registries; vertiports don’t yet exist as an FAA-recognized facility class; and every workflow that will eventually touch AAM infrastructure (insurance underwriting, public-private financing, eIPP applications, regulatory filings, litigation discovery) needs a stable reference key per facility.

AirIndex publishes one. The AirIndex Facility Identifier (AIX-ID) is a permissively licensed identifier — analogous in purpose to FIGI for financial instruments and DUNS for businesses — assigned to every AAM-relevant entity that AirIndex tracks. Identifiers are issued once, never reused, and persist across name changes, ownership transfers, and facility remediation. As of May 2026, 5,762 AIX-IDs are live across 12 asset types, spanning facilities (5,647 heliports), metropolitan areas (26), operators (9), corridors (9), insurance carriers and brokers (14), suppliers (13), and additional categories detailed below.

Behind every AIX-ID is an immutable, append-only audit trail of every score, factor, and source citation AirIndex has captured for that entity. AirIndex commits to citing AIX-IDs alongside human-readable names in all future Pulse issues, market reports, and research artifacts beginning Pulse Issue 10 (May 15, 2026). Third parties — including insurance carriers, public-private partnership advisors, federal contracting officers, and operators — are encouraged to adopt the convention in their own publications and workflows. The identifiers are free to look up, free to cite, and free to use commercially.

This paper documents the namespace, the persistence rules, the confidence-tier methodology, the audit chain, the adoption commitment, and the licensing terms.

2. The Problem

AAM infrastructure data is fragmented across at least four registries with material disagreement among them. The FAA’s National Airspace System Resource (NASR) lists approximately 6,000 heliports nationally. Independent industry registries — most notably LZControl, maintained by Protean LLC — report 14,844 helicopter landing zones across the same geography, including 4,009 hospital sites against the FAA’s 2,675. The 2.5× discrepancy is not noise. It reflects systematic differences in what gets registered: FAA records depend on operator-initiated filings, while independent registries include first-responder LZs, private corporate pads, and informal landing sites that operate outside FAA notification.

For AAM specifically, the gap is structurally worse. Vertiports do not yet exist as an FAA-recognized facility classification. No federal registry distinguishes a heliport that has been certified for eVTOL operations from one that has not. Published heliport-screening frameworks — including the Q1–Q5 framework from NFPA 418 (the heliport construction standard, currently being adapted to address vertiport safety) — articulate the dimensional, airspace-clearance, and operational criteria that an eVTOL-capable site must meet, but no public registry tracks compliance against them.

This data-integrity gap is the bottleneck for every downstream workflow that AAM will require at scale. Insurance underwriters cannot reliably price facility risk without a stable identifier mapping to a verified source-of-record. Public-private partnership advisors cannot reference specific sites in financing documents without an identifier persistent across the deal lifecycle. Federal contracting officers cannot administer the eIPP program without per-facility tracking. Plaintiffs’ counsel and operator general counsel will, in the inevitable event of an early eVTOL accident, ask the same question: what was the documented state of this facility on a specific date, and from what source? No public registry answers that question today.

AirIndex publishes the identifier system that answers it.

3. The AIX-ID System

An AIX-ID has the format aix:<asset_type>:<identifier>, where asset_type denotes the kind of entity and identifier is an 8-character base-32 string drawn from the alphabet [A-Z2-7]. The full identifier is treated as opaque — it conveys no semantic information about the entity beyond its type and serves only as a stable join key.

A worked example: aix:hp:4QKZWCG8 resolves to Phoenix Children’s Hospital Heliport (FAA LID AZ99, nearest ASOS PHX). The AIX-ID will not change if the facility is renamed, transferred, or remediated to a vertiport classification. If the facility is decommissioned, its AIX-ID is retired (not deleted), and a successor identifier is minted for any successor facility — preserving the historical reference.

As of May 2026, twelve asset types have minted AIX-IDs:

Every AIX-ID in the registry carries a cross-reference (xrefs) record mapping the AirIndex identifier to the entity’s identifier in any external registry where one exists. For heliports, this includes FAA site number, ICAO designation, and (where applicable) LZControl identifier. For operators, it includes SEC Central Index Key (CIK), ticker symbol, and EDGAR identifier. For markets, it includes USPS state/city codes, FIPS codes, and MSA codes.

The AIX-ID is the join key. The cross-references are the bridges between AirIndex’s namespace and every other registry an external party already references.

4. Persistence Rules

The AIX-ID is never reused. Once an identifier is minted for an entity, it remains bound to that entity for the lifetime of the registry. This is the single most important operational rule of the system, and it is enforced both by schema constraint and by published commitment.

When an entity is decommissioned, sold, merged, or otherwise transformed in a way that breaks identity, the original AIX-ID is retired (its retiredAt timestamp is set, with a retirementReason recorded), and a successor AIX-ID is minted via the predecessorId / successorId chain. This pattern follows the precedent established by the Financial Instrument Global Identifier (FIGI) convention in capital markets, where instrument identifiers persist through corporate actions via the same successor-chain mechanism.

Three classes of change are explicitly distinguished. The distinction matters because each class produces a different audit-chain pattern, which downstream consumers — insurers, regulators, plaintiffs’ counsel — must be able to reconstruct from the audit chain:

• Mutation (e.g., a heliport name change, an operator rebranding) — same AIX-ID, the displayName field is updated.
• Succession (e.g., a heliport remediated to vertiport classification, a corporate parent change that creates a new legal entity) — old AIX-ID retired, new AIX-ID minted, succession link recorded in both directions.
• Decommission (e.g., a permanently closed heliport) — AIX-ID retired with no successor.

Historical references that cite a retired AIX-ID continue to resolve. The retirement state is part of the identifier’s history, not a deletion. No AIX-ID is ever removed from the registry.

5. Confidence Tiers and Source Discipline

Every fact AirIndex publishes about an AIX-ID-tagged entity carries an explicit confidence tier and a source citation. Three tiers are used:

• high — the fact is supported by a primary source (a regulatory filing, a verified operator press release, an SEC document, an explicit municipal record). High-confidence facts are publishable without further review.
• medium — the fact is supported by a secondary source (industry trade press, third-party reporting that cites a primary source). Medium-confidence facts are not surfaced in public scoring without manual promotion.
• needs_review — the fact has been classified by automated systems but has not been validated. Needs-review facts never reach public scores; they remain in an internal queue.

Public reads of the AirIndex API and dashboard filter on confidence:"high" only. Lower-confidence records are visible to administrators for review but not to readers.

The confidence methodology is built on published external frameworks, including NFPA 418 (the heliport construction standard, with vertiport criteria currently in development by NFPA’s technical committee) and the FIGI identifier convention from financial markets. AirIndex’s contribution is not the underlying screening framework but the per-source confidence assignment, the audit trail of every classification, and the publication gate that ensures only high-confidence facts move public scores.

A worked example: when a state legislative event affects a market’s regulatory posture, AirIndex’s daily classifier ingests the legislative record from the LegiScan API (primary source), assigns it a high confidence tier if the bill text and status are unambiguous, and creates a pending ScoringOverride row. The override does not affect public scores until an administrator reviews it and explicitly publishes it. Same-value re-confirmations (a second news article covering the same event) are skipped at publish time. The full chain — source, classifier output, model version, prompt version, review decision, publish timestamp — is preserved in the audit chain (Section 6).

6. Audit Chain and Reproducibility

Every score AirIndex has ever published is reproducible from source on a specific date. This is not a marketing claim; it is a property of the data architecture.

Five tables form the audit-trail spine:

• ScoreSnapshot — every score capture, append-only. Each row records the city, the score, the factor breakdown, the tier classification, the triggering event, the source-record ingestion timestamp, and the capture timestamp.
• ScoringOverride — every factor change. Each row records the city, the field, the value, the reason, the source URL, the source type, the confidence tier, the origin (classifier / analyst / admin), the applied timestamp, the published timestamp, and the superseded timestamp.
• ChangelogEntry — every state change linked to its triggering record.
• ClassificationResult — every classifier run, preserving the full model response, the model version, the prompt version, and the classification metadata.
• AixIdentifier — the registry itself, recording the canonical AIX-ID, asset type, source-of-record table, cross-reference identifiers, and the predecessor / successor / retirement chain for every entity AirIndex tracks.

These tables are append-only or succession-only. Direct UPDATE or DELETE on these tables is prohibited by operational policy and will be enforced at the database level in a planned future hardening (Postgres BEFORE UPDATE and BEFORE DELETE triggers on the five tables above). Corrections happen by appending a new row that supersedes the old one — never by editing the historical record. The original record is preserved with its supersededAt timestamp set, citing the corrective row’s identifier.

The credibility of this architecture was tested publicly in May 2026. A reader signed up for AirIndex Research, examined the published changelog for a specific Florida bill (HB1237), identified within twenty minutes that the classifier had produced a false-positive interpretation of the bill’s effect on regulatory posture, and reported it. AirIndex’s internal review confirmed the false positive, the override was rejected, and the corrective record was appended with explicit reference to the rejected entry. The original false-positive record was preserved in the audit trail. No row was edited. The correction is itself part of the historical record.

This pattern — preserve the original, append the correction, link them in the chain — is the operational discipline that makes AirIndex’s historical record credible. In litigation discovery, in insurance underwriting documentation, in regulatory filings, the question "what did AirIndex know about this facility on this date, and from what source?" has a single answer that cannot be retroactively edited.

7. Adoption and Citation Convention

Beginning Pulse Issue 10 (May 15, 2026), every public AirIndex artifact will cite AIX-IDs alongside human-readable names. The format on first mention is the inline parenthetical:

Subsequent mentions in the same artifact use the human-readable name only. In tabular displays, research articles, and machine-readable exports, the AIX-ID is included as a column or field alongside the human-readable name.

Third parties are encouraged to adopt the convention. Insurance carriers, public-private partnership advisors, federal contracting officers, operators, regulators, and journalists may cite AIX-IDs in their own publications, contracts, filings, and analyses. The identifiers are free to look up, free to cite, and free to use in any workflow — commercial or non-commercial.

Adoption questions to anticipate:

• What if an AIX-ID changes? It does not. If the underlying entity changes, the original AIX-ID is retired and a successor is minted; both remain in the registry. References to a retired AIX-ID continue to resolve.
• What if AirIndex is acquired or ceases operations? The registry is published and citable. Retiring a registry would itself be a registry event documented in the audit chain. A succession plan for the registry — including a commitment that the namespace will not be relicensed under restrictive terms — will be published in a future governance update.
• Can I assign my own AIX-IDs? No. AIX-IDs are minted only by AirIndex to ensure uniqueness and the never-reuse guarantee. You may, however, cite AIX-IDs that AirIndex has minted, and you may request that AirIndex mint identifiers for facilities or entities not yet in the registry by contacting the AirIndex team.

The binding commitment is in print as of the publication date of this paper. The first scheduled execution is Pulse Issue 10.

8. Governance and Licensing

The AirIndex Facility Identifier System is published under a permissive license modeled on the FIGI convention from capital markets. The license has three components:

Free: identifier lookup, identifier resolution from external IDs (FAA site number, ICAO, CIK, etc.), citation of AIX-IDs in any document, public-facing presentation of AIX-IDs as labels, all components of this methodology paper, and the schema documentation.

Paid: historical score data per AIX-ID, factor-state time-series, classifier rationale and source-record linkage, programmatic API access at all rate-limit tiers above public (Pro, Institutional, Enterprise), the AirIndex Ecosystem Intelligence Database (EID) counterparty graph beyond the multi-operator surface, full audit-trail access for litigation, insurance, and regulatory use cases.

Not Permitted: relicensing the AIX-ID namespace under restrictive terms; re-issuing identifiers in a way that conflicts with AirIndex’s mint logic. (The license also does not authorize attribution of third-party claims to AirIndex when those claims were not generated by the AirIndex pipeline; misattribution is governed by general law rather than by this license, but is noted here for clarity.)

Registry maintenance. AirIndex maintains the registry. New AIX-IDs are minted only by the AirIndex team or by automated processes operating under the AirIndex audit gate. The mint procedure follows the same discipline as the score-publication audit gate (Section 6): every minted ID is sourced, every retirement is documented, and the registry’s append-only invariants are enforced at the schema level.

Versioning. This document is Version 1.0, dated May 2026. Future revisions will be versioned (1.1, 1.2, etc.) and historical versions will remain available at versioned URLs. Substantive changes — to the namespace, the persistence rules, the confidence methodology, or the licensing terms — will be announced through the same channels as Pulse and will be subject to a public-comment window before becoming effective.

Contact. The AirIndex methodology team can be reached at hello@airindex.io. Questions about AIX-ID assignments, requests for new identifier mints, and feedback on this methodology paper are welcome.