What we check first on a batch ETL review
Before we comment on naming or folder layout, we answer four questions that predict production pain. If any answer is shaky, deeper reading waits.
1. Grain is written down
We look for an explicit grain statement in model headers or design docs. “One row per order” is not enough when returns and partial shipments exist. We trace joins that could fan out rows silently.
2. Incremental predicate is stable
Timestamp-only cursors fail when clocks skew or bulk updates touch updated_at uniformly. We prefer composite keys or change tables and note when tie-breakers are missing.
3. Late facts have a policy
Arriving facts after period close need a documented rule: reject, restate, or route to a quarantine table. Code without that policy usually hard-deletes or double-counts.
4. Tests assert grain, not just presence
Row-count > 0 tests rarely fail on the interesting bugs. We value uniqueness tests on business keys and relationship tests that match the declared grain.
After the opening pass
Only then do we dive into style, modularity, and orchestration ergonomics. Clients hire us for risk reduction, not for alphabetising CTEs.