# 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). --- ## 1. `development-license` **What the payer receives:** commercial-use rights and early commercial access to the protected, pre-conversion Milestone Release — the direct purchase of a Commercial Entitlement under the Commercial Use Agreement. **Worked narrative:** a company wants to run the governed software commercially before its Conversion Event. It pays a fixed development fee under the CUA's Exhibit A. Once the payment settles (processor confirmation, not invoice date — Rule 4), 100% of the net amount (after tax, refunds, chargebacks) becomes Development Credit for the Phase named in the CUA. This is the simplest and most direct profile: the payment's entire purpose is buying into the protected development, so its entire net value counts. **Default `development_allocation`:** 100%. **Fixture:** `examples/phase-001/extensions/development-license.json`. --- ## 2. `cost-plus-operations` **What the payer receives:** a hosted, operated instance of the software — compute, storage, networking, monitoring, backup, incident response — priced at cost plus a surcharge (default 50%). **Worked narrative:** a customer doesn't want to self-host; they pay for a managed instance. The bulk of this price recovers real operating cost, not development investment — per concept §13.4 (already settled), operations revenue must not be conflated with Development Credit or used to pause degeneration. By default, **none** of this revenue counts toward the Phase's Outstanding Target. A Phase may explicitly declare a nonzero allocation specifically on the surcharge portion (the profit margin above cost) if the Licensor and Customer agree the hosting relationship itself also functions as a development investment — but this must be an explicit, recorded declaration, never inferred from the existence of a hosting fee. **Default `development_allocation`:** 0% (declarable nonzero on the surcharge only, by explicit agreement). **Fixture:** `examples/phase-001/extensions/cost-plus-operations.json`. --- ## 3. `phase-sponsorship` **What the payer receives:** no direct product access at all in the minimal case — this profile is for financial support explicitly directed at funding a named Phase's development, structurally closer to a grant or sponsorship than a purchase. **Worked narrative:** a foundation, a downstream adopter, or an interested party wants to fund a specific Phase's completion without necessarily receiving a Commercial Entitlement themselves (though nothing prevents combining this with one). Because there is no natural default split (unlike a hosting fee, a sponsorship payment has no "cost" component to separate from "development" component), the sponsoring party and Licensor must explicitly declare what fraction of the sponsorship is development allocation at the time it's recorded. **Unrestricted general project sponsorship — support for the project as a whole, not any one Phase — is never assigned to a Phase by default**, since assigning it silently would let a Licensor manufacture Development Credit for a struggling Phase by recharacterizing general goodwill funding after the fact. **Default `development_allocation`:** explicitly declared per transaction, no numeric default. **Fixture:** `examples/phase-001/extensions/phase-sponsorship.json`. --- ## 4. `service-with-development-allocation` **What the payer receives:** installation, migration, configuration, integration, customization, support, or training services. **Worked narrative:** a customer pays for a services engagement — say, a custom integration. Most of this work is customer-specific and has no bearing on the governed Milestone Release's own development; it defaults to 0% allocation. If, during the engagement, a genuinely reusable component is built and actually incorporated into the governed Milestone Release (not merely "could theoretically be reused" — actually merged), the Licensor may split out and declare that reusable portion's value as Development Credit, with a statement identifying the specific reusable deliverable. Customer-specific configuration itself is **never** allocated, regardless of how the engagement is billed. **Default `development_allocation`:** 0% (explicit split when a reusable deliverable is actually incorporated). **Fixture:** `examples/phase-001/extensions/service-with-development-allocation.json`. --- ## 5. `product-ideation` **What the payer receives:** paid discovery, requirements-gathering, or prototyping work exploring a *possible* future product direction — work that has not yet been committed to any governed Milestone Release, and may never be. **Worked narrative:** a company pays for exploratory work on an idea that might become a future Phase, or might not. At the time of payment, there is no Phase to allocate anything toward — this is the key distinction from `service-with-development-allocation`, where a Phase already exists and is being actively developed. Default allocation is 0%. If the ideation output is later adopted into an actual governed Milestone Release, the allocation decision is made **at that later time**, against the adopting Phase, as a new declaration — never inferred automatically from the original, pre-Phase-existence payment. This ordering (Phase must exist before allocation can be declared against it) prevents retroactively manufacturing Development Credit for a Phase using unrelated earlier payments. **Default `development_allocation`:** 0% (or explicitly declared later, against a specific adopting Phase, once one exists). **Fixture:** `examples/phase-001/extensions/product-ideation.json` (new). --- ## 6. `general-consulting` **What the payer receives:** general technical advisory, architecture review, or strategy consulting engaged alongside the Software, but not scoped to building or delivering any specific governed Milestone Release. **Worked narrative:** a company retains the Licensor's team for broad technical guidance unrelated to any one Phase's deliverable — the opposite end of the spectrum from `development-license`. This profile's `development_allocation` is 0% **by definition**, not merely by default: its entire scope is defined as work that isn't a development contribution to any specific Phase. A payer who wants engagement work to actually count toward a Phase target must use a Phase-scoped profile instead (`development-license`, `service-with-development-allocation`) — choosing `general-consulting` is itself the declaration that no allocation is intended. **Default `development_allocation`:** 0% (fixed, not merely defaulted). **Fixture:** `examples/phase-001/extensions/general-consulting.json` (new). --- ## 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.