Five Questions to Ask Before Any Tool Touches Your Airflow Metadata

Your orchestration metadata is a map of how your business actually runs — what moves, when, owned by whom, feeding what. Any tool that wants to import it should be interrogated first. Here are the five questions we think you should ask, and how our Apache Airflow connector answers them. We are publishing the answers because the posture is the product: a governance tool you cannot trust is worse than none.

1. What will you change in my systems?

Nothing. The connector never connects. You call your own Airflow REST API — the DAG list, optionally tasks and data-aware scheduling assets — and upload the JSON responses. CoreModels holds no Airflow credentials, installs nothing, and sits nowhere in your execution path. Live connection is a capability we have deliberately deferred rather than quietly implemented, because "we could sync automatically" is not worth "we hold your keys."

And on our side, import is strictly additive. It creates governed types for your DAGs and assets, elements for tasks, and lineage for the producing and consuming relationships — but it never mutates or deletes a governed node that already exists. Re-import after a deployment change refreshes vendor bookkeeping metadata, not governed meaning. If the estate and the model now disagree, that disagreement is surfaced, not silently resolved. Changing what something means is a human decision, made by a human, on purpose.

2. What happens when reality and the model disagree?

Drift becomes evidence, never an automatic edit. The audit compares fresh artifacts against the governed model and reports three kinds of findings — coverage (what exists but isn't governed), drift (where estate and meaning have diverged), and conformance (Airflow-specific hygiene: the unowned DAG, the missing description, the asset nothing produces, the paused producer feeding active consumers). Every finding carries a stable code, a severity, and the specific subject it names.

The audit runs read-only, at viewer level. It does not even record its own run unless you ask — recording into the rolling history is opt-in bookkeeping, so an exploratory audit leaves no trace. The one exception proves the rule: re-audit, which replays the estate snapshot stored at import time against the current governed model, always records its run, because a check triggered by a governance decision is exactly what a history is for.

Enforcement is review-shaped. In CI, an error count above zero fails the pull request — meaning changes get discussed before merge, with the author in the room. The gate does not fix anything; it convenes the humans who should.

3. What do you lose in translation, and will you tell me?

Every translation between systems loses something, and most tools handle that by not mentioning it. We publish it. Import and audit responses carry an explicit lossiness channel alongside the results — a successful operation can still tell you exactly what it approximated.

The Airflow connector uses it honestly. Task operator classes are not data types, so the model carries them as strings and flags the approximation rather than inventing a type system that isn't there. Facts that don't fit the neutral model are reported as lossiness rather than smuggled in somewhere they don't belong. And when a very large deployment exceeds the snapshot storage cap, the import says so plainly — snapshot not stored, with a record explaining it — and the stored-snapshot re-audit is honestly unavailable rather than quietly wrong. Fresh-artifact audits keep working. We would rather hand you a limitation than a surprise.

4. What do you refuse to do?

Generate Airflow code. Most of our connectors can generate vendor artifacts from the governed model — contracts, DDL, schemas — because for those systems the artifact really is derivable from governed meaning. Orchestration code is not. A DAG encodes decisions about retries, sensors, scheduling, and failure handling that no schema contains, and a generator would produce something that looks plausible and runs wrong — the most dangerous kind of output a governance tool can emit.

So the Airflow connector's capabilities are import and audit, full stop. Ask it to generate and you get an explicit refusal — the capability gate answers that the connector does not support generation, before any emission code runs. Nothing is silently emitted. We think the refusals a tool is willing to state out loud are the best predictor of how it behaves where you can't see it.

5. Who can do what?

Roles, narrowly drawn. Import — the only verb that writes to the governed graph — requires project admin. Audit, re-audit, history, status, and the SVG badge all run at viewer level, read-only. The CI gate authenticates with a user API key that needs nothing more than viewer access, because the audit never writes governed meaning; a leaked CI key cannot corrupt your governed model. The same split governs AI agents over MCP: read-only tools are on the public endpoint, and the import tool lives only on the admin endpoint behind admin membership. Nobody — human or agent — gets a write path they didn't explicitly earn.

Why we hold this posture

Governance fails socially before it fails technically. The moment a tool mutates something unexpectedly, loses something silently, or generates something confidently wrong, engineers stop trusting it — and then they route around it, and then it is decoration. Every answer above is designed against that failure: additive import, human-gated meaning, published lossiness, honest refusals, minimal privilege. Ask these five questions of anything that wants your metadata. We wrote our answers down so you can hold us to them.

The Apache Airflow quickstart in the CoreModels docs states each of these guarantees alongside the calls they apply to.