Standards + integrations
Kirimana stands on open standards. The product has two clear paths:
Databricks-native and Kirimana OSS Edition. Kirimana OSS Edition uses one prescribed
end-to-end stack; custom integrations live behind the adapter
architecture, not in the first-install decision.
| Standard | What we use it for |
|---|
| ODCS v3 (Open Data Contract Standard) | Canonical contract format. Extended via documented kirimana.* customProperties namespaces. |
| Apache Iceberg | Kirimana OSS Edition table format for the OSS path. |
| Apache Polaris (incubating) | Kirimana OSS Edition Iceberg metadata catalog. Bidirectional sync. |
| OpenLineage | Lineage emission from apply and ingestion. |
| OAuth 2.0 / OIDC | Auth + SSO delegation across providers. |
Frameworks we wrap or extend
| Framework | What we do with it |
|---|
| dbt-core | Kirimana OSS Edition transformation framework. We wrap dbt-core; we don’t replace it. |
| Apache Ranger | Kirimana OSS Edition policy framework. Pushes contract classification into row/column policies. |
| Apache Airflow | Kirimana OSS Edition orchestration framework. Kirimana compiles contract intent into DAGs. |
| Great Expectations | Data quality framework backing the quality layer. |
Source-system integrations (ingest)
| Integration | Default? | Notes |
|---|
| Airbyte | ✓ Kirimana OSS Edition default | Primary ingest backend in the OSS path |
| Databricks-native ingestion | ✓ Databricks path | Existing Databricks jobs and platform ingestion patterns stay in place |
| Confluent Schema Registry | ✓ supported | Streaming schema discovery |
| AWS Glue | ✓ supported | Schema registry for AWS-native sources |
Catalog integrations (pass-through, not replacement)
Critical positioning: Kirimana is not a catalog
replacement. We are a contract layer that pushes truth to
whatever catalog the customer prefers. The catalog stays the
user-facing metadata surface; Kirimana is the source of contract
truth feeding it.
| Catalog | Mode | Product path |
|---|
| Databricks Unity Catalog | push + pull | Primary for Kirimana for Databricks |
| Apache Polaris (incubating) | push + pull | Primary for Kirimana OSS Edition |
| Apache Ranger | push | Kirimana OSS Edition policy target |
| Atlan / Collibra / Alation | adapter shelf | Available via custom adapter / Pro Services |
AI integrations
| Integration | What it is |
|---|
| Anthropic Claude | Primary LLM via the AI gateway. Always uses prompt caching. |
| Azure OpenAI | Routed via AI gateway for Microsoft-stack tenants. |
| AWS Bedrock | Claude / Llama / others via the gateway. |
| Ollama | Local / air-gapped LLM provider. |
| Databricks AI Assistants | MCP server lets the AI assistants read contracts, classifications, lineage, AI policy, release status, all gated by the same classification rules. |
| External AI assistants via MCP | Claude.ai, Cursor, Continue.dev, Cline, read Kirimana via the same MCP server. |
| Anthropic prompt caching | Always-on for Kiri prompts and AI gateway calls. |
DevOps + GitHub
| Integration | What it is |
|---|
| GitHub | Federated contract library backend (storage in repo, discovery on website, engagement via Stars/Forks/Issues). |
| GitHub Actions | PR-time contract lint, two-approver gate for redaction events, schema-drift detection. |
| CODEOWNERS | Wired into the contract-approval workflow. |
| Conventional commits + SemVer | The release plan / apply / verify lifecycle stamps releases against the git SHA. |
Incident + ITSM dispatch
| Integration | Mode | Dedup key |
|---|
| Jira | REST v3 | custom-field source_id |
| ServiceNow | Table API | correlation_id |
| Zendesk | REST v2 | external_id |
| Generic webhook | POST + signed headers | source_id |
The detection layer routes apply-failures, SLA breaches,
schema-drift, and health events through the dispatcher.
Communication
| Integration | What it is |
|---|
| Slack | Bot for governance queries, “who owns customer.yml?”, “what’s the AI policy on silver.payments?”, “show me the latest apply for domain X”. Read-only bot; mutating actions go through the Streamlit UI. |
| Microsoft Teams | Same surface as Slack via the bot’s adapter. |
Auth
| Provider | Mode |
|---|
| OIDC generic | Any OIDC IdP |
| GitHub | OAuth + OIDC |
| Microsoft Entra ID | OIDC for Microsoft tenants |
| Okta / Auth0 | OIDC |
The PR-time RBAC gate enforces capabilities per role
(.github/workflows/contract-approval.yml).
Vault / secret management
| Provider | Native? |
|---|
| Azure Key Vault | ✓ |
| AWS Secrets Manager | ✓ |
| GCP Secret Manager | ✓ |
| HashiCorp Vault | ✓ |
| Databricks Secret Scopes | ✓ |
| env-based (dev only) | ✓ |
All ${vault:...} references resolved by the active vault adapter.
CI fails on detected plaintext.
BI + semantic layer (export)
| Target | Mode |
|---|
| dbt Semantic Layer | export |
| MetricFlow | export |
| Cube | export |
| Power BI | connection guide |
| Tableau | connection guide |
| Qlik | connection guide |
Compliance generators
| Standard | Status |
|---|
| DORA (EU operational resilience) | built-in generator |
| EU AI Act | built-in generator |
| GDPR (Art. 17 redaction etc.) | built-in generator + redaction surface |
| SOC 2 | scoped via Pro Services |
| ISO 27001 | scoped via Pro Services |
Adapter shelf
These are not part of the Kirimana OSS Edition first-install path. They belong in
the custom adapter architecture and are scoped when a customer has a
real runtime or catalog requirement:
- Atlan / Collibra / Alation catalog push
- Snowflake Horizon advanced bidirectional sync
- Proprietary streaming sources
- Proprietary BI semantic layers (Looker, ThoughtSpot)
Want a new integration?
- Read the custom adapter architecture
- Open a GitHub Issue for an adapter request
- Use Pro Services when the integration is customer-specific