List the tables visible to the configured warehouse connection.

Returns the table names (capped) and a total count. Use this to discover what can be profiled before calling investigate or watch.

Profile tables and store them as the baseline for future anomaly checks.

Pass tables to limit to specific tables, or omit to profile everything visible. The first profile of a table establishes its baseline; no anomalies are reported here. Run watch later to detect drift. A table whose current state has a CRITICAL anomaly against its baseline keeps that baseline, with baseline_updated false: a broken state is not learned. Only a person makes it the new baseline, with scherlok accept. Fails while baselines are locked.

Profile tables and detect anomalies against the stored baseline.

Returns the anomalies found (type, severity, message per table), capped. Each also carries column, metric, baseline, current, change_pct and a fixed hint on where to look, null when one does not apply. Pass tables to limit scope, or omit to watch everything. A table with no prior baseline gets the new-table checks instead (empty_table, all_null_column, duplicate_key as WARNING, constant_column as INFO), and its baseline is set for next time. A table with a CRITICAL anomaly keeps its baseline, so the anomaly is reported again on every call until the data recovers or a person runs scherlok accept; WARNING and INFO findings are learned. With baselines locked, nothing is learned.

Report the current monitoring state.

Returns the connection target (password redacted), how many tables the connection can see, and how many anomalies were recorded in the last 30 days. A quick health glance without profiling anything.

Return anomalies recorded in the last days days (capped).

Reads from the local profile store — does not re-profile the warehouse. Only the configured connection's anomalies are returned. They carry the same fields as watch; those recorded before the fields existed have them all null.

Run a watch over all tables and return a CI-style pass/fail gate.

fail_on is "critical" (default — fail only on CRITICAL) or "warning" (stricter — fail on WARNING or worse). Mirrors scherlok ci. Returns passed plus the severity counts the decision was based on. Like watch, it saves what it sees except a table with a CRITICAL anomaly, so a check failing on CRITICAL keeps failing until the data recovers, while one failing on a WARNING passes next time; verify saves nothing. With baselines locked, check saves no profiles either.

Compare tables with the stored baseline and return a pass/fail gate, leaving it unchanged.

Read-only, unlike watch and check: no profiles or anomalies are written, so retrying after a failure keeps failing until the data is fixed; only the run itself is recorded. Pass tables to limit scope, or omit to verify everything. fail_on is "critical" (default) or "warning". Tables with no stored baseline are listed in tables_without_baseline and never counted as verified. Naming one in tables says it was just built, so an empty table, an all-NULL column or a duplicate key there is CRITICAL; unnamed, they stay WARNING. Once the data is right, investigate sets a baseline.

against compares with another database's baseline instead, e.g. production's when the connection is a dev schema you just built: its scope, such as postgresql://db.example.com/shop (adapter, host, port and path, never a connection string with credentials). Only records saved under that scope count, freshness is not compared, and a scope with no baseline in the store is an error. ignore=["volume"] is for a build on sampled data: row counts are not compared and the column checks allow for a sample.

Check that an output table adds up against the input it was built from.

Read-only: compares target with source on the configured connection and saves nothing. Always compares row counts. With key_columns (unique in the target; several for a composite key) it also counts keys repeated in the target (a join that fans out), source keys missing from the target and target keys the source lacks. With sum_columns it compares each column's total, which may differ by at most tolerance (absolute). Returns counts and totals only, never a key value; passed is false on any mismatch, each a CRITICAL anomaly with a fix hint. Both tables must be listed by list_tables.