target-revenue/specs/TargetDegenerationPolicyResearch.md

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.