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

Advance WP-0007: degeneration research, profile catalog, canonicalization checklist

Browse source 
T01: specs/TargetDegenerationPolicyResearch.md. Survey finds no
precedent (BSL/FSL/Elastic) implements progress-sensitive degeneration
- TRSL's model is original design. Proposes a candidate v1 formula
(90-day rolling "quiet period" pause on Remission Credit accrual
during active Development Credit periods), resolves the
contributor-diversity input as explicitly not-adopted (no
gaming-resistant signal exists yet), and resolves the
longstop/progress-sensitivity relationship as a hard, unconditional
backstop. Does not recommend v0 vs v1 for T02 - that's the human gate.

T02: recommendation added (confirm v0 for the first pilot cohort, name
v1 as the next iteration) - left todo per the human-accept policy.

T03: specs/CanonicalMonetizationProfiles.md with worked narratives for
all six catalog profiles, plus two new fixtures (product-ideation,
general-consulting), both schema-validated and added to the
parametrized conformance test.

T04: specs/CanonicalizationReviewChecklist.md, an 8-item checklist
layered on the already-implemented promote_extension_canonical()
mechanism (WP-0006-T03) - defines what a reviewer must verify, not a
new promotion mechanism.
This commit is contained in:
tegwick 2026-07-29 22:31:19 +02:00
parent 8894acc584
commit 58a4dd1db2
8 changed files with 658 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

236
specs/TargetDegenerationPolicyResearch.md Normal file
View file

@ -0,0 +1,236 @@
# Target Degeneration Policy Research
Status: Research artifact, Stage 1 (`workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md` T01)
Feeds: `workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md` T02 (human-gated formula decision)
Primary artifacts: `specs/TargetRevenueLicenseConcept.md` §13, `specs/OpenQuestions-WorkingDefaults.md` Q7/Q8, `history/260729-TRSL-PriorArt-Survey.md`
**Scope note:** this document surveys comparative models and proposes a
candidate v1 degeneration formula. It does **not** itself adopt or confirm
any formula as a permanent norm — that is T02's explicit human-gated
decision (`SCOPE.md` §4). This document's job is to make that decision
well-informed, not to make it.
---
## 1. What "degeneration" already means here, and why it needs more work
Per concept §13, `Outstanding Target = max(0, T₀ − C(t) − R(t))`, where
`C(t)` is cumulative Development Credit (real commercial monetization) and
`R(t)` is cumulative Remission Credit (a transparent, non-revenue
reduction under a published policy). The Stage 0 pilot default
(`trsl:policy:linear-longstop-v0`, Working Default Q7) is deliberately
minimal: pure linear time-decay toward a declared Longstop Date, with
**no** sensitivity to whether Development Credit is actively accruing.
Q7 itself flags this as "blocked on research" for two specific inputs
concept §13.2 lists but v0 does not use:
1. **Progress-sensitive pause when material Development Credit arrives.**
2. **Diversity-of-payers factors.**
This document resolves (1) with a concrete proposal, and resolves (2) by
recommending it is *not* adopted for v1 — a decision, not an omission.
---
## 2. Comparative survey
`history/260729-TRSL-PriorArt-Survey.md` already covers BSL/FSL/Elastic
for the license *category* question (delayed open source vs. permanent
restriction); this section re-reads the same precedent specifically for
what it implies about degeneration/trigger *mechanisms*:
| Model | Trigger mechanism | Progress-sensitivity | Relevance to TRSL |
|---|---|---|---|
| **BSL 1.1** | Fixed Change Date, set per release, typically ~4 years | None — pure calendar trigger | Confirms a fixed backstop date is a well-precedented, easily-explained mechanism (concept §13.1's "remain easy to explain and calculate" goal). Provides no guidance on progress-sensitivity since BSL has none. |
| **FSL** | Fixed, per-version, exactly 2 years | None | Same as BSL: simpler than TRSL needs to be, since FSL treats commercial success and commercial failure identically. TRSL's Development-Credit-linked model is already a meaningful design step beyond both precedents, not a refinement of an existing progress-sensitive scheme — there is no direct precedent to copy for the pause mechanism proposed in §4. |
| **Elastic License 2.0** | None (permanent restriction) | N/A | Confirms the negative case: no trigger at all is a valid design (for a different goal), not something TRSL should drift toward by making degeneration so slow or so easily paused that it functions like ELv2's permanent restriction in practice. This is a design constraint on §4's pause mechanism: pausing must never become *indefinite* pausing. |
| **Venture/vesting "cliff + linear" patterns (informal analogy, not a license precedent)** | Time-based linear vesting after a cliff | None, but structurally similar to a linear ramp | Not a license model — cited only as the closest informal analogy for *why* a linear ramp toward a hard date is an easily-understood mechanism to non-lawyers (Phase declarers, Customers). Included for design intuition, not as legal precedent. |
**Finding:** no surveyed license precedent actually implements
progress-sensitive degeneration — TRSL's Development-Credit-linked
Remission Credit model is already outside this precedent set. §4's
proposal is therefore original design work reasoned from concept §13.1's
intended properties, not an adaptation of an existing scheme.
---
## 3. Resolving concept §13.2 input 1: progress-sensitive pause
**Problem statement (concept §13.1):** degeneration should "preserve
incentives during periods of genuine commercial validation" and "react to
insufficient material progress" — v0 does neither; it decays identically
whether the Phase is thriving or abandoned.
**Proposed mechanism — a rolling "quiet period" pause:**
- Define a **quiet period** for a Phase as any point in time `t` such that
no `development-credit` ledger entry has `recognized_at` within the
trailing window `[t − W, t]`, for a published window length `W`
(default proposal: **90 days**).
- Remission Credit accrues under the same linear formula as v0
(`R(t) = T₀ × clamp((t − t₀)/(t_L − t₀), 0, 1)`) **only during quiet
periods**. During any non-quiet period (a `development-credit` entry
landed within the last `W` days), the Remission clock **pauses** — it
neither accrues nor reverses; time spent in a non-quiet period simply
does not count toward the numerator `(t − t₀)`.
- Consistent with concept §13.4 (already settled, not reopened here):
only `development-credit` entries count toward "material progress" for
this purpose. Remission-credit, correction, and checkpoint entries never
affect quiet-period status — otherwise a policy could reduce its own
trigger for pausing itself, a circularity concept §13.4 already
forecloses for operations revenue and which applies equally here.
- **The Longstop Date itself is never extended by pausing.** See §5 below
— this is deliberately a hard backstop, not something the pause
mechanism can push out indefinitely.
**Why a pause, not a slowdown or reversal:** a proportional slowdown
(e.g., halving the accrual rate during active periods) is harder to
explain and calculate (violates concept §13.1's simplicity goal) for
marginal benefit over an on/off pause, and a *reversal* of already-accrued
Remission Credit would violate the "transparent, non-gameable" property
(PRD NFR-5) by creating a path where genuine, already-published Remission
Credit could later disappear — the pure fold's monotonicity (Remission
Credit never decreases without an explicit, visible correction entry) is
worth preserving.
**Gaming resistance:** a Licensor cannot indefinitely suspend degeneration
by manufacturing tiny, infrequent Development Credit entries, because (a)
each entry must correspond to a real Commercial Entitlement transaction
recorded in the Target Ledger with an evidence reference (TSD §3.2), which
is auditable, and (b) the absolute Longstop Date (§5) still fires
regardless of how many quiet-period pauses occurred — the worst case for a
Licensor gaming small entries is "no Remission Credit accrues before
Longstop," not "conversion never happens."
---
## 4. Resolving concept §13.2 input 2: contributor diversity factors
**Recommendation: do not adopt for v1.** Reasoning, not silent omission:
- There is no reliable, ledger-derivable signal for "diversity of
commercial contributors" that resists trivial gaming — a single
Licensor-controlled entity can create arbitrarily many nominally
distinct Commercial Entitlement holders (shell companies, related
parties, multiple email addresses for the same actual payer) with no
mechanism in this framework to detect or prevent it. Adopting a factor
that's this easy to manufacture would violate PRD NFR-5 (resistance to
manipulation) more than it would deliver the intended signal.
- Building a real identity/relatedness model to make this signal
trustworthy is a substantial project of its own (KYC-adjacent, with its
own data-protection and cost implications) — wildly disproportionate to
what a Stage 1 pilot-rollout formula needs, and not something this
research task should smuggle in as a side effect of picking a
degeneration formula.
- No pilot data exists yet (`workplans/TREV-WP-0008-governance-and-pilot-rollout.md`
has not run) to know whether diversity even correlates with the thing
the framework actually cares about (genuine commercial validation) in
practice, as opposed to being a plausible-sounding proxy.
**This is deferred, not rejected** — revisit once real pilot Phases
produce actual multi-payer data and a concrete, gaming-resistant
diversity signal can be designed against real cases rather than
speculatively.
---
## 5. Resolving concept §13.3: relationship between progress-sensitive degeneration and the fixed Longstop
Concept §13.3 leaves this explicitly open ("the detailed relationship...
remains an open design question"). **Proposed resolution: the Longstop is
an absolute backstop, never itself affected by pausing.**
- The pause mechanism in §3 only affects the *rate* at which the linear
schedule's numerator `(t − t₀)` accumulates before the Longstop.
- The Longstop Date `t_L` itself is fixed at Phase declaration (Working
Default Q8, unchanged) and is **never extended, paused, or recalculated**
by any amount of quiet-period pausing.
- Consequence: heavy pausing (frequent Development Credit, i.e., strong
commercial validation) means **less** Remission Credit accrues before
`t_L`, but at `t_L` itself, the policy still remits
`max(0, T₀ − C(t_L))` in full — full remission at Longstop is
unconditional, exactly as v0 already guarantees, preserving concept
§13.1's "provide an eventual path to conversion even when the initial
product hypothesis fails" property without exception.
- This is a clean, easy-to-explain rule: *"pausing changes how much you
give away for free before the deadline; it never changes the deadline
itself."*
---
## 6. Candidate v1 formula: `trsl:policy:progress-paused-longstop-v1`
Combining §3 and §5, formally:
```
Let:
T0 = phase.initial_target.amount
t0 = Phase activation timestamp
tL = phase.longstop_at
W = quiet-period window (proposed default: 90 days)
D = the set of development-credit ledger entries for the Phase
quiet(t) = true iff no entry in D has recognized_at in [t - W, t]
effective_elapsed(t) = the total duration, summed over [t0, t],
of subintervals where quiet(t) is true
(i.e., "clock time spent in a quiet period")
R(t) = T0 * clamp(effective_elapsed(t) / (tL - t0), 0, 1) for t < tL
R(tL) = T0 - C(tL) [full remission of whatever remains, unconditionally]
```
**Worked example** (illustrative, not from real data): `T0 = 100,000
USD`, `t0` = Phase activation, `tL = t0 + 365 days`, `W = 90 days`.
- Days 0–120: no Development Credit lands. All 120 days are quiet.
`effective_elapsed = 120` days. `R = 100,000 × (120/365) ≈ 32,877`.
- Day 121: a `development-credit` entry for 5,000 lands. From day 121
through day 210 (121 + 90), the Phase is in a non-quiet period —
`effective_elapsed` does not advance during these 89 days, so R stays
frozen at ≈32,877 even though wall-clock time passes.
- Day 211 onward: quiet again (assuming no further credits), so
`effective_elapsed` resumes advancing from day 211.
- Day 365 (`tL`): regardless of how much pausing occurred,
`R(tL) = T0 − C(tL)` — full remission of whatever's left, unconditionally.
**Difference from v0:** v0 would have accrued Remission Credit steadily
across the entire 365-day period with no regard to the day-121 Development
Credit; v1 rewards that Development Credit by pausing degeneration for the
following 90 days, while still guaranteeing the same unconditional
full-remission outcome at the Longstop.
---
## 7. v0 vs. candidate v1 — comparison for T02's decision
| | `linear-longstop-v0` (current pilot default) | `progress-paused-longstop-v1` (this document's candidate) |
|---|---|---|
| Complexity | Lower — one clamp formula, no window state | Higher — requires tracking a rolling quiet-period window per Phase |
| Matches concept §13.1's "preserve incentives during genuine validation" goal | No — decays identically regardless of Development Credit | Yes — directly responsive to Development Credit |
| Matches "avoid manipulation through unrelated revenue" | Yes (trivially, since it ignores everything) | Yes, if evidence-reference auditing catches manufactured entries (§3) — a materially stronger claim, not a weaker one, but relies on evidence quality |
| Implementation cost for WP-0006's hosted Metrics/Ledger components | None (already implemented) | New: hosted service must compute rolling-window quiet-period state, not just a cumulative sum — a genuinely new calculation, not a formula tweak |
| Pilot-readiness | Already implemented and tested (WP-0002) | Not yet implemented — would require new schema/fold work before T02's acceptance could be operationalized |
**This document does not recommend one over the other** — that is T02's
call, informed by whether the added implementation cost (a new,
untested calculation the hosted service would need before any pilot Phase
could actually use it) is worth the incentive-alignment improvement, given
`workplans/TREV-WP-0008-governance-and-pilot-rollout.md`'s timeline
pressure to launch pilots soon. A reasonable middle path T02 may want to
consider: **confirm `linear-longstop-v0` as the v1 norm for the first
pilot cohort, with `progress-paused-longstop-v1` explicitly named as the
next planned iteration** once real Development Credit data exists to
validate the window length (`W = 90 days` above is a reasoned default,
not an empirically-derived one).
---
## 8. Non-goals
- Adopting any formula as final — T02's explicit human-gated decision.
- Building the hosted-service implementation of either formula — a
follow-on `workplans/TREV-WP-0006-trust-service-implementation.md`-style
task if T02 selects the v1 candidate, not scoped here.
- Resolving contributor-diversity factors — explicitly deferred (§4), not
a gap to backfill under schedule pressure.