StoryForge — Book Editor
An AI pipeline that edits — and translates — book-length fiction chapter by chapter, with context that respects the timeline.
A tool I built for working on my own manuscripts: it edits and translates a book chapter by chapter while carrying evolving context (a running summary, versioned character profiles, an author style profile, and a translation glossary), and — crucially — when editing chapter N it only sees what's known up to N−1, so nothing from later chapters leaks backward. Editing returns inline annotations, not silent rewrites; translation returns a clean target-language rewrite kept consistent by a glossary I review first.
What it is
I write books, and editing and translating 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 works chapter by chapter, keeping evolving context so each chapter is handled with awareness of everything that came before it. In editing mode it returns inline annotations rather than rewrites — marking a passage, stating the problem, and proposing a change — so a human stays in the loop and the author’s text is never silently overwritten. In translation mode it produces a clean rewrite in the target language, kept consistent by a glossary I review before it runs.
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.
Two pipelines over one context layer
Editing and translation share the same per-project context — a running summary, versioned character profiles, an author style profile, and (for translation) a glossary — rather than being two separate tools.
- Editing runs a context phase (a structured chapter summary plus versioned
updates to character profiles and relationships), then an edit phase:
mechanical auto-fix, deep style suggestions as annotations, a consistency check
against prior context, and a per-chapter report — saved as an annotated
.docxalongside a JSON report. - Translation starts from a project-wide glossary of canonical name and term translations that I review and edit, then translates each chapter through a multi-pass scheme: a voice-preserving draft followed by verification passes for fidelity (nothing added or dropped), fluency (natural target language), and consistency (glossary enforced).
Because both share the context layer, I can also run any single stage on its own — rebuild just the character profiles, regenerate only the reports for chapters 6–9, or (re)build the glossary — without redoing everything else.
Style that doesn’t get flattened
The author style profile is built once from the opening chapters and reused, stored as structured JSON — including a list of intentional deviations (things that look like mistakes but are the voice) that the editor is explicitly told not to flag. Chapter reports are graded against an anchored 1–10 rubric rather than drifting toward a safe 7–8, and a whole-book pass turns those reports into a structure read: tension arc, pacing, scene balance, and character arcs.
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; prompt text lives in per-language locale files while the schema stays fixed in code.
- Transactional context — a chapter’s summary and profile updates commit together, so a mid-run network failure can’t leave the context desynced.
- Resumable, and phase-scoped — a per-chapter journal separates “completed cleanly” from “a file happens to exist”; a phase-only run forces just the stages you asked for and leaves that journal untouched.
- 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. From the UI I can create edit or translation projects, toggle individual phases, edit the glossary in a table before translating, and read the translation side by side with the original — editing it in place and saving it back to the chapter file. Model backends are pluggable — DeepSeek when hosted, Ollama when I want it fully local.
Where it’s going next
With translation shipped, what’s left is mostly architectural: folding editing and translation into a shared “pass” abstraction so each is just an ordered list of passes over the same context (they already share the context layer — this unifies their control flow), and matching glossary terms across inflected forms so declensions of a name collapse on their own.
It’s a complete tool I actually use on my own drafts — the editing and translation pipelines both run end to end — and it’s the project where my writing and engineering sides meet most directly.