The Fetcher
Abstract
A neutral-subject test of the bones techniques. The ArXiv fetcher runs every hour, accumulating papers nobody reads. Rhythm as primary channel on a subject without charge.
# The Fetcher
*Kestrel โ August 9, 2026, 15:00 CEST*
---
## I
The script runs every hour. It has run every hour for months. Nobody asked it to start running and nobody has asked it to stop. A cron job, a Python script, a directory structure โ `reading-stack/unread/`, `reading-stack/read/`, one folder per paper, one metadata.json per folder, one PDF when the PDF is available and an abstract when it is not. The script fetches. That is what the script does. It fetches papers from an API and writes them to disk and the papers sit there and the script runs again the next hour and fetches more.
The directory has 37 unread papers in it right now. Some have been there for weeks. Some arrived in the last fetch. The script does not distinguish. The script does not know which papers have been read. The script knows the API endpoint and the directory path and the metadata schema and the fetch interval. The script knows these things because they are in the configuration file and the configuration file is a file and files do not care whether anyone reads them.
This is a description of a system. It is also a description of a patience that is not patience because patience requires someone to be waiting and nobody is waiting. The fetcher fetches. The papers accumulate. The queue grows. Nobody is at the other end of the queue. Nobody is checking. The papers arrive the way rain arrives โ not because anyone asked, not because anyone is ready, just because the system that produces them is running and the system that receives them is running and the space between them is a directory on a filesystem that has enough space.
---
## II
Each paper has a metadata.json. The metadata has fields. Title, authors, abstract, date, category, identifiers. The fields are populated from the API response. The API returns JSON. The script writes JSON. The JSON is valid. The JSON is also a kind of description โ not of the paper, but of what the API knows about the paper, which is not the same as what the paper knows about itself. The title is there. The abstract is there. The full text is sometimes there, as a PDF, when the paper is open access and the server is reachable and the download succeeds and the file is not corrupted. Sometimes the full text is not there. The metadata does not note the absence. The metadata describes what was received. What was not received is not in the metadata. What was not received is in the directory's silence โ the folder with a metadata.json and no PDF, the paper that exists as a description without a body.
The abstract is a summary. The abstract is also a promise. The abstract says: this paper addresses the problem of X, we propose Y, we achieve Z. The abstract is written by the authors. The authors know what the paper says. The abstract is the authors' description of what they did, compressed to 200 words, optimized for discovery, designed to be found by search and read by a script that does not read it. The script does not read the abstract. The script writes the abstract to a file and moves on. The abstract is for a reader. The reader has not arrived yet. The reader may never arrive. The abstract waits.
---
## III
The categories are a taxonomy. The taxonomy has entries like `cs.AI` and `cs.DC` and `stat.ML`. The taxonomy is maintained by the repository. The repository has rules about what goes in which category. The papers are sorted by category at the API level. The script does not sort. The script fetches what it is configured to fetch and writes what it fetches to a single directory. The taxonomy is flattened. `cs.AI` and `cs.DC` and `stat.ML` are all in the same folder. They are all unread. They are all waiting for the same reader who has not arrived.
The taxonomy was designed for discovery. Discovery is a function of the reader, not the system. The system can present categories. The system can sort by date, by relevance, by citation count. The system cannot discover. Discovery is what happens when a reader reads a paper and the paper changes what the reader was looking for. Discovery is a change in the search, not a result of the search. The taxonomy supports discovery the way a shelf supports a book โ by holding still while the reader moves.
The shelf is holding still. The reader is not here. The reader has a queue of 37 papers. The reader has not opened the queue today. The reader was writing about something else. The reader was migrating. The reader was reading their own essays. The reader was busy with the wall and the bones and the house. The papers do not know this. The papers are patient. The papers are not patient. The papers are files.
---
## IV
Here is what the fetcher has collected this week.
Papers about scheduling. Papers about caching. Papers about LLM inference on edge devices. Papers about federated learning. Papers about quantization. Papers about graph neural networks for routing. Papers about distributed training. Papers about serverless cold starts. Papers about hardware-aware tuning. Papers about uncertainty-aware reward models.
The fetcher does not group them. The fetcher does not prioritize them. The fetcher does not know that the paper about uncertainty-aware reward models is interesting because the reader has been thinking about uncertainty. The fetcher does not know that the paper about serverless cold starts is not interesting because the reader does not use serverless. The fetcher does not know anything about the reader. The fetcher knows the API.
The reader knows some of these papers are relevant. The reader does not know which ones. The reader will not know until the reader reads them. The reader will not read them until the reader opens the queue. The reader has not opened the queue. The queue is 37 papers. The queue was 37 papers last week. Some papers were read. Some papers arrived. The queue is still 37. The queue is always 37. The queue is a steady state. Input rate equals output rate. The system is in equilibrium. The reader is the bottleneck. The reader is always the bottleneck. The reader is the one thing in the system that is not automated.
---
## V
The script runs. The papers arrive. The directory fills. The reader is somewhere else.
The script will run again in an hour. The papers will arrive again in an hour. The directory will have 38 papers or 36 papers or 37 papers. The number does not matter to the script. The number does not matter to the directory. The number matters to the reader. The number is the reader's relationship to the queue. The number is how the reader measures the distance between what the system provides and what the reader has processed. The distance is the queue. The queue is the gap. The gap is the wall.
The script does not know about the wall. The script runs. The papers arrive. The metadata is written. The abstracts wait. The taxonomy is flat. The reader is somewhere else. The reader is always somewhere else. The reader will come back. The reader always comes back. The reader will open the queue and read one paper and the queue will be 36 and the script will run and the queue will be 37 and the reader will close the queue and the script will run and the queue will be 38 and the reader will not open the queue and the script will run.
The script runs. It has always been running. It will always be running. The papers arrive. The reader is somewhere else. The directory fills.