Publishing tools can preserve decisions, revisions, and source records by treating the book as a managed project, not just a finished PDF. For a hardcover or illustrated edition, keep a decision log for trim size, color, bleed, paper, ISBN, cover dimensions, image sources, rights, and metadata, then tie each later file to that record. Use tools that export source files, revision notes, asset lists, and KDP-setting snapshots, and confirm current KDP requirements inside your account before upload because available settings can change.
Start with a project record before you design the book
For a hardcover or illustrated edition, the more practical question is whether your publishing workflow can remember why each production choice was made. A beautiful cover file is not enough if you cannot later identify the trim size it was built for, the image license behind it, or which manuscript version it matches.
Create one project record before formatting begins. This can be a spreadsheet, database, project management board, or publishing tool with exportable fields. The record should include the book title, subtitle, author name, edition type, intended format, ISBN plan, trim size, interior color choice, bleed decision, paper choice if applicable, source manuscript location, cover source location, image folder, font list, and the date each decision was made. The point is to make later updates traceable instead of relying on memory.
Capture hardcover and illustrated edition decisions first
Hardcover and illustrated books create dependencies that are easy to overlook. Trim size affects page layout, cover dimensions, spine width, image placement, and sometimes the reader’s perception of the edition. Bleed affects whether illustrations reach the page edge. Interior color affects file preparation and production cost. Page count affects spine measurements. If you change one of these later, several files and metadata fields may need to be revised together.
Record trim size, whole-file bleed setting, margins, page-count target, chapter openings, front matter, image resolution, and the role of each illustration before final layout. Keep planned decorative interior pages distinct from unsupported custom binding components. Verify the actual hardcover specification and case-wrap template rather than treating a generic formatting page as a list of supported products.
Keep a source manifest for art, fonts, and permissions
An illustrated edition needs a source manifest. This is a list of every non-text asset used in the book and cover. Include the file name, creator, license or permission status, date obtained, original location, edited file location, and where the asset appears in the book. If an image was created or modified with an AI tool, record the tool, date, prompt or project name if available, input images used, and any license terms you relied on. Do not assume that a generated file is safe to use commercially without reviewing the tool’s terms and your own rights position.
The manifest protects future revisions. If you later replace a spread, create a large-print edition, update the cover, or respond to a rights question, you can see what was used and why. It also helps avoid accidental substitutions, such as placing a low-resolution web preview into a print file or using a font that was licensed for desktop design but not embedding. Publishing tools are most useful when they can package or export this asset list instead of locking it inside a project dashboard.
Use version names that connect source files, proofs, and uploads
A revision history should connect the editable source file, the exported print PDF, the cover PDF, the proof copy, and the KDP upload event. Avoid vague names such as final.pdf, final2.pdf, or real-final-cover.pdf. Use a simple naming pattern that includes the title abbreviation, format, trim size, version number, and date, such as BookTitle_HC_6x9_Interior_v03_2026-08-25.pdf. Use the same version number across the matching cover and interior files when possible.
Keep a short change log for each version. The log does not need to be elaborate. It should state what changed, who changed it, why it changed, and which files were replaced. For an illustrated hardcover, useful entries might include “increased gutter margin after proof review,” “corrected image credit on copyright page,” “re-exported cover after page count changed,” or “updated subtitle on title page to match metadata.” This prevents a common problem: fixing the interior while accidentally uploading an older cover, or updating metadata without updating the title page.
Tie metadata decisions to the files they depend on
Record metadata alongside the source files, including title, subtitle, author, contributors, series, language, description, keywords, categories, reading age, and ISBN. Before publication, reconcile identity fields with the cover and title page. For a published print book, title, subtitle, and primary-author changes are limited to the initial 72-hour window once the book is out of review; later identity changes require a new edition. Do not treat a subtitle revision as an ordinary file correction.
A hardcover and paperback require separate ISBNs. A page-count revision can change the case-wrap template, while a change of trim or ink type may require a new edition rather than an in-place update. Save the production specification and a dated metadata snapshot before each upload so the record identifies both the files and the edition they belong to.
Let AI assist, but do not let it become the only record
AI tools can help summarize change logs, compare descriptions, check consistency between a title page and metadata, generate file-name suggestions, or flag missing image credits. They can also help create production checklists for a hardcover or illustrated edition. That is useful, but the author or publisher still needs a durable record that can be opened without the original AI session. If a tool cannot export your decisions, source notes, and revision history, copy the important information into your own system.
For generated artwork or text, preserve the tool and asset origin even after human editing. Record the rights terms reviewed and the final approved file, and retain the KDP disclosure answer for the generated content being published. For metadata research, save the actual entries selected and the reason for them; a list of unused suggestions is not the publication record.
Build a pre-upload and post-upload preservation habit
Before each KDP upload, pause and create an upload packet. It should include the editable interior source file, exported interior PDF, editable cover source file, exported cover PDF, source manifest, font list, image folder, change log, metadata snapshot, and proof notes if you have them. If you ordered or reviewed a proof, keep the proof comments with page numbers and the version they refer to. Proof feedback that is not tied to a version becomes confusing after the next export.
After upload, record what KDP accepted for review, what you changed in response to previewer warnings, and the date of the live or updated edition. If you later update the hardcover, repeat the packet rather than overwriting the old one. This gives you an audit trail for future corrections, new formats, foreign editions, special editions, or retailer updates. The best publishing workflow is not the one with the most automation. It is the one that lets you understand, months later, exactly which choices shaped the book readers received.
Frequently asked questions
Clear answers for this publishing decision.
What is the minimum record I should keep if I do not use a publishing database?
Keep one spreadsheet or document with four tabs or sections: decisions, source assets, revision log, and metadata. Store it in the same main folder as your manuscript, cover files, exported PDFs, and proof notes. Make a dated copy before every major upload.
Should I keep old files after KDP accepts the newest hardcover files?
Yes. Do not overwrite the prior source and PDF files. Archive them in a dated folder so you can identify what was live before a correction. This is especially important when a page count change affects the cover spine or when an illustration is replaced.
How do I track decisions that affect both the cover and the interior?
Mark them as linked decisions in your log. Page count, trim size, bleed, title, subtitle, contributor credits, series name, and ISBN can affect both files. When any linked decision changes, check the interior PDF, cover PDF, title page, copyright page, and KDP metadata together.
Can AI tools create the decision log for me?
They can help draft or summarize it, but you should review it and store it somewhere you control. The reliable record is the dated, exportable version that names the approved files, sources, rights notes, and KDP entries. Do not rely only on chat history or a tool’s internal project memory.
How often should I confirm KDP requirements?
Confirm them before building final files and again before upload, especially for hardcover trim, cover setup, bleed, color, pricing, and metadata fields. KDP options and instructions can change, so use the current guidance inside your KDP account and Amazon’s help pages rather than relying on an old template.
How wide does the full-wrap cover need to be, and how thick is the spine?
The cover width is back cover plus spine plus front cover plus bleed on both sides; the spine width is the final even page count multiplied by the paper-specific factor Amazon publishes, so the cover cannot be sized before the interior page count is final.
Prepare the cover in a book project