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

Implement WP-0015-T02: extract policy/profile spec files

Browse source 
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:
tegwick 2026-08-03 20:49:22 +02:00
parent d8aa9b3f96
commit 1fb7212e2d
12 changed files with 237 additions and 152 deletions
Download patch file Download diff file Expand all files Collapse all files

4
README.md
View file

@ -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)

153
specs/CanonicalMonetizationProfiles.md
View file

@ -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).
---

6
specs/DevelopmentEffortCalculatorConcept.md
View file

@ -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

10
specs/OpenQuestions-WorkingDefaults.md
View file

@ -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.
---

43
specs/policies/linear-longstop-v0.md Normal file
View file

@ -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.

26
specs/profiles/cost-plus-operations.md Normal file
View file

@ -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`.

23
specs/profiles/development-license.md Normal file
View file

@ -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`.

25
specs/profiles/general-consulting.md Normal file
View file

@ -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).

29
specs/profiles/phase-sponsorship.md Normal file
View file

@ -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`.

29
specs/profiles/product-ideation.md Normal file
View file

@ -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).

25
specs/profiles/service-with-development-allocation.md Normal file
View file

@ -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`.

16
workplans/TREV-WP-0015-phase-provenance-implementation.md
View file

@ -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