Facility capability tagging.

1. Executive Summary

AirIndex’s existing facility records — heliports, vertiports, and other infrastructure tracked under the AIX-ID system — capture readiness: a market-level seven-factor score reflecting whether a metropolitan area is positioned for Advanced Air Mobility operations. Readiness is the right framing for buyers asking “is this market ready?” It is not the right framing for buyers asking “what happens at this specific facility when something goes wrong?”

That second question — facility-level, emergency-relevant, capability-grounded — is the layer this specification reserves space for. Not the readiness score; a parallel attribute axis describing what each facility can do under stress conditions.

This document defines the schema for eight initial capability attributes, the audit-chain discipline that governs them, the confidence-tier framework, and the boundary between what this layer covers and what it explicitly does not. The schema is paper-first: reserved, documented, citable, and not yet populated with data. Population is gated on external signal — operator buyers, insurance underwriters, or regulatory bodies asking for facility-level capability data — at which point the architecture absorbs the demand cleanly rather than scrambling to define structure under pressure.

The pattern matches the AIX-ID system itself: paper-first, populate-when-warranted, audit-chain discipline from day one.

2. The Problem

The data that will matter when the first major eVTOL incident occurs is broader than what AirIndex currently tracks. The instinctive framing of “first eVTOL accident” defaults to aircraft failure, but the aircraft themselves are being certified to extraordinary redundancy standards. The probability of an aircraft-caused fatal accident in early commercial operations is genuinely low. The probability of non-aircraft causes — bird strikes, weather and visibility events, vertiport infrastructure failures, air traffic management failures, structural events — is meaningfully higher.

Every one of those non-aircraft causes resolves to facility-side or environment-side data. A bird-strike incident raises questions about the facility’s bird mitigation posture. A weather incident raises questions about what weather infrastructure was deployed and whether minimums protocols matched the deployed capability. A vertiport infrastructure failure raises questions about fire suppression equipment, NFPA 418 compliance status, battery thermal management. These are AirIndex’s data territory — but they are not currently in AirIndex’s database.

No public registry tracks them either. The FAA’s facility records cover dimensional and airspace criteria, not operational capability. NFPA 418 articulates standards, not facility-by-facility compliance status. Insurance underwriters who will eventually want to ask “what is the documented emergency response posture at the facilities this operator uses?” have no reference dataset to query. Federal contracting officers administering eIPP have no shared join key for capability data across participating facilities.

The right move is not for AirIndex to build the operational systems that respond to incidents — dispatchers, mobile mechanics, investigation infrastructure. Those are different categories with different buyers. The right move is to reserve the data-layer schema underneath those systems, so that when buyers ask for capability data, the structure is in place and the architecture is consistent with the existing AIX-ID audit chain.

This specification is that reservation.

3. Design Principles

Six principles govern the schema:

1. Capability is parallel to readiness, not a replacement for it. The existing seven-factor readiness scoring continues unchanged. Capability tagging is a separate attribute axis on the same facility records. A facility can have a readiness score with or without capability data; capability data can be present with or without affecting the score. The two layers serve different buyer questions and operate independently.

2. UNKNOWN is a first-class value. Every capability attribute admits an explicit UNKNOWN state. A facility that has never been assessed for fire suppression capability is UNKNOWN, not NONE. Absence of data is honest; assuming worst-case (or best-case) when data is missing corrupts the chain. The default state of every attribute is UNKNOWN until a sourced assessment lands.

3. Source citation is required per attribute value. Same discipline as the readiness scoring. A capability flag without source provenance is not entered. The provenance lives in the audit chain alongside the value itself, indexed to the AIX-ID of the facility.

4. Confidence tier is required per attribute value. HIGH / MEDIUM / LOW. The framework matches the existing scoring confidence tiers and uses the same definitions, with one extension noted in Section 5 (capability-specific calibration).

5. The audit table is succession-only, never UPDATE or DELETE. Matches the rule that governs every other AirIndex audit table. A facility’s capability assessment can change over time — equipment is added, certifications expire, mitigation programs lapse — and every change appends a new record. The historical chain is preserved.

6. Values are enumerated, not free text. Every attribute below has an explicit value domain. Free-text capability descriptions are not entered into the structured schema; they belong in source-citation metadata if relevant. Enumeration is the discipline that makes the layer queryable at scale.

4. The Attribute Domain — v1.0

Eight attributes are defined in v1.0 of the schema. Each is documented below with its value domain, the source types acceptable for assigning a value, and notes on confidence tier application.

4.1 fireSuppressionLevel

Definition. What fire suppression equipment is on-site at the facility, sufficient for rotorcraft and eVTOL fuel and battery thermal events.

Acceptable sources. Facility operator filings, fire marshal inspection records, NFPA 418 compliance certifications, vendor-disclosed installation records, on-site inspection reports cited by Authority Having Jurisdiction (AHJ).

Confidence tier notes. HIGH requires AHJ inspection record or operator certification within last 24 months. MEDIUM requires operator filing or vendor disclosure of installation. LOW covers third-party reports or news coverage without primary-source confirmation.

4.2 medicalProximityNm

Definition. Distance in nautical miles from the facility to the nearest hospital with emergency department capability or designated trauma center.

Value domain. A numeric value in nautical miles (typically 0.0–50.0) or UNKNOWN. By convention, values are reported to one decimal place. A facility that is a hospital pad records 0.0.

Acceptable sources. Geocoded hospital location data cross-referenced against facility coordinates; CMS Hospital Compare; state department of health emergency facility registries; LZControl’s hospital pad dataset (when available under licensing).

Confidence tier notes. HIGH for geocoded distance derived from authoritative coordinates of both endpoints. MEDIUM for derived distance where one endpoint is approximated. LOW for self-reported or industry-publication-cited distances without independent verification. Distances change rarely; reassessment cadence is annual.

4.3 birdMitigationPosture

Definition. Whether the facility has an active bird hazard management program, and at what intensity.

Acceptable sources. FAA Wildlife Strike Database entries identifying mitigation at the facility; Wildlife Hazard Assessment filings; operator facility manuals; airport/heliport master plans; documented bird strike incident response reports.

Confidence tier notes. HIGH requires Wildlife Hazard Assessment on file or operator-published procedures. MEDIUM covers operator filings or master plan documentation without independent verification. LOW covers third-party reports. Bird strike risk is intrinsically dynamic — assessments depreciate faster than infrastructure assessments. Reassessment cadence is two years; older assessments downgrade automatically by one tier.

4.4 groundPowerAvailability

Definition. What ground power options are available to aircraft at the facility, relevant to eVTOL charging operations and to powered ground support of conventional rotorcraft.

Acceptable sources. Operator facility manuals, vertiport infrastructure specifications, eIPP application materials, OEM-published facility certifications, electrical permit filings.

Confidence tier notes. HIGH requires operator-published specification or eIPP filing. MEDIUM covers permit filings or master plan references. LOW covers third-party industry coverage without primary source.

4.5 securePerimeterLevel

Definition. Physical security classification of the facility’s perimeter, relevant to incident response, passenger handling, and post-incident scene preservation.

Acceptable sources. Facility operator security disclosures, airport security plans (for collocated facilities), insurance carrier facility audits when disclosed, FAA airport security records.

Confidence tier notes. Security data is often non-public. HIGH requires direct operator disclosure or AHJ-published record. MEDIUM covers documented airport collocation (which carries inherited security tier). LOW covers third-party assessment without operator confirmation. Reassessment cadence is annual.

4.6 weatherInfrastructure

Definition. What weather observation and prediction infrastructure is deployed serving the facility, beyond the general regional ASOS coverage already factored into readiness scoring.

Acceptable sources. TruWeather Solutions deployment data (when available under partnership), FAA eIPP weather infrastructure filings, manufacturer deployment records, DOT/FAA published facility lists for Recommendation 2.8 pilot deployments.

Confidence tier notes. This attribute coordinates with the existing readiness weather factor. HIGH requires primary-source deployment confirmation. MEDIUM covers DOT/FAA program participation without facility-specific confirmation. LOW covers industry coverage. Note: this attribute is the natural integration point for the TruWeather data layer when partnership warrants.

4.7 batteryIsolationCapability

Definition. Whether the facility has dedicated battery thermal event containment infrastructure — physical isolation, thermal runaway suppression, post-event removal capability.

Acceptable sources. Vertiport design documents, OEM facility certification, fire marshal records for battery storage classification, NFPA emerging vertiport battery safety standards filings.

Confidence tier notes. HIGH requires operator certification or fire marshal documentation. MEDIUM covers design documents without inspection confirmation. LOW covers industry coverage. The higher tiers (SUPPRESSION_CAPABLE, FULL_CONTAINMENT) are intentionally aggressive — most facilities today will record NONE or UNKNOWN honestly. That is the correct state of the industry.

4.8 nfpa418ComplianceStatus

Definition. The facility’s compliance status against NFPA 418 (the heliport construction and operations standard, currently being adapted to address vertiport safety).

Acceptable sources. AHJ filings, fire marshal records, NFPA member compliance disclosures, operator-published assessments, third-party engineering reports.

Confidence tier notes. HIGH requires AHJ or operator-published assessment. MEDIUM covers documented engineering reports. LOW covers third-party industry coverage. Note: NFPA 418 is itself in active revision for vertiport applicability; this attribute’s confidence framework will revise alongside the standard’s evolution. AirIndex tracks the standard’s revision cycle and updates this specification accordingly.

5. Confidence Tier Framework

The three-tier framework (HIGH / MEDIUM / LOW) matches the existing readiness scoring framework. Capability-specific calibration:

HIGH — Primary source from operator, AHJ, or formal certification body, dated within the attribute’s reassessment cadence (annual for security, weather, fire suppression; biannual for bird mitigation; annual for compliance status; ongoing for proximity attributes). Source must be directly verifiable; it does not need to be publicly available, but a public-facing summary citing the source provenance is required.

MEDIUM — Secondary source (regulatory filing not specific to the attribute, master plan referencing the capability, vendor disclosure of installation without certification) or HIGH-quality source outside the reassessment cadence. MEDIUM is also the default tier when an AHJ-quality source is cited but cannot be confirmed within the reassessment window.

LOW — Tertiary source (industry publication, third-party report without primary citation, derived from contextual signals rather than direct evidence). LOW tier values are recorded with explicit acknowledgment of their derivation pathway in source citation metadata.

Public consumers (the /aix registry, the API, citations in published artifacts) display HIGH-tier capability values by default. MEDIUM-tier values are displayed with explicit tier badging. LOW-tier values are accessible via API for buyers who explicitly want signal-grade data, but are not displayed by default in published surfaces.

This matches the pattern already in place for readiness scoring: HIGH is published, MEDIUM is qualified, LOW is signal-grade and available on request.

6. Audit Chain Integration

Every capability attribute value participates in the existing AIX-ID audit chain. The mechanics:

• Each value entry is keyed to an AIX-ID (the facility) and the attribute name.
• Each entry carries source citation, confidence tier, and assigned timestamp.
• Each entry is append-only — never UPDATE, never DELETE.
• A facility’s current value for an attribute is the most recent appended record.
• Historical values remain queryable; the audit chain answers “what was the documented battery isolation capability at facility X on date Y?” the same way it answers “what was the documented readiness score at market X on date Y?”

The audit-chain discipline that makes the readiness scoring credible makes capability data credible. No exception is made for capability data; the same rules apply.

When the schema is implemented in Prisma, the table is FacilityCapabilityAssessment (or equivalent naming under existing audit-table conventions). Postgres triggers prevent UPDATE and DELETE operations consistent with the existing immutable audit-table pattern. Any direct edit destroys the chain retroactively and is structurally prohibited.

7. Scope — In and Out

In scope for v1.0:

• The eight attributes defined in Section 4
• Audit-chain integration per Section 6
• Confidence tier framework per Section 5
• Reservation of the schema as a publicly cited methodology artifact
• Public-facing display rules for HIGH-tier values when populated

Out of scope for v1.0 (deferred to future revisions):

• Real-time emergency dispatch coordination — different category, not AirIndex’s territory
• Predictive maintenance attributes — OEM telemetry territory
• Operator-specific capability claims — facility-side only; operator capabilities are tracked separately under the operator namespace
• Incident investigation outputs — NTSB/FAA process territory; AirIndex provides facility data that may inform investigations but does not run or publish investigations
• Subjective quality assessments — every attribute in v1.0 is structured and source-grounded; subjective “quality” framings are not entered into the schema

Out of scope unless future versioning warrants:

• Insurance-specific risk ratings (different framework, separate methodology paper if it advances)
• Per-aircraft-type capability ratings (the schema is facility-side; aircraft compatibility belongs in a separate axis if it advances)
• Operator history at facility (separate join layer if buyer demand warrants)

The boundary discipline matches the existing AIX-ID system: structured, source-grounded, facility-side, audit-chain-integrated. Adjacent categories belong to adjacent papers, not to this one.

8. Population Strategy

This specification is paper-first. The schema is reserved; the data is not yet populated. Population is gated on three categories of external signal:

Operator signal. When an operator buyer (Joby, Archer, Beta, Wisk, or another commercial-stage AAM operator) requests facility-level capability data as part of evaluating AirIndex as a data source, the relevant attributes are populated for the markets that operator covers. Population scope is buyer-led, not internal-projection-led.

Insurance signal. When an insurance underwriter or broker requests facility capability data as part of underwriting workflow, the relevant attributes are populated for the facility population the underwriter is pricing. Underwriter buyers often want narrow scope (specific facilities for a specific deal); the schema supports per-facility population.

Regulatory signal. When a federal contracting officer or eIPP program administrator requests shared facility data referencing capability attributes, the relevant attributes are populated across the eIPP participating facility set. Regulatory buyers want consistent coverage across a program scope; the schema supports program-level population batching.

In the absence of any of these signals, the schema remains reserved and unpopulated. AirIndex does not proactively backfill capability data as a speculative investment. The architecture is the substrate; the population is the buyer-funded work.

Two exceptions to the buyer-signal gating rule:

• medicalProximityNm is derivable from existing geocoded facility data without buyer signal. It may be backfilled across the AIX-ID heliport population as a standalone enrichment, since the source data is already in AirIndex’s possession and the attribute itself does not require buyer-specific scoping.
• weatherInfrastructure is populated as part of the TruWeather partnership integration when that partnership warrants — independent of operator/insurance/regulatory buyer signal — because it directly extends the existing weather factor in the readiness scoring.

Both exceptions are noted explicitly so the buyer-signal gating discipline is not interpreted absolutely.

9. Adoption Commitment

When capability attributes are populated, AirIndex commits to:

• Citing capability values alongside AIX-IDs in published artifacts where the value is relevant to the narrative (Pulse issues, market reports, research, Daily Wire)
• Displaying capability values at HIGH tier on the public /aix facility lookup interface
• Providing capability values through the AirIndex API under the same licensing terms as AIX-IDs (identifiers free; data history and API access licensed)
• Versioning the schema with a public revision history when new attributes are added or existing attribute domains evolve

Third parties — insurance carriers, public-private partnership advisors, federal contracting officers, operators — are encouraged to adopt the schema convention in their own workflows. The attribute names and value domains are free to reference and free to use commercially. Same permissive license as the AIX-ID system.

The discipline that makes the AIX-ID system the canonical identifier for AAM infrastructure makes this capability tagging schema the canonical attribute framework for that infrastructure. Adoption follows utility; utility follows public claim plus documented work.

10. Revision Discipline

The schema is versioned. v1.0 is the initial paper-first reservation. Future revisions:

• Adding a new attribute to the v1.x line is a minor revision; the attribute domain is documented in the revision and the cumulative schema is republished.
• Changing an existing attribute’s value domain (adding values, deprecating values) is also a minor revision; deprecated values remain valid for historical audit-chain records but are not accepted on new entries.
• Restructuring the schema (e.g., splitting an attribute into multiple, merging two into one) is a major revision (v2.0) and requires a migration mapping for historical records.

Revision triggers — when the schema warrants update:

• A new external standard (NFPA 418 revision, FAA AAM-specific facility certification framework, DOT Recommendation 2.8 implementation guidance) introduces a capability dimension not covered by v1.0
• A buyer cohort consistently requests capability data not covered by v1.0 attributes
• An incident or operational event reveals a capability dimension that was material to outcomes but not represented in the schema

Revisions are not made on calendar cycles. They are made when material signal warrants, and the rationale is documented in the revision history.

11. License Terms

Same permissive license as the AIX-ID system:

• The schema (attribute names, value domains, confidence tier framework, audit-chain integration pattern) is free to reference, free to cite, and free to adopt in third-party workflows.
• Capability data populated by AirIndex (the actual values associated with specific AIX-IDs) is licensed under AirIndex’s standard data licensing terms — identifiers are free; data is paid.
• Citations to the schema or to AirIndex-populated capability values should reference the version (e.g., “Capability Tagging Schema v1.0”) and the AIX-ID of any specific facility referenced.

The schema is offered as a contribution to the AAM data infrastructure layer. AirIndex maintains the schema; adoption is at the discretion of third parties; the permissive license invites consistent industry-wide adoption without commercial gating. See the AIX-ID License for the formal terms governing identifiers; the same posture applies to this schema.

12. What This Document Is Not

To preserve boundary discipline:

• This is not a buyer-facing pitch document; it is a methodology specification.
• It is not a product roadmap; population is gated on buyer signal and not committed to any timeline.
• It is not an operational system for emergency response; it is the data layer underneath such systems.
• It is not a certification framework; AirIndex documents capability status as observed, not as audited.
• It is not a competing standard to NFPA 418, FAA airport certification, or any other existing framework; it is a parallel attribute layer that references those frameworks where relevant.

The strategic posture is identical to the AIX-ID system: data substrate underneath the operational systems, not the operational system itself.

13. Related Methodology Documents

• The AirIndex Facility Identifier System v1.0 — the canonical AIX-ID methodology paper this specification extends
• AirIndex Scoring Methodology — the readiness scoring framework this specification operates alongside
• AIX-ID License v1.0 — the permissive license terms referenced in Section 11