The tools that exist

The previous chapter designed a ten-stage pipeline. This one asks what you can install instead of build. For each stage it lists the projects that exist, what each one does, how healthy it is, what evidence there is that it works, and whether I would use it.

The short post had a compressed version of this survey. The finding hasn't changed: almost every stage has a good open-source tool, and the glue between them doesn't exist. What this chapter adds is the detail behind that sentence, the numbers, and the caveats on the numbers.

How to read this chapter#

Stats. Star counts, last-push dates, licences and archive status come from the GitHub API (gh api repos/OWNER/REPO) on November 11, 2026. Three research agents gathered them, and I re-ran the call for most repos named here on the same day. Where a repo has moved (Vale and its packages now live under vale-cli, RAGAS at vibrantlabsai/ragas), the API follows the redirect and I give the new name. Stars measure attention, not quality. A repo with 200 stars can be the right tool and a repo with 80,000 can be the wrong one.

Last push. A repo with no push in a year isn't necessarily dead, but for a dependency in a pipeline it is a risk. I flag anything quiet since 2025 or earlier.

Licences. They matter here more than usual. Several OCR models are Apache-2.0 for the code but have revenue limits on the weights. Several useful repos have no licence file at all, which legally means you can read the code but not reuse it.

Evidence. I separate three kinds: numbers from a peer-reviewed paper or a public benchmark run by someone else, numbers from the project's own README or benchmark page (marked vendor-reported), and numbers I couldn't check against the primary source (marked secondhand).

Scope. Incidents where these tools or their absence led to published errors are in chapter 13. Prices for model calls are in chapter 10. The abuse cases are in chapter 14.

A gap in the search. GitHub's search API hit its rate limit partway through discovery. A handful of queries never ran ("ghostwriter agent", "nonfiction writing llm", "agentic writing", "deep research benchmark" among them). The repos below were found by other queries, papers and links, and every stat was fetched directly, but there may be small projects this survey missed.

Research agents#

"Deep research" agents are the most crowded category in this whole survey. They map onto the scout (stage 1), and some reach into drafting and fact-checking. Almost all of them read the web and papers. None reads a book you bought.

Summary#

STORM and Co-STORM#

STORM comes from Stanford's OVAL lab (paper, NAACL 2024). It writes Wikipedia-style articles in two phases. First it simulates several perspectives, personas with different angles on a topic, and has each one interview a "topic expert" grounded in search results. From those conversations it builds an outline. Then it writes the article section by section with inline citations and polishes it.

The pre-writing phase is the interesting part for this report. Asking questions from several angles before structuring anything is the closest thing in software to Greene reading widely before he sorts his cards.

The evaluation used FreshWiki, a set of recent, high-quality Wikipedia articles, so the model couldn't have memorized them.

Article-level, STORM scored ROUGE-1 45.82 and ROUGE-L 16.70, with citation recall of 84.83% and precision of 85.18% (judged by Mistral-7B). Ten experienced Wikipedia editors rated STORM's articles more organized (by 25 percentage points absolute) and broader in coverage (by 10) than an outline-driven retrieval baseline.

The editors also complained. They flagged source bias, and "red herring" links between unrelated facts: the article would connect two things that the sources didn't connect. That is the exact failure the [card:ID] discipline in chapter 11 is meant to prevent. A sentence that joins two facts needs a card for each, and the entailment check asks whether the cards support the join.

Co-STORM (EMNLP 2024) adds a moderator and several expert agents whose discussion the user can watch and steer, with a mind map that becomes the report. On its WildSeek dataset, 70% of people in the human study preferred it to a search engine and 78% to a retrieval chatbot. The steering is one of only two designs in this survey that treat the human as part of the loop instead of a reader at the end.

Citations are at URL level, to retrieved web snippets or a custom vector store. No page anchors, no books.

Verdict. The strongest evidence that outline quality drives article quality, which supports the architect stage. Learn from it, but don't build on it: no push since September 2025.

GPT Researcher#

GPT Researcher is the most mature active web-research agent. A planner turns a task into research questions, executors scrape the web in parallel, and a writer and publisher assemble the report. It has a multi-agent mode built on LangGraph (editor, researcher, reviewer, reviser, writer, publisher) and a recursive "deep research" mode. It can run over local PDFs and Word files.

In 2026 it added a context filter that scores how useful each retrieved passage is. The README claims 73% of kept passages are relevant, against 46% for plain embedding similarity, on 28 tasks. That is vendor-reported, though the benchmark is in the repo under evals/context_filter, so you could re-run it.

Citations are URLs. On local files it gives no page or quote anchors.

Verdict. A solid scout and a weak drafter. Its reviewer/reviser loop is a light version of the critics stage.

LangChain open_deep_research#

open_deep_research is a LangGraph supervisor that fans out research sub-agents, compresses what they find and writes one report. Its design history is in Lance Martin's "bitter lesson" post, which is worth reading for how the architecture got simpler over time. It ranked sixth on the DeepResearch Bench leaderboard with an overall score of 0.4344 in August 2025.

The repo is archived. It is read-only.

Verdict. A clean reference implementation. Don't depend on it.

Jina node-DeepResearch#

node-DeepResearch loops through search, read (through Jina Reader) and reason until it finds an answer or runs out of its token budget. It aims at concise answers, not reports.

One caution from the DeepResearch Bench authors: bad scraping by Jina Reader skews citation scores. That generalizes. When an agent can't read a page properly, its citations look wrong even when its reasoning was fine. The equivalent in the book pipeline is a bad scan.

Verdict. A scout for single questions. Not a fit for building a reading list.

Hugging Face smolagents#

The open Deep Research example in smolagents uses a code agent, which writes its actions as Python instead of JSON tool calls, plus a text browser. It scored 55% pass@1 on the GAIA validation set, against 67% for OpenAI's Deep Research.

The 30,304 stars are for the whole library, not the example.

Verdict. Evidence that code-acting agents work for the acquisition step, where the agent has to call several catalogue APIs and reconcile their results.

dzhng/deep-research#

deep-research is under about 500 lines of TypeScript. It generates search queries, extracts "learnings" and follow-up questions from the results, and recurses with breadth and depth parameters. It ends with a Markdown report and a source list.

The "learnings" list is a primitive notecard: a sentence with a URL, no quote and no page.

Verdict. The best starting point if you want to write your own scout. It's small enough to read in one sitting, and the breadth-by-depth recursion is the footnote-chaining loop from stage 1.

PaperQA2#

PaperQA2, from FutureHouse (paper), is an agentic retrieval system over a local folder of PDFs. Its tools are paper search, gather evidence, citation traversal and generate answer.

The step that matters for this report is what the paper calls RCS, re-ranking and contextual summarization. For each retrieved chunk, the model scores how relevant it is and summarizes it with respect to the question, keeping a citation like "(Author2023 pages 3-4)". In effect it writes evidence cards with a page range. The cards are summaries, not verbatim quotes, which is the main difference from the design in chapter 11.

The numbers are the strongest in this survey:

So PaperQA2 matched human accuracy and beat humans on precision: when it answered, it was right more often.

Its WikiCrow mode writes Wikipedia-style articles. Over 375 statements compared against the real Wikipedia articles:

A WikiCrow article cost $4.48 ± $1.02.

It also has ContraCrow, which looks for contradictions between a paper and the literature. It found 2.34 ± 1.99 contradictions per biology paper, of which experts validated 70%. A contradiction finder is a critic the chapter 11 design doesn't have and probably should: two cards that disagree about a date are worth surfacing before the drafter picks one.

Verdict. The best existing evidence that a page-cited evidence layer beats humans on precision. It is built for science papers. It has no notion of a biography's narrative, and it summarizes where the pipeline needs verbatim text.

Hyperresearch#

Hyperresearch is a 2026 project that runs as a Claude Code or Codex skill. It runs a 16-step pipeline:

• It queries OpenAlex, Crossref, CORE, the Directory of Open Access Books, ClinicalTrials.gov, SEC EDGAR and FRED.
• It fetches legal open-access full texts through Unpaywall, Europe PMC and CORE.
• It keeps every source in a persistent Markdown and SQLite vault.
• An independence audit treats syndicated copies of one story as one source.
• A "skeptical cite-checker" gate blocks shipping if a quote is invented or a source has been retracted.
• Four critics attack the draft in parallel, and a patcher locked to edit tools can only make small changes.
• An experimental "dissertation" mode targets 25,000 to 80,000 words.

It claims first place on DRACO with 77.7 over 10 tasks, against 73.0 for Claude Research and 55.2 for ChatGPT Deep Research. That is vendor-reported, on the project's own benchmark page.

Verdict. Architecturally the closest open project to chapter 11's critic layer. The cite-checker as a hard gate and the edit-only patcher are both worth copying. It is still built for web and paper sources, not scanned books.

deer-flow, Tongyi DeepResearch and the 2026 scouts#

deer-flow, from ByteDance, is the most-starred project in this chapter at 85,226. It is a general long-horizon agent harness: research, coding, sandboxes, memory, skills, subagents and a message gateway. There is nothing book-specific in it. It could run the orchestration layer from chapter 11, but so could a job queue and a database.

Tongyi DeepResearch, from Alibaba, is a model rather than an app: an open mixture-of-experts model with 30.5 billion parameters in total and 3.3 billion active, trained for long search tasks. Its paper claims state-of-the-art results on Humanity's Last Exam, BrowseComp and xbench-DeepSearch. Those are the authors' claims on public benchmarks. For the pipeline it would be a cheap, self-hostable brain for the scout.

MiroThinker (8,451 stars, last push 2026-07-06, Apache-2.0) and SkyworkAI's DeepResearchAgent (3,572, 2026-05-04, MIT) are more scout-tier agents and models. nickscamara/open-deep-research (6,299 stars, no push since May 2025) is a Firecrawl-based clone that has gone quiet.

Verdict. Options for the scout's model and harness. None changes the design.

Ai2 ScholarQA#

ai2-scholarqa-lib is small (289 stars) but close to the card idea. Its pipeline extracts quotes from papers, plans the sections of an answer, clusters the quotes into those sections, and writes each section with citations. Quotes, then clusters, then sections is the order of chapter 11's stages 5, 6 and 8.

It works on paper snippets from Semantic Scholar, not on book pages.

Verdict. Read the code for the quote-to-section step. It is the nearest existing implementation of verbatim cards feeding an outline.

open-notebook and Khoj#

open-notebook (41,834 stars, MIT) is an open clone of Google's NotebookLM: a library of sources, chat grounded in them, and notes. It is a plausible base for the human side of the card box, a place to browse cards and their sources. It doesn't do structured cards with page anchors.

Khoj (38,102 stars) is a self-hosted assistant over your notes (Obsidian, Emacs, Notion, PDFs) plus the web, with custom agents, scheduled automations and a research mode. It is AGPL-3.0, so if you run it as a service for others, you must publish your changes.

Verdict. Interfaces, not pipeline stages.

AutoSurvey#

AutoSurvey (paper, NeurIPS 2024) writes academic surveys. It retrieves papers, writes an outline, drafts subsections in parallel, refines them, and then evaluates the result with several language models as judges, including a citation check.

Its citation numbers, against human-written surveys:

Content quality was rated 4.61 against 4.52 for humans at 8k, and 4.62 against 4.88 at 64k.

On speed, the paper's table gives about 73 to 107 surveys per hour, against about 0.07 to 0.16 for humans. Its Figure 1 says "3 minutes per survey," which doesn't match the table. I'd trust neither precisely.

The precision column is the one to read. About 77% means roughly one citation in four or five does not support its claim. That is a strong system on a well-studied task, and it is the reason the fact gate in chapter 11 is not optional.

The repo has no licence file, and no push since February 2025.

Verdict. The closest academic analogue to "draft with tagged facts, then check citations." Its numbers are a useful baseline for what an unchecked drafter does.

LongWriter#

LongWriter (paper, ICLR 2025) addresses a different problem: models that stop writing too early. Its AgentWrite method plans paragraph by paragraph, each with a target word count, then writes each paragraph with the earlier ones in context. That gets outputs over 20,000 words from off-the-shelf models. The authors also built LongWriter-6k, 6,000 training examples of 2,000 to 32,000 words, and a 9-billion-parameter model trained on it beat larger proprietary models on their LongBench-Write benchmark.

It does no grounding at all.

Verdict. The lesson, per-section word budgets, is in chapter 11's architect stage. The code isn't needed.

WikiChat#

WikiChat (paper) is a chatbot, not a writer, but its pipeline is the template for a fact checker. It retrieves, drafts, splits the draft into atomic claims, checks each claim against retrieved evidence, drops what fails and refines the rest.

It reported 97.3% factual accuracy in simulated conversations and 97.9% with real users on recent topics. Against GPT-4, its margin was 3.9 points on well-known topics, 38.6 on obscure ones and 51.0 on recent ones.

That last pattern matters for Greene-style books, whose stories are deliberately obscure. A plain model is most likely to make things up exactly where Greene likes to look.

Verdict. Copy the claim-then-check structure. The code is tied to Wikipedia.

autonovel#

autonovel, from Nous Research, is a fiction pipeline modelled on Andrej Karpathy's "modify, evaluate, keep or discard" loop. It runs in three phases.

• Foundation: world, characters, outline, a ledger of foreshadowing, a voice fingerprint and a canon of hard facts. It loops until a foundation score passes 7.5.
• Drafting: chapters one at a time, each kept only if it scores above 6.0.
• Revision: adversarial "cut 500 words" edits, a mechanical slop scorer plus a model judge, an Elo tournament between chapters, a four-persona reader panel, and a final review by two Opus personas that stops when the reviewer runs out of major items.

It produced a novel of 79,456 words. Those figures come from its README.

Its gen_canon.py cross-checks hard facts across chapters, which is a fiction version of [card:ID]. The difference is that its facts are invented, so the canon only has to be consistent, not true.

The repo has no licence file.

Verdict. The best critic stack in this survey. Its reader panel is the model for chapter 11's bored reader, and its slop scorer is a cousin of Vale. Read it; you can't legally reuse the code without a licence.

Agent Laboratory and AI Scientist#

Agent Laboratory (paper, Findings of EMNLP 2025) runs literature review, experiments and report writing, with an optional "co-pilot" mode where a human gives feedback at each stage. The abstract claims an 84% cost reduction against earlier autonomous research systems.

Secondary write-ups, which I didn't check against the PDF, say that in autonomous mode its papers scored about 3.8 out of 10 from human reviewers, about 1.45 below the average accepted NeurIPS paper (5.85), and that model reviewers scored about 2.3 points higher than humans. Its stated finding is that human feedback at checkpoints improves quality. Treat the specific scores as secondhand. The direction (humans at checkpoints help, model reviewers are lenient) is the paper's own claim.

AI Scientist, from Sakana, and its successor v2 (7,495 stars) generate an idea, check it for novelty, run experiments, write a LaTeX paper and review it with a model. v2 adds tree search over experiments. As publicly reported, and not re-checked here, v1 costs about $15 per paper and a v2 paper passed peer review at an ICLR 2025 workshop. The licence is custom; v1 asks users to disclose AI-written papers.

Verdict. Agent Laboratory is the best evidence in this survey for human gates. AI Scientist is the template for a pipeline with an automated reviewer, and a warning about how lenient those reviewers are.

Fiction tools and a word processor#

Three Chinese web-novel pipelines turned up with thousands of stars each: chinese-novelist-skill (4,751), AI-Novel-Writing-Assistant (3,420) and Pagekin (2,557), all pushed in November 2026. They have outline tiers, a story bible, memory and automated review. All fiction, no sources. The first is MIT-licensed; I didn't check the other two.

mshumer/gpt-author (2,534 stars, MIT, no push since April 2024) was an early proof that a model can draft a whole book in one pass. It's dead.

hughhowey/neo (1,673 stars, MIT) is not an AI tool. It is a word processor by the novelist Hugh Howey with an outline view made of index cards. It's on this list because it is the human side of the card box: a writer's interface for shuffling cards into a structure, which is what gate 2 needs.

Measuring research agents#

DeepResearch Bench (849 stars, Apache-2.0, ICLR 2026) has two scores. RACE rates report quality (comprehensiveness, depth, instruction-following, readability). FACT rates citation accuracy: it extracts statement and URL pairs and judges whether each URL supports its statement. Both use Gemini as the judge. The repo listed a proprietary agent at the top with 57.00 in April 2026, and a second version of the benchmark came out in February 2026.

FACT is the right shape of metric for this report's question, but it checks URLs, not pages. There is no benchmark for "does this sentence match page 212 of this edition."

OCR and scanning#

Getting books into text is the most mature part of the pipeline. The open models are good, and several keep track of pages and layout. The open problem is one that no benchmark measures.

Physical scanning#

Two routes, both described in the research for this report.

• Non-destructive. The DIY Book Scanner community's design: two cameras, a V-shaped cradle and a glass platen, so the book opens at an angle and never lies flat. Capture software includes Pi Scan for Raspberry Pi rigs (292 stars, dormant since 2018). libreflip/sans controls an automated page-turner and is tiny (18 stars) but active. Right for rare or out-of-print copies.
• Destructive. Cut the spine with a guillotine and feed the pages through a sheetfed duplex scanner. Fastest by far. It's the route the Bartz court record describes Anthropic taking with print books it bought.

After capture, ScanTailor Advanced splits pages, deskews, dewarps, crops and cleans. The live fork is the one under the ScanTailor-Advanced organization (358 stars, pushed May 2026, GPL-3.0). The better-known 4lex4/scantailor-advanced (1,581 stars) has had no push since September 2023.

For scale, the Internet Archive's Scribe stations scan about 450 to 500 pages an hour per operator (IA blog, 2015). Partner pricing has been quoted at around $0.10 a page. Both figures are old and the price is secondhand.

The OCR engines#

A few notes on that table.

The weights licences. Datalab's code is Apache-2.0, but the model weights for marker and surya are free only for organizations under $5 million in combined revenue and funding, and chandra's under $2 million. For one author writing one book, that doesn't bite. For a company running the pipeline at scale, it does. olmOCR, docling, PaddleOCR and Tesseract have no such limit.

Datalab's prices. Lite is $0.375, Fast $1, Balanced $3 and Accurate $7.50 per thousand pages, plus a third if you opt out of data sharing. There is a free tier of $10 to $20 a month.

olmOCR's cost. The project says self-hosting costs under $200 per million pages. That's a vendor-reported figure, but it's the right order of magnitude: OCR is not where the money goes.

OCRmyPDF's role. It doesn't compete with the others. It adds a Tesseract text layer to the scanned PDF and keeps the page images, so a human checking a card opens a searchable file that looks exactly like the book. The structured text for the pipeline comes from one of the other engines.

olmOCR-Bench#

olmOCR-Bench, published by the olmOCR team, tests PDF-to-text conversion with unit tests (is this table cell right, is this sentence present, is this header removed) across document types. The overall scores from the README:

The "old scans" column is the one that matters for out-of-print books. Even the best engines score around 50 there. Old print is still hard. Mistral's API, the easiest to call, scores 29.3 on exactly the sources Greene prefers. (The Mistral row is an older version of its OCR model than the current OCR 3.)

The benchmark also has a "headers and footers" column. That matters more than it sounds. Running heads have to be stripped from the body text, but the page number lives in them. An engine that strips the header cleanly and throws away the number has destroyed the anchor.

Note that olmOCR's own team publishes this benchmark. That isn't a reason to distrust it (the code and data are public, and olmOCR doesn't come first), but it is worth knowing.

OmniDocBench#

OmniDocBench (CVPR 2025) is the other major document-parsing benchmark, from the MinerU team. Its leaderboard moved to version 1.7 in April 2026; the README table I read is labelled v1.6.

The top of this benchmark is saturated. The leaders are within about 1.3 points of each other, so the ranking among them says little. It also skews toward modern documents (papers, reports, slides), not 1930s trade books.

The page-number gap#

Neither benchmark measures whether the page number printed on the page survives into the output and stays attached to the right text. That is the property the whole card system depends on, as chapter 11 explains: a card cites the printed folio, not the position in the PDF.

The good news is that several engines label headers and footers as separate blocks: marker, docling and surya all do. So the folio pass is a script over their output (a regex on header and footer blocks, a sequence fit, interpolation, and flags for breaks), not a new model. But nobody has packaged it, and nobody has measured how often each engine gets it right on old books. That's a small, useful benchmark someone could build.

Discovery#

The scout needs to find books, follow footnotes, and get interviews into text. The tools here are mostly free APIs with good coverage of academic work and patchy coverage of trade books.

Scholarly graphs#

OpenAlex is the open graph of scholarly works, authors and citations, with CC0 data. Each work lists its referenced_works and can be queried for what cites it, which is footnote-chaining in both directions. Since February 13, 2026, it requires a free API key. With a key you get $1 a day of free usage; without one, $0.10 a day. Lookups of a single work by ID or DOI are free. Full-text PDFs cost about $0.01 each. The rate limit is 100 requests per second. pyalex (432 stars, MIT) is the Python client.

Its weakness for this report is trade books. A biography from a commercial publisher often has no DOI and no references in OpenAlex.

Semantic Scholar covers about 214 million papers and 2.49 billion citations. It has /references and /citations endpoints, recommendations, and one thing OpenAlex lacks: citation contexts, the sentence around each citation. That tells the scout why one work cites another, which is a better signal than the bare link. Unauthenticated calls share a pool of 1,000 requests per second; a new key starts at 1 request per second. The community scripts repo allenai/s2-folks is archived. An MCP wrapper exists (semantic-scholar-mcp, 38 stars).

Crossref has DOI metadata and the references publishers deposit. It's free, with a "polite pool" if you send a contact address. Use it as a verification layer: does this DOI exist, and does its title match?

Two small agents use these graphs to verify citations. opendraft (531 stars) writes papers with every citation checked against Crossref, OpenAlex and Semantic Scholar. findpapers (419 stars, MIT) searches several databases at once.

Visual tools (ResearchRabbit, Connected Papers, Litmaps, Inciteful) draw citation graphs on top of the same data. They're for humans. An agent should call the APIs directly. Inciteful is free and built on open data.

Books#

Open Library is the core for books. It has works, editions and ISBNs, the graph between them, and whether the Internet Archive has a scan to borrow. The code is at internetarchive/openlibrary (6,818 stars, AGPL-3.0, pushed November 10). For "find this out-of-print book and every edition of it," this is the first call. It's also the resolver for chapter 11's reference check: every book in the bibliography should resolve to an Open Library edition.

The Internet Archive gives full text and page-level hOCR for its public-domain scans, through its advanced search and download endpoints. That is free OCR for anything before 1929. Lending of in-copyright scans is limited: in Hachette v. Internet Archive, the Second Circuit ruled against the Archive's controlled digital lending in September 2024.

HathiTrust is the best finder for in-copyright books. Its full-text search returns which volume and which page mention a term, even when you can't read the page. That's exactly the question the scout asks: which of these 600 candidate books actually talks about this person, and where? Public-domain volumes can be read in full. Its research centre, HTRC, offers page-level token counts ("Extracted Features") and secure Data Capsules for non-consumptive research on in-copyright works.

WorldCat tells you which libraries hold a copy. Its search API needs an OCLC subscription. The website is free to browse, so for interlibrary loans a human does it by hand.

Interviews and audio#

yt-dlp (206,728 stars, Unlicense) downloads video, audio and captions. With --write-auto-subs it saves YouTube's automatic captions, which is how this report got its 22 Greene transcripts for free. Auto-captions have errors (chapter 1 covers what that means for this report), and they have no speaker labels.

ScrapeCreators is a paid API for the same job when YouTube blocks yt-dlp from a server's IP address, which it often does. The endpoints relevant here:

Pricing: 100 free credits, then $47 for 25,000 (about $1.88 per thousand) or $497 for 500,000 (about $0.99 per thousand). One credit is roughly one request, cached results are free, and credits don't expire. A transcript only exists where captions exist, so this doesn't help with audio-only podcasts.

The Whisper family handles audio with no captions.

WhisperX is the one the pipeline wants. A card from an interview needs a timestamp and a speaker, so that "page 212" becomes "minute 14, Greene speaking," and a checker can open the URL at that second.

A note on shadow libraries#

Every discovery tool above points at legitimate copies. The obvious shortcut, downloading books from shadow libraries, is what cost Anthropic $1.5 billion in the Bartz settlement. Chapter 14 covers the case and what it means for someone building this pipeline. The short version for tool choice: the scout should be able to say where to buy each book, and nothing else.

Cards and the card box#

This is the stage with the biggest gap. The pieces exist: a reference manager with a card-shaped annotation schema, an annotation standard with robust anchors, a topic model that clusters with seeds. Nobody has put them together, and nobody checks a card's quote against its page.

Zotero#

Zotero (15,910 stars, AGPL) is the free reference manager most academics use, and it is already halfway to a card box. Highlights made in Zotero 7's PDF reader are stored as annotation items, with these fields (available through the Web API v3 and the local API):

annotationPageLabel is the important one. It's the printed label, not the PDF index, so Zotero has already solved half the folio problem for PDFs that carry page labels. A scanned PDF often doesn't, which is why the folio pass in chapter 11 still matters.

zotero-mcp (5,845 stars, MIT, active) lets an agent search a Zotero library, read full text and annotations, and run semantic search. That makes Zotero usable as the pipeline's source of record: the human highlights in Zotero, the agent reads the highlights, and the cards point back to Zotero items.

Two other Zotero plugins add chat: zotero-gpt (7,518 stars, AGPL-3.0) and ARIA (1,731 stars, no push since April 2025). They're conveniences for a human, not pipeline parts.

Verdict. Use Zotero as the library and zotero-mcp as the agent's door into it.

Hypothesis and the W3C selectors#

Hypothesis (3,189 stars, BSD-2-Clause) is the web and PDF annotation tool. Its search API is /api/search. What matters for this report is how it anchors a highlight. It stores W3C Web Annotation selectors:

• A TextQuoteSelector with exact (the highlighted words), prefix (a few words before) and suffix (a few words after).
• A TextPositionSelector with character offsets.

The quote selector is what makes a card checkable when the underlying text shifts. If you re-run OCR with a better model, the offsets change, but a script can still find the exact quote, and the prefix and suffix tell it which occurrence you meant. That's the anchor model chapter 11's cards use.

Verdict. Don't run Hypothesis for this. Steal its anchor model.

Readwise and e-books#

Readwise collects highlights from Kindle, the web and PDFs. Full Readwise is $9.99 a month; Reader and Highlights alone are $7.99 each, billed yearly. Its export API (/api/v2/export) and Reader API (/api/v3/list) return highlights with location and page where available. An official readwise-mcp (152 stars) and readwise-skills (328 stars) show the company courting agents.

It is the intake path for Kindle highlights. The catch is that Kindle books have no stable printed page, only "locations," so a card from a Kindle highlight has a weaker anchor than one from a scan.

The same is true of EPUBs generally. calibre (26,410 stars, GPL-3.0) manages bought e-books and converts formats with ebook-convert. An EPUB's anchor has to be a CFI (a standard pointer into the EPUB's structure) or a chapter location, not a page.

Obsidian and Logseq#

For a human browsing the card box, the note-taking apps have plugins worth knowing:

• obsidian-smart-connections (5,553 stars, custom licence) uses local embeddings to show related notes. For a card box, it's a way to wander from one card to similar ones, the digital version of sifting a shoebox.
• obsidian-copilot (7,977 stars, AGPL-3.0) now runs agents such as Claude Code and Codex inside an Obsidian vault.
• Logseq (45,544 stars, AGPL-3.0) is a block-based outliner. Viable, but Obsidian has more plugins.

None of these stores structured cards with anchors and verification status. They're browsing interfaces.

BERTopic#

BERTopic (7,953 stars, MIT, pushed November 5) is the tool for turning cards into chapters. Its pipeline is: embed each document, reduce dimensions with UMAP, cluster with HDBSCAN, and label each cluster with its distinctive words using c-TF-IDF. Three features fit the architect stage:

• Guided topics. Seed it with lists of keywords for the author's provisional chapters, and it nudges clusters toward them.
• Hierarchical topics. It can build a tree of clusters, which maps onto chapters and sections.
• LLM topic naming. It can ask a language model to name each cluster.

Verdict. Use it. The design question is what to embed. Chapter 11 argues for the card's note and gloss, not its quote, so the clusters follow what the cards are for, not the vocabulary of their sources.

Prior art, and the gap#

A few projects have tried an LLM-assisted commonplace book: commonplace-bot (60 stars, dormant since 2024), barnsworthburning (44 stars, a public commonplace site), atomic-notes (no stars, but the same idea: PDF to atomic notes, with an extractive pipeline that uses no model), and tieubao/til (77 stars, a Zettelkasten with an "LLM wiki").

The searches for "notecard" mostly return Blues Notecard, a piece of IoT hardware. The biggest "zettelkasten LLM" project has 77 stars.

No established project makes cards with verbatim quotes and checks them against the scanned page. That's the gap this report keeps coming back to.

Verification#

Chapter 13 covers how often deep-research tools get facts wrong and how to design the fact gate. This section is the inventory of checkers: what each one checks, how well, and whether it fits a pipeline.

Summary#

MiniCheck and the LLM-AggreFact leaderboard#

MiniCheck (Tang, Laban and Durrett, EMNLP 2024) answers one question: does this document support this claim? It works one sentence at a time, and the README says to split text into sentences first. That matches the pipeline's sentence-to-card structure exactly.

The README says the 770-million-parameter MiniCheck-Flan-T5-L "reaches GPT-4 performance" at under a billion parameters. The paper frames it as roughly 400 times cheaper; the research agent that found this cited it from memory of the abstract, so treat that ratio as secondhand. Throughput: the 29,000-example test set takes about 30 minutes on one A6000 GPU with prefix caching. It runs on a CPU too, slowly. The larger Bespoke-MiniCheck-7B needs a commercial licence for its weights.

The independent measure is the LLM-AggreFact leaderboard, which collects fact-checking datasets where a claim has to be grounded in a document. Its "Average" column is balanced accuracy. As of November 11:

Two things stand out. Small specialist checkers sit within a few points of large general models: a 0.4-billion-parameter DeBERTa is 0.3 points behind GPT-4o. And nobody is near 90. So a checker flags sentences for a human. It doesn't prove anything.

Verify with Caution (Godbole and Jia, 2025) re-ran five leading factuality metrics on 11 datasets and found that they often disagree with each other, misjudge which system is better, penalize heavy paraphrase, and penalize claims whose support is in a distant part of the source. The last two are the useful ones for design. A pipeline that checks a sentence against a verbatim quote sitting next to it avoids both.

Verdict. MiniCheck is the default entailment checker for chapter 11's critics stage, with a larger model as a second opinion on borderline cases.

AlignScore, FActScore, SAFE and VeriScore#

AlignScore (ACL 2023) is a 355-million-parameter RoBERTa model trained on a unified alignment task. Its abstract claims it matches or beats much larger metrics based on ChatGPT and GPT-4 on the SummaC and TRUE benchmarks. No push since March 2024.

FActScore (paper, EMNLP 2023) splits long text into atomic facts and checks each against a knowledge source, Wikipedia by default. On biographies of people, it measured factual precision of 42% for InstructGPT, 58% for ChatGPT and 71% for PerplexityAI. Its automated estimator was within 2% of human judgment on the aggregate score, not per fact. It also showed that plain retrieve-then-check can overestimate precision by up to 17 points. Biographies are the genre Greene's stories come from, which makes these numbers more relevant than most.

SAFE (paper, from DeepMind) splits text into facts, runs Google searches for each one, and judges support. It agreed with crowdsourced annotators on 72% of about 16,000 facts, and on 100 sampled disagreements SAFE was right 76% of the time. It was more than 20 times cheaper than the humans ($0.19 against $4.00 per response). The baseline was crowdworkers, not professional fact-checkers. It checks against the web, which is the wrong source of truth for a book built from specific editions.

VeriScore (Song, Kim and Iyyer, Findings of EMNLP 2024, paper) extracts only verifiable claims and checks those against search results. Secondary summaries say annotators preferred its extraction to SAFE's 93% of the time, and that GPT-4o had the highest VeriScore, 65.8, across 8 datasets. Both figures are secondhand. The idea, skip what can't be verified, is the claim classifier in chapter 11.

Verdict. None of these fits the gate directly, because they check against Wikipedia or the web. Their decompose-then-check structure is the pattern to copy.

RefChecker, LettuceDetect and LongCite#

RefChecker (paper) breaks claims into (subject, predicate, object) triplets and checks each against a reference, labelling it entailment, neutral or contradiction. It beat earlier methods by 6.8 to 26.1 points on its own benchmark of 11,000 annotated triplets from 2,100 responses by 7 models, and majority voting across checkers agreed best with humans. The repo is archived.

LettuceDetect detects, at the token level, which spans of an answer the context doesn't support. It's the most actively maintained open checker here. In the pipeline it turns "this sentence failed" into "these four words failed," which is what a drafter needs to fix it.

LongCite (paper) is a model that generates sentence-level citations in long-context question answering. Its 8B and 9B models beat GPT-4o on its LongBench-Cite benchmark's citation F1 by 6.4 and 3.6 points, with citations about half as long (GPT-4o's averaged about 220 tokens). The judge was GPT-4o, with agreement against humans up to a kappa of 0.655. Not a checker, but evidence that fine-grained citation is learnable.

RAGAS, TruLens and the Vectara leaderboard#

RAGAS (moved from explodinggradients/ragas) and TruLens compute "faithfulness" or "groundedness": the share of an answer's claims supported by the retrieved context, judged by a model. They're good dashboards for watching a system over time. They give no per-sentence verdict tied to an ID, so they're a weak fit for a gate.

The Vectara hallucination leaderboard (3,326 stars) ranks models by how often they add unsupported content when summarizing. It's data, not a tool, but it's a reasonable input when picking a drafting model.

Grounding APIs#

Anthropic's Citations API. You pass documents (plain text, PDF, custom content blocks or search results) with citations enabled. The response comes back as text blocks, and each cited block carries cited_text and a location: char_location for plain text, page_location (1-indexed) for PDFs, content_block_location for custom content. The docs say citations "are guaranteed to contain valid pointers to the provided documents," and cited_text doesn't count toward output tokens. At launch, Anthropic reported recall accuracy up to 15% better than citing via prompts (an internal evaluation, so vendor-reported), and a customer, Endex, reported source hallucinations and formatting problems falling from 10% to zero (vendor-reported, via a customer quote).

Two limits matter. Citations can't be combined with structured outputs: asking for both returns an error. And a PDF's page_location is the PDF's page index, not the printed folio. Chapter 11 works around both: the margin pass runs with citations on, using one custom content block per OCR'd page, and the carder runs separately with structured outputs.

Google's Vertex AI Check Grounding takes an answer and a set of facts and returns a support score from 0 to 1, the claims with their cited chunks, and optional per-claim scores. The default citation threshold is 0.6 and latency is under 500 milliseconds. It can skip sentences that don't need grounding. Contradiction scoring is limited to an allowlist. It's a hosted alternative to MiniCheck on Google Cloud.

Search-grounded answers from Gemini and OpenAI attach URLs to spans of text. They cite web pages, not a page-numbered corpus.

Links and references#

lychee is a fast link checker written in Rust. It reads Markdown, HTML and reStructuredText, outputs JSON or Markdown (--format json), caches results (--cache --max-cache-age 1d), and exits with a non-zero code when a link is broken. The official GitHub Action supports the same formats. Pair it with a cache to avoid rate limits. In the Penn study cited in the short post, link checking cut broken citations by 6 to 79 times.

Fake-reference detectors are all small: hallucite (16 stars, checks references in paper PDFs), veracite (3 stars, checks BibTeX against arXiv, Crossref, OpenAlex and Semantic Scholar), ethz-spylab/hallucinated-citations (3 stars) and Microsoft's hallucinated-references (10 stars, research code). The working method behind all of them is simple: resolve every reference against a registry and fuzzy-match the title, author and year. For a book bibliography, that's Open Library by ISBN plus Crossref and OpenAlex for anything academic, and it's a few dozen lines of code. JabRef (4,883 stars) does the same lookups in a GUI for humans.

Verdict. lychee for URLs, an in-house resolver for references.

Prose#

The last group is the critics that read for style: rules, grammar and the tells of machine-written text.

Vale and its packages#

Vale (6,371 stars, MIT, pushed November 9) is a markup-aware prose linter. Rules are YAML files built on a few rule types: existence, substitution, occurrence, repetition, capitalization, conditional, metric and script. It outputs JSON (--output=JSON), line format or custom Go templates, exits with an error code, and has a GitHub Action that posts results through reviewdog. It is the only tool here with all of those properties, which is why it's the core of chapter 11's critics stage. The Greene style is built on it.

Its package catalogue (vale-cli/packages, 128 stars) installs styles with a Packages = line and vale sync:

Vale's limit, for this pipeline: its repetition rule only catches a word repeated back to back. Repetition across chapters needs other code.

vale-ai-tells#

vale-ai-tells (129 stars, MIT, pushed November 3) is a Vale package of 137 rules for the tells of model-written text. It covers model vocabulary, contrastive negation ("not X but Y"), short "mic-drop" fragments, formulaic openings and closings, families of figurative language, em dashes and hedging. It includes a sub-package for commit messages. It's in the Vale catalogue (Packages = ai-tells), and every rule defaults to error.

Its README warns that it targets technical documentation. For narrative history, some rules need turning off or down. ContrastiveNegation is aggressive, and the figurative-language rules will flag metaphors a history writer uses on purpose. Each rule can be disabled in the config (for example ai-tells.SycophancyMarkers = NO).

Verdict. Stack it under the Greene style, with the figurative rules and contrastive negation at warning level.

proselint, LanguageTool and textlint#

proselint (4,599 stars, BSD-3-Clause) checks 24 categories: clichés, redundancy, weasel words, hedging, "skunked" terms, typography, mixed metaphors and more. It has had stable JSON output (--output-format json) since version 0.16 and a pre-commit hook. The GitHub repo is a mirror; the primary is on Codeberg. The Vale port avoids running a second tool.

LanguageTool (15,246 stars, LGPL-2.1) is the only real grammar checker in this set: grammar, spelling and style in more than 25 languages. Run its Java server in Docker and POST to /v2/check to get JSON matches with offsets and suggested replacements. It catches agreement errors and wrong words that Vale's pattern rules can't model.

textlint (3,206 stars, MIT) is a pluggable JavaScript linter with a large rule ecosystem (especially strong for Japanese), JSON output and --fix. Mostly redundant if you have Vale.

The original Node tools write-good (5,111 stars) and alex (5,106 stars) have Vale ports; use those.

Slop measurement: slop-forensics and the Antislop paper#

Sam Paech's projects are the most rigorous work on measuring what makes model text recognizable.

slop-forensics (372 stars, MIT) finds words and n-grams that are over-represented in a model's output compared with a human baseline, and builds "slop lists" from them. Point it at your own drafts with the author's earlier books as the baseline, and it finds the drafter's tics. That's chapter 11's repetition critic.

The Antislop paper (Paech and others, October 2025) put numbers on the problem:

• Some slop patterns appear more than 1,000 times more often in model output than in human text.
• Their antislop sampler, which backtracks when it's about to produce a listed phrase, suppressed more than 8,000 patterns without losing quality. Simply banning tokens broke down at about 2,000.
• A fine-tuning method they call FTPO cut slop by about 90% while keeping or improving scores on GSM8K, MMLU and creative writing. DPO, the common alternative, hurt quality and lexical diversity.

The code is in antislop-sampler (359 stars, Apache-2.0) and auto-antislop (209 stars, no licence). Both work at generation time and need local model weights, so they only apply if the drafter is a model you host.

slop-score (43 stars) is a weighted composite of slop words, "not X but Y" patterns and slop trigrams, used on the EQ-Bench creative writing leaderboard. Third-party descriptions put the weights at roughly 60%, 25% and 15%; I didn't verify those in the repo, so treat them as secondhand. Surge AI has argued that the EQ-Bench judge can be gamed by dense literary devices. That's a competitor's claim.

Two smaller detectors: ai-slop-detector (108 stars, MIT) has 120 patterns and a Claude Code skill, but relies on model judgment rather than fixed rules. snifftest (37 stars, MIT) combines countable rules with one judgment model.

Wikipedia's Signs of AI writing, and humanizer#

Wikipedia: Signs of AI writing is an advice page from WikiProject AI Cleanup, not a policy. It lists the patterns editors see in model-written articles. It is careful in a way most AI-detection material isn't: it says human writing shows the same signs, that you should look for several signs together, and its companion guide warns that AI-detection tools have high error rates. TechCrunch called it the best guide to spotting AI writing. It is the upstream source for most of the "ai-tells" rule sets.

humanizer (67,560 stars, MIT) is an agent skill that rewrites text to remove those patterns. It has more stars than every other prose tool in this chapter combined. It's a rewriter, not a gate. In chapter 11's design, it has no place: the critics flag a pattern and the drafter fixes it in context, with the card tags intact. A rewrite pass that doesn't know about card tags can break the fact chain while improving the prose. Its popularity also says something about demand for disguising machine text, which chapter 14 takes up.

Gaps no tool fills#

Laying the survey against the ten stages, these are the gaps. Most are small engineering. A few are open research.

1. Verbatim cards anchored to a printed page. PaperQA2 cites page ranges of summaries and ScholarQA extracts quotes, both from papers. No tool takes a book you own, keeps its printed folios, and stores a card of exact quote, prefix, suffix, folio, edition and gloss that a later [card:ID] can resolve to. Hyperresearch's vault is the nearest storage design.
2. A folio-fidelity check and benchmark. No OCR benchmark measures whether the printed page number survives. The check is a script over header and footer blocks; the benchmark doesn't exist.
3. A marginalia pass. Nothing models a first reading that marks freely before any cards exist. Every tool goes from retrieval straight to answer. A two-pass design, mark then promote, is new.
4. Acquisition as a stage. Scouts search the web and scholarly APIs, and Hyperresearch covers open-access books. Nothing plans which books to buy or borrow, tracks a reading list's status, or reasons about which primary sources a chapter lacks.
5. Story selection by drama. Every tool picks evidence by relevance to a query. None ranks anecdotes by stakes, turning point, surprise, a named person and vivid detail. autonovel judges drama, but only for invented stories.
6. Hard per-sentence enforcement. AutoSurvey (about 77% citation precision), STORM (about 85%) and WikiChat check claims against retrieval. None requires every factual sentence in a long draft to carry a card ID, checks the card supports it, and checks quotations character by character. Hyperresearch's block on invented quotes is the closest.
7. Literary critics on grounded non-fiction. Prose linting, cross-chapter repetition and a bored-reader pass exist only in fiction tools. No research tool runs them. Agent Laboratory and AI Scientist suggest model reviewers are lenient, which argues for deterministic critics plus humans.
8. Human gates with diffs. Only Agent Laboratory's co-pilot mode and Co-STORM's steering treat the human as part of the loop. Nothing has approval checkpoints with card-level diffs between drafts.
9. Book-length structure around a thesis. LongWriter and AutoSurvey reach tens of thousands of words, and Hyperresearch's dissertation mode claims up to 80,000. None organizes a book around laws or principles where each chapter pairs an argument with its stories.
10. Quotation budgets. No tool tracks how many words are quoted from each source. That matters once cards hold verbatim text from copyrighted books, and it's a simple counter on the card table.

The stack#

If I were building chapter 11's pipeline today, this is what I'd install and what I'd write.

Read down the right-hand column. The install column covers the reading, the scanning, the checking and the style. What's left to write is the part of the pipeline that is Greene's: the second read, the card that has to match its page, the eye for a story, and the human who decides.

Sources#