Airflow Sits in the Middle of Your Stack. Govern It Without Wrapping It.

Draw a map of a typical modern data platform and Apache Airflow is rarely at the edge. It is the connective tissue: it triggers the ingestion jobs, kicks off the dbt build, loads the warehouse, refreshes the feature tables, and moves the files everything else depends on. An Apache Software Foundation project with pipelines defined as Python DAGs and a broad provider ecosystem, Airflow became, for many data teams, simply the scheduler — the thing all the other tools are arranged around.

That position in the map is exactly why governing it matters, and exactly why the way you govern it matters more.

The orchestrator holds the estate in motion

Catalogs and warehouses describe your data at rest. The orchestrator describes it in motion: which process produces which artifact, on what schedule, consumed by whom, currently running or paused. Recent Airflow releases made this explicit — data-aware scheduling turned the datasets that pipelines exchange into first-class objects (called Assets in Airflow 3), so the dependency structure between DAGs is no longer only implied by convention; it is declared, and it is served by Airflow's stable REST API.

That means the orchestration layer now holds a machine-readable map of your estate's dynamics that exists nowhere else. The question is what a governance product should do with it.

Meeting a standard where it stands

Our answer is deliberately boring: we implement Airflow's published surface and nothing else. The CoreModels connector consumes three documented REST API responses — the DAG list, the per-DAG tasks, and the datasets — which you extract yourself with your own credentials. No plugin in your Airflow deployment, no wrapper around the scheduler, no agent in the execution path, no credentials held by us. Airflow versions upgrade on your schedule; our contract is with the stable API, not with your internals.

This is a general principle for us, not an Airflow accommodation. Every one of our thirteen connectors — dbt, Snowflake, Databricks, BigQuery, Microsoft Fabric, AWS Glue, Confluent Schema Registry, Airbyte, Neo4j, Salesforce, REDCap, cBioPortal, and Airflow — works from artifacts the vendor's own tooling already produces. The vendor defines its surface; we read it faithfully; you stay in control of the connection.

Composition is the point

The value of governing the orchestrator is not the orchestrator in isolation — it is what the orchestrator connects. Airflow runs your dbt project; dbt materializes into your warehouse; the warehouse feeds what Airflow schedules next. Each of those systems describes its own slice of reality in its own vocabulary, and traditionally the joins between the slices live in people's heads.

In CoreModels, each estate imports into one neutral model, and — critically — Airflow's producing and consuming relationships land in the same dependency graph the dbt and warehouse connectors feed. A DAG that writes a file, the DAGs that trigger on that file, chained cross-DAG through the assets they share, alongside the model-to-model lineage from dbt and the object dependencies from the warehouse: one graph, one vocabulary, queryable end to end. Where two vendors govern the same physical object from different sides, a reconciliation step can link them explicitly as the same thing. That composite picture is something no single vendor can draw, because no single vendor can see past its own boundary — and it is only drawable at all because the model in the middle belongs to none of them.

Neutrality is a load-bearing property

Why insist on the neutral middle? Three reasons, in ascending order of importance.

First, longevity. Your orchestrator will outlive any particular governance tool's roadmap, and your governance record should outlive both. A governed model held in a vendor-neutral graph — exportable to open formats like JSON Schema, LinkML, Avro, and OWL — is a record you can take with you. Meaning captured in someone's proprietary silo is meaning held hostage.

Second, mixtures are normal. Real platforms run Airflow next to a warehouse-native scheduler, or migrate orchestrators over years, or acquire a company that chose differently. A governance layer that privileges one vendor's worldview cannot describe that reality; a neutral one describes it natively, because every estate lands in the same model regardless of which system it came from.

Third — and this is the one that gets missed — neutrality means telling the truth about what each system is. Our connector capabilities are honest per vendor: most connectors can generate artifacts from the governed model, because for a warehouse or a schema registry the artifact genuinely is derivable from governed meaning. For Airflow we refuse to generate, explicitly, because orchestration code is not derivable from schema. A neutral layer does not flatten every system into the same shape to make its own feature matrix look uniform. It represents each system's real nature, including the parts that mean saying "no."

The middle of the stack deserves better than another middleman

There is a recurring pattern in this industry: a system becomes central, and tools compete to insert themselves in front of it. We think the center of your stack is precisely where you should tolerate that least. Airflow earned its position; the way to govern it is to read what it publishes, join it to what its neighbors publish, and keep the resulting meaning in a model that no vendor — including us — can hold hostage.

To see what the connector reads and how the estates join up, start with the Apache Airflow quickstart in the CoreModels docs.