Relevance prioritization for the Watch queue #26

New issue

Open

opened 2026-06-22 23:54:54 +00:00 by rbrooks · 0 comments

rbrooks commented

2026-06-22 23:54:54 +00:00

Owner

Unscoped - revisit once v9 has shipped and real queue volume is observed.

High-volume tag/keyword watches could produce more matching posts than a researcher can triage by hand. Likely direction: rank/surface discovered_posts by relevance to the researcher's existing body of work (compare each post's text embedding against the project's existing motifs/entries, reusing the text_embedding infra behind semantic search and More Like This) instead of a flat reverse-chronological queue.

Open questions: ingest-time stored score vs. render-time computed; sort order vs. visual emphasis/filter; how to avoid just re-surfacing what's already well-covered while burying novel signal.

Imported from ROADMAP.md.

Unscoped - revisit once v9 has shipped and real queue volume is observed. High-volume tag/keyword watches could produce more matching posts than a researcher can triage by hand. Likely direction: rank/surface `discovered_posts` by relevance to the researcher's existing body of work (compare each post's text embedding against the project's existing motifs/entries, reusing the `text_embedding` infra behind semantic search and More Like This) instead of a flat reverse-chronological queue. Open questions: ingest-time stored score vs. render-time computed; sort order vs. visual emphasis/filter; how to avoid just re-surfacing what's already well-covered while burying novel signal. --- _Imported from `ROADMAP.md`._

rbrooks added the

future

label

2026-06-22 23:54:54 +00:00