[DX23876]

Why

This is the only retrieval change that survived a frozen-holdout read, and it is a removal rather than an addition.

The two tail slots were kept for "an exact name, date or number that the embedding missed". Measured on the 404-query corpus in Tools/MemoryBench:

	Δ nDCG@8 dev	Δ nDCG@8 holdout
drop the guaranteed slots	+0.007 [+0.003, +0.011]	+0.008 [+0.002, +0.017]

Small, but confirmed on data it was not chosen on — which is more than any addition to this pipeline managed. Recency, a kind prior, quotas, MMR and every absolute or relative floor either failed to confirm or came back resolvably worse.

Two measurements explain the shape of it

Improving the arm that fills the slots is worth nothing. IDF weighting plus numeric and date tokens, with fuse otherwise untouched, is +0.000 on both halves. Two guaranteed places at the end cannot express a better ranking however good the arm behind them gets. (The +0.025 that the same arm shows elsewhere in the ladder is measured inside a pipeline that has already removed the slots — and it did not confirm on the holdout either, at +0.010 [−0.004, +0.023]. It is not in this PR.)

The category built for the slots is better without them. numeric reads 0.803 against 0.797. The mechanism was not serving the purpose it was kept for.

What is given up

A source the semantic arm never returned can no longer enter on keyword evidence alone. That is a real capability, and on this corpus it is worth less than the two slots it spends. SemanticRanking.fuse keeps the mechanism and all of its tests, so re-enabling it is a one-argument change if a future corpus disagrees.

Unaffected is the path that matters most: when the model loses the 2.5-second race there is no semantic arm at all and fuse returns the keyword ranking in full — testWithoutSemanticHitsTheLexicalOrderSurvives pins that. Losing that race costs −0.285, two orders of magnitude more than this change is worth in either direction.

Verification

• Packages/SemanticMemory: 19 tests green; fuse's rescue behaviour is untouched and still covered, including the rescueSlots: 0 case this now relies on.
• Both app targets built (Strand macOS and NOOPiOS), because app-build.yml is default-disabled.
• Full macOS suite: 2132 tests, 0 failures.
• One line of production change; the reasoning and the numbers are in the call-site comment so the next reader does not have to find this PR.

🤖 Generated with Claude Code