trace_workflow

com.airsidelabs/aviation-tools · Verify this server

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.