Skip to content

Distribution & Channels

Once a Work has been composed into Products and gathered into a Catalogue, something has to actually send those products to the places customers buy them — Amazon, a subscription platform, a Shopify storefront, packtpub.com itself. Distribution is that step: it takes what a catalogue says should be on sale in a given context and syncs it out to the partner that serves that context. Catalogues decide what; Distribution ships it.

The partners on the receiving end are Channels. A channel is not just a name on a list — each one carries a usage profile that declares how it uses content: which manifestation classes it handles (print, ebook, hosted access), which territories it serves, and its access model (outright sale, subscription, lending). Two outlets that look alike to a person are different channels to the platform when their usage differs — Amazon US and Amazon DE are separate partners, because the rights question is answered separately for each.

That separation is the whole point of this part of the platform. Catalogues define what to distribute, Distribution ships it, and Channels define who may receive what — and the channel boundary is the final rights gate. Before any item leaves the platform, Distribution matches it against the receiving channel's usage profile: does this content hold the rights to be used by this channel, in the way this channel will use it? The consequence is the headline guarantee: a catalogue mistake cannot leak content. Even if someone adds a title to a catalogue that Packt has no right to distribute to a particular partner, the match notices the missing right and that title is never sent to that channel.

In design

Distribution and parts of Channels are still in design. This page describes the committed architecture — the boundaries, the catalogue-to-channel flow, and the rights match that gates every item — not shipped behaviour. Event names, connector mechanics, partner lifecycle, and a dedicated channels bus are not yet finalised; open questions are flagged inline and on the Channels page.

Three responsibilities, three services

Getting a product to a customer touches three services, and the platform keeps them deliberately separate so that no single mistake can override the rights model.

Concern Owner What it answers
What is on sale in a context Product Management (catalogues) Which products belong in this destination's set
Ships it to the partner Distribution Deliver listings and artifacts; keep the partner in sync
Who may receive what Channels Which partner, handling content in which way, in which territory

A Catalogue is a curated subset of products for one destination — packtpub.com has one, the Amazon Kindle store has one, a Shopify storefront has one. Catalogues are a Product Management concern; they define the set. Distribution consumes catalogue membership changes and does the shipping. Channels hold the usage profiles Distribution matches against. The rights terms behind those profiles trace all the way back to the Contract on each product's Work.

flowchart LR
    CAT["Catalogue<br/>(Product Management)<br/>defines the set"] --> DIST["Distribution<br/>ships + matches rights"]
    CHAN["Channels<br/>usage profiles"] -.->|profile to match against| DIST
    DIST -->|passes the match| OUT["Channel partner<br/>Amazon · O'Reilly · Shopify"]
    DIST -->|fails the match| BLOCK["Blocked<br/>never sent"]

The channel boundary is the final rights gate

Rights are enforced in layers across the platform, and Distribution is the last of them. Contracts hold the terms; the Content Lake projects resolved rights onto every Resource; search filters what a caller may retrieve. The channel boundary is the point where content actually leaves the platform — so it is the point where the final check happens.

When Distribution ships catalogue content to a channel, it matches every item against that channel's usage profile. The match combines two things: the channel's declared usage — its manifestation classes, territories, and access model — and the content's resolved rights, which the Content Lake holds on each product's Work and which trace back to that Work's contracts.

The access model a channel declares maps directly onto the contract usage type vocabulary — the same vocabulary the matchmaker evaluates. There is deliberately no SELL usage type: a retail sale is expressed as DISTRIBUTE with a commercial purpose, so one clause has one encoding.

Channel access model Usage the match checks
Sale of copies (Amazon US/DE, bundles) DISTRIBUTE (commercial purpose)
Subscription / hosted access (O'Reilly) MAKE_AVAILABLE
Library lending LEND
Print-on-demand manufacture MANUFACTURE (+ DISTRIBUTE)
Preview / excerpt display DISPLAY
AI retrieval / training partners AI_RETRIEVAL / AI_TRAINING

The block is per channel, per usage. A title with no German print rights is blocked for Amazon DE while still shipping to Amazon US — the same title, two different answers, because the two channels declare different territories and the rights are resolved for each. This is why a catalogue mistake cannot become a rights leak: catalogue membership is a proposal to distribute, and the channel match is the decision.

Product Management surfaces rights; Distribution enforces them

The Product Management service reads contract information and surfaces it alongside product data, but it never enforces rights — it deliberately allows a catalogue to reference rights (a rule can include products that carry a given permission) without being the thing that blocks a shipment. Enforcement is Distribution's job, at the channel boundary. Keeping the two apart means a mislabelled catalogue rule can never, by itself, send content somewhere it may not go.

When rights change, the shelves follow

The final gate is not only checked when a product first enters a catalogue — it re-runs whenever the answer might have changed. The clearest case is a contract expiring or being amended. Because the platform is event-driven, that change ripples out on its own: nobody has to remember to pull the affected titles from every partner.

The chain starts in Contracts and ends at the channel. A contract event triggers the Content Lake to re-resolve the affected Work's rights and re-project them onto its Resources; that reprojection publishes a Work-level rights-changed signal; catalogue membership is re-evaluated against the new rights; and Distribution re-runs the channel match, pulling anything that no longer passes.

sequenceDiagram
    autonumber
    participant C as Contracts
    participant L as Content Lake
    participant P as Product Mgmt<br/>(catalogues)
    participant D as Distribution
    participant CH as Channel partner
    C->>L: contract expires / amended
    Note over L: re-resolve the Work's rights,<br/>re-project onto its Resources
    L->>P: Work rights changed
    Note over P: re-evaluate catalogue<br/>membership against new rights
    P->>D: catalogue membership changed
    Note over D: re-run the channel match<br/>(per channel, per usage)
    D->>CH: pull / update listing

This is the same "ripple" the Explorer walks through in its final chapter. The events that carry it are the platform's platform signals: contract changes on the platform-contracts bus, the Content Lake's platform.content-lake.work.v1.rights_changed, and catalogue membership events on the platform-products bus. Because each consumer re-reads the source of truth when it reacts, a burst of changes collapses to the latest state — the shelves converge on what the current contracts allow, not on whatever order the events arrived in.

The single thread is still the Contract

Rights are held once on the Work, cached per Resource, and revalidated at the point of use. The channel boundary is a point of use — the last one, where content leaves the platform. So a term set once in a contract (say, no German print rights) constrains what ships to which partner without anyone re-checking it by hand. Enforcement is the platform's job, not each storefront's.

Contract expiry ripple — the events involved (JSON)

The three platform events that carry a contract expiry through to the channel. Payloads are thin — identifiers and change families only; consumers fetch the resolved terms from the source of truth.

// 1. Contracts → platform-contracts bus
{
  "detail-type": "platform.contract.v1.state_changed",
  "detail": {
    "contract_id": "ctr_chandra_2026",
    "from_status": "ACTIVE",
    "to_status": "EXPIRED",
    "direction": "INBOUND",
    "work_ids": ["wk_ml_go"],
    "tenant_id": "packt"
  }
}

// 2. Content Lake → platform-content-lake bus (after reprojection)
{
  "detail-type": "platform.content-lake.work.v1.rights_changed",
  "detail": {
    "work_id": "wk_ml_go",
    "contract_id": "ctr_chandra_2026",
    "change_types": ["TERRITORIAL"],
    "tenant_id": "packt"
  }
}

// 3. Product Management → platform-products bus (catalogue re-evaluated)
{
  "detail-type": "platform.products.catalogue.v1.product_removed",
  "detail": {
    "catalogue_id": "cat_amazon_de",
    "product_id": "prod_ml_go",
    "tenant_id": "packt"
  }
}

Distribution consumes the membership event and re-runs the channel match; a product removed from the Amazon DE catalogue is pulled from that channel while the same title keeps shipping to Amazon US.

Channel-specific presentation ships too

Distribution does not ship the bare product record. Catalogue entries can override any product attribute — title, description, cover, price — per catalogue, so the same product is presented differently in different contexts without touching the base record. Distribution reads the catalogue entry (overrides applied), so a German storefront's localised title or a promotion's "$title — Now 70% Off" template ships exactly as the catalogue owner set it. The set of products comes from the catalogue's membership; the shape of each listing comes from its overrides.

Where to go next

  • Channels — the registry of channel partners, the usage profile in detail, and the full access-model-to-usage-type mapping the match evaluates.
  • Channel directory — the concrete list of the partners Packt distributes to today, grouped by the kind of partner.
  • Catalogues — how the product set for each destination is defined, by manual picks and continuously evaluated rules.
  • Contracts & Rights — the source of the terms the channel match ultimately checks against.
  • Channels — the partners on the receiving end and how each declares its use of content.
  • Catalogues — the product set Distribution ships to each channel.
  • Contracts & Rights — where the rights the channel match enforces are held.
  • Content Lake — where resolved rights are projected onto every Resource.
  • Explorer — Chapter X — distribution, channels, and the rights ripple, visualised.