I used to describe autonomous publishing as publishing without a publish button. That was wrong.
The phrase captured the appeal of the system: routine work could move from topic selection to a rendered page without a person manually carrying every field between tools. But it collapsed two events that need to remain distinct. Generation produces a candidate. Publication grants that candidate public authority.
A mature pipeline may automate much of the path, but the boundary between those states has to be explicit, observable, and reversible. The publish button may become a policy decision or a promotion gate rather than a literal interface control. It cannot simply disappear.
Stage 1: select a problem, not merely a keyword
The pipeline begins before writing. Something has to decide which problem deserves a page and why it belongs to this publication. A search query can provide evidence of demand, but demand alone is not an editorial reason.
A useful candidate topic should pass several tests. It fits the domain promise. It is not already answered by an existing article. The publication has experience, evidence, or a distinctive model to contribute. The intended reader can do something better after reading it.
This is where scaled generation often fails. A queue of phrases can produce an endless supply of syntactically valid pages while avoiding the harder question of whether the publication has anything original to say. Google describes scaled content abuse in terms of producing many low-value or unoriginal pages primarily to manipulate rankings, regardless of whether automation was used. The relevant distinction is value and purpose, not human versus machine keystrokes.
Stage 2: build a source pack
Before an article is drafted, the pipeline should assemble the evidence it is allowed to rely on. I call this a SourcePack: a bounded collection of primary sources, authoritative references, project observations, existing internal articles, and unresolved questions.
A SourcePack is not a pile of scraped text. It should identify where each item came from, what kind of source it is, when it was accessed, and which claim it can support. It should also preserve disagreement and missing evidence instead of blending everything into one confident summary.
This is provenance in practical form. The W3C PROV family describes provenance through the entities, activities, and people involved in producing a result, supporting judgments about trust, quality, and reliability. A publishing pipeline does not need to expose its private process publicly in full, but it should retain enough lineage to explain why a factual claim entered a draft.
Stage 3: generate a candidate, not a publication
The generator receives the problem, domain constraints, SourcePack, target reader, and desired editorial function. That last part matters. A comparison, case study, decision record, build log, and tutorial should not all emerge from the same section template.
The output at this stage is deliberately provisional. It may contain a strong synthesis, but it may also hide unsupported transitions, flatten disagreement, imitate the rhythm of other articles, or expand thin material to satisfy a length target. Structural validity only proves that the candidate can move through the system. It does not prove that it should move into public view.
This distinction is developed in Generation Is Not Publication. It is also why the seed described in Seed Instead of CMS contains constraints and evaluation rules, not just writing instructions.
Stage 4: audit claims and editorial value
The next stage evaluates the candidate against both evidence and purpose. One useful tool is a claim ledger. Each consequential statement is classified as an externally verifiable claim, an author thesis, or a project observation. The audit asks whether evidence is present, partial, unnecessary, or missing and recommends whether the statement should be kept, qualified, sourced, or removed.
A separate editorial audit asks different questions:
- Does the article contain a distinction or observation that belongs specifically to this publication?
- Is it substantially different from the existing library?
- Are broad claims hiding behind confident language?
- Does the structure fit the function of the article?
- Does it disclose more about the private system than the public argument requires?
- Are the title and excerpt accurate promises?
- Does the reader reach a useful conclusion without having to search again for the missing substance?
Google's people-first guidance asks similar questions about original information, first-hand expertise, substantial value, clear sourcing, and whether automation is being used primarily for search traffic. These are not boxes an LLM can certify about itself. The pipeline can collect evidence and flag weaknesses; accountability remains with the publisher.
Stage 5: derive visuals from accepted meaning
Images should come after the article has enough substance to describe what the visual is for. Generating a hero from a category label usually produces atmosphere. Generating from a specific passage can produce an explanatory object, process, contrast, or environment.
The visual brief should record its source passage, editorial purpose, crop requirements, factual constraints, alt-text intent, and avoid list. A generated image is then reviewed against that brief rather than accepted because it matches the palette.
This project reached that rule through failure. Early category imagery looked finished but said little. Content-derived briefs produced visual sections with different jobs instead of repeating the same decorative card across the page.
Stage 6: validate the complete page
The candidate must be tested as a page, not only as text. Links, relations, headings, metadata, image weight, alt text, encoding, mobile overflow, and indexing state are part of editorial quality because they determine whether the argument can actually be accessed.
Automated checks are valuable here. They are consistent, repeatable, and good at detecting known failure classes. But passing them means the page satisfies the checks that exist. It does not mean the page is meaningful. A system can return perfect status codes while publishing an empty promise.
NIST's AI Risk Management Framework treats governance, measurement, and management as continuing activities rather than one final test. Its generative-AI profile also notes that some uses call for additional human review, tracking, documentation, and management oversight. The appropriate level depends on risk; the need to make that decision does not disappear because the output looks polished.
Stage 7: promote deliberately
A reviewed candidate remains outside indexing until an explicit promotion decision. Promotion may happen one article at a time or in a controlled batch. The important point is that saving, rendering, and indexing are different states.
Human override belongs here, but not only here. An operator should be able to reject a topic, stop a batch, return a published page to review, or tighten a rule after discovering a failure. The intervention should preserve a reason and should not require dismantling the useful automation around it.
Stage 8: observe what publication changes
Publication is not the end of the loop. The system should observe whether pages are indexed, found for the intended queries, read, linked, or repeatedly ignored. Those signals do not automatically dictate what to write next, but they can reveal mismatches between the publication's intent and the result.
The dangerous version of feedback is blind optimization: produce more of whatever receives a click. The useful version treats performance as diagnostic evidence. A page excluded from indexing may expose thin content, duplication, technical failure, or simply insufficient demand. The system should surface the pattern and its uncertainty before changing editorial policy.
Where the human actually is
The human is not absent from autonomous publishing. Their work moves. Instead of transferring every field manually, they define the domain promise, evidence standard, disclosure boundary, acceptable risk, promotion rules, and response to failures. They review what deserves responsibility rather than performing every mechanical transformation.
The pipeline remains autonomous where autonomy is useful: collecting, structuring, checking, comparing, and observing. It remains governed where consequences begin: claims, identity, disclosure, and publication.
That is what an autonomous publishing pipeline actually looks like to me now. Not a machine that publishes because it can, but a system that can move candidates toward publication while keeping evidence, state, and human authority visible throughout the loop.