# Canonical Monetization Profile Catalog

Status: Draft v0.1
Date: 2026-07-29
Workplan: `workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md` T03
Primary artifacts: `specs/MonetizationExtensionSpecification.md` §5, `schemas/extension_contract.schema.json`, `examples/phase-001/extensions/`

Full worked pricing narratives and examples for the six canonical-candidate
Monetization Extensions already named in
`specs/MonetizationExtensionSpecification.md` §5. All six now have a
fixture in `examples/phase-001/extensions/`, validated against
`schemas/extension_contract.schema.json`. This document does not
canonicalize any profile — promotion from `registered` to `canonical` is a
separate, documented governance action
(`workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md` T04).

Each profile's full worked narrative now lives in its own file under
`specs/profiles/` (WP-0015-T02), one per profile, each with
`extension_id`/`title` frontmatter so the id → file mapping is explicit:

1. [`development-license`](profiles/development-license.md) — 100% default allocation
2. [`cost-plus-operations`](profiles/cost-plus-operations.md) — 0% default, declarable on surcharge
3. [`phase-sponsorship`](profiles/phase-sponsorship.md) — no default, explicit per transaction
4. [`service-with-development-allocation`](profiles/service-with-development-allocation.md) — 0% default, explicit split on incorporated reusable work
5. [`product-ideation`](profiles/product-ideation.md) — 0% default, allocation only at later adoption
6. [`general-consulting`](profiles/general-consulting.md) — 0% fixed by definition

This document remains the cross-profile comparison and non-goals record
(§7–§8 below).

---

## 7. Cross-profile summary

| Profile | Default allocation | Allocation adjustable? | Phase must pre-exist? |
|---|---:|---|---|
| `development-license` | 100% | No (fixed at 100% of net) | Yes |
| `cost-plus-operations` | 0% | Yes, declarable on surcharge only | Yes |
| `phase-sponsorship` | none (explicit) | Required every transaction | Yes |
| `service-with-development-allocation` | 0% | Yes, on actually-incorporated reusable work | Yes |
| `product-ideation` | 0% | Yes, but only at later adoption time, against the adopting Phase | No at payment time; yes at later allocation |
| `general-consulting` | 0% | No — fixed by definition | N/A (never allocated) |

All six share the same reversal pattern (a compensating `credit-reversal`
ledger entry for refunds/chargebacks, per TSD §3.2 Rule 8) and the same
recognition event (`payment-settled`, Working Default Q10) — variation
across profiles is entirely in the allocation rule, consistent with
`specs/MonetizationExtensionSpecification.md` §4's non-redefinition
constraint (an extension may only ever affect `development_allocation`,
never the core terms themselves).

---

## 8. Non-goals

- Canonicalizing any of the six profiles (`registered` → `canonical`) —
  that is T04's checklist and a separate governance action.
- Inventing a seventh profile — this document catalogs the six already
  named in `specs/MonetizationExtensionSpecification.md` §5, it does not
  expand that set.
- Resolving the degeneration policy formula — `specs/TargetDegenerationPolicyResearch.md`
  (T01) and T02's human gate, a separate and unrelated open question.