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.
Related pages
- 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.