Airside Labs Aviation Tools

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,

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 a

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

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 recog

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

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

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 read by a person. 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 op

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 hazar

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

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; and the five nearest use cases by text similarity. Use this for the few worked examples an argument actually needs, chosen with search_use_cases, use_case_landscape or similar_use_cases first. Calls are counted against your key's daily allowance, so walking the catalogue record by record is the wr

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 o

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 me