target-revenue/specs/CanonicalMonetizationProfiles.md
tegwick 1fb7212e2d Implement WP-0015-T02: extract policy/profile spec files
specs/policies/linear-longstop-v0.md extracted from
OpenQuestions-WorkingDefaults.md Q7's prose, with policy_id/title
frontmatter -- Q7 now records only the adoption decision, pointing at
this file for the formula itself.

Six specs/profiles/*.md files extracted from
CanonicalMonetizationProfiles.md's per-profile sections (#1-6), each
with extension_id/title frontmatter matching the ids already used in
real Phase Manifests. CanonicalMonetizationProfiles.md keeps the
cross-profile summary and non-goals sections, now pointing at the
extracted files instead of containing their content.

DevelopmentEffortCalculatorConcept.md gets calculator_id/revision/title
frontmatter for consistency, no move (already conformed as one file per
model). Checked for stale cross-references before editing -- nothing
in the repo links to the removed section anchors.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-03 20:49:22 +02:00

62 lines
3.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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).
Each profile's full worked narrative now lives in its own file under
`specs/profiles/` (WP-0015-T02), one per profile, each with
`extension_id`/`title` frontmatter so the id → file mapping is explicit:
1. [`development-license`](profiles/development-license.md) — 100% default allocation
2. [`cost-plus-operations`](profiles/cost-plus-operations.md) — 0% default, declarable on surcharge
3. [`phase-sponsorship`](profiles/phase-sponsorship.md) — no default, explicit per transaction
4. [`service-with-development-allocation`](profiles/service-with-development-allocation.md) — 0% default, explicit split on incorporated reusable work
5. [`product-ideation`](profiles/product-ideation.md) — 0% default, allocation only at later adoption
6. [`general-consulting`](profiles/general-consulting.md) — 0% fixed by definition
This document remains the cross-profile comparison and non-goals record
(§7§8 below).
---
## 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.