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>
62 lines
3.3 KiB
Markdown
62 lines
3.3 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).
|
||
|
||
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.
|