Worked examples

The rest of this section explains the contract model field by field. This page does the opposite: it starts from situations Packt actually meets — signing an author, licensing a title to a partner, widening a deal by addendum, renegotiating with an estate, resolving two deals that disagree — and shows the contract each one produces.

Every scenario follows the same shape. A short plain-English story sets the scene, a table or diagram summarises the terms that matter, and the full contract record sits in a collapsed block for anyone who wants to copy it. You can read every story straight through without ever opening the JSON.

Two ideas from Works & rights recur throughout, so they are worth restating once. First, a Contract attaches to a Work — the intellectual-property anchor — never to an individual document or file; the rights it grants are resolved on the Work and projected onto every Resource beneath it. Second, only inbound contracts (rights flowing in from an author or rights holder) contribute to what the platform holds; outbound contracts (rights flowing out to a distributor or partner) are checked against those held rights and never widen them.

Money in the JSON is in integer micros (1,000,000 micros = 1.00 of the stated currency) and rates are in basis points (rate_bps: 2500 = 25%). IDs use readable slugs in place of the random suffix.

1. A standard author deal

Priya Chandra writes Hands-On Machine Learning with Go. She grants Packt worldwide rights to publish it, in every language, as an ebook and in print — but keeps audiobook rights back for a separate deal she is still negotiating. She is paid a royalty: 25% of net receipts on ebooks, 10% on everything else, every quarter. This is the everyday shape of Packt's list, and it is an inbound contract — the author is granting rights to the platform.

The three grant axes each do one job. Territory opens the whole world. Manifestation says which sellable embodiments may be produced — ebook and print yes, audiobook explicitly no — so the moment anyone tries to build an audiobook Product from this Work, the rights check denies it, with no extra configuration anywhere downstream. Royalty prices each sale by its most specific matching rule.

flowchart TD
    C["Author agreement<br/>ctr_chandra_2026 · INBOUND"] --> W["Work<br/>wk_ml_go"]
    W --> P1["Ebook · PERMITTED"]
    W --> P2["Print · PERMITTED"]
    W --> X1["Audiobook · PROHIBITED"]
    W --> R1["Resource · Chapter 1"]
    W --> R2["Resource · Chapter 3"]

The audiobook prohibition is the interesting bit. Because it is set once on the Work, it governs every Resource, Expression, and Product built from Hands-On Machine Learning with Go automatically — nobody has to remember it, and nobody downstream can quietly override it.

{
  "id": "ctr_chandra_2026",
  "title": "Author Agreement — Hands-On Machine Learning with Go",
  "status": "ACTIVE",
  "direction": "INBOUND",
  "version": 1,
  "agents": [
    { "agent_id": "agt_chandra", "role": "AUTHOR", "name": "P. Chandra" },
    { "agent_id": "agt_packt", "role": "PUBLISHER", "name": "Packt Publishing" }
  ],
  "work_ids": ["wk_ml_go"],
  "territorial_rights": [
    { "worldwide": true, "status": "PERMITTED" }
  ],
  "manifestation_rights": [
    { "manifestation_type": "EBOOK", "status": "PERMITTED" },
    { "manifestation_type": "PRINT", "status": "PERMITTED" },
    { "manifestation_type": "AUDIOBOOK", "status": "PROHIBITED" }
  ],
  "royalty": {
    "type": "ROYALTY",
    "currency": "GBP",
    "basis": "NET_RECEIPTS",
    "rates": [
      { "rate_bps": 1000 },
      { "manifestation_type": "EBOOK", "rate_bps": 2500 }
    ],
    "payment_frequency": "QUARTERLY"
  },
  "usage_terms": [
    {
      "usage_type": "ACCESS",
      "status": "PERMITTED",
      "user_types": ["INDIVIDUAL", "INSTITUTIONAL"]
    },
    { "usage_type": "DISPLAY", "status": "PERMITTED" },
    { "usage_type": "TRANSLATE", "status": "PROHIBITED" }
  ],
  "duration": {
    "effective_date": "2026-01-01T00:00:00Z",
    "expiry_date": "2029-01-01T00:00:00Z",
    "auto_renew_months": 12,
    "notice_period_days": 90
  }
}

2. A distributor grant

Packt already holds the rights above, and now wants to sell the same Work through O'Reilly's learning platform. That is an outbound contract: Packt grants onward a slice of what it holds. The slice is deliberately narrow — ebook only, US and UK only, streamed to O'Reilly's own subscribers — with attribution required on every use and a named channel rule that Distribution will match against later.

Two things make outbound different from inbound. It never widens the Work's rights: reading the Work still shows only Priya's inbound grant. And it is validated at activation against the resolved inbound rights — Packt cannot grant O'Reilly a territory, manifestation, or usage it does not itself hold. Try to add audiobook here and activation fails, because the inbound deal prohibits audiobook.

flowchart LR
    W["Work · wk_ml_go<br/>inbound rights held"] -->|checked at activation| O["Distributor grant<br/>ctr_oreilly_ml_go · OUTBOUND"]
    O --> CH["Channel<br/>O'Reilly Learning · US/GB · ebook"]
    O -.->|never widens| W

{
  "id": "ctr_oreilly_ml_go",
  "title": "O'Reilly Distribution — Hands-On Machine Learning with Go",
  "status": "ACTIVE",
  "direction": "OUTBOUND",
  "version": 1,
  "agents": [
    { "agent_id": "agt_packt", "role": "PUBLISHER", "name": "Packt Publishing" },
    {
      "agent_id": "agt_oreilly",
      "role": "DISTRIBUTOR",
      "name": "O'Reilly Media",
      "email": "partners@oreilly.com"
    }
  ],
  "work_ids": ["wk_ml_go"],
  "territorial_rights": [
    { "territory_codes": ["US", "GB"], "status": "PERMITTED" }
  ],
  "manifestation_rights": [
    { "manifestation_type": "EBOOK", "status": "PERMITTED" }
  ],
  "usage_terms": [
    {
      "usage_type": "MAKE_AVAILABLE",
      "status": "PERMITTED",
      "user_types": ["INDIVIDUAL", "INSTITUTIONAL"],
      "method": "VIEW_ONLINE",
      "territory_codes": ["US", "GB"]
    },
    {
      "usage_type": "DISTRIBUTE",
      "status": "PERMITTED",
      "purpose": "COMMERCIAL"
    }
  ],
  "handling_terms": [
    {
      "handling_type": "ATTRIBUTION",
      "status": "REQUIRED",
      "exception": "Attribute Packt and the author on every use"
    }
  ],
  "channel_rules": [
    {
      "channel_id": "oreilly-learning",
      "channel_name": "O'Reilly Learning",
      "territory_codes": ["US", "GB"],
      "permitted_manifestation_types": ["EBOOK"],
      "category_codes": ["COM051000"],
      "status": "PERMITTED"
    }
  ],
  "royalty": {
    "type": "ROYALTY",
    "currency": "USD",
    "rates": [{ "rate_bps": 2500 }],
    "payment_frequency": "MONTHLY"
  },
  "duration": {
    "effective_date": "2026-02-01T00:00:00Z",
    "expiry_date": "2028-02-01T00:00:00Z",
    "auto_renew_months": 12
  }
}

3. An addendum amending territory

A year in, the author deal is doing well and Packt wants to sell into Australia and Canada too. Priya signs a one-page addendum widening the territory. The important thing is what the platform does not do: it does not edit the original contract in place. Instead the addendum produces a new version — version 2 — that carries the full amended term set, while version 1 is preserved exactly as signed. The history is never lost.

Publishing version 2 emits a rights_changed event. The Content Lake hears it, re-resolves the Work's rights, and rewrites the projection on every Resource beneath it — the reprojection ripple described in Works & rights. Nobody sweeps the catalogue by hand; the two new markets simply start resolving as permitted on the next query.

flowchart LR
    V1["Version 1<br/>US, GB permitted"] -->|addendum signed| V2["Version 2<br/>US, GB, AU, CA permitted"]
    V2 -->|rights_changed| CL["Content Lake<br/>reprojects the Work"]
    CL --> IDX["Search index +<br/>Resource projections updated"]

{
  "id": "ctr_chandra_2026",
  "version": 1,
  "territorial_rights": [
    { "territory_codes": ["US", "GB"], "status": "PERMITTED" }
  ]
}

{
  "id": "ctr_chandra_2026",
  "version": 2,
  "territorial_rights": [
    {
      "territory_codes": ["US", "GB", "AU", "CA"],
      "status": "PERMITTED",
      "source": {
        "document_id": "srcdoc_chandra_addendum_1",
        "clause": "1.1"
      }
    }
  ]
}

4. A succession window — two contracts on one Work

An author's fixed-term agreement is running out, and the renegotiated replacement is not signed yet. For a few weeks the Work sits under two contracts at once: the old agreement, now EXPIRED but carrying a continuing-access window so existing subscribers keep their ebook access, and the new agreement, freshly ACTIVE. This is the classic succession shape, and it is exactly why a Work can be governed by more than one contract.

The merge behaviour is what matters. Between the old deal's expiry and the new deal's effective date, only the expired contract contributes — and only its continuing-access terms, so existing ebook entitlements stay served and nothing else resolves. Once the new agreement takes effect, it contributes its full terms; the two windows overlap briefly, and during that overlap a Resource's rights_basis pins both contracts — one entry each.

gantt
    dateFormat YYYY-MM-DD
    axisFormat %b
    title Two contracts across the succession window
    section Old agreement (EXPIRED)
    In force            :done, 2023-01-01, 2026-01-01
    Continuing access   :active, 2026-01-01, 2026-05-01
    section New agreement (ACTIVE)
    In force            :2026-04-01, 2029-04-01

{
  "id": "wk_python_data",
  "rights": {
    "contracts": [
      {
        "id": "ctr_devi_2023",
        "status": "EXPIRED",
        "version": 4,
        "duration": {
          "effective_date": "2023-01-01T00:00:00Z",
          "expiry_date": "2026-01-01T00:00:00Z",
          "continuing_access": {
            "post_cancellation_access": true,
            "access_period_days": 120,
            "permitted_manifestation_types": ["EBOOK"],
            "description": "Existing subscribers keep ebook access during renegotiation"
          }
        }
      },
      {
        "id": "ctr_devi_2026",
        "status": "ACTIVE",
        "version": 1,
        "duration": {
          "effective_date": "2026-04-01T00:00:00Z",
          "expiry_date": "2029-04-01T00:00:00Z",
          "auto_renew_months": 12,
          "notice_period_days": 90
        }
      }
    ]
  }
}

{
  "id": "res_python_data_ch1",
  "work_id": "wk_python_data",
  "usable": true,
  "rights_basis": [
    { "contract_id": "ctr_devi_2023", "contract_version": 4 },
    { "contract_id": "ctr_devi_2026", "contract_version": 1 }
  ]
}

5. A rights conflict — prohibition wins

Two inbound contracts govern one Work and they disagree. The author agreement permits worldwide distribution. A separately acquired rights-holder agreement — perhaps covering a third-party asset embedded in the title — prohibits distribution in the European Union pending a compliance review. What does the Work resolve to?

The rule is simple and absolute: where grants overlap, prohibition wins. The platform unions the permitted grants, then subtracts every prohibited one. So the Work resolves to distributable everywhere except the EU — the EU prohibition beats the worldwide permit precisely where they overlap, and leaves the rest of the worldwide permit intact. The precedence order is PROHIBITED > CONDITIONAL > PERMITTED.

flowchart TD
    A["Author agreement<br/>worldwide · PERMITTED"] --> M{"Resolution<br/>on the Work"}
    B["Rights-holder agreement<br/>EU · PROHIBITED"] --> M
    M --> R["Resolved rights<br/>worldwide EXCEPT the EU"]

The same precedence settles a usage disagreement identically: if one contract permits AI_TRAINING and another prohibits it, the resolved verdict is prohibited. A prohibition can never be cancelled by another contract's permission or silence — that is what makes the model safe to build enforcement on.

{
  "id": "ctr_okafor_2026",
  "direction": "INBOUND",
  "territorial_rights": [
    { "worldwide": true, "status": "PERMITTED" }
  ]
}

{
  "id": "ctr_dataco_2026",
  "direction": "INBOUND",
  "territorial_rights": [
    {
      "territory_sets": [
        {
          "set": "EU",
          "pinned_codes": [
            "AT", "BE", "BG", "HR", "CY", "CZ", "DK", "EE", "FI",
            "FR", "DE", "GR", "HU", "IE", "IT", "LV", "LT", "LU",
            "MT", "NL", "PL", "PT", "RO", "SK", "SI", "ES", "SE"
          ]
        }
      ],
      "status": "PROHIBITED"
    }
  ]
}

{
  "id": "wk_okafor_secure",
  "rights": {
    "contracts": [
      { "id": "ctr_okafor_2026", "status": "ACTIVE", "version": 1 },
      { "id": "ctr_dataco_2026", "status": "ACTIVE", "version": 1 }
    ],
    "territorial_rights": [
      { "worldwide": true, "status": "PERMITTED" },
      {
        "territory_sets": [{ "set": "EU" }],
        "status": "PROHIBITED"
      }
    ]
  }
}

Where to go next

These five cover the everyday shapes. When the question is "can the model hold this clause?", go to Complete examples — three deliberately maximal records distilled from Packt's real contract archive, with a lookup table from real-world clause to schema field. When you need a specific corner of the model, reach for the field reference in the Contract model.

Related pages

• Contracts overview — what contracts are and how they fit the platform.
• Contract model — the field-by-field reference behind every example here.
• Royalties — how the commercial terms in these examples are computed and settled.
• Works & rights — how a contract's rights reach content through projection.
• Explorer — Chapter III — contracts and rights, visualised.