Business-Rule Density
The rules your numbers depend on, and how little of that logic is written down anywhere but SQL.
Distinct business rules recovered from one team's query history: the filter conditions that decide who and what counts. Almost none documented anywhere but the SQL.
The rules that decide who counts in your business are spread across thousands of WHERE clauses nobody has read side by side. Your data dictionary does not hold them. A business rule is a single decision about what qualifies: an active customer, a billable event, an in-cohort patient, an eligible transaction. It is the highest-value thing a semantic model is ever built from, and the thing least likely to be written down anywhere but the query that used it.
You do not know how many rules your business runs on yet. You can, by the end of the day, off your own query history, for free.
What it tells us
A schema tells you a table has a status field. It does not tell you which statuses your team agreed to call active, or the date cutoff that drops a fourth without anyone noticing. That decision lives in a filter condition, and it changes the answer.
These rules are the logic your business runs on, and most of them exist in only one place: the SQL that used them. Density measures how much of that rule-level knowledge is there to be recovered.
What we found
In one estate we assessed, we recovered 4,317 distinct business rules from one team's query history: the filter conditions that decide who and what counts. Because the rules do not always agree, 39 of them were each defined more than one way, and one, the index date, carried ten concurrent definitions in active use. That is the pattern Definition Concentration takes on head-on.
The density hides in a simple fact: a cohort is never just one filter. It is a stack of decisions, an index date, a lookback window, a continuous-enrollment requirement, an inclusion test, and an exclusion set, all packed into one definition. Move any one and the population changes. Here is a single rule from that stack, as we found it in the query log.
WHERE months_enrolled_before_index >= 12 AND qualifying_dx_claims_12mo >= 2
Only counts patients who were covered for a full year before we start counting, and who actually had the condition, at least two claims carrying a qualifying diagnosis, not a one-off code.
That single WHERE clause is two decisions fused together: a full-year enrollment floor and a two-claim confirmation. Neither is in the schema. Both change who is in the cohort, and then multiply that by 4,317. Ten definitions of the index date were live at the same time, and no meeting was ever held about it.
Why it matters to you
The real business logic is in the WHERE clause, not the catalog. That is the distance between what your data dictionary says and what production SQL actually computes.
Schema descriptions will not make an agent behave like your best analyst. The rules will. Point a text-to-SQL agent at column names alone and it guesses the logic your team already decided.
A cohort defined only in one analyst's SQL is not reproducible and not defensible. When a regulator asks exactly how the population was built, the definition has to exist somewhere you can point to.
The fraction of rules with any documentation is the ceiling on how much of your business is AI-ready. Everything below it is logic an agent has to infer rather than apply.
What good looks like
Your rules are recovered and reconciled, so the logic that used to live in one analyst's SQL sits where the whole team, and the agent, can read it. Recovered rules become an institutional knowledge asset: a set of files people and machines can both read, where each rule tells you which query to write and how your team defines what counts, rather than noting somewhere that a rule exists. The agent applies the versions your team ratified instead of inferring one from column names. Cohorts are reproducible, run to run and analyst to analyst. And a regulator's "how did you define the population" has an answer that is written down, sourced, and yours.
What to do about it
- Run Neuron on your query history.
- Read the recovered rule list.
- Filter to the rules defined more than one way.
- Ratify a canonical version and publish it into the semantic model.
- Gather the rules your team used last week.
- Check which have any documentation immediately available.
- Where a rule is defined two ways, agree on one and write it down.
- Re-check as the query history grows and new rules appear.