trace_data_lineage

com.airsidelabs/aviation-tools · Verify this server

Which standard operational messages would evidence this data need? The lineage spine is use case -> data requirement -> requirement family -> standard message type -> data elements. Four modes. With `use_case_id`: that use case's requirements grouped by family, each family with the standard messages that evidence it (relevance primary/supporting, cadence, element count) -- plus `requirements_without_standard_messages`, the needs no standard message covers, which is the honest feed-gap statement. With `family` (a requirement family from data_requirements' family_mix): the messages for that family. With `message_id` (e.g. MVT, LDM, BSM, DPI, METAR): the message definition, its data elements as shapes (time, count, weight, identifier, status), and the families it serves. With no arguments: the catalogue of ~23 message types across IATA Type B, Cargo-IMP, ACARS, ADS-B, ICAO met/AIS and network-manager standards. Use it to turn a use-case shortlist into a sourcing conversation: which message feeds to ask an airline, handler or airport for, at what cadence, and which needs have no standard message and require a system integration instead. Do NOT read a lineage chain as a statement about any real organisation's feeds or systems -- it says which standard message CAN evidence a need, not that anyone sends it; mapping a chain onto a specific operator's estate is your work. Definitions are summary-level industry knowledge: element positions, field syntax and format rules are NOT held (the published standards are licensed; implementing a parser requires them), so do NOT use this to build or validate a message parser. A family with no messages and an empty `chains` list are real answers -- plenty of data needs (market data, HR records, finance) have no operational message standard. 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.