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.