The table your team would never use.
Your team carries a mental map of what not to use. That map isn't in the catalog.
Ask anyone who's worked in your warehouse long enough which table to use for daily active users and they won't hesitate: dau_metrics. They'd skip raw_events_ingest without a second thought, because they know what it actually contains.
raw_events_ingest has 1.2 billion rows. The column user_id is present. The name suggests user activity data, and by catalog signals it's a reasonable candidate. In practice it's a trap: duplicate events from SDK retries, bot traffic and internal users included, schema changes without notice, no deduplication or QA applied.
That rejection is immediate because your team carries a mental map of what to avoid. That map was built through experience: a Q3 incident, a data quality review, a conversation with whoever owns the table. It's accurate, current, and completely invisible to any system that wasn't there for those conversations.
dau_metrics exists because someone built the right answer: deduplicated, validated, team-owned, specifically designed for DAU reporting. The catalog knows both tables exist. Which one the engineering team trusts isn't in there.
The difference between 4.7M and 1.1M is the difference between the table an agent selects and the table your team would use. That gap lives in knowledge that has never had a place to live.
