Connect Airbyte

Schema Changes Don't Knock: Why Airbyte Pipelines Need a Front Door

An application team ships a routine release, and somewhere in their product database a numeric total becomes a string with a currency prefix. No announcement reaches the data team — schema changes don't knock. Airbyte keeps syncing, because moving data is its job. The warehouse keeps loading, because storing data is its job. Every sync stays green while the numbers drift quietly out of truth, until a human happens to squint at them. The only thing that broke was the meaning of the data, and meaning was the one thing no part of that pipeline was watching.

Recipe: Source Onboarding Review

The Quiet Week: Life With a Governed Airbyte Connection

The most convincing demo of schema governance is a boring week. No archaeology through sync logs, no "who changed this?" threads, no Friday backfill. What follows is a composite week for a data engineer who owns an Airbyte deployment after the catalog is governed in CoreModels — and, running alongside it, the same week as it used to go.

Recipe: CI Drift Gate for Airbyte · First Governed Import for Airbyte · Source Onboarding Review

Five Commitments We Make Before Touching Your Airbyte Catalog

Any tool that asks to sit between your data sources and your governed schemas is asking for a lot of trust. We think that trust should rest on verifiable commitments rather than assurances — specific behaviors, designed into the system, that you can test before you rely on them. Here are the five that govern how CoreModels handles an Airbyte catalog, and why each one exists.

Open Pipes, Open Meaning: Airbyte's Place in a Neutral Governance Layer

Airbyte's founding bet was that data movement should be open: an open-source platform, a connector catalog anyone can extend, and — the part that matters most for governance — schemas declared in the open. Every Airbyte stream describes itself with JSON Schema inside a catalog document: property names and types, nullability expressed as type arrays, enums, primary keys, supported sync modes. You can extract that catalog from your own instance with a single API call. No proprietary binary, no export ceremony.

From Plausible to Provable: Giving AI Agents the Truth About Your Airbyte Streams

Watch a coding agent write transformation logic against ingested data and you can see the exact moment it starts making things up. Asked to build staging models over an Airbyte-landed orders stream, it will confidently produce column lists it inferred from the table name, treat every `id` as a unique key, assume `updated_at` implies incremental sync, and enumerate status values it has seen in other companies' schemas. The output is fluent, well-formatted, and structurally fictional — not because the model is weak, but because nothing in its context contained the actual schema. Agents don't fail loudly on missing ground truth; they interpolate over it.

Zero to First Audit: Putting an Airbyte Catalog Under Governance

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.

Recipe: Blank Airbyte project · First Governed Import for Airbyte

Every Verb, Every Role: The Airbyte HTTP Surface

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.

Tool Calls, Not Screenshots: Running an Airbyte Audit from an AI Agent

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 Drift Gate for Airbyte: CI, Badges, and the Heartbeat Between Runs

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".

Recipe: CI Drift Gate for Airbyte

Inside the Airbyte Connector: Identity, Types, Checks, and the Limits We Publish

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.

Recipe: Source Onboarding Review