StoryForge — Book Editor
An AI editing pipeline for book-length fiction — chapter by chapter, with context that respects the timeline.
A tool I built for editing my own manuscripts: it edits a book chapter by chapter while carrying evolving context (a running summary, versioned character profiles, an author style profile), and — crucially — when editing chapter N it only sees what's known up to N−1, so nothing from later chapters leaks backward. Edits come back as inline annotations, not silent rewrites, keeping a human in the loop.
What it is
I write books, and editing at length is exactly the kind of structured, repetitive work an LLM pipeline is good at — so I built one for my own manuscripts and use it. It processes a manuscript chapter by chapter, keeping evolving context so each chapter is edited with awareness of everything that came before it, and returns its edits as inline annotations rather than rewrites: it marks a passage, states the problem, and proposes a change, but never silently overwrites the author’s text.
The part I care about — context that respects the timeline
The idea I’m most happy with is time-consistent context. When the pipeline edits chapter N, the model only sees the summary and character state established up to chapter N − 1 — so nothing from chapters that haven’t happened yet bleeds into earlier ones. To make that work, each character is stored as a base state plus per-chapter deltas, and their knowledge and status are reconstructed for the exact point in the book being edited. It’s the difference between an editor who’s read only as far as you have and one who keeps spoiling the ending.
The pipeline
Each chapter runs two phases:
- Context phase — a structured summary of the chapter (events, state changes, open threads) and versioned updates to character profiles and relationships.
- Edit phase — mechanical auto-fix (spelling/punctuation/grammar), then deep style suggestions as annotations, then a consistency check against prior context, then a per-chapter report, saved as an annotated
.docx.
The author style profile is built once from the opening chapters and reused, so suggestions stay in the author’s voice rather than flattening it.
Making it reliable
A fair amount of the work is the unglamorous part that makes a long run trustworthy:
- Strict, self-repairing JSON — a single helper centralizes extraction, schema validation, and auto-repair of malformed model output.
- Transactional context — a chapter’s summary and profile updates commit together, so a mid-run network failure can’t leave the context desynced.
- Resumable — a per-chapter journal separates “completed cleanly” from “a file happens to exist”, so failed chapters aren’t silently skipped.
- Per-project isolation — all per-project state travels in one object with no shared globals, so concurrent web requests don’t clobber each other.
Interfaces & models
There’s a Rich-powered CLI and a FastAPI web UI that streams live progress over SSE and runs the pipeline as a subprocess, so long jobs don’t block the server. Model backends are pluggable — DeepSeek when hosted, Ollama when I want it fully local.
On the roadmap
The next piece is translation as a parallel pipeline over the same context layer: a versioned glossary for canonical name/term translations, segment-by- segment drafting, and verification passes (fidelity → fluency → consistency). The plan is a shared “pass” abstraction so editing and translation are just different ordered lists of passes over the same context — reusing the infrastructure rather than forking it.
It’s a working tool I actually use on my own drafts, not a finished product — but the core pipeline runs end to end, and it’s the project where my writing and engineering sides meet most directly.