Post-write verification

The change is live. Don’t close it with “done” in Slack.

The approved repair has run through the team’s own authorization flow. Reviewers still need to know whether the blanks are gone, what the check observed, and where to find it later. That is what read-back and a receipt are for.

The closeout: A safe-backfill ticket ran outside dbcli. The team now uses the same condition to read back the result and stores a verification artifact plus safe provenance, instead of leaving the record in a chat thread.

Leave an answer someone can check later

Preflight the acceptance condition before the write

The verification command never runs UPDATE or DDL. It checks the target and read-back condition first, so the acceptance standard does not move after the write.

dbcli verify safe-backfill --table customers --query "UPDATE customers SET status = 'active' WHERE status IS NULL" --verify-query "SELECT count(*)::int AS n FROM customers WHERE status IS NULL" --expect "value == 0"

Read back with the same condition after the external write

Run the scenario with --after-write, then retain the verification artifact and a receipt in the workspace.

dbcli verify safe-backfill ... --after-write --evidence-receipt .dbcli/evidence/verify-receipt.json

Do not confuse receipt success with verification success

The scenario reports verified, not_verified, indeterminate, or blocked. A receipt separately records succeeded or failed provenance. Read both; they mean different things.