The Precomputed Judgment

When the senior move is to change the shape of the data, not write a longer query

This exhibit is different. It is not a flaw. It is the absence of one.

Most exhibits in this museum document what happens when complexity accretes — when procedural logic grows one branch at a time until no one can hold it in their head. This exhibit documents the alternative: a design technique that experienced database developers discover independently, pass on to juniors who don't believe it at first, and rarely find documented anywhere because it lives in the space between "too obvious to write down" and "too non-obvious to discover on your own."

The technique has two forms. Both follow the same principle: encode the complex judgment into a queryable representation, then query the representation instead of re-evaluating the judgment.

Form 1 — Sequence Encoding: convert a series of ordered events into a coded string, then use string pattern matching to validate or classify the sequence.

Form 2 — Boolean Predicate Matrices: precompute a set of true/false conditions per record into columns, then use boolean logic in the WHERE clause instead of re-evaluating the conditions.

Both are preprocessing techniques. Both require translation tables. Both feel like extra work until you see what they replace. And what they replace is always the same thing: a procedural cascade of if/else logic that grows with every business rule change until the validation function is 400 lines long and nobody dares refactor it.

This is the anti-accretion pattern. This is what complexity prevention looks like in practice.