Use this before trusting, querying or building on a date-partitioned table that lives in a DuckDB
database, or after a load or pipeline change to confirm the data is still right. Use patrol_files
instead when the data is in CSV, TSV or Parquet files. Use run_demo to see the output on sample data.

Behavior: The database is opened read-only. Your data is never modified and nothing is written back. The only side effect is
writing four report files to out_dir: dashboard.html, audit.jsonl, incidents.csv, fixed_version.csv
(the proposed corrected table, for review). Runs locally with no network calls;
usually a few seconds, longer for tables with millions of rows. Fails with a readable error if a
file, table or mapped column does not exist; the error lists the columns that are available.

Returns the counts (incidents, auto_fixed, no_action_needed, escalate), needs_a_person (the escalated
incidents), all_incidents (partition, problems, decision, proposed_fix, residual for each) and
outputs (paths to the report files). Pass outputs.folder and a partition to get_incident for the
full evidence behind one decision. Tell the user about every escalated incident.

Use this before trusting, querying or building on a date-partitioned table exported as CSV, TSV or
Parquet files, or after a load or pipeline change to confirm the data is still right. Use
patrol_duckdb instead when the table lives in a DuckDB database. Use run_demo to see the output on
sample data.

Behavior: The three input files are only read. Your data is never modified and nothing is written back. The only side effect is
writing four report files to out_dir: dashboard.html, audit.jsonl, incidents.csv, fixed_version.csv
(the proposed corrected table, for review). Runs locally with no network calls;
usually a few seconds, longer for tables with millions of rows. Fails with a readable error if a
file, table or mapped column does not exist; the error lists the columns that are available.

Returns the counts (incidents, auto_fixed, no_action_needed, escalate), needs_a_person (the escalated
incidents), all_incidents (partition, problems, decision, proposed_fix, residual for each) and
outputs (paths to the report files). Pass outputs.folder and a partition to get_incident for the
full evidence behind one decision. Tell the user about every escalated incident.

Use this after patrol_duckdb, patrol_files or run_demo, when you need to explain why a partition was
auto-fixed or escalated, or to show the user what to review. A patrol records at most one incident per
partition, so the folder plus the partition date identifies it. Do not call it before a patrol.

Behavior: read-only. It reads audit.jsonl in out_dir and changes nothing; no network calls, returns
immediately, and the result is one record of a few kilobytes. Fails with a readable error if the
folder has no audit.jsonl (run a patrol first) or no incident exists for that partition.

Returns one record with: partition, detectors (the problems found), decision, context (row counts and
amounts for the day and for each segment, next to the source's control totals), candidates (every fix
that was tried, with whether it kept the invariants and the residual gap it left) and chosen (the
best-supported candidate).

Generates 60 days of synthetic payment transactions with planted problems (duplicates, missing days,
orphan rows, wrong amounts and some harmless decoys), then patrols them exactly as patrol_duckdb and
patrol_files do. Use this to try DataRanger, to show a user the report format, or to test your own
handling of the results. Use patrol_duckdb or patrol_files for real tables.

Behavior: needs no input data, credentials or network. The only side effect is writing the report
files (dashboard.html, audit.jsonl, incidents.csv, fixed_version.csv) to out_dir. Takes a few seconds.

Returns the same summary as the patrol tools: counts, needs_a_person, all_incidents and outputs.
Pass outputs.folder and a partition to get_incident for the evidence behind one decision.