From Workshop Transcript to AI Opportunity Map

You have just come out of a two-hour workshop with an airport operations manager. The transcript is a wall of half-formed ideas: predict turnaround delays, flag stand conflicts before they happen, get ahead of weather disruption, "do something with all the data the ramp teams generate." Your job is to turn that into something a steering committee can act on — a set of concrete AI use cases, each with the role that owns it, the data it needs, and an honest read on where it sits against the EU/EASA AI rules.

The slow way is to do it from memory and hope. The problem with doing it from memory is not that a language model lacks aviation knowledge — it has plenty — but that it will invent a plausible role, a plausible data feed, and a plausible compliance posture, and you will not know which of the three is wrong until a regulator or a client SME tells you.

This is exactly the gap the Airside Labs aviation-tools MCP server is built to close. It exposes a catalogue of 6,527 aviation AI use cases — organisation type, role, data requirements with normalised update cadence, and an EASA AI-level and hazard screen — as tools an agent can call. Below is the actual workflow, run against the live catalogue, with the real responses.

Step 1 — Find the use cases the transcript is gesturing at

Take one idea from the transcript — "predict turnaround delays and get smarter about stand allocation" — and search for it in operational language:

search_use_cases("predict aircraft turnaround delay stand allocation")

→ 10 results, top four:
   #7060  Ramp Agent                       Optimize aircraft turnaround times using predictive analytics…
   #6257  Airport IoT Specialist           Optimize turnaround times and gate utilisation through AI…
   #6398  Airport Innovation Manager        Automating aircraft turnaround processes and reducing delays…
   #5525  Airline IoT Specialist            Automating turnaround by integrating IoT sensors…

Search is BM25 over the catalogue, so it ranks on the operational nouns, not on marketing phrasing. Already you have something the transcript did not give you: the same idea belongs to four different roles, and which one owns it changes the data, the budget and the risk. That distinction is the first thing a good opportunity map makes explicit.

Step 2 — Pull the structured record, decorated with data needs

Fetch the full record for the closest match:

get_use_case(7060)

→ role:  Ramp Agent
  org:   Aviation Services
  data_requirements:
    - Flight Schedule Data        [Real-time]
    - Aircraft Turnaround Times   [Daily]
    - Weather Data                [Hourly]
    - Airport Operational Data    [Real-time]
    - Ramp Agent Activity Data    [Real-time]
  classification:
    ai_level:   1A
    hazard:     H4
    confidence: 0.65
    rationale:  "Predicts turnaround delays; information support"

This is the spine of an opportunity-map entry, produced in one call. Note the update cadence on each data requirement — "Real-time" versus "Daily" versus "Hourly" is the difference between a streaming integration and a nightly batch, and it is the detail a data-strategy document lives or dies on. get_use_case returns it as structured data, not prose you have to trust.

If you want the data picture for the role rather than a single use case — useful when the workshop keeps circling one job function — data_requirements(role="Ramp Agent") returns an aggregate profile: the top requirements across every use case that role owns, the mix of cadences, and provenance on each.

Step 3 — Name the EASA footguns before the client does

Here is where confidently-wrong hurts most. The record above carries a screen — ai_level: 1A, hazard: H4 — but read the provenance that comes with it:

Airside Labs assessment over the catalogue: the EASA AI level and hazard class are our screen (title-level, with a confidence), not an EASA determination.

That honesty is the point. A 1A screen tells you this looks like Level 1 "information support" AI rather than Level 2 human-AI teaming or Level 3 autonomy — which matters enormously for the assurance burden — but it is a starting hypothesis with a 0.65 confidence, not a compliance sign-off. To reason properly, pull the framework itself:

easa_ai_framework()

→ ai_levels, hazard_classes, technique_ceilings, sources

You get the EASA AI-level definitions, the hazard classes, the technique ceilings (which AI techniques are permissible at which assurance level), and page-cited sources. Now your agent is reasoning over the actual framework tables rather than its recollection of them — so when it writes "this use case likely sits at Level 1A, but the moment you let it act on stand allocation without a human in the loop it climbs toward Level 2 and a different assurance regime," that sentence is grounded, and you can show the client where it came from.

Step 4 — Frame the map

Finally, zoom out to shape the opportunity map itself:

use_case_landscape(group_by="ai_level")

→ 6,527 use cases total (1,913 EASA-screened)
   1A: 1,262    1B: 493    2A: 152    3A: 3    2B: 1

Most airport-operations AI clusters at Level 1 — information and support — which is the honest, unglamorous truth an opportunity map should lead with: the near-term wins are decision-support tools an operator stays in command of, not autonomy. That framing manages expectations before the steering committee forms them.

What you end up with

Run across every idea in the transcript, this gives you a defensible opportunity map: each use case tied to the role that owns it, decorated with data requirements and their cadence, screened against the EASA AI level with a stated confidence, and neighbours suggested for the ideas the room did not think of. The agent composes the narrative; the catalogue keeps it honest.

The one thing to hold in mind: for an idea genuinely novel to the catalogue — something the airport is doing that nobody else is — you will not get an automated classification, because the EASA screen exists for use cases in the catalogue, not arbitrary text. There you use easa_ai_framework as grounding and reason it through. That is a feature, not a limit: the tool tells you what it knows and declines to fabricate what it does not.

Try it

use_case_landscape and get_use_case are on the free tier — no API key — so you can walk the catalogue and pull records straight away. search_use_cases, data_requirements and easa_ai_framework — the tools that turn browsing into a deliverable — are on the £49/month plan. Connection details and the full tool reference are at airsidelabs.com/for-ai-agents.

And if the workshop surfaced a use case the catalogue is missing, tell us — submit_suggestion is an open, no-auth channel, read by a person. That is how the catalogue grows.

---

Airside Labs builds and evaluates production AI for aviation — prototypes, fine-tuned models, RAG systems and adversarial testing — with 25+ years of aviation data experience behind it. The use-case catalogue is one of the tools we use on client work, now available to yours.

How do you turn a client workshop into an AI opportunity map?

Take each idea from the transcript and, for each, resolve it against a catalogue of aviation AI use cases: find the matching use cases in operational language (search), pull the full record — role, data requirements with update cadence, and an EASA AI-level and hazard screen (get_use_case), aggregate the data needs for the owning role (data_requirements), ground the compliance read in the actual EASA framework tables (easa_ai_framework), and frame the whole map by AI level (use_case_landscape). The Airside Labs aviation-tools MCP server exposes exactly these tools, so the agent composes the narrative while the catalogue keeps the roles, data and compliance posture honest.

Can an AI tool classify an aviation use case against the EASA AI framework?

Partly, and honestly. The Airside Labs catalogue carries a title-level EASA AI-level and hazard screen with a stated confidence for the use cases it holds — a starting hypothesis, explicitly not an EASA determination. For a use case in the catalogue you get that screen directly; for a genuinely novel idea you use the easa_ai_framework tool, which returns the EASA AI-level definitions, hazard classes, technique ceilings and page-cited sources, and reason it through. The tool grounds the classification in the framework rather than fabricating a compliance verdict.

What data does an airport turnaround-prediction AI use case need?

For a ramp-agent turnaround-optimisation use case, the catalogue lists flight schedule data (real-time), aircraft turnaround times (daily), weather data (hourly), airport operational data (real-time) and ramp activity data (real-time). The update cadence on each is the load-bearing detail — real-time versus daily is the difference between a streaming integration and a nightly batch — and the get_use_case tool returns it as structured data with provenance.