Skip to main content
Private Preview·Early access by invitation.Request access →
Kirimana.
Maturity & honesty

What's shipped, what's coming.

Kirimana is in private beta, v1.0.0-beta.1 (invitation-gated) — last updated 5 July 2026. The list below is the capability surface that lives in the code today, runs in design-partner pilots, and we'd let you run with on a Databricks Lakehouse under early-access supervision.

Anything not on this page is not yet ready to be on this page. When something promotes from "in design" to "in code, exercised in CI" we move it up. We'd rather be modest here and exceed the bar than the other way round.

Shipped today

Live in the code, exercised in CI, run by design partners on Databricks.

Project lifecycle & guardrails

  • Guided, fail-closed project bootstrap

    `kiri project init` cannot leave the project in an invalid state. Every required choice — name, target, classification posture — is checked before write.

  • Fail-closed authoring guardrails

    Inferred PII (names, e-mails, free-text identifiers, classified attributes) cannot be authored as `public` without an audited override and a reason. The default is refuse, not warn.

  • Canonical scheduling contract

    `kiri.schedule` is the single canonical scheduling customProperty. Cron expressions with nested `schedule.*` routing — one declaration drives ingestion, transformation, and orchestration on the same cadence without separate scheduler config.

  • Holiday-aware business-calendar scheduling

    `kiri.schedule` understands `helgfria vardagar` and equivalent — Swedish business days, EU holidays, custom calendars per project. "Ready by 06:00 Europe/Stockholm on the next business day" is a one-line declaration.

  • Canonical lifecycle state and URN namespace

    Every artefact (contract, table, job, audit row) is addressed by a stable URN; `kiri.lifecycle.state` is the canonical state field across the platform. One namespace across CLI, MCP, federation, and audit — no per-surface dialect drift.

  • Generated project documentation

    Lineage and data-model docs materialise as Markdown + Mermaid inside the repo on `kiri docs generate`. `kiri docs verify-generated` is a CI gate — if the docs drift from the contracts the build fails.

  • One-command project health — `kiri doctor`

    One command answers "is my project healthy, and what do I fix first?" It composes the existing checks — contracts, modeling technique, layer contracts, sources, fixtures, and adapter health against a reachable target — into one ranked punch-list. Findings sort by severity then layer (bronze → silver → gold); each carries a fix hint and, where the fix is a Kirimana command, a copy-pasteable one. `--format json` and a non-zero exit on any error make it a single CI health gate; unreachable-target checks are skipped, never failed. Day-2 triage collapses from knowing a dozen commands to one.

Build and generate — the data path

  • Semantic Intent Model · technique-neutral goal coverage

    A business outcome resolves to columns regardless of whether the silver layer is Flat, Data Vault 2.0, or conformed Kimball. The intent layer is the join.

  • Target-based silver and gold

    Customer vocabulary first. The contract names the target (a column, a metric, an entity); the generator picks the source projection. No silver-table-name in business prose.

  • Conformed Kimball silver

    Silver as a conformed dimensional layer is one of the three first-class silver techniques — alongside Flat and Data Vault 2.0. All three feed the same gold contract.

  • Kimball-target-native gold generator

    Gold compiles to a Kimball star schema regardless of silver technique. Slowly-changing dimensions, conformed facts, surrogate keys — first-class outputs.

  • Computed gold columns

    Declarative `CASE` / type-cast / normalisation as a contract property. No SQL strings hand-written; every projection is contract-declared and versioned.

  • Multi-locale gold view twins

    One gold contract, parallel per-locale views. Swedish + English analytics off the same star schema; per-table opt-in so localisation is scoped where it matters. Nordic teams get bilingual BI without maintaining two models.

  • Named silver zones

    Silver splits into standard / curated / conformed zones with governed transitions between them. Beyond raw + business — silver has room for the intermediate shapes brownfield estates actually build.

  • Bilingual catalog annotations

    Every table + column can carry a description in both Swedish and English. AI agents, catalogs, and BI tools read whichever fits — one contract, both languages.

  • Production Data Vault silver

    Raw vault + business vault + PIT bridges as a production technique. Optional DataVault4dbt backend wired in via the same contract — pick the engine, the contract stays canonical.

Sources and ingestion

  • Guided source-schema introspection

    Sample, classify, and propose populated bronze contracts from a live source. The output is editable scaffolding, not auto-applied — humans approve.

  • Landing-zone storage primitive

    Every adapter ships with a typed landing-zone abstraction. Bronze writes go to a known address; lineage starts at the landing zone, not somewhere down the pipeline.

Catalogs and federation

  • Federation and catalog contract

    Cross-project catalog snapshots over three transports (in-process, HTTP+ETag, fs-static). `health()` returns OK / STALE / UNAVAILABLE; browse serves stale-with-marker; lint, apply and AI-policy all fail closed when a federated source isn't reachable.

  • Attribute review-state machine

    Every catalog attribute moves through a closed-menu review-state machine (new → in_progress → submitted → approved or rejected, with reopen back to in_progress) — discovery never self-approves. SME decisions are typed, auditable, and surfaced in the lint output — no informal review queue.

Adapters

  • Adapter-surface versioning and conformance

    Every adapter ships against a published surface contract; conformance tests gate the merge. Databricks is the flagship today; an OSS edition with a prescribed stack is on the roadmap.

  • AI-determinism boundary enforced in CI

    An architectural boundary separates AI-assisted code paths from deterministic codegen, enforced by an import-linter contract and architecture tests. The build fails if an AI module leaks into a deterministic surface — what gets generated is reproducible by construction.

  • Configurable customer-facing resource naming

    Volumes, jobs, schemas, and catalogs materialise under names you set — not names that hard-code Kirimana. Tier-0 de-branding is native, so enterprise estates keep their own conventions end-to-end.

  • Azure Service Principal as Databricks execution identity

    Databricks jobs run under an Azure AD service principal — least-privilege by construction, no token proliferation. Fits directly into estates that already govern SPs through Entra.

Audit

  • Mandatory one-line Databricks audit trail

    Every Kiri → Databricks action (CREATE / INSERT / SHOW / job submit / …) emits a one-line audit record. MCP calls are audited identically to CLI calls — same logger, same fields, same correlation id. `tail -f databricks-audit.log` is the whole demo.

  • Compliance evidence generators — DORA · EU AI Act · GDPR

    `kiri compliance report --framework dora|ai_act|gdpr` builds a structured evidence document from contract metadata + the audit log — JSON for GRC import, Markdown for humans — over a defined control set (DORA operational-resilience controls, EU AI Act high-risk controls, GDPR selected articles). Gaps are reported as `inconclusive`, never quietly passed; the DORA data-quality control uses the four-status taxonomy (`engine_ran` / `documentation_only` / `engine_none_configured` / `engine_not_applicable`). Structured evidence, not a legal opinion — every report says so, and human attestation by qualified personnel remains required. Broader control coverage and more frameworks are on the roadmap.

  • GDPR Art. 17 audit redaction — redact, don't delete

    `kiri audit redact` overwrites the prompt/response hashes for a trace with `[REDACTED]` and appends a redaction event (actor · reason · justification) rather than hard-deleting — the append-only audit invariant holds. Gated to platform-admin with a two-approver co-sign. The controlled exception that lets you honour an erasure request without breaking the audit trail.

AI access & the determinism boundary

  • One gateway for every AI call, audited

    Every AI call runs through a single gateway that records it — model, caller, classification, token counts, estimated cost, contract, and a trace id — on an append-only JSONL log. Prompts are hashed, not stored, so the audit is privacy-preserving. Rejections are recorded too, with the human-readable policy reason.

  • Classification gate before the call

    The gate runs pre-flight: a call that would send `restricted` data to the model is refused before it leaves, and the refusal is audited. `public` / `internal` / `confidential` pass by default; `restricted` is blocked unless explicitly allowed. Provider selection is configuration-driven — the audit and the gate hold identically whichever model you point it at.

  • AI query gate — allowed / gated / forbidden

    Before a natural-language question runs, the query gate parses the SQL, resolves each table to its contract and each column to its classification and PII metadata, and returns `allowed` / `gated` / `forbidden`. Restricted data is gated *before* the query executes. It's a decision gate — the caller (e.g. Databricks Genie via the `evaluate_query` MCP tool) honours the verdict; it does not silently rewrite your data.

  • AI barred from the generation pipeline

    AI is architecturally forbidden inside `plan` / `apply` / `verify`, DDL planning, diff, and validation — enforced by a CI import-path check that fails the build if an AI module leaks in. AI proposes; deterministic code disposes. What ships is reproducible by construction.

Migration workflow

  • Dual-flow bronze backfill

    Historical seed and continuous stream share the same bronze contract. Backfill from a legacy warehouse once, then let the continuous flow take over — no bespoke landing job, no schema divergence between the two paths.

  • Verbatim source-name fidelity

    Migrated bronze and silver objects keep the source name — no `__` prefix noise. Reconciliation against the legacy estate stays visual: what was `dim_customer` there is `dim_customer` here.

  • AI-assisted translation with mandatory review queue

    AI translates legacy business-vault objects into ODCS contracts; every output lands on a review queue with `accept` / `reject` as the only ways forward. Nothing reaches a contract without an SME signature.

  • Parity-testing harness

    AI-translated output is row-hash-compared against a deterministic baseline. Input snapshots are pinned, the row-hash algorithm is closed-menu, mismatches block promotion. Parity is the gate, not a report.

  • Cutover lifecycle as first-class verbs

    `kiri cutover shadow` / `diff` / `promote` / `rollback`. Shadow builds are namespace-isolated; promotes are atomic and rename-based; rollback is one verb, not a runbook.

  • Quarantine reprocess as a supported workflow

    Re-ingestion goes through the same DQ pipeline that rejected the row. The reprocess table is append-only; the per-row state machine is four states with a closed-menu of transitions — no silent quarantine rotting.

  • Migration simplification: KEEP / DROP / MERGE / REDESIGN

    The review queue gets three new SME decisions next to `accept`/`reject`: `drop` (legacy object isn't migrated), `merge` (collapse into a downstream object), `redesign` (rebuild rather than translate). A project-level flag flips the default action — burden of proof becomes "why migrate this?" instead of "why drop it?".

On the roadmap

Direction of travel, no promises. We share specifics with design-partners; on the public site we share the shape.

  • Capabilities in design and active development

    Several surfaces are live in design-partner private beta but haven't crossed our "implemented in code, exercised in CI" bar. We don't list them by name on this page — when they cross the bar they move into the section above. Watch the changelog if you need to track that closely.

  • OSS edition

    A prescribed end-to-end open-source stack alongside the Databricks flagship is on the roadmap. We won't share the component list publicly until at least one path is exercised end-to-end with a design partner.

  • Managed Kirimana SaaS

    Not an active workstream. The source-available self-host path (FSL-1.1) is the only one we operate today.

When we'll call something v1.0.

We're not in a hurry to put a "1.0" label on a number. Here's the bar we'd want cleared before we did:

  • Public GitHub organisation, source open, issues open. Going public is in progress.
  • Foundation engagement on a neutral home for the project (LF AI & Data is the direction we lean). Planning stage.
  • At least two to three named design-partner deployments running governance in production on a Databricks Lakehouse.
  • SOC 2 Type I in hand. Targeted ahead of any first paid offering.
  • An open-data-contract extension for AI policy accepted upstream. We're contributing the proposal; acceptance by the working group is the gate.

If you need governance in production this quarter on a non-Databricks platform, Kirimana isn't ready for you yet. We'd rather you know that than discover it three months in. Request early access if you want to be a design partner — that's the only door today.