Create a Release Manifest for Your Book Files

A release manifest is a short record naming the exact files that belong to one book edition. Include the interior, cover, metadata sheet, relevant specifications, and review status. Use it to prevent individually correct files from different revisions being combined during an upload or later correction.

Give the release a stable identity

Choose a simple release identifier and use it consistently across the production folder and manifest. Include the book, edition or format, and revision. Avoid relying on a filename such as final-final, which says little about what changed or which file was reviewed.

The identifier does not need to be technically elaborate. Its purpose is to let you and a collaborator refer to the same set of files unambiguously. If the interior changes after approval, create a new release entry rather than silently replacing the file associated with the old one.

List the files and their roles

Record each filename, its role, and the source revision it came from. Separate the production export from its editable source. Include the metadata sheet so the wording entered during publication matches the cover and title page.

For a print edition, the manifest might list an interior PDF, cover PDF, editable layout package, and metadata document. For another format, the file set may differ. Use the current requirements for that edition. Do not create a universal checklist that assumes every format uses the same production artifacts.

Record the important shared inputs

Include the choices that connect the files: format, trim size where relevant, final page count, and the specification used for the cover. Record the source and date of material KDP requirements you checked. Keep provisional assumptions clearly separate from confirmed inputs.

If your workflow uses file checksums, include them to identify exact bytes. A checksum can detect that a file changed, but it does not prove the content is correct. The manifest still needs meaningful review records and a clear explanation of what was approved.

Make approval specific

Add the review performed, reviewer, date, and result for each artifact. Text proofread, exported dimensions checked, and cover compared with current template describe different work. A single approved label can hide those distinctions.

Keep unresolved problems visible. A manifest that looks complete by omitting pending decisions is less useful than a short document that accurately shows what remains.

• Name each production file exactly.
• Link it to its editable source revision.
• Record shared edition inputs.
• Identify completed reviews and unresolved issues.
• Name the matched files intended for submission.

Use the manifest at upload and archive time

Before submission, compare the selected files with the manifest. After submission, record what was actually uploaded and retain the response or review notes relevant to that release. This creates a traceable connection between your local approval and the platform action.

Archive the entire matched set together. A later correction can then start from a known release instead of whichever file appears newest in a folder. The manifest is especially valuable when several people handle editing, design, and upload because it reduces the amount of production knowledge that exists only in conversation.