Skip to main content
Private Preview·Early access by invitation.Request access →
Kirimana.
Docs · CLI reference

CLI · Governance and RBAC

Governance is enforced from the contracts outward: classification and PII flags live on columns, policies live in the catalog, and CI gates make sure changes carry the right approvals.

kiri attr

Review-state workflow for catalog attributes (columns). Every column moves through new → in_progress → submitted → approved | rejected, mirroring a PR lifecycle. REF is always <asset_urn>#<column_name>.

  • kiri attr list [--state <s>] [--domain <d>] [--source <urn-substring>] [--limit 50] — list columns with their review state; --source helps triage “what did the last sync discover?”.
  • kiri attr show REF / kiri attr history REF — one column with its review history.
  • kiri attr edit REF [--classification public|internal|confidential|restricted] [--description <text>] — edit column metadata.
  • kiri attr submit REF — in_progress → submitted (the PR-open moment).
  • kiri attr approve REF — submitted → approved (PR-merge). kiri attr reject REF --reason <why> — reason is required for forensic clarity.
  • kiri attr reopen REF — approved/rejected → in_progress.
  • kiri attr detect-pii REF [--apply] — ask Kiri to classify PII on one column. Suggest-only by default — human review is the norm; --apply flips is_pii / pii_category / classification / masking_policy directly.

All verbs take --actor to override the actor identity recorded in the history (defaults to the environment).

kiri catalog

The project data catalog — governance, PII, and lineage over every asset.

Local catalog lifecycle

  • kiri catalog init — create an empty catalog database (default <project>/.kiri/catalog.sqlite).
  • kiri catalog import — populate it from project YAML, or from an NDJSON asset stream via --from-ndjson - (designed to chain with kiri catalog pull).
  • kiri catalog list [--type source|bronze|silver|gold|view|dashboard|job] [--domain] [--classification] [--certification draft|certified|deprecated|restricted] [--pii] — filtered asset listing.
  • kiri catalog search QUERY / kiri catalog show URN — search and full asset detail.
  • kiri catalog show-attribute NAME — trace where a column appears across the estate, case-insensitive.
  • kiri catalog lineage URN — immediate upstream and downstream of one asset.
  • kiri catalog pii-scan — every asset containing PII, with its categories.

External catalog sync

  • kiri catalog pull --target unity --catalog <name> [--schema <s>…] [--no-columns] [--no-tags] — pull metadata from Unity Catalog as NDJSON (one asset per line, stdout by default).
  • kiri catalog push --target unity|horizon|purview — push catalog rows to Unity Catalog, Snowflake Horizon, or Microsoft Purview. Dry-run by default: inspect the NDJSON write plan, then rerun with --no-dry-run to execute the annotation writes. --type / --urn filter the scope; --no-lineage skips lineage edges.
  • kiri catalog verify [--fail-on missing|stale|extra|all] — diff live catalog annotations against the local catalog; JSON report to --output.
  • kiri catalog migrate-annotations [--apply] — write store-only steward assignments back into the contracts that own them (kiri.governance.stewards), so a governance fact set only in the catalog store gets a home in git. Dry-run by default; --apply writes the patched contracts for you to commit through a pull request. Exits cleanly when nothing needs migrating.
  • kiri catalog publish --project-urn kirimana:project:<slug> --release-sha <sha> — build and atomically publish the federation export (default <project>/.kirimana/federation/export.json), pinned to a release SHA.

Access policies

kiri catalog policy manages principal-level access policies:

kiri catalog policy upsert bi_analysts --name "BI analysts" \
  --max-class internal --hide email --hide government_id --domain sales
kiri catalog policy list
kiri catalog policy show bi_analysts
kiri catalog policy delete bi_analysts

--max-class caps the classification a principal may see; --hide (repeatable) masks PII categories from a closed menu covering both ordinary and special-category PII; --allow-special-pii opts a principal into special categories; --domain whitelists domains (omit for all, pass --domain '' for none).

kiri rbac

RBAC administration plus CI-time gates.

  • kiri rbac emit-grants [--role analyst|data_engineer|auditor] [--zone raw|business|pit|all] [--catalog <c>] — emit silver-layer GRANT statements per role and zone, qualified by the resolved profile’s catalog.
  • kiri rbac gate-pr --submitter <identity> [--groups a,b] [--changed-files-from <file>] — gate a PR against authorship rules: who may touch which contracts, and whether classification raises to restricted (via --restricted-raises-from) need elevated approval. Reads changed paths from stdin by default; groups fall back to KIRIMANA_PR_GATE_GROUPS.

Related CI gates live on the contracts page: kiri contract approval-count and kiri contract codeowners.

kiri governance

  • kiri governance approval-count [--action <name>] [--list] — print the required approver count for a governed action (e.g. audit_log_redaction, catalog_push_live, contract_retirement). --list prints every supported action.

kiri audit

Audit-log operations over the JSONL audit trails.

  • kiri audit join [--apply-id <id> | --trace-id <id>] [--since 6h] — join Kirimana audit events with Databricks-delivered audit logs into one timeline. The Kirimana side carries the apply id on the apply-log row; the Databricks side carries it via the trace comment / Workflow tag map. --databricks-audit-dir points at the delivered audit JSON (production deploys sync it into <project>/logs/databricks-audit/).
  • kiri audit correlate --since <iso> --until <iso> — post-hoc correlation of AI-driven query traffic against the Databricks audit trail for the window, flagging BYPASS, STALE_GATE and forbidden-query findings. --dispatch routes findings above --severity-floor to the configured ITSM.
  • kiri audit redact --trace-id <id> --reason <enum> --justification <text> — redact a log row in place and append a redaction marker. Reasons are a closed enum: gdpr-art-17, data-residency, platform-rotation, legal-hold-release, operator-error. Auditors read the justification — be specific (e.g. “data subject request DR-2026-042”). Targets the AI audit log by default; --mcp-log or --incidents-log select the other trails.
  • kiri audit purge — intentionally not implemented. Hard-deleting audit rows destroys the evidence chain; use kiri audit redact.

kiri retention

Adapter-dispatched data retention.

Usage: kiri retention --auto [OPTIONS]

--auto is required: retention is a project-level sweep over every contract that declares kiri.retention.days — there is no per-table invocation. --layer bronze|silver|gold restricts the sweep; --dry-run previews exactly what each adapter would execute.

kiri compliance

Usage: kiri compliance report [OPTIONS]

--framework dora|ai_act|gdpr selects the framework; the report evaluates a defined control set (DORA operational-resilience controls, EU AI Act high-risk controls, GDPR selected articles) from contract metadata + the audit log, over a --period YYYY-MM-DD..YYYY-MM-DD window (default: last 365 days), as --format json (for GRC import) or markdown. Each control returns pass / fail / partial / inconclusive — gaps are surfaced as inconclusive, never quietly passed — and every report carries the disclaimer that it is structured evidence, not a legal opinion. --fail-on-fail exits non-zero when any control fails, to gate merges in CI. The DORA data-quality control (DORA-DQ-1) uses the four-status quality taxonomy (engine_ran, documentation_only, engine_none_configured, engine_not_applicable). Broader control coverage and additional frameworks are on the roadmap.

Updated 5 July 2026 · v1.0.0-beta.1