The glossary defines Active Customer as a customer who has meaningfully engaged with the product in the last 30 days. The term has an owner, a review date and a catalogue link. Two teams implement it from that text and their counts differ by 9%. Which property is the definition missing?

What is being tested

Whether you can tell a definition from a description. A glossary definition either compiles to exactly one query or it is a label on an argument, and most governance programmes ship the second kind for years without noticing, because every individual definition reads well.

The mechanism

Two engineers read "meaningfully engaged" and make different reasonable choices. One counts a login, the other counts any event that writes data. One counts distinct customer accounts, the other distinct users inside those accounts. One uses the last 30 calendar days in the warehouse time zone, the other the last 30 days ending at the customer's local midnight. Each of those choices moves the number a few per cent, and they compound into the 9% gap. Nobody is wrong, because the text did not decide.

A definition is executable when it names five things:

• The countable event, as a specific condition on a specific table or metric.
• The grain - what one counted thing is: account, user, device, subscription.
• The window and its boundary, including the time zone and whether the end is inclusive.
• The exclusions and tie-breaks - test accounts, internal staff, refunded orders, a user who belongs to two accounts.
• The late-data rule - whether a number published yesterday may change tomorrow.

Write those and the definition can be implemented once, in the semantic layer, and the glossary entry becomes a link to the implementation rather than a rival description of it.

Why the other options fail

• "A named owner." It already has one. An owner resolves a dispute that somebody raises, and the whole problem here is that no dispute was raised: both teams believed they had complied. Ownership without an executable form means the owner is asked to arbitrate the same ambiguity repeatedly, which is the usual steward burnout path.
• "A version number." Versioning an ambiguous definition pins the ambiguity. It is genuinely necessary once the definition is executable, because then a change to the SQL is a change to every report - but it fixes nothing here.
• "A link to the physical tables." Useful for lineage and the commonest answer in catalogue rollouts. The tables were never in doubt; both teams queried the same ones and still disagreed.

When this is the wrong answer

Not every glossary term needs an executable form. Terms that describe the business rather than measure it - "merchant of record", "regulated market", "strategic account" - are legitimately narrative, and forcing a SQL expression onto them produces a fake precision that someone later treats as authoritative. The test is whether anyone computes it. If a term appears in a report as a number, it needs the five clauses; if it appears in a sentence, it needs a good paragraph.

Equally, do not start by rewriting 1,400 entries. Choose the terms that appear in the metrics leadership actually looks at - usually under 30 - and make those executable first. Each rewrite costs an afternoon with the people who argue about the term, and that cost is only worth paying for a definition already running in production behind a report somebody acts on.