A condition column built from a re-ordered copy of a table is then used to restrict the original — what comes back?

## A full-length column has to be lined up with something The addressing step takes a column of outcomes and a table and has to decide which outcome governs which row. That decision is not part of the syntax — the expression looks the same either way — and it is not a property of selection in general. It is a property of the design you are running on. Two rules are in use in this family: - **By row label.** Where the table's rows carry labels and the condition column carries labels too, the outcomes are aligned to the rows by matching labels. A condition column computed from a re-ordered copy carries the same labels in a different order; alignment undoes the reordering and the correct rows come back. - **By position.** Where there are no row labels to consult — a plain rectangle of numbers, or a tabular design that has no row-label concept — the first outcome governs the first row, the second the second, and so on. Nothing about where the outcomes came from is consulted. ## The two rules side by side | | aligned by row label | matched by position | |---|---|---| | condition built from a re-ordered copy | correct rows; the reorder is undone | wrong rows, nothing raised | | lengths differ | usually accepted, aligned on the overlap | raises | | labels present on only one side | outcome is neither true nor false, or an error | labels are never consulted | | condition built in the same expression | correct | correct | The row that matters is the first one, and the cell that matters is the second half of it. **Equal length with a different order is the silent case**: the operation succeeds, the result has a plausible row count, and every surviving row is one the condition was not true for. ## Why a length mismatch is a gift It is worth noticing which failures are loud. Under position matching, handing over a condition column of the wrong length is almost always refused, because the rule has no way to proceed. That refusal is the friendly failure — it stops the program at the point of the mistake. Under label alignment, differing label sets are handled rather than refused, and the handling reintroduces the third outcome: labels present on only one side produce an outcome that is neither true nor false, and the row count moves in a way that has nothing to do with the condition itself. So the failure modes invert. The design that is more forgiving about mismatches is the one that lets a mismatch reach your results, and the strict one converts a class of silent wrongness into an exception. Neither is the safe choice in general. ## Diagnosing it after the fact When a restriction returns rows that plainly do not satisfy it, the shape of the evidence is distinctive: - The row **count** is often right, or at least plausible, because the same number of outcomes were true — they were just applied elsewhere. - The surviving rows fail the condition when you re-check them against it directly. - The failure appears or disappears when an ordering step earlier in the pipeline is changed, which is the tell that the condition and the table disagree about row identity. The direct check is to evaluate the condition again against the rows you actually got back and see whether they satisfy it. That is a one-off diagnostic, and it either confirms the class in one step or clears it. ## The habit that removes the class Three rules, in order of how much they buy: 1. **Build the condition from the object you address, in the same expression.** If no step can intervene between producing the outcomes and consuming them, no reordering can either. This alone removes almost all of it. 2. **Do not carry a condition column across a step that can reorder or re-label rows.** Naming the intermediate is useful — for inspection, for reuse — but its validity is scoped to the arrangement it was computed against. Treat it as tied to that arrangement, not to the data. 3. **Do not treat equal lengths as proof.** Length equality is necessary under position matching and says nothing about correspondence. Under label alignment it is not even necessary. And one thing to avoid: forcing the two sides to agree by resetting row labels so the ranges line up. That converts a case the design would have caught into one it cannot, which is the opposite of what you want. ## What this looks like in a review A condition column produced several statements above where it is used, with a reordering, a re-labelling or a second restriction in between, is the pattern to flag. It is not wrong — under label alignment it is entirely correct — but it is code whose correctness depends on which design is underneath, and that dependency should be deliberate rather than inherited from whoever wrote the first version.