Product types

A product type answers one question: what kind of thing is being sold? A book is not a course, a course is not a certification, and the platform needs to know which it is dealing with so it can offer the right formats, apply the right lifecycle, and present the right options to editors and storefronts. There are exactly eight types — Book, Video Course, Audiobook, Interactive, Course, Certification, Article, and Newsletter — and this page explains what each one is and what it can carry.

The type is a different axis from how the product is embodied. A single Work can become several products of different types (a book, its audiobook, a course built from its chapters), and each product offers its content as one or more Manifestations — the sellable SKUs with their own ISBNs. The type says what is being sold; the manifestation class (PRINT, EBOOK, AUDIOBOOK, and so on) says how it is delivered. Keeping the two apart is deliberate, and the section on types versus manifestation classes below explains why it matters.

The other thing a type governs is format sourcing. Every file a product produces is either rendered — assembled on the fly from the product's composition of Content Lake resources — or an artifact: a pre-existing file that was uploaded whole. Some types support both, some only accept uploads, and two have no file formats at all. The table below is the quick reference; the rest of the page takes each type in turn.

The eight types at a glance

The two middle columns are format sources, not separate products. Rendered formats are generated on demand from the product's composition; artifact formats are uploaded distributables stored by the platform. See Format sourcing for how the two work, and Composition for what a rendered format is assembled from.

• Book and Course support both sources. Their files can be rendered from Content Lake content or uploaded as finished artifacts, and a single product may mix the two.
• Video Course and Audiobook are artifact-only. Their distributables (an MP4, an M4B) cannot currently be rendered from Content Lake resources, so the file is always uploaded.
• Interactive, Article, and Newsletter have no file formats at all — they are delivered exclusively through the hosted ONLINE manifestation class, assembled from the Content Lake at access time.
• Certification has neither files nor manifestations: certification products are entitlement wrappers with no content embodiment.

flowchart TD
    B["Book"] --> BOTH["Both sources<br/>rendered + artifact"]
    CR["Course"] --> BOTH
    VC["Video Course"] --> ART["Artifact only<br/>uploaded file"]
    AU["Audiobook"] --> ART
    IN["Interactive"] --> HOST["No file<br/>hosted ONLINE only"]
    AR["Article"] --> HOST
    NL["Newsletter"] --> HOST
    CE["Certification"] --> NONE["No file<br/>entitlement wrapper"]

Format sourcing

A product offers its content through Manifestations, and each Manifestation carries the formats that realise it as files. Every format declares how its file comes to exist — its source — and this is decided per format, never per product.

RENDERED formats have no stored file. The product holds a composition — an ordered tree of references to Content Lake resources — and the output is generated on the fly: content streams out of the Content Lake, product assets (the cover, the imprint) are injected, the table of contents and index are generated dynamically, and the target format is rendered, all in a single streaming pipeline with no intermediate file kept anywhere.

ARTIFACT formats have a pre-existing distributable — an ePub, a SCORM package, a video file. The file is uploaded and stored by the platform as a product asset (ast_). The binary is treated as opaque: it is never decomposed into Content Lake resources. But a structural descriptor is extracted at upload — an ePub's navigation, a SCORM package's manifest, a PDF's outline — so consumers can see what is inside and how to consume it without opening the file. Artifact formats are the compatibility path for existing catalogue items and the natural home for content produced outside the Content Lake.

Because sourcing is per format, it can vary even within one Manifestation: a PRINT manifestation might pair a rendered InDesign file with a print-ready PDF supplied by an external typesetter as an uploaded artifact. A product whose formats are all artifacts is fully upload-backed; one whose formats are all rendered is fully Content Lake-backed; anything in between is mixed. The search attribute product_model is derived from the format sources and takes one of three values: artifact, rendered, or mixed.

The types in detail

Types versus manifestation classes

Product types and manifestation classes are different axes. The type says what is being sold; the class says how it is embodied and delivered. One is a property of the product; the other is a property of each SKU beneath it.

The full set of manifestation classes is PRINT, EBOOK, AUDIOBOOK, VIDEO, ONLINE, and SCORM_PACKAGE; PRINT takes the forms PAPERBACK or HARDBACK, and AUDIOBOOK and VIDEO take DOWNLOAD or STREAM. These are the vocabulary contracts speak — a grant names a manifestation class and form, scoped by territory, language, and medium.

graph BT
  MP["Manifestation<br/>PRINT · PAPERBACK"] -->|embodies| E1
  MB["Manifestation<br/>EBOOK"] -->|embodies| E1["Expression<br/>TEXT · en"]
  MA["Manifestation<br/>AUDIOBOOK · DOWNLOAD"] -->|embodies| E2["Expression<br/>AUDIO · en"]
  E1 -->|realises| W["Work<br/>rights + contracts"]
  E2 -->|realises| W
  MP -.->|offered as| PB["Product · type Book"]
  MB -.->|offered as| PB
  MA -.->|offered as| PA["Product · type Audiobook"]

Three rules keep the two axes from collapsing back into one:

• Contracts never speak product-type vocabulary. Grants name manifestation classes and forms, not "Book" or "Course". "May we build a course from this?" is a derivation question — a DERIVE-family usage term — because building a course creates a new Work with its own rights basis.
• Product configuration is not identity. Trim size, binding style, interior stock, ebook file format, and DRM live in the format configuration, below the class and form — never as manifestation classes of their own.
• Rights are read, never enforced, here. The resolved manifestation rights on a Work bound which Manifestations may be produced and offered; the Product Management service surfaces them, and Distribution applies the policy.

Format configuration

Every format carries a configuration object that shapes its output. Two products using the same format can produce very different files depending on their configuration. Two configuration values surface into the rights model — the paperback/hardback binding choice is the Manifestation form, and DRM is constrained by contract conditions — and the rest are pure production detail.

Digital format configuration

Digital formats (PDF, ePub) support digital-rights-management options. The DRM choice is not free: it is constrained by the governing contract's DRM_REQUIRED / DRM_PROHIBITED conditions, so a grant condition dictates which protection settings a configuration may legally use. DRM is never a manifestation class of its own.

A product can offer the same format both with and without DRM — a DRM-free PDF for direct sales and a DRM-protected PDF for third-party distribution — provided the contract permits it.

{
  "format": "PDF",
  "source": "RENDERED",
  "configuration": {
    "drm": "watermark",
    "watermark_text": "Licensed to acme-corp"
  }
}

SCORM packaging configuration

Rendered SCORM packages are generated from the product's composition: MODULE nodes become organisation items, LESSON nodes are rendered as HTML SCOs, and imsmanifest.xml is generated from the tree. Uploaded SCORM packages keep their own packaging — the manifest inside the zip is parsed into a descriptor at upload so the platform and any LMS can read the organisation tree and launch points without unpacking the file.

{
  "format": "SCORM",
  "source": "RENDERED",
  "packaging": {
    "schema": "SCORM_2004_4E",
    "organization": { "modules_from": "MODULE", "scos_from": "LESSON" },
    "sequencing": "LINEAR",
    "completion": { "rule": "ALL_SCOS", "mastery_score": 0.8 }
  }
}

Print format configuration

Print formats (rendered InDesign or PDF, or an uploaded print-ready PDF) carry a detailed physical specification. This is the production detail that sits below the Manifestation form — the paperback or hardback choice is the rights-relevant form; everything else here is manufacturing configuration.

Content type roadmap

The eight types are the shipped set. A broader range of content types is under consideration for future work — among them whitepapers, research papers, versioned documentation, podcasts, hands-on labs, standalone assessments, workshops, datasets, code repositories, tutorials, Q&A pairs, RFCs and specifications, changelogs, conference talks, and slide decks. Newsletters and blog posts have already graduated from this list — Newsletter shipped as a type, and blog posts are covered by Article. None of the rest is available yet; they are recorded here so integrators know the type set is expected to grow rather than being fixed at eight forever.

Related pages

• Products overview — how a Work becomes sellable things.
• Composition — the ordered tree a rendered format is assembled from.
• Catalogues — how products are grouped for a storefront or channel.
• Contracts & Rights — the manifestation vocabulary grants speak, and the conditions that constrain DRM.
• Core concepts — the Work → Expression → Manifestation → Product ladder.
• Explorer — Chapter VII — products, seen visually.