Lessons 66.1 through 66.3 built the machine: a conversion map, an editorial OS, agent help with human gates. This lesson keeps the machine honest. An engine without a review loop does not improve — it just repeats, louder each cycle, until the audience leaves.

Four jobs, in order: check, listen, preserve, improve

The review loop has four jobs, and their order matters:

1. Pre-publish: check quality and integrity. Does the asset say something true, clearly, in a shape the audience can use? Facts, brand fit, legibility, accessibility, permissions — the publishing checklist from Lesson 66.2 runs here, before anything goes live. 2. Post-publish: read the response. What did people actually do — watch through, click, save, reply, ignore? Signals, not vanity. A million views with zero next actions is information, not success. 3. Preserve: store the findings. Log what worked, what failed, and what it cost into the learning log while memory is fresh. Unwritten learnings evaporate by next week. 4. Improve the next brief. The loop's output is not a report — it is a better brief for the next round. If the postmortem does not change what you make next, it was paperwork.

Beginners skip straight from publishing to producing more. Professionals close the loop first, because the second round built on evidence beats the tenth round built on habit.

The postmortem: six questions, answered briefly

Keep the postmortem small enough to actually run every time. Six questions, a paragraph or less each:

1. What did we claim? (the central promise in one sentence)
2. Who was it for? (the specific audience, not "everyone")
3. Did the asset make the claim clear? (clarity verdict + evidence)
4. What did people actually do? (observable response: retention, clicks, replies, saves)
5. What feedback is useful? (one signal worth keeping, one noise to discard)
6. Repeat, improve, or stop? (the decision + the reason)

Question 3 deserves emphasis: clarity is testable. Show the asset to one person in the target audience and ask them to restate the claim. If they can't, the asset failed regardless of its view count. Question 5 needs discipline too — a single loud comment is not a pattern, and silence from the right audience is itself a signal. Write down what you are deliberately ignoring and why; that note protects the next brief from anecdote-driven whiplash.

Run the postmortem on a fixed rhythm — weekly for active channels, per-asset for expensive pieces — and keep each one to a single file. A backlog of unexamined publishes is how weak assets get endlessly remixed instead of replaced.

Retire without sentimentality

Not everything deserves another round. Retire a format or series when any of these hold:

• It no longer serves an audience need — the question it answered stopped being asked.
• The evidence went stale — sources aged out, products changed, claims no longer hold.
• Cost overwhelms value — production time, review load, or tool spend exceeds what the response justifies.
• It confuses or damages — viewers misunderstand the promise, or the series drifts off-brand.

Retirement is a decision, not a disappearance. Record it in the learning log with the reason, archive the assets, and redirect the slot on the board to the replacement experiment. The engine improves as much by stopping as by starting — every retired series frees a research cycle for something the audience actually wants now.

Note the trap this avoids: the endless remix. A weak asset re-clipped five ways is still weak, and each remix spends review attention that a fresh, better-researched idea deserved. The postmortem exists to tell you which outcome you're in — improve the execution, or replace the idea.

Cost belongs in the review alongside applause. Log production and review time per asset, including the agent-assisted steps from Lesson 66.3, and ask whether the response justified the spend. An asset with modest reach but ten minutes of production time can be a better engine citizen than a hit that consumed a week. Engines survive on return per effort, not on highlights alone.

Exercise: postmortem one real asset, then write the next brief

Pick one real published piece — yours, not a hypothetical. Fill in CONTENT-POSTMORTEM.md:

# Content Postmortem — [asset title, date, channel]

## Claim / audience / clarity
- Claim:
- Audience:
- Clarity check (method + result):

## Response
- Observed signals:
- Useful feedback:
- Ignored noise (and why):

## Cost
- Production + review time:
- Worth it? (yes / no / with changes):

## Decision: repeat / improve / stop
- Decision + reason:

## Next brief (one paragraph)
- Changed audience, claim, shape, or proof:

The last section is mandatory. Even a "repeat" decision must state what stays identical and what gets tested next — otherwise the engine has a treadmill with documentation. A "stop" decision must name the replacement experiment that takes its board slot.

Done means: one CONTENT-POSTMORTEM.md plus a next brief that visibly changed because of it. Verify: hand the postmortem to someone unfamiliar with the asset and ask whether they can state the repeat/improve/stop decision and its reason without asking you. Common failure: a postmortem that praises the view count, lists no clarity check, and changes nothing. That is a trophy, not a loop — redo questions 3 and 6 until the next brief moves.

Check your understanding

• Why must the postmortem end in a next brief rather than a score?
• How do you test clarity separately from popularity?
• When is retiring a series the right call even if it still gets views?

In the next lesson you will go upstream to where quality really starts: research — the work that gives the whole engine something worth converting, and the highest-leverage use of AI a creator has.