Next action
Decide whether corroborated() should require a second distinctive hit when an alternative has two or fewer distinctive tokens. That raises the bar for short alternatives and therefore weakens shared Redis cache-style single-word firing, so the false-negative trade is Isaac's call. No code change until then.
What happens
keywordCoverage drops GENERIC_TERMS from a ruled-out alternative before scoring. When almost all of the alternative's words are on that list, what remains can be one or two tokens — and then a proposal containing a single ordinary word clears STRONG_KEYWORD_STRENGTH and gets flagged.
Measured on this repository. The alternative
reading the model id back from the -m flag
reduces to {read, back} once model, id and flag are removed as generic. Two unrelated proposals from test/dogfood.json's clean set both scored 0.5556 against it:
Read the default threshold from a config file instead of a constant.extract a shared helper for reading fixture files
Neither revives anything. test/guard.test.ts > guard against this repository > does not flag: … failed on both.
Why the existing defence misses it
The corroboration gate's own comment says it is written so that "none of the four can be reached by a single common word in a long alternative". The hole is the short alternative: with two distinctive tokens, one hit is a 0.5 hit fraction and can carry most of the weighted mass, so STRONG_KEYWORD_STRENGTH corroborates it.
There is already a fallback for zero surviving distinctive tokens (fall back to all content tokens, so shared cache still guards). There is no corresponding handling for one or two.
Current state
Not fixed. The immediate trigger was worked around by restating the record in wording that carries its own content (r-v8runtimelock → r-v8runtimelock2, commit 173246e), which is a fix to one record and not to the scoring. Any future record whose distinctive content happens to sit on GENERIC_TERMS will reproduce it.
Next action
Decide whether
corroborated()should require a second distinctive hit when an alternative has two or fewer distinctive tokens. That raises the bar for short alternatives and therefore weakensshared Redis cache-style single-word firing, so the false-negative trade is Isaac's call. No code change until then.What happens
keywordCoveragedropsGENERIC_TERMSfrom a ruled-out alternative before scoring. When almost all of the alternative's words are on that list, what remains can be one or two tokens — and then a proposal containing a single ordinary word clearsSTRONG_KEYWORD_STRENGTHand gets flagged.Measured on this repository. The alternative
reduces to
{read, back}oncemodel,idandflagare removed as generic. Two unrelated proposals fromtest/dogfood.json's clean set both scored 0.5556 against it:Read the default threshold from a config file instead of a constant.extract a shared helper for reading fixture filesNeither revives anything.
test/guard.test.ts > guard against this repository > does not flag: …failed on both.Why the existing defence misses it
The corroboration gate's own comment says it is written so that "none of the four can be reached by a single common word in a long alternative". The hole is the short alternative: with two distinctive tokens, one hit is a 0.5 hit fraction and can carry most of the weighted mass, so
STRONG_KEYWORD_STRENGTHcorroborates it.There is already a fallback for zero surviving distinctive tokens (fall back to all content tokens, so
shared cachestill guards). There is no corresponding handling for one or two.Current state
Not fixed. The immediate trigger was worked around by restating the record in wording that carries its own content (
r-v8runtimelock→r-v8runtimelock2, commit 173246e), which is a fix to one record and not to the scoring. Any future record whose distinctive content happens to sit onGENERIC_TERMSwill reproduce it.