The pipeline

The short post that started this report ended with a sketch: a table of ten stages, a card in JSON, and a list of critics. This chapter turns that sketch into a design an engineer could build from. It covers what each stage reads and writes, which model runs it and why, what goes wrong, and what the checks are. It also covers the plumbing that the sketch skipped: the database, the state machine, retries, caching, the approval queue, and the logs.

Three other chapters carry the load this one leans on. What it costs has the token arithmetic, so the stage sections below point there instead of repeating prices. The tools that exist surveys the open-source projects each stage could be built from, with star counts and benchmarks. Verification and failure covers the hallucination studies and how much to trust a fact checker. This chapter is the design that sits between them.

One warning before the design. The pipeline below is a proposal. Nobody has built it, including me. Where I give a number that comes from a paper or a vendor, I cite it. Where I give a number that is a design choice (a threshold, a retry count, a batch size), I say so. The worked example at the end uses placeholder data, marked as such, because inventing a historical story to show off the pipeline would be the exact failure the pipeline exists to stop.

The principles#

The short post gave three rules. Each one turns into constraints on the code, and those constraints are what make the rest of the design hang together.

Rule 1: the agents do the researcher's job#

Greene's description of the help he wanted is narrow. Ryan Holiday transcribed tapes and read books Greene did not want to read. The researchers who failed did so because they skipped the part where you sit with a book and think about it. The worst one, in Greene's telling, "digitally copied passages from the books" and printed them on the cards. "He didn't take the time to write and to think about what they might be."

That gives the first constraint: the agents produce material for decisions, and the human makes the decisions that carry the book. In code, that means three things.

• No stage both proposes and approves. The scout proposes books, a human approves the list. The story hunter proposes stories, a human picks one. An agent never writes to a table that a gate owns.
• Every agent output has a reason field. A book on the scout's list says why it is there. A card says why it matters to its theme. A story candidate says what makes it dramatic. The reason is what the human reads at the gate, so it has to be specific enough to argue with.
• The agents also do jobs nobody did for Greene. He had no one checking every quote against its page, and no one flagging every hedged sentence. Those are mechanical, tedious and exactly the work machines do well. The critics stage is where that happens.

Rule 2: every fact carries a card#

A sentence that makes a factual claim about the world points to a card. A card points to a page in a specific edition. If any link in that chain breaks, the sentence does not ship.

This rule does more work than any other in the design. It turns fact-checking from "is this true?", which nobody can answer cheaply, into "does this sentence say what this card says, and does this card say what this page says?", which a script can answer for most cases and a human can answer fast for the rest. The short post estimated about 200 hours of human checking for a Greene-sized book without this rule. With it, most of that becomes a lookup.

The constraints that follow:

• Cards hold verbatim quotes. A card stores the exact words from the page, not a paraphrase. The paraphrase goes in a separate field. A script can check a quote against a scan. It cannot check a paraphrase.
• Cards are immutable once verified. If a card is wrong, you retire it and make a new one with a new ID. Drafts that cited the old card then fail the "card must resolve" check and get flagged, which is what you want.
• The draft format carries card IDs inline. A sentence ends with [card:SHELLEY-07] or similar. The tags stay in every draft until the very last export step, which strips them into endnotes.

Rule 3: a human holds the gates#

The short post named three gates: the reading list, the choice of story for each chapter, and the final read. The full design adds a fourth, the outline, which the short post folded into the architect stage. So the gates are:

1. Reading list (after stage 1).
2. Outline (after stage 6).
3. Story choice (after stage 7, once per chapter).
4. Final read (stage 10).

Gates are blocking. A stage downstream of a gate cannot run until the gate is approved. That sounds obvious, but most agent frameworks treat human review as an optional interrupt. Here, a gate is a row in a table with a status, and the orchestrator refuses to schedule work whose gate is not approved.

The derived invariants#

Put the three rules together and you get a short list of properties the code must hold at all times. I'll refer back to these by number.

I1 and I2 are the fact chain. I3 closes the gap where a model writes a factual sentence and forgets to tag it. I4 keeps the human in charge. I5 and I6 are what let you rerun a stage after fixing a bug without wondering what you broke.

The shape of the whole thing#

Here is the pipeline as a diagram. Boxes are stages, double lines are human gates, and the loop on the right is the critics cycle.

And the same thing as a table, with the model choice for each stage. The model names are Anthropic's current line-up, priced in chapter 10. The reasons for each choice are in the stage sections.

The data model#

Most agent pipelines keep state in files or in the conversation. This one can't, because the fact chain needs joins: sentence to card to page to edition. So the core is a relational database. I'll use SQL here because it is the clearest way to show the constraints, but any store that enforces foreign keys works.

Works, editions and copies#

Greene cites a book and a page. A page number only means something inside one edition. The 1930s printing and the 1990s reprint of the same title have different page numbers, so a card that says "p. 212" is meaningless without the edition.

So the model separates three things, the way library catalogues do:

• Work: the abstract book. Title, author, first publication year.
• Edition: one printing with its own pagination. Publisher, year, ISBN if there is one, and page count.
• Copy: the physical or digital object you actually own and scanned. Where it came from, what you paid, the scan files.

The provenance column is there for chapter 14's reasons. A copy has to come from somewhere legitimate. There is no shadow_library value, and the orchestrator refuses to OCR a copy with no provenance.

Interviews and podcasts fit the same shape. The work is the interview, the edition is the specific upload (a YouTube video ID), and the "page" is a timestamp plus a speaker. I'll come back to that under stage 2.

Pages: printed folio against PDF index#

This is the part none of the OCR benchmarks measure, and the part the whole fact chain depends on.

A scanned book has two page numbers for every page. One is the position in the PDF: the 230th image in the file. The other is the number printed on the page, which a reader would cite: page 212. They differ because of the cover, the front matter in roman numerals, unnumbered plates, blank versos, and the occasional skipped or doubled page in old printings. A card has to cite the printed one, because a human checking the card opens the physical book.

folio_source records how the number was found. header and footer mean the OCR engine labelled a block as a page header or footer and a regex pulled a number out of it. interpolated means the page had no visible number (a chapter opener, often) and the number was inferred from its neighbours. manual means a human typed it. Interpolated folios get a lower confidence, and a card on an interpolated page gets a flag for the final read.

The unique index on (copy_id, folio) catches a class of bugs cheaply: if two PDF pages claim to be page 212, something went wrong in the folio pass, and the insert fails.

Marks#

A mark is the digital version of Greene's pencil in the margin: a passage that caught the reader's attention on the first pass, with a quick tag. Marks are cheap and plentiful. Most will not become cards.

The sign column borrows Greene's marginal grammar. He describes exclamation marks for agreement and large crosses for disagreement. story marks a passage that might carry a chapter. fact and idea cover the rest.

Cards#

The card is the centre of the design. The short post's version had seven fields. The full version adds the anchor and the bookkeeping.

The anchor follows the W3C Web Annotation model that Hypothesis uses. Hypothesis stores a highlight as a TextQuoteSelector with three parts: exact (the highlighted words), prefix (a few words before) and suffix (a few words after). It also stores a TextPositionSelector with character offsets. The quote selector is the robust one. If the OCR is re-run and the offsets shift, the prefix and suffix still let a script find the right occurrence of the quote, even when the quote itself is a common phrase that appears five times in the book.

Here is a card as JSON, with placeholder content:

A few fields deserve a sentence each.

• colour is the domain, from Greene's war-book scheme as Holiday describes it (politics, war, arts and entertainment, strategy). For a new book the colours are set at gate 1. They exist for the coverage check under stage 5.
• secondary_themes handles Greene's rule that a card fitting two themes is written out twice. In a database you don't need two copies. You store one card with a list of themes, and the clustering stage treats it as a member of both.
• gloss is the paraphrase, kept apart from the quote so nobody confuses them. Entailment checks run against the quote, never the gloss.
• verified.page_text_sha256 pins the card to the exact OCR text it was checked against. If someone re-OCRs the book with a better model, every card on a changed page drops back to unverified until the quote check passes again. That is invariant I1 in practice.

The SQL:

Themes, chapters and stories#

Themes are the corner labels on Greene's cards. Chapters are groups of themes. Stories are the opening narratives, each built from a set of cards.

The role column on story_card records what the card does in the story: setup, turn, detail, outcome. That matters for the drafter (it knows which card carries the turning point) and for the rubric (a story with no turn card has no turning point on file).

Drafts and sentences#

A draft is a version of one chapter. The text lives in Markdown with inline card tags, because that is what the critics read and what a human can diff. But the fact chain needs sentence-level joins, so every draft is also split into sentences on save.

With this in place, invariant I2 is a query:

An empty result means every tag resolves. Any row is an error finding. Invariant I3 is the same idea: sentences where is_factual is true and there is no row in sentence_card.

Runs#

Every stage execution is a run, and every row any stage writes carries its run_id.

The unique index on (stage, input_key) for succeeded runs is invariant I5. If a run with the same inputs, the same prompt version and the same model already succeeded, the orchestrator reuses its outputs instead of calling the model again.

The stages#

Each stage below follows the same outline: what goes in, what comes out, which model and why, what the prompt asks for, how it fails, and what checks it. The prompts are described, not written out. A prompt is a few hundred words of instructions plus examples, and the examples matter more than the wording. Writing ten of them out in full would fill the chapter and age badly.

Stage 1: Scout#

Input. A one-page brief from the human: the book's working thesis, a list of seed themes (Greene's "20-some" provisional chapters for The Law of the Sublime is the right scale), any books the author already knows they want, and the colour scheme.

Output. About 600 candidate sources, each a row with: work and edition metadata, where to get it (buy, borrow, public domain), which seed themes it serves, how the scout found it (search, a footnote in another source, a catalogue subject heading), and a reason in two sentences. Interviews and lectures go on the same list with a video or episode ID.

Model. Sonnet 5.5 with tools. The scout is a loop of search, read a page, decide, search again. That needs decent judgment (is this a real biography or a self-published summary?) and lots of tool calls. Opus would do it a little better at twice the price per token, and the gate after this stage catches the scout's mistakes anyway. Haiku is cheap enough, but in my experience smaller models are weaker at telling a serious book from a lookalike, and a bad reading list poisons everything downstream. This is a judgment call, not a measured result.

Tools. Open Library for editions and ISBNs. HathiTrust full-text search, which returns which volume and page mentions a term even for in-copyright books. OpenAlex and Semantic Scholar for anything with a DOI, including referenced_works and cited_by to follow footnotes. yt-dlp or a transcript API for interviews. A web search tool for reviews and bibliographies. Chapter 12 covers each one.

Footnote chaining. Greene says one book leads to three others, and warns that it explodes. The scout does the same thing with a depth limit. It reads the bibliography of each strong candidate (from the publisher's preview, a catalogue record, or OpenAlex for academic works), adds the cited works as new candidates with found_via set to the parent, and stops at three levels. A candidate cited by several independent parents gets a boost. That is the cheapest signal of a standard source the scout has.

Prompt outline. The system prompt describes the job as a research assistant's: build a reading list for this thesis, prefer primary sources and serious biographies, prefer the obscure over the popular when both cover the same ground (Greene's own rule), and explain each pick in terms of a seed theme. It lists what counts as a bad source (summaries, listicles, AI-generated "books" with no author history). Examples show three good entries and two rejected ones with the reasons.

Failure modes.

• Invented books. The worst case, and a real one: the Chicago Sun-Times reading list in 2025 had ten books that did not exist (chapter 13 has the story). Every candidate must resolve against Open Library, a library catalogue, OpenAlex or Crossref before it is saved. A candidate that resolves nowhere is dropped, and the drop is logged.
• Popularity bias. Search results favour bestsellers. The prompt pushes against this, and the footnote chain helps, because old scholarly books cite other old scholarly books.
• Runaway expansion. The depth limit and a hard cap on candidates per seed theme stop this.
• Tool errors. Rate limits and timeouts are retried with backoff. A source API that is down for an hour pauses the run; it doesn't fail it.

Gate 1. The human gets the list grouped by seed theme, sorted by how many parents cite each candidate, with the reason next to each one. They cut it to the real reading list (the short post's 400) and mark which books to buy, which to borrow and which are public domain. They also confirm or edit the seed themes and the colours. The approved list is frozen. Adding a book later is allowed but goes through the same gate as a single-item change.

Cost. Small next to the reading. See chapter 10.

Stage 2: Acquire#

Input. The approved list.

Output. For each source: a copy row with provenance, an archival searchable PDF, and a page row for every page with body text, printed folio, folio source and per-block coordinates. For interviews: a transcript with timestamps and speakers.

Model. No language model makes decisions here. OCR models do the text. A small model can help with one sub-task (reading folios when the regex fails), described below.

Physical steps. Buying is a human task or a purchasing script. Scanning is either destructive (cut the spine, feed a sheetfed duplex scanner) for cheap copies, or non-destructive (a V-cradle with two cameras) for rare ones. After capture, ScanTailor-style tools split, deskew and crop. Then the OCR.

OCR. Two outputs per book. First, an archival PDF with a text layer, made with OCRmyPDF, which keeps the page images. This is what a human opens to check a card. Second, structured text: marker, docling or olmOCR, which give per-page blocks with bounding boxes and labels for headers and footers. For old or degraded scans, the olmOCR-Bench "old scans" column is the one to read before picking an engine (chapter 12 has the table).

The folio pass. This is the check the pipeline needs that no benchmark tests. It runs after OCR:

1. For each page, take the blocks the OCR labelled as header or footer. Run a regex for an arabic number, or a roman numeral in the front matter.
2. Build the sequence of found folios against PDF index. In a healthy book, the folio increases by one per page, with gaps on chapter openers and plates.
3. Fit the sequence. Where a page has no folio but its neighbours do (say 211 and 213), interpolate 212 and set folio_source = 'interpolated'.
4. Flag breaks: a folio that goes backwards, a jump of more than a few pages, or two pages with the same folio. These usually mean a missed page in scanning, a misread number ("212" OCR'd as "2l2"), or a plate section.
5. If more than a small share of pages are flagged (a design threshold, say 2%), the book goes to a human with the flagged pages shown side by side.

A small vision model can read the folio from the page image directly when the OCR missed the header. That is a narrow, checkable task: the answer must fit the sequence, or it is rejected.

Interviews. The "page" of an interview is a timestamp. Captions from yt-dlp give timestamps but no speakers, and auto-captions contain errors (this report's own transcripts do: "barbaric" comes out as "bar barbaric" in one of them). WhisperX gives word-level timestamps and speaker labels. A card from an interview stores the video ID, start and end seconds, and the speaker, so its "page" is a URL with &t= that a checker can open.

Failure modes. Bad scans (blur, curvature near the spine), wrong reading order on two-column pages, footnotes merged into body text, and running heads left in the body. Each has a check: a word-level confidence threshold from the OCR engine, a comparison of character counts against neighbouring pages, and a rule that strips any line identical to the running head.

Cost. Mostly the books and the scanning labour. OCR is cents per book on hosted APIs and free self-hosted. Chapter 10 has the numbers.

Stage 3: Margin pass#

Input. One book's pages, plus the approved seed themes.

Output. Marks: verbatim passages with page, offsets, a provisional tag and a sign. Greene's rate for a good book is 20 to 31 cards. The margin pass should mark more than that, because the second pass will throw about half away. A target of 40 to 80 marks for a good book is a reasonable design choice.

Model. Haiku 5.5, through the batch API. This is the bulk reading: 400 books, every page. It needs to notice interesting passages and copy them exactly, not judge them deeply. That is the cheapest stage to run at scale, and the one where a cheap model's mistakes cost least, because the next stage re-reads everything it kept.

One pricing detail shapes the design. Haiku 5.5 is priced per token at a low rate for prompts up to 100,000 tokens and five times more above that. A whole book is about 130,000 tokens. So the margin pass reads books in chunks under 100,000 tokens (a chapter or two at a time), each chunk with the seed themes in a cached prefix. Chapter 10 works through what that saves.

Prompt outline. Read these pages as a researcher would on a first pass with a pencil. Mark passages that tell a story, state a striking idea, give a vivid detail or contradict the thesis. Copy each one exactly as it appears, including its spelling and punctuation. Give a one-word tag from the seed themes, or a new tag if none fits. Do not paraphrase in the quote field. Do not mark more than a set number of passages per chapter. The output is a list of objects, one per mark.

Getting quotes back exactly. The model is asked to copy text, and models sometimes "fix" old spelling, smooth over hyphenation or drop a clause. Two designs help. The first returns offsets instead of text: the pages are given with line numbers, and the model returns a page, a start line and an end line, and code cuts the quote out of the OCR text. That makes the quote exact by construction, at the cost of coarser selections. The second asks for the text and checks it. This design does both: the model returns a line range and the quote, and the check compares them.

Checks. Every mark's quote must string-match its page after normalization (the method is under the critics section, because the same function is reused there). A mark that fails is retried once with the page text and the failed quote shown to the model. A mark that fails twice is dropped and counted. A book where more than a set share of marks fail goes to a human, because it usually means the OCR is bad, not the model.

Cost. The cheapest stage per token, and the biggest by volume. See chapter 10.

Stage 4: Second pass, or the two-month wait#

Greene's process has a delay built in. He marks a book, puts it aside, and comes back later to make cards. He told Olivier Roland that he does this "maybe two months later": "I go back to that book and I take notes on cards based on my little highlights."

The wait matters because the reader has changed. Two months and a dozen books later, some of what jumped out the first time doesn't jump anymore, and some marks that seemed minor now connect to something else. A model does not have two months. What it can have is a fresh context and more information than it had on the first pass.

Input. One book's marks, plus the current theme map: the seed themes, plus every new tag the margin pass invented across all books, with counts. Plus a short summary of what the other books have contributed to each theme so far.

Output. The same marks, each with kept set to true or false and a one-sentence keep_reason. A kept mark can also get its tag changed.

Why a fresh context. The second pass must not see the first pass's reasoning. If it does, it tends to agree with it. So the second pass gets the marks and the page text around each one, never the first pass's conversation or notes. That is the closest a model gets to forgetting.

Why later. The second pass for a book runs only after the margin pass has finished for a large share of the reading list (a design choice, say 70%). That is the engineering version of the wait. By then the theme map shows which themes are thin and which are crowded. A mark about envy that looked strong in isolation might be the fifteenth near-identical one, and a mark about a minor theme might be the only one the book list has.

Model. Sonnet 5.5, batch. This pass makes real judgments: keep or drop, and why. It reads much less text than the margin pass (only the marks and their surroundings), so the better model is affordable.

Prompt outline. You are re-reading your own highlights two months later, with this theme map in front of you. For each mark: does it still matter? Is it a story, a fact the book needs, or just something that was interesting at the time? Is it a near-duplicate of something the theme already has plenty of? Keep about half. Give a reason that would convince a skeptical editor.

Checks. The survival rate per book. Greene's numbers give a rough target: a good book yields 20 to 31 cards and a bad one two or three. If the second pass keeps 95% of a book's marks, it is not doing its job, and if it keeps 5% of a book the human rated highly at gate 1, something is off. Both cases go to a review queue. Neither is automatically wrong.

What this does not replace. The wait also changes Greene, not just his view of the book. That part has no engineering version. The second pass is a re-read with better information, which is useful, but it is not the same thing.

Stage 5: Carder#

Input. Kept marks, with the page text around each one.

Output. Cards in the schema above: verbatim quote with prefix and suffix, gloss, note, theme, colour, source.

Model. Sonnet 5.5, batch. The carder writes the gloss and the note, which need to be precise and short, and decides the colour. It does not choose the quote. That was chosen at stages 3 and 4, and the carder may only trim it (start later or end earlier), never extend or rewrite it.

Prompt outline. Turn this marked passage into a notecard. The quote stays exactly as given, or trimmed to the essential sentence. Write a one-sentence gloss in plain words. Write a note saying what this card does for its theme: is it evidence, a story beat, a counterexample? Pick a colour from this list. Return one object per card.

Structured output. The carder returns JSON, so it uses the API's structured output mode, with a schema that requires every field. That is one of the two places where the design runs into a limit of the Citations API, covered under orchestration below.

The verbatim check. Before a card is saved as verified, code runs the quote check against the page. A trimmed quote must be a substring of the original mark's quote. Then the prefix and suffix are computed by code from the page text, never by the model. A card whose quote fails is saved as failed, retried once, then sent to a human.

Colour coverage. Greene spreads a chapter's cards on a table and sees, for example, that there's nothing blue. The script version runs after stage 6 assigns cards to chapters, but the data comes from here. For each chapter, count cards by colour. Flag any chapter where a colour the human marked as required is missing or below a threshold. Show it as a small table:

Here chapter 3 has no science and chapter 4 has no war. Whether that matters is a human call. The script's job is to make the gap visible, which is all Greene's coloured cards do too.

Cost. See chapter 10. Output tokens dominate here, but 10,000 cards of about 200 tokens each is a small bill.

Stage 6: Architect#

Input. All verified cards, the seed themes, the thesis.

Output. A theme map (each card assigned to one or more themes, with new themes proposed where clusters don't fit any seed) and a chapter plan: for each chapter, a title, a one-paragraph thesis, the themes it covers, its cards, and a word budget.

Two steps: cluster, then plan. The clustering is not done by a language model reading every card. It is done by a topic model, and the language model works on the clusters.

Clustering. BERTopic is the tool to model this on. It embeds each text, reduces the embeddings with UMAP, clusters them with HDBSCAN, and labels each cluster with its most distinctive words (c-TF-IDF). Three of its features fit this stage:

• Guided (seeded) topics. You give it the seed themes as lists of keywords, and it nudges clusters toward them. That matches Greene's process: he starts with provisional chapters and lets the cards push back.
• Hierarchical topics. It can merge clusters into a tree. The top level maps onto chapters and the next level onto sections within a chapter.
• LLM labelling. It can ask a language model to name each cluster from its top cards, which gives human-readable labels for the gate.

What goes into the embedding matters. Embedding the quote alone clusters cards by the source's vocabulary (all the 1930s books end up together). Embedding the note, which is in the carder's own words and says what the card is for, clusters them by function. The design embeds the note plus the gloss, and keeps the quote out.

HDBSCAN leaves some cards as outliers. That is useful information. An outlier card is either noise or the seed of a theme nobody planned. The architect gets the outliers as a separate list.

Planning. Opus 5.5 gets the cluster tree, a sample of cards from each cluster (not all of them), the outliers, the seed themes and the thesis. Its job is to turn about 20 clusters into a chapter plan of about 12, the way The Law of the Sublime went from "20-some" planned chapters to 12. It proposes merges, splits and drops, and gives a reason for each. It also assigns word budgets per chapter and per section, which is LongWriter's main lesson (chapter 12): a model writes long text better when each section has a target length.

The whole card set fits in a 1M-token window (Greene's box of 2,000 to 3,000 cards is around half a million tokens), so the architect can read everything at once. The design still gives it samples, for two reasons. A model reading 10,000 cards attends unevenly, and the clusters already did the grouping. The architect can request the full card list of any cluster with a tool call when it wants to check something.

Model. Opus 5.5. This is the stage where structure gets decided, and STORM's evaluation found that outline quality drives article quality (chapter 12 has the numbers). It runs once per book and reads relatively little, so the price of the best model barely registers.

Prompt outline. Here is the thesis, the provisional chapters, and what the cards actually cluster into. Propose a chapter plan. For each chapter: what it argues, which clusters feed it, what it lacks. Point out clusters with lots of cards and no clear argument, and seed themes with few cards. Do not invent themes the cards don't support.

Gate 2. The human sees the plan beside the cluster tree, the colour coverage table per chapter, and the outliers. They edit titles, merge or split chapters, move clusters, and approve each chapter's thesis. Approval freezes the chapter list. Cards keep flowing in from late books, and the architect can propose assigning them, but changes to the plan itself go back through the gate.

Stage 7: Story hunter#

Greene calls finding the stories "the whole work," and says it is "probably what has aged me a lot." To David Perell, he described what he looks for: people "dying for a cause or making a mistake and dying" is "so elemental, so basic." The researchers who failed him, he says, had no sense of drama. This stage is where that judgment would go, and it is where the design is least sure a model can do the job.

Input. One approved chapter: its thesis, its cards, and the cards in neighbouring clusters.

Output. Five candidate stories for the chapter's opening, each with a subject, a two-sentence logline, the cards that support it (with roles), a rubric score with reasons, and a list of further sources to read before drafting. Greene reads a second, third and fourth biography of a subject at the last minute. The story hunter's "further reading" list is that step.

Where candidates come from. Story candidates are built from cards marked with sign = 'story' and from clusters of cards about the same named person or event. A person who appears on many cards across several books in the chapter's themes is a candidate. So is a single strong card from one book, flagged by the second pass as "this could carry a chapter." Greene's Harriet Tubman example cuts the other way: he read about her early and only found her place later, when he reached the chapter on the daemon. So the story hunter for each chapter searches all cards, not just the chapter's own.

The rubric. Six criteria, each scored 1 to 5 with a one-sentence reason that cites a card.

The "BOOM" line comes from his talk at Google. The sensory-detail and hologram lines come from the Perell interview.

Each score has to point at evidence. "Turning point: 4, see card X-12, where <placeholder for the reversal>." A score with no card is treated as a 1. That keeps the rubric honest: a story with high drama and no cards for the turn is a story you'd have to make up.

Model. Opus 5.5. This is the hardest judgment in the pipeline and it runs only once per chapter.

Prompt outline. Here is the chapter's argument. Here are cards about people and events. Propose five opening stories. For each one, tell the story in two sentences, score it on the six criteria with a card for each score, say which parts are thin, and list the sources you'd need to read to tell it well. Prefer stories the reader is unlikely to know. Rank them.

Why a human picks. Three reasons, in order of weight.

1. Drama is the open question. The short post said it, and this chapter's design doesn't change it. A model can rank candidates by a rubric. Whether the rubric captures what Greene means by drama is untested. There is no benchmark for "would this story have carried a Greene chapter."
2. Model judges are lenient. Agent Laboratory's write-ups report that LLM reviewers scored papers about 2.3 points higher than human reviewers did (chapter 12 has the caveats on that figure). A model scoring its own story candidates will tend to like them.
3. The choice is the book. Greene's books are recognisable by their stories. If a model picks them, the model is the author in the way that matters. The design keeps that with the human on purpose.

Gate 3. Per chapter. The human sees the five candidates side by side, each with its rubric, its cards (click through to the page image), and its further reading. They pick one, or reject all five and ask for another round with a note ("too familiar", "I want someone from the sciences"). They can also pick a story the hunter didn't propose, by naming the cards. The choice and the note are saved. Then the further reading for the chosen story goes back to stage 2 as a small acquisition order, and its cards come through stages 3 to 5 before drafting starts.

Stage 8: Drafter#

Input. One chapter: its approved thesis, its chosen story with role-tagged cards, the rest of the chapter's cards grouped by section, the word budget per section, and the style guide (the Greene Vale rules as plain-English instructions).

Output. A Markdown draft where every factual sentence ends with one or more [card:ID] tags.

Model. Opus 5.5, or the human. The design is the same either way. If the author drafts by hand (or by dictation, as Greene does since his stroke), the tagging can be done afterward by a model that proposes card IDs for each sentence and a human who accepts them. That is a cheaper and more honest version of the pipeline, and it keeps Greene's own line, from his 2026 Perell masterclass: "You don't let it compose paragraphs for you." Chapter 15 comes back to that choice.

Structure. Greene's template goes back to The 48 Laws: the story first, then the interpretation. The drafter follows the section plan from stage 6, writing the opening story from its role-tagged cards (setup, turn, details, outcome), then the analysis sections, each from its own cards.

The card tag format. Tags go at the end of the sentence, before the period's trailing space:

A sentence with two claims from two cards gets two tags. A sentence of the author's own interpretation gets none, and the claim classifier in stage 9 decides whether that is allowed.

Prompt outline. Write this chapter section by section. Use only facts that appear on the cards you are given. Every sentence that states a fact about the world must end with the ID of the card it comes from. Quotation marks are allowed only around text that appears word for word in a card's quote. If you need a fact that no card supports, write [card:NEEDED: <what you need>] instead of inventing one. Hit the word budget for each section within 15% (a design tolerance).

The NEEDED escape hatch matters more than it looks. Without it, a model that needs a bridging fact will invent one, because writing a fluent paragraph is what it is trained to do. With it, the gap becomes a finding the human can act on: read another source, add a card, or cut the sentence.

The invariant. I2 says every [card:ID] resolves to a verified card. The drafter cannot break it silently, because the save step parses every tag and rejects a draft that cites an ID that doesn't exist. NEEDED tags are allowed to save but block the chapter from gate 4.

Context. A chapter's cards (Greene uses about 60 per chapter, the pipeline might use more) plus the style guide plus the previous chapters' summaries fit easily. The card set and style guide go in a cached prefix, so each revision in the loop only pays full price for the new part. Chapter 10 has what caching saves across twenty drafts.

Stage 9: Critics#

The critics are the stage where drafts get to twenty. They have their own section below, because they are the bulk of the design. In summary: Vale for rules, a deterministic quote check, an entailment model for card support, a link checker, an n-gram repetition critic, and a bored-reader agent. They write findings. The drafter reads the findings and writes the next version. The loop stops on a clean pass or a retry limit.

Stage 10: Readers#

Greene's version: once a story is good enough, his wife reads it, then his editor. The pipeline's version is the same. Humans read the chapter. The difference is what they get with it: the clean critic report, a list of every waived finding with who waived it and why, a random sample of sentences with their cards and page images (for spot-checking the checkers), and a diff against the version they last read.

Reader notes go in as findings with critic = 'human'. They can send the chapter back to stage 8, to stage 7 (wrong story), or rarely to gate 2 (the chapter shouldn't exist). Gate 4 is approved when the human says so. No metric approves it.

The critics loop#

Each critic reads a draft and writes findings to the finding table. Findings have a severity. Errors block the chapter. Warnings go to the drafter, which must fix them or argue for a waiver. Suggestions are logged and shown to the human at gate 4 but don't block anything.

The critics run in a fixed order, cheapest and most deterministic first. There is no point asking an entailment model whether a sentence is supported by a card that doesn't exist.

Vale, with the Greene style#

Vale is a prose linter. Rules are YAML files, each one extending a rule type (existence, substitution, occurrence, repetition, metric, conditional and a few others). It reads Markdown and skips code blocks. With --output=JSON it prints every alert with its line, column, rule name and message, and its exit code fails the run when there are errors. That makes it the easiest critic to wire into an agent loop: the drafter reads the JSON, finds the line and fixes it.

The short post introduced the Greene style. Here it is in full, as published on this site:

Three of them in full. The chapter cap uses Vale's metric type, which computes a formula over the document:

The moralizing rule is a plain word list. It is short on purpose. Each entry is a phrase that, in this genre, almost always means the writer is judging instead of showing:

And the rule that ties Vale to the card system. It works on paragraphs and flags any four-digit year that is not followed, on the same line, by a card tag:

This rule is crude. A paragraph about "the 1930s" with no card trips it, and a factual sentence with no year passes it. That is why it is only the first pass on invariant I3, and the claim classifier below does the real work. But it is free, it runs in milliseconds, and it catches the commonest failure (a date the drafter remembered instead of reading).

The full config and every rule file are at vale.ini and styles/Greene/ next to it. Two packages from Vale's catalogue are worth stacking on top, both covered in chapter 12: ai-tells for model tics (with some of its rules turned off for narrative history), and readability for sentence-length metrics.

Some rules are worth adding for the pipeline that aren't about Greene's prose at all:

• Tag format. An existence rule with a raw regex for malformed tags: [card: ID] with a space, [cards:...], (card:...). A malformed tag would fail the resolver anyway, but Vale gives a clearer message.
• NEEDED tags. An existence rule that turns every [card:NEEDED: ...] into an error, so the count shows up in the same report as everything else.
• Mined tics. Rules generated from the repetition critic's output, described below.

The quote check#

Quotations are where the famous failures happen. Chapter 13 has the incidents; the pattern is a quote attributed to a person who never said it. The quote check makes that structurally hard. It has two jobs:

1. At card creation (stages 3 and 5): is this card's quote on this page?
2. In the critics stage: is every quotation in the draft a substring of one of the sentence's cards?

Both use the same function. It normalizes both strings, tries an exact match, then falls back to a fuzzy match, and uses the Hypothesis-style prefix and suffix to pick the right occurrence.

Normalization is where most of the work is. OCR text and model output differ in ways that have nothing to do with meaning:

A sketch in Python, using RapidFuzz for the fuzzy step:

The thresholds are design choices. The research dossier for this report suggests exact match after normalization with a fuzzy fallback at about 95. I'd use three bands:

• 100 (exact or exact with context): pass.
• 95 to 99 (fuzzy): pass, but store the matched page text as the card's quote, replacing what the model wrote. The card then quotes the page, not the model's memory of it. Log the difference, because a pattern of small differences from one book usually means an OCR problem.
• Below 95: fail.

For the draft-level check, the function runs on each quoted span (text inside quotation marks) against the quotes of the sentence's cards. A quotation that matches none of them is an error. This catches the subtle case: the drafter quotes accurately from a card, but attaches the wrong card to the sentence.

Claim classification#

Invariant I3 needs a way to tell factual sentences from interpretation. "In <year>, <subject> left <city>" is factual and needs a card. "Envy, in the end, hides itself best from the envious" is interpretation and doesn't. Greene's chapters mix both, and the interpretation is the part that is his.

A small classifier does this well enough for a first pass. The approach VeriScore takes is to extract only verifiable claims and skip the rest (chapter 12). Here the classifier only has to label each sentence: factual, interpretive, mixed. A Sonnet 5.5 call over a whole chapter, returning one label per sentence index, is cheap. factual and mixed sentences without a card are errors. The drafter fixes them by adding a card, rewording the sentence as interpretation, or adding a NEEDED tag.

The classifier will make mistakes, mostly on borderline sentences ("He was, by every account, impossible to work for" is a factual claim about accounts). The human sees the waived and the borderline cases at gate 4.

Entailment#

The quote check proves a quotation is real. It doesn't prove a paraphrase is fair. For that, each factual sentence is checked against its cards' quotes with an entailment model.

MiniCheck is the model to start from. It takes a document and a single-sentence claim and returns a probability that the document supports the claim. Its README says to split text into sentences first, which is exactly the shape of the sentence_card table. The 770-million-parameter version runs on a laptop CPU, slowly. On the LLM-AggreFact leaderboard, the best checkers score in the high 70s, and nobody is near 90. So entailment flags sentences for review. It does not certify them.

A study of these checkers by Godbole and Jia (2025) found two weak spots: heavy paraphrase, and claims supported by a distant part of the source. The card design avoids both. The "document" for each check is one to three card quotes, a few hundred characters, sitting right next to the sentence. There is no distance to cross.

The routing:

1. MiniCheck scores each (sentence, concatenated card quotes) pair.
2. High probability (a design threshold, say above 0.9): pass.
3. Low probability (say below 0.5): error, sent back to the drafter with the card quotes shown.
4. In between: a second opinion from Sonnet 5.5 with the sentence, the quotes and a narrow question ("Does the quote support every part of this sentence? List any part it does not support."). Its answer becomes the finding.
5. Anything the drafter can't fix in two rounds goes to the human.

LettuceDetect, also covered in chapter 12, can mark which words of a flagged sentence lack support. That makes the finding more useful: "the quote supports the departure, not the date."

Links and references#

Two kinds of pointer can break outside the card system.

• URLs. Interview cards point to YouTube timestamps, and the bibliography has web sources. lychee checks every URL in the Markdown, caches results, outputs JSON and returns a non-zero exit code on a broken link. In the Penn study cited in the short post, link checking cut broken citations by 6 to 79 times.
• References. Every work in the bibliography must resolve to a record: Open Library by ISBN for books, Crossref or OpenAlex for anything with a DOI. The resolver checks title, author and year with a fuzzy match. This is the check that would have caught every fake book on the Sun-Times list. In this pipeline it should never fire, because works only enter the database after resolving at stage 1, but it costs nothing to run again.

Repetition#

Greene's own rule, to Perell: "This idea here is repeated over there. I have to change that." He says it about the Harriet Tubman story: he can't repeat in one place what he said in its interpretation.

Vale can't do this. Its repetition rule only catches a word repeated back to back. So the repetition critic is its own script, with two levels.

Phrase level. Build every 4-gram to 6-gram of the whole manuscript (all chapters, tags and quotations stripped). Count each one per chapter. Flag n-grams that appear in more than one chapter, and any that appear more than a few times in one. Filter out n-grams made only of stopwords and the book's own key terms (a book on power can say "power" a lot). What's left is the writer's tics: the drafter's favourite transitions, the phrase it reaches for at the end of every section. The method borrows from slop-forensics, which compares a model's output against a human baseline to find over-used words and phrases. Here the baseline can be the author's earlier books, if the author wants to sound like themselves, or a general corpus. The most frequent tics become new Vale existence rules, so the next draft gets them flagged inline.

Idea level. Embed every paragraph of the manuscript. For each paragraph, find its nearest neighbours in other chapters. Pairs above a similarity threshold go to an LLM with a narrow question: are these two paragraphs making the same point? If so, which chapter should keep it? This is the cross-chapter check Greene does in his head. It only works once several chapters exist, so it runs at the book level as well as per draft.

Repetition findings are warnings. Sometimes a callback is deliberate.

The bored reader#

Greene says he is "very aware of my audience, I'm very aware of when they're going to get bored," at Google, and that he structures his books "to have continual little pops" so the reader is "never quite bored". He also says that once a chapter gets past 20,000 words, his own eyes glaze over and he cuts.

The bored-reader critic is a language model reading the chapter cold. It gets the chapter text with tags stripped and no other context: no thesis, no cards, no previous drafts. Its job is to say where it stopped caring.

Prompt outline. You are a reader who picked this book up in a shop. Read the chapter. Mark the first paragraph where your attention dropped, and say why in one sentence. Then mark every paragraph you would have skimmed. Then name the moment you most wanted to keep reading. Don't comment on style or grammar.

Panel. One reader is one opinion. autonovel, a fiction pipeline covered in chapter 12, uses a four-persona reader panel. The design here borrows that: three or four reader personas (a history buff, a business reader who came for the laws, a skeptic, a reader who has read Greene before) run in parallel. A paragraph flagged by most of them is a real problem. A paragraph flagged by one is a note.

Model. Sonnet 5.5. Readers should be cheaper than the drafter and should not be the same model, so their tastes are less correlated with the drafter's. Using a different model family for one panel seat is worth considering for the same reason.

What it can't do. A model that never gets bored is being asked to simulate boredom. The findings are useful as pointers, the way a beta reader's are. They're not a measurement, and the loop never treats a clean bored-reader pass as proof the chapter is good.

Loop control#

The critics write findings; the drafter writes the next version. Left alone, this loop can run forever, or worse, oscillate (fix A, break B, fix B, break A). Four rules keep it in line.

1. Edit-only after round two. The first two revisions can rewrite freely. After that, the drafter gets the findings and the current text and may only make local edits: replace this sentence, cut this paragraph, add a tag. Hyperresearch's patcher, which can only make surgical edits, is the model here (chapter 12). It stops the late rounds from rewriting good paragraphs to fix one bad one.
2. Monotonic errors. Each round must reduce the error count. A round that adds errors is rolled back, and the drafter tries again with the regression shown.
3. A round limit. A design choice: eight automated rounds per chapter, then the chapter goes to the human with whatever is left. Greene's twenty drafts include the human's.
4. Waivers have names. A warning can be waived, but only by a human, with a reason, stored in finding.resolution. The drafter can propose a waiver ("this callback to chapter 2 is deliberate") but not grant one.

Orchestration#

A state machine per unit of work#

Each unit of work (a book through stages 2 to 5, a chapter through stages 7 to 10) has a state, and the orchestrator moves it forward one transition at a time. For a chapter:

Every transition is a row in an append-only transition table with the run that caused it. The current state of anything is the last row. That gives a full history for free, and it makes the human gates ordinary transitions with a human actor instead of special cases.

This can be built on a workflow engine, a job queue, or plain cron and a database. The choice doesn't matter much. What matters is that a gate is a state the orchestrator can't leave without a human row, and that every stage reads its inputs from the database and writes its outputs back, so any stage can be re-run alone.

Idempotence and caching#

Invariant I5 says re-running a stage with the same inputs gives the same stored outputs. Language models aren't deterministic, so "the same outputs" means reused, not regenerated. The input_key on each run is a hash of: the stage name, the prompt version, the model ID, and the content hashes of every input row. Before calling a model, the orchestrator looks for a succeeded run with that key. If there is one, it uses its outputs.

That makes three things cheap that would otherwise be expensive or risky:

• Resuming after a crash. Re-run the whole pipeline; everything already done is a cache hit.
• Fixing one book's OCR. Pages change, so their hashes change, so the marks and cards for that book get new input keys and re-run. Nothing else does.
• Changing a prompt. Bump the prompt version for one stage. Only that stage and its downstream work re-run.

The second cache is the model provider's prompt cache. It is a prefix match: any change early in the prompt invalidates everything after it. So every prompt in this design is laid out stable-first: system instructions, then the style guide or theme map, then the chapter's cards, then the variable part (the draft, the findings, the page chunk). For the drafter's loop, the cards and style guide are identical across all revisions of a chapter, so after the first round they are read from cache at a tenth of the input price or less. Chapter 10 puts numbers on this.

The batch API#

Stages 3, 4 and 5 are bulk work with no human waiting on them. The batch API takes a file of requests, runs them within a day, and charges half price for both input and output. Results come back in any order, so every request carries a custom_id (the book, chunk and stage), and the orchestrator writes results by ID, never by position. A request that errors or expires inside a batch is retried in the next batch, not the same one.

The interactive stages (scout, architect, story hunter, drafter) don't use batch. They are tool loops or need fast turns, and they are a small share of the tokens.

Where the Citations API fits#

Anthropic's Citations API is the closest off-the-shelf match to the card idea. You pass documents with citations enabled, and the model's answer comes back split into text blocks, each cited block carrying the exact cited_text and a location. The docs say citations are guaranteed to contain valid pointers to the provided documents.

That guarantee is attractive for stage 3. Instead of asking the model to copy quotes and then checking them, you ask it to cite the passages it marks, and the API hands back text that is in the source by construction.

The details matter, though.

• The page number is the PDF's, not the book's. For a PDF document, citations come back as page_location with a 1-indexed start and end page. That is the PDF index, not the printed folio. The page table maps one to the other, so this works, but only because stage 2 did the folio pass.
• Custom content documents give finer control. Instead of a PDF, you can pass a document made of content blocks, one block per page of OCR text. Citations then come back as content_block_location, which maps directly to pdf_index. And the text is the pipeline's own normalized OCR, not the model's reading of the page image, so the quote check has nothing to disagree with.
• It can't be combined with structured outputs. The docs are explicit: enabling citations together with a structured output format returns an error. So a single call can't return both "cards as JSON" and "citations." The design splits it. Stage 3 runs with citations on and asks for free-text marks, one per cited passage, with a tag word after each. Code parses the citation blocks into mark rows. The carder (stage 5) then runs with structured outputs on and citations off, taking those verified marks as input.
• Size limits. PDF documents have a page and request-size limit (600 pages per request at the time of writing), which most books fit. Chunking by chapter under Haiku's 100,000-token price step makes this moot anyway.

So the Citations API doesn't replace the quote check. It makes stage 3's quote check almost always pass. The check still runs, because "almost always" isn't invariant I1.

Failure handling#

Two of these are worth a word. A refusal on a history book is not as rare as you'd think: chapters about war, poisoning or cons can trip a safety classifier on a passage that is pure history. The design logs the category and routes to a human rather than rewording the request until it passes. And truncation matters for the drafter, whose output is long. Streaming with a generous output limit avoids most of it; the rest is caught by checking the stop reason before saving a draft.

The human gates in practice#

The gates are the point of the design, so their interface deserves the same care as the stages. A gate that is tedious gets rubber-stamped, and a rubber-stamped gate is no gate.

One queue. Every pending human decision goes into one approval queue, sorted by what it blocks. A gate 3 decision that blocks a chapter draft comes before a waiver on a warning. Each item shows what it is, what it blocks, and how long it has waited.

Decisions show evidence, not summaries. The reading-list gate shows each candidate's reason and its citing parents. The story gate shows the rubric with each score's card, and a click on a card opens the page image with the quote highlighted (the bounding boxes from stage 2 make this possible). The final read shows the chapter with its cards in the margin, which is the closest a screen gets to the layout of The 48 Laws.

Diffs between drafts. Between versions of a chapter, the human sees three diffs:

• A word-level text diff, with tags hidden, for reading.
• A card diff: which cards were added, which were dropped, which sentences changed their cards.
• A findings diff: which findings were fixed, which are new, which were waived and by whom.

The card diff catches something the text diff hides. A revision that reads better but has quietly dropped the only card for a key claim shows up as a removed card next to a sentence that still makes the claim.

Spot checks of the checkers. At gate 4, the human gets a random sample of sentences that passed every critic, with their cards and page images. Checking a dozen of these per chapter is the only way to know whether the critics are working. If the human finds a passed sentence that is wrong, that's a finding against the critic, logged separately.

Keyboard first. Approve, reject with a note, open the page, next item. Gate work is high-volume at gate 1 (hundreds of books) and slow at gate 3 (one story per chapter). The interface should be quick for the first and roomy for the second.

Observability#

Every run logs its tokens in, out and cached, and its cost. That gives a cost per stage per book, which is the first number anyone asks for.

The more useful numbers are about quality, tracked over time and per source:

• Quote-check failure rate per book and per OCR engine. A spike in one book means a bad scan. A difference between engines is a reason to switch.
• Mark survival rate per book at stage 4. Compare against the gate 1 rating the human gave the book.
• Cards per chapter by colour, the coverage table above.
• Findings per round per critic for each chapter. A healthy loop shows errors falling to zero and warnings falling and levelling off. A loop where one critic's findings bounce is oscillating.
• Entailment score distribution. If most pairs sit in the uncertain middle band, either the threshold is wrong or the drafter is paraphrasing too freely.
• Human override rate. How often the human rejects all five stories, waives a finding, or finds an error in a sentence the critics passed. This is the one number that measures the machine against the person it serves.

Traces should link a sentence in a final draft back through its card, its mark, its page, its copy and the run that made each one. That's what turns "where did this come from?" from an investigation into a click.

A worked walk-through#

Here is one chapter end to end. Everything specific in this section is hypothetical: the chapter, the counts, the IDs and the scores are invented to show the mechanics. Placeholders like <quote from p. 212> stand for text that would come from a real page. No historical claim is being made.

Setup. The book has a thesis and 22 seed themes. Gate 1 approved 380 sources: 340 books and 40 interviews. Stages 2 to 5 have run on all of them.

Stage 6 output. BERTopic, seeded with the 22 themes, finds 26 clusters plus about 400 outlier cards. The architect proposes 12 chapters: it merges four pairs of seed themes, drops two seed themes that drew fewer than 20 cards each, and turns one large outlier group into a new chapter. At gate 2, the human accepts 11 of the 12, merges the new one into an existing chapter, and edits three titles. Call the chapter we follow Chapter 4, on a placeholder theme <theme X>. It gets 140 cards and a budget of 14,000 words.

Coverage check. Chapter 4's colour table shows 70 biography cards, 31 arts, 22 politics, 17 science and zero war. The human decides war doesn't belong in this chapter and moves on.

Stage 7. The story hunter searches all 9,000 verified cards for people and events that fit <theme X>. It proposes five:

Each score carries a card. For candidate 2, the turning point score cites card B-14, whose quote is <quote from p. 301 describing the reversal>.

Gate 3. The human reads all five. Candidate 1 is strong but well known. Candidate 2 has the best turn and a low sensory score, because the cards come from one dry source. The human picks candidate 2 with the note "best turn; needs a second source with physical detail." The story hunter's further reading for candidate 2 lists two more books. Both go to stage 2 as a small order.

Further reading. The two books arrive, are scanned, and run through stages 3 to 5. They yield 23 new cards about <Person B>, 9 of them tagged with sensory detail. The story now has 30 cards with roles: 6 setup, 3 turn, 15 detail, 6 outcome.

Stage 8, version 1. The drafter writes 16,200 words: the story first, then four analysis sections. It uses 118 of the chapter's 163 cards and leaves three [card:NEEDED: ...] tags, one of them [card:NEEDED: the year <Person B> left <city>].

Stage 9, round 1. The critics report:

The quote-check error is worth following. A sentence reads: She told him that <quoted phrase>. [card:B-22]. The quoted phrase is not in card B-22's quote. It is in card B-23's, from the next page. The drafter attached the wrong card. The fix is one tag.

The NEEDED tags. Two can be filled from existing cards the drafter missed (the human points to them). The third, the year, isn't on any card. A human looks it up in one of the two new books, finds it on a page the margin pass skipped, and adds a card by hand. Hand-made cards go through the same quote check.

Rounds 2 to 5. The error count falls 25, 9, 3, 0. Round 3 is rolled back once, because the drafter's fix for a bored-reader flag cut the only sentence carrying card B-17 and the claim classifier caught the orphaned claim in the next paragraph. Warnings level off at 12, most of them deliberate repetitions the drafter argues for. The word count comes down to 13,600 after the bored-reader flags lead to cutting one analysis section by half.

Gate 4. The human gets version 5, the card diff against version 1 (31 cards dropped, 9 added), the 12 open warnings with the drafter's waiver requests, and 15 randomly sampled passed sentences with their page images. They grant 9 waivers and refuse 3. They find one sampled sentence where the card supports the claim but the claim overstates it ("always" where the source says "often"). That goes in the log as a miss against the entailment critic. They then read the chapter in full and write two pages of notes, mostly about the interpretation, which is the part the machine didn't write and couldn't judge.

After. The notes send the chapter back to stage 8 as human-directed revisions. Versions 6 to 9 are written by the author with the drafter tagging sentences. By version 9 the chapter is the author's prose, with every factual sentence still pointing to a card, and every card still pointing to a page.

That last step is the design working as intended. The machine did the reading, the carding, the checking and a first draft. The human chose the chapters, chose the story, read the pages the machine flagged, and wrote the parts that make it a book.

What this design does not solve#

A few things stay open, and they are the same things the short post ended on.

• The story choice. The rubric makes candidates comparable. It doesn't make the choice. Whether a model can find the story Greene would have found is untested, and gate 3 exists because of that.
• The checker ceiling. Entailment models top out in the high 70s on hard benchmarks. Verbatim cards next to each sentence make the task easier than the benchmarks, but nobody has measured by how much. The spot checks at gate 4 are the only measurement this design has.
• The wait. Stage 4 gives the model a fresh context and more information. It doesn't give it two months of living. Greene's second pass is partly about him having changed.
• The anger. Greene says every book came out of something that made him angry. No stage in this design supplies that, and none should try.
• Copyright. The cards hold verbatim text from copyrighted books. That is fine for private research notes. It becomes a question once cards are shared, published or used at scale. Chapter 14 covers the law and the abuse case.

The rest is engineering, and most of it can be built from existing parts. Chapter 12 is the parts list.

Sources#