In April 2026, a designer-author received a rejection email from KDP. The book, which was well-written and complete, came back with three blockers: metadata fields incomplete—keywords and BISAC category missing—a cover image at the wrong resolution, and EPUB validation errors including missing language metadata and improper image alt text. The author had not written a bad book. The author had written a book and skipped the final check sequence. What's striking is that each of these three failures takes only minutes to fix and zero minutes to prevent. This chapter is the prevention. By running four simple steps in sequence—fact-check, build, device-read, submit—and accepting that you will rebuild, you avoid every problem in that rejection email.

Understanding the final check sequence changes everything about how you ship a book. Without it, your book fails at the gate and your publication window closes. More painfully, if a final check slips through, your readers receive a broken file, bad metadata, or covers that look unprofessional. KDP is just the symptom. The real problem is that the pipeline you've built so far—your writing, your design, your formatting—has limits. There are checks that no automated tool can run until you hand it over. A device test cannot happen on your desktop; a human reader's first impression happens in the Kindle app, not your PDF viewer. The final check sequence is where you catch what the pipeline could not. Understanding the stakes means accepting that publishing is not one step but four, and the fourth step is always acceptance of rebuild.

The sequence is simple and must be run in order. First: run the Fact-Checking Assistant and triage the results, resolving at minimum all contradicted claims. Second: run the build script to produce both EPUB and PDF files. Third: read the EPUB on an actual device—a real Kindle or the Kindle app on your phone, not a desktop viewer. Fourth: submit to KDP. Then accept that you will rebuild. The rebuild loop is not a failure of your pipeline; it is the pipeline. KDP will find issues you missed. Your device test will reveal formatting problems the build tool didn't catch. Each round of feedback is information. You fix, rebuild, and resubmit. This cycle is normal and necessary, not a sign that you did something wrong, but proof that you're doing something right—shipping to real readers under real constraints.

Before you fact-check, you need to classify claims. The Fact-Checking Assistant uses five categories drawn from professional fact-checking practice, starting with Sarah Harrison Smith's research methodology at the New York Times Magazine. A basic claim is a plain factual assertion: 'Pandoc converts Markdown to EPUB.' An emphatic claim adds a strength qualifier: 'Pandoc is the de facto Markdown-to-EPUB toolchain'—the emphasis itself needs verifying. A positive claim is affirmative against an implied alternative: 'Pandoc beats Calibre for reproducible builds'—the comparison is the assertable thing. I-language claims are first-person assertions, hard to verify externally, and usually flagged for caveat language. Combination claims carry two or more assertions in a single sentence and must be decomposed before verifying. Understanding these five types lets you know what work the assistant is actually asking you to verify.

The second classification dimension is content category. Peter Canby's department at The New Yorker established six categories that professional fact-checkers use to sort claims. STAT covers statistical claims, verified against the primary source, never a derivative summary. GUIDELINE covers best-practice claims attributed to a standards body, verified against current published guidance. APPROVAL covers claims about authority decisions, verified against the authority's published policy as of a named date. EVIDENCE covers claims that evidence supports a conclusion, verified against the cited study with strength assessed. SPECIALIST covers claims attributed to a named expert, verified against published work from that expert. CURRENT covers claims true now—the most aging-prone category because the world changes—requiring explicit verification dates. A claim about KDP's cover requirements falls into GUIDELINE and CURRENT: it must be checked against KDP's current published specs as of a specific date.

Every claim in your book sits at the intersection of a claim type and a content category. A basic statistical claim about indie ebook market share is different from an emphatic guideline claim about EPUB validation standards, which is different from a combination claim mixing evidence and specialist attribution. The five-by-six matrix gives you a framework for sorting what work needs to happen. A combination STAT claim covering three numbers requires more decomposition than a basic SPECIALIST claim about one person's published work. The matrix doesn't solve fact-checking; it makes visible what you're actually trying to verify. Once you classify a claim, you know which source to check, what kind of evidence counts as verification, and how aging will affect it over time. The Fact-Checking Assistant produces a master report showing every claim's classification and status, then your job is not to be perfect but to be deliberate about each one.

Every assertion returns one of four statuses: OUTDATED, CONTRADICTED, UNVERIFIED, or VERIFIED. You triage in that exact order because the order tracks both urgency and effort. OUTDATED claims come first. These are claims that were true when you wrote them but are no longer true—KDP's minimum cover size changed, Pandoc's feature set expanded, a quoted standard was superseded. These are the fastest to fix and the most embarrassing if they ship. A number change takes seconds. CONTRADICTED claims come second. These are claims where the cited or implied source actually says something different from what your chapter claims. Pandoc supports EPUB 3.3 partially, not fully. These require rewriting, not just fact-updating, and they're the most important to catch because they're exactly what gets quoted in one-star reviews. UNVERIFIED claims come third. These are claims you cannot verify in either direction—no single authoritative source confirms the market share of indie ebooks through KDP. VERIFIED claims need no action.

OUTDATED claims are the fastest to resolve and the most damaging to ignore. The chapter's example is precise: 'KDP requires a 1600 × 2400 minimum cover'—as of 2026 the actual minimum is higher. You find the claim, check KDP's current documentation, replace the number, re-verify it against the new source, and move on. The time cost is minutes. But if you ship that spec and a reader tries to upload a cover at 1600 × 2400, they'll fail. They'll check your book's documentation, find the wrong number, and leave a one-star review before they try contacting you. OUTDATED claims kill credibility because they suggest you didn't check your own work. The fix is trivial, but the prevention requires one discipline: before you submit, run the fact-checking assistant and flag every OUTDATED result. The rebuild loop will catch some of these, but KDP's feedback cycle is slow. Better to catch them yourself.

CONTRADICTED and UNVERIFIED claims require different strategies. A CONTRADICTED claim is one where the source you cite or imply actually contradicts you. You claim Pandoc supports EPUB 3.3 natively. The Pandoc documentation says it supports much of EPUB 3.3, but some features require post-processing. That's a contradiction. You have three options: rewrite to align with the source, cite a different source that matches your claim, or remove the claim. UNVERIFIED claims are harder because they're not wrong—they're just unverifiable. You write 'About 80% of indie ebook units in the US are sold through KDP' but no single authoritative source confirms that figure. The resolution is not to remove it, but to make the uncertainty visible. Rewrite as 'Probably the largest share of indie ebook units in the US, though no single authoritative source confirms a precise figure.' That's honest in a way the original was not. Honesty is both ethically correct and strategically better—it signals that you know what you're talking about by acknowledging what you don't.

The fact-checking workflow is the first gate in the four-step pipeline. You run the Fact-Checking Assistant once per round of writing and review. It outputs a master report showing every claim, its classification, and its status. Your job is to triage that report: verify outdated claims are actually fixed, resolve or rewrite every contradicted claim, and make deliberate decisions about each unverified claim—find a source, add caveat language, or remove it. You don't resolve every unverified claim to verified; you make a deliberate decision on each one. The assistant writes the report. You read and decide. Then you rebuild. The EPUB and PDF are only as reliable as the claims inside them, and claims are only reliable if they've been deliberately verified. The sequence is: classify, triage, decide, rebuild. That's how you prevent KDP rejection letters and ship books that readers trust.

The central insight of this chapter is almost mundane in its clarity: each of the three blockers in the KDP rejection email takes a few minutes to fix and zero minutes to prevent. You don't prevent mistakes by being perfect. You prevent them by building a sequence that catches predictable failures before they ship. Fact-checking is not a luxury step added to good authors; it's a standard gate that professional publications have used for a century. The New York Times, The New Yorker, and every other publication that cares about credibility runs fact-checking before anything ships. For you as an author-publisher, the cost is one evening spent running four simple steps. The benefit is not just avoiding rejection. It's knowing that every claim in your book has been deliberately verified, that you can stand behind what you've published, and that readers won't find errors that undermine their trust. Spend an evening running the sequence now, or spend months explaining yourself later. The choice is made in advance, during final check.