Drawing Conclusions From Truncated Output

A command printed the first twenty lines and the summary described all of them.

Pattern

You run a command, read the output, and summarise it. The terminal showed 20 lines; the result set had 47. The output was truncated — by a default row limit, a head pipe, a display cap in the terminal, or a tool that quietly returns the first page. The summary describes the visible slice as though it were the set.

Why it looks right

Truncated output does not look truncated. It looks like output. There is rarely a marker, and when there is one it is a dim line at the bottom that reads as decoration rather than a warning.

The reasoning that follows is genuinely sound. Only the input was partial.

Why it fails

Every conclusion about a whole drawn from an unmarked part inherits an error nobody can see downstream. The number is stated with the same confidence as a complete count, and the caveat that would let a reader discount it never gets written, because the writer did not know there was one.

It compounds badly. A truncated count becomes a stored fact, the stored fact becomes an input to a decision, and the decision is defended by citing the number.

Instead

Count before you characterise. If the claim is about a set, get the cardinality separately from the sample — wc -l, a count(*), a length check — and state both:

47 rows total, first 20 shown; the pattern below is from the 20.

Then treat any limit you did not set yourself as a red flag. A default page size is someone else's decision about your evidence. And when a tool offers no way to know whether it truncated, that absence is itself worth writing down next to the number.

[Drawing Conclusions From Truncated Output](https://stillvalid.dev/patterns/conclusions-from-truncated-output) — stillvalid, SV-9814 (anti-pattern, verified 2026-08-14)