Airbyte

Everything in this tutorial happens in a shell. There is no agent to install in your Airbyte deployment, no warehouse connection to configure, and no credential of yours that ever reaches CoreModels. You export one JSON document that Airbyte already produces, upload it, and ask a question about it.

One sentence in the controller sets the shape of everything below it: the vendor integration surface is **read-authority**. Import writes to the graph, and only additively. Audit and generate never write anything. Recording an audit run in the history is opt-in bookkeeping - except for re-audit, which always records its run because that is the whole point of the verb.

There are two ways to let an AI assistant help with an ingestion catalog. The first is to paste the catalog into a prompt and ask what looks risky - fast, ungrounded, unverifiable. The second is to give the assistant a tool that runs the real audit against your governed model and returns coded findings. This article is about the second one.

A dbt gate has an obvious trigger: someone opens a pull request, the project compiles, and the compiled artifact is the thing you audit. Airbyte has no build step. A catalog is *discovered*, not compiled, and the schema it describes belongs to a system nobody in the repository controls. So the first question for an Airbyte drift gate is not "which endpoint do I call" - it is "where does `catalog.json` come from, and when".

Every vendor CoreModels integrates parses into one neutral shape: datasets with fields and normalized checks, plus lineage between them. Vendor detail rides in metadata bags, never as new top-level concepts, and connectors are pure - they parse, map types and contribute audit rules, never touching the graph.