Apache Airflow

Your Airflow deployment can already describe itself. The stable REST API v1 will tell you every DAG, every task, and - if you use data-aware scheduling - every asset your pipelines produce and consume. What it will not tell you is whether any of that still matches what your organization *thinks* it runs: who owns each pipeline, which assets are consumed but produced by nothing, which consumers are quietly running on stale data because every producer is paused.

Every vendor integration in CoreModels answers the same first question the same way. Ask the platform what it knows how to govern:

"Which of our pipelines have no accountable owner, and is anything downstream of a paused DAG?" That is a governance question, and until recently answering it meant a human clicking through the Airflow UI and cross-referencing a wiki. With CoreModels, an AI agent answers it directly: the same import/audit machinery we expose over HTTP is exposed over the Model Context Protocol, so an agent connected to your CoreModels server can inspect connector capabilities, run a full drift-and-hygiene audit of an Airflow deployment, and read back a human-quality report - all through typed tool calls.

Orchestration drift is the quiet kind of failure. Nobody deletes a pipeline; a schedule is flipped to manual during an incident and never flipped back, and for three weeks a downstream table renders yesterday's world with perfect confidence. Nobody removes a dataset from governance; a DAG is renamed in a refactor and the governed model now describes a pipeline that no longer exists. None of this throws an exception - which is exactly why it belongs in CI, where a machine checks it on every change.

Airflow is not a schema estate. A warehouse table has columns with types; a dbt model has a contract; an Avro subject has fields. A DAG has none of those - it has tasks, a schedule, an owner, and (with data-aware scheduling) declared relationships to the data it produces and consumes. So when we built the Apache Airflow connector for CoreModels, the design question was not "how do we pretend DAGs are tables?" but "what is orchestration's actual governance value?" The answer we committed to: the DAG-to-asset dependency graph, and pipeline hygiene. This connector is lineage-first, and every mapping decision below follows from that.