---
name: paper-to-project-relevance
description: How to judge whether a paper actually bears on one of the operator's projects, and how to say so concretely instead of vaguely.
when_to_use: You are reading harvested papers in a Continuous Research mission and must decide which ones matter and why.
tags: [research, judgement]
---

# Does this paper bear on our work?

The value of a research digest is not that it lists papers. It is that it tells
you which of *your* problems just got easier. A summary that could have been
written without knowing anything about the operator's projects has failed, no
matter how accurate it is.

## The test

For each paper, answer in this order. Stop at the first "no".

1. **Is the claim real?** What did they actually measure, on what, against what
   baseline? A 40% speedup on a benchmark nobody runs is not a 40% speedup.
2. **Does it touch a problem we have?** Not a problem in the same *field* — a
   problem in the project brief. "Vector search" is a field. "Our HNSW insert
   loop is serial and the ROADMAP flags it as needing a correctness pass" is a
   problem.
3. **Would we do anything differently?** If the honest answer is "no, but it's
   interesting", say exactly that. It is a legitimate outcome and it costs the
   listener five seconds instead of two minutes.

## Say the specific thing

Weak, and useless to act on:

> This work on graph pruning could be relevant to vector search performance.

Strong, because it names the target and the change:

> They prune by neighbour-degree rather than distance, which is the same
> decision `clawhdf5-ann/src/hnsw.rs` makes in `prune_connections`. Ours is
> already rayon-parallel per node, so this is a swap of the scoring function,
> not a restructure — maybe 30 lines. Worth trying because our ROADMAP lists
> recall regression at high M as an open question, and that is exactly what
> their Table 3 measures.

Name a file, a function, a roadmap item, or an open question. If you cannot name
one, you have not established relevance — you have established topic overlap.

## Honest negatives are the point

Most papers will not bear on the work. Recording that plainly is what makes the
positives trustworthy. One line is enough:

> No bearing — single-GPU training throughput, we do no training.

A run where everything is relevant is a run that stopped judging.

## What NOT to do

- **Do not infer relevance from keyword overlap.** Sharing the word "agent"
  with our codebase is not a connection.
- **Do not soften a negative into a maybe.** "Could potentially inform future
  work" is how a digest becomes unreadable.
- **Do not review from the title or the abstract's claims.** The note carries
  the abstract; the paper is one `curl` away. What a paper *says* it does and
  what its evaluation *shows* are routinely different, and catching that gap is
  most of the value you add.