target-revenue/specs/CanonicalMonetizationProfiles.md

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.