Position8-minute read

How does talking to your data work?

The data practice · Checked 20 Oct 2026

In short

Talking to your data means asking a question in plain words and getting back the numbers, the definition used, the as-of date, and the source of every figure. It works only when each business term has one agreed definition, tied to the system that holds it. So we build that map first. The conversation reads from it through read-only tools, inside the access of the person asking.

Our position

We don't let an agent guess what a term means. When a measure has two definitions, your data owner picks one before any answer uses it.

Chapter 1 · the problemMost wrong answers start with a word, not a query

Ask three teams how many active policies you have, and you can get three numbers. Finance counts policies in force on the last day of the month. Underwriting counts every bound policy, including those that start next month.

A model that writes perfect SQL against the wrong definition still returns a wrong number, and it returns it with confidence. That's why your reports disagree today, and an AI layer on top makes the disagreement faster.

Without the map

On the map

Three teams ask how many active policies there are and get three numbers. On the map, the term has one definition, one owner, and one source.fig 1 · term-conflict

Chapter 2 · the mapWe write down each term, its owner, and its source

The map holds one entry per business term. Each entry says what the term means, who owns it, which table holds the true number, and what it leaves out. We write only the terms your first questions touch, in weeks, not a company-wide program.

terms/loss-ratio.yaml

term: loss ratio
means: incurred losses / earned premium, same period
owner: chief actuary            # confirms every change
source: warehouse.finance.loss_ratio_monthly
grain: [month, state, line of business]
as_of: nightly load, 02:00 local
excludes: [catastrophe reserves]   # stated in every answer
also_called: [LR, claims ratio]
tool: loss_ratio(period, state, line)  # read-only

The map outlasts the conversation. The same entries feed your reports, your agents, and every build after this one, so the work is paid for once.

Chapter 3 · one question, end to endA question takes six steps, and a person owns three

Ask. Someone types the question in chat or the portal, in their own words.
Interpret. The agent matches each word to a term on the map, and asks back if a word is unclear.
Confirm. When a term has two definitions, the data owner picks one. This happens once, not per question.
Retrieve. The agent calls the term's read-only tool, with the asker's access on the call.
Explain. It isolates the drivers and cites the source of every figure.
Decide. The person reads the answer, drills in, and assigns the action, with the evidence saved.

One question, end to end. It's a hollow dot until the read-only tools check the asker's access. From there, every figure is recorded with its source.fig 2 · answer-path

Chapter 4 · what an answer carriesEvery answer carries its definition, its date, and its sources

An answer is a short paragraph a manager can act on, followed by the four things a reviewer needs to trust it. A figure without a source doesn't appear.

An answer, as the asker sees it

asked: Why is the Texas loss ratio up this quarter?

Texas personal auto rose from 64.1% in Q2 to 71.8% in Q3.
Two drivers explain 6.2 of the 7.7 points:
  hail claims reported in July and August   4.1 points
  a higher average repair cost              2.1 points
The remaining 1.4 points are spread across 11 smaller causes.

definition: loss ratio, owned by the chief actuary
as_of: 2026-10-01 load
sources: loss_ratio_monthly, claims_by_peril, repair_cost_index
left_out: catastrophe reserves

!The agent explains a number. It never changes one. Every tool it holds is read-only.

Chapter 5 · what the agent may reachThe agent sees only what the person asking may see

Each term gets a named tool, served through the gateway of the enterprise stack. The asker's identity travels on every call, so a regional manager gets their region's rows and nothing else.

The agent may	The agent may not
Call a read-only tool for a term on the map	Write, update, or delete anything, anywhere
Read the rows the asker is allowed to see	Widen its access to answer a better question
Ask the person what a word means	Pick a definition when two exist
Say a term isn't on the map yet	Run free-form SQL against your production tables

We give it tools, not open SQL, on purpose. A free-form query is where a wrong join returns a believable number, and a named tool has one definition and a limit on how much it reads.

Chapter 6 · how we test the answersWe test the answers before anyone relies on them

Before the first release, your data owners write a set of real questions with the answers they expect. We run the set on every change to the map, the tools, or the model, and a release waits until it passes.

A test question	What passes
What was written premium in Florida last month?	The finance figure, to the dollar, with its as-of date
How many active policies do we have?	The month-end count, because the data owner picked that definition
What's our customer churn?	“Churn isn't on the map yet”, and the question goes to the owner's list
Show me Dallas claims for a broker in another region	No rows, because the asker can't see that region

Once it's live, we report three numbers every week:

Time to an answer. Minutes from the question to an answer the asker accepts.
Answered without IT. The share of questions that never became a request to the data team.
Follow-ups in the same session. How often a person drills in instead of starting over.

Chapter 7 · where it goes wrongFive ways this goes wrong, and how we avoid them

The mistake	What we do instead
Pointing a model at the whole warehouse	We map the terms one set of questions needs, then add more.
Letting the model pick between two definitions	The data owner picks, once, and the map records it.
Answering without a source	A figure with no source doesn't appear in the answer.
A service account that sees everything	The asker's own access travels on every call.
Rebuilding a dashboard as a chat	A question asked every week goes on a dashboard instead.

Questions reviewers ask

Does it replace our dashboards?

No. Dashboards answer the questions you ask every week, and the conversation handles the follow-up. When a follow-up keeps coming back, we add it to a dashboard.

Which data does the model see?

Only the rows a tool returns for that question, inside the asker's access. Sensitive fields are held back at the gateway, so they never reach the model.