Open-source data contracts for the AI era. Contracts on disk, audit on disk, lineage on disk — AI agents read your data platform without API calls or integration code. Kiri, the in-product AI assistant, turns business intent into contracts that hold. Built first for Databricks Lakehouse.
One contract, the whole medallion on Databricks — governed, audited, and answerable in Claude.
Kirimana is Māori for contract. But it carries something English splits into two words. A bond is the trust between people. A contract is the proof that survives them. Kirimana is the place a bond becomes a contract — your name on the surface, your mana behind it. That's the brand. That's also the architecture.
Mandatory. The platform refuses contracts that don't name a human. When the regulator asks who decided this — there's an answer.
Every Kiri → Databricks action emits a one-line audit record — CREATE, INSERT, SHOW, job submit, override. CLI and MCP audited identically. The audit trail is the operating posture, not a feature flag.
Guided source-schema introspection samples a live source, classifies columns, and proposes populated bronze contracts. Editable scaffolding, not auto-applied. Databricks today; other sources on the roadmap.
Contracts you write today are Open Data Contract Standard v3 YAML — readable by humans, by Kiri, by Claude Code or Cursor dropped into your repo. No proprietary catalogue. No lock-in by format.
Most data teams want to use AI on their data. They can't, safely. Their data lacks the governance AI needs to be trustworthy: ownership, classification, lineage, audit trails, contract-driven SLAs. That's Gartner Level 3-4 BI maturity, and it's a multi-quarter project for most teams.
Kirimana makes BI maturity automatic by making it structural:
You're not adding governance for AI. Your platform becomes AI-ready by construction from contract one.
Take the AI maturity light assessmentODCS contracts in git. Audit as JSONL. Lineage as a graph. Drop Claude Code or Cursor into your repo and the agent understands your data platform without an integration, an API call, or a permission ceremony. That's not AI-aware — that's AI-native.
Every AI surface speaks as Kiri: the UI, the CLI, and the docs chat above. She knows your operating model, your role, your contracts, and your audit history. She helps your team draft and review contracts, explains lineage, triages failed applies, and never invents numbers she can't substantiate.
CREATE, INSERT, SHOW, job submit, classification override — every Kiri → Databricks action emits a single audit record. CLI calls and MCP calls are audited identically with the same correlation id. `tail -f databricks-audit.log` is the entire demo; the regulator can read it without us being in the room.
Inferred PII cannot be authored as public without an audited override and a reason. `kiri project init` cannot leave the project in an invalid state. PR-time lint blocks contracts with missing owners, drift between docs and contracts, or unsigned classification changes. Default is refuse, not warn.
Classification-gated before it leaves — a call that would send restricted data to the model is refused, and the refusal is audited with its reason. Every call is logged: model, caller, classification, tokens, cost, contract, trace id, prompt hashed not stored. And the query gate checks a natural-language question before it runs, returning allowed / gated / forbidden. Databricks Genie integrates out of the box.
Most migrations move every legacy decision into the new platform. The customer's own words usually come out of the steering-group: we want to simplify, drop the stuff we don't need, redesign the dimensions we always regretted. Kirimana ships that as a first-class workflow — not a slide deck.
KEEP /
DROP /
MERGE /
REDESIGN as
first-class SME decisions. Nothing reaches a contract
without a signature.
kiri cutover shadow,
diff,
promote,
rollback. Shadow
builds are namespace-isolated; promotes are atomic and
rename-based; rollback is one verb, not a runbook.
Start in light mode:
single-approver, relaxed classification requirements, fast
onboarding. One flag in kiri.yml
scales you to enterprise mode
when you need it — two-approver gates, mandatory classification on
every property, full audit correlation. No tool switch, no migration.
And as the team grows: federated libraries with fail-closed
health, hub-and-spoke domains, audit-correlated trace ids,
source-available under FSL-1.1-ALv2 (converting to Apache-2.0
two years after each release). `kiri compliance report`
generates structured evidence for DORA, EU AI Act, and GDPR
from contract metadata and the audit log — evidence, not a
legal opinion, and honest about gaps.
Same contracts, same audit trail, same Kiri across both paths. The difference is the operating surface wired underneath. Kirimana for Databricks is the flagship today; Kirimana OSS Edition is on the roadmap.
Whether you choose Databricks or Kirimana OSS Edition, the governance model is the same. Six things both paths ship.
One open standard contract format. Extended via documented kirimana.* customProperties. Same artefact runs on both product paths.
Every AI call runs through one gateway that audits it — model, caller, classification, tokens, cost, contract, trace id — with prompts hashed, not stored. A call that would send restricted data is refused before it leaves, and the refusal is audited with its reason.
Run Databricks-native or use the prescribed Kirimana OSS Edition path. Custom adapters are a separate architecture extension, not the default install story.
`kiri compliance report` builds a structured evidence document from contract metadata + the audit log, over a defined control set. Structured evidence, not a legal opinion; gaps are reported as inconclusive, not passed.
Unity Catalog on Databricks today. Kirimana feeds the metadata surface; it doesn't replace it. OSS edition catalog targets are on the roadmap.
GitHub-backed marketplace for contracts. Submit a pack via PR; install from either product path. Patterns travel across organisations.