Solutions

Two ways to run Kirimana.

Kirimana ships as one Apache-2.0 codebase with two clear product paths. Pick Kirimana for Databricks when Databricks is your operating platform. Pick Kirimana OSS Edition when you want the prescribed open-source path from source ingestion to governed data products.

Choose this if

You already run Databricks

Keep Unity Catalog, Workflows, Delta Lake, Genie, and Databricks operational patterns. Kirimana adds the contract lifecycle, AI-policy gate, lineage, compliance evidence, and PR-time governance on top.

Choose this if

You want the OSS reference stack

A prescribed open-source path alongside the Databricks flagship — same ODCS-v3 contracts, same Kiri, same audit posture. The component stack is on the roadmap; we'll share specifics once the first design-partner deployment is exercised end-to-end.

Private Preview ★ Most mature

Kirimana for Databricks

Databricks Lakehouse + Unity Catalog + Workflows

AI gates Databricks alone can't enforce

Per-contract classification blocks every LLM call (Databricks AI Assistants included) from touching restricted data. Workspace ACLs don't get this granular.
Unity Catalog stays, backed by a contract source of truth

Owner, classification, lineage pushed bidirectionally. UC keeps its UX; Kirimana is the artefact your auditor reads.
DORA / EU AI Act / GDPR, generated, not assembled

Reports synthesised from contract metadata + audit log. The audit takes minutes, not weeks.

See full comparison

Private Preview

Kirimana OSS Edition

OSS edition · on the roadmap

One prescribed open-source path

Kirimana OSS Edition is the prescribed open-source path alongside the Databricks flagship. Stack components will be shared publicly when the first design-partner deployment is exercised end-to-end.
Same audit posture

Mandatory one-line audit per Kiri action, fail-closed authoring guardrails, federation with fail-closed health — every Implemented capability on the Databricks flagship is in scope for the OSS path too.
Same contract format

ODCS v3 stays canonical regardless of which path runs underneath — the contract format does not change between Databricks today and the OSS edition tomorrow.

See full comparison

Detailed view

Same governance model, different operating surface.

Databricks-native path

Kirimana for Databricks

For teams already standardized on Databricks Lakehouse, Unity Catalog, and Workflows. Kirimana becomes the contract lifecycle and audit layer above the Databricks primitives you already operate.

Databricks remains the operating platform. Kirimana makes the data product lifecycle governed, AI-readable, auditable, and repeatable.

What runs underneath

Delta Lake bronze, silver, and gold generation — target-based, technique-neutral
Unity Catalog pass-through for owners, classification, lineage, and contract versions
Databricks Workflows DAGs compiled from contract state
Databricks Secret Scopes for vault resolution
One-line Databricks audit per Kiri action — CLI and MCP audited identically
Databricks-first setup wizard and deployment runbooks

Best fit

Existing Databricks platform teams
Teams that want governance to move left into PR and CI
Teams that want to increase Unity Catalog and Workflows usage with contract context
Organisations migrating legacy data models into Databricks

Read the full solution

Open-source end-to-end path

Kirimana OSS Edition

A prescribed open-source path alongside the Databricks flagship. ODCS v3 stays canonical; the same Kiri, the same audit posture, the same Implemented capability surface — running on an open-source operating layer instead of Databricks.

Kirimana OSS Edition is on the roadmap. Watch this page — we'll publish the component stack and a design-partner programme once the first deployment is exercised end-to-end.

What runs underneath

ODCS v3 contracts on disk — identical to the Databricks path
Same Kiri, same fail-closed authoring guardrails, same federation contract
Component stack on the roadmap; specifics published once the first design-partner deployment runs end-to-end
Not generally available today — the Databricks path is the supported route

Best fit

OSS-first organisations evaluating the path in advance of GA
Public sector and regulated teams seeking platform sovereignty
Enterprise architects who want a portable contract format from day one

Read the full solution

Decision matrix

The quick rule.

The commercial model is the same for both: the product is open source; paid work is installation, enablement, migration, training, and regulated-industry implementation assistance.

Question	Databricks	OSS Edition
Primary platform	Databricks Lakehouse	Open-source stack · on the roadmap
Orchestration	Databricks Workflows	On the roadmap
Catalog	Unity Catalog	On the roadmap
Policy enforcement	Unity Catalog + Kirimana authoring guardrails	On the roadmap
Table format	Delta Lake	On the roadmap
Transformation	dbt-databricks or native Databricks jobs	On the roadmap
Audit	One-line audit per Kiri action — CLI + MCP identical	Same posture on the OSS path
Status	Private preview · design-partner pilots	Roadmap · not generally available
Best first move	Wire Kirimana into existing Databricks governance	Request early access to be a design partner

Need a runtime outside these two paths?

Keep Kirimana OSS Edition narrow for first install. Use the custom adapter architecture when there is a real platform requirement after the contract lifecycle is proven.

Read adapter architecture