Abstract
A creator can finish a manuscript, approve a cover, and retain a valid publication file without yet possessing a complete route to public life. A title still needs a way to be identified, listed, administered, authorized, paid for, delivered, discovered, and understood if a service relationship changes. These needs do not prove that self-publishing has failed, nor that every intermediary is a gatekeeper in the same sense. They establish a more useful fact: a finished file is production capability, while public publication depends on a set of service, account, rights, record, transaction, and audience relationships.
This paper introduces the toolchain dependency surface: the set of outside services, rules, accounts, intermediaries, and audience channels that condition a title’s ability to be found, acquired, paid for, delivered, administered, or sustained after its files are ready. It offers the Toolchain Dependency Audit, an original Wexley teaching instrument that helps readers name a function, controlled asset or permission, current holder, rule, local record, failure signal, continuity question, and escalation boundary. The instrument is not a platform ranking, business plan, legal checklist, rights opinion, payment calculation, or recommendation to avoid or use a named service. Its purpose is to make a particular title’s public dependencies legible enough to inspect and revisit.
The book is finished; the publication is not
Avery Lin has completed a book. The fictional title is River Index. Its manuscript has been edited. Its cover is final. Avery has a publication-ready file in a local folder and can make another copy of it without asking anyone’s permission.
That is a meaningful achievement. It establishes that the work can be revised, rendered, and kept by its author-publisher. But then a reader asks a plain question: “Where can I get the current edition?” Avery can point to the file, but cannot yet answer several other questions. Which public title record distinguishes this edition from another format? Which account has authority to change that record? Who accepts a payment? Where is a payment report shown? Which agreement represents that Avery has the relevant rights? How does a reader receive the appropriate copy after a request? Which contact receives a policy or account notice? What will still be understandable if a service relation changes?
The title is finished. Its publication route is unfinished.
This distinction is easy to miss because contemporary self-publishing systems can place file conversion, public listing, distribution, reports, payments, and promotion-adjacent features close together. Draft2Digital’s current terms, for example, describe tools for turning manuscripts into digital and physical works, controlling selected book metadata, accessing third-party retailer, subscription, and library channels, reviewing sales reports, and receiving royalties less commission. The same terms also require a participant to represent that it has the necessary publishing/distribution rights and grant a nonexclusive distribution license.[1] Kobo Writing Life’s terms similarly join submitted works and metadata with specified rights authorization, conversion/reformatting, digital distribution through its service and other parties, promotion-related discretion, reporting, payments, and rules around content and accounts.[2]
Those arrangements can provide real capabilities. A small publisher may not have the resources to build separate conversion, retail, reporting, payment, and fulfillment systems. But an arrangement that makes these services available also makes their conditions relevant. A finished file does not tell a reader who can correct a public description, what channel receives it, what record identifies a payment, whether a permission representation is current, or how an account contact is maintained.
The right question is therefore not “Is Avery independent?” That word is too large. The question is:
Which relationships must remain intelligible and operative for this finished title to become, and stay, public?
Capability is not control
The word self in self-publishing can create a misleading image: one person makes a file, so one person controls every important part of the book’s public life. But production capability and control over a publishing relation are different things.
| Term | Meaning in this paper | What it does not mean |
|---|---|---|
| Production capability | The ability to create and retain a source manuscript, cover, and publication-ready file. | Automatic public availability or reader reach. |
| Service dependency | A relationship with an outside service that conditions a needed publishing function. | Exploitation, failure, or lack of author agency. |
| Control | A specified ability to change, verify, export, authorize, or discontinue something under stated conditions. | Ownership of every relevant relation. |
| Intermediation | A service connecting participants, files, payments, information, or physical/digital delivery. | Gatekeeping in every case. |
| Continuity condition | A fact, record, permission, account path, or alternative relation relevant if a service/account/policy changes. | A guarantee that disruption will not occur. |
| Dependency surface | The set of outside services, rules, accounts, and channels through which a title must pass or remain legible. | One technical stack or one villain. |
The distinction is visible in the terms themselves. Draft2Digital says that a participant owns work files it creates, subject to rights granted in the agreement, while the participant grants a nonexclusive worldwide right and license to distribute works through selected sales channels.[1] The point is not to interpret that agreement for a particular person. It is simply to see that file possession and a distribution relationship can coexist. A creator may retain a file while relying on a stated account, license, retailer connection, reporting system, and payment process for one public route.
Kobo’s agreement gives a different, equally useful example. It authorizes the service to make works available within selected territories, to convert or reformat them for its e-reading service, and to use works and supplied metadata through its own services and stated third-party relationships.[2] It also assigns distinct responsibilities around the accuracy of works and metadata and the representations necessary to make the relevant rights grant.[2] Again, the lesson is not that this relation is inherently good or bad. It is that an author’s file does not contain the entire public machinery through which a reader encounters, purchases, reads, or receives a book.
A broader literature confirms why the difference matters. In an open-access repository record for a peer-reviewed study of UK trade-book publishing, Simone Schroff describes self-publishing authors as having limited information and bargaining power within structural relations that include distribution concentration.[3] The accessible abstract does not authorize claims about every country, income level, or author experience. It does, however, block an easy conclusion: removing one conventional publisher from a route does not automatically remove the structural conditions that shape a title’s commercial and public life.
Claire Parnell’s 2025 study of Amazon and Wattpad provides a second, more specific limit. The accessible description states that it uses interviews, walkthrough method, metadata analysis, and other methods to examine how these platforms set market conditions and use algorithmic sorting; it reports that the studied structures can reproduce racial, gender, and sexual inequities for authors of color and queer authors.[4] This is not a finding about all platforms or all self-publishers. It does show why visibility cannot be treated as a neutral outcome of uploading a valid file. A platform can do more than host a title. In a stated setting, it can structure the conditions through which content and users are sorted.
The point of dependency language is not to convert every shared service into oppression. A service may make possible a route that an individual publisher could not otherwise build. The point is to keep several questions distinct: Who holds the file? Who can administer the account? Who receives the payment report? What rights are represented? Which route makes the title requestable? Where does visibility depend on a rule or relationship?
The launch-day dependency board
Return to the fictional River Index. The book’s files are complete before the following board begins. Its author, title, services, reader, and all outcomes are invented. The board does not tell Avery which accounts to open, which provider to use, which rights decision to make, or how to spend money. It is a way to see what an upload slogan leaves out.
| Card | Publishing function | Controlled asset or permission | The dependency question | An observable failure signal |
|---|---|---|---|---|
| 1. Source and publication files | Maintain the canonical manuscript, cover, and delivery files. | Versioned source manuscript, cover, export file. | Where is the controlled local copy, and who can verify that it is the intended edition? | Only a remote service copy is known. |
| 2. Identity and public description | State which title/version/format a reader is encountering. | Title, contributor, format, edition, description, public record. | Which record carries the public facts, and who can update it? | The public listing conflicts with the controlled title record. |
| 3. Account access | Administer the title and receive notices. | Login, authorized administrator, contact route. | Who can access the account and receive a material notice? | Necessary account authority or contact information is unclear. |
| 4. Rights/permissions representation | Enable a chosen route to accept the title. | Rights statement and relevant permissions record. | What representation, license, or permission supports the route? | A work is supplied without a current record of the relevant rights basis. |
| 5. Listing/distribution | Make the title requestable through a named channel. | Accepted file and channel relationship. | Which service/recipient makes this version available to request? | A valid file exists but no public route can be stated. |
| 6. Transaction/payment | Receive, review, and reconcile payment information. | Payment destination, report, record of the relation. | Where is the report, and who reviews its stated status? | A payment or report condition is assumed rather than documented. |
| 7. Fulfillment/access | Connect a reader’s request to a relevant physical or digital copy. | Order, copy, or reading-access route. | How does the relevant format reach the reader after a request? | The route works in a particular case but cannot be described or verified. |
| 8. Audience/promotion | Connect prospective readers to a dependable title representation. | Reader communication and promotional access path. | Which route links a prospective reader to the correct public record? | Visibility depends on an unrecorded or opaque relationship. |
| 9. Local records/continuity | Keep the relation understandable over time. | File inventory, terms record, account record, correspondence, verification log. | What remains intelligible if an account, policy, contact, or service changes? | No one can say what was last verified or where relevant records are. |
The board contains no claim that every title needs every card in exactly this form. A print-only local sale, a library-mediated work, a retail e-book, and a direct institutional publication may organize their relations differently. The board’s purpose is to prevent a category error: confusing the completed file with every relationship that gives the file a public life.
The current terms cited earlier make several cards concrete. Draft2Digital’s terms describe a relation that can include metadata controls, channel access, reports, royalties, and a distribution license.[1] Kobo’s terms describe creator-supplied metadata, rights authorization, channel use, promotion rules, and reporting/payment conditions.[2] These examples are not tool recommendations. They simply demonstrate that the public chain includes more than conversion.
An account-change case shows why card 9 belongs beside the visible public cards. Amazon KDP’s current account-management documentation describes its account as connected to personal, tax, and financial information; it discusses title administration, reports, payments, merger processes, advertising assets, and closure.[5] In the document’s account-closure guidance, KDP states that a closed account becomes inaccessible and cannot be restored; it tells users who choose closure that access to reports and tax forms will be permanently lost and says that confirmed closure leads to book unpublishing while certain existing print orders and already purchased digital books can have separately described treatment.[5]
This paper offers no advice about account closure. The source is one provider’s current documentation. Its teaching value is narrower: the title, its local source file, account-held report, public listing, outstanding payment record, and a prior purchaser’s access do not necessarily have the same status or change path. A continuity question must be granular enough to tell them apart.
Six dependency surfaces
The board becomes more usable when its cards are organized into six surfaces. A surface is not a product category. It is a place where an outside rule, account, service, intermediary, or audience relation conditions a title’s public life.
1. Publication record
A public title needs a comprehensible identity and description. An author may hold the final wording locally, yet a reader encounters a version through a public record that has to identify the relevant edition/format and carry enough information to distinguish it from another object. Draft2Digital explicitly lists control over selected metadata elements among the tools it provides; Kobo describes the use of submitted metadata through its e-reading service.[1] [2]
WEXLEY-WP-042, Metadata Is Distribution, studies the detailed journey of a publication record through authoritative sources, transformations, recipients, and discovery displays. WEXLEY-WP-041 has a narrower question: which service relationship currently conditions the ability to correct or verify a title’s public representation? The answer might be local, shared, or external. The Audit does not trace all fields; it records who has standing to act when an issue arises.
A correct record also does not guarantee a reader’s attention. Parnell’s Amazon/Wattpad study matters here because it cautions against treating technical listing as equal visibility in the studied platforms and author populations.[4] A Toolchain Dependency Audit can register an audience/discovery condition. It cannot promise ranking, sales, fair treatment, or reader demand.
2. Account and authorization
Publishing accounts collect more than a password. They can serve as the route through which a publisher uploads a file, changes a description, receives notices, accesses a report, authorizes another person, or asks support to act. An account may be personally held, organizationally held, or ambiguously shared. Those differences are operational, not merely administrative.
KDP’s current guidance says that the service is connected to an Amazon account and does not recommend multiple people using the same login credentials. It describes different requirements for merging accounts and lists particular information that does not transfer in that process, including certain historic account information, tax profiles, sales reports, payment information, active ads, and enhanced-content projects.[5] The paper does not infer that another service uses the same rules. It uses this one account system to show why “we can always move it later” is not a sufficient continuity statement.
The relevant audit question is not “Who owns the platform?” It is: Who can take a stated administrative action, where is the contact path, and what record makes that authority intelligible? The answer may be a named account holder, a shared institutional process, a documented support channel, or “not yet verified.” The last answer is not a failure of character. It is a condition worth recording.
3. Rights and permissions representation
A publication route normally involves more than having written a text. A service may require the person submitting a work to represent that they possess rights to publish, distribute, and manage it. Draft2Digital’s terms state such a representation and describe a nonexclusive distribution license.[1] Kobo’s terms require participants to have the necessary rights and identify responsibilities around permissions and rights grants.[2]
These statements are not legal opinions. They do not answer who owns a particular work, whether a given use is allowed, whether a contract is enforceable, or what someone should do about a dispute. They are evidence of a more modest proposition: rights representation is one operational dependency after the file is ready. A title’s toolchain therefore needs an intelligible record of the rights/permissions basis relevant to a chosen route. The appropriate escalation for a real uncertainty is qualified professional help, not an inference from this paper’s table.
The distinction also separates WEXLEY-WP-041 from WEXLEY-WP-043, which will examine subscription-tool ownership, portability, cancellation, and exit rights as a consumer-policy problem. WEXLEY-WP-041 does not adjudicate rights in a tool. It asks whether the publishing route has a named rights representation and whether the relevant record is findable.
4. Transaction and payment
A title may be listed and still require a means of receiving and interpreting payment information. The question does not begin with a forecast of revenue. It begins with the simpler relationship: Which account receives the report? Which payment destination is on record? Who can identify an issue? What terms or notices govern a stated relationship?
Kobo’s terms state payment and reporting conditions for works sold through the service, attach conditions to account/payment information, and address circumstances such as chargebacks or suspected fraud within the agreement.[2] Draft2Digital’s terms similarly describe access to reports and royalties less commission.[1] These sources are not used to calculate a royalty, explain tax, interpret a contract, or advise a creator about a payment option. They show that payment reporting is not an afterthought to a finished file. It is a distinct publishing relation with its own record, terminology, and conditions.
The Toolchain Dependency Audit asks a modest question: What local evidence allows the publisher to identify the current payment/report relation without relying on memory? The answer could be a saved terms date, a report export, a record of the account administrator, or an “unverified” notation. The Audit cannot state what a creator should earn, whether a term is fair, or how a particular payment issue will resolve.
5. Fulfillment and reader access
A file becomes public to a reader through a route. That route may involve digital delivery, a reading application, a retailer, a library channel, a print order, a direct fulfillment arrangement, or another format-specific relationship. Draft2Digital’s terms reference retailer, subscription, library, print, and digital routes.[1] Kobo’s terms describe the e-reading service as involving several interfaces and state that it may exercise its rights through booksellers, retailers, distributors, affiliates, and contractors.[2]
This is a field-guide observation, not a universal description of every book route. Its importance is that a title’s accessibility has two components that should not be collapsed: a reader needs to identify the correct work and reach a usable copy through a specified path. A local file contributes to neither automatically. A platform can make a route available; it cannot be assumed to supply every reader, place, format, or accessibility need. A completed delivery is not proof that all readers can receive the work, and an unavailable route is not necessarily a failure by the author.
WEXLEY-WP-010 treats fulfillment as a risk location in a specific production/return path. WEXLEY-WP-041 treats it as one node in a wider post-file toolchain. It does not compare inventory models, track return exposure, or calculate print costs.
6. Audience and visibility
A public title also depends on attention and recognition. The service taxonomy in an Authors Guild chapter distinguishes functions such as editorial work, format conversion, design, identifiers, listing/distribution, promotion, royalty administration, and author-led marketing.[6] The chapter is not current market data and will not be used for its dated price/provider claims. Its enduring teaching value is its refusal to collapse all these functions into “publish.”
A listing is one condition of public visibility; it is not a complete audience relationship. Schroff’s study of UK trade books argues that self-publishing authors can have limited information and bargaining power within a structurally concentrated distribution environment.[3] Parnell’s study of Amazon and Wattpad indicates that platform market conditions and sorting can affect visibility and reproduce inequities in its named contexts.[4] Neither source proves that any particular author is unseen because of an algorithm, nor that every service is a gatekeeper. Together, they establish a question the toolchain must retain: Which route connects a prospective reader to a reliable title representation, and what is known or unknown about the conditions of that route?
That question differs from an advertising plan. The Audit has no column for “best tactic.” It records a public relation, its evidence, and its limit.
The Toolchain Dependency Audit
The Toolchain Dependency Audit is an original Wexley teaching instrument. It is intended for a publisher, editor, or student who wants to move from “I uploaded my book” to a legible map of the relations that keep a particular title public. It does not rank platforms, select a payment processor, evaluate a contract, guarantee a transfer, recommend an exit, establish legal rights, or declare a creator independent or dependent in the abstract.
| Audit field | The reader asks | A proportionate output | A warning sign |
|---|---|---|---|
| 1. Function | What work must happen for this title to remain public? | “Receive a payment report,” not “use a platform.” | Treating the tool name as the function. |
| 2. Controlled asset or permission | What file, record, right, account, or access is involved? | “Versioned EPUB,” “account-held sales report,” or “nonexclusive distribution license.” | Calling every title-related item “the book.” |
| 3. Current holder/administrator | Who can change, view, or authorize it under the current route? | A named person, organization, or shared relation. | Assuming file author equals administrator of every relation. |
| 4. Rule or condition | Which term, policy, process, or technical condition governs it? | A dated source/terms record or “unverified.” | Treating hearsay or a remembered workflow as evidence. |
| 5. Concentration/substitutability | Is this function confined to one route, or is another route identifiable? | “One named route; alternative unverified.” | Assuming an alternative is available, affordable, or equivalent. |
| 6. Data/record condition | What local evidence is retained, and when was it checked? | File inventory, saved terms date, exported report, correspondence log. | Treating online availability as a local record. |
| 7. Failure signal | What observable event would show a condition needs attention? | Mismatched listing, inaccessible account, missing report, rejected file, changed-term notice. | A vague fear of “being deplatformed.” |
| 8. Continuity question | What modest preparation makes the relationship more intelligible? | Document contact/administrator; retain relevant source file/record; schedule review. | Promising immunity from change. |
| 9. Escalation boundary | When does the issue become a rights, contract, tax, privacy, finance, or support matter? | “Needs appropriate qualified or service-specific review.” | Treating the Audit as professional advice. |
Apply two rows of the Audit to River Index. First, consider an account-held sales report. Its function is reporting, not “the platform.” The controlled asset is a report and related account access. The current administrator must be named. A dated terms/help record may describe the condition, while a saved report export can make the relation inspectable without promising that payment, data, or access will continue unchanged. A missing report or inaccessible account is a failure signal. The escalation boundary is clear: a payment, tax, contractual, or account matter must be handled through appropriate channels or qualified expertise.
Second, consider a reader-facing title listing. Its function is to make a specific version identifiable/requestable. The asset is a record plus the right/ability to change it under a stated route. A misleading title, edition, or access statement is a failure signal. The continuity question is not “How do we beat an algorithm?” It is “Who can verify the controlled public facts, and what route records a correction request?” WEXLEY-WP-042’s trace is the specialized tool for following metadata handoffs; WEXLEY-WP-041 records the dependency owner and the local evidence necessary to know where a request belongs.
The Audit’s strength is its modesty. It does not promise that every dependency has an easy substitute. It does not demand total self-sufficiency. It lets a reader say: “This title’s public description is administered here; this report is available through this account; this rights representation is documented here; this route is currently verified; this condition remains unknown; this issue requires another kind of review.” That is a more durable achievement than a blanket declaration of independence.
Intermediation is not the opposite of independence
A careful toolchain paper needs a counterweight. The evidence does not support the claim that all shared services are harmful. Draft2Digital’s current terms describe conversion, retailer/subscription/library routes, reports, and payment mechanisms that can be useful to publishers who cannot build them alone.[1] Kobo’s terms describe a service that can make works available across an e-reading route and additional named relationships.[2] The Authors Guild service taxonomy shows why publishing has long involved different bundles of editorial, production, distribution, promotion, and payment work.[6]
Intermediation can lower an operational burden, link a small publisher to readers, provide reporting, or help execute a task that would be difficult to perform alone. It may also introduce terms, account structures, sorting conditions, concentrated routes, or recordkeeping requirements that a creator should understand. These propositions are not contradictory.
The useful claim is therefore not “Self-publishing removes gatekeepers” or “Platforms replace publishers with a new form of dependence.” It is more exact:
| Claim version | Editorial judgment |
|---|---|
| “Once the book file is finished, the author controls publication.” | Too broad. It confuses production capability with all public relations. |
| “Self-publishing platforms are just new gatekeepers.” | Too broad. It turns varied, sometimes useful services into one moral category. |
| “A finished file broadens a creator’s production capability. It does not by itself provide control over the accounts, rules, records, payment routes, rights representations, discovery conditions, and audience relationships that make a title public.” | Proportionate. It preserves new capability while making dependencies visible. |
A self-publisher does not become less capable by recording dependencies. The record is part of capability. It enables a periodic question: What relation makes this title public now, what evidence shows its current condition, and what needs review before memory becomes the only infrastructure?
Boundary statement
This paper does not recommend a platform, retailer, distributor, advertising tactic, payment processor, identifier, service bundle, account arrangement, or exit plan. It does not offer legal, tax, financial, contract, rights, estate, privacy, account-closure, or data-portability advice. It does not predict sales, royalties, ranking, suspension, removal, reader access, or platform conduct. It does not claim that all platforms share the terms or effects of Draft2Digital, Kobo, or KDP, or that every author experiences the structural/equity conditions examined in the UK, Amazon, or Wattpad research. Its contribution is a bounded action practice: map the function, name the asset and holder, retain evidence of the governing condition, identify a failure signal, and record the appropriate boundary for further review.
References
[1]: Draft2Digital, “Terms of Service” (effective 14 April 2026).
[2]: Kobo Writing Life, “Terms of Service.”
[3]: Schroff, Simone. “Missing the Point—the Disappointed Hope of Self-Publishing Authors.” International Journal of Cultural Policy 30, no. 7 (2024): 960–977. University of Plymouth repository record.
[4]: Parnell, Claire. Inequalities of Platform Publishing (2025).
[5]: Amazon Kindle Direct Publishing, “Manage Your KDP Account.”
[6]: Authors Guild. “Self-Publishing Options: Ebooks and Print on Demand.” In The Writer’s Legal Guide, chapter 13 (publicly posted 2022).