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.
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.
AI translates legacy business-vault objects into ODCS contracts. Every output lands on a review queue with KEEP / DROP / MERGE / REDESIGN as first-class SME decisions. A parity harness row-hash-checks AI output against a deterministic baseline. Cutover is shadow → diff → promote → rollback as first-class verbs.
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 dca.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,
Apache-2.0 forever. Compliance evidence generators (DORA, EU
AI Act, GDPR) are on the roadmap and ship before the first
paid offering.
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 LLM call (Anthropic, Azure OpenAI, Bedrock, Ollama, Databricks AI Assistants) is gated by per-contract classification. Restricted data never reaches the model.
Run Databricks-native or use the prescribed Kirimana OSS Edition path. Custom adapters are a separate architecture extension, not the default install story.
Compliance reports generate from contract metadata + audit log. The work was done all along; the report is the proof.
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.