Advance WP-0007: degeneration research, profile catalog, canonicalization checklist

T01: specs/TargetDegenerationPolicyResearch.md. Survey finds no
precedent (BSL/FSL/Elastic) implements progress-sensitive degeneration
- TRSL's model is original design. Proposes a candidate v1 formula
(90-day rolling "quiet period" pause on Remission Credit accrual
during active Development Credit periods), resolves the
contributor-diversity input as explicitly not-adopted (no
gaming-resistant signal exists yet), and resolves the
longstop/progress-sensitivity relationship as a hard, unconditional
backstop. Does not recommend v0 vs v1 for T02 - that's the human gate.

T02: recommendation added (confirm v0 for the first pilot cohort, name
v1 as the next iteration) - left todo per the human-accept policy.

T03: specs/CanonicalMonetizationProfiles.md with worked narratives for
all six catalog profiles, plus two new fixtures (product-ideation,
general-consulting), both schema-validated and added to the
parametrized conformance test.

T04: specs/CanonicalizationReviewChecklist.md, an 8-item checklist
layered on the already-implemented promote_extension_canonical()
mechanism (WP-0006-T03) - defines what a reviewer must verify, not a
new promotion mechanism.

README.md

@@ -79,7 +79,7 @@ The concept's §13 now defines a **Global Contingency Share Determination Rule**
 | [TREV-WP-0004](workplans/TREV-WP-0004-global-jurisdiction-research.md) | Global jurisdictional research backing the License/CUA candidates — **finished**, T10 synthesis accepted 2026-07-29 with alpha/beta working defaults (full legal review deferred until out of beta — see `SCOPE.md` §1) |
 | [TREV-WP-0005](workplans/TREV-WP-0005-enforcement-network-research.md) | Enforcement Network legal feasibility research — **finished**, T10 synthesis accepted 2026-07-29 on the same alpha/beta basis (Japan's Article 12 risk remains explicitly unresolved) |
 | [TREV-WP-0006](workplans/TREV-WP-0006-trust-service-implementation.md) | Hosted Trust Service reference implementation (PRD Phase 4b) — **finished**, all 9 tasks done (Postgres-backed registries/ledger/metrics/attestation/breach-record, ADR-0002 accepted, onboarding CLI, hosted conformance suite) |
-| [TREV-WP-0007](workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md) | Degeneration policy + canonical monetization profile catalog — active, not yet started |
+| [TREV-WP-0007](workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md) | Degeneration policy + canonical monetization profile catalog — active; T01 (degeneration research), T03 (profile catalog), T04 (canonicalization checklist) done; T02 (formula decision) ready for review, awaiting maintainer sign-off |
 | [TREV-WP-0008](workplans/TREV-WP-0008-governance-and-pilot-rollout.md) | Governance formalization + pilot rollout across `coulomb-loop`/`net-kingdom`/`helix-forge`/`railiance-*` — active, not yet started; real Phase declarations gated behind T05 |
 
 Hub index: [`WORK-RECORDS.md`](WORK-RECORDS.md) · brief: [`.custodian-brief.md`](.custodian-brief.md)

examples/phase-001/extensions/general-consulting.json

@@ -0,0 +1,24 @@
+{
+  "id": "trsl:extension:general-consulting",
+  "version": "1.0",
+  "value": {
+    "description": "General technical advisory, architecture review, or strategy consulting engaged alongside the Software but not specific to building or delivering any governed Milestone Release."
+  },
+  "pricing": {
+    "method": "time-and-materials or retainer, per consulting agreement"
+  },
+  "allocation": {
+    "rule": "Development allocation is 0% by definition for this profile. General consulting is, by its own scope, not a development contribution to any specific Phase; a payer or licensor who wants engagement work to count toward a Phase target must use a profile scoped to that Phase (e.g. development-license, service-with-development-allocation), not this one.",
+    "default_rate": 0.0
+  },
+  "recognition": {
+    "event": "payment-settled"
+  },
+  "reversal": {
+    "rule": "Refunds and chargebacks generate a compensating credit-reversal entry for the reversed amount; since default_rate is always 0%, this affects non-target revenue bookkeeping only, never a Phase's Outstanding Target."
+  },
+  "evidence": {
+    "requirement": "Settled payment reference at minimum (working default Q10 tier E1)."
+  },
+  "status": "registered"
+}

examples/phase-001/extensions/product-ideation.json

@@ -0,0 +1,24 @@
+{
+  "id": "trsl:extension:product-ideation",
+  "version": "1.0",
+  "value": {
+    "description": "Paid discovery, requirements, or prototyping work exploring a possible future product direction, not yet committed to a governed Milestone Release."
+  },
+  "pricing": {
+    "method": "fixed-fee or time-and-materials, per ideation engagement agreement"
+  },
+  "allocation": {
+    "rule": "Development allocation defaults to 0%, since ideation work has not yet been incorporated into any Phase's Milestone Release. If and when ideation output is adopted into a governed Milestone Release, the licensor and payer may explicitly declare a development_allocation fraction at that later time, recorded as a new ledger entry against the adopting Phase — never inferred automatically from the original ideation payment.",
+    "default_rate": 0.0
+  },
+  "recognition": {
+    "event": "payment-settled"
+  },
+  "reversal": {
+    "rule": "Refunds and chargebacks generate a compensating credit-reversal entry for the reversed amount, against whichever Phase (if any) the allocation was declared against."
+  },
+  "evidence": {
+    "requirement": "Settled payment reference; the ideation engagement's scope statement recommended, and required whenever a nonzero allocation is later claimed against an adopting Phase."
+  },
+  "status": "registered"
+}

specs/CanonicalMonetizationProfiles.md

@@ -0,0 +1,193 @@
+# Canonical Monetization Profile Catalog
+
+Status: Draft v0.1
+Date: 2026-07-29
+Workplan: `workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md` T03
+Primary artifacts: `specs/MonetizationExtensionSpecification.md` §5, `schemas/extension_contract.schema.json`, `examples/phase-001/extensions/`
+
+Full worked pricing narratives and examples for the six canonical-candidate
+Monetization Extensions already named in
+`specs/MonetizationExtensionSpecification.md` §5. All six now have a
+fixture in `examples/phase-001/extensions/`, validated against
+`schemas/extension_contract.schema.json`. This document does not
+canonicalize any profile — promotion from `registered` to `canonical` is a
+separate, documented governance action
+(`workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md` T04).
+
+---
+
+## 1. `development-license`
+
+**What the payer receives:** commercial-use rights and early commercial
+access to the protected, pre-conversion Milestone Release — the direct
+purchase of a Commercial Entitlement under the Commercial Use Agreement.
+
+**Worked narrative:** a company wants to run the governed software
+commercially before its Conversion Event. It pays a fixed development fee
+under the CUA's Exhibit A. Once the payment settles (processor
+confirmation, not invoice date — Rule 4), 100% of the net amount (after
+tax, refunds, chargebacks) becomes Development Credit for the Phase named
+in the CUA. This is the simplest and most direct profile: the payment's
+entire purpose is buying into the protected development, so its entire
+net value counts.
+
+**Default `development_allocation`:** 100%.
+
+**Fixture:** `examples/phase-001/extensions/development-license.json`.
+
+---
+
+## 2. `cost-plus-operations`
+
+**What the payer receives:** a hosted, operated instance of the software —
+compute, storage, networking, monitoring, backup, incident response —
+priced at cost plus a surcharge (default 50%).
+
+**Worked narrative:** a customer doesn't want to self-host; they pay for a
+managed instance. The bulk of this price recovers real operating cost, not
+development investment — per concept §13.4 (already settled), operations
+revenue must not be conflated with Development Credit or used to pause
+degeneration. By default, **none** of this revenue counts toward the
+Phase's Outstanding Target. A Phase may explicitly declare a nonzero
+allocation specifically on the surcharge portion (the profit margin above
+cost) if the Licensor and Customer agree the hosting relationship itself
+also functions as a development investment — but this must be an explicit,
+recorded declaration, never inferred from the existence of a hosting fee.
+
+**Default `development_allocation`:** 0% (declarable nonzero on the
+surcharge only, by explicit agreement).
+
+**Fixture:** `examples/phase-001/extensions/cost-plus-operations.json`.
+
+---
+
+## 3. `phase-sponsorship`
+
+**What the payer receives:** no direct product access at all in the
+minimal case — this profile is for financial support explicitly directed
+at funding a named Phase's development, structurally closer to a grant or
+sponsorship than a purchase.
+
+**Worked narrative:** a foundation, a downstream adopter, or an interested
+party wants to fund a specific Phase's completion without necessarily
+receiving a Commercial Entitlement themselves (though nothing prevents
+combining this with one). Because there is no natural default split (unlike
+a hosting fee, a sponsorship payment has no "cost" component to separate
+from "development" component), the sponsoring party and Licensor must
+explicitly declare what fraction of the sponsorship is development
+allocation at the time it's recorded. **Unrestricted general project
+sponsorship — support for the project as a whole, not any one Phase — is
+never assigned to a Phase by default**, since assigning it silently would
+let a Licensor manufacture Development Credit for a struggling Phase by
+recharacterizing general goodwill funding after the fact.
+
+**Default `development_allocation`:** explicitly declared per transaction,
+no numeric default.
+
+**Fixture:** `examples/phase-001/extensions/phase-sponsorship.json`.
+
+---
+
+## 4. `service-with-development-allocation`
+
+**What the payer receives:** installation, migration, configuration,
+integration, customization, support, or training services.
+
+**Worked narrative:** a customer pays for a services engagement — say, a
+custom integration. Most of this work is customer-specific and has no
+bearing on the governed Milestone Release's own development; it defaults
+to 0% allocation. If, during the engagement, a genuinely reusable
+component is built and actually incorporated into the governed Milestone
+Release (not merely "could theoretically be reused" — actually merged),
+the Licensor may split out and declare that reusable portion's value as
+Development Credit, with a statement identifying the specific reusable
+deliverable. Customer-specific configuration itself is **never** allocated,
+regardless of how the engagement is billed.
+
+**Default `development_allocation`:** 0% (explicit split when a reusable
+deliverable is actually incorporated).
+
+**Fixture:** `examples/phase-001/extensions/service-with-development-allocation.json`.
+
+---
+
+## 5. `product-ideation`
+
+**What the payer receives:** paid discovery, requirements-gathering, or
+prototyping work exploring a *possible* future product direction — work
+that has not yet been committed to any governed Milestone Release, and may
+never be.
+
+**Worked narrative:** a company pays for exploratory work on an idea that
+might become a future Phase, or might not. At the time of payment, there is
+no Phase to allocate anything toward — this is the key distinction from
+`service-with-development-allocation`, where a Phase already exists and is
+being actively developed. Default allocation is 0%. If the ideation output
+is later adopted into an actual governed Milestone Release, the allocation
+decision is made **at that later time**, against the adopting Phase, as a
+new declaration — never inferred automatically from the original,
+pre-Phase-existence payment. This ordering (Phase must exist before
+allocation can be declared against it) prevents retroactively
+manufacturing Development Credit for a Phase using unrelated earlier
+payments.
+
+**Default `development_allocation`:** 0% (or explicitly declared later,
+against a specific adopting Phase, once one exists).
+
+**Fixture:** `examples/phase-001/extensions/product-ideation.json` (new).
+
+---
+
+## 6. `general-consulting`
+
+**What the payer receives:** general technical advisory, architecture
+review, or strategy consulting engaged alongside the Software, but not
+scoped to building or delivering any specific governed Milestone Release.
+
+**Worked narrative:** a company retains the Licensor's team for broad
+technical guidance unrelated to any one Phase's deliverable — the
+opposite end of the spectrum from `development-license`. This profile's
+`development_allocation` is 0% **by definition**, not merely by default:
+its entire scope is defined as work that isn't a development contribution
+to any specific Phase. A payer who wants engagement work to actually count
+toward a Phase target must use a Phase-scoped profile instead
+(`development-license`, `service-with-development-allocation`) — choosing
+`general-consulting` is itself the declaration that no allocation is
+intended.
+
+**Default `development_allocation`:** 0% (fixed, not merely defaulted).
+
+**Fixture:** `examples/phase-001/extensions/general-consulting.json` (new).
+
+---
+
+## 7. Cross-profile summary
+
+| Profile | Default allocation | Allocation adjustable? | Phase must pre-exist? |
+|---|---:|---|---|
+| `development-license` | 100% | No (fixed at 100% of net) | Yes |
+| `cost-plus-operations` | 0% | Yes, declarable on surcharge only | Yes |
+| `phase-sponsorship` | none (explicit) | Required every transaction | Yes |
+| `service-with-development-allocation` | 0% | Yes, on actually-incorporated reusable work | Yes |
+| `product-ideation` | 0% | Yes, but only at later adoption time, against the adopting Phase | No at payment time; yes at later allocation |
+| `general-consulting` | 0% | No — fixed by definition | N/A (never allocated) |
+
+All six share the same reversal pattern (a compensating `credit-reversal`
+ledger entry for refunds/chargebacks, per TSD §3.2 Rule 8) and the same
+recognition event (`payment-settled`, Working Default Q10) — variation
+across profiles is entirely in the allocation rule, consistent with
+`specs/MonetizationExtensionSpecification.md` §4's non-redefinition
+constraint (an extension may only ever affect `development_allocation`,
+never the core terms themselves).
+
+---
+
+## 8. Non-goals
+
+- Canonicalizing any of the six profiles (`registered` → `canonical`) —
+  that is T04's checklist and a separate governance action.
+- Inventing a seventh profile — this document catalogs the six already
+  named in `specs/MonetizationExtensionSpecification.md` §5, it does not
+  expand that set.
+- Resolving the degeneration policy formula — `specs/TargetDegenerationPolicyResearch.md`
+  (T01) and T02's human gate, a separate and unrelated open question.

specs/CanonicalizationReviewChecklist.md

@@ -0,0 +1,108 @@
+# Canonicalization Review Checklist
+
+Status: Draft v0.1
+Date: 2026-07-29
+Workplan: `workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md` T04
+Primary artifacts: `specs/MonetizationExtensionSpecification.md` §4, `specs/CanonicalMonetizationProfiles.md`, `src/target_revenue/registry.py` (`promote_extension_canonical`)
+
+**Scope note:** this is the short, profile-level checklist
+`specs/MonetizationExtensionSpecification.md` §4 says must exist before
+any of the six catalog profiles can be promoted from `registered` to
+`canonical`. It is **not** a general governance framework — that's
+`workplans/TREV-WP-0008-governance-and-pilot-rollout.md` T01
+(`specs/TRSL-Governance.md`, extension canonicalization review process,
+dispute/conflict-of-interest handling at the organization level). This
+document answers one narrower question: *what does a reviewer actually
+check before canonicalizing one of these six profiles?*
+
+---
+
+## 1. Mechanism (already built, not new here)
+
+Canonicalization is performed by
+`target_revenue.registry.promote_extension_canonical(conn, extension_id,
+version, approved_by)` (WP-0006-T03), which calls the database's
+`set_extension_status()` function — the only way to change an extension's
+status, since the application role has no `UPDATE` grant on `extensions`
+at all (`migrations/0001_registries.sql`). This checklist exists so that
+whoever calls that function (the `approved_by` recorded) has actually
+verified the items below first — the system enforces *who* performed the
+promotion and *that it's attributable*; it does not and cannot enforce
+*that the reviewer actually checked anything*. That's what this document
+is for.
+
+## 2. Checklist
+
+A profile is ready for `promote_extension_canonical` once all of the
+following are true:
+
+1. **Already `registered` and passing conformance.** Schema-valid
+   (`validation.validate_extension_contract`) and the core-term
+   non-redefinition check passes — a prerequisite, not sufficient alone,
+   since that check is a pattern-based heuristic
+   (`validation.check_extension_core_term_redefinition`'s own docstring),
+   not an exhaustive semantic review.
+2. **A human has read the `allocation.rule` text itself**, not just
+   confirmed the heuristic check passed, and confirms it does not redefine
+   `Phase`, `Milestone Release`, `Initial Target`, `Development Credit`,
+   `Remission Credit`, `Outstanding Target`, `Conversion Event`, or `Future
+   License` in substance, even if it happens not to trip the pattern-based
+   check's specific wording triggers.
+3. **Internal consistency**: `value.description`, `pricing.method`, and
+   `allocation.rule` tell the same story about what's being sold and what
+   counts toward the target. A profile whose narrative description implies
+   one thing and whose allocation rule computes another is not ready,
+   regardless of schema validity.
+4. **`reversal.rule` covers the realistic refund/chargeback path** for
+   this profile's actual pricing model (e.g., a cost-plus profile's
+   reversal rule should address partial refunds proportional to the cost
+   basis, not only full reversal).
+5. **`evidence.requirement` is proportionate** to the profile's typical
+   transaction size and the allocation it can produce — per
+   `specs/OpenQuestions-WorkingDefaults.md` Q10's evidence tiers (E0/E1/E2):
+   a profile capable of generating a large Development Credit per
+   transaction should not have only an E0-level evidence requirement.
+6. **At least one full worked narrative exists**, not only the bare JSON
+   fixture — `specs/CanonicalMonetizationProfiles.md` §1–§6 satisfies this
+   for all six catalog profiles as of this document.
+7. **No known open legal/compliance flag specific to this profile's
+   structure.** This is a sanity check, not a legal opinion: does the
+   pricing/allocation shape resemble a regulated financial instrument
+   (e.g., a sponsorship structured with an implied return expectation
+   could resemble a security) closely enough to warrant specialist input
+   before recommending it broadly? If yes, canonicalization should wait for
+   that input; if no obvious resemblance exists, this item is satisfied by
+   the reviewer's own note that they considered it.
+8. **Sign-off is recorded.** `promote_extension_canonical`'s `approved_by`
+   parameter, plus a one-line note (in this document, a workplan Result, or
+   a dated `history/` entry) of who reviewed against this checklist and
+   when — the mechanism records *that* an approval happened; a human
+   record should say *why* it passed.
+
+## 3. Applying the checklist to the six catalog profiles now
+
+This document does not itself canonicalize anything — recording the
+checklist is T04's job; running it against a real profile and deciding to
+promote is a separate governance action (item 8 above), appropriately
+left to whoever owns that decision (plausibly folded into
+`workplans/TREV-WP-0008-governance-and-pilot-rollout.md` T01's broader
+governance work, or done independently once a first real pilot Phase
+actually wants to declare `canonical` status for one). A quick read
+against the six profiles in `specs/CanonicalMonetizationProfiles.md`
+suggests `development-license` and `general-consulting` are the two
+simplest, lowest-ambiguity candidates (fixed 100%/0% allocation, no
+per-transaction declaration required) if a first canonicalization pass is
+wanted before a full governance review cadence exists — but that
+recommendation is exactly the kind of judgment call item 7/8 above
+require a named human to actually make, not something this checklist
+resolves on its own.
+
+## 4. Non-goals
+
+- Performing any canonicalization — a separate, attributable governance
+  action per §1–§2 above.
+- Organization-wide governance (Licensor identity, dispute process,
+  conflict-of-interest handling) — `workplans/TREV-WP-0008-governance-and-pilot-rollout.md` T01.
+- Changing `promote_extension_canonical`'s implementation — already built
+  and tested in WP-0006-T03; this document is a human-process checklist
+  layered on top of it, not a code change.

specs/TargetDegenerationPolicyResearch.md

@@ -0,0 +1,236 @@
+# 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.

tests/test_extension_conformance.py

@@ -13,6 +13,8 @@ from target_revenue import validation
         "cost-plus-operations",
         "phase-sponsorship",
         "service-with-development-allocation",
+        "product-ideation",
+        "general-consulting",
     ],
 )
 def test_canonical_stage0_extensions_are_conformant(name):

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

@@ -32,7 +32,7 @@ this workplan was skipped.
 
 ```task
 id: TREV-WP-0007-T01
-status: todo
+status: done
 priority: high
 state_hub_task_id: "6b99a020-6892-4c79-a18d-88ffa1f8d750"
 ```
@@ -45,6 +45,27 @@ 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
@@ -62,11 +83,26 @@ 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
 
 ```task
 id: TREV-WP-0007-T03
-status: todo
+status: done
 priority: high
 state_hub_task_id: "063dcb0a-69b1-44a5-b95f-093b306b7040"
 ```
@@ -80,11 +116,26 @@ named in `specs/MonetizationExtensionSpecification.md` §5
 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: todo
+status: done
 priority: medium
 state_hub_task_id: "7bbcdb3e-403c-49be-acc2-eba9e03926b9"
 ```
@@ -96,3 +147,19 @@ 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.