46 lines
1.8 KiB
Markdown
46 lines
1.8 KiB
Markdown
# 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](../../50-evidence/topics/2026-07-30-channel-bi-post-update-data-contamination.md)
|
|
|
|
## 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.
|