Two documents: the draft you review and the one you publish
A human-in-the-loop content pipeline needs two different documents: a short kernel for the decision, and the full piece for the reader. Conflating them fails both ways.
When you build a pipeline that turns raw material into published writing — with a human approving in the middle — the first instinct is to generate the finished article and ask "yes or no?" That's the wrong shape, and it took shipping it wrong to see why.
The review artifact and the publish artifact are different
The document optimized for a fast decision is short: a kernel, a few sentences, the whole argument visible at a glance so a person can judge ten of them in two minutes. The document optimized for a reader is long: the full piece, with the reasoning, the concrete example, and the generalization that makes it worth reading.
Conflate the two and you fail in one of two directions. Make the reviewer read full essays and they drown — review fatigue sets in by the third one and the rest get rubber-stamped. Or review the kernels, publish the kernels, and the site fills with thin stubs that read like abstracts of articles that were never written.
The document you show someone for a decision and the document you show the world are not the same document. Build the pipeline to produce both, in that order.
Decision first, expansion after
So the flow is: generate kernels for review, let the human approve the ideas, then expand only the approved ones to full length, and confirm the finished piece with a final yes. Approval happens twice, on two different artifacts, and each is sized for its job. The expensive step — expansion — only ever runs on material that already cleared the bar.
Why the order matters
Expanding before approval wastes the costly work on ideas that get cut. Approving without an expansion step ships stubs. The sequence — cheap-to-review first, expensive-to-produce last, on survivors only — is the same economy as any good filter: do the cheap discriminating work up front, and spend the expensive effort only on what passed.
The short version
A human-in-the-loop content pipeline needs two artifacts: a short kernel for the decision, and a full piece for the reader. Review the kernel, expand only what's approved, confirm the finished version. Don't make a person review what they should be reading, and don't publish what they only reviewed.