coulomb/target-revenue
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source 
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.
This commit is contained in:
tegwick 2026-07-29 22:31:19 +02:00
parent 8894acc584
commit 58a4dd1db2
8 changed files with 658 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

193
specs/CanonicalMonetizationProfiles.md Normal file
View file

@ -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.

108
specs/CanonicalizationReviewChecklist.md Normal file
View file

@ -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.

236
specs/TargetDegenerationPolicyResearch.md Normal file
View file

@ -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.