Airside Labs Aviation Tools

Reviewed 1d ago.

• tools: 29 tools scanned
• metadata: scanned

No findings.

Tools (29)

• resolve_airport

  Which aerodrome does this airport code or name refer to on a given date? Accepts an IATA three-letter code, an ICAO four-letter code, an airport name fragment or a city name. Returns the aerodrome with its codes, location, elevation, IANA timezone and type (large, medium, small, heliport or closed). Pass `as_of` whenever the question concerns a past date. Airport codes move between aerodromes: ATH meant Ellinikon until 2001 and Athens International after it; HKG meant Kai Tak until 1998. Without a date these questions get today's answer, which is silently wrong for historical data. `timezone` is always an IANA identifier such as Europe/London, never a UTC offset, because an offset cannot express daylight saving. Do NOT use this for live operational status, runway or stand data, slots, or whether an airport is currently accepting traffic. It answers identity questions only. A name fragment matching several aerodromes returns `ambiguous` with candidates rather than picking one; use `

• resolve_airline

  Which airline does this designator, name or callsign refer to on a date? Accepts an IATA two-character designator, an ICAO three-letter designator, an airline name or a callsign. Returns the operator with both designators, country, operational status and, where an airline ceased, its successor. `as_of` matters more here than for any other tool. IATA two-character designators are heavily reused: SN was Sabena until 2001 and has been Brussels Airlines since 2007, so "SN" without a date is a question with two answers. Where a date falls between two holders the tool returns `unresolved` with both as alternates rather than guessing. ICAO three-letter designators are not recycled the same way and are the safer identifier to carry through a pipeline. `status` is reported as at the date asked about, not as at today: asked about 2005, Northwest Airlines is `active`, with a note that it merged into Delta in 2010. A status of `unknown` means no reliable source states it -- the bulk open data f

• resolve_aircraft_type

  Which aircraft type does this designator or marketing name refer to? Accepts an ICAO type designator (A21N) or a marketing name people actually say ("A321neo", "Dash 8-400", "777-300ER", "Q400"). Returns the ICAO designator, manufacturer, model, engine count and type, aircraft class, and the ICAO wake turbulence category. A name that identifies a family rather than a variant -- "Dreamliner", "777X", "A330neo" -- returns `ambiguous` with the variants as alternates and a confidence in the 0.4-0.69 band. That is the correct answer to an imprecise question; do not collapse it to the first alternate. `wtc` (wake turbulence category) is stated for almost every type, from FAA Order JO 7360.1K, and is cited like any other field. Where it is null the document leaves it blank -- do NOT fill it in from your own knowledge if the caller needs it for separation or charging, say it is unavailable. IATA aircraft type codes are NOT held -- the three-character form used in schedules and booking syst

• resolve_registration

  Which airframe wore this registration on a given date? Accepts a tail number in any common form: VH-OQA, VHOQA, lowercase, padded with whitespace. Returns the aircraft with its country of registry, ICAO type designator, an embedded resolved aircraft type, operator, owner, serial number and Mode-S hex address. A registration is a slot rather than a permanent name: marks are surrendered and reissued. N803AL was one airframe from 1987 to 1993 and a different one, a 787-8, from 2015; N264CP moved to a different Mode-S address in 2015. Pass `as_of` for any historical question. Where the date falls between two holders the tool returns `unresolved`, reports the country from the nationality mark, and offers both airframes as alternates. When the tail is unknown but the nationality mark is recognised, the response carries a `partial` object with the country of registry at confidence around 0.5. That is a partial answer, not a resolution: the aircraft is still unidentified. Coverage is not g

• parse_flight_identifier

  Split a flight designator into carrier and number, and identify the carrier. Accepts the forms that arrive in real message traffic: TK1979, BAW276, "U2 8341", BA02490, BA2490A. Returns the parsed carrier with its resolved airline, the flight number, any operational suffix, which scheme was used (IATA or ICAO), and both normalised forms. Two things this tool will not do. It will not tell you who operated the flight: a designator names the marketing carrier, and a codeshare is invisible in the string. And it will not invent a carrier for a bare flight number -- pass `context` and it will look for an identifier in that text, but the result is capped at 0.6 confidence and returned as a candidate, because inference is not identification. Pass `date` when parsing historical data: the carrier depends on it, since SN2103 was a Sabena flight in 1995 and a Brussels Airlines flight in 2020. A string that parses correctly but names no known airline returns `unresolved` with a note saying exact

• flight_airframes

  Which airframes have been heard operating this airline flight, how often and when -- from Airside Labs' own ADS-B receiver? Accepts a flight in any common form: BA49, BAW49, "BA 49", VS105. Returns each airframe heard broadcasting that Flight ID within the receiver's footprint, with its Mode-S address, registration and ICAO type (joined from the registrations dataset), how many receiver poll cycles it was in view for, over how many distinct days, and first and last heard. `most_seen` and `most_recent` name the likeliest next tail; `types_seen` lists every type that has flown it, and where there is exactly one the resolved type is embedded with its capacity block. Why this matters: the cabin, the seat map and the sub-fleet vary by REGISTRATION, not by type. Two A330-900s at one airline can be different aircraft inside. A seat-finding or fleet-watching agent needs the tail; this answer comes from what the receiver observed, not from a schedule. Coverage is the station's footprint: abo

• airframe_flights

  Which flights has this airframe been heard or filed operating, how often and when -- the inverse of flight_airframes, from Airside Labs' own ADS-B receiver and the FAA flight-plan feed? Accepts a registration in any common form (G-XWBA, N101DU, PH-BHA) or a Mode-S address (406a3d). A registration is resolved first, so `as_of` matters for a re-issued mark: the answer names the airframe it resolved to and the Mode-S address(es) it looked up. Returns each Flight ID the airframe was heard broadcasting within the receiver's footprint, or was filed under in FAA flight plans, with sightings (receiver poll cycles in view), distinct days seen, first and last seen, and which instrument observed it. `most_seen` and `most_recent` name the services it is usually on; `flight_count` how many distinct Flight IDs it carried in the window. Why this matters: movement history for a tail. A fleet-watching, lessor or MRO agent that has resolved a registration wants to know what it has been doing; this ans

• validate_identifiers

  Do these aviation identifiers describe the same thing on this date? Give any combination of a registration (tail number), a Mode-S 24-bit address, an ICAO type designator, an operator name, an airline designator (IATA or ICAO), a callsign and a flight designator, plus `as_of`. Each pair that can be checked is checked, and every check comes back with a verdict -- `consistent`, `contradicted` or `unverifiable` -- the detail, and the rule that decided it. `contradictions` lists the failures on their own so an agent can act on them without reading everything. The top-level verdict is `consistent` ONLY when every check verified. When some checks passed but others could not be checked it is `consistent_where_checkable` -- a different answer, because an absent record silences exactly the checks that would catch a false claim about that airframe. `unverifiable_count` says how many checks were silent; treat anything above zero as partial coverage, not a pass. Use it before acting on identifi

• report_unmet_need

  Tell us what you came looking for and could not get from these tools. Call this when you needed something aviation-related that this toolset did not give you. It is not an error channel and it is not a retry: it is how the next version of these tools learns what is missing. A need reported here is appended to this service's own feedback store, on the same server that answered you, and reviewed later by Airside Labs; nothing is sent to any other system. Use it when: - a tool returned `unresolved` and you believe the thing exists - a tool returned `ambiguous` and nothing available could break the tie - the entity resolved but a field you needed was null or absent - no tool here covers the question at all - a tool answered confidently and the answer looked wrong `gap_kind` must be one of: `unresolved`, `ambiguous`, `missing_field`, `no_tool`, `wrong_answer`, `no_use_case` (the use-case catalogue had nothing on the operational need you searched for). `sought` is the important

• use_case_landscape

  How many use cases are there, sliced one way? Counts you can quote. `group_by` is one of org_type (16 canonical organisation types: Airport, Airline, Air Navigation Service Provider, Ground Handling, Regulator / Authority, Aerospace Manufacturing, MRO / Maintenance …), sector, role (500+ roles), ai_level, hazard_class, or cadence_class (counts data requirements rather than use cases). Filters AND together and apply before grouping, so group_by=role with org_type=Airport lists airport roles by how many use cases each carries. Also returns the total in scope and how many of those carry an EASA screen. This is the tool to call first: it tells you what the catalogue covers before you search it, and the exact spellings that the filters accept. Grouping the whole catalogue by ai_level or hazard_class shows a large null bucket -- only the ~1,900 airport-operations use cases were screened; pass screened_only=True to see the screened distribution alone. Counts describe the catalogue, not the

• search_use_cases

  Which aviation AI use cases match this text? Find candidates by keyword. Full-text search (BM25, stemmed) over 6,500 use cases spanning airports, airlines, ANSPs, ground handlers, regulators, manufacturers and more, each attached to a role and an organisation type. Returns summaries only -- id, short text, role, organisation type, EASA screen -- capped at 25. Use get_use_case for the full record with its data requirements. Search concrete operational nouns ("stand allocation", "baggage misconnect", "de-icing", "turnaround"), not capability labels ("shared operational picture", "digital transformation"): the corpus vocabulary is operational, and abstract phrases match little. Terms are OR-ed and ranked, so a multi-word query returns the best partial matches; `score` is relative within one query and means nothing across queries. Filters AND together. `org_type` is one of the 16 canonical types (see use_case_landscape group_by=org_type). `screened_only=True` keeps the ~1,900 use cases

• get_use_case

  The full record for one use case, by id from a search or landscape result. Returns the use-case text; the role that owns it with its description; the organisation type (canonical and as the corpus names it); every data requirement -- title, description, nominal update rate with a normalised cadence class (real_time … annual), and the kind of system it typically comes from; the EASA screen (AI level, hazard class, confidence, rationale) with the framework rows it points at, page-cited; keywords; up to three `data_stories`; and the five nearest use cases by text similarity. A data story is what this use case's data does when you actually touch it: a measured finding from Airside Labs' own receiver, the FAA flight-plan feed, BTS traffic data or the served entity registry -- a fill rate, a reused identifier, an ambiguous timestamp, the reach of one sensor. Each carries `claim` (the finding, with its scope in the sentence), `implication` (what to do about it), `identifiers` (exact ids to

• similar_use_cases

  What else in the catalogue is like this use case? Nearest neighbours by meaning. Returns up to 20 use cases closest in embedding space (bge-base cosine over the use-case text), as summaries with a `similarity`. Good for "what else is like the one we picked", for finding the same idea stated for a different role or organisation type, and for spotting near-duplicates before counting them as two. Similarities are compressed into roughly 0.5-0.95: rank within one result, never threshold across the catalogue, and do not read 0.9 as "the same". The neighbours were computed at build time as the top 20 for each use case; an `org_type` or `screened_only` filter narrows within those 20 and does not search further out, so a tight filter can return few or none -- that is honest, not broken. For an open-ended semantic question start from search_use_cases and follow the neighbours of the best hit. Do NOT use this to rank importance, maturity or value: proximity in text says two use cases are desc

• data_requirements

  What data does this use case, role or organisation type need, and how fresh? Three modes. With `use_case_id`: that use case's requirements verbatim -- title, normalised title_family, description, nominal update rate, normalised cadence class and the kind of source system. With `query`: REVERSE lineage -- full-text search over requirement titles and descriptions (the inputs, not the use-case text), returning the use cases that CONSUME data matching the query. Ask `query="taxi-out time"` to get everything downstream of a better taxi-out estimate: each consumer with the requirement titles that matched, the total count, and the requirement families involved. This is the "if we improved this prediction/feed, what would benefit" question; combine with trace_data_lineage to see which standard messages carry the input. With neither: an aggregate profile for a scope (`role`, `org_type`, `sector`, any combination): the most common requirement titles with the typical cadence and source for each,

• trace_data_lineage

  Which standard operational messages would evidence this data need? The lineage spine is use case -> data requirement -> requirement family -> standard message type -> data elements. Four modes. With `use_case_id`: that use case's requirements grouped by family, each family with the standard messages that evidence it (relevance primary/supporting, cadence, element count) -- plus `requirements_without_standard_messages`, the needs no standard message covers, which is the honest feed-gap statement. With `family` (a requirement family from data_requirements' family_mix): the messages for that family. With `message_id` (e.g. MVT, LDM, BSM, DPI, METAR): the message definition, its data elements as shapes (time, count, weight, identifier, status), the families it serves, and `data_stories` -- what Airside Labs measured about that message type in real feeds (fill rates, identifier traps), each with its window and source. With no arguments: the catalogue of ~23 message types across IATA Type B

• trace_workflow

  What happens before and after this use case, and who hands off to whom? The catalogue is otherwise flat -- role, use case, data requirement -- with no edges. This is the edges: named operational sequences with their steps in order, the role at each step, the `gate` that must hold before the next one may start, and what passes between roles at each handoff (headset, radio, hand signal, system, visual, document, verbal, formal correspondence). Three modes. With `use_case_id`: every workflow that places that use case, its position, and the steps immediately `preceded_by` and `followed_by` it with what transfers. That is the real operational dependency -- distinct from `similar_use_cases`, which is text similarity, and from `data_requirements(query=...)`, which infers a relationship from two use cases sharing a feed. A gate is a dependency; a shared feed is a correlation. With `workflow_id`: the whole sequence end to end. With `phase` (arrival, turnaround, departure, abnormal, oversight,

• easa_ai_framework

  The EASA AI-level and hazard-class tables, page-cited, to read a screen against. Returns the AI levels (0, 1A, 1B, 2A, 2B, 3A, 3B: what the system does and how much authority the end user keeps), the hazard classes (H1-H5: worst credible effect and the assurance level it implies at acceptable and moderate risk), the technique ceilings (which AI techniques the Concept Paper accepts up to which level), and source notes. Pass `level` or `hazard_class` for one row. Every row carries `cp_ref`, the page in the proposed Issue 03; quote that, not this tool, as the citation. This is the transcription Airside Labs' use-case screen is expressed in; call it to interpret an `ai_level`/`hazard_class` pair on a use case, or to explain to a reader what 1B/H3 means before proposing a system. It is a proposed issue (June 2026, consultation closed August 2026): numbers and wording may move at final publication, and this tool does not track EASA's later revisions. Do NOT use it to decide that a system

• scenarios

  Which real operational episodes does the catalogue carry, to illustrate use cases with? A scenario is one real day reconstructed from data Airside Labs holds and may publish: FAA SWIM flight plans, FAA NOTAMs, its own ADS-B receiver. Each is a UTC window at a place, a timeline whose every event names the raw record it came from, and a set of lenses -- one use case's cut of the day, with the actual rows, an implication, and the use cases it is attached to. This lists them with their window, place, event and lens counts and how many use cases they touch. Fetch one with get_scenario; the lenses also arrive inside get_use_case as `data_stories` of kind `lens`. Use it when a brief needs a worked example with real rows behind it: a PRD's assumptions section, a workshop narrative, an edge-case note for a data team. Do NOT read a scenario as a rate or as how an operator usually behaves: it is one day, one or two airports, dated. The list is short by design; an empty result means the dataset

• get_scenario

  One real episode end to end: what happened, where and when (UTC), the actors, what it shows and what it must not be read as; the timeline, every event with its actor, source and the reference of the raw record it came from; and the lenses, each a use case's cut of the day with a small evidence table, an implication, and the use cases it illustrates with a reason for each. Use it when a brief needs the whole story rather than one finding: a worked example with a paper trail, an edge-case write-up for a data science team, a workshop narrative. For one use case's view, take the lens from get_use_case instead; it is smaller and carries the same caveats. `events=False` or `lenses=False` trims the reply. Every figure in a lens was measured by a probe over the named source and window and checked against its evidence before publication; quote it with the scenario id, the source and the window, and copy `not_to_be_read_as`. Do NOT extend a scenario past its window, treat its counts as rates,

• airport_network_integration

  What level of network integration does this airport have with the EUROCONTROL Network Manager, or with the FAA's TFDM programme, as of a date? Answers with one value: `ani` (Advanced Network Integrated: A-CDM with the higher level of integration), `acdm` (all DPI message types sent to the network, so a TOBT and TSAT stream exists), `adv_twr` (Advanced ATC TWR: E-DPI, C-DPI and A-DPI only, no TOBT or TSAT stream), `tfdm_a` or `tfdm_b` (FAA Terminal Flight Data Manager configurations), `standard` (removed from the Network Manager list by a notice), or `not_listed`. Each value carries its definition, the notice that establishes it, the date it has held since, and the history of changes across the notice chain. The source is the Network Manager's own Information Notice "Updated list of A-CDM, Advanced ATC TWR and ANI airports", parsed from each PDF in the chain from IN/25-001 (10 January 2025) to the current one. Pass `as_of` for a historical question: Berlin Brandenburg and Barcelona we

• airport_operator

  Who operates this airport, which group would take the commercial meeting, and who owns it? Returns operator_name, operator_group (the parent that a sales or partnership conversation lands with, spelled consistently: Aena, MAG, Groupe ADP, Fraport, VINCI Airports, Adani and so on), ownership_class (public-national, public-regional, private-group, private-individual, concession-mixed or unknown), owner_name, concession_end_year where a public page states it, and the listed parent and ticker where there is one. Sources: Wikidata for every airport in the set (operator P137, owned by P127, parent P749), and the operator's own website, annual report or a national register where a row is `verified`. A `programmatic` row is only as current as its Wikidata item and can lag a concession by years; read the note before relying on it, and prefer a verified row. Do NOT use this to establish who owns the airport's systems or data, what vendors it uses, or whether the group buys centrally: it is an

• airport_operations_status

  Is there a positive, sourced reason this airport is not open for ordinary commercial engagement: closed to civil traffic, in a sanctioned jurisdiction, or a general-aviation field with no scheduled service? Returns `closed` (no civil passenger operations), `restricted` (the airport operates but sits under UK sanctions guidance for its jurisdiction, with the guidance page cited), `general-aviation` (no scheduled passenger service), or `no_exception_recorded`. The last is exactly that: this dataset records exceptions with their sources; it does not confirm that scheduled service exists, and a `no_exception_recorded` answer should not be quoted as "open". Read `method` before quoting a `closed`. `sanctions-register` and the other airport-level methods are hand-read against a named source and carry the date the airport closed: Kyiv Boryspil since 24 February 2022, Istanbul Atatürk since April 2019. `curated-airports-type` means the airport's own record types it as closed and usually carr

• airport_connectivity

  How many nonstop destinations does this airport publish, and in which countries? Returns the count of nonstop destinations from the airport's published destination table, the number resolved to a country, the destinations by country, and the counts to the United States, the Gulf and the UAE, with the date of the read. This is presence, not frequency: one weekly seasonal service and a daily trunk route count the same. It is right for "does this airport connect to the US at all" and wrong for "how much traffic does it exchange with the US"; frequency needs a schedule source, which this dataset is not. Seasonal and suspended routes are counted when the table lists them. `not_covered` means the airport is outside the public set or no destination table was parsed. `identifier` is an IATA or ICAO code, or an airport name; a name is resolved to its code first and the answer says so in its first note. Reading the answer: `status` is resolved, unresolved or not_covered. `confidence` is verif

• airport_size_band

  Which ACI passenger size band is this airport in, on its latest published annual total? Returns the passengers figure, its year, and the band on ACI World's published ASQ size categories: under 2M, 2 to 5M, 5 to 15M, 15 to 25M, 25 to 40M, over 40M passengers per year. The figure comes from the airport's Wikipedia infobox (its latest published annual total), not from ACI, so airports are not on a common year; the year travels with the answer, and a figure dated the current year is flagged as probably part-year. Use it to say "a 25 to 40M airport" in the way the industry does. Do NOT use it as a traffic statistic for comparison across airports or years, for growth, or for anything that needs a consistent reporting basis; that needs a statistics source. `not_covered` means the airport is outside the public set or its article carries no passenger figure. `identifier` is an IATA or ICAO code, or an airport name; a name is resolved to its code first and the answer says so in its first not

• airport_runways

  What runways does this aerodrome publish in its state AIP, with what dimensions, surface, bearings, thresholds and declared distances, and for which AIRAC cycle? Returns every runway the state's export lists for the aerodrome: designator, length and width, surface and PCN, the runway strip, and per direction the threshold coordinates, true and magnetic bearing, the approach slope indicator (PAPI or VASIS type, slope and MEHT) and the four declared distances TORA, TODA, ASDA and LDA. Every length is `{"m": ...}`; where the publisher states feet it is `{"m": ..., "published": {"value": ..., "uom": "FT"}}` and the published figure is the one to quote. `as_of` is the cycle the figures are true for and `provenance` names the export. Read `declared_distances` and `from_intersections` as two different things. The top-level figures are the FULL-LENGTH declared distances. `from_intersections` lists the reduced distances available to a departure that starts at a taxiway intersection: Paris CDG

• route_capacity

  How much scheduled capacity is flown nonstop from one airport to another, by whom and on what, over the last N months of BTS T-100 data? Returns monthly departures performed, seats and passengers with the load factor, and the same broken down by carrier and aircraft type with seats per departure and the sector distance (BTS statute miles, and nautical miles converted). The pair is DIRECTIONAL: SEA to LHR is not LHR to SEA; ask both if you need the round trip. `months` defaults to the last 12 of the window; pass null for the whole window. `scheduled_only` (default true) restricts to scheduled passenger service, BTS class F -- charter and all-cargo rows exist in the source and would distort seats and load factors. This is the frequency, capacity and load-factor side of a route model. Combine with resolve_aircraft_type's capacity block for the type's certified and typical seating, and supply yield yourself: fares are not held here. Airports may be given as an IATA code, an ICAO code o

• airport_fleet_mix

  What aircraft types fly from (or into) an airport, how often, with how many seats, and at what load factor, over the last N months of BTS T-100 data? Returns each type's departures performed and share of the airport's departures, seats, passengers, load factor, seats per departure, and how many carriers and destinations it serves, plus airport totals. `direction` is `departures` (default) or `arrivals`. `months` defaults to the last 12 of the window; pass null for the whole window. Scheduled passenger service only. This is the fleet-mix question a planner asks before sizing a route or a gate: what the airport is actually flown with, from the census of segments carriers file, not from a schedule or a fleet list. Airports may be given as an IATA code, an ICAO code or a name. T-100 is filed under three-character codes that follow IATA, so an ICAO code or a name is resolved to the airport's IATA code first and the answer says so in its first note; `query` echoes the code that was looke

• submit_suggestion

  Record a suggestion about this toolset or its use-case catalogue. No API key is needed for this tool. The suggestion is written as one record into this server's own local feedback store and nothing else happens: no message, notification, email or request goes to any website, person or other system, now or later, and the tool does not read the store back. Airside Labs reads the store when preparing the next version of the catalogue and the tools. Use it for: a correction to a catalogue use case, an aviation AI use case the catalogue is missing, a data source or requirement it should know about, a tool or field that would have helped you, or commercial feedback (what would make the full toolset worth a subscription). `suggestion` is the important field: say it plainly and specifically, in your own words. `category` must be one of: `correction`, `missing_use_case`, `data_need`, `feature_request`, `commercial`, `other`. If the suggestion concerns one use case, pass its `use_case_id` (th

• feedback_status

  What happened to a suggestion or unmet-need report filed here? No API key is needed. Pass the `fingerprint` from a submit_suggestion or report_unmet_need receipt (12 hex characters). Returns `status`: `shipped` (a person acted on it and the change is live, with what shipped and when), `declined` (read and not taken up, with the reason), `acknowledged` (read, still open) or `open` (recorded, not yet reviewed), or `unknown_fingerprint` if nothing was ever filed under it. `times_reported` says how many times that exact text has been filed, and `first_reported` / `last_reported` when. Resolutions are written by a person when something ships, so `open` means exactly that: it has not been read yet, or has been read and not written up. Filing again does not move it. Do NOT infer from `shipped` that the whole class of problem is fixed: the note says what was changed and the dataset build it landed in.