Knowledge Pull Requests for Continual Document Authoring
Alexander Martin, Benjamin Van Durme
Johns Hopkins University
Published September 22, 2026 · on the feed September 24, 2026 · ▲ 2 · arXiv 2609.26634
The abstract
We introduce Knowledge Pull Requests (KPRs), a framework for continual document authoring that makes each change interpretable. Documents require ongoing revision as new knowledge surfaces from other sources, languages, or times, but existing approaches either edit with no account of what knowledge changed or regenerate from scratch. A KPR integrates new knowledge into a document by extracting claims, filtering and routing them to sections, and flagging conflicts with existing content, producing a ChangeLog that separates what knowledge changes (claim proposal) from how the text changes (document diff). We evaluate KPRs on revising Wikipedia across languages and updating query-driven reports on RAGTIME. KPRs integrate more information and better preserve existing content than rewriting from sources or regenerating from scratch, while adding the most information per token generated. A KPR-revised article also grounds question answering better than a frontier model with search, which does not surface knowledge documented only in other languages.
The Brief
1:52A short podcast summary of the paper. Written and voiced by AI.
Transcript
Knowledge Pull Requests for Continual Document Authoring. By Alexander Martin and one other, from Johns Hopkins University. Published on the twenty-second of September. Its code repository is public and real: about twenty-five source files.
Documents need ongoing revision as new knowledge surfaces from other sources, other languages, or other times. Existing approaches either edit with no account of what knowledge changed, or regenerate the document from scratch. The first hides what was learned inside the edit. The second throws away the existing text, and with it whatever was already right.
Knowledge Pull Requests, or KPRs, are a framework for continual document authoring that makes each change interpretable. The central product is a ChangeLog that keeps two things apart. One is what knowledge changes, the claim proposal. The other is how the text changes, the document diff.
A KPR integrates new knowledge in steps. It extracts claims. It filters them, and routes each one to a section. It flags conflicts with content the document already contains. The ChangeLog records the outcome, so the knowledge change can be read separately from the edit that carries it into the text. A reviewer can check the claims without reading the prose, or the prose without re-deriving the claims.
The evaluation covers two tasks: revising Wikipedia across languages, and updating query-driven reports on RAGTIME. KPRs integrate more information and better preserve existing content than either rewriting from sources or regenerating from scratch, and they add the most information per token generated. An article revised by a KPR also grounds question answering better than a frontier model with search, which does not surface knowledge documented only in other languages.
Keeping the claim apart from the diff is the heart of the design. An edit alone shows what the words became. A proposal of claims shows what was learned, and holding both lets a document keep growing without losing track of why it changed.
Paper Quest · 7 chapters · about 41 min
Play this paper
Learn it by doing: make the calls the authors made, guess the result before you see it, and defend it in a viva graded on your own words. Chapter 1 is right here.
Chapter 1 🧩 · The problem
Some documents are never finished. The question is how to keep changing them without losing track.
You look after a long English article. New facts keep turning up in other sources, in other languages, and over time. The article has to keep up.
The road ahead
- 1 · The problem ~7 min A long article must keep absorbing new facts from other sources, languages and times, but today's ways of updating it either hide what changed or throw away what was right.
- 2 · What came before ~3 min
- 3 · The key idea ~9 min Treat each update like a code pull request: break sources into single-fact claims, screen and place them, flag clashes, and record knowledge changes apart from text changes.
- 4 · Choose your own research ~3 min
- 5 · Build the method ~8 min The method runs in order: extract claims, filter and route them, flag conflicts, then rewrite touched sections and record a ChangeLog.
- 6 · The experiment ~6 min You’ll guess: As a grounding source for question answering, how did a KPR-revised article compare with a frontier model using web search?
- 7 · The viva ~5 min Three questions from the examiners, answered in your own words. Win it for the paper’s trophy.
Free, with Google or an email address. Your stars and progress are kept.