The most consequential decision in an autonomous publishing system is not how text is generated. It is where generation stops and publication begins.
Those events are easy to collapse into one action. A model returns structured content, the content passes validation, an image exists, and the entity can be displayed. Technically, the page is ready. Editorially, it may still be unproven. Treating those two states as identical turns automation from an assistant into an unaccountable publisher.
Generation produces a candidate
A generation pipeline can assemble a useful candidate from a topic, context, sources, constraints, and a target format. It can normalize fields, suggest relations, create an excerpt, and prepare an image brief. These are valuable capabilities because they reduce the cost of reaching a reviewable draft.
But a valid candidate answers only a mechanical question: did the requested process produce an object in the expected shape? Publication asks different questions. Does the article add something? Are its claims supported? Does it belong on this domain? Is it safe to expose? Does it reveal more about the underlying system than intended? Would the author stand behind it under their own name?
No schema can answer all of those questions. A schema can require an excerpt. It cannot determine whether the excerpt promises more than the article delivers. It can require a category. It cannot know whether the category represents a genuine editorial relationship or a convenient default.
Why human override is part of autonomy
Human override is sometimes described as a concession: evidence that a system is not truly autonomous. I see it as the opposite. A system that cannot be paused, inspected, reversed, or redirected is not demonstrating mature autonomy. It is merely executing without supervision.
The override must exist at more than one level. A person should be able to reject a single draft without disabling the entire pipeline. They should be able to stop a batch when its assumptions are wrong, return an indexed article to review, or tighten a domain rule after a new failure. The intervention should leave an observable reason, not just a changed state.
This also protects the system from confidence theatre. Generated prose often looks settled even when the source material is weak. A review gate creates room to say that the available evidence is insufficient, the framing is too generic, or the article duplicates something already published. Not publishing is a valid output.
The hidden weakness of a successful pipeline
A pipeline can succeed at every stage and still produce thin content. It may collect material, produce fluent prose, satisfy a word target, create metadata, and save the result without a technical error. If the source question was weak or the prompt rewarded coverage rather than insight, success simply means that the weakness travelled intact through the system.
This is why word count is not a useful proxy for depth. Forcing expansion can make the result worse by adding explanations that are broadly true but locally unnecessary. A better quality gate asks whether the article contains concrete distinctions, attributable evidence, honest limitations, and experience that could not be substituted into any neighboring domain.
The same applies to imagery. Producing an attractive image is not proof that the image explains the article. A final visual should be traceable to a passage, process, object, or contrast in the finished text. Otherwise the pipeline has generated decoration, not editorial material.
A deliberate boundary between states
The publishing model now uses distinct states even when the underlying content object is the same. A draft can render privately and participate in internal review while remaining outside indexing. It can be checked for links, encoding, accessibility, image weight, relations, and mobile behavior before promotion.
Promotion is therefore not a side effect of saving. It is a separate editorial decision. This separation makes batch publishing safer and allows the system to retain unfinished work without presenting it as complete. It also creates a useful audit trail: what was generated, what was reviewed, what changed, and what was finally approved.
The distinction matters most when automation grows. At small scale, a person may remember which pages are provisional. At larger scale, state must carry that information explicitly. Otherwise drafts and publications become visually indistinguishable inside the machinery long before they become indistinguishable to readers.
What should remain automated
Human override does not mean every action should be manual. Machines are well suited to checking route availability, required fields, duplicate patterns, image sizes, broken relations, missing alt text, encoding corruption, and whether unpublished material has entered a sitemap. They can assemble evidence for a decision and make inconsistencies difficult to ignore.
The human role is not to repeat those checks by hand. It is to judge the things the checks expose: whether a claim is responsible, whether an article has a reason to exist, whether the level of disclosure is appropriate, and whether the publication still reflects its stated promise.
The standard I want the system to meet
An autonomic publishing system should be able to explain what it produced, which constraints shaped it, what evidence it used, and why the result changed state. It should make reversal ordinary rather than exceptional. Most importantly, it should never confuse the ability to publish with permission to publish.
Generation creates options. Publication creates responsibility. Keeping that boundary visible is not friction to be engineered away; it is part of the architecture of trust.
For the failures that led to this separation, read What Broke While Building an Autonomic Publishing System.