A field in a database is not business meaning. It is evidence that some system captured something, under some rule, at some point in time.
That distinction sounds pedantic until the number lands in a review. Then everyone discovers that active_customer, booked_revenue, or open_risk carries assumptions nobody wrote down. Sales meant one thing. Finance meant another. Product was counting usage a third way. The warehouse did not create the argument; it made the argument visible.
The semantic layer is the place where raw facts get promoted into operating language. It says what the object is, what qualifies it, which states matter, which exclusions apply, and which team is allowed to change the definition. That work is not glamorous. It is also what keeps a dashboard from becoming a debate club.
Operators should care because undefined meaning creates fake precision. A chart can be perfectly calculated and still be useless if the business concept underneath it is unstable. A renewal-risk score built on stale account ownership will look sophisticated while sending the team to the wrong accounts.
Start with the terms that already cause friction. Do not boil the ocean. Pick one operating loop: forecast review, renewals, onboarding, support escalations, usage reporting. For each contested term, write the plain-English definition, the authoritative source, the owner, the refresh rule, and the known exceptions.
The goal is not purity. The goal is custody. If the business cannot say what a term means and who can change it, the term is not ready to steer decisions.
This is part 1 of 10 in The Semantic Layer.
