get_use_case

com.airsidelabs/aviation-tools · Verify this server

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 wrong tool: use the aggregates. The data requirements are what this use case *needs*, stated generically ("airport operational database", "ADS-B feed"), not what any particular airport has. A requirement with cadence_class `unknown` had an update rate the normaliser could not read; the raw `update_rate` is still there. Do NOT treat the EASA screen as a determination: it is a title-level assessment by Airside Labs with a confidence, made to sort a portfolio, and a real classification needs a ConOps. Cite the framework rows by their cp_ref if you quote them. Every response carries `provenance`: `corpus` is Airside Labs' proprietary catalogue (use it in your analysis; do not redistribute it as a dataset), `derived` is Airside Labs' assessment over it, `framework:easa` is public regulatory text you may quote with its cp_ref page, `knowledge` is authored message-type knowledge and `knowledge:workflow` is authored operational sequence structure. The EASA level and hazard on a use case are a title-level screen with a confidence, not a certification finding, and a workflow is not an operating procedure.