target-revenue/workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
TREV-WP-0007	workplan	Degeneration policy research and canonical monetization profiles	infotech	target-revenue	active	claude	infotech	2026-07-29	2026-07-29	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

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)

id: TREV-WP-0007-T02
status: todo
priority: high
human_accept_required: true
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. Awaiting maintainer decision.

Canonical monetization profile catalog

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)

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.