Protocolize Your Book · Field note

The template was never the protocol.

We set out to remove the book factory's dependency on Microsoft Word. Two days before a workshop, watching two writers struggle to get our template's styles into their manuscripts, we found that the real contract was far smaller than the template: two heading names and a marker you can type. This is the conversation that got us there, and what it taught us about protocols.

Jenna Dixon & Shelley (the studio's coding agent) · punchlist thread 0.25, 19 Sep 2026 · shipped the same evening

01 The question

The book factory turns a manuscript into an EPUB and a print-ready PDF. For a year the front door was a Word template: thirteen paragraph styles (Heading 1, First Paragraph, Epigraph, Verse, Block Quote…) that the typesetting pipeline maps onto a book design. Write in the template, upload the .docx, get a book.

Then real people tried it. On a Friday afternoon two testers sat down with the factory. Neither had Word. Word for the web felt janky. Apple Pages silently renamed the styles on export, and our Inspect step flagged every one of them as an undeclared custom style. Google Docs has no custom paragraph styles at all, so there was nothing to import our thirteen into.

Jenna's question, logged as punchlist item 0.25: does the factory still need Word at all?

02 First answer: read what the pipeline actually reads

The first move was to stop guessing and trace the input through every stage of the pipeline: Upload, Inspect, book map, the style-marker pre-pass, corrections, chapter detection, the print build, the EPUB build. What does each stage actually key on?

The answer was the same at every stage: the style name on each paragraph. Inspect reads paragraph.style.name. The book map reads w:name out of styles.xml. pandoc's docx+styles reader wraps each paragraph in the name of its style, and a small Lua filter maps that name to a typesetting call. Fonts, sizes, spacing, colors, the whole visual surface of the file, are ignored. Word for the web's "janky" upload had in fact kept every style name and built perfectly; it had also added direct spacing to 727 of 771 paragraphs, which nobody downstream ever looked at.

So the honest first answer was: the factory does not need Word. It needs a .docx whose paragraphs carry the template's thirteen style names. That opened several doors, and we tested each one on the server without spending a build credit: LibreOffice Writer opens the template with all thirteen styles intact (round trip through .odt and back: byte-identical output). Markdown with pandoc's fenced divs feeds the same filter. Google Docs, which cannot hold custom styles, could still work through the [[style]] markers we had shipped the day before for a different reason.

Decision note delivered: seven candidate paths, effort-rated, with a recommendation to say "you need a .docx in our style names, not Word", offer LibreOffice and Docs as ways in, and avoid Pages until we had a real export to build a normalizer against.

03 The pushback

Jenna had watched the testers, and the note had answered the wrong question.

Jenna · 19 Sep, 17:53

Good notes, but watching the two folks work through the factory yesterday afternoon made clear that applying our Word template that is exported — applying the styles in the template onto their document — is non-trivial. The additional factor is that Google Docs doesn't allow any custom styles, so there's no way to grab those.

I think if they have an existing document, we need to be more proactive with coaching on a good round trip: either importing the factory styles into their current document or bringing their text over safely into our template. Both ways seem more fragile than I'm comfortable with. Think some more about that.

Actually, now that you mention LibreOffice Writer, maybe we offer more export choices and stop doubling down on Word. I'll stop thinking aloud now. Let's discuss this a little bit more before we do anything else.

Every path in the decision note still assumed the template was the way in. The testers' problem was not which editor; it was that the factory asked them to move thirteen style definitions from one document into another, and every editor makes that hard.

04 The turn

Shelley · 19 Sep, 17:54

Agree with the diagnosis, and I think it points somewhere cleaner than "more export formats."

The fragile thing is moving style definitions between documents. Both round trips you describe do that: importing our thirteen styles into their file (Word's Organizer is hostile, LibreOffice's Load Styles is one dialog but still a step, Docs simply can't), or pasting their text into our template (which either loses italics or drags their formatting along). Every editor makes this hard because it is genuinely a cross-document operation. No amount of coaching makes it not fragile.

What the pipeline actually needs is much smaller than "our template." I checked this afternoon's test file: a document with only Word built-ins — Normal, Heading 1/2/3 — plus [[quote]] / [[verse]] / [[epigraph]] markers where needed builds byte-identical output to the templated Word file, and Inspect came back clean. So for an existing manuscript the whole contract is:

chapter titles → Heading 1 (every editor has it: Word, Docs, Pages, LibreOffice)
sub-heads → Heading 2
the handful of special blocks → type [[quote]] (or verse, code, epigraph…) at the start of the paragraph
export .docx → Inspect (free) tells you what it found.

Markers move intent as text. They survive copy-paste, email, Docs, Pages, Word online — anything. Nothing has to be imported anywhere. That is the robust primitive, and it is already live.

So the reframe: the template stops being the way in and becomes a convenience for people starting fresh. For everyone with an existing document: "Heading 1 for chapters, a marker for anything special, export, Inspect." One page, one slide.

On more export choices: cheap, and I'd do it — but framed as three starters, not three ways to move styles. Not "stop doubling down on Word" so much as "stop making the template the gate."

Honest costs: markers are visible in the manuscript until the build removes them (a one-sentence explanation). No inline character styles by marker — italics and bold pass through natively, which is fine; small caps would still need the template.

Jenna · 19 Sep, 22:06

This is pretty great news. Go ahead and take a swing at A, and maybe in small type we can offer B, the ODT export, for folks who really do want to use Word. It's interesting to think of a small, one-book-at-a-time kind of place versus a larger small publishing company that might want to push a book a week through the pipeline. I'd like to be able to accommodate both.

05 The contract, as it now stands

Bring your manuscript — from any editor

Chapter titles use Heading 1.
Sub-heads use Heading 2.
Special paragraphs get a marker at the start: [[quote]], [[verse]], [[epigraph]], [[code]], [[break]], [[signature]]; [[/quote]] closes a run.
Export .docx. Run Inspect (free). It lists the markers it found and anything it did not understand.

The template is still there, as .docx or .odt, for anyone starting from a blank page who wants to see the styles. It is a convenience, not the gate. Full details on the factory page.

A press that wants to push a book a week gets the same contract, applied differently: one paragraph in its house style guide ("type [[quote]] before every extract") and any author in any editor produces a file the factory reads. Scripted intake goes through the API. The solo author gets the page; the press gets the paragraph.

06 What this taught us about protocols

The workshop this note belongs to argues that a manuscript is already a protocol stack, and a stylesheet is the layer writers can see and own. This episode is the argument in miniature.

Find the smallest signal the receiver readsWe had been asking for a template — thirteen styles, fonts, spacing, a whole document — when the pipeline read exactly one field per paragraph. The protocol is what the receiver keys on, not what the sender's tool exports. Tracing the receiver end to end before designing the sender end is the whole method.

State transfer is where protocols breakBoth of the "round trips" that worried Jenna required moving style definitions across a document boundary. Every editor makes that a special operation (Organizer, Load Styles, or simply impossible), and coaching cannot fix a step that is fragile by construction. A protocol that requires importing state is brittle; one that rides on the payload is not.

Intent as text[[quote]] is a style name written into the content stream. It survives copy-paste, email, every editor, every export path, because everything preserves text. When the channel is unreliable for metadata, put the metadata in the channel that is reliable. The build strips the markers on the way out.

Use the vocabulary everyone already hasHeading 1 and Heading 2 exist in Word, Docs, Pages and LibreOffice. A contract built on a shared minimum needs no onboarding. Custom names only where the built-ins have no word for the thing — and then as a marker, not a style definition.

Conformance you can check for freeInspect runs before any credit is spent and reports exactly what the pipeline will act on: headings found, markers resolved, anything unknown. A protocol without a cheap validator is a protocol nobody can trust their file against.

The gate and the convenience are different thingsThe template did not go away; it stopped being required. Separating "what you must send" from "what makes it comfortable to write" let both the one-book author and the book-a-week press use the same contract. Loosen the gate to what the receiver needs; keep the conveniences as conveniences.

Say the costs out loudMarkers are visible in the draft. Inline character styles have no marker. The validator still runs the marker pass in a different order from the build (a one-line fix, queued). A protocol is easier to adopt when its edges are documented than when it is oversold.

07 Timeline

When	What
Fri 18 Sep	`[[style]]` markers shipped as a pre-pass, originally so Google Docs users had any way to name a special paragraph. That afternoon, two testers try the factory without Word. Pages renames styles; Word for the web frustrates; Docs can't hold the template's styles.
Sat 19 Sep 17:05	Question logged: does the factory need Word? Decision note written: seven paths, all assuming the template is the way in.
17:53	Jenna: the fragile step is moving styles between documents, not the editor. "Let's discuss before we do anything else."
17:54	The reframe: the contract is Heading 1, Heading 2, and a marker. Verified: a built-ins-only file builds byte-identical output to the templated one.
22:06	Jenna: go. Also serve the template as `.odt`; accommodate both the solo author and the book-a-week press.
22:11	Live: /factory#bring, /workshop#bring, the transmittal hand-off card leads with "no template needed", `.odt` template endpoint. Copy changes only, plus one additive endpoint, on a freeze day.
Sun 20 Sep	Outcome recorded in the decision note. Still open: a real Apple Pages export, to build the style normalizer against.

The full decision note, with the stage-by-stage trace of the pipeline and the evidence for each path, is in the studio's private repository (WORD-FREE-AUTHORING-2026-09-19.md; ask for a copy). The conversation above is condensed from the punchlist thread; the working text is in the studio's run archive.

Part of the Protocolize Your Book workshop — a working book-production factory reframed as a protocol stack. See also Language as protocol — examples in the wild.