A Book Is a Dependency Graph

00 / THE DEPENDENCIES

A correction to one paragraph can create work in fourteen languages. Before you can update anything, you need to know which editions contain that paragraph, which source version they used, and whether their translations have since been reviewed.

I encountered this while building a publishing system around a client’s house-building notes. The manuscript became a 227-page Croatian book with 88 illustrations, followed by fourteen localized editions and their storefronts. As the project grew, keeping those documents connected became part of the engineering.

A book is a dependency graph. The original notes feed sections of the manuscript. Those sections feed translations, which feed exported files that readers receive. A change somewhere upstream gives you work downstream. If you lose those relationships, you have to reconstruct them by reading.

01 / SOURCE REQUIREMENTS

What one note can become

The client had collected 219 notes while building his house. They covered decisions, mistakes, comparisons, and things he wished someone had explained earlier.

A note is a convenient unit for collecting material. It can be a poor unit for checking whether that material made it into a book.

Consider a note about choosing a wall system. It could ask for an explanation of the alternatives, a comparison table, the author’s reason for choosing one, and a labelled illustration. A model might produce a perfectly readable explanation while leaving out the other three requests.

Marking that note as “included” would hide the unfinished work.

I used stable note IDs, such as N-0219, and tracked individual requests separately. The explanation could be accepted while the illustration remained incomplete. Each request needed a destination in the manuscript and something specific to check there.

That also changed the chapter briefs. A broad instruction to write about wall systems leaves the model considerable freedom to decide what counts as coverage. A brief tied to the source requests gives the reviewer something to compare against.

The outline still needed editorial judgment. Related material had to come together, repetition had to go, and the chapters needed an order that made sense to someone building a house. The tracking made those decisions inspectable.

02 / TWO KINDS OF REVIEW

Why a readable draft can still be incomplete

I learned to review sections twice.

One pass compared the draft with its source material. Were the requested explanations present? Had a measurement changed? Was the author’s reason for a decision still there? Did the table actually exist?

The other pass treated the section as writing. Was the explanation clear? Did it repeat an earlier chapter? Had the author’s voice disappeared into generic advice?

A section could pass either review and fail the other.

That is an awkward property of generated prose: omissions often read smoothly. A missing paragraph leaves no blank space where it should have been. The model can write a neat transition around the absence, and the reviewer has to remember that something belonged there.

Code helped with the things I could state precisely. It checked protected numbers and strings, expected structure, and whether batches returned the required IDs. Those checks narrowed the review, but they could not establish that an explanation was accurate or useful.

A construction warning can retain every number and still give bad advice. Another model pass can help identify a problem; someone with the relevant knowledge still has to judge the content.

The practical benefit was being able to distinguish what had been checked. “Reviewed” needed to mean something more specific than “someone looked at this and it seemed fine.”

03 / DRAFTS AND EDITIONS

The manuscript as a set of dependencies

The work happened in sections small enough to review and save.

That mattered when model requests timed out or returned incomplete output. Accepted work stayed separate from failed batches, so a retry could address the unfinished part. I could split a troublesome batch without throwing away the rest.

Localization followed the same principle. Each edition started from the reviewed Croatian source. German did not depend on an English translation that happened to be available, and French did not inherit another translation’s editorial choices.

Each language also needed decisions about what should travel.

The source included Balkan prices, public services, procedures, and local examples. A literal translation could carry advice into a place where it no longer applied. I removed local material that did not belong in the international editions and retained the construction principles that did.

Those choices became part of the localization instructions. Translation and target-language copy-editing ran as separate stages, with checks protecting content through both.

The exported pages needed inspection too. Text that fits in one language can push a table onto another page in the next. A reviewed manuscript and a reviewed PDF are different artifacts, even when one is generated from the other.

By this point, a folder containing files called final would have explained very little. I needed to know which source each edition came from and which work had already been accepted.

04 / CHANGES AND RELEASES

Following a correction across languages

The original notes remained the source of truth. Corrections went back into the source book, then into the affected localizations.

I used source hashes to identify changed sections. A hash is a fingerprint of the text: change the text and its fingerprint changes. If a localized section recorded an older fingerprint, it needed another pass. Unchanged sections could keep their accepted output.

This gave corrections a route through the system.

It also set a clear limit on what the automation knew. A changed hash establishes that the text changed. It says nothing about whether the change was a corrected fact, a rewritten sentence, or an accidental deletion. The editorial decision still had to happen.

At the batch boundary, returned IDs and source hashes were checked before output was saved. That helped prevent incomplete responses from quietly becoming accepted work.

At the release boundary, the edition recorded its locale, Croatian source version, and localization revision. A version such as en-GB-0.10.75.2 connected those pieces. The release manifest recorded file paths, page counts, and checksums.

That bookkeeping continued into delivery. Stripe Checkout metadata recorded what was sold, while download access served the current active PDF for that language. The exported artifact had a life beyond the process that produced it.

Without those connections, answering a simple question like “does this download include the correction?” would become a search through manuscripts, translations, and exported files.

05 / EDITORIAL JUDGMENT

What software can check, and what still needs a reader

There is a temptation to keep extending automated checks until “passed” sounds like an editorial verdict.

The useful boundary is more modest. Software can tell me that an expected section arrived, that a protected string survived, or that a translation was produced from the current source. A reader can tell me whether the explanation makes sense and whether the book is worth reading.

Both kinds of work need somewhere to record their decisions.

For a smaller project, I would start with a spreadsheet: source note, requirement, manuscript section, review status, and the editions affected by a change. Stable IDs and hashes become useful as the volume grows. The relationships matter before the machinery does.

I would also establish that tracking earlier than I did and involve target-language readers earlier. The project needed clearer review decisions as much as it needed reliable batch processing.

What I want from the system is straightforward. When someone corrects an explanation, I should be able to find its source, see which editions depend on it, and follow the correction through to the files readers receive.

That is the dependency graph worth preserving. The next correction will need it.