Why Kirimana
The problem
Data contracts shouldn’t be click-through. But for most teams, they are: a YAML file nobody reads, a SLA nobody enforces, a classification flag nobody honors. The catalog tool says “owner: unknown”. The AI assistant queries restricted data because nothing gates it. The compliance audit happens once a year and nobody remembers what was decided in March.
We borrowed kirimana — Māori for contract, literally “where your mana shows” — because it captured the meaning English doesn’t have a word for. Mana is honor staked, not claimed. We’re trying to make data agreements feel that weighty again.
The thesis
Make the contract operational. Make ownership mandatory. Make AI policy enforceable, not advisory. Make compliance a generator, not a project. Do all of it in open source so any team can adopt it.
What we do that others don’t
1. Mandatory ownership
Every contract names a real human. Every schema property names a
classification. The platform won’t apply a contract that doesn’t.
No more owner: unknown.
2. AI-policy enforcement at the gate
Every LLM call goes through a policy gate. The gate reads the classification on the contract. Restricted data never reaches the model. Every call is logged — prompt, response, cost, caller.
3. Multi-platform — for real
The same ODCS contract runs on Databricks Lakehouse, Fabric, Trino + Iceberg, DuckDB, Postgres. The platform adapter is ~400 lines. Adding a new platform is a weekend, not a roadmap item.
4. PR-time linting, not post-hoc audit
Every contract change is linted in CI before merge — classification present, owner valid, lineage resolves, AI policy parses. The governance moves left, into the developer’s flow.
5. Compliance generators built in
DORA, EU AI Act, GDPR — the reports generate from the contract metadata + audit log. The work was done all along; the report is the proof.
6. Federated contract library
Community-curated contracts you can install and extend. Customer 360 patterns, FHIR healthcare bundles, public-sector reference data. You don’t start from zero, ever.
How we compare
| Kirimana | Atlan / Collibra / Alation | dbt Cloud | Gable.ai / Datatera | Unity Catalog / Purview | |
|---|---|---|---|---|---|
| Data contract platform | ✓ end-to-end | Catalog-first | Transformation-first | Validation-only | Vendor-native |
| Open source | ✓ Apache-2.0 | ✗ | Engine OSS | ✗ | ✗ |
| AI-native (not bolted on) | ✓ | Bolted on | ✗ | Partial | Vendor-locked |
| Multi-platform | ✓ | Partial | dbt-only | Limited | ✗ |
| AI-policy enforcement | ✓ classification-gated | Manual | ✗ | Partial | ✗ |
| DORA / GDPR generators | ✓ built-in | Add-on | ✗ | ✗ | ✗ |
| Audit-clean by default | ✓ every call logged | Configurable | Limited | Limited | Configurable |
Where the contract becomes operational
Where Atlan stops at the catalog and dbt stops at transformation, Kirimana operationalises the contract. From draft → apply → audit → compliance report, all in one Apache-2.0 codebase.
Try it
- Talk to Kiri — ask any of the above to the AI assistant
- See the editions — Databricks, Fabric, Enterprise OSS
- Read the install guide — local DuckDB to multi-cloud
- GitHub — read the source