Reflection: Distinguish a database snapshot from batch completeness

Trigger

The first Channel BI diagnosis treated the three real versions visible at 15:44 as the complete intended input set and declared 307 the clean expected total. The user's 07-23 upload committed later at 16:12 and raised the real total to 416.

Expected Behavior

A live-update diagnosis should timestamp its snapshot, enumerate expected source files/dates, check recent or in-flight runs, and distinguish “currently persisted” from “business batch complete” before declaring an expected total.

Actual Behavior

The diagnosis correctly found the one-row fixture but incorrectly promoted the then-current 307-row database subtotal to the final business expectation. The user's correction was required to reopen the missing-date audit.

Root Cause

Weak gate
Other: temporal incompleteness was mistaken for data correctness

Evidence

15:44 snapshot: three real current versions totaling 307 plus one fixture.
16:12:27: daily version 7 committed 109 retained rooms for 07-23.
Final real total: 416; live source total with fixture: 417.
Channel BI contamination evidence

Lesson

PostgreSQL is authoritative for what is committed at a given instant, but it does not by itself prove that every expected source has arrived. Live batch diagnoses need both state reconciliation and completeness reconciliation.

Action

Update gate
Add check/eval

Before declaring a clean expected total after uploads, list expected dates, query recent runs, state the snapshot time, and wait for or explicitly exclude any missing/in-flight input.

Promotion

Promote this to the data-diagnosis checklist and future automated batch-completeness checks.

1.8 KiB Raw Blame History