coulomb/target-revenue
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Advance WP-0007: degeneration research, profile catalog, canonicalization checklist

Browse source 
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.
This commit is contained in:
tegwick 2026-07-29 22:31:19 +02:00
parent 8894acc584
commit 58a4dd1db2
8 changed files with 658 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

193
specs/CanonicalMonetizationProfiles.md Normal file
View file

@ -0,0 +1,193 @@
# 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.