# A practical paper triage workflow when 700 papers land a day

- Published: 2026-07-25
- Authors: CORTEXA
- Category: Engineering
- HTML: https://researchhub-vert.vercel.app/blog/paper-triage-workflow-2026

Hundreds of submissions a day means reading the feed is not a plan. Three filters, applied in order, and one thing to skip on purpose.

arXiv's cs.AI feed alone runs to hundreds of submissions a day. Reading it is not a plan.

## Three filters, in order

**Attention first.** Community-ranked lists — Hugging Face Daily Papers, researchers who post consistently — are a cheap prior. Not authoritative, but a better starting distribution than chronological.

**Problem second.** Keyword search finds papers sharing your words; semantic search finds papers sharing your problem. For a literature review the second is what you want, and the two disagree more than people expect.

**Structure third.** Read the abstract, the limitations, and one figure. If it survives, it earns a note with a quote and a page number — not a summary. Summaries decay; quotes stay checkable.

## What to skip deliberately

Anything you cannot state a reason for reading. "It seemed relevant" is how a triage system turns back into a pile.

## The honest limit

No workflow makes you current with a field producing hundreds of papers daily. The goal is a defensible sample, not coverage.

## Filter one: attention as a prior

Community-ranked lists are not authoritative, and treating them as such is a mistake. But as a *prior* over what to look at first, they beat chronological order substantially.

Hugging Face Daily Papers, a handful of researchers who post consistently, and subreddit activity all encode a rough judgement from people closer to the work than you are. Use them to order the queue, not to decide the queue.

## Filter two: problem, not words

Keyword search retrieves papers that share your vocabulary. Semantic search retrieves papers that share your problem. These disagree constantly, and the disagreement is informative.

A paper solving your exact problem in a different subfield's language is invisible to keyword search and is often the most valuable thing you could read. Conversely, a paper sharing all your terminology may be addressing something unrelated.

Run both. Read the disagreements first.

## Filter three: structured skim

Three parts, in this order. **Abstract** — what is claimed. **Limitations** — what the authors admit, which is where the honest signal is. **One figure** — usually the main result, which tells you whether the claim survives contact with data.

If it survives that, it earns a note. A note is a quote and a page number, not a summary. Summaries decay into your paraphrase of your paraphrase; quotes stay checkable against the source three months later.

## What to skip on purpose

Anything you cannot state a reason for reading in one sentence. "Seemed relevant" is how a triage system silently reverts to a reading pile.

## The honest limit

No workflow makes you current with a field producing hundreds of papers a day. Coverage is not achievable and pursuing it is how people burn out. The goal is a defensible sample — one you could justify to a reviewer — plus a mechanism for noticing when you have missed something that matters.

That mechanism is usually other people, not a tool.


## The workflow as a diagram

```mermaid
flowchart TD
    A[Hundreds of new papers] --> B{In a trending<br/>or curated list?}
    B -- no --> S[Skip]
    B -- yes --> C{Semantic search:<br/>shares your problem?}
    C -- no --> S
    C -- yes --> D[Read abstract]
    D --> E[Read limitations]
    E --> F{Claim survives<br/>the caveats?}
    F -- no --> S
    F -- yes --> G[Read one figure]
    G --> H[Note: quote + page number]
    H --> I[(Reading queue)]
```

The order is deliberate. Each filter is cheaper than the one after it, so the expensive step — actually reading — only runs on what survived three cheap ones.