The Feedback Loop
Whether the work your team does builds on itself, or starts over each time.
In a healthy history the loop closes, and every turn of it leaves the next analyst further along. In most histories the work stops at the query that produced it.
This is the last of the ten, and the one the others were building toward. The nine before it take stock of what your query history holds, all of it work your team has already done and already paid for. This one asks the question that decides the payoff: has any of it become something the whole team, and the AI you want to trust, can pick up and use?
The other nine readings return a number. This one returns a yes or a no, and you do not have yours yet. You can, by the end of the day, off your own query history, for free.
What it tells us
A query history is raw material, and at the scale of a real team it is close to unreadable. Hundreds of thousands of queries, no index, no map, no easy way to separate the work that gets reused from the one-off someone ran on a Tuesday and never opened again. Left alone, a history records what happened. It does not tell anyone what to do next.
The phrase people reach for here is institutional knowledge. Everyone nods at it and almost nobody pins it down, so we spent two years on the line. Here is where we landed.
Institutional knowledge is what is in your people's heads.
An institutional knowledge asset is the version someone can actually use: a set of files, readable by humans and machines, that meets five criteria.
Anyone on the team can open it, not just the person who wrote it.
Anyone can find the piece they need without knowing who wrote it or where it lives.
It shows how your organization does the work: which definition to use, which query to write, what the right move is.
It keeps up. Three more months of work does not leave it three months out of date.
It covers what your team actually produced, not the fraction that happened to survive.
All five, or the loop does not close. Fresh is usually the first to go.
What we found
The raw SQL is still sitting in the query log. That is thin comfort, because nobody reads a log with half a million rows and nobody goes looking. So when one analyst finally fixes the washout window that has been wrong for a year, the fix helps her report and stops there. She mentioned it in standup. Standup is not a semantic model. The next person opens an old query, copies the old rule, and the mistake gets a second life.
WHERE gap_days <= 365
-- was 90; 365 is the
-- version we trust now
An analyst corrects how long a patient has to be free of treatment before they count as new. Captured, every later query and the agent use the corrected window. Left in the log, the old rule keeps getting copied.
The work happened. It just did not carry. That is the difference between a history that grows and one that improves.
Why it matters to you
You stop rebuilding what someone already solved. You find the team's version and start there, instead of from a blank query.
New hires reach real work in weeks rather than quarters, because the how is written down and findable instead of locked in one person's memory.
The same work stops being paid for twice, and the numbers stop drifting between teams that never compared notes.
Your agent answers from how your team works now, current as of the last run, rather than from a snapshot that went stale months ago.
What good looks like
Your query history has become an institutional knowledge asset: available, searchable, instructive, fresh, comprehensive. An analyst asks how the team defines the treated cohort and gets the answer, with the query that computes it and the one definition the team ratified. A new hire finds it without knowing who to ask. Your agent reads the same files, current as of the last run. The knowledge stops walking out the door when people do.
What to do about it
- Run Neuron on your query history.
- It writes the institutional knowledge asset: your metrics, rules, and joins, described in plain language, in files your team and your tools can both read.
- Re-run it on a cadence so it stays fresh as your team works.
- Publish the ratified definitions into the semantic model, so your BI tools and your agent read the same definitions.
- Stand up a shared query library.
- Curate the best patterns and definitions, and write down how each one is used.
- Save it where the team and an AI tool can both read it, the SQL alongside a plain-English description.
- Assign someone to keep it current. It works, and it is a standing job.