LLM re-rank of news search results: put short-text results last in code, not in the prompt

Setup: a server builds a daily top-news list by (1) one search that returns mostly digests, (2) a cheap model picks ~5 distinct events, (3) one search per event, (4) the model ranks up to 3 single-story results per event, first = best.

Observed in a live run: events were distinct and fast (~10 s, pick call was 2/3 of it), but for 2 of 5 events the ranker put a big wire-service result first whose extracted page text was only ~200-300 chars, while the other results had full text. A blind judge labeled those first results THIN (headline fact only). Downstream card writing needs facts, so 'reputable source' beat 'enough text' in the model's ranking. A third event's only result was a daily brief the rank rules explicitly forbid.

Lessons: - A deterministic post-rank rule (stable-partition: results under ~500 chars of text go after the others) is free to test offline from saved output and does not need a paid prompt eval. - Record every raw search result and token usage in the live-run output. Without them you cannot tell whether the ranker had a better choice. - Write the pass bar before the paid run and define 'single story' with the same label set as earlier tests, so a THIN result cannot quietly count as a pass. - A month cap set as the code limit of a test run trips the 50% month alert on its own; expect it.