Channels

A channel is a partner that takes Packt products to customers: a retailer such as Amazon, a subscription platform such as O'Reilly Learning, a library-lending service, a print-on-demand supplier, or Packt's own storefront. Every finished Product reaches a reader through a channel, and the Channel service is the registry that describes those partners so the platform can decide, item by item, what may be sent to each of them.

The idea that makes channels more than a list of names is that each channel is stored with a usage profile — a declaration of how that partner uses content. A profile names the manifestation classes the channel handles (print, ebook, online, and so on), the territories it serves, and its access model — whether it sells copies outright, hosts subscription access, lends time-limited copies, and the like. Two outlets that look like one shop to a person are different channels to the platform whenever their usage differs.

That profile is the whole point. When Distribution ships catalogue content to a channel, it matches every item's resolved rights — which trace back to the governing Contract on the item's Work — against the receiving channel's usage profile. The channel boundary is the last rights gate on the platform: the point where content leaves it. A catalogue mistake therefore cannot leak content, because the match, not the catalogue, decides what ships.

This page explains what a channel is, why Amazon US and Amazon DE are two channels rather than one, and how each access model maps onto the platform's usage vocabulary — the mapping the matchmaker actually evaluates. It closes with the design questions still open.

What a channel is

A channel has two halves. One is the partner — the commercial counterparty and the connection to it. The other is the usage profile — a machine-readable declaration of how that partner uses content, which is what lets the platform reason about it. The profile carries three things:

• Manifestation classes — which sellable embodiments the channel handles: PRINT, EBOOK, AUDIOBOOK, VIDEO, ONLINE, SCORM_PACKAGE. These are the same classes contracts grant, so a channel's declared classes and a Work's granted classes are directly comparable.

• Territories — where the channel serves customers, expressed as ISO 3166-1 codes and named territory sets (EU, NORTH_AMERICA, and the rest).

• Access model — how the channel puts content in front of customers: outright sale of copies, hosted subscription access, library lending, print-on-demand manufacture, preview display, or an AI partnership. The access model is the half that maps onto the contract usage vocabulary, and the rest of this page is about that mapping.

flowchart LR
    P["Channel partner<br/>(e.g. Amazon US)"] --> PROF["Usage profile"]
    PROF --> C["Classes<br/>PRINT · EBOOK"]
    PROF --> T["Territories<br/>US"]
    PROF --> AM["Access model<br/>sale of copies"]
    AM --> U["Usage the matchmaker checks<br/>DISTRIBUTE · COMMERCIAL"]

Why Amazon US and Amazon DE are different channels

Because the rights question is answered separately for each. Amazon US serves the United States; Amazon DE serves Germany. A title may hold print rights in the United States but not in Germany, so the honest answer to "may this ship?" is different for the two — and the only way to get two answers is to model two channels, each with its own territory in its usage profile.

Modelling them as one "Amazon" with a territory setting would collapse that distinction and invite exactly the leak the channel boundary exists to prevent: a title with no German print rights blocked for Amazon DE while still shipping to Amazon US is only expressible when the two are separate channels the matchmaker evaluates independently.

flowchart TD
    W["Work<br/>resolved rights:<br/>PRINT permitted in US, not DE"]
    W --> MUS{"Match:<br/>Amazon US<br/>PRINT · US"}
    W --> MDE{"Match:<br/>Amazon DE<br/>PRINT · DE"}
    MUS -->|US print right present| SHIP["Ships to Amazon US"]
    MDE -->|no DE print right| BLOCK["Blocked for Amazon DE"]

Access models and the usage vocabulary

A channel's access model maps directly onto the contract usage_type vocabulary — the sixteen verbs the rights model defines (Contract model — Usage terms). This is the vocabulary the matchmaker evaluates: for each item it asks whether the item's resolved rights permit the usage the channel's access model implies, for the channel's territories and classes.

A few of these repay a closer look, because the encoding is deliberate and easy to get wrong.

There is no SELL usage type. Retail sale is the idiomatic DISTRIBUTE with purpose: COMMERCIAL — copies pass onward to a buyer who then holds them, and the commercial purpose distinguishes a sale from, say, a permitted educational hand-out. One clause, one encoding: pricing and settlement live in the contract's royalty terms, not in a separate usage verb.

Subscription is MAKE_AVAILABLE, not sale. A subscription platform hosts the content and makes it available to its own users without transferring copies onward. That is a different right from selling a copy, so it is a different verb, qualified with a method (VIEW_ONLINE, STREAM, or DOWNLOAD for offline reading). It is also distinct from ACCESS, which is what the end consumer does once content has been made available to them.

Print-on-demand is two rights. Manufacturing physical copies is MANUFACTURE; it is distinct from an end consumer printing pages (PRINT) and from reproduction in general (COPY). Because a print-on-demand partner both makes copies and puts them in customers' hands, the profile checks MANUFACTURE for the production and DISTRIBUTE for the fulfilment of those copies.

AI partners are first-class — and there is more than one kind. The rights model gives each AI action its own verb, so the matchmaker asks a different question depending on what the partner actually does. A partner whose assistant answers end users from the content checks AI_RETRIEVAL; a partner that has licensed the content for its own model checks AI_DISTRIBUTION (the third-party-onward verb, like DISTRIBUTE for copies); a partner training on the content checks AI_TRAINING. Because these are separate rights, a contract can permit one while prohibiting the others — retrieval yes, training no — and the matchmaker honours the difference per channel. The full AI verb set covers grounding, summarisation, and writing-assistance too, for the first-party AI surfaces the platform itself runs.

How an AI channel settles follows its access model, not a special pricing rule. A served AI surface settles from a consumption pool, so its royalty events are subscription attributions; a partner that has licensed or trained on the content settles as a fee or revenue share, a retail-style event. Packt's own AI features are PLATFORM channels this same matchmaker gates, so a first-party assistant is checked against resolved rights exactly as an external partner is. See AI & your content.

{
  "id": "chan_amazon_de",
  "partner": "Amazon Germany",
  "usage_profile": {
    "manifestation_classes": ["PRINT", "EBOOK"],
    "territory_codes": ["DE"],
    "access_model": "RETAIL_SALE",
    "checks": [
      { "usage_type": "DISTRIBUTE", "purpose": "COMMERCIAL" }
    ]
  }
}

{
  "id": "chan_oreilly_learning",
  "partner": "O'Reilly Learning",
  "usage_profile": {
    "manifestation_classes": ["ONLINE"],
    "territory_codes": [],
    "access_model": "SUBSCRIPTION",
    "checks": [
      { "usage_type": "MAKE_AVAILABLE", "method": "VIEW_ONLINE" }
    ]
  }
}

How it fits with the rest of the platform

Channels does not ship anything itself; it describes the partners so other services can. The division of labour is:

• Channels (this service) — the registry of channel partners and their usage profiles.
• Distribution — consumes catalogue-membership signals, reads channel profiles, runs the rights match, and syncs listings to the channels that pass.
• Contracts — the source of the terms. The channel-partner usages the matchmaker evaluates — DISTRIBUTE, MAKE_AVAILABLE, MANUFACTURE, LEND — are defined once in the contract model.
• Products — owns catalogues; catalogue entries carry the channel-specific presentation that Distribution ships.

Open questions

The design is deliberately unfinished. These are the open decisions recorded on the concept, not omissions to be filled in silently:

• Vocabulary. "Usage profile", "usage declarations" and "channel handling data" have all been used for the same thing; one name needs to win.
• Service boundary. Whether Channels is a standalone service (svc-channels) or a registry owned by Distribution is undecided. This page assumes standalone.
• Partner lifecycle. Onboarding, connector credentials, suspension, and offboarding of partners are unspecified.
• Events. Whether the service publishes its own bus and, if so, what its event types are, is not yet decided.
• IDs and scopes. No ID prefix or access scopes are registered for channels yet; the chan_ prefix used in examples here is provisional.

Related pages

• Channel directory — the concrete list of partners Packt ships to today, grouped by the kind of partner.
• Distribution — the service that runs the rights match and ships to the channels that pass.
• Contract model — Usage terms — the sixteen usage types and the channel-partner usages the matchmaker checks.
• Products — Catalogues — where the channel-specific presentation that Distribution ships is held.
• Works & rights — how resolved rights are held on the Work and cached per Resource.
• Explorer — Chapter 10 — distribution and channels, visualised.