A colophon is a short page with a large disclosure risk. An editor may intend to publish an author name and edition date yet accidentally carry a production email address, local folder name, or internal note into the ebook. The safe question is therefore broader than “Which fields should I fill in?” A colophon for a KDP ebook needs an approved publication list and a direct inspection of the generated page for information that was never approved.
This workflow is based on a retained six-chapter synthetic EPUB with a generated colophon. It covers source approval, Rune Studio output, and a reopened package check. It is not a complete statement of legal imprint requirements or a prediction of current KDP acceptance.
Classify Every Candidate Before Entering Metadata
Create three categories: approved for publication, conditional, and private. Typical candidates for the approved list are title, author or pen name, publication date, edition, publisher name, and copyright notice. A contact address belongs there only when it is an intentionally public channel rather than a personal or production address.
Place staff email addresses, computer usernames, absolute manuscript paths, proofreading notes, private legal names, and contract-restricted details in the private category by default. Move an item out only after its publishing purpose and authority are clear. When law, contract, or retailer policy requires a particular disclosure, record that external requirement on the approval sheet; do not infer it from the presence of an input field in an application.
Give every approved value a stable row ID. The row should identify who approved it, the exact spelling, where it may appear, and when the approval expires or needs review. This creates a source against which generated metadata can be tested.
What the Fixed Colophon Package Establishes
The retained test publication contains six chapters. Its reopened OPF carries the recorded synthetic title, creator, and publisher strings, with language ja. Package inspection found nine spine items, six navigation links, six NCX points, and zero missing resources. Rune’s local EPUB inspection returned valid=true.
A generated colophon-related XHTML document was opened and a 180-character range was reviewed. It contained output such as date, edition, author, publisher, and copyright information. The number 180 is the length of the retained excerpt, not a recommended colophon length. The fixed EPUB contains no image resources, so evidence from another cover-oriented test must not be imported into this result.
These observations provide a reproducible package baseline. They do not certify that the displayed facts are legally sufficient for a particular market.
Map Approved Rows to Individual Input Fields
Enter metadata one field at a time and record the approval-row ID beside it. Keep title, creator, publisher, date, and edition separate rather than combining several facts in one free-text field. Atomic values are easier to trace and replace when a correction affects only one item.
Set the volume and publication information in Rune Studio, confirm the six-chapter sequence, and export to a new filename. Record the output SHA-256, close the file, and reopen that exact package. Inspecting only the project settings is insufficient because the deliverable is the generated XHTML and metadata, not the input form.
If an optional field is not needed, leave it empty rather than filling it with a working note. Treat every entered value as potentially publishable until output inspection proves where it appears.
Read the Generated Colophon and Search the Whole EPUB
First compare OPF title, creator, publisher, and language with the approval sheet. Then open the generated colophon and read it from beginning to end. Make two decisions: all required approved values are present, and no unapproved value is present. Passing the first condition does not imply the second.
Search the expanded EPUB for signals of production data: @, /Users/, a workstation account name, internal domains, ticket identifiers, and distinctive strings from editorial notes. The leak may occur in a title page, metadata file, or another generated document rather than in the visible colophon.
An automated zero-result is still not a complete privacy judgment. Personal names and free-form notes may not match a reliable pattern. A reviewer should compare generated text directly with the approved and private lists. Record the file and surrounding text for each match so the source can be traced.
Correct the Authoritative Input, Not the Generated Page
Deleting a private value directly from generated XHTML creates a fragile one-off artifact; the next export can restore it. When an unapproved value is found, identify the project field or source document that supplied it and correct that authoritative input. Export under a new name and preserve the rejected package digest.
Recheck both sides of the approval decision. Confirm that the private value is gone, then confirm that required title, author, date, and publisher information was not removed with it. Verify that the colophon remains toward the end of the spine and that all six chapter destinations still work in the navigation document and NCX.
Even though the correction concerns disclosure, regeneration can change the whole package. Rerun the zero-missing check and retain the new OPF and colophon evidence beside the previous version.
Do Not Promise Automatic Privacy Removal
The command-line workflow used for this evidence does not expose a dedicated public-contact field and does not establish an automatic private-information removal guarantee. Treat every supplied value as data that may reach output, and require a human review of the package. A field that appears secondary or hidden in an interface is not necessarily private.
The fixed package’s valid=true result is a local structural result. It does not prove legal sufficiency, comprehensive detection of private information, KDP acceptance, or identical rendering on every device. The W3C EPUB 3.3 specification defines publication structure, while legal, contractual, and retailer disclosure rules require their own current checks.
Keep those decisions in separate records. A technically valid EPUB can contain inappropriate text, and a carefully approved colophon can sit inside a structurally broken package.
Hand Off the Approval Record With the EPUB
The final handoff should include every approved value, its generated output value, the inspected XHTML path, search terms, review date, and EPUB digest. For the controlled sample, the evidence supports six chapters, nine spine items, six nav links, six NCX points, zero missing resources, the OPF metadata comparison, and the 180-character colophon-related read. Define new expected values for the production title rather than copying those sample counts.
Ask a second reviewer to read the generated colophon while following the approval sheet. The reviewer should confirm that required public facts are present, private facts are absent, the colophon appears at the intended rear position, and all chapter navigation still works.
A colophon for a KDP ebook is not complete when its fields have merely been populated. It is complete for handoff when the generated page has been reopened, approved information has been matched, unapproved information has been searched for and excluded, and the exact inspected EPUB is the file moving to the next acceptance stage.
