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.

A typical CI sequence:

kiri apply --target test
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.

Related quality surfaces

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