KDP manuscript QA
Before you upload a manuscript to Kindle Direct Publishing, score each chapter for generic filler, weak sourcing, and the kind of advice-shaped paragraphs that read fine in isolation but read hollow across 200 pages. Reviews are forever; the gate runs once.
KDP guides are a category where AI-assisted drafts have flooded the market faster than reader trust has adapted. The pattern is consistent: chapters open with a strong specific anecdote (because the author wrote that part themselves) and then drift into category-level advice (because that's the part the generator filled in). Readers feel the seam. The chapter-level scoring gate is specifically designed to catch the drift — you'll usually see slop_risk spike in the middle third of a chapter, exactly where the author handed off to the model.
Business value
- Protects the launch window. KDP's review velocity (first 30 days) compounds. A flurry of one-star 'feels AI-written' reviews in the first week is hard to recover from.
- Catches the chapters that drift into AI-shaped advice before the editor reads them, so the editor reviews concrete drafts instead of 80,000-word soup.
- Surfaces the high-risk safety/legal/medical sections that should never autopublish — books are durable; bad advice in chapter 7 is liability for years.
Agent job to be done
Be a developmental editor with a deadline. Score each chapter, flag the sections that feel generic or unsupported, and produce a chapter-level revision queue ranked by both risk and importance to the book's argument.
format: articleintended_use: publishdomain: KDP manuscript QA / self-publishing editorial
KDP-specific failure modes the score won't catch
The API doesn't know about KDP's narration-AI policy (manuscripts produced primarily by generative AI must be disclosed during upload), Amazon's quality-removal patterns, the title-stuffing patterns that trigger A+ Content rejection, or the ASIN-level review-velocity dynamics that shape week-one survival. Pair the gate with a manual KDP-policy review checklist for any AI-assisted manuscript, and run an A+ Content preview before final upload.
When to call VeracityAPI
After the full manuscript draft, before final proofing and layout. Re-run after major chapter rewrites — the first revision is rarely the last.
What text to submit
Chapter text, chapter title, subheads, callouts/sidebars, checklists, and chapter-end summary. Score per chapter (and for long chapters, per H2 section). Don't score the whole book in one call — you lose evidence resolution and the analysis_id stops being actionable.
Decision policy
- allow: chapter proceeds to copy-edit and layout.
- revise: chapter needs concrete examples, named sources, clearer steps, or less category-level advice. Most chapters land here on first pass.
- human_review: chapters with health, legal, financial, or safety claims; OR chapters where provenance_weakness ≥ 0.70 (the book is making claims it can't back up).
- reject: only after two failed rewrite cycles, or chapters where the entire premise is restated common knowledge.
Request template
The exact payload shape this use case sends. The sample below uses representative content for this workflow; substitute your own.
curl https://api.veracityapi.com/v1/analyze \
-H "Authorization: Bearer $VERACITY_API_KEY" \
-H "Content-Type: application/json" \
-d '{"type":"text","content":"Travel scams are a major problem around the world. This chapter will teach you important information to stay safe, avoid danger, and make smart decisions wherever you go.","context":{"format":"article","intended_use":"publish","domain":"KDP manuscript QA / self-publishing editorial"},"store_content":false}'Automation recipe
- Split manuscript by chapter using stable IDs (chapter_03_packing_for_southeast_asia, not chapter_3 — KDP rewrites can shuffle ordering).
- Score each chapter with intended_use=publish.
- Create editorial tickets in your project system (Notion, Asana, Linear) with the evidence spans pasted into the ticket body.
- Revision agent (or human writer) patches the flagged sections with examples and sources.
- Final QA agent rescores; only chapters at allow proceed to layout.
Evidence spans agents should inspect
- 'category_advice' — 'always pack light' / 'do your research' / 'be careful with strangers' without telling readers HOW
- 'unsupported_claim' — health/legal/financial claims with no cited source
- 'filler_intro' — chapter intros that restate what the reader will learn without starting to teach
- 'recycled_warning' — the same caution repeated in different words across chapters
Policy pseudocode
if (result.recommended_action === "allow") continueWorkflow(); if (result.recommended_action === "revise") rewriteWith(result.evidence, result.recommended_fixes); if (result.recommended_action === "human_review") queueForHumanReview(result); if (result.recommended_action === "reject") discardOrRebuild();
KPIs to track
- chapters flagged before final proof
- average revision cycles per chapter
- reader review quality signal (verified-review keyword analysis for 'generic,' 'AI,' 'unhelpful')
- Kindle refund/return rate in first 90 days post-launch
- editorial cost per finished book
What can go wrong
- Don't use the score as your only editorial decision. Books are long, idiosyncratic, and voice-driven; a chapter can score 'allow' and still have a structural problem the API won't see.
- Safety, legal, and medical claims need independent verification regardless of the score. The gate is not a fact-checker.
- Score long chapters by section. A 6,000-word chapter scored whole loses the resolution you need to actually fix it.
Cost and latency notes
Analyze only is $0.005 per 1,000 characters; Analyze + revise with auto_revise=true is $0.010 per 1,000 characters. Both round up to the nearest 1,000 characters. Short captions/emails usually cost $0.005; longer pages or chapters scale linearly by length. Current v0.1 latency is LLM-bound, so batch/concurrent orchestration is recommended for high-volume pipelines.
Agent evaluation checklist
- Does this workflow have a costly failure mode from generic or weak-provenance text?
- Can the agent map evidence spans back to editable source locations?
- Should this workflow fail open, fail closed, or queue human review if VeracityAPI is unavailable?
- Which field drives policy: recommended_action, risk_level, content_trust_score, specificity_risk, or provenance_weakness?
- What local rule should complement the API score?