It looks for the damage that a green job and passing tests miss: rows lost or duplicated (a join that
fans out, a dedupe that drops too much), keys that disappeared, values that changed in columns the
change was not meant to touch, a jump in nulls, a shifted total (a unit or currency change), new or
vanished categories, and schema or type changes.

Use this after you edit a SQL query, dbt model, Spark job or load, or after an agent applies a fix,
and before you report the work as done, merge it or publish the table. Use check_against_source
instead when there is no earlier snapshot but you have the raw input the table was built from, and
run_config when the project already has a pipeverify.yml listing its tables.

Behavior: read-only and repeatable. Both snapshots are read (files are opened read-only; Snowflake,
dbt and SQL sources run one SELECT each, with credentials already configured on this machine, never
passed as arguments) and loaded into a temporary in-memory DuckDB where the checks run. Nothing is
written anywhere. Each snapshot is loaded whole, so for a large warehouse table pass a SELECT or a
'where' filter covering the slice you changed. Usually takes seconds. Fails with a readable error
if a file, table, dbt model, key column or login is wrong.

Returns verdict ("pass", "review" or "block"), headline (one sentence you can show the user), and
tables: one entry with stats (row counts and more) and findings, each with check, severity, message,
column and metrics. On "review" or "block", tell the user every finding and do not apply the change.

It catches a transformation that looks clean but decided something it had no basis for: the source
sent two different amounts for one key and the output kept one without saying so, values that no
longer match the source, source rows that never arrived, or output rows with no source at all.

Use this for a new table, a first load, or a dedupe or repair step, where compare_tables has nothing
to compare with. Use compare_tables when you do have the table from before the change; you can run
both for the strongest check.

Behavior: read-only and repeatable. The table and the source are each read once (files are opened
read-only; Snowflake, dbt and SQL sources run one SELECT each, with credentials already configured
on this machine) and loaded into a temporary in-memory DuckDB. Nothing is written anywhere. Usually
takes seconds. Fails with a readable error if a file, table, key or column does not exist.

Returns verdict ("pass", "review" or "block"), headline (one sentence you can show the user), and
tables: one entry with stats and findings, each with check, severity, message, column and metrics.
A "review" here usually means the source itself is ambiguous, so a person must choose; say so.

Use this when the project already has a pipeverify config, which is the same check its CI runs, so
you see what the pull request check will say before you push. Use compare_tables for a one-off
comparison of two snapshots without a config file.

Behavior: read-only and repeatable. Reads the config, then reads each table's snapshots (files,
DuckDB, Snowflake, dbt models or SQL databases, using credentials already configured on this
machine) into a temporary in-memory DuckDB. Nothing is written anywhere. Time grows with the number
and size of the tables. A table that cannot be read is reported as "block" with the reason in its
error field, and the remaining tables are still checked. Fails with a readable error if the config
file is missing, is not valid, or no table matches.

Returns verdict (the worst across tables: "pass", "review" or "block"), headline, and tables: one
entry per table with its own verdict, stats, error and findings. Tell the user every review and
block finding.