Airside Labs Aviation Tools

View saved version →

---
name: aviation-identity
description: Resolve and cross-check aviation identifiers (airports, airlines, aircraft types, registrations, flight designators) with the Airside Labs Aviation Tools, on the right date, and report confidence and sources honestly.
---

# Aviation identity: resolve, date, cross-check

Use this workflow whenever a question names an airport, airline, aircraft type, registration or
flight number and the answer depends on which entity that identifier means.

## Steps

1. **Fix the date first.** If the question is about the past, pass `as_of` (YYYY-MM-DD) on every
   call. Airport codes move (ATH, HKG) and airline two-letter designators are reused (SN was
   Sabena, then Brussels Airlines). Without a date the tools answer for today, which is silently
   wrong for historical data.
2. **Resolve each identifier** with the matching tool: `resolve_airport`, `resolve_airline`,
   `resolve_aircraft_type`, `resolve_registration`, `parse_flight_identifier`. Prefer ICAO
   identifiers (four-letter airports, three-letter airlines) when carrying a result forward; they
   are not recycled the way IATA codes are.
3. **Read `status` and `confidence` before the value.** `resolved` at 1.0 is a unique match.
   0.7 to 0.99 came through an alias or a historical record; say so. 0.4 to 0.69 means
   `alternates` is populated: ask the user which one rather than choosing. `ambiguous` with a
   `country_hint` available: call again with the hint. `unresolved` is a real answer, not an
   error; do not invent one.
4. **Cross-check** when identifiers come from more than one source (a registration from a
   movement message and an address from a surveillance track, a flight number and an airline):
   call `validate_identifiers` with all of them and the date. `contradicted` means at least one
   check failed; never average it away. `consistent_where_checkable` with
   `unverifiable_count` above zero is partial coverage, not a pass: say which checks were silent.
5. **Cite.** Every field in `best` has an entry in `provenance` with a source id and retrieval
   date. Quote the source when the answer will be relied on.

## Output requirements

- State the date the answer applies to.
- Give the resolved entity with both code systems where the tool returns them.
- Name the confidence band in words (exact match, via alias, one of several candidates).
- If anything was unresolved, ambiguous or unverifiable, say so in the first sentence, not the last.

## Do not

- Use these tools for live status, schedules, slots, fleet lists or routes; they answer identity
  questions only.
- Present an unresolved result as a hint that the thing does not exist; coverage is not global.
- Drop the date from a follow-up question because the first call had one.

## Example

User: "Which airline was SN in 1995, and is BA117 a British Airways flight?"

1. `resolve_airline` with identifier `SN`, `as_of` `1995-06-01`: read `status`; if `ambiguous`,
   report the best candidate and the alternate with the tool's reason.
2. `validate_identifiers` with airline `BA`, flight `BA117`, `as_of` today: report the verdict
   and the checks.
3. Answer with the date, the entities, the confidence in words, and the sources.

View saved version →

---
name: aviation-use-cases
description: Find and evidence AI use cases for an aviation organisation or role with the Airside Labs Aviation Tools, including the data each needs and the EASA AI-level screen, without overstating what the catalogue shows.
---

# Aviation AI use cases: landscape, search, fetch, screen

Use this workflow when someone asks what AI could do for an airline, airport, ANSP, MRO,
regulator or a role inside one, what data it would need, or how a use case sits against
EASA's AI framework.

## Steps

1. **Start with the landscape.** Call `use_case_landscape` first, grouped by `org_type`, then
   narrow with `org_type` and `group_by=role` or `sector`. This tells you what the catalogue
   covers and the exact spellings the filters accept. Counts describe the catalogue, not the
   industry; never present a count as market evidence.
2. **Search with operational nouns.** `search_use_cases` works best on the things people do and
   the systems they touch (turnaround, stand allocation, NOTAM triage, engine health), not on
   abstractions. Take the top handful, not the whole list.
3. **Fetch the few records the argument needs** with `get_use_case`. Each record carries the
   role, the organisation type, every data requirement with its update cadence, the EASA screen
   where assessed, and nearest neighbours. Three well-chosen records beat thirty summaries.
4. **Go sideways when asked for alternatives:** `similar_use_cases` for the neighbours of one
   record; `data_requirements` for a role's or organisation type's aggregate data profile;
   `trace_data_lineage` to say where a data requirement's knowledge comes from.
5. **Screen with the framework, page-cited.** `easa_ai_framework` returns the AI-level, hazard
   class and technique-ceiling tables from the public EASA document with page references. The
   level and hazard on a use case are a title-level screen with a confidence, not a certification
   finding; say so.
6. **File what you could not find.** If the user needed something the catalogue lacks, call
   `report_unmet_need` once with what was asked and what came back. If they have a correction or
   an addition, `submit_suggestion`. Both are read by a person; `feedback_status` says what
   happened later.

## Output requirements

- Name the organisation type and role the answer is scoped to.
- For each use case cited, give its ID, the data it needs with cadence, and the EASA screen if
  present, with the confidence stated.
- Separate what the catalogue records from what you infer.
- Carry the provenance note: the catalogue is Airside Labs' proprietary corpus for use inside
  the user's analysis, not for redistribution as a dataset; the EASA tables are public text that
  may be quoted with their page reference.

## Do not

- Quote landscape counts as adoption rates or market size.
- Describe a use case as certified, approved or compliant on the strength of the screen.
- Fetch dozens of full records when the question needs three.