Reuse / Build-On
How much of your team's work stands on work it already trusts.
At one estate we assessed, 80 percent of queries built on prior work. A borrowed enrollment window, or a pattern someone else established first.
Your team votes every day on which logic to trust, and nobody is counting. The single most-borrowed query in your estate is your best analytical asset, and almost certainly no one at your company can name it. Reuse is that vote. The more a pattern gets picked up, by more people and more often, the more the team has already put its weight behind it. This is the first vital sign where a high number is the good one.
You do not know your most-borrowed query yet. You can, by the end of the day, off your own query history, for free.
What it tells us
Most work is not written from scratch. An analyst opens last quarter's cohort query and adapts it, or borrows a code list that already passed review. Each of those is a small vote of confidence, cast with a keyboard rather than a meeting.
That makes reuse a ranking signal you already own. Order the history by what the team leans on most, and the pattern the next person is likely to want rises to the top on its own, instead of whatever happened to be written last. It is also a signal that gets sturdier at scale. The more separate authors have reused a pattern, the harder it is to write off as one person's habit.
What we found
At one estate we assessed, 80 percent of queries built on prior work. The clearest example is a washout window: a single block, copied unchanged across the team, that defines the clean period before treatment starts.
NOT EXISTS (
SELECT 1 FROM rx
WHERE rx.patient_id = cohort.patient_id
AND rx.fill_date BETWEEN index_date - 365
AND index_date - 1
)
Look back 365 days before the index date and require no prescription fills in that window. Everyone copies this same block, so each new cohort inherits it instead of rewriting it.
One washout block, adapted by analyst after analyst. The team keeps returning to it because it has held up. Nobody could tell us who wrote it first. It has outlasted them either way.
One caveat matters more than the rest. Reuse tells you what a team trusts, not what is right. Wrong SQL runs just as cleanly as correct SQL, so a mistake can spread on the strength of being convenient and end up heavily reused. A query with forty borrowers can still be wrong.
So reuse is a popularity and trust prior, useful for deciding what a person sees first out of thousands of candidates. It is not evidence of truth, and we do not claim to assess it. Deciding which definition is correct is a human call, made by the people who own the metric. Neuron's job is to put the strongest candidates in front of them in minutes rather than weeks.
Why it matters to you
Reuse is an ordering signal you already have. It tells the agent which of thousands of precedents to reach for first, instead of drawing one at random.
The code your team keeps coming back to is the code most worth standardizing. Reuse points straight at it, and your review decides whether it deserves the promotion.
Usage tells you which definitions have earned trust in practice, not just which ones the catalog claims are canonical. The two lists rarely match, and the gap is the interesting part.
Your most-reused logic is your most valuable analytical asset. Most teams cannot name it, so it never shows up as one.
What good looks like
The candidate list leads with what your team already trusts. Someone asks a question and the answer starts from the pattern reused forty times, rather than a random draw from the history, with the reuse count visible so a reviewer can see why it came up first. Your analysts still decide what is correct, but they decide it on the strongest few instead of reading everything. That is the difference between knowledge sitting in people's heads and an institutional knowledge asset, a set of files readable by humans and machines that meets five criteria. The precedent your team has already voted for is the one that surfaces first.
What to do about it
- Run Neuron on your query history.
- It ranks that history by reuse, so the patterns your team returns to most sit at the top.
- Review the top of the list with its owners and pick the ones the team will stand behind.
- Publish those into the semantic model.
- Ask your team for the top three queries they borrowed from someone else in the last couple of weeks.
- Count how many separate people borrowed each one, and sort by that.
- Review the top of that list, keep the ones that survive review, and write them down where the team and an AI tool can both read them.
- Repeat it each quarter to catch the patterns that rise over time.