Adopt contracts on a raw dbt-core project

You have a dbt-core project that runs. Models, schema.yml files, maybe some tests — no data contracts, no governance layer, just dbt. Adopting Kirimana here is additive: it puts ODCS contracts above your existing models without rewriting them, and your dbt build keeps working exactly as it does today. Nothing you rely on changes; you gain a contract layer, a validator, and the kiri.* governance namespaces on top.

The core promise: your dbt files are not touched

Kirimana’s dbt integration never modifies user-authored files. When it generates dbt-native artifacts from a contract, it writes them into a namespaced subdirectory with generated filenames of the form _kiri_<contract_id>.contract.yml, each carrying a DO NOT EDIT — generated by kiri header. Your models, your hand-written schema.yml, your macros, your dbt_project.yml — all untouched. That is what lets dbt build behave identically before and after adoption: the generated artifacts live alongside your project, not inside your authored files.

What kiri reads from an existing dbt project

Adoption starts by reading, not writing. Kirimana reads your dbt project’s compiled artifacts — the manifest.json dbt produces on a build — to learn what models exist, their columns, and how they relate. That is the map it works from: it doesn’t guess at your project’s shape, it reads dbt’s own record of it. Your model SQL stays the source of truth for how data is produced; the contract describes what the model guarantees.

Step 1 — Scaffold contracts above your models

With the project’s shape known, scaffold contracts over the models you want to govern. The contract sits above the model: the model remains the transformation, and the contract becomes the promise about its output — schema, ownership, classification, and any SLA you choose to declare.

Start with the models that matter most — the ones downstream teams consume — rather than boiling the ocean. A gold-layer fact that BI depends on is a far better first contract than an intermediate staging model nobody reads directly. Each contract you author gets a generated dbt model-contract artifact emitted into the namespaced subdirectory, wiring dbt’s own contract-and-test enforcement to the guarantees your ODCS contract declares — without you hand-writing that YAML and without it colliding with your authored schema.yml.

Step 2 — Lint before you enforce

Validate the contracts against your project before you make anything depend on them. kiri migrate lint-models applies the medallion layer-policy across your dbt models, so a model that claims to be gold but reads straight from a raw source is flagged rather than silently accepted:

kiri migrate lint-models --models models

Contract validation runs the same way — read-only, no workspace changes — telling you where a contract is malformed or where its declared shape doesn’t match the model it sits over. Iterate here until the project is clean. Throughout this phase your existing dbt build is entirely unaffected; you’re checking contracts, not changing pipelines.

Step 3 — dbt build stays exactly as it was

This is the property that makes adoption safe. Because the generated artifacts are additive and namespaced, your build command, your selectors, your CI — none of it changes:

dbt build

The generated model-contract files participate in dbt’s own contract enforcement when you build, but they were produced from your ODCS contracts, and regenerating them overwrites only the generated files — never your authored ones. The dbt-core versions Kirimana supports are a published, CI-gated set; a build on a supported minor behaves the same with the contract layer present as without it.

Where it goes from here

Once a contract lints clean and your build is green with it in place, that model is governed: its schema is a promise, its classification and SLA are declared, and it can be promoted between environments with the kiri release verbs like any other contract. You adopt the next model when you’re ready. There is no cutover — the raw dbt project and the contract-governed one are the same project, one model at a time. Kirimana is in private beta at v1.0.0-beta.1; the lint and generation surfaces above are available today.