Warnings

Non-blocking validation — observe before you enforce

Warnings surface issues without stopping the pipeline.

They let you observe data quality before enforcing it.

Use warnings when you’re not ready to fail — yet.

Why Warnings Exist

Not all data issues should block your pipeline.

• You’re introducing a new check
• You’re unsure about thresholds
• You’re monitoring a known issue
• You want visibility before enforcement

Warnings let you see problems without breaking production.

Constraints vs Audits vs Warnings

Constraints:

• Fail before insert
• Block bad rows

Audits:

• Fail after insert
• Roll back bad results

Warnings:

• Do not fail
• Log issues for visibility

How Warnings Run

Warnings run after data is written.

They evaluate the same patterns as constraints and audits, but:

• They do not fail the model
• They do not trigger rollback
• They are logged in execution output

Warnings are not ignored — they are signals. They show up in logs, CLI output, and metadata, and can be tracked over time.

From Warning to Enforcement

A common workflow:

1. Start with a warning
2. Observe behavior over time
3. Tune thresholds
4. Promote to constraint or audit

Validation evolves with your data — no rewrites needed.

Usage

-- @warning: PATTERN

Warnings support the same patterns as constraints and audits.

You can use:

• Row-level checks (NOT NULL, UNIQUE, IN, etc.)
• Dataset checks (row_count_change, freshness, distribution, etc.)

Dataset checks

-- @warning: row_count_change < 50%
-- @warning: mean(amount) BETWEEN 0 AND 1000
-- @warning: freshness(updated_at, 48h)
-- @warning: distribution(status) STABLE(0.2)
-- @warning: min(price) >= 0

Row-level checks

-- @warning: email NOT NULL
-- @warning: status IN ('active', 'inactive', 'pending')
-- @warning: price >= 0
-- @warning: sku UNIQUE
-- @warning: email MATCHES '^[^@]+@[^@]+$'

Example

-- @kind: merge
-- @unique_key: product_id
-- @constraint: product_id PRIMARY KEY
-- @audit: row_count > 0
-- @warning: row_count_change < 50%
-- @warning: mean(price) BETWEEN 1 AND 10000
-- @warning: description NOT NULL

SELECT product_id, name, price, description
FROM raw.products

In this example:

• Constraints enforce correctness — primary key must be valid
• Audits enforce expectations — row count must exist
• Warnings monitor anomalies — without failing the run

Large row count swings, unusual price averages, and missing descriptions generate log warnings but do not block execution.