The unknowns in your data

A spreadsheet looks like your business, so it’s easy to forget it isn’t. It’s a map — something a person compressed onto a grid on a particular day, for a particular reason, leaving out everything they already knew and didn’t think to write down. The column header says revenue. It does not say whether that’s before or after refunds, whether tax is in or out, whether the figure is booked the day the order lands or the day the money actually clears. The map is confident and silent about all of it. The territory is where the real answer lives.

Every spreadsheet carries questions it never asks out loud. Dates written 03/04 that could be March or April and look identical right up until the 13th of the month, when one reading quietly breaks. A workbook with four tabs where exactly one is the truth and the other three are someone’s abandoned working copies. A “customer” column that’s a company on some rows and a person on others. A total that’s missing the region nobody remembered to export.

None of that is written on the map. It lives in the head of whoever made the file — and the moment you compute on top of it without checking, you’ve inherited every assumption they forgot to mention. The math will be flawless. The answer will be wrong, and it will look exactly as trustworthy as a right one.

There’s a good essay by Thariq Shihipar on getting real work out of AI, and its whole argument is that quality is bottlenecked by unknowns — the gap between the map you hand the model and the territory it’s actually about — and that the cheapest place to close that gap is before any work begins. Ask first; guess never. It’s written about software, but it is precisely the job of a senior analyst.

Watch a junior analyst and a senior one open the same file. The junior starts computing. The senior starts asking: what does this column actually mean, which sheet is the real one, is this booked or collected, why does the total for last quarter not match the deck. The arithmetic was never the hard part. Knowing what to compute — that’s the part you were paying for.

The expensive mistakes don’t come from bad math. They come from confidently computing the wrong thing.

This is the reflex we built blueberry.’s agent around. When your file is genuinely ambiguous — a workbook with more than one sheet, a column whose meaning it can’t pin down, a grain it can’t be sure of — it doesn’t quietly pick an answer and move on. It stops and asks you one plain question, with the answers to choose from, the same way a good analyst would have asked over your shoulder. And where it has to make a reading rather than ask — the date format that could go either way, the rows it couldn’t read, a column mixing two currencies — it writes that down and shows it to you, so the assumption is yours to overrule instead of ours to hide.

And once the unknowns are settled, every number it charts is computed from your real rows — never invented to fill a sentence. Asking first and computing exactly turn out to be the same discipline seen from two ends: a refusal to pretend it knows something it doesn’t. A tool that guesses at the top of the pipeline and guesses at the bottom is just wrong twice, faster.

The tools that feel most impressive are usually the ones that skip the interview. They take the map at face value, hand you a confident chart, and leave the gap between the spreadsheet and the business exactly where it was — only now it’s hidden behind a nice font. We’d rather ask the awkward question up front and earn a number you can actually stand behind. That’s the whole difference between a demo and a data team.