CLI · Orchestration

Two declarative surfaces: pipelines/*.yml describe task DAGs that lower to Databricks Workflows, and flows/*.yml declare the scheduled flows that run them. Both are reconciled, never hand-synced.

kiri pipeline

Pipeline definitions compile through an intermediate representation (PipelineIR) before lowering to the platform.

• kiri pipeline validate — load and validate every pipelines/*.yml in the project.
• kiri pipeline plan --pipeline <name> [--target <t>] — show the task DAG plus the lowered Databricks job spec for one pipeline. --target is threaded into the kiri apply invocations the tasks perform.

kiri pipeline validate
kiri pipeline plan --pipeline nightly_core --target prod

Scoped orchestrator tasks pair with kiri apply --contract <c> --materialize / --domain <d> --materialize — the --materialize flag forces the dbt build on a scoped run so a scheduled single-contract task actually materialises instead of succeeding as a silent no-op (see the build page).

kiri flows

Scheduled-flow lifecycle. Flows are declared in flows/*.yml and reconciled against the target platform’s scheduler.

kiri flows sync

Reconcile flows/*.yml with the platform.

Usage: kiri flows sync [OPTIONS]

Flag	Description	Default
--target	Target environment from kiri.yml	dev
--flows-dir	Directory holding flows/*.yml	flows
--plan-only / --no-plan-only	Print the diff but don’t apply	off
--dry-run	Compile and print scheduled job specs without contacting the platform	off
--prune / --no-prune	Delete platform-side jobs not in YAML	off

--plan-only is the CI-review mode; --prune makes YAML fully authoritative — anything on the platform that isn’t declared gets removed.

Run and inspect

• kiri flows list [--target <t>] [--name-prefix <p>] — flows registered on the target’s scheduler. The prefix defaults to the project’s orchestration.job_name_prefix resolver.
• kiri flows trigger NAME [--target <t>] — fire the flow now, ad-hoc.
• kiri flows runs NAME [--window-days 30] [--limit 50] — recent runs from the automation run-history database (--database-url / DATABASE_URL; needs no kiri.yml).
• kiri flows recs NAME [--window-days 30] [--json] — Kiri’s recommendations for a flow based on its run history (schedule fit, failure clusters, duration drift).

Pause, resume, delete

kiri flows pause nightly_core --target prod    # stop the cron, keep the definition
kiri flows resume nightly_core --target prod
kiri flows delete nightly_core --target prod --confirm

delete requires --confirm — removal from the platform is irreversible (the YAML declaration is untouched; the next sync would recreate it).

Backfills under orchestration

Bounded reprocessing is an apply-level concern, not a scheduler hack:

• Flat watermark contracts: kiri apply --window '<START>..<END>' [--reset] — the cursor advances only on success, and a window run refuses to skip the dbt build (see the build page).
• Data Vault: kiri dv apply --backfill --from-batch <id> --reason <why> --yes — drop + recreate satellites and PIT forward from a batch; hubs and links are preserved (see the silver page).

Incident routing

Failed scheduled runs route through the incident surface when the project has an incidents: block configured — kiri incident and the incidents API are documented on the platform-ops page. SLA breaches found by kiri sla check dispatch through the same channel (data-quality page).