Draw the chain before choosing the tools

When a publishing workflow becomes difficult, the first impulse is often to look for a new tool. A database might replace the spreadsheet. A dashboard might replace the weekly meeting. An automated transfer might remove a repetitive task. These choices can be useful, but they begin one step too late.

Before choosing software, draw the chain as it actually exists.

This means following a book from its source to its next valid state. What enters each step? Who makes a decision? What evidence shows that the step is complete? Where does the result go? What happens when a correction arrives? The answers are rarely contained in one job description or one folder.

Start with passages, not applications

A publishing chain crosses several kinds of work: editorial selection, rights and provenance, text preparation, design, metadata, production, distribution and later correction. Each passage changes the object. A manuscript becomes an approved text; an approved text becomes a composed edition; an edition becomes a product that other systems must identify.

The useful map does not need to be beautiful. A page with boxes and arrows is enough if it names the states clearly. “In progress” is weak because it hides the expected result. “Copy edited, author queries unresolved” is stronger. It tells the next person what exists and what remains open.

Mapping also exposes invisible queues. A file may take ten minutes to process but wait three days for a decision. If only the processing time is measured, the team may automate the wrong part. The delay belongs to the chain, not merely to the tool that happens to display it.

Name responsibility at every gate

Many workflow failures are described as communication problems. Often, the deeper issue is that nobody knows who may change a state. Who approves the final title? Who confirms that a translated cover matches the correct edition? Who can reopen a supposedly complete package after a metadata correction?

Tools can assign tasks, but they cannot invent legitimate authority. The map should therefore distinguish action from validation. One person may prepare a file; another may accept it. A check may be deterministic, such as verifying that required fields are present. A judgment may remain editorial, such as deciding whether a subtitle clarifies or weakens the promise.

This distinction protects both speed and craft. Repetitive checks can be made consistent. Decisions that require context remain visible rather than being disguised as automatic rules.

Choose technology against the map

Once the chain is drawn, tools can be evaluated with better questions. Can the system preserve stable identifiers across versions? Can it show the source of a correction? Can a failed step be resumed without rebuilding the entire book? Can the records be exported if the organisation later changes platforms?

The cheapest application may be expensive if it creates manual reconciliation. The most comprehensive platform may be excessive if the team cannot explain the states it is configuring. Fit is not the number of features. It is the degree to which the tool supports the responsibilities and passages already made explicit.

In Maison Beaulieu’s internal Publishing OS research, this principle sets a boundary. The prototype is not presented as a validated commercial product. It is a way to test whether sources, identities, states and controls can remain legible across a growing catalogue.

A map is also a shared language

The strongest result of mapping may not be technical. When editorial, design and production can point to the same chain, disagreements become more precise. Instead of saying that a file is “wrong,” someone can identify the source, the state and the gate where the divergence began.

Technology then returns to its proper place: not a promise of transformation by itself, but an instrument fitted to a known piece of work. Draw the chain first. The tool should answer the map, not force the work to imitate its menus.

adrienbeaulieu.com