A cap is a floor. Raise it and re-run.

Three times this year I built on a number that was measuring my own tooling.

The first was an options pull. I fetched a long stretch of dates in windows and every window came back at 2,000 rows. Ninety-three windows, same figure each time. Two thousand is a page cap. I narrowed the windows and fetched recursively, and the same range returned 24,420 rows. Two and a half times what I had. Everything I had computed before that ran on a fifth of the range with no gap anywhere to see.

The second was search traffic on one of my own sites. The query report came back capped by a row limit and showed 64 clicks. The same site over the same period, read on the date dimension, showed 315. The capped figure was twenty per cent of the truth, and I had already used it to decide which pages were worth writing more of.

The third had no cap in it at all, and it belongs with the other two anyway. I had collected 1,760 files of option chains. 716 of them were empty. Counting files said coverage was complete. Counting content said coverage was overstated by sixty-eight per cent. A directory entry records an attempt. The row inside records a result. I had been counting attempts and calling them data.

All three shared one property. Nothing failed. No error, no warning, no retry. Each call returned, on time, with a plausible number.

A result landing exactly on a limit is measuring the limit. So the response comes before any analysis, and it is mechanical rather than a judgement call.

Raise the cap, or narrow the window, and re-run until the result sits comfortably under the limit. Until it does, every figure derived from it carries the word FLOOR, which is the honest label for a number with an unknown amount of the range still behind it.

Round numbers are caps until disproved. 100, 500, 1,000, 2,000, 10,000. Anything landing on one of those gets one cheap test: halve the window and see whether the total moves. If it moves, the first number was a wall with a number painted on it. If it holds, you have a real answer and it cost you one extra run.

Some caps cannot be raised. Fine. Name it in the output along with the window that hit it, so the person reading knows which figure is a wall rather than a finding.

And count content, never directory entries. File size screens the empties for free before anything expensive touches them.

An agent will report the capped number with complete confidence, because from where it sits the call succeeded. That is the whole problem in one sentence. A failure announces itself. A cap does the opposite: it hands back a clean, well formed, round result that slots straight into the next step. The agent has nothing to be suspicious of. Neither do you, unless you go looking.

So the suspicion has to be structural. I no longer ask whether a fetch worked. I ask what the ceiling was and whether I hit it. When I write instructions for an agent doing data collection, the instruction is to re-run narrower before reporting, and to label anything sitting on a round number as a floor. The judgement lives in the loop instead of my memory.

What made this expensive was never a bug. Each of those runs did exactly what it was told. The tool told the truth about its own page size, and I read it as a truth about the world. That gap is quiet enough to survive several steps of analysis, and by the time it surfaces you have written conclusions on top of it.

One extra run is cheap. A conclusion built on a page size costs a week.