Intelligence Volume
Whether your team is breaking new analytical ground, or re-running the same report.
distinct analytical calculations, from a claims-based RWE team of 10 to 15 analysts, in a single quarter. All of it sitting in the query history, unrefined.
Two teams can run the same number of queries and build completely different records. One answers the same question about one indication every quarter. The other gets asked, without warning, about new drug candidates across a whole disease landscape. Intelligence Volume separates them. It counts the distinct analytical calculations your team commits to SQL, which is a measure of how much new ground they actually covered. Put a number in your head for last quarter. You are probably low by a factor of ten, and nobody has checked, because nothing in your stack counts this.
You do not know your own number. It is already sitting in your query history, and you can have it by the end of the day, for free.
What it tells us
This reading is about novelty, not effort. A team re-running the same report on one indication every quarter is working hard and building a narrow record. A team fielding ad hoc questions across a whole disease landscape is building a wide one. Same headcount, very different asset.
What matters is what that record can teach. A wide history gives an agent enough precedent to reason across your full scope. A narrow one leaves enormous blank spots, and an agent asked about anything outside the covered ground will guess rather than say it does not know. How much of this volume is genuine analysis rather than routine reporting is the next reading, Analysis Rate.
What we found
In one estate we assessed, a claims-based RWE team of roughly a dozen analysts produced 8,792 distinct calculations in a single quarter. The word distinct carries the sentence. The raw log holds many times that number, because the same calculation reran again and again with fresh literals and column aliases. Each of those repeats counts once. If you put a number in your head at the top of this page, this is where you revise it. Upward.
To get to 8,792 we normalize every calculation that ran, then compare the shape of the logic rather than the text that expressed it. A metric recomputed a hundred times folds to one. A metric defined two genuinely different ways stays two. The three queries below show where the line sits.
SELECT SUM(paid_amt) AS total_spend FROM claims WHERE region = 'Northeast'
Adds up the dollars paid, for one region.
SELECT SUM(paid_amt) AS spend FROM claims WHERE region = 'Midwest'
The same sum of dollars paid, with a different region name and a different column label. Same calculation, counted once.
SELECT SUM(paid_amt)
/ COUNT(DISTINCT member_id)
AS spend_per_member
FROM claims
Dollars paid divided by the number of members. A different question with different logic. A real second definition, counted separately.
The count rises only when the reasoning is genuinely new. Reruns, renamed columns, and swapped filter values do not move it. That makes 8,792 a floor rather than an inflated total, which is worth remembering before you decide the number looks too high.
Why it matters to you
Every one of these calculations is analytics spend. This number tells you whether that spend is building something you keep, the record of every analysis your team designed and ran, or evaporating the moment the query closes.
The breadth of distinct calculations sets the ceiling on how much of the business an agent can answer. It can only reason over the definitions the team has actually produced.
This separates novel work from repetition. A rising count is a team reaching new territory. A flat one is a team re-running the same reports more efficiently.
Most of your team's output is invisible until it is counted. Until then, the reasoning sits in query logs that only the author can find.
What good looks like
Your team's real output is visible and countable. Every distinct calculation is a candidate the semantic model can capture, named and attributed, instead of a row that closed with the query that ran it. That is what turns a quarter of scattered work into an institutional knowledge asset, and breadth is the criterion this reading tests: a record comprehensive enough to cover the ground your team is actually asked about. The agent you point at the database draws on the full breadth of what the team has produced, not the fraction that survived in someone's memory.
What to do about it
- Run Neuron on your query history.
- Read the count of distinct calculations and the list behind it.
- Review the highest-value calculations with the analysts who wrote them.
- Promote the ones worth keeping into your semantic model.
- Pull a sample of last quarter's query logs.
- Count the distinct metrics and calculations in it.
- Set aside the reruns that share the same logic.
- Compare the count against what your modeled layer actually exposes.