target-revenue/specs/MonetizationExtensionSpecification.md

Monetization Extension Specification (Normative Extract)

Document version: TRF-Extension-0.1 Status: Normative extract, Stage 0 Extracted from: specs/TargetRevenueLicenseConcept.md §11–§12 and specs/TechnicalSpecificationDocument.md §3.3 Machine-readable counterpart: schemas/extension_contract.schema.json — implemented and tested under workplans/TREV-WP-0002-trust-service-foundation.md T04 (src/target_revenue/validation.py::validate_extension_contract).

This is a complete short specification, not a stub — it freezes the extension contract and the registered/canonical distinction. It intentionally does not catalog all canonical profiles in depth; that remains a follow-on, specs/CanonicalMonetizationProfiles.md (planned).

---

1. Purpose

Monetization Extensions let new commercial mechanisms be published without redefining or fragmenting the core (specs/TargetRevenueFrameworkCore.md). The framework's central economic distinction is between target-relevant allocation (may become Development Credit) and non-target allocation (everything else) — a monetization label explains the transaction; the explicit allocation determines its effect on conversion.

2. The six-field extension contract

Every extension must answer exactly these six questions and no more:

Field	Question	Type
value.description	What does the payer receive?	string
pricing.method	How is the payment calculated?	string
allocation.rule	What portion may become Development Credit?	string, plus optional default_rate (0–1)
recognition.event	When is the allocation recognized?	enum {order, invoice, payment-settled, delivery}
reversal.rule	How are refunds, chargebacks, or corrections handled?	string
evidence.requirement	What proves the transaction and allocation?	string

Working default (Q10): recognition.event should be payment-settled for any entry that is to count as Development Credit or Remission Credit in the Stage 0 fold. Invoice/order without settlement does not create a fold-eligible entry in Stage 0.

3. What an extension must not do

An extension may define pricing and allocation logic. An extension must not reference or redefine: Phase, Initial Target, Development Credit, Remission Credit, Outstanding Target, Conversion Event, or Future License (specs/TargetRevenueFrameworkCore.md §1). This is the constitutional boundary between flexibility and complexity (concept §20.1's complexity budget applies equally here).

Conformance check: structural conformance (all six fields present and well-typed) is validated against schemas/extension_contract.schema.json. The core-term-redefinition rule is checked by a pattern-based heuristic in src/target_revenue/validation.py::check_extension_core_term_redefinition — documented there as a Stage 0 limitation, not a substitute for human review before an extension is promoted to canonical.

A non-conforming extension is rejected at registration, with a field-by-field diff, not silently accepted with reduced trust.

4. Registered vs. canonical

Status	Meaning
registered	Passes the conformance check. No endorsement implied.
canonical	Reviewed and maintained as a recommended framework profile. Promotion is a documented human/governance action (SCOPE.md §4), never automated.
deprecated	No longer recommended; existing registrations remain valid evidence, but should not be used for new Phases.

5. Stage 0 canonical profile catalog (working default Q11)

Six initial canonical-candidate profiles, shipped as registered fixtures pending formal canonical review:

Profile	Default development_allocation	Fixture
development-license	100% of settled development fee (net of tax/refunds)	examples/phase-001/extensions/development-license.json
cost-plus-operations	0%	examples/phase-001/extensions/cost-plus-operations.json
phase-sponsorship	Explicitly declared per transaction	examples/phase-001/extensions/phase-sponsorship.json
service-with-development-allocation	0% (explicit split when reusable work enters the Milestone)	examples/phase-001/extensions/service-with-development-allocation.json
product-ideation	0% or declared	Not yet fixture-backed
general-consulting	0%	Not yet fixture-backed

A full worked catalog with pricing narratives belongs in specs/CanonicalMonetizationProfiles.md (planned, PRD Roadmap Phase 3).

6. Conservation rule

One monetary unit may create no more than one monetary unit of Development Credit (Rule 3). A payment may be split across allocation purposes, but the split must be declared when the transaction is created — never inferred after the fact from a monetization label.

7. Not covered here

• The Target Ledger entries that record an extension's effect: specs/TargetLedgerSpecification.md.
• Full pricing narratives and worked examples per canonical profile: specs/CanonicalMonetizationProfiles.md (planned).
• Extension registry hosting and canonical-promotion workflow tooling: deferred to a Trust Service implementation workplan (SCOPE.md §3).