Definition Concentration
How much of your team's shared vocabulary lives in one person's SQL.
At two estates we assessed, 94 and 97 percent of metric definitions had a single author and no second copy anywhere in the warehouse.
Your most-reported metric is almost certainly defined more than one way, and the two versions do not agree. You have probably shipped both. A definition is a set of rules that decide what counts, and when two analysts write those rules a little differently, you get two numbers wearing the same name.
You do not know your number yet. You can, by the end of the day, off your own query history, for free.
What it tells us
A definition with one author is still good work. It is precise, and usually correct. It is also invisible to everyone else. No one can check it against a second version, build on it, or find it when a number looks wrong.
Shared, the same definition becomes the team's starting point instead of a private rebuild. That is what concentration costs you. The work is good. It stops with the person who wrote it, and the next analyst starts over. This is how analytics teams tend to work, one query at a time, so the number is high almost everywhere we look.
What we found
Almost every definition each team relied on had one author and no documented second version. In one estate, 59 metrics were each defined more than one way. One, a patient decile, carried 14 definitions. The formatting matched. The denominator did not.
NTILE(10) OVER (ORDER BY score)
/ enrolled_patients
Sorts patients by score into ten equal groups, measured against patients who were enrolled.
NTILE(10) OVER (ORDER BY score)
/ all_patients_in_pull
The same ten groups, but measured against everyone in the data pull. A different denominator puts the same patient in a different decile.
Two dashboards both read decile. They rank the same patients differently, and nothing downstream flags it, because the label is identical. This is the part where you open your own dashboards in a second tab. It's fine. Probably.
Why it matters to you
The same KPI defined two ways is two different board numbers. Reconciling them after the fact is work you already paid for once.
A text-to-SQL agent pointed at 14 definitions of one metric inherits all 14. Its answers are only as consistent as the definitions underneath.
You own the catalog. This is the distance between what the catalog says a metric is and what production SQL actually computes.
Until the versions sit side by side, you cannot tell whether your team agrees on a number or only assumes it does.
What good looks like
One definition per metric, visible to the whole team and to the agent that answers on top of it. Someone asks for the decile in plain language and it comes back the same number every time, computed from the version your team ratified. A new analyst inherits it on day one, and so does a new agent. That is the difference between knowledge sitting in one person's head and an institutional knowledge asset the whole team can use. The reconciliation you did once does not come back next quarter.
What to do about it
- Run Neuron on your query history.
- Filter the metric list to definitions with a conflict count above two.
- Review each with its owners and pick the version the team will stand behind.
- Publish that version into the semantic model, so your BI tools and your agent both read the same definition.
- List your ten most-reported metrics.
- Ask each owner to write the definition down, filters and edge cases included.
- Where they differ, agree on one and save it somewhere the team and an AI tool can both read, such as a shared repo with the SQL and a plain-English description.
- Re-read the query history each quarter to catch new drift.