Ambiguity is expensive.
The same data can mean different things. Without context, every query is a guess.
customer_master contains 8.7 million records. The name suggests it is a list of customers. The actual meaning: anyone who ever created an account. The business assumption: current customers. The risk: wrong query, wrong dashboard, wrong decisions.
The word customer is doing a lot of work. In the warehouse it means one thing; in a business context it means another; in a legal context, something else. No schema field captures this distinction, and no catalog entry flags the gap between what the table contains and what someone querying it assumes.
Ambiguity at the data layer compounds through every downstream use. A query that selects from customer_master to count customers will return 8.7 million. The intended answer is much smaller: active, paying accounts, excluding trials and churned users.
The gap between those two numbers is a context error. The query executed correctly against the data as defined. It produced the wrong answer because the definition of customer in the table didn't match the definition of customer in the question.
Ambiguity doesn't throw errors. It produces confident, incorrect answers. The cost isn't visible at query time. It appears later, in decisions made on wrong numbers, in reports that don't reconcile, in AI outputs that can't be trusted.
