[docs] recall documented as 6-signal WRRF; PG path is a weighted sum of 5 SQL signals #562

What happened

The documentation describes recall as a "6-signal WRRF" fusion. The PostgreSQL path does something else.

• docs/mcp-tools.md:29: "Retrieve memories via 6-signal WRRF fusion".
• ADR-013 (docs/adr/013-*.md:24-48): 6-signal WRRF of vector, BM25, heat, Hopfield, HDC and SR.
• The published recall tool description says "server-side WRRF fusion of vector + FTS + trigram + heat + recency".

In the code, recall_memories() (mcp_server/infrastructure/pg_schema.py:918-1138) fuses 5 signals (pgvector cosine, ts_rank_cd, pg_trgm, effective_heat, recency) as a weighted sum of max-normalised scores (:1059-1085); p_wrrf_k is only used by the agent boost (:1090). The full-text signal is ts_rank_cd, not BM25. Hopfield and HDC are applied after fusion, blended by RRF k=60 (mcp_server/core/recall_pipeline.py:99-128). The SQLite backend does run a rank-based WRRF w/(k+rank) over vector, FTS5, heat and recency, with no trigram signal (mcp_server/infrastructure/sqlite_store_search.py:60-136).

Reproduction steps

Compare the three documents above with pg_schema.py:1059-1085 at commit a3b3a79d.

Expected behavior

The docs and the tool description state what each backend computes: 5 SQL signals, weighted sum on PostgreSQL, rank-based WRRF on SQLite, then post-fusion reranks and FlashRank.

Environment

Cortex 4.21.0, commit a3b3a79

Severity

Medium (feature works; its documentation misdescribes it)

Evidence required to close

docs/mcp-tools.md and the recall tool description corrected. ADR-013 stays as the historical record, with a dated note pointing to the current fusion.