Silos are often local memories

In one corner of a publishing workshop, a folder has an odd name. A spreadsheet nearby contains columns that appear to duplicate the production register. Someone keeps a private checklist because the official process does not mention a recurring exception. From a distance, these objects look like silos: isolated stores that should be merged, replaced or removed.

Look closer and they may reveal something else. Each can be a local memory of work the organisation never learned to describe in a shared form.

This does not make every silo good. It explains why a clean diagram and a central platform rarely make them disappear on command.

A silo may be holding a missing distinction

The separate spreadsheet might distinguish a work from an edition more accurately than the central register does. The unusual folder name might preserve a language or format that the standard hierarchy cannot express. The private checklist may contain the only reminder that a cover must be checked again when pagination changes.

People return to these local devices because they solve an immediate problem. Over time, use becomes habit and habit becomes infrastructure. The meaning remains clear to the person who built it, while the rest of the workshop sees duplication.

Before consolidation, it is worth asking what the silo protects. Which object does it identify? Which uncertainty does it reduce? Which decision or exception does it preserve? What would become harder to understand if it vanished tomorrow?

These questions separate knowledge from container. The container may be fragile, but the knowledge can still be essential.

Resistance is information, not proof of bad intent

When a central system arrives, reluctance is easily described as resistance to change. Sometimes it is. More often, people are being asked to surrender a working memory before the replacement can carry its meaning.

A field may exist in both systems yet mean different things. “Approved” can refer to corrected text, a visual proof or permission to manufacture. A title may identify a book for one team while another needs to distinguish work, translation and format. Copying the values without translating their meaning creates a central repository with local ambiguity hidden inside it.

The useful response is not to keep every private practice forever. It is to treat reluctance as a request for evidence. Show how the new structure represents the object, how an exception is recorded, who owns the decision and how a mistake can be recovered. When those answers are visible, migration becomes a testable handover rather than an act of faith.

Build a shared core without erasing useful views

A durable architecture does not require everyone to look at identical screens. Editorial, design and production work ask different questions. They may need different views of the same edition.

What must be shared is smaller and more important: stable identities, named sources of authority, explicit states and the relationship between a decision and the object it affects. A local table can remain useful if it is a view or controlled export, rather than an undocumented rival truth.

This distinction allows consolidation to proceed by function. First identify the authoritative object. Then map the local vocabulary to it. Preserve the exceptions that still have a reason. Mark what cannot yet be translated. Only after these checks should an old store be retired.

The transition also needs an owner. Not a permanent guardian of every cell, but a function responsible for the mapping, unresolved cases and the point at which the old source ceases to be authoritative.

Memory must survive its first keeper

The deepest risk in a silo is not separation alone. It is dependence on unspoken interpretation. If the only person who understands a code, sequence or exception becomes unavailable, the organisation must reconstruct the rule from traces.

Documentation should therefore capture why a local practice exists, not merely how to click through it. A successor needs to know what the data represents, what has been verified, what remains uncertain and which decisions still require editorial judgment.

At Maison Beaulieu, Publishing OS is an internal research-and-development prototype exploring relationships between sources, editions, states and checks. It is not a commercially validated software product, and no external transfer result is claimed here. The relevant question is narrower: can local knowledge become explicit without flattening the practice that produced it?

A silo should not be romanticised. It can duplicate work, conceal outdated information and make recovery difficult. But removing it before reading it may destroy the very memory a shared system needs. Transformation begins when the workshop can say: this container may go, this knowledge must stay, and this responsibility now has a visible home.

adrienbeaulieu.com