diff --git a/README.md b/README.md index eab8845..215018b 100644 --- a/README.md +++ b/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) diff --git a/examples/phase-001/extensions/general-consulting.json b/examples/phase-001/extensions/general-consulting.json new file mode 100644 index 0000000..1cf28b9 --- /dev/null +++ b/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" +} diff --git a/examples/phase-001/extensions/product-ideation.json b/examples/phase-001/extensions/product-ideation.json new file mode 100644 index 0000000..468f6ec --- /dev/null +++ b/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" +} diff --git a/specs/CanonicalMonetizationProfiles.md b/specs/CanonicalMonetizationProfiles.md new file mode 100644 index 0000000..0b9a579 --- /dev/null +++ b/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. diff --git a/specs/CanonicalizationReviewChecklist.md b/specs/CanonicalizationReviewChecklist.md new file mode 100644 index 0000000..ae920c6 --- /dev/null +++ b/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. diff --git a/specs/TargetDegenerationPolicyResearch.md b/specs/TargetDegenerationPolicyResearch.md new file mode 100644 index 0000000..50ed379 --- /dev/null +++ b/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. diff --git a/tests/test_extension_conformance.py b/tests/test_extension_conformance.py index e886dbf..311c95e 100644 --- a/tests/test_extension_conformance.py +++ b/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): diff --git a/workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md b/workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md index def596d..5327339 100644 --- a/workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md +++ b/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:@`), 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.