Fact-check claims and numbers

Complete Create the email follow-up version first.

A deck needs a fact-check pass before it is used to make decisions or promises. This lesson asks you to make a fact-check log, not a prettier version of scattered notes. The output should be specific enough that someone could open the deck file and see what changed.

Here is the before and after: Before, numbers and claims are trusted because they made it into the deck. After, each claim has a source, date, owner, and status. For example, if you are preparing a sales presentation, the artifact should name the audience, slide job, proof, speaker note, or export check where that detail matters. A reviewer should be able to tell whether the deck is closer to being presented, sent, or handed off.

Now try it: Build a fact-check log from the deck and mark each item verified, needs source, outdated, or remove. Make one choice before asking Claude to write: which audience, which decision, which proof, which slide job, or which delivery mode matters most right now. That choice keeps the deck from becoming a generic presentation outline.

The lesson is done when the artifact moves the deck toward a real room, reader, or file handoff.

Create a fact-check log for this deck. Extract claims, numbers, customer quotes, market statements, and promises. Return Claim, Slide, Source, Date, Owner, Status, Risk, and Fix. Deck: [paste].

If any input is missing, ask me up to three questions before producing the artifact. Then return five sections: Finished Artifact, Realistic Deck Example, Assumptions To Check, What I Should Use In The Next Lesson, and One Risk If I Present Or Send This Without Fixing It. Keep the answer practical enough that I can paste it into my deck working doc.

Finished Artifact:
- a fact-check log
- Why it matters: it gives the deck a concrete thing to inspect instead of a vague intention.
- Use it next: paste this artifact into the next lesson before asking Claude to write, build, import, publish, or review anything.

Reality Check:
- The artifact names the user, input, decision, owner, or proof it depends on.
- The weakest assumption is visible.
- The next step can be completed in one sitting.

What good looks like

• Claims and numbers are extracted.
• Each item has a source or missing-source label.
• Dates and owners are included.
• Risky claims have a fix.

Without rereading the lesson, explain why a fact-check log matters in three bullets. Then apply it to a second deck example: [describe a different audience, room, or topic]. Return What Changed, What Stayed The Same, What To Check Before Presenting Or Sending, and the exact next action.

Transfer Check:
- What changed: the second example has a different audience, input, or delivery context.
- What stayed the same: a fact-check log still needs a source, a review check, and a next step.
- Before trusting it: inspect the delivery check that would catch a wrong assumption.
- Next action: run the check once, then carry the revised artifact into the next lesson.

What good looks like

• You explained the lesson idea from memory before applying it again.
• The second example changes the artifact instead of copying the first answer.
• The delivery check names a real risk.
• The next action can be done in one sitting.