Use Kirimana with an existing dbt-core project

Kirimana does not replace dbt-core. It wraps it. If you already have a dbt project building models against a Databricks SQL warehouse, you keep that project, keep your models, keep dbt build — and layer contract context on top of it. Nothing about your existing transformation logic has to move.

This page is the honest inventory of what changes in your repo and what stays exactly where it is.

The mental model: dbt-core builds, Kirimana governs

dbt-core stays the transformation engine. It compiles your SQL, resolves ref() and source(), runs materialisations, and writes the manifest. Kirimana sits alongside it as the contract layer: it reads your models, attaches classifications, ownership, lineage, and SLA metadata, and projects that governance out to your catalog and BI tools.

The kiri CLI wraps dbt-core rather than shelling out to a fork. The supported dbt-core minors are pinned and gated in CI — 1.8.x, 1.9.x, and 1.10.x are the currently supported set, with the workspace pin at dbt-core>=1.8,<2.0. A minor outside that set may work but is not guaranteed. If you are on one of those three, adoption is additive.

What does not change

Your models. Every .sql file stays where it is. Kirimana reads them; it does not rewrite them on adoption.
dbt build / dbt run / dbt test. The commands you already run keep working unchanged. Kirimana’s build orchestration is a superset, not a replacement — you can invoke dbt directly whenever you want.
Your adapter and warehouse connection. You keep pointing dbt at your Databricks SQL warehouse through your existing profiles.yml.
Your ref() / source() graph. Lineage is read from the compiled manifest, not re-declared by hand.
Your test suite. Existing dbt-core data tests (not_null, unique, relationship tests) continue to run as part of the build.

What gets added to the repo

Adoption adds a small, reviewable surface:

kiri.yml — the project manifest. It declares your targets (dev / test / prod), the default target, and optional blocks such as semantic_layer: for BI export. This is the one file that makes a directory a Kirimana project.
Contracts under models/. Contracts are ODCS documents that carry the governance metadata a bare dbt model can’t: kiri.classification, owner, PII flags, AI policy, SLA. You can author them by hand or scaffold them from an upstream inventory.
A .kiri/ working directory. Audit logs, the local catalog, and cached state live here. Add it to .gitignore as appropriate.

You do not have to contract everything on day one. Start with the models that carry sensitive or business-critical data; the rest keep building as plain dbt models until you get to them.

How contract context enriches the manifest

When Kirimana runs your build, it reads dbt-core’s compiled manifest and joins it against your contracts. That join is where the value is:

Classifications — every contracted model carries a kiri.classification (public / internal / confidential / restricted). This flows through to catalog annotations and BI-tool metadata, so the analyst sees the sensitivity of a column, not just its name.
Ownership — the contract’s owner becomes the authoritative answer to “who owns this table”, surfaced in the catalog and in KPI lineage.
Lineage — Kirimana reads the ref() / source() edges dbt already resolved. You do not re-declare lineage; it is derived from the manifest and enriched with contract-level ownership and classification so a lineage query returns governance, not just graph edges.
SLA — freshness and SLA declarations on the contract feed KPI freshness lookups (kiri kpi describe) and catalog signals.

The manifest stays dbt-core’s artefact. Kirimana enriches its reading of that manifest — it does not mutate the file dbt wrote.

A typical adoption sequence

Add kiri.yml at the project root with your targets, pointing at the same Databricks SQL warehouse your profiles.yml already uses.
Contract your highest-value models. Author or scaffold ODCS contracts for the tables that carry PII or drive reporting. Set kiri.classification and owner first; the rest can follow.
Build as usual. Run your build; dbt-core compiles and materialises exactly as before, and Kirimana attaches the contract context.
Project governance outward. Push classifications and ownership to Unity Catalog, and export the semantic layer for your BI tools when you’re ready.

Because the wrapper is additive, every step is reversible. If you stop using kiri, your dbt project is exactly the project you started with — plus some contract YAML you can keep or delete.

Version discipline

The dbt-core minor you run matters. Kirimana gates its dbt-bridge test suite against each supported minor weekly, so a supported minor that breaks is a release blocker, not a surprise you discover in production. If you need a minor outside the supported set, raise it before you pin — adding a minor is a deliberate, CI-gated step, not a silent widening of the range.

Keep your dbt-core inside >=1.8,<2.0, prefer one of the three supported minors, and adoption stays boring in the best way: your build doesn’t change, and your governance finally has somewhere to live.