CLI · Data quality

Quality in Kirimana is contract-declared: invariants and SLAs live in the contract YAML, and every run leaves evidence behind.

kiri invariants

Evaluate declared business-rule invariants against the live target.

Usage: kiri invariants check [OPTIONS]

Flag	Description	Default
`--project`, `-p`	Project directory
`--target`, `-t`	Target alias from `kiri.yml::targets`
`--severity`	Which invariant severities to evaluate: `error` \| `warn` \| `drop` \| `all`	`all`
`--format`	`text` \| `json`	`text`
`--strict`	Exit 1 when `warn`-severity invariants breach	off

Invariants carry a severity in the contract: error fails the run, warn reports, drop quarantines offending rows. --strict promotes warnings to a CI-failing signal.

kiri quality

Quality-engine evidence collection.

Usage: kiri quality collect-evidence [OPTIONS]

Flag	Description	Default
`--target-dir`, `-t`	The dbt project’s `target/` directory — the collector reads `run_results.json` + `manifest.json` from here (required)
`--project`, `-p`	Kirimana project root	`$KIRIMANA_PROJECT` or CWD
`--out`, `-o`	JSONL evidence file	`<project>/.kirimana/quality_engine/evidence.jsonl`

collect-evidence converts a dbt-test run into per-contract quality evidence. Each contract’s evidence records which quality engine ran and what it found, using a four-status taxonomy:

Status	Meaning
`engine_ran`	A quality engine executed checks for this contract and results were captured
`documentation_only`	Quality expectations are documented in the contract but no engine executed them this run
`engine_none_configured`	The contract declares checks but no quality engine is configured to run them
`engine_not_applicable`	No quality checks apply to this contract

The evidence JSONL is the input for the DORA data-quality control (DORA-DQ-1) in kiri compliance report (see the governance page), and is also written by kiri silver conformance --out. That report also generates DORA, EU AI Act, and GDPR evidence over a defined control set; broader control coverage and more frameworks are on the roadmap.

kiri quality report

Run every contract’s column rules against the target and report pass rates by quality dimension.

Usage: kiri quality report [OPTIONS]

Flag	Description	Default
`--project`, `-p`	Project directory	`$KIRIMANA_PROJECT`, nearest `kiri.yml`, or the active project
`--target`	Target profile from `kiri.yml`	project’s `default_target`
`--json`	Emit JSON instead of a table	off
`--write-evidence`	Append one evidence row per contract to `.kirimana/quality_engine/evidence.jsonl`, which `kiri sla check` reads for `kiri.sla.quality_threshold`	off

Column rules are declared on the contract — not_null, accepted values, ranges, patterns, uniqueness — and execute on your Databricks tables. Every check is classified against a closed menu of seven dimensions: accuracy, completeness, consistency, integrity, timeliness, uniqueness, validity. A rule that cannot be evaluated reports skipped; it never counts as a pass.

kiri quality rejects

A rule marked on_violation: reject turns kiri apply into a gate: every violating row is captured into a rejects table (<source_schema>_rejects) with the full row, the rule it broke, and the run that caught it — before it reaches downstream layers. These commands work that table.

Command	What it does
`kiri quality rejects status --schema … --table …`	Summarise rejects by check, dimension, and run
`kiri quality rejects list --schema … --table …`	Print rejected rows, leading with the value that broke the rule (`--check`, `--limit`, `--full-payload`)
`kiri quality rejects submit … --reject-id … --payload … --reason … --principal …`	Stage a correction for one rejected row. `--payload` is the corrected row as JSON, or `@file`
`kiri quality rejects reprocess … --reject-id …`	Append the staged correction to bronze
`kiri quality rejects abandon … --reject-id … --reason … --principal …`	Stop trying to fix a row, on the record

A correction is a new bronze arrival that records which rejected row it fixes — history is never edited in place. The next apply re-runs the rules on it, and every row ends resolved, rejected again, or abandoned. Only principals listed in the contract’s quality.column_rules.reprocess_principals can submit or abandon, and every transition is audited before it takes effect.

A typical CI sequence:

kiri apply --target test            # column-rule gate runs here
kiri quality report --target test --write-evidence
kiri quality collect-evidence --target-dir dbt/target
kiri invariants check --target test --strict --format json

kiri sla

Data SLA enforcement — check declared freshness/availability SLAs and dispatch breaches.

Usage: kiri sla check [OPTIONS]

Flag	Description	Default
`--project`, `-p`	Project root
`--target`	Environment target	project’s `default_target`
`--contract`	Check only this contract (by name)
`--dry-run`	Don’t dispatch breaches; print what would happen	off

SLA declarations live on the contract. When a breach is found and the project has an incidents: block configured, the breach is routed to the configured ITSM dispatcher (see kiri incident on the platform-ops page); --dry-run previews the dispatch without firing it.

Data Vault silver quality — kiri dv quality run executes the versioned DV check catalogue (DV-001, …) with gating (--gate) and exclusions; kiri dv test runs DV invariants offline against CSV fixtures. Documented on the silver page.
Referential integrity — kiri fk gate probes declared foreign keys live; structural findings (FK-003 dangling parent, FK-004 self-cycle) are hard FAILs that cannot be suppressed. Documented on the silver page.
Technique conformance — kiri silver conformance runs the technique-appropriate conformance suite and writes its findings into the same evidence JSONL.
Test drafting — kiri suggest tests drafts dbt-core data tests from a bronze table’s shape and a reporting goal’s KPIs. Documented on the gold page.