Skip to content

The big picture

Packt is rebuilding publishing around one idea: content should be liquid. A manuscript that arrives once should be able to flow into an ebook, an audiobook, a course, a newsletter, a set of short videos, or an answer given by an AI assistant — without anyone re-keying it, and without ever losing track of who wrote it or what may be done with it. The old way, where each format is a separate project starting from a fresh copy of the text, loses that thread almost immediately: the same book exists in a dozen slightly different files, attribution drifts, and nobody can say with confidence whether a given use is contractually allowed.

The rebuild fixes that by holding content once, in a single shared store, and treating three things as first-class from the moment content arrives: attribution — every piece traces back to its author, so authors keep a reason to publish; contractual alignment — the Contract that governs content is attached up front, so anyone reusing it can be sure how they are allowed to; and provenance — every transformation is recorded, so "what did AI touch?" and "who is owed?" are answerable questions rather than investigations.

None of this is one big programme. The platform is a set of cooperating services arranged around a single content estate. Each service does one job well — ingesting content, holding rights, composing products, shipping to partners — and they coordinate mostly by reacting to events rather than calling each other directly. When a contract changes, the services that care about rights notice and update themselves; nobody has to remember to phone everyone. The content estate in the middle — the Content Lake — is the shared ground everything else stands on.

This page is the guided tour: what the platform is, the service map, and a walk through the life of a single manuscript from arrival to shelf. It assumes only the handful of terms on the Core concepts page; anything unfamiliar links to the Glossary.

The service map

The clearest way to picture the platform is as a series of layers around the estate. Content flows in through ingestion, settles in the lake where it is enriched, is composed into products, and flows out to channels. Two concerns cut across every layer rather than sitting in the flow: Contracts & Rights, which govern what may be done at each step, and Authentication, which decides who is asking and on whose behalf.

flowchart LR
    subgraph flow [The content estate]
        direction LR
        I["Ingestion<br/>Sources in"] --> L["Content Lake<br/>content · rights · provenance"]
        L --> E["Enrichment<br/>Knowledge Graph"]
        E --> P["Products<br/>editions · formats"]
        P --> D["Distribution<br/>& Channels"]
    end
    C["Contracts &amp; Rights"] -.->|govern every step| flow
    A["Authentication"] -.->|who is asking| flow

Reading it left to right: Sources such as SharePoint, Google Drive, or a plain upload feed Ingestion, which registers what arrives as Resources in the Content Lake. There the content is enriched — linked to the shared Knowledge Graph so it gains context — and later composed into Products: the editions, formats, and bundles that are actually sold. Finished products flow out through Distribution to the Channels that take them to customers.

Contracts & Rights and Authentication are drawn as cross-cutting because they apply everywhere at once. Rights are not a gate you pass once at the start; they are checked at ingestion, carried with every read, and re-checked at the point a product is published or shipped. Authentication is the same: every request, from a person or another service, arrives with a token that says who is asking and which Tenant they belong to.

Why the services react rather than poll

The platform is event-driven: services announce that something happened — a Resource was created, a contract changed — and other services react. Producers do not need to know who is listening, so a new capability can be added without touching the services it depends on, and a slow or failed step never blocks the ones upstream. This is why a contract change quietly ripples out to rights across the estate instead of requiring a coordinated update.

The Explorer

If you would rather see the platform than read about it, the Explorer is a guided, interactive tour of the whole thing in ten short chapters — from a manuscript arriving to a product reaching the shelves.

Take the visual tour

The Explorer walks the same journey this page describes, one chapter at a time, with the entities and flows drawn live. It is the fastest way to build a mental model before diving into any single area. Chapter I opens on the service map below.

Open the Explorer

A day in the life of a manuscript

The layers make more sense once you follow one thing through them. Here is a manuscript's journey, end to end. Nothing here is hypothetical plumbing — each arrow is a real step the platform takes.

flowchart LR
    M["Manuscript<br/>arrives"] --> ING["Ingested<br/>as Resources"]
    ING --> W["Held in a Work<br/>under a Contract"]
    W --> EN["Enriched<br/>linked to the Knowledge Graph"]
    EN --> PR["Composed<br/>into a Product"]
    PR --> CH["Shipped<br/>to a Channel"]

  1. A manuscript arrives. An author or editor sends a file — a Word document, a Google Doc, a folder in SharePoint. It may land first in staging: a holding area where content is owner-only and not yet usable, so work can begin before the paperwork is settled.

  2. It is ingested. Ingestion reads the file and registers it in the Content Lake as one or more Resources — typically one per chapter — stored as structured content rather than an opaque document.

  3. It is held in a Work under a Contract. The Resources are attached to a Work, the intellectual-property anchor, and the Work is governed by a Contract. This is the moment content becomes properly usable: rights are resolved on the Work and projected onto every Resource, so every later read already knows what may be done — which territories, which formats, whether AI may retrieve it.

  4. It is enriched. The content is linked to the shared Knowledge Graph, so mentions of a technology, tool, or person connect to a live, shared record. The content gains context — currency, credibility, relationships — without that context being copied into the text.

  5. It is composed into a Product. One or more Manifestations — the ebook, the paperback, the audiobook — are assembled from the Work's Resources and offered as a sellable Product. The composition declares what the product is made of and, for rendered formats, what they are generated from.

  6. It is shipped to a Channel. The product is placed in a Catalogue and offered to a Channel — a partner that takes it to customers. Before anything is sent, the product's resolved rights are matched against what the channel needs. The channel boundary is the final rights gate.

Rights travel the whole way

The single thread running through all six steps is the Contract. Because rights are resolved on the Work and carried with the content everywhere it goes, a term set once — say, ebooks permitted, audiobooks prohibited — automatically constrains what can be composed and shipped, without anyone re-checking it by hand at each stage. Enforcement is the platform's job, not each app's. See Core concepts.

A short tour of the platform

The rest of this site is organised by area. Here is what each one covers and where to start.

  • Content Lake — the content estate itself: how content is ingested, stored as structured blocks, versioned, enriched with the Knowledge Graph, and searched. This is the foundation the other areas build on.

  • Contracts & Rights — the system of record for what may be done with content: territories, formats, the sixteen usage types (including a family of purpose-specific AI verbs), and the commercial terms behind royalties. Rights resolve here and flow everywhere else.

  • Products — how a Work becomes sellable things: editions and formats, the Work → Expression → Manifestation → Product ladder, composition, catalogues, and product search.

  • Distribution & Channels — how finished products reach partners: the registry of channels and how each uses content, and the rights matchmaking that approves every item for every channel before it ships.

  • Build on the platform — for integrators and no-code or AI tools: the Public API, authentication, events and webhooks, and recipes for automating against the platform.

In design

Distribution and parts of Channels, along with royalty accrual and settlement, are still in design. Those pages carry their own status notes; treat them as the intended shape rather than shipped behaviour.