An arXiv reading workflow with an evidence trail

Recommendation: Every claim taken from an arXiv paper belongs in a note with the versioned identifier, the exact passage and the question it answers. arXiv shows the latest version when no version is named, and its moderation is not peer review, so the version read and the publication status both need recording.

Each stage in the map leaves one small record behind:

• Search and queue: the query, the date it ran and the reason each paper was kept or excluded.
• Versioned paper: the identifier with its version suffix, plus the publication status.
• First pass: an orientation note that decides where the close reading goes.
• Evidence notes and synthesis: one note per claim, tied to a passage, and a summary that keeps disagreements visible.

A reading queue built around one question

A queue starts from one narrow question, for example whether two methods were evaluated under comparable conditions. Each entry records why the paper might answer part of it:

The status values are working labels for the queue, not states that arXiv provides. A paper that turns out to address a different task leaves the queue with a one-line exclusion note, so the next search does not rediscover the same mismatch.

Searching the site and the API

arXiv's article-finding guide covers the search box for title, author and abstract words, the advanced search form, retrieval by identifier and date listings by category. For a query that has to be repeated, the arXiv API returns the same kind of search as structured data:

curl -G 'https://export.arxiv.org/api/query' \
  --data-urlencode 'search_query=abs:"retrieval augmented generation" AND cat:cs.CL' \
  --data-urlencode 'sortBy=submittedDate' \
  --data-urlencode 'sortOrder=descending' \
  --data-urlencode 'max_results=20'

Each part of the request:

• -G with --data-urlencode: sends every parameter in the URL query string and encodes the spaces and quotation marks.
• search_query: field prefixes narrow the match, such as ti (title), au (author), abs (abstract) and cat (subject category), and AND joins two conditions.
• sortBy: relevance (the default), lastUpdatedDate or submittedDate.
• sortOrder: ascending or descending.
• max_results: the number of entries returned (10 by default), with start paging through longer result lists.

The response is an Atom XML feed. Each <entry> carries an <id> that is the abstract URL with its version suffix, such as http://arxiv.org/abs/<identifier>v1, so a scripted queue records the version from the first fetch. The queue also keeps the query string and the date it ran, which makes a later search comparable with the earlier one.

The version and the publication status

The identifier guide gives the current form as arXiv:YYMM.NNNNN, followed by a version suffix such as v1 or v2. Opening an abstract page without the suffix shows the most recent version, and every earlier version stays available and citable with its full identifier (versions guide). A note about a specific equation or table therefore records the version that was read.

Publication status is a separate question. arXiv's moderation documentation states that "the arXiv moderation process is not a peer-review process", so a listing on arXiv says nothing about acceptance by a journal or conference. A journal reference, when one is listed, is where that check starts.

A note header holds all of this in four lines:

Paper:     arXiv:<YYMM.NNNNN>v<N>
Read on:   <date>
Status:    <journal reference, or "preprint">
Question:  <the research question this paper serves>

• Paper: the identifier with the version suffix that was actually read.
• Read on: the reading date, which separates this record from later versions.
• Status: the journal reference when one is listed, otherwise "preprint".
• Question: the link back to the queue entry.

Citation formats for preprints are covered in how to cite arXiv preprints.

First pass and evidence notes

The first pass produces a short orientation note: the claimed contribution, the kind of evidence (experiment, derivation or author discussion) and one reason the paper matters to the question. Its job is to decide where the close reading goes: the evaluation setting for an empirical claim, a definition or hypothesis for a mathematical argument, or implementation detail for a methods comparison. Uncertainty stays written down, for example "unclear whether the baseline uses the same data split".

The close reading then produces one evidence note per claim:

The template holds the project's own observations and supplies no findings. Equations copied into a note are compared with the source symbol by symbol, because a changed subscript or a dropped assumption changes what the expression says.

A synthesis that keeps disagreements visible

The synthesis groups papers by the part of the question they address. Agreement stays provisional until the assumptions and evaluation settings have been compared, and a disagreement stays as two linked passages with a next task rather than a single smoothed conclusion. The research paper evidence matrix lays out the same comparison across several papers.

In Oyren, source PDFs sit in the workspace beside the notes that explain them. The PDF-to-note guide describes that path, and research notes keep each source and its interpretation together.

Frequently asked questions

What happens when a later version changes a cited result?

The original note keeps its versioned identifier, and the new version gets its own evidence note. The comparison between the two stays an open question until it is checked, and the project cites whichever version supports its sentence.

How much can the arXiv API return, and how often can it be called?

One query returns up to 30,000 results in slices of at most 2,000, and the manual suggests narrowing any query that returns more than 1,000. Repeated calls need a 3-second delay, and because results change only when new articles are added, one run per query per day is enough. Bulk harvesting uses the OAI-PMH interface instead.