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>
This commit is contained in:
parent
d8aa9b3f96
commit
1fb7212e2d
12 changed files with 237 additions and 152 deletions
|
|
@ -14,150 +14,19 @@ 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`
|
||||
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
|
||||
|
||||
**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).
|
||||
This document remains the cross-profile comparison and non-goals record
|
||||
(§7–§8 below).
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue