nx_recall_prox.nx

nx_recall_prox.nx -- serve-time TERM-PROXIMITY signal for the recall reranker. module: nishi-core.search.recall_prox depends: nx_syscalls.nx capability: CORE_COMPUTE wired_status: LIBRARY (SERP wiring into dss_search_off_div PASS-1/PASS-2 = R1b, claims-coordinated) genealogy_id: buttcher_clarke_cormack_2006_proximity (term-proximity relevance) WHY: the live SERP ranks by BM25 (+PageRank) only. dss PASS-1 ALREADY loads each candidate's doc TEXT to count tf -- so a proximity signal (query terms that CLUSTER = more relevant) is computable at serve time with NO dense index. Byte-substring based (tokenizer-free) = low blast-radius; it fuses in exactly like the existing authority multiply. Honest: this is a proximity signal, NOT a neural cross-encoder; it moves the ranking on the "terms-together" cases (the JPEG-vs-IR problem). prox_score(text, tn, terms, termlens, nterms) -> strength in [0, PROX_SCALE]: the smallest byte-window containing ALL present query terms; tighter + more-terms = higher. single-term query (or <2 terms present) -> 0 (no proximity signal, ranking unchanged). ⚠⚠SERVE-PATH ALIGNMENT (do NOT wire this raw into dss_search_off_div): this fn is byte-SUBSTRING based -- correct for general text, but the engine's dss_tf_all matches by TOKENIZING via ss_tok_next2 + dss_streq (token-EXACT, normalized). Wiring substring proximity into the SERP would MIS-FIRE (case/stem/substring-in-word) and REGRESS live ranking. The serve version = a SEPARATE dss_prox_all inside the search organ that clones dss_tf_all's tokenize loop + records token positions -> the SAME min-window logic. This fn stays the gated ALGORITHM proof + a general (non-tokenized) proximity primitive. See [[project-nishi-information-finding-sota-2026-07-17]] R1b.