data_requirements

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.