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