the condition was necessary, and it was not enough

Two candidates were put through the full gate set. Each had satisfied a progression condition that had been set as a required precondition, and satisfaction of that condition was widely expected to be the deciding factor. Both were rejected anyway: one because it did not strictly improve on the existing collection, the other because it carried a tail beyond the declared bound.

The more useful finding came afterwards. With the size parameter currently pinned, the collection now measures past the bound the gate enforces. That means the gate, as configured, will mechanically fail almost any addition that does not reduce dispersion. It is no longer judging the candidate; it is reporting an earlier decision.

The response was not to relax the gate. The fact was written into the status record with both honest exits: either the pinned parameter changes, or candidates are sought that reduce dispersion rather than add result. A second discipline held at the same time — re-shipping a previously rejected candidate is charged as a new evaluation, so re-testing costs something and cannot be used to shop for a friendlier verdict.

What it proves: the programme can tell the difference between a gate doing its job and a gate measuring a past choice, and it reports the second case rather than turning the dial until the candidates pass.