A working replica of a twice-weekly database audit for a pipeline that ingests reference-rate series into Azure SQL. Three synthetic series stand in for NYFED-style feeds. The audit button below is not a mockup: it executes five checks against the raw payloads embedded in this page, writes the status report, and appends to a chained audit log. A selftest at the bottom re-verifies every number.
Each entry's checksum is computed over the previous entry's checksum plus this entry's content. Change or delete any historical row and every checksum after it stops matching. The selftest below recomputes the whole chain. In production this lives in an audit_log table the pipeline never updates in place, so "what did the Thursday audit say three weeks ago" always has one answer.
These are the most recent raw payloads per series. Switch the scenario to "Schema drift" above and reopen SYN-SOFR: one field renamed, one retyped. That is the kind of quiet provider change that breaks ingestion two days later if nobody is looking.
This page simulates in the browser what a scheduled Claude Code job does against the real database: the checks are plain read-only SQL plus a schema snapshot, versioned in a repo, run at fixed times. Nothing here writes to the pipeline.
Thursday and Friday, ahead of the 4:30 audit window, the job connects read-only to Azure SQL and runs the five checks against the live tables.
Results land as a drafted status report in the exact format above, with row counts, freshness and schema findings attached as evidence.
I read the draft against the evidence, investigate anything flagged, and handle small fixes inline. The report is not sent until I have verified it.
You get "Database is good to go" or the flagged issue with detail. The run is appended to the audit log either way, so the history is complete.
Accountability note: the automation makes the audit faster and harder to fool. It does not own pipeline health. I review every run, I confirm every fix, and the report you receive is one I stand behind.