Structured production · updated 6 August 2026
Manuscripts as Code
Treating a manuscript as structured source can reduce version sprawl and make production repeatable—but the source remains a creative work governed by editorial judgment and access controls.
One accountable source
Keep the canonical manuscript in a controlled source of truth, with a clear owner and access policy. Plain-text formats can make diffs, structure, and automated transformations easier to inspect, while editorial teams may still use familiar review tools around that source.
Branches are review spaces
Draft or staging branches are places to propose structural changes, corrections, and experiments. The production version should represent only the current approved source. A merge is a workflow event, not a substitute for an editor’s decision.
Automate checks, not accountability
A pipeline can check links, metadata shape, formatting, build reproducibility, and selected consistency rules. It should report limits and route failures to people who can interpret them. Do not represent automated checks as proof of factual accuracy or publication readiness.
Build outputs need their own boundary
A build may produce an ePub, print PDF, web experience, internal retrieval index, or public JSON manifest. Each output must inherit an explicit rights and access classification from the approved source; a private index does not become public because it was generated automatically.
This page develops ideas first discussed in the Agentic Publishing community. The documentation states the current public boundary and does not turn discussion or roadmap material into a product guarantee.
Related documentation
For a concrete public record, inspect the metadata-only Context Pack demo. It remains separate from protected manuscript content and private editorial systems.