A column became text at step two, but the run only fails at step six. Why does the failure surface there?

## What travels between steps is a value, not a fault When a step changes how a column is held, it produces a column and hands it on. No marker is attached saying this is not what the next step expects, and nothing inspects it in between. Each later step receives a perfectly well-formed column of text and asks one question about it: *can I do my operation on this?* Four times in a row, the answer was yes. So "the run failed at step six" means exactly one thing: **step six is the first step in this file with no defined meaning on text.** It is a lower bound on where the change happened, and nothing more. ## The steps in between were not lucky Ordering compares characters. A comparison against a threshold compares characters. Grouping puts equal spellings together. Matching pairs identical spellings. Writing the table out writes characters. Every one of those has a correct, well-defined answer for text, so every one of them returned a result — a result that is wrong for the question being asked, but a result. That asymmetry is why this class of defect travels: - a step that **cannot** work on text refuses, and stops the run; - a step that **can** work on text succeeds, and stops nothing; - in an ordinary analysis file there are far more of the second kind than the first, and they usually come first. ## Why the failing step gets the blame The error names the operation that refused. The operation that refused is, by definition, the one thing in the file strict enough to notice. The code there is usually correct — a mean, a division, a numeric aggregation — and is the only honest participant in the sequence. A first reaction of "why is this arithmetic broken?" sends the investigation to the wrong place. The useful reading is: *the column arriving here is not what this step was written for; when did it stop being that?* ## The distance depends on the design, and on your file | design | at the first step mixing text with a number | distance between cause and symptom | |---|---|---| | strict per-column typing | refuses outright | short, often a single step | | a catch-all representation holding arbitrary values | succeeds, returning a text-shaped answer | as long as the file — possibly no failure at all | The file matters as much as the tool. A pipeline whose only arithmetic sits in the final summary has nowhere to fail earlier, whatever the tool would have done. A pipeline that multiplies a rate by a quantity in its second step gives the defect nowhere to hide. ## The outcome with no failure at all A run that fails at step six is annoying. A run that never fails is worse, and it is a realistic outcome wherever a catch-all representation meets a file that never demands a number: - ordering, grouping, extremes and counts all return values that exist in the data; - a threshold comparison returns a subset of plausible size; - the table is written out without complaint; - the report is produced, delivered, and believed. The late failure at least converts a wrong answer into a stopped run. Treat it as the better of two bad outcomes, not as the defect itself. ## Shortening the distance on purpose The distance is not a fact of nature; it is a consequence of nothing in between having an opinion. You can give the file one: 1. State beside the step, in the same file, that the column is held numerically at the points where later work depends on it — the run then stops where the claim is false rather than where the arithmetic is. 2. Put those claims at boundaries where the representation can actually change, not after every step: a claim that never fails is a cost with no return. 3. Make the claim about how the column is held, not about whether its values could be read as numbers — a column of digits held as text passes the second and fails the first. The measure of success is not that the run fails less often. It is that when it fails, the step named in the error and the step at fault are the same step.