trace_workflow

What happens before and after this use case, and who hands off to whom?

The catalogue is otherwise flat -- role, use case, data requirement -- with
no edges. This is the edges: named operational sequences with their steps in
order, the role at each step, the gate that must hold before the next one
may start, and what passes between roles at each handoff (headset, radio,
hand signal, system, visual, document, verbal, formal correspondence).

Three modes. With use_case_id: every workflow that places that use case,
its position, and the steps immediately preceded_by and followed_by it
with what transfers. That is the real operational dependency -- distinct
from similar_use_cases, which is text similarity, and from
data_requirements(query=...), which infers a relationship from two use
cases sharing a feed. A gate is a dependency; a shared feed is a
correlation. With workflow_id: the whole sequence end to end. With
phase (arrival, turnaround, departure, abnormal, oversight,
certification, crew qualification, planning, mission) or nothing: the
catalogue of workflows with their step and handoff counts.

Use it to answer "if this prediction improved, what downstream step benefits
and who would have to act on it", to see which roles a change touches, and
to find the abnormal branches -- communication failure, coupling break-off,
spillage, a ramp finding serious enough to stop the aircraft -- which are
sequences in their own right and where the costly failures live. Some
sequences cross an organisation: a finding travels from an authority to an
operator and back, and those edges carry the channel `formal
correspondence`.

Coverage is ground handling, regulatory oversight and certification, crew
qualification and rostering, and specialised missions -- not the whole
catalogue. A use case with an empty placed_in is outside the covered
sequences, which is a statement about coverage and not about the use case,
and some are unplaced because they are standing monitoring states rather
than sequences. A step whose role_in_catalogue is false is a real
participant the catalogue holds no use cases for -- the flight deck on a
turnaround, the officer who signs a certificate -- not a data error. The
sequences are Airside Labs' derived structure: they say how this work is
ordered in the industry, NOT that any particular operator runs it this way,
and they are not an operating procedure. Do NOT use one as a checklist to
work to; the authority for that is the operator's own manual.

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.