Match a Preflight Report to the File You Will Upload

Confirm that a preflight report describes the exact file intended for upload and the checks relevant to that format. Match the file identity, production assumptions, and review time before interpreting a passing result. If the file changes afterward, determine which checks must be repeated. A clean report for a different export is not evidence about the current candidate.

Identify the tested artifact precisely

Find the file name and version recorded in the report, then compare them with the candidate in the upload folder. A generic name such as novel-final.pdf is not enough if several exports have used it. Look for a reliable version identifier or file fingerprint where the workflow provides one. A fingerprint is a value calculated from the file's contents that can help distinguish otherwise similarly named files.

If the report records only a name and date, investigate how the candidate was preserved after testing. File timestamps can change during copying and do not by themselves explain the full revision history. Keep the tested file with its report in a clearly labeled package. The practical question is whether you can demonstrate that the evidence applies to this artifact, not whether the document contains a reassuring green status.

Read the scope before interpreting the result

List the checks actually performed. A report may examine page dimensions, font embedding, image properties, or structural issues without evaluating story continuity, readability, rights, or metadata accuracy. Treat untested questions as untested. The absence of a warning about a topic outside the tool's scope does not establish that the topic is satisfactory.

Check the assumptions under which the tests ran. A report based on one trim size or format can be inappropriate for another even if the file itself has not changed. Record the intended production setup alongside the report and compare it with the current KDP requirements for that edition. A technically consistent file can still be the wrong file for the settings selected during submission.

Separate warnings from unresolved decisions

Review each warning in context and record the action taken. Some findings may identify a definite export defect; others may require the author or designer to decide whether an element is intentional. Do not dismiss every warning to obtain a cleaner-looking report. Equally, do not make arbitrary changes to intentional content without understanding what the check detected.

For example, an unexpected blank page may come from a duplicated break, while another blank page may belong to the approved chapter-opening design. The report can help locate both, but the production record and surrounding content explain the difference. Preserve the reason for any accepted exception so a later reviewer can distinguish a deliberate choice from an alert that was ignored without investigation.

Recheck after changes to the candidate

Record every change made after the report was produced. Replacing an image, correcting a name, updating back matter, or exporting with a different setting can produce a new artifact even when the file name stays the same. Determine which checks depend on the change and run them on the replacement file. Do not attach the old report to the new file solely because the revision appears minor.

Keep editorial and technical evidence connected but separate. A proofreader may approve a text correction, while the fresh export still needs its own production review. Conversely, a passing preflight does not establish that the corrected sentence is accurate. The release record should show how the final candidate reached its approved state, including which evidence was reused legitimately and which checks were performed again after the change.

Deliver the report with its matching package

Place the approved file, report, production assumptions, and resolved-warning notes together in the handoff. Give the uploader a clear manifest that identifies the intended candidate rather than leaving several similar files available without explanation. Preserve the earlier package separately as superseded. This reduces the chance that a valid report accompanies an accidental upload of a different revision.

Use the appropriate KDP preview and submission checks on the actual uploaded file. Local preflight evidence supports preparation but does not replace the platform's own assessment or the author's editorial responsibilities. If a discrepancy appears, begin by confirming file identity and setup before guessing at a content problem. A traceable package makes that investigation much more efficient than relying on the memory that a report once showed no errors.