# 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.