Make it compute, do not let it estimate

Two things that look the same

Upload a spreadsheet and ask for total sales by month. You may get either of two things, and the screen does not always distinguish them.

The model reads and reports. It takes in the rows as text and produces numbers that look right. With a hundred rows it is often close. With five thousand it is not, and it will not say so. This is the failure module six named: arithmetic is not what the mechanism does.

The tool writes code and runs it. It generates a few lines of Python, executes them against your actual file, and reports what came back. The arithmetic is done by a computer doing arithmetic.

The first is a guess dressed as a figure. The second is a calculation you can audit. Knowing which you are looking at is the single most useful habit in this module.

How to tell

Ask to see the code. A tool that ran code will show it. A model that estimated will either produce code it did not run, or explain its reasoning in prose.

The features that execute go by names like Advanced Data Analysis, code interpreter, or analysis tool, depending on the product, and most of the major chat products now have one. Free path: Google Colab runs Python in a browser at no cost and will happily take code a model wrote; a spreadsheet’s own formulas are also real computation, which is why module six’s advice to ask for the formula works.

What to do with the code

Read enough of it to check three things, and you do not need to write Python to do this.

Which file and which column it used. Models pick the wrong column with confident ease when two have similar names: total and total_inc_vat is the classic.

What it excluded. Look for filters. Did it drop refunds, cancelled orders, rows with missing values? Any of those may be right, and all of them change the answer, and none will be mentioned in the summary unless you ask.

How it handled dates and blanks: the two faults from the previous lesson, which cause silently wrong groupings rather than errors.

Verify against one number you already know

This is the whole quality-control procedure and it takes a minute.

Pick a figure you know independently: last month’s total sales from your accounts, the number of jobs in March from your diary. Ask the tool for the same figure from the file.

If it matches, the pipeline is sound: the right file, the right column, sensible filters. If it does not, stop. Do not adjust the question until it agrees; find out why it disagrees. Nine times in ten it is a filter or a date parse, and the same fault is affecting every other figure you were about to believe.

Where it earns its place

Honest assessment: on files under a few thousand rows, a pivot table does most of this and you already know how to check it.

The code route pulls ahead in three situations. Files too large for a spreadsheet. Analyses you will repeat monthly, where a saved script is rerun in seconds and a remembered click sequence is not. And joins across sources (bookings against till data against weather) which are painful by hand and routine in six lines.

The chart trap

These tools produce good-looking charts instantly, which is a hazard.

A chart with no axis labels, no baseline at zero, or a filtered subset presented as the whole is persuasive and wrong, and it is persuasive to you, in your own business, about your own money. Check what is on each axis, whether the vertical starts at zero, and how many rows are actually in the picture, before the chart becomes the thing you remember.

The rule to carry out of this lesson

If a number is going to change what you do, you should be able to say which file it came from, which rows were included, and what operation produced it.

“The AI said 4,300” is not an answer to any of those. “The sum of the net column for rows dated in March, excluding the 14 refunds, from the export dated the 2nd” is, and getting to that sentence is what separates analysis from a plausible number on a screen.