data_requirements

com.airsidelabs/aviation-tools · Verify this server

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, a `family_mix` that collapses the titles into ~29 canonical requirement families, plus the overall cadence mix. The aggregate is the "what data, how fresh, from whom" content for a data strategy, a feed inventory or a gap analysis, and is safe to quote as counts. For counting DISTINCT feeds, use `family_mix`, not raw titles: the corpus carries ~8,000 title spellings for far fewer real feed kinds ("Weather Data", "Weather and Environmental Data" and "Environmental Conditions" are one family), so raw-title counts overstate a feed inventory roughly 2-3x. Each family_mix row shows how many raw titles it absorbed; ~24% of requirements stay family `other` (genuinely heterogeneous). Cadence classes, coarsest to finest: annual, quarterly, monthly, weekly, daily, hourly, sub_hourly, near_real_time, real_time, event (on each occurrence), static, unknown. They normalise 1,300 spellings of update rate in the corpus ("every 15 minutes" and "4/hour" both land in sub_hourly). 152 requirements keep `unknown` because the text was not an update rate at all. Do NOT read a requirement as a statement about any real organisation's systems or data availability; it is what the use case needs in principle. Mapping needs to an actual feed inventory is your work, not the tool's. 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.