How Kirimana compares
For data engineers and data architects evaluating where the contract layer fits next to dbt, DataHub, Great Expectations, OPA, Unity Catalog, and the rest of the stack you already run.
Honest comparison. Kirimana is not trying to replace dbt, your catalog, your quality engine, or your policy engine. It operationalises the contract — the design-time artefact that ties them together — anchored in capabilities that are implemented today.
Status: where Kirimana actually is
v0.9 · private preview · invite-only · v1.0 target H2 2026.
This page compares a v0.9 platform against products with ten-year heads of runway. That asymmetry is real and worth naming. Read every ”✓” below as “implemented today in core, exercised in preview” — not as “shipped at GA scale with reference customers.” Production miles on the implemented surface are still small.
What you can rely on at v0.9:
- ODCS v3 contracts as the canonical artefact, on disk, in git.
kiriCLI: contract authoring + lint/validate/diff, ingest, migrate, audit, federation, catalog pass-through, project lifecycle.- Databricks adapter — the supported runtime path.
- Guided source-schema introspection on Databricks.
- Mandatory one-line Databricks audit on every Kiri-driven action.
What is on the roadmap and not marketed as shipped:
- Compliance evidence generators (DORA / EU AI Act / GDPR).
- OSS edition operating runtime (component stack to be published when the first design-partner deployment is exercised end-to-end).
- Additional source-system introspection beyond Databricks.
If you need a procurement-ready governance suite tomorrow, run something else and revisit Kirimana at v1.0. If you want to shape the contract layer your stack will need next, the preview is open.
What makes Kirimana distinctive
An open-source data contract platform built around the artefact developers can actually grep — with ownership, authoring guardrails, and audit enforced structurally, not by policy guidance.
- ODCS v3 contracts as source of truth on disk. Not a catalog
UI, not a metadata API. Files in git that
dbt, Claude Code, Cursor, and your CI can read directly. - Mandatory ownership, enforced structurally. Every contract
names a real human; every property names a classification. The
CLI rejects what doesn’t. No
owner: unknown. - Fail-closed authoring guardrails. Inferred PII (names, emails,
free-text identifiers, classified attributes) cannot be authored
as
publicwithout an audited override and a written reason. Default is refuse, not warn. - Mandatory one-line Databricks audit. Every Kiri → Databricks
action emits a single audit line with a correlation id. CLI calls
and MCP calls are audited identically.
tail -f databricks-audit.logis the entire demo. - Design-time, not post-hoc. Atlan, Collibra, DataHub, Unity Catalog, Purview, and Horizon observe what already exists. Kirimana decides what should exist — at PR time, in the linter, before the table is built.
- Guided source-schema introspection for the warehouse you already have. Sample a live source, classify columns, and propose populated bronze contracts. Editable scaffolding, not auto-applied. Databricks today; additional source-system targets on the roadmap.
- Wraps your dbt build. We don’t replace dbt-core. We add the
contract, the lineage edges, and the audit log around the same
dbt buildyou already run. - Column-level lineage declared in contracts.
kiri.lineage.from_columnsemits per-column URN edges through the medallion. Deterministic at compile time, not scanned post-hoc. - Federation across three transports. Versioned catalog
snapshots over in-process, HTTP+ETag, and fs-static.
health()returns OK / STALE / UNAVAILABLE;lint,apply, and federated reads fail closed when a source isn’t reachable. Multi-team governance without a central catalog vendor. - Migration as a verb set. AI-assisted business-vault → ODCS
translation, parity harness with row-hash check,
shadow → diff → promote → rollbackcutover, KEEP / DROP / MERGE / REDESIGN review actions, and quarantine reprocess as a typed state machine. - Apache-2.0 today, no BSL planned. Licence-stable. Structural protection is being built in via a legal entity (David Barton Consulting AB, Sweden) and a future donation path to a neutral foundation — the LF AI & Data Foundation, the same home as Bitol/ODCS. We describe the path; we don’t promise the move.
Detailed comparison
vs dbt model contracts (dbt-core + dbt Cloud)
The most important comparison for data engineers, and the one we get asked first. dbt is not the enemy. Kirimana runs on top of dbt.
| Kirimana | dbt-core model contracts | dbt Cloud | |
|---|---|---|---|
| Cost | Free (Apache-2.0) | Free | Paid |
| Contract scope | full ODCS v3 — schema + classification + ownership + lineage edges + SLA | schema + column types + basic constraints in model.yml | model.yml + Cloud-only governance features |
| Mandatory ownership | ✓ structurally enforced | optional | optional |
| Fail-closed authoring guardrails (PII → public refused) | ✓ | ✗ | ✗ |
| Mandatory action-level audit (one line per action) | ✓ on Databricks | ✗ | partial (cloud-only) |
| Column-level lineage | ✓ contract-declared edges | ✗ (model-level only) | model-level only |
| PR-time governance gates | ✓ kiri contract lint/validate/diff | partial (schema only) | partial |
| Federation | ✓ three transports · fail-closed health | ✗ | partial |
| Compliance evidence generators | roadmap | ✗ | ✗ |
How we differ: dbt model contracts are free and they cover
schema. That’s the right floor and we don’t try to undercut it.
Kirimana adds mandatory ownership, fail-closed authoring guardrails,
mandatory Databricks audit, column-level lineage edges, federation,
and migration verbs on top of the same dbt build. If schema-only
contracts are enough for your team, stay on dbt-core. We’re for the
moment governance starts to matter.
vs DataHub (OSS metadata + lineage)
The other comparison data engineers raise. Different layer, not a competitor.
| Kirimana | DataHub | |
|---|---|---|
| Category | Design-time contract platform | Runtime metadata + lineage |
| Open source | ✓ Apache-2.0 | ✓ Apache-2.0 |
| Primary artefact | ODCS YAML on disk | Metadata model in a service |
| Posture | Decides what should exist (PR-time) | Observes what does exist (scan-time) |
| Mandatory ownership | ✓ | ✗ |
| PR-time governance gates | ✓ | ✗ |
| Lineage | Contract-declared edges | Scan-derived, strong runtime coverage |
| Catalog UX | basic | excellent |
| Quality | Wraps DQX / Great Expectations | Pluggable quality monitors |
How we differ: DataHub is a strong OSS catalog with the best OSS lineage in its class. It is complementary, not competitive. Kirimana is the source-of-truth contract layer that feeds a catalog like DataHub. Many teams will run both: Kirimana for design-time contracts, DataHub for runtime metadata and post-hoc lineage. A push adapter is on the roadmap.
vs Great Expectations / Databricks DQX (data quality)
| Kirimana | Great Expectations | Databricks DQX | |
|---|---|---|---|
| Category | Contract layer | Quality engine | Quality engine |
| What it is | Contract that quality rules attach to | Library of expectations | Native Spark quality rules |
| Replaces the other? | No | No | No |
How we differ: Kirimana runs Great Expectations and DQX — it does not replace them. Quality rules declared in a contract compile down to the engine that already runs in your platform. What Kirimana adds is the contract context: which dataset, which classification, which owner, and which lifecycle state a rule belongs to.
vs Atlan / Collibra / Alation (data catalogs)
| Kirimana | Atlan | Collibra | Alation | |
|---|---|---|---|---|
| Category | Data contract platform | Data catalog | Data governance + catalog | Data catalog |
| Open source | ✓ Apache-2.0 | ✗ | ✗ | ✗ |
| Contract artefact (ODCS v3 on disk) | ✓ canonical | ✗ | ✗ | ✗ |
| Mandatory ownership | ✓ structurally enforced | partial | partial | partial |
| Fail-closed authoring guardrails | ✓ | ✗ | ✗ | ✗ |
| Contract state machine | ✓ canonical lifecycle | ✗ | ✗ | ✗ |
| Column-level lineage from contracts | ✓ generated at compile time | post-hoc scan | post-hoc scan | post-hoc scan |
| PR-time governance linting | ✓ | ✗ | ✗ | ✗ |
| Mandatory action-level audit on Databricks | ✓ one line per Kiri action | configurable | configurable | configurable |
| Migration as a verb set | ✓ translate · parity · cutover · KEEP/DROP/MERGE/REDESIGN | ✗ | ✗ | ✗ |
| Compliance evidence generators | roadmap | add-on | enterprise add-on | partial |
| Catalog UX polish | basic (v0.9) | ✓ excellent | enterprise | enterprise |
| Pricing | Free | $$$ | $$$$ | $$$ |
How we differ: Atlan wins on catalog UX — we don’t compete there. Kirimana can feed Atlan via a push adapter so a team can have both: contracts at the source, Atlan as the discovery surface. Collibra owns deep enterprise governance suites built over ten years; we’re lighter, design-time, contract-native, and free.
vs Gable.ai / Datatera / Schemata (data-contract specialists)
| Kirimana | Gable.ai | Datatera | Schemata | |
|---|---|---|---|---|
| Category | Data contract platform | Contract validator | Contract validator | Contract validator |
| Open source | ✓ Apache-2.0 | ✗ | ✗ | ✗ |
| End-to-end (author, apply, audit, migrate) | ✓ | partial | partial | ✗ validation only |
| Mandatory ownership | ✓ | partial | partial | ✗ |
| Fail-closed authoring guardrails | ✓ | partial | partial | ✗ |
| PR-time linting | ✓ | ✓ | ✓ | ✓ |
| Catalog pass-through (Unity / Purview / Horizon) | ✓ | partial | partial | partial |
| Federated library | ✓ three transports · fail-closed health | ✗ | ✗ | ✗ |
| MCP for AI assistants | ✓ | ✗ | ✗ | ✗ |
| Migration as a verb set | ✓ | ✗ | ✗ | ✗ |
How we differ: the contract specialists validate. We operationalise. Gable raised on the contract-validation thesis; Kirimana is a superset that adds apply, audit, federation, migration verbs, and a typed lifecycle — running on top of ODCS v3 as the canonical standard.
vs Unity Catalog / Microsoft Purview / Snowflake Horizon (vendor-native governance)
| Kirimana | Unity Catalog | Microsoft Purview | Snowflake Horizon | |
|---|---|---|---|---|
| Category | Data contract platform | Vendor-native catalog | Vendor-native catalog | Vendor-native governance |
| Open source | ✓ Apache-2.0 | ✗ | ✗ | ✗ |
| Cloud posture | Databricks today; OSS edition on the roadmap | Databricks-only | Microsoft-only | Snowflake-only |
| Contract artefact (ODCS v3 on disk) | ✓ canonical | tags + lineage | tags + lineage | tags + lineage |
| Mandatory ownership enforced structurally | ✓ | ✗ | ✗ | ✗ |
| Contract state machine | ✓ | ✗ | ✗ | ✗ |
| Mandatory one-line Databricks audit (Kiri-correlated) | ✓ correlation id, kiri audit join | partial | ✗ | ✗ |
| Column-level lineage from contracts | ✓ generated | scan-based | scan-based | scan-based |
| Compliance evidence generators | roadmap | ✗ | partial (Compliance Manager) | ✗ |
| Integration with Kirimana | n/a | reads UC metadata via API; pushes contract metadata into UC table comments / tags | reads Purview metadata; pushes tags | reads Horizon metadata; pushes tags |
How we differ: We integrate, we don’t replace. Concretely
for Unity Catalog: Kirimana reads UC metadata via the UC API,
pushes contract metadata into UC table comments and tags, and
operates as a layer above UC — not a replacement. For Databricks
teams, Kirimana attaches a correlation id to every Kiri-driven
action so kiri audit join produces a unified Kirimana + Databricks
audit timeline that UC alone cannot give you.
vs Monte Carlo / Soda / Bigeye (data observability)
| Kirimana | Monte Carlo | Soda | Bigeye | |
|---|---|---|---|---|
| Category | Contract platform | Observability | Observability + tests | Observability |
| Open source | ✓ | ✗ | partial | ✗ |
| Reactive detection | partial (DQX / GX integration) | ✓ | ✓ | ✓ |
| Contract-driven monitoring | ✓ | ✗ | partial | ✗ |
| PR-time governance gates | ✓ | ✗ | ✗ | ✗ |
How we differ: observability vendors detect when something is wrong. Kirimana prevents what shouldn’t be allowed (via the contract + PR-time linter + fail-closed authoring) and records what has to happen (via the mandatory Databricks audit). Adjacent, not competing — run both.
vs TimeXtender / BimlFlex / VaultSpeed (data warehouse automation)
These tools accelerate pipeline construction through metadata-driven code generation. They are not data contract platforms. Kirimana does both: it generates deterministic, content-hash-verified pipeline code and holds the contracts that govern it.
| Kirimana | TimeXtender | BimlFlex | VaultSpeed | |
|---|---|---|---|---|
| Category | Contract platform + code generation | Pipeline automation | DW code generation | Data Vault automation |
| Open source | ✓ Apache-2.0 | ✗ | ✗ | ✗ |
| Data contract standard (ODCS v3) | ✓ canonical | ✗ | ✗ | ✗ |
| Deterministic code generation | ✓ content-hash verified | ✓ | ✓ | ✓ |
| Technique-neutral build path (Flat / DV2.0 / Kimball silver → same gold) | ✓ Semantic Intent Model | partial | partial | ✗ |
| Production Data Vault silver | ✓ raw vault / business vault / PIT-bridge / DataVault4dbt backend | partial | ✓ DV2.0 native | ✓ DV2.0 specialist |
| Mandatory ownership | ✓ | ✗ | ✗ | ✗ |
| Fail-closed authoring guardrails | ✓ | ✗ | ✗ | ✗ |
| Contract state machine | ✓ | ✗ | ✗ | ✗ |
| PR-time governance linting | ✓ | ✗ | schema validation only | ✗ |
| Column-level lineage | ✓ contract-declared | ✗ | ✗ | ✗ |
| Guided source-schema introspection (Databricks today) | ✓ | ✗ | ✗ | ✗ |
| Migration as a verb set | ✓ translate · parity · cutover · KEEP/DROP/MERGE/REDESIGN | ✗ | partial (manual) | ✗ |
| Pricing | Free (Apache-2.0) | contact sales | $$$ per developer seat | usage-based |
How they differ from Kirimana:
TimeXtender, BimlFlex, and VaultSpeed answer “how do I build pipelines faster?” Kirimana answers both that question and “what is the data, who owns it, what is the audit trail, and how do I migrate off the legacy model?”
TimeXtender generates and orchestrates pipelines on Azure and Snowflake. It recently added an MCP server that exposes its semantic layer to AI agents — that is advisory, not enforced. There is no ODCS contract artefact, no mandatory ownership enforcement, no fail-closed authoring guardrails. Concurrent development by multiple engineers is a known weak point.
BimlFlex generates native SQL, ADF pipelines, and dbt models from a metadata store — no proprietary runtime. It handles Data Vault 2.0 patterns well. It stops at the build artefact: no producer/consumer contracts, no contract state machine, no migration verb set. Teams looking for an Apache-2.0 replacement can scaffold ODCS contracts from an existing Databricks warehouse via guided source-schema introspection and adopt the Kirimana core incrementally.
VaultSpeed is a Data Vault 2.0 specialist with deterministic SQL and dbt generation from an active metadata layer — canvas-based modelling, CDC, schema drift, late-arriving data. Kirimana covers the same Data Vault patterns natively (raw vault, business vault, PIT-bridge, DataVault4dbt backend) and adds the full contract governance layer on top: mandatory ownership, fail-closed authoring, column-level lineage, federation, and migration verbs.
Where the DWA tools are the right call and Kirimana is not:
- You need drag-and-drop pipeline authoring for non-engineering stakeholders → TimeXtender.
- You’re a Microsoft-stack DW team generating ADF / Synapse code today and not yet ready to migrate → BimlFlex (but plan the migration).
- You need a Data Vault specialist tool with canvas modelling and your team already knows DV2.0 cold → VaultSpeed.
Where Kirimana replaces or extends them:
All three stop at the build artefact. Kirimana adds: the contract as a first-class governance artefact, mandatory ownership, fail-closed authoring guardrails, column-level lineage, federation, and a migration verb set — on top of the same deterministic code generation they provide. For teams already on BimlFlex, guided source-schema introspection provides a bottom-up scaffold so the existing Databricks warehouse can come under contract governance without a rebuild.
Where Kirimana might not be right for you
- You need a procurement-ready governance suite this quarter. We’re v0.9 private preview. Run Collibra or Alation now and revisit Kirimana at v1.0.
- You want catalog UX polish first. Atlan and DataHub still win on UX. Run Kirimana + Atlan (or + DataHub) together via the push adapter.
- You’re a 1-engineer prototype. Use dbt-core directly. Add Kirimana when contracts start mattering, usually around team-size 5+.
- You only need transformation orchestration. dbt-core (free) or dbt Cloud is enough. Don’t pay for a contract layer you won’t use.
- You only need observability. Run Soda or Monte Carlo alongside Kirimana, not instead.
- You need graphical drag-and-drop pipeline authoring. TimeXtender wins there. Kirimana is code-first and git-native.
Where Kirimana is the right call
- Data engineering and data architecture teams that already
live in
dbt, git, CI, and the CLI — and want the contract layer their stack is missing. - Mid-size to enterprise data teams that need contracts to matter, not just be paperwork.
- Databricks platform teams that want governance to move left into PR and CI, with mandatory action-level audit underneath.
- Teams migrating off BimlFlex or TimeXtender that want an Apache-2.0 replacement with a structured migration verb set (translate · parity · cutover · KEEP/DROP/MERGE/REDESIGN).
- OSS-first organisations evaluating the path in advance of GA.
- Public sector + sovereignty-critical buyers that can’t put governance on a US-vendor SaaS. Classification, audit, and the migration verb set are designed for regulated Swedish and European public-sector needs.
- Teams with an existing Databricks warehouse who want to add governance without rebuilding: guided source-schema introspection scaffolds contracts from the live warehouse.
Compliance evidence generators (DORA / EU AI Act / GDPR) are on the roadmap. When they ship, the outputs will be structured evidence artefacts, not legal certification — human attestation and review by qualified personnel remain part of every regulatory framework we cover.
Talk to Kiri
Kiri can answer specific comparison questions — for example “how does the migration verb set compare to a manual KEEP/DROP review?” or “would DataHub + Kirimana give me both the runtime catalog and the design-time contracts?” Ask: /chat.