What's shipped, what's coming.

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

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.

`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.

`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.

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.

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

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.

`kiri onboard` writes a portable briefing of the CLI surface, the methodology, the installed skills and — optionally — a digest of your project, so the coding assistant you already use starts from how Kirimana actually works. `--agent` writes it into CLAUDE.md / AGENTS.md / Cursor rules inside a marker block it never lets clobber your own text.

Rules declared on a contract — not-null, accepted values, ranges, patterns, uniqueness — execute against your Databricks tables, not just in a local test. A rule that cannot be evaluated is reported as skipped, never as a silent pass.

Mark a rule `on_violation: reject` and every violating row is captured into a rejects table — the full row, the rule it broke and the run that caught it — before it can reach downstream layers. A retried apply never double-counts its own rejects; a new run records the row again, so "still broken on Tuesday" stays answerable.

`kiri quality rejects status | list | submit | reprocess | abandon`. A correction is a new bronze arrival that records which rejected row it fixes, so history is never edited in place. Each row ends resolved, rejected again, or abandoned on the record — and only allow-listed principals can move it.

`kiri quality report` runs a contract's rules and reports pass rates against a closed menu of seven quality dimensions — accuracy, completeness, consistency, integrity, timeliness, uniqueness and validity — so a quality score means the same thing on every contract.

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.

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.

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.

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

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

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.

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.

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.

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.

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

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.

A source can declare that its own columns define the bronze table — `ingestion.schema_source: declared` — so a JSON feed whose shape shifts between batches can no longer reshape the table or break a write. Opt-in per source; `kiri reload` replays already-landed raw files through the declaration to bring an existing table in line.

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.

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.

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.

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.

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.

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.

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.

`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.

`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.

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.

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.

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.

Point Kiri at Databricks Model Serving and every AI flow runs on models your workspace already serves — no AI-vendor account, no second credential, the workspace identity you use for `kiri apply`. A contract can say `egress: in_platform`: AI may run on your own data platform, never on a third-party API.

`kiri ai databricks status | plan | apply` configures the workspace's own AI Gateway — usage tracking, rate limits, PII and safety guardrails, payload logging, fallbacks — with a plan you review before anything changes. It refuses settings that would change a workspace-shared endpoint for other teams unless you say so explicitly, and `correlate` reconciles Kirimana's audit log with the gateway's own record.

`kiri ai check-policy ` asks exactly the question the gateway asks before an AI call — is inference allowed on this contract, with this provider? — and exits 0 or 1, so it works as a pre-commit hook or a pipeline gate. No prompt is sent.

Every audited AI call records how much input was served from the provider's cache and how much was written to it, and cost estimates price both at each model's own rate. "Caching is on" becomes a figure in the audit log, not a claim.

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.

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.

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.

`kiri migrate translate-tsql` translates stored-procedure and view logic with a rule-based dialect bridge — no AI in the loop, the same input always yields the same Spark SQL. `kiri migrate analyze` inventories the source first. Both are in the free CLI.

`kiri reconcile` compares the legacy and migrated tables from one frozen batch — row counts, key presence, null rates, date bounds, SCD2 effectivity, full-row fingerprints — in a locked mode that omits raw values. Business sign-off consumes a single-use approval token bound to that exact report.

Migration Pack: an add-on for design-partner migrations, not part of the free CLI. 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.

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.

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

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?".