A Private Reading Stack for Researchers and Analysts

Research reading has an uncomfortable shape: too much material, not enough time, and a meaningful fraction of it that you are not allowed to hand to a third party. Grant applications under review, manuscripts before submission, internal reports, material covered by a data agreement, peer reviews you have been asked to keep confidential.

The usual answer — paste it into a hosted assistant — is unavailable for exactly the material you most want help with. The local stack is not a compromise here; it is the only option that is both useful and permitted.

Stage 1: triage, do not read

The mistake is reading papers in the order they arrive. Summarise first, in bulk, and use the output to decide what deserves attention.

Ask for the same things every time so results are comparable: the question, the method, the sample, the headline result, and the stated limitations. Five consistent fields across thirty papers produce a spreadsheet you can sort, which is the actual deliverable of a literature review’s first pass.

Where the source is a scanned PDF, it has no text layer and extraction will return nothing. That is not a failure — run OCR first, then summarise. Building this reflex early saves the most confusing hour of any first attempt.

Stage 2: interrogate the shortlist

Summaries tell you what to read. Questions tell you what is in it. On the five or six papers that survived triage, switch to question mode and ask narrowly:

• What is the sample size and how was it selected?
• What did the authors identify as limitations?
• What was controlled for, and what was not?
• Does any result depend on a subgroup analysis?

Narrow questions work better than broad ones because of how long documents are processed: each part of the document is interrogated separately and only relevant parts are kept. A precise question returns a precise, quotable passage; a vague one returns a plausible paragraph.

Always open the page it points you at. Treat the answer as a pointer into the document, not as a statement of fact — the passage is the citation, and the citation is what goes in your notes.

Stage 3: build a local corpus

Once you have a working set, load the documents into on-device semantic search. This is where the stack stops being a summariser and becomes a research tool: you can ask across the whole corpus rather than one document at a time.

Questions that work well across a corpus:

• Which of these papers report a negative or null result?
• Where is this method criticised?
• Which papers use the same dataset, and do their results agree?

The embedding model runs in your browser, so the corpus itself is never uploaded. For work under embargo or review, that is the difference between using the tool and not.

Stage 4: keep notes in your own words

The output of this stack is a set of pointers and summaries. The research output — the thing that becomes related work, a critique, a decision — has to be yours. Write the notes as you go, in your own sentences, with the page reference next to each claim. That is what makes the final write-up fast, and it is also what keeps the work honest: a claim you cannot attribute to a page is a claim you should check.

Honest limits

• Tables and figures are mostly invisible to text extraction. If the result lives in a chart, you must read the chart.
• Reasoning that spans distant sections may not surface, because each part is read in isolation before synthesis.
• Verify every number against the source page before it goes into your own work.
• Mathematics and dense notation do not survive text extraction cleanly.

Used with those limits in mind, the stack is genuinely faster than reading everything and materially safer than uploading everything. Begin with the PDF summarizer for triage, then move the survivors into document search for cross-corpus questions.