diff --git a/README.md b/README.md index bc0685e..24f9c38 100644 --- a/README.md +++ b/README.md @@ -40,6 +40,8 @@ Extracted and stabilized from the concept draft under `workplans/TREV-WP-0003-no | [`specs/MonetizationExtensionSpecification.md`](specs/MonetizationExtensionSpecification.md) | Six-field extension contract, registered vs. canonical | | [`specs/PhaseLifecycleUseCases.md`](specs/PhaseLifecycleUseCases.md) | Nine Phase-lifecycle use cases mapped to what's built, what's a real gap, and what has no UI by design (WP-0012-T01) | | [`specs/PhaseProvenanceSpecAddendum.md`](specs/PhaseProvenanceSpecAddendum.md) | Schema/spec-file/UI changes from WP-0012-T02–T04's accepted decisions — repo provenance fields, `specs/policies/`/`specs/profiles/` extraction, ledger UI treatment. **Accepted 2026-08-03**, implementation tracked in WP-0015 | +| [`specs/policies/linear-longstop-v0.md`](specs/policies/linear-longstop-v0.md) | The v1 degeneration-policy formula's own definition — extracted from `OpenQuestions-WorkingDefaults.md` Q7 (WP-0015-T02); Q7 now records only the adoption decision | +| [`specs/profiles/`](specs/profiles/) | The six canonical monetization profiles' worked narratives, one file per profile — extracted from `CanonicalMonetizationProfiles.md` §1–§6 (WP-0015-T02) | **Forbidden synonyms:** do not treat undifferentiated "revenue captured" as equivalent to Development Credit (see `CONTRIBUTING.md` § Terminology); do not call pre-conversion software "Open Source" (see the guardrail table above). @@ -89,7 +91,7 @@ The concept's §13 now defines a **Global Contingency Share Determination Rule** | [TREV-WP-0012](workplans/TREV-WP-0012-phase-provenance-and-policy-modeling.md) | Phase provenance, ledger reference, and degeneration-policy modeling — **finished**, all 5 tasks done. Decisions (T02–T04) synthesized into [`specs/PhaseProvenanceSpecAddendum.md`](specs/PhaseProvenanceSpecAddendum.md) (T05) — **not yet accepted for implementation**; that's the document to discuss before any schema/UI work is filed as its own workplan | | [TREV-WP-0013](workplans/TREV-WP-0013-remission-credit-automation.md) | Remission Credit automation (degeneration policy execution) — active; T01–T03 `wait` on WP-0012-T03's policy-spec-file decision. Nothing currently computes or writes `remission-credit` ledger entries | | [TREV-WP-0014](workplans/TREV-WP-0014-control-plane-extensions-breach-attestation-ui.md) | Control Plane UI: Extension Registry, Breach Records, Conversion Attestation — active; T01 next. Backend for all three already exists (WP-0006); UI-only work, not blocked on WP-0012 | -| [TREV-WP-0015](workplans/TREV-WP-0015-phase-provenance-implementation.md) | Implement `specs/PhaseProvenanceSpecAddendum.md` — active; T01, T04, T06 done (schema change + Control Plane form/ledger UI + real-data backfill for the three pilot candidates). T02 (`specs/policies/`/`specs/profiles/` extraction) next | +| [TREV-WP-0015](workplans/TREV-WP-0015-phase-provenance-implementation.md) | Implement `specs/PhaseProvenanceSpecAddendum.md` — active; T01, T02, T04, T06 done. T03 (Control Plane reference-rendering routes) next | Hub index: [`WORK-RECORDS.md`](WORK-RECORDS.md) · brief: [`.custodian-brief.md`](.custodian-brief.md) diff --git a/specs/CanonicalMonetizationProfiles.md b/specs/CanonicalMonetizationProfiles.md index 0b9a579..5fd8583 100644 --- a/specs/CanonicalMonetizationProfiles.md +++ b/specs/CanonicalMonetizationProfiles.md @@ -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). --- diff --git a/specs/DevelopmentEffortCalculatorConcept.md b/specs/DevelopmentEffortCalculatorConcept.md index 8344867..c214bbc 100644 --- a/specs/DevelopmentEffortCalculatorConcept.md +++ b/specs/DevelopmentEffortCalculatorConcept.md @@ -1,3 +1,9 @@ +--- +calculator_id: development-effort-calculator-candidate-a +revision: "1.0" +title: Development Effort Calculator — Candidate A +--- + # Development Effort Calculator — Concept Status: Concept v0.1 diff --git a/specs/OpenQuestions-WorkingDefaults.md b/specs/OpenQuestions-WorkingDefaults.md index 873d474..19c4828 100644 --- a/specs/OpenQuestions-WorkingDefaults.md +++ b/specs/OpenQuestions-WorkingDefaults.md @@ -84,15 +84,9 @@ A Phase has **one native currency** (`phase.initial_target.currency`). All ledge ## Q7 — Progress-sensitive degeneration formula (7) -**Adopted 2026-07-29** (`workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md` T02, maintainer-accepted): `trsl:policy:linear-longstop-v0` is confirmed as the v1 norm for the first pilot cohort, not merely a Stage 0 pilot placeholder. Defined as: +**Adopted 2026-07-29** (`workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md` T02, maintainer-accepted): `trsl:policy:linear-longstop-v0` is confirmed as the v1 norm for the first pilot cohort, not merely a Stage 0 pilot placeholder. -- Remission accrues **only** by time toward a declared **Longstop Date** (see Q8). -- Between Phase activation `t0` and Longstop `tL`, - \( R(t) = T_0 \times \mathrm{clamp}((t - t_0)/(t_L - t_0), 0, 1) \) - with discrete ledger `remission-credit` entries computed on a published schedule (e.g. daily or monthly UTC), **or** a single full remission at longstop for minimal implementations. -- Development Credit does not change the remission schedule in v0 (no progress-sensitive boost/pause). - -**Research complete, not adopted:** `specs/TargetDegenerationPolicyResearch.md` (T01) proposes a candidate `trsl:policy:progress-paused-longstop-v1` (a 90-day rolling "quiet period" pause on Remission Credit during active Development Credit periods) and explicitly recommends *not* adopting a diversity-of-payers factor (no gaming-resistant signal exists yet). v1 is the named next iteration, to be revisited once real pilot Development Credit data exists — not required before pilot Phases proceed under v0. +**The policy's own definition** (formula, schedule, and the not-yet-adopted `progress-paused-longstop-v1` candidate) lives at `specs/policies/linear-longstop-v0.md` (WP-0015-T02) — this entry is the *decision record* ("this is the accepted v1 norm, adopted 2026-07-29"), not the policy's content. --- diff --git a/specs/policies/linear-longstop-v0.md b/specs/policies/linear-longstop-v0.md new file mode 100644 index 0000000..0c037f0 --- /dev/null +++ b/specs/policies/linear-longstop-v0.md @@ -0,0 +1,43 @@ +--- +policy_id: trsl:policy:linear-longstop-v0@1.0 +title: Linear Longstop v0 +--- + +# Linear Longstop v0 + +Adopted 2026-07-29 +(`workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md` +T02, maintainer-accepted): confirmed as the v1 norm for the first pilot +cohort, not merely a Stage 0 pilot placeholder. + +## Definition + +- Remission accrues **only** by time toward a declared **Longstop Date** + (`specs/OpenQuestions-WorkingDefaults.md` Q8). +- Between Phase activation `t0` and Longstop `tL`, + + R(t) = T0 × clamp((t − t0)/(tL − t0), 0, 1) + + with discrete ledger `remission-credit` entries computed on a published + schedule (e.g. daily or monthly UTC), **or** a single full remission at + longstop for minimal implementations. +- Development Credit does not change the remission schedule in v0 (no + progress-sensitive boost/pause). + +## Status + +Not yet automated — see +`workplans/TREV-WP-0013-remission-credit-automation.md`. Nothing in this +codebase currently computes or writes these entries; this file is the +formula those entries must be checkable against once that workplan lands. + +## Superseded / next iteration + +`specs/TargetDegenerationPolicyResearch.md` (T01) proposes a candidate +`trsl:policy:progress-paused-longstop-v1` (a 90-day rolling "quiet +period" pause on Remission Credit during active Development Credit +periods), research complete but **not adopted**. Explicitly recommends +*not* adopting a diversity-of-payers factor (no gaming-resistant signal +exists yet). Named as the next iteration, to be revisited once real +pilot Development Credit data exists — not required before pilot Phases +proceed under v0. diff --git a/specs/profiles/cost-plus-operations.md b/specs/profiles/cost-plus-operations.md new file mode 100644 index 0000000..cd34c0d --- /dev/null +++ b/specs/profiles/cost-plus-operations.md @@ -0,0 +1,26 @@ +--- +extension_id: trsl:extension:cost-plus-operations@1.0 +title: Cost-Plus Operations +--- + +# 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`. diff --git a/specs/profiles/development-license.md b/specs/profiles/development-license.md new file mode 100644 index 0000000..30c2141 --- /dev/null +++ b/specs/profiles/development-license.md @@ -0,0 +1,23 @@ +--- +extension_id: trsl:extension:development-license@1.0 +title: Development License +--- + +# 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`. diff --git a/specs/profiles/general-consulting.md b/specs/profiles/general-consulting.md new file mode 100644 index 0000000..78e7f5f --- /dev/null +++ b/specs/profiles/general-consulting.md @@ -0,0 +1,25 @@ +--- +extension_id: trsl:extension:general-consulting@1.0 +title: General Consulting +--- + +# 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). diff --git a/specs/profiles/phase-sponsorship.md b/specs/profiles/phase-sponsorship.md new file mode 100644 index 0000000..45db585 --- /dev/null +++ b/specs/profiles/phase-sponsorship.md @@ -0,0 +1,29 @@ +--- +extension_id: trsl:extension:phase-sponsorship@1.0 +title: Phase Sponsorship +--- + +# 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`. diff --git a/specs/profiles/product-ideation.md b/specs/profiles/product-ideation.md new file mode 100644 index 0000000..fa54946 --- /dev/null +++ b/specs/profiles/product-ideation.md @@ -0,0 +1,29 @@ +--- +extension_id: trsl:extension:product-ideation@1.0 +title: Product Ideation +--- + +# 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). diff --git a/specs/profiles/service-with-development-allocation.md b/specs/profiles/service-with-development-allocation.md new file mode 100644 index 0000000..132ed10 --- /dev/null +++ b/specs/profiles/service-with-development-allocation.md @@ -0,0 +1,25 @@ +--- +extension_id: trsl:extension:service-with-development-allocation@1.0 +title: Service With Development Allocation +--- + +# 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`. diff --git a/workplans/TREV-WP-0015-phase-provenance-implementation.md b/workplans/TREV-WP-0015-phase-provenance-implementation.md index 638d3a4..9f2eb10 100644 --- a/workplans/TREV-WP-0015-phase-provenance-implementation.md +++ b/workplans/TREV-WP-0015-phase-provenance-implementation.md @@ -66,7 +66,7 @@ passing with Docker (up from 146). ```task id: TREV-WP-0015-T02 -status: todo +status: done priority: high state_hub_task_id: "8b5ab6ea-fa80-4e08-8733-2faad810962e" ``` @@ -83,6 +83,20 @@ DevelopmentEffortCalculatorConcept.md` (no move). Update `OpenQuestions-WorkingDefaults.md` Q7 to point at the new file rather than contain the policy's content directly. +**Result:** `specs/policies/linear-longstop-v0.md` and all six +`specs/profiles/*.md` files created exactly as scoped, each with the +decided frontmatter shape. `CanonicalMonetizationProfiles.md` §1–§6 +replaced with a linked list pointing at the new files; §7 (cross-profile +summary) and §8 (non-goals) untouched. `OpenQuestions-WorkingDefaults.md` +Q7 now records only the adoption decision, pointing at the policy file +for content. `DevelopmentEffortCalculatorConcept.md` got its +`calculator_id`/`revision`/`title` frontmatter, no move (already +conformed). Checked for stale cross-references before editing — nothing +in the repo links to the removed `CanonicalMonetizationProfiles.md` +section anchors (`grep` confirmed), so no other file needed updating. +Offline suite unaffected (no code reads these doc files' content) — +94 passing, unchanged. + ```task id: TREV-WP-0015-T03 status: todo