tegwick
58a4dd1db2
T01: specs/TargetDegenerationPolicyResearch.md. Survey finds no precedent (BSL/FSL/Elastic) implements progress-sensitive degeneration - TRSL's model is original design. Proposes a candidate v1 formula (90-day rolling "quiet period" pause on Remission Credit accrual during active Development Credit periods), resolves the contributor-diversity input as explicitly not-adopted (no gaming-resistant signal exists yet), and resolves the longstop/progress-sensitivity relationship as a hard, unconditional backstop. Does not recommend v0 vs v1 for T02 - that's the human gate. T02: recommendation added (confirm v0 for the first pilot cohort, name v1 as the next iteration) - left todo per the human-accept policy. T03: specs/CanonicalMonetizationProfiles.md with worked narratives for all six catalog profiles, plus two new fixtures (product-ideation, general-consulting), both schema-validated and added to the parametrized conformance test. T04: specs/CanonicalizationReviewChecklist.md, an 8-item checklist layered on the already-implemented promote_extension_canonical() mechanism (WP-0006-T03) - defines what a reviewer must verify, not a new promotion mechanism.
193 lines
9 KiB
Markdown
193 lines
9 KiB
Markdown
# 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.
|