Momenta believes the key to AI-ready analytics lives in query history. Because Neuron reads it, we get a close look at how analytics teams actually work: the patterns that recur, how knowledge moves, and where an AI agent is finally positioned to help. This is one of ten readings from that work.

The Health Assessment · Vital Sign 04

Hidden-Join Rate

How much of the way your tables connect lives only in the queries, never in the schema.

The reading · one estate we assessed

109

Hidden in the SQL 59% Guessable from schema 41%

Of 184 joins in one core reporting schema, 109 could not be guessed from the column names. Fifty-nine percent of how those tables connect lives only in the queries that used them.

More than half of how your tables actually connect is missing from your schema. Your best analysts learned those connections by getting a wrong number first, and none of them wrote it down. A schema tells you which tables you own. The keys that link one table to the next are recorded in one place only, the queries that used them. The Hidden-Join Rate measures how much of your data model lives in that gap.

You do not know your own hidden-join rate yet. You can, by the end of the day, off your own query history, for free.

What it tells us

The Hidden-Join Rate is the share of table joins whose keys cannot be inferred from the schema or the column names. A schema lists what tables exist. It says very little about how they relate, and how they relate is institutional knowledge, learned by an analyst who tried the obvious key, got a wrong number, and found the real one the hard way.

Some of those keys are declared. A foreign key or a dbt relationship test names a few. The hidden joins are the rest, and they survive in one place, the query log, which runs on a retention clock. Snowflake's ACCOUNT_USAGE holds about 365 days. The map is recoverable today. It will not be recoverable forever.

What we found

In one core reporting schema, 109 of 184 joins could not be guessed from the column names. The obvious version of a join usually compiles cleanly and still returns the wrong number. Here is one, drawn from real-world claims data.

The obvious key

select count(*)
from claims c
join members m
  on c.member_id = m.member_id

In plain English

Matches every claim to a member by ID. Simple, and it counts claims from months when the member was not actually enrolled.

The key your team learned

select count(*)
from claims c
join enrollment e
  on c.member_id = e.member_id
 and c.service_date
     between e.span_start and e.span_end

In plain English

A claim belongs to a member only during the months they were covered, so the join runs on the eligibility date range as well as the ID. Get it wrong and you count patients who were not covered.

Both queries read as a claims-to-member join. Only the second encodes the eligibility span, and nothing in the column names tells you it is required. That span is a business rule living inside a join, the kind Business-Rule Density counts. Multiply it across 109 joins in one schema. Nothing alerts either, because the wrong join runs fast and returns on time, which is most of what a dashboard gets judged on.

Why it matters to you

CTO

Each hidden join is a dependency on the one person who knows it. No diagram shows it, so it does not register as risk until that person leaves.

Head of Data

Your real data model lives in the queries, not the schema. The catalog names the tables. The joins that make them usable sit somewhere no catalog looks.

Chief AI Officer

A text-to-SQL agent without the joins connects tables the way the column names suggest. That is the obvious key, and on data like this it is wrong.

Analytics lead

The map your team built exists nowhere but the query log, and that log ages out. Lose the window or the people and you lose the map.

What good looks like

The working join paths are recovered from the queries that use them and written down where the whole team can see them. Anyone can look up how two tables actually connect without knowing which analyst first worked it out, and the agent answering on top of your warehouse joins them the way your analysts do. That is the difference between institutional knowledge, which sits in a few people's heads, and an institutional knowledge asset, a set of files that people and machines can both read and that meets five criteria we set out at the end of this series. The map then survives both turnover and the retention window, instead of scrolling off the end of the log the day someone leaves.

What to do about it

With Neuron

Run Neuron on your query history.
It recovers the join paths from the queries that worked, each with the query it came from and how often it ran.
Review the ones your team relies on most and confirm the keys with the analysts who wrote them.
Publish those join paths into the semantic model, so your BI tools and your agent both connect the tables the same way.

By hand

Pick one core report you run every week.
List the joins in the SQL the warehouse actually ran.
Ask how many a new hire could guess from the column names alone. The rest is your hidden-join rate.
Write the non-obvious ones down somewhere the team and an AI tool can both read, and re-check each quarter.

The schema tells you which tables you have. Only the queries tell you how they actually connect. Neuron recovers the join paths your team learned the hard way straight off your query history, in an afternoon, for free, and writes them into a semantic model, so the map outlives both the people who found it and the log that holds it. Your log holds about 365 days of that map. You are already some months into it.