Two documents: the draft you review and the one you publish

When you build a pipeline that turns raw material into published writing — with a human approving in the middle — the first instinct is to have the machine produce finished articles and ask "yes or no?" I built mine wrong in the opposite, sneakier direction: it produced short review summaries and treated them as the finished articles. Either way it's the same mistake, and it took shipping it wrong to see why.

The moment it broke

The pipeline in question turns my AI-session history into candidate write-ups for this site: scan the sessions, extract candidate learnings, check each against what's already published, queue the survivors for my review, submit what I approve. Version one had a single artifact flowing end to end. The extractor drafted each candidate as a tight kernel — a title, tags, and two to six sentences carrying the complete argument in miniature — I reviewed those kernels, and the publisher submitted approved ones to the site's draft queue at that same length.

The first real batch was seven candidates, and reviewing them was genuinely pleasant: seven kernels scan in about two minutes. Then I pushed the approved set to the site's preview area, saw them sitting next to the essays already published there, and asked the question that forced the redesign: why do these look much shorter than the ones already on the site?

Because they were the review artifact. Nothing in the pipeline ever turned an approved idea into a finished piece — approval just forwarded the kernel. What reached the preview queue were stubs dressed as posts: abstracts of essays nobody had written.

Worth noticing: no automated check caught this, and none plausibly could have — every item had passed extraction, uniqueness, and my own review. It was caught by eye, and only because the preview area put the stubs next to real essays and the contrast was unmissable. Reviewing the output in the medium it ships in is its own quiet verification step; the same lesson I keep relearning with documents applies to pipelines.

The review artifact and the publish artifact are different documents

The document optimized for a fast decision is short: the whole argument visible at a glance, so a person can judge a batch of them in 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 someone's time. They serve different audiences making different decisions, and no single document serves both.

Publishing has run on this distinction forever. Freelance editors want the pitch, not the manuscript — as former New York Times editor Tim Herrera puts it, "attaching a draft with a pitch actively costs you money," because a finished draft forecloses the shaping an editor exists to do. Nonfiction books are sold the same way: the proposal "essentially acts as a business case for why your book should exist," in Jane Friedman's summary of how publishers buy books they haven't read — because the expensive artifact should only be written once someone has said yes to the cheap one.

Conflate the two artifacts and you fail in one of two directions. The direction I actually shipped was thin stubs. The mirror image — making the reviewer read full essays — I didn't have to suffer personally, because review research has already measured it: SmartBear's study of 2,500 code reviews found reviewers should take on no more than 200–400 lines at a sitting, that effectiveness collapses past about an hour, and Microsoft researchers found the proportion of useful review comments drops as change size grows. Reviewers saturate. Ten full essays in one sitting doesn't produce ten reviews; it produces about three reviews and seven rubber stamps.

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

The redesigned flow: generate kernels for review, let the human approve the ideas, expand only the approved ones to the site's full register, then confirm each finished piece with a final yes. Approval happens twice, on two different artifacts, and each is sized for its job. In practice the pipeline grew three output registers, not two — a kernel for review, a short note for single ideas, and a full insight for pieces that earn the length — because "expand everything to essay length" would just be the stub mistake inverted.

The order is what makes the economics work, and both wrong orders have a name. Expanding before approval wastes the costly work on ideas that get cut. Approving without an expansion step ships stubs. Cheap-to-review first, expensive-to-produce last, on survivors only — the same shape as any good filter.

The economics are the same as any staged filter. Cooper's Stage-Gate model formalizes it for product development: gates are go/kill decision points, and investment escalates stage by stage only as information improves — you spend the expensive effort exclusively on survivors of the cheap gate. The same logic is showing up in AI-pipeline design guidance: Anthropic's notes on building effective agents recommend agents "pause for human feedback at checkpoints" — and the artifact presented at a checkpoint should be sized to the decision being made there, not to the deliverable being produced downstream.

Three smaller decisions turned out to be the same principle wearing different hats. The uniqueness check runs before review — candidates are deduplicated against the live site by topic rather than title, because near-duplicates arrive dressed in new words (one batch's "chained-function syncs" candidate was an existing post wearing a new headline) — so the reviewer never spends attention on an item whose disposition is already known. A privacy gate likewise scrubs client names and internal identifiers before anything reaches the queue: whatever can be enforced mechanically gets enforced before it costs a human any attention. And every candidate exits with an explicit disposition — submitted, duplicate, declined, or parked — where "parked" matters more than it looks: an idea cut today is often just early, and a pipeline that only knows yes/no quietly destroys its own backlog. The next batch through the redesigned pipeline proved the shape: kernels reviewed in minutes, expansion run only after the approve, and the previously parked ideas promoted back into the queue with a single instruction.

Why there are two yeses

The second confirmation isn't ceremony, and the publishing world again got there first: approving a proposal is not accepting the book. Standard publishing contracts reserve the publisher's right to reject the delivered manuscript in its "sole editorial judgment" — a clause contentious enough that the Authors Guild pushes back on how it's exercised — because everyone involved knows an approved idea can still expand into a bad piece. Expansion can drift, overclaim, or flatten the argument that made the kernel worth approving. So the finished piece gets its own yes: a fast one, since the idea is already agreed, but a real one.

And the honest boundary of the whole pattern: sometimes one artifact is right. Herrera's own exception is instructive — for opinion pieces, editors want the draft, not the pitch, because "opinion pieces build an argument, so you need to show what that argument is." When the value lives in the execution rather than the premise, a kernel can't carry the decision. The two-artifact shape earns its complexity at volume — ten candidates a week, most destined to be cut. If you're reviewing one high-stakes, voice-driven piece a month, skip the kernel and just read the piece.

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 — and filter what you can (duplicates, known dispositions) before it ever reaches the reviewer. Don't make a person review what they should be reading, and don't publish what they only reviewed.