Case study 03

Numbers that reconcile: one definition per metric, and a smaller number when the data cannot support the bigger one.

Café Zupas, 90+ locations / 2024 to present

I started in financial reporting, writing the SQL behind month-end close and SOX reports, and I run a warehouse the same way. Shared business rules derive once and downstream marts read them. Every hourly build carries freshness and correctness assertions that fail loudly instead of returning plausible wrong numbers. Legacy objects are retired by rename-and-drop only after a lineage sweep; one sweep found 15 live downstream jobs, including ad-platform conversion feeds. Every decision that more than one project depends on gets a row in a decision ledger, superseded and never edited.

Outcomes

• Unified an employee-benefit metric across four POS generations and eight years of history with a defense-in-depth definition and a 90-day agreement audit before cutover; identified roughly $750K in unflagged spend.
• Recomputed loyalty balances from the transaction ledger (99.8% of accounts reconciling) after finding a vendor balance column overstated by about 5%.
• Found a silent race condition that had erased ten business days from a core fact table across 23 runs with zero errors; fixed the class (transactions, staggered schedules, assertions), not the incident.
• Tested CRM campaign response three ways against holdouts and moved reporting from implied incrementality to documented last-touch influenced sales; required total and comparable-store views on every year-over-year figure after a 6% total gain concealed a 2% comp decline.

Stack

• BigQuery scripting and transactions
• INFORMATION_SCHEMA job forensics
• Cloud Scheduler
• Git
• decision ledger