A platform message is a symptom, not always a diagnosis
An upload system sees the submitted artifact and the settings selected in the title record. It may report that content is outside a margin, a page size is wrong, or an image is low resolution. The visible marker is valuable, but the underlying cause can sit earlier in the workflow. The trim may have changed after layout. The final page count may have crossed a gutter threshold. A cover may still use the spine from yesterday’s interior. An image may have adequate source pixels but inadequate effective resolution after enlargement.
Treat the message as an observation to reproduce. Confirm the selected print options, inspect the exact page and PDF properties, then locate the source decision that created it. A durable repair changes that source and regenerates the artifact. A superficial repair moves the flagged object just far enough to clear one check without asking whether the page remains readable or the same issue occurs elsewhere.
Why the repair stage matters
Production failures become more expensive the later they are addressed. A trim decision belongs in planning. A missing chapter or duplicate matter belongs in the manuscript. Gutter, running heads, and blanks belong in page composition. Encryption and font embedding belong in export. Spine width belongs in cover production after pagination. The physical feel of the gutter belongs in proof review. Routing work correctly prevents the release file from becoming a pile of local exceptions.
The taxonomy includes a repair-stage column to make that ownership explicit. It also exposes repeated system failures. If every title produces a new running-head error, the template or release checklist needs revision. If covers repeatedly mismatch interiors, the organization is starting cover production too early. The objective is not merely to get one upload through; it is to build a publishing operation that becomes more reliable with every release.
Technical acceptance is not the same as a good print book
Some of the worst reader experiences never trigger a hard error. A gutter can meet the published minimum and still be uncomfortable. A typeface can be embedded and still be poorly chosen. An image can clear a resolution threshold and still print muddy. Page numbers can be inside safety and still appear on pages where they do not belong. The physical proof is where technical compliance meets the object a customer will hold.
For that reason, the taxonomy ends with visual proof failure. It is not an edge case; it is a reminder that automated acceptance cannot approve taste, rhythm, or material interaction. Order a proof after the interior and cover have stabilized, mark it like an editor, return changes to the maintained source, and export again. Do not let “the portal accepted it” become the quality standard for a product sold to readers.
About the data and its limits
This dataset organizes KDP’s public production rules into a root-cause model. It does not contain customer support tickets, private rejection logs, or a measured frequency distribution. We therefore do not label any item “most common” or attach invented percentages. The version date tells readers when the official source was last checked, and the JSON makes every row reusable in an internal checklist or QA system.
It also covers production-file failures, not every policy, metadata, rights, content, account, or marketplace issue that can affect publication. If the platform message concerns identity, ownership, prohibited content, metadata, or title status, use the relevant official workflow. The lab’s scope is deliberately narrow enough to be useful and accurate.