Products

A Product is the thing a customer actually buys. Everything else on the platform is about owning and governing content; a Product is where that content is finally offered for sale — priced, packaged, put in a catalogue, and shipped to a channel. It is the commercial wrapper that sits on top of the platform's content model, and it is the last rung of a four-part ladder that begins with the intellectual property itself.

The ladder is the single most important idea to carry into this section: one Work (the IP, where rights live) is realised as one or more Expressions (a medium and language — the English text, its audio narration, a French translation), each embodied as one or more Manifestations (the sellable SKUs, each with its own ISBN — the paperback, the ebook, the audiobook download), which are in turn offered as Products. Keeping "what we own" separate from "what we sell" is what lets one manuscript flow into dozens of products without re-keying content or losing track of who is owed what.

The Product Management service is the catalogue and lifecycle engine that owns this. It manages product metadata, pricing, composition, format generation, and search — and it is the second-largest service on the platform after the Content Lake itself. This overview walks the ladder, explains how a product's files come to exist (the RENDERED-versus-ARTIFACT distinction), and follows a product through its six lifecycle states. The sub-pages go deeper on types, composition, catalogues, and search.

Why this exists — from rigid products to granular ones

Historically a published product was a rigid, high-effort thing that took months or years to produce. Publishers are used to print books and audiobooks with multiple rounds of review, each format a separate project starting from a fresh copy of the text. That model still matters — flagship titles are still manually curated and distributed through storefronts like Amazon, Barnes & Noble, or Waterstones — but it is no longer the only shape a product can take.

Because content now lives once in the Content Lake as structured, addressable blocks, the unit of a product no longer has to be the whole book. It can be a chapter, a section, an image, or a code block. A product's files need not be pre-built and stored; they can be generated fresh from the lake on every request. Taken to its limit, each AI query could be its own product request — assembling a unique response from different pieces of Content Lake content, each with its own price and royalty flowing back to the authors whose work it drew on. If automated agents transact in milliseconds, the platform may create far more products by volume than any human catalogue ever held.

The model on this page is built for both ends of that spectrum at once. A hand-curated print book and a machine-composed answer are the same underlying construction — a Product wrapping Manifestations of Expressions of a Work — differing only in how their files are sourced and how much of the process a human touches.

The Work → Expression → Manifestation → Product ladder

Products sit at the top of the platform's four-tier entity model. Identity rolls up from the sellable file to the IP; a Product wraps the SKUs, and rights live at the bottom, on the Work.

• A Work is the intellectual property — the book as an idea, together with the Contract and rights that govern it. Hands-On Machine Learning with Go is one Work (wk_ml_go). Contracts attach here and nowhere else.
• An Expression realises the Work in a medium and language: the English text edition, its audiobook narration, a French translation. Same Work, different realisations (expr_ml_go_en_text).
• A Manifestation embodies one Expression as a sellable SKU — a class, optionally a form, plus configuration. The paperback, the ebook, and the audiobook download are three Manifestations (man_ml_go_ebook_epub), each carrying its own ISBN. The classes and forms — PRINT (PAPERBACK/HARDBACK), EBOOK, AUDIOBOOK (DOWNLOAD/STREAM), VIDEO, ONLINE, SCORM_PACKAGE — are the contract grant vocabulary.
• A Product is the sellable thing one or more Manifestations are offered as, classified by a product type (Book, Audiobook, Course, and so on — see Product types) (prod_ml_go_book).

flowchart TD
    W["Work<br/>Hands-On Machine Learning with Go<br/>(rights live here)"]
    W -->|realised as| E1["Expression<br/>English text"]
    W -->|realised as| E2["Expression<br/>English audio"]
    E1 -->|embodied as| MP["Manifestation<br/>PRINT · PAPERBACK"]
    E1 -->|embodied as| MB["Manifestation<br/>EBOOK"]
    E2 -->|embodied as| MA["Manifestation<br/>AUDIOBOOK · DOWNLOAD"]
    MP -->|offered as| PB["Product · Book"]
    MB -->|offered as| PB
    MA -->|offered as| PA["Product · Audiobook"]

The Content Lake stores the Works and records Expressions and Manifestations as graph nodes; the Product Management service owns the Expression and Manifestation entities and the Products built on them. The ladder is introduced first for the whole platform on Core concepts — this page is the same ladder in commercial terms.

Format sourcing — rendered fresh, or a file we already have

A Manifestation is realised as files by its formats, and every format declares a source: how its file comes to exist. This is the axis that replaces the old "legacy versus Content-Lake-backed" split — and, crucially, it is decided per format, not per product.

There are two sources:

• A RENDERED format has no stored file. The product holds a composition — an ordered tree of references to Content Lake resources — and the output is generated fresh from the lake on every request: content streamed from the Content Lake, product assets (covers, imprint) injected, the table of contents and index generated on the fly, and the target format rendered — all in one streaming pipeline with no intermediate storage.
• An ARTIFACT format is a file we already have — a pre-existing distributable such as an ePub, a SCORM package, or an MP4. It is uploaded and stored as a product asset (ast_ml_go_epub). The binary is treated as opaque — it is never decomposed into Content Lake resources — but a structural descriptor is extracted at upload so consumers can see what is inside without unpacking it.

Because sourcing is per format, a single Manifestation can mix the two: a PRINT manifestation might pair a RENDERED InDesign file with a print-ready PDF supplied by an external typesetter as an uploaded ARTIFACT. From the mix of a product's format sources the platform derives a single search attribute, product_model:

• artifact — every format is an uploaded file (what earlier drafts called a "legacy" product).
• rendered — every format is generated fresh from the lake (fully Content Lake-backed).
• mixed — some of each. A product legitimately sits here mid-migration, when its ebook has gone rendered while its print manifestation stays artifact-backed.

The product lifecycle — six states

Every product moves through a defined lifecycle. There are six states: a linear path from DRAFT to PUBLISHED, plus two terminal exits. Every transition is a verb, and every transition emits a lifecycle event on the platform-products bus, so downstream systems react without polling.

stateDiagram-v2
    [*] --> DRAFT: drafted
    DRAFT --> REVIEW: submitted
    REVIEW --> APPROVED: approved
    APPROVED --> PUBLISHED: published
    PUBLISHED --> RETIRED: retired
    DRAFT --> WITHDRAWN: withdrawn
    REVIEW --> WITHDRAWN: withdrawn
    APPROVED --> WITHDRAWN: withdrawn
    PUBLISHED --> WITHDRAWN: withdrawn
    RETIRED --> [*]
    WITHDRAWN --> [*]

RETIRED and WITHDRAWN are both terminal. The difference is intent: RETIRED is an orderly wind-down from PUBLISHED (the old edition after its successor launches), while WITHDRAWN is the emergency exit — available from any active state, and used when a product must cease to exist as an offering. A withdrawn title that later returns comes back as a new product, with the old product's change history intact as the audit record.

Three rules that keep the model honest

• Contracts never speak product-type vocabulary. Grants name manifestation classes and forms, scoped by territory, language, and medium. Building a course from a book creates a new Work — with its own rights basis — so it is a DERIVE-family rights question, not a product setting.
• Product configuration is not identity. Trim size, binding style, ebook file format, and DRM live in the format configuration, below the class and form — not as classes of their own.
• Rights are read, never enforced, here. The Product Management service surfaces the resolved manifestation rights on a Work so downstream consumers can decide; Distribution applies the policy.

{
  "id": "prod_ml_go_book",
  "type": "Book",
  "title": "Hands-On Machine Learning with Go",
  "language": "en",
  "product_model": "mixed",
  "manifestations": [
    {
      "id": "man_ml_go_ebook_epub",
      "class": "EBOOK",
      "isbn": "978-1-80000-001-0",
      "formats": [
        { "format": "ePub", "source": "RENDERED" }
      ]
    },
    {
      "id": "man_ml_go_print_pb",
      "class": "PRINT",
      "form": "PAPERBACK",
      "isbn": "978-1-80000-003-4",
      "formats": [
        { "format": "InDesign", "source": "RENDERED" },
        { "format": "Print PDF", "source": "ARTIFACT",
          "asset_id": "ast_ml_go_print_pdf" }
      ]
    },
    {
      "id": "man_ml_go_online",
      "class": "ONLINE",
      "formats": []
    }
  ]
}

Where to go next

• Product types — the eight product types (Book, Video Course, Audiobook, Interactive, Course, Certification, Article, Newsletter) and which format sources each supports.
• Composition — the ordered tree that declares what a product is made of, and version pinning against the Content Lake.
• Catalogues — curated, per-destination subsets of the product set, with manual picks and continuously-evaluated rules.
• Search — hybrid product search and the exposed embeddings that let each storefront overlay its own taxonomy.

Related pages

• Core concepts — the ladder and vocabulary the whole platform assumes.
• Contracts & Rights — where the rights that bound every product are held and resolved.
• Content Lake — the content estate that rendered formats are generated from.
• Distribution & Channels — how published products reach partners and where rights are finally enforced.
• Explorer — Chapter VII — the Work → Expression → Manifestation → Product ladder, visualised.