Lessons 85.1 and 85.2 set the job and the pipeline. Now the most mishandled step: where AI actually helps. Teams fail in opposite directions — banning AI from drafting while drowning in production work, or letting it invent claims, quotes, and case studies with total confidence. Both mistakes come from one confusion: treating fluency as knowledge.

The rule: AI is strong at production; evidence controls knowledge.

What AI is genuinely good at

Give AI work where the material is provided and the transformation is checkable:

• Structure: turning a brief into an outline, ordering scattered notes into a coherent flow.
• Variants: one approved message reshaped per channel — the email version, the short social version — without new claims.
• Summaries of provided material: condensing the research packet you supplied, never the open web it half-remembers.
• Metadata: titles, descriptions, tags, internal-link suggestions from the finished draft.
• Backlog organization: clustering audience questions, spotting duplicates, ranking by frequency — turning a messy pile of requests into a ranked queue the editor can assign from.

Notice the pattern: in every case a human could verify the output against an input in minutes. That checkability is what makes these steps safe amber marks on the 84.4 ladder — and what makes uncheckable open-ended generation unsafe there.

What evidence controls

Four things AI must never supply on its own authority, no matter how plausible the output sounds:

• Claims about the world: statistics, comparisons, "best" judgments. Each needs a packet source.
• Quotes: exact words with exact locations. A paraphrase labeled as a quote is fabrication.
• Current product facts: prices, features, limits, policies. These change constantly and models remember stale versions confidently.
• Real case studies: named organizations and outcomes. Never invent customers, results, or stories.

Teach the workflow three habits: source packets (nothing downstream cites what is not in the packet), verification checks (every claim, quote, fact, and case traced before review), and unknown fields — explicit "unknown" markers where evidence is missing. An unknown the team can see gets researched. An unknown papered over with fluent text ships as a lie. Final editorial review stays human, always: the machine prepares, the editor decides.

The most common failure deserves a name: the confident fill. The draft reaches a gap — a statistic the packet lacks, a product detail nobody verified — and instead of marking it unknown, the prose flows smoothly over it with something plausible. It reads well, which is exactly why it survives review. Counter it structurally: require every draft to carry its unknown list up front, check the list before reading the prose, and treat a missing unknown marker discovered in review as a process defect worth logging. Teams that do this find review gets faster, because the reviewer stops hunting for hidden gaps and starts judging visible ones.

Exercise: write your CONTENT-REVIEW-CHECKLIST.md

Create the gate every piece passes before publishing:

# CONTENT-REVIEW-CHECKLIST

## Accuracy
- [ ] Every claim traces to the research packet (spot-check 3+).
- [ ] Quotes verified word-for-word with locations.
- [ ] Product facts current as of [date]; stale items flagged.
- [ ] No invented cases, customers, or results.

## Voice
- [ ] Reads as us: [2–3 voice markers, e.g. direct, specific, no hype].
- [ ] No generic filler the brief did not ask for.

## Originality
- [ ] Says something our sources alone do not; point of view present.
- [ ] Derivatives add value, not just rewording (see 85.4).

## Usefulness
- [ ] Answers the assigned audience question completely.
- [ ] Reader's next step is stated.

## Publishing
- [ ] Assets finished; metadata filled; links checked.
- [ ] Unknowns resolved or explicitly marked; reviewer signed + dated.

Finish line: a checklist file the reviewer actually initials per piece — with rejections and correction lists treated as the system working, not as friction.

Verify: run your last published piece through the checklist retroactively. Every unchecked box is a gap in the published record — log it as an update need (Lesson 85.5) and schedule the fix.

Common failure mode: the checklist becomes a rubber stamp under deadline pressure. Protect it the 84.4 way: the reviewer sees evidence (packet, diff, sources), quotas never override the gate, and skipped checks are recorded as exceptions, not silently passed. Watch especially for deadline creep — the quiet agreement that "this one is time-sensitive, so we'll check after publishing." After publishing, nobody checks. The gate either holds on the busiest day or it holds on no day; schedule the review time before you schedule the publish date.

Check your understanding

1. What makes a summary of provided material checkable in a way open-ended research is not? 2. Why are explicit "unknown" markers safer than fluent complete-sounding text? 3. Which checklist section protects the publication's point of view, and how?

Next, Lesson 85.4: the published piece is not the end — turn one canonical lesson into six derivatives and build a library that compounds.