Build a Correctness-Check Habit
You can now read what a result does and does not say. This chapter gives you the habit that protects every number before it leaves your hands: a short, repeatable set of checks you run on any result, so you catch your own mistakes before anyone else has the chance. This is the heart of the whole course, the move that separates a number you merely computed from a number you can defend.
Why a Confident Number Deserves a Second Look
A freshly computed number is at its most dangerous the moment it appears, because that is when you trust it most and have examined it least. It looks finished. It sits there in a clean cell or at the end of a tidy line of arithmetic, and everything about it says “done.” That confidence is exactly the problem: the mistakes that survive are the ones that look right.
Most wrong numbers are not wild. They are plausible-looking figures produced by a small slip, a wrong base, a duplicated row, an extra zero, that nobody thinks to question because the result seems reasonable enough. A second look is not doubt for its own sake; it is the one habit that catches these quiet errors while they are still yours to fix, and free to fix, rather than after someone has acted on them.
I already computed it carefully, so isn’t checking it again just doing the same work twice?
Not if you check it a different way. Redoing the identical steps tends to repeat the identical mistake. The checks in this chapter deliberately come at the result from other angles, its size, its parts, a second route, so they catch what a careful first pass missed rather than simply agreeing with it.
What a Correctness Check Really Is
Before the catalog, three plain terms anchor the habit.
The point of a check is not to redo the calculation perfectly. It is to interrogate the result cheaply: is it the right size, do its parts fit together, does a second route agree, is any input obviously broken? A check takes seconds and catches errors that a flawless-looking calculation hides.
Run the Check Catalog
Here is the catalog itself, five checks you can run on almost any result in under a minute. Treat it as a habit, not a chore: the same short pass, every time, before you trust a number.
Unit and definition consistency. Confirm every value you combined was in the same unit, the same period, and counted the same way, so you never added minutes to hours or a weekly figure to monthly ones.
Parts sum to the whole. When you have shares or subtotals, add them back: shares should total 100%, and subtotals should add up to the grand total. A sum that lands off means something was dropped or double counted.
Sanity and order of magnitude. Step back and ask whether the answer is even believable, and whether it is the right size. If a typical weekly figure suddenly comes out ten times larger than usual, stop.
Recomputation or a second-route cross-check. Get the same number a different way: recompute from scratch, or estimate it roughly and see if the estimate lands near your exact answer. Two independent routes agreeing is strong reassurance; disagreeing is a caught error.
Error and outlier scan. Look over the raw inputs for data-entry mistakes, duplicates, and impossible values, a negative age, a 420 km run, the same entry logged twice, before you trust anything computed from them.
Hunt the Usual Suspects
A catalog tells you how to check; it helps to also know what usually goes wrong. Four miscalculations account for a large share of everyday numeric errors, and each one has already appeared in this course. Learn to hunt for them by name.
Percentage of the wrong base. A change or share divided by the wrong starting number. Always ask “percentage of what?” and confirm the base is the reference value, not the new one (the percentages chapter).
Averaging averages. Averaging two group averages as if the groups were the same size. When the groups differ in size, weight by their counts instead (the mean-versus-median chapter).
Ignoring the denominator. Comparing raw counts across different-sized groups and letting the bigger group win automatically, instead of normalizing to a rate (the rates chapter).
Confusing a count with a rate. Reading a raw tally as if it were a per-unit intensity, so “more comments in total” gets misread as “more engaged per listener” (the rates chapter).
See It in Action: A Running Club’s Weekly Distances
A neighborhood running club logs how far each of its six members ran this week, in kilometers. You are asked for the typical weekly distance.
38, 42, 45, 40, 420, 36
The quick move is to compute the mean: 38 + 42 + 45 + 40 + 420 + 36 = 621, divided by 6, gives 103.5 km. Now, instead of trusting that number, run the catalog.
Unit and definition consistency: all six figures are in kilometers for the same week, so nothing is mismatched there.
Parts sum to the whole: this check needs shares or subtotals, and a single list of weekly distances has neither, so it does not apply here.
Sanity and order of magnitude: 103.5 km as a typical week is hard to believe when five of the six runners sit between 36 and 45. The answer is roughly ten times too big for the crowd it is meant to represent. That is an order-of-magnitude warning.
Error and outlier scan: one value, 420, towers over every other. Scanning the raw inputs, 420 is almost certainly a data-entry error, an extra zero on a 42 km week.
Recomputation with the fix: correct 420 back to 42 and recompute: 38 + 42 + 45 + 40 + 42 + 36 = 243, divided by 6, gives 40.5 km.
Second-route cross-check: the values cluster near 40, and 40 × 6 = 240, which is right beside the corrected total of 243. The two routes agree, so 40.5 km is trustworthy.
The raw mean of 103.5 was arithmetically perfect and completely misleading. One order-of-magnitude glance and one outlier scan turned a wrong answer that looked finished into a right one, in well under a minute.
Remember What Checks Can and Cannot Do
One honest limit keeps this habit in proportion. Running the catalog and passing every check makes a result far more trustworthy, but it does not prove the result is correct. A duplicate you never spotted, a definition that was wrong from the start, or a base error that happens to look plausible can all slip through a clean set of checks.
That is not a reason to skip the checks; it is a reason to keep them modest and routine. A number that has survived the catalog is one you can share and defend with good reason, and that is the realistic goal.
Your Turn!
You track your weekly grocery spending for one month and record four figures, in euros.
62, 58, 64, 610
Do the following, writing your answers down before you check:
Compute the mean of the four figures as they stand.
Run the check catalog on that result. Name which check first tells you something is wrong, and say what the broken input most likely is.
Fix the input and recompute the mean, then do one second-route cross-check to confirm the corrected answer is sensible.
Then check your answer against the model solution found at the end of this chapter.
Let’s Recap!
A freshly computed number is trusted most and examined least, so the mistakes that survive are the ones that look right.
A correctness check is a quick test that interrogates a result, its size, its parts, a second route, rather than redoing the same steps.
The catalog is five checks: unit and definition consistency, parts sum to the whole, sanity and order of magnitude, a second-route cross-check, and an error and outlier scan.
Four usual suspects cause most everyday errors: percentage of the wrong base, averaging averages, ignoring the denominator, and confusing a count with a rate.
Passing the checks makes a result much more trustworthy but does not prove it correct: checks reduce error, they do not guarantee truth.
You now have every piece of the method: choose the quantity, compute it, read it, and check it. In the final chapter you will put all four together, carrying one messy real dataset from raw numbers to trusted answers from start to finish.
Model Solution
The mean as the figures stand: 62 + 58 + 64 + 610 = 794, divided by 4, gives 198.5 euros.
The sanity and order-of-magnitude check is the first to flag it: a typical grocery week of about 198 euros is hard to believe when three of the four weeks sit between 58 and 64. The answer is roughly three times the size of most of the data, which points at one broken value. The error and outlier scan then identifies it: 610 towers over the other three and is almost certainly a data-entry error, an extra zero on a 61 euro week. (Unit consistency passes, since all four are in euros, and parts-sum-to-the-whole does not apply here, as there are no shares or subtotals.)
Correct 610 back to 61 and recompute: 62 + 58 + 64 + 61 = 245, divided by 4, gives 61.25 euros. Second-route cross-check: the weeks cluster near 60, and 60 × 4 = 240, which lands right beside the corrected total of 245, so 61.25 euros is trustworthy.
