Operations

Most of this site describes a core that is largely settled: the Content Lake holds content and its resolved rights, Contracts hold the terms, and Products compose what customers actually buy. Around that core sits a ring of operational services — the ones that sell things, decide who may access what, remember what happened, and pay the people whose work made the sale. This page introduces that ring and the journey that connects it: sell → entitle → measure → pay.

The journey: sell → entitle → measure → pay

The four services tell one story. An order is placed on a Packt storefront; the order creates an entitlement — a durable record that this customer may access this product; every use of that access is measured as behavioural facts; and periodically those facts meet the contract terms so that authors get paid. Identity underpins every step, because each of them starts with knowing who is on the other end.

flowchart LR
    ORD["Orders<br/>sell"] --> ENT["Entitlements<br/>entitle"]
    ENT --> ANA["Analytics & usage<br/>measure"]
    ANA --> ROY["Royalty operations<br/>pay"]
    ID["Identity<br/>customers & organisations"] -.-> ORD
    ID -.-> ENT

The deliberate split matters as much as the flow. Recording what happened is kept apart from deciding what it is worth: usage and analytics capture facts, and only Royalty operations — reading the contract model — turns facts into money. That is the same separation the rest of the platform uses everywhere: one service owns the record, another owns the interpretation.

Orders — sell and entitle

Orders is first-party commerce: purchases, subscriptions, and refunds on Packt's own storefronts. What is on sale in each storefront is already decided elsewhere — Catalogues define the set, with their destination templates and price policies — so Orders picks up at the moment a customer commits to buy.

The most important thing an order does is create an entitlement: the durable record that this customer (or this organisation's seats) may access this product. Entitlements outlive the checkout — they are what subscription renewals extend, refunds revoke, and access checks consult. And because a sale is a royalty-bearing event, orders are also the retail input to the royalty pipeline: what was sold, at what price, under which product.

Third-party sales — Amazon, subscription partners — do not flow through Orders; they arrive through the channel partners described in Distribution & Channels.

Royalty operations — pay what the contracts promise

The royalty model is already documented and settled: rates, bases, advances, recoupment, splits, and the most-specific-wins resolution all live on Contracts. What is being designed is the service that executes that model on real numbers: accruing earnings from sales and usage, attributing consumption-pool revenue, running settlement periods, issuing statements, and triggering payouts.

Its inputs are deliberately dumb. Retail sales arrive from Orders and channel partners; served AI usage arrives as fact events — one event per served response, carrying which resources appeared, from which version, ranked or cited, under which rights basis — as described in How AI use is tracked and Events. None of those events carry a royalty weight. Royalty operations is the only place facts meet contract terms, which means a change to a contract changes future statements without rewriting history.

Analytics — the platform's behavioural memory

Analytics is the part of the ring that already partially exists. Search feedback and executed-search events stream into an analytics store today, and a refresh workflow aggregates per-resource performance — signals like recent sales performance — and feeds it back into search ranking. Platform-maintained labels such as trending come from the same loop: the system observes, the system labels, and no one curates popularity by hand.

The design direction is to grow this into the platform's behavioural memory: one place where orders, usage, and engagement can be asked questions — what is selling, what is being read, what do AI surfaces actually serve — without touching the operational stores that answer customer requests. Search estates beyond the existing Content Lake and Products ones (orders, users, agents) are planned on the same pattern.

Identity — who is on the other end

Identity is the source of truth for customers and B2B organisations: who a person is, which organisation they belong to, and which seats an organisation holds. It is not a password store — authentication is delegated to WorkOS, and the platform's services see only Bearer tokens carrying tenant claims, as described in Authentication and Tenancy & security.

That split keeps the interesting problems local. Identity models the relationships — a customer joining an organisation, seats being assigned, an organisation's entitlements applying to its members — while sign-in mechanics, SSO, and credential storage stay with a provider whose whole job is doing them well.

Signals the ring will publish

Every service on the platform announces state changes as events, and the operations ring will be no different. The names below follow the platform's event grammar but are illustrative, not yet claimed — none of them exists yet.

What does exist today is the usage side: served AI responses are already specified as fact events on their own bus, so the measuring step of the journey has a settled shape even while the services around it are still being drawn.

Related pages

• Royalties — the settled contract model that Royalty operations will execute.
• How AI use is tracked — the fact-based usage events that feed measurement and payment.
• Catalogues — how what is on sale in each storefront is decided before Orders sells it.
• Events — the event grammar and buses the operations ring will publish on.
• Glossary — the platform's shared vocabulary, including the terms used on this page.