Editorial Council GitHub · opens at v0.1.0

Editorial Council · open source · local-firstMIT-licensed code

Drop in a novel. A council of AI editors reads it.

Editorial Council is an open-source, local-first multi-agent editorial system for novelists. Nine specialist clerks — continuity, voice, theme, pacing, plot structure, and more — each read your manuscript on its own terms; a briefing clerk synthesizes what they found; and a review room puts every finding on the page it belongs to, one tracked change away from your manuscript. Every brief excerpt and finding on this site is verbatim pipeline output — nothing hand-written, nothing cherry-picked.

The three-pane review room: a novel's first chapter open in LibreOffice Writer with highlighted passages, a findings map of per-dimension bubbles in the middle, and a correction panel on the right showing a grammar finding with an editable revision and an Approve button. ▶ watch the room work Real run · not a mockup
The desktop room mid-revision on Strike Zone — the author's actual working session. Click for the animated demo.
10specialist clerks
7novels analyzed
565kwords analyzed
1,250+findings anchored
$0to run locally
Exhibit A — two clerks disagree, on purpose
From the brief for The Picture of Dorian Gray — “Cross-Clerk Tensions”

Pacing Cliff at Arc: Dorian Gray at ch_12, ch_13

Pacing finds: Sharp tension drop (tension falls 0.06→0.03 — 69% of the manuscript's range — between ch_12 and ch_13)2

Character finds: Dorian Gray (17 beats) is active in this section1

If intentional (breathing room after a climax), the pacing serves the arc; if unintentional, consider whether Dorian Gray's arc carries enough momentum through the lull.3

ch 12→13: the drop ch 1 ch 20

The curve in question — per-chapter tension from the run's own pacing record (arc_tension, 20 chapters). Not an illustration: the data behind the finding.

1 Two specialist clerks read the same chapters independently — and disagree. The brief surfaces the disagreement instead of averaging it away.
2 Real measurements from the text: a per-chapter tension curve, not vibes.
3 Framed as an editorial decision for the author — not an error to auto-fix. The system tells you where to look and why; the call stays yours.
The review room

Findings you can sit inside, not a report you scroll past

The council's findings don't arrive as a PDF. They land in a three-pane review room: your manuscript in a real word processor on the left, a findings map in the middle, and a correction panel on the right. Click a finding, edit the suggested revision, approve it — it lands in the manuscript as a tracked change you can accept or reject later, like any human editor's markup.

How it works

One command in. One brief out.

No uploads, no accounts, no hosted service. The pipeline runs on your machine, against models you choose — fully local for $0, or bring your own API key.

STEP 1

Ingest

Point the pipeline at a manuscript — pipeline.py run — and it splits the text into chapters and fans them out to the council.

STEP 2

The council reads

Nine specialist clerks each analyze one dimension of the book — who's on the page, what's been established, how the voice holds, where the tension moves — and file their findings.

STEP 3

The brief — and the review room

A briefing clerk synthesizes everything into one editorial brief, its evidence graded against the source text. Every anchorable finding also lands in the review room, highlighted on the exact passage it concerns.

ClerkWhat it contributes to the brief
Continuitycharacters, established facts, timeline, settings
Outlinescenes, plot threads, seeds (foreshadow/payoff pairs), arcs
Style Guidedialogue attribution, show/tell balance, craft concerns
Voiceper-chapter voice consistency + a voice fingerprint
Characterarc tracking + arc-health findings
Themethematic threads + controlling-idea candidates
Plot Integrityseed health, subplot and causality analysis
Plot Structureframework detection (Hero's Journey, Story Circle, …)
Worldbuildingentity and relationship graph
Pacingper-chapter speed, dialogue density, pacing sags
Editorialper-chapter line edits during evaluation — the grammar and copyedit calls that feed the review room
Briefingsynthesizes all of the above + an opening literary assessment

The colors are the same dimension hues the review room uses for its bubbles and highlights. Each brief carries its own per-run coverage table — the roster, run by run, as it actually executed.

Run it yourself

Fully local — $0, nothing leaves your machine

This is the actual quickstart from the repository. Public-domain sample manuscripts ship with it, so you can try the pipeline before pointing it at your own work. Never used a terminal? The FAQ covers what you need in plain language.

$ ollama pull qwen2.5:7b
$ OLLAMA_URL=http://127.0.0.1:11434 CLERK_MODEL=qwen2.5:7b \
    clerks/pipeline-orchestrator/venv/bin/python3 \
    clerks/pipeline-orchestrator/pipeline.py run dorian_gray \
      --source manuscripts/dorian_gray/source.txt \
      --model qwen --eval-backend local

→ manuscripts/dorian_gray/editorial_brief.md

Prefer a cloud model? Bring your own API key — the pipeline never ships one. Model tier is a real choice: the Strike Zone showcase ran on a frontier API model and discloses its full model bill; this quickstart runs the identical pipeline locally for $0. A recorded terminal session will land here with the v0.1.0 release.

FAQ

Questions you should ask

Is this site a service? Can I upload my manuscript here?

No — deliberately. This site is a demonstration of the open-source tool, not a hosted product. There is no upload box and no inference endpoint; every brief and every finding you see here was pre-generated by running the pipeline locally. To use it on your own book, you run the software on your own machine.

Where does my manuscript go?

Nowhere. Editorial Council is local-first: the pipeline runs on your machine, and with a local model, nothing leaves it. If you choose a cloud model, your text goes to that provider under your own API key and their terms — the choice, and the key, are yours.

Do the clerks talk to each other?

No. The clerks analyze independently and their findings — including their disagreements — are merged into one brief; they don't converse with each other.

What manuscripts can I run it on?

Public-domain works, or manuscripts you own the rights to. The project asks that you run it only on books you hold the rights to; it's built for authors working on their own manuscripts.

What does it cost to run?

$0 if you run a local model via Ollama — that's the default quickstart. If you prefer a cloud model, you bring your own API key and pay that provider directly; there is no service fee and no middleman.

What do I actually need? I'm a writer, not a programmer.

A reasonably modern computer that can run Python, plus LibreOffice (free) for the review room. For the $0 path you also install Ollama, which manages local models for you. Your manuscript goes in as plain text; the review room works on a .docx working copy so approvals land as ordinary tracked changes. The quickstart above is the whole ceremony — copy, paste, wait. If that still feels like a wall, that's honest feedback the project wants: the issue tracker is open.

How long does a run take?

It's an unattended batch job, not an interactive tool: every clerk reads every chapter. On a local model, budget hours for a full novel — start it and go write. Cloud models are faster; you trade money for time. Either way you run it occasionally on a draft, not continuously while typing.

Will my manuscript be used to train an AI?

Not by us — there is no "us" in the loop; the software runs on your machine and phones nothing home. With a local model, training on your text is architecturally impossible: nothing leaves the room. If you bring a cloud API key, your text goes to that provider under your agreement with them — the major providers state they don't train on API inputs by default, but verify your provider's current terms. That's the real distinction to watch: your own API key, not pasting chapters into a consumer chatbot, whose terms are usually different.

If I approve its suggestions, is my book "AI-generated"? Do I have to disclose it?

The tool is built so the honest answer stays "no more than with a human editor": nothing is applied automatically, every change arrives as a tracked change you accept, reject, or rewrite, and the findings are notes on your prose, not generated prose. Platforms draw their own lines — Amazon KDP, for instance, currently distinguishes AI-generated content (disclosure required) from AI-assisted work the author created and substantially edited. Check your platform's current policy; this isn't legal advice.

Are the sample briefs edited or curated?

The briefs are verbatim single-command pipeline output — nothing in them is hand-written. The pages on this site select excerpts to explain, but each links to the full untouched brief.

Couldn't the model just be remembering published criticism of these classics?

For the four public-domain novels, that's a fair worry — which is why the fifth novel is there. Strike Zone is a 2013 Kindle novel with near-zero web footprint; before the run, the models were probed for any knowledge of it and produced nothing, across two frontier-model families. A probe can't prove a book is absent from a training corpus — but it can show no model exhibits any memory of this one, so its analysis can't be memorized criticism. Read what the council found.

Why do some analyses carry ⚠ flags?

By design. The brief grades its own evidence against the source text and flags claims it can't verify verbatim, and a coherence gate marks structural calls as contested when the clerks' readings contradict each other. An editorial tool you can't trust to admit uncertainty isn't an editorial tool.

Where's the code?

Open source under the MIT license. The repository goes public with the v0.1.0 release at github.com/GrettirJacobs/Editorial-Council.