---
id: TREV-WP-0007
type: workplan
title: "Degeneration policy research and canonical monetization profiles"
domain: infotech
repo: target-revenue
status: finished
owner: claude
topic_slug: infotech
created: "2026-07-29"
updated: "2026-07-29"
state_hub_workstream_id: "5bfbe5d1-5150-41ff-bc6b-c4f0e2021fa6"
---

# Degeneration policy research and canonical monetization profiles

Finalizes two PRD deliverables that pilot Phases (`workplans/TREV-WP-0008-governance-and-pilot-rollout.md`)
cannot responsibly launch without: a degeneration policy beyond the
placeholder `trsl:policy:linear-longstop-v0`, and a full worked canonical
monetization profile catalog beyond the six one-line defaults already in
`specs/MonetizationExtensionSpecification.md` §5.

**Why this blocks pilot rollout:** every Phase Manifest requires a
`degeneration_policy` reference (`specs/PhaseManifestSpecification.md`,
Required field) and, in practice, at least one Monetization Extension.
Launching real pilot Phases on an admittedly-provisional pilot policy and
one-line profile defaults is a real business decision, not a technical
blocker — but it should be a *chosen* risk, not an accidental one because
this workplan was skipped.

## Degeneration policy research

```task
id: TREV-WP-0007-T01
status: done
priority: high
state_hub_task_id: "6b99a020-6892-4c79-a18d-88ffa1f8d750"
```

Produce `specs/TargetDegenerationPolicyResearch.md`: survey comparative
models (BSL/FSL-style fixed longstop vs. progress-sensitive decay vs.
hybrid — `history/260729-TRSL-PriorArt-Survey.md` already has partial
groundwork), and resolve concept §13.2's open inputs (progress-sensitive
pause on material Development Credit, contributor diversity factors) that
`trsl:policy:linear-longstop-v0` deliberately left unresolved per
`specs/OpenQuestions-WorkingDefaults.md` Q7.

**Result:** `specs/TargetDegenerationPolicyResearch.md` produced. Survey
finding: none of BSL/FSL/Elastic actually implement progress-sensitive
degeneration — TRSL's Development-Credit-linked model is original design
work, not an adaptation of precedent. Input 1 (progress-sensitive pause)
resolved with a concrete proposal: a rolling 90-day "quiet period" pause —
Remission Credit accrues only during periods with no recent
`development-credit` entry, and freezes (not reverses) during active
periods. Input 2 (contributor diversity) resolved as **not adopted for
v1** — no ledger-derivable diversity signal resists trivial gaming
(shell/related-party entitlement holders), and no pilot data yet exists to
validate a signal empirically; explicitly deferred, not silently dropped.
Also resolves concept §13.3's open relationship question: the Longstop
Date is an absolute backstop, never itself extended or paused by the
quiet-period mechanism — pausing only changes how much remits *before*
Longstop, never *whether* full remission happens *at* Longstop. Proposes
candidate `trsl:policy:progress-paused-longstop-v1` with worked numeric
example, and an explicit v0-vs-v1 comparison table (implementation cost:
v1 requires new hosted rolling-window computation, not yet built) for T02
to weigh — deliberately does not recommend one over the other, since that
promotion decision belongs to T02's human gate.

## Degeneration formula decision (human gate)

```task
id: TREV-WP-0007-T02
status: done
priority: high
human_accept_required: true
human_accepted_by: Bernd
human_accepted_at: "2026-07-29"
state_hub_task_id: "44e396e9-7ab4-4952-89dc-880461dda2e1"
```

Using T01, propose either: (a) confirming `linear-longstop-v0` as the
adopted v1 formula (not merely a Stage 0 pilot default), or (b) a
refined/replacement formula. Either way this promotes a working default to
permanent-enough-to-launch-pilots-on status, which per `SCOPE.md` §4
requires explicit human accept — agents may prepare the recommendation and
leave this `todo`.

**Status: ready for review, not done.** Recommendation per T01 §7's
middle path: **confirm `linear-longstop-v0` as the adopted v1 norm for
the first pilot cohort**, and record `progress-paused-longstop-v1`
(T01 §6) as the named next iteration rather than adopting it now. Reasoning:
v0 is already implemented, tested (WP-0002/WP-0006), and pilot-ready today;
v1 requires new, untested hosted-service computation (a rolling
quiet-period window, not a formula tweak) that would sit on
`workplans/TREV-WP-0008-governance-and-pilot-rollout.md`'s critical path
for no proven benefit yet — the incentive-alignment improvement v1 offers
is real but currently unvalidated by any actual pilot data. Confirming v0
now does not foreclose v1: the policy id is versioned
(`trsl:policy:<slug>@<version>`), so a future Phase can adopt v1 once
implemented without touching any Phase already running under v0.

**Accepted 2026-07-29 by the maintainer (Bernd): confirmed
`trsl:policy:linear-longstop-v0` as the adopted v1 norm** for the first
pilot cohort, per this document's recommendation.
`progress-paused-longstop-v1` (T01 §6) remains the named next iteration,
to be revisited once real pilot Development Credit data exists to
validate the proposed 90-day window — not adopted now, and not required
before `workplans/TREV-WP-0008-governance-and-pilot-rollout.md`'s pilot
Phases can proceed.

## Canonical monetization profile catalog

```task
id: TREV-WP-0007-T03
status: done
priority: high
state_hub_task_id: "063dcb0a-69b1-44a5-b95f-093b306b7040"
```

Produce `specs/CanonicalMonetizationProfiles.md`: full worked pricing
narratives and examples for the six canonical-candidate profiles already
named in `specs/MonetizationExtensionSpecification.md` §5
(`development-license`, `cost-plus-operations`, `phase-sponsorship`,
`service-with-development-allocation`, `product-ideation`,
`general-consulting`), plus fixture files for the two not yet
fixture-backed (`product-ideation`, `general-consulting`), following the
pattern already established in `examples/phase-001/extensions/`.

**Result:** `specs/CanonicalMonetizationProfiles.md` produced with a
worked narrative per profile plus a cross-profile summary table (default
allocation, whether/when it's adjustable, whether a Phase must pre-exist
before allocation can be declared). New fixtures
`examples/phase-001/extensions/product-ideation.json` and
`.../general-consulting.json`, both schema-validated. Key distinction
worked out between the two new profiles: `product-ideation` may acquire a
nonzero allocation *later*, against a Phase that didn't yet exist at
payment time (declared only once adoption actually happens, never
inferred retroactively); `general-consulting` is 0% *by definition*, not
merely by default — choosing that profile is itself the declaration that
no allocation is intended. Added both to
`tests/test_extension_conformance.py`'s parametrized conformance test
(now 6 profiles, 11 tests total in that file, all passing).

## Canonicalization review process (light)

```task
id: TREV-WP-0007-T04
status: done
priority: medium
state_hub_task_id: "7bbcdb3e-403c-49be-acc2-eba9e03926b9"
```

Per `specs/MonetizationExtensionSpecification.md` §4, promoting an
extension from `registered` to `canonical` "is a documented human/
governance action, never automated" — but no document yet describes what
that review actually checks. Produce a short (not a full governance
framework — that's `workplans/TREV-WP-0008-governance-and-pilot-rollout.md`
T01) checklist for canonicalizing the six profiles in this workplan,
sufficient to promote them from `registered` to `canonical` status.

**Result:** `specs/CanonicalizationReviewChecklist.md` produced. An
8-item checklist (already-registered/conformant; human re-read of the
allocation rule beyond the heuristic check; internal consistency between
description/pricing/allocation; realistic reversal coverage; proportionate
evidence tier per Working Default Q10; a full worked narrative existing;
a sanity check for regulated-financial-instrument resemblance; recorded
sign-off) layered on top of the already-implemented mechanism
(`registry.promote_extension_canonical`, WP-0006-T03) — this document does
not change that mechanism, it defines what a reviewer must verify before
calling it. Does not itself canonicalize any profile (a separate,
attributable governance action) but flags `development-license` and
`general-consulting` as the two structurally simplest candidates if a
first canonicalization pass is wanted before WP-0008-T01's fuller
governance cadence exists — offered as an observation, not a decision this
document makes on its own.