Publishing as Regeneration

#Opening signal

A book seems like a fixed object, but it is not: it is a family of derived artifacts — a print interior, an electronic edition, a cover, a catalog listing — all of which should be produced from one canonical source. The moment you edit the print file directly to fix a typo, and then separately edit the electronic edition, and then forget to update the catalog, you have three diverging versions and no source of truth. Publishing done well is publishing as regeneration: one canonical manuscript, from which every format is rebuilt, with predecessor versions preserved. This chapter uses the production of this book as its worked case.

#Mathematical core

FACT. The publishing pipeline is a deterministic function from a canonical source to a set of derived artifacts, exactly like the Fibonacci generator from Chapter 19. The canonical source is a single manuscript (in this book's case, structured Markdown under version control). From it, deterministic tools regenerate: a print interior (a fixed-layout file with embedded fonts, sized to a chosen trim, with margins and folios governed by the platform's requirements); a reflowable electronic edition (with semantic headings, a linked table of contents, and accessible text); and a metadata record (title, author, description, keywords, categories). Because the pipeline is deterministic, the same source always produces the same artifacts, so any artifact can be regenerated rather than hand-edited, and any artifact can be verified against the source by re-running the pipeline. The mathematical property — determinism — is what makes "regenerate, do not patch" possible for a book.

FACT. The print artifact has hard, external constraints that the pipeline must satisfy, and these are facts set by the print platform, not choices. For a 6 × 9-inch interior on white paper with black ink and no bleed: the inside (gutter) margin depends on page count — for books of 301 to 500 pages it is 0.625 inch — and the outside margin must be at least 0.25 inch.^[62] The cover's spine width is a deterministic function of page count: for white paper it is the page count multiplied by 0.002252 inch.^[63] A full-wrap cover requires 0.125-inch bleed on all sides and keeps critical content at least 0.25 inch from trimmed edges.^[63] These are inputs to the regeneration function, and — this is the essential point — the cover cannot be finalized until the interior's page count is known, because the spine width depends on it. Regeneration has a dependency order.

#Odisena translation

METHOD. Treat the book as a governed publishing system: one canonical source, deterministic regeneration of every format, predecessor versions preserved, and the platform's constraints encoded as inputs to the pipeline. Respect the dependency order: regenerate the interior first, obtain the final page count, then regenerate the covers from that count. Never hand-edit a derived artifact; fix the source and regenerate (Chapter 19). This is not only how the method describes publishing — it is how this book was produced. The Odisena imprint's doctrine is exactly this regenerate-not-patch pipeline, and the front matter's provenance notice states it plainly: a single canonical source, every derived artifact regenerated from it, predecessors preserved, corrections issued as explicit superseding versions.

#Boundary note

INTERPRETATION. It is tempting to treat publishing as a one-time act — produce the files, upload, done — and therefore to skip building a regenerable pipeline. The interpretation I hold: a book is never one-time. There will be a typo, a corrected fact, a new edition, a different format, a platform requirement change. Every one of these is a regeneration, and the pipeline that seemed like over-engineering at first pays for itself the first time you must produce a corrected edition without introducing new errors. The boundary is the same as Chapter 19's: build the regenerable pipeline whenever the artifact will change more than once — and books always change more than once.

#Applied CASE

CASE. The production of this book. The canonical source is a set of structured manuscript files. A deterministic build regenerates the print interior (6 × 9, embedded fonts, gutter sized to the final page count, front matter without body page numbers and body matter with them, chapters starting on right-hand pages), the electronic edition (reflowable, semantic headings, linked contents, accessible equation text and figure descriptions), and the metadata package. The cover is regenerated after the interior's page count is known, so the spine width is computed from the actual count using the platform's white-paper formula. When a correction is needed, it goes to the source; every artifact is rebuilt; the prior version is preserved and the change recorded as a supersession (Chapter 15). The book is, quite literally, an instance of its own thesis: a governed Infinity Engine whose cycles produce a preserved, regenerable, validated family of publication artifacts. The full manifest of this pipeline — every file, its hash, the page count, the word count, and the open human gates — is preserved in the release manifest and summarized in Appendix G.

#Failure mode

The failure mode is the hand-edited format: fixing the print file, or the electronic edition, or the metadata directly, so the artifacts diverge from the source and from each other. Its signatures are the "fixed in the PDF but not the EPUB" typo, the catalog listing that no longer matches the title page, and the corrected edition that reintroduces old errors because it was rebuilt from a source that was never updated. A publishing-specific failure is finalizing the cover before the page count — computing a spine width from a guessed count, producing a cover that will not fit. The fix is the regenerable pipeline: one source, deterministic regeneration, predecessors preserved, and the interior-before-cover dependency order respected.

#Reusable protocol — The Reproducible Publishing Pipeline

1. One canonical source. A single, version-controlled manuscript is the only source of truth.
2. Deterministic regeneration. Automated tools rebuild every format from the source; the same source always yields the same artifacts.
3. Encode platform constraints as inputs. Trim size, margins, gutter-by-page-count, spine formula, bleed, and safe areas are parameters of the pipeline, not manual tweaks.
4. Respect dependency order. Regenerate the interior first; obtain the final page count; then regenerate covers from that count.
5. Forbid hand-edits. All changes go to the source; artifacts are read-only outputs.
6. Preserve and record. Every regeneration is a new version; predecessors are preserved; corrections are recorded as supersessions with a manifest of hashes and counts.

#Validation questions

1. Do you have one canonical source for your publication, or several diverging format files?
2. Can you regenerate every format from source, or would a correction require editing each format by hand?
3. Are the platform's constraints encoded as pipeline inputs, or applied as manual tweaks?
4. Do you finalize your cover only after the interior page count is known?

#The dependency order is a law, not a preference

FACT INTERPRETATION. The single most common and most frustrating error in book production is finalizing the cover before the interior page count is known, and it is worth understanding why this is not a matter of workflow preference but of arithmetic necessity. The spine of a printed book must be exactly wide enough to hold the pages, no more and no less; too narrow and the cover will not close, too wide and the text block will slide. The spine width is therefore a deterministic function of the page count — for white paper, the page count multiplied by 0.002252 inch — and the page count is not known until the interior is fully laid out, because it depends on typography, figure placement, and where chapters fall. This creates a hard dependency: the cover cannot be correct until the interior is final, because one of the cover's essential dimensions is computed from the interior. A team that designs the cover first, guessing the page count, will produce a cover that does not fit and must be redone — and if they do not catch it, a cover that fails at the printer. The dependency order (interior first, then page count, then cover) is imposed by the mathematics of the physical object, not chosen by the workflow, and no amount of scheduling cleverness can reverse it.

This is a small, concrete instance of a general truth about regeneration pipelines: derived artifacts have a dependency order, and the pipeline must respect it. Some artifacts depend on others; you cannot regenerate a dependent artifact correctly until its dependencies are final. The interior-before-cover order is the most visible case in publishing, but the principle recurs everywhere — you cannot finalize a summary until the thing summarized is final, cannot compute a total until the line items are settled, cannot sign a manifest until the files it lists are frozen. A regeneration pipeline that ignores dependency order produces artifacts that are internally inconsistent — a cover sized for the wrong page count, a manifest listing the wrong hashes — and internal inconsistency in a set of artifacts that are supposed to be regenerated from one source is exactly the divergence the whole discipline exists to prevent. Respecting the dependency order is how a pipeline keeps its outputs mutually consistent as well as individually correct.

#Bridge

Publishing as regeneration keeps a book honest across its formats. The next chapter turns the method's honesty-discipline back on the most seductive misuse of Fibonacci itself — the claim that the golden ratio governs beauty and nature — and builds the evidence matrix that separates exact results from models, approximations, and cultural readings.