target-revenue/specs/ProductRequirementsDocument.md

target-revenue — Product Requirements Document

Status: Draft v0.2 Date: 2026-07-28 Owner: target-revenue initiative Primary artifacts: INTENT.md, SCOPE.md, specs/TargetRevenueLicenseConcept.md, history/260728-InitialExploration.md Living scope: SCOPE.md states Stage 0 in/out boundaries and workplan sequencing (normative extract + schemas/fold before hosted Trust Service). Working defaults: specs/OpenQuestions-WorkingDefaults.md holds provisional answers to §14 items for Stage 0 unblocking; promotion into core requires human accept. Terminology alignment: This document does not redefine terms already normatively defined in specs/TargetRevenueLicenseConcept.md (ultimate source; day-to-day reference: specs/TargetRevenueFrameworkCore.md §1). Where a definitive formula, rule, or schema already exists there, this PRD references it rather than restating it with variation.

---

1. Product summary

target-revenue establishes the Target Revenue Framework (TRF): a phased software monetization system combining the Target Revenue Source License (TRSL) with a Trust Service.

A software producer declares a bounded development Phase leading to a Milestone Release, together with an immutable Initial Target. During the Phase, noncommercial use may be source-available while commercial use requires an entitlement. Qualifying commercial payments accumulate as Development Credit; a published degeneration policy may accumulate Remission Credit over time. When Development Credit plus Remission Credit satisfy the Initial Target, the Milestone Release automatically and irrevocably converts to a declared permissive Future License (MIT or Apache-2.0).

The product's central bargain:

Commercial beneficiaries fund the creation and early availability of a software improvement; once the declared target is satisfied, the governed release becomes permissively open source.

The framework is intended to become a monetization canon for exploratory software products — a small, stable legal/economic kernel plus an extensible catalog of monetization profiles, published and made verifiable through a Trust Service.

---

2. Problem statement

Exploratory product development creates a coordination problem (INTENT.md, specs/TargetRevenueLicenseConcept.md §2):

• new software capabilities require up-front work and risk-taking;
• fully proprietary licensing restricts adoption, inspection, and ecosystem participation;
• immediate permissive publication can make it difficult to recover development investment;
• conventional open-core and dual-licensing models do not transparently connect commercial success to a transition into the commons;
• exploratory products need multiple monetization paths (development, operations, services, consulting, ideation, sponsorship), and conflating them makes "revenue captured" hard to define, dispute-prone, and easy to manipulate.

Without a shared framework, every project reinvents ad hoc answers to: which payments count, when conversion happens, whether it can be revoked, and how to prove any of it. target-revenue solves this by providing a canonical Phase/target/credit/conversion model, a payment-allocation boundary between development and non-development monetization, a degeneration mechanism so unsuccessful phases do not stay restricted forever, and a Trust Service that makes the whole mechanism observable and verifiable without becoming a discretionary licensing authority.

---

3. Goals

G1 — Minimal constitutional core

The normative kernel (Phase, Milestone Release, Initial Target, Development Credit, Remission Credit, Outstanding Target, Conversion Event, Future License) shall remain small enough to explain in one paragraph and apply consistently across projects (specs/TargetRevenueLicenseConcept.md §7, §22).

G2 — Automatic, irrevocable conversion

Conversion shall occur automatically when the Outstanding Target reaches zero, without discretionary action by the licensor or Trust Service, and shall never be revoked by later corrections, refunds, or disputes (Rules 6 and 9, §10).

G3 — Explicit economic allocation

No payment shall count toward a Phase's target unless its development allocation is explicitly declared. Development, operations, services, consulting, ideation, and sponsorship monetization shall remain distinguishable and independently accounted (§11).

G4 — Transparent, non-gameable degeneration

Unsatisfied targets shall be able to degenerate over time under a published, deterministic policy, recorded as Remission Credit and never misrepresented as captured revenue (§13).

G5 — Extensibility without fragmentation

New monetization ideas shall be publishable as registered or canonical extensions through a constrained six-question contract (value, pricing, allocation, recognition, reversal, evidence), without redefining core terms or the conversion mechanism (§12).

G6 — Trust without discretionary control

The Trust Service shall observe, record, calculate, and attest — never hold discretion over whether a conversion occurs. A Conversion Attestation is evidence of conversion, not its legal cause (§14.2).

G7 — Federation-ready from day one

Even while centrally operated, the Trust Service shall produce open schemas, deterministic calculations, globally unique identifiers, signed records, and append-only history so that independent verification, replication, and federation are possible later without a rearchitecture (§14.4, §15).

G8 — Permanent prior freedom

A later Phase may govern new development but must never withdraw or restrict rights already granted for an earlier converted Milestone Release (Rule 7, invariant 10).

---

4. Non-goals

Per INTENT.md "Strategic Boundaries" and specs/TargetRevenueLicenseConcept.md §5, the framework shall not:

1. Govern the products or software releases of individual TRSL Phases beyond the framework's own reference material.
2. Define customer-specific commercial, hosting, support, consulting, or service agreements.
3. Function as a tax, bookkeeping, or statutory revenue-recognition standard.
4. Impose a universal pricing model on all projects.
5. Guarantee that a Phase reaches its commercial target or becomes profitable.
6. Make hosted operation, support, or consulting free after license conversion.
7. Prevent independent competition after permissive conversion.
8. Determine the commercial value of an improvement objectively (the Target Multiple is an explicit hypothesis, not a measured fact).
9. Operate every future Trust Service provider's implementation.
10. Finalize legal license text, a final degeneration formula, tax treatment, detailed pricing schedules, or jurisdiction-specific agreements as part of this concept phase (§3).

---

5. Users and stakeholders

Stakeholder	Needs
Independent developer / maintainer	A way to fund exploratory work without giving up an eventual open-source outcome.
Product company	A reusable mechanism to finance product-defining or platform-defining capabilities.
Commercial user / early adopter	Clear, auditable terms for what a commercial entitlement buys and how it advances conversion.
Sponsor	A way to fund a Phase, feature, or the project generally with a declared (not silently assumed) effect on the target.
Service provider / consultant	Confidence that ordinary service, support, or consulting revenue will not accidentally trigger or block conversion.
Trust Service operator	A bounded, well-defined responsibility (registry, ledger, metrics, attestation) without legal discretion over conversion.
Future federation operator	Open schemas and signed, deterministic records enabling independent verification and replication.
Legal / financial practitioner	A conceptually complete, internally consistent model suitable as the basis for legal drafting and review.
Contributor	Clarity about what rights they must grant so both the TRSL phase and the eventual Future License can be honored.

---

6. Conceptual model

6.1 Core entities

The seven core terms and their relationships are normatively defined in specs/TargetRevenueLicenseConcept.md §7 (day-to-day reference: specs/TargetRevenueFrameworkCore.md §1, WP-0003 extract) and must not be restated with variant meaning elsewhere in the framework:

Entity	Summary
Phase	A bounded development undertaking governed by one Initial Target, one Milestone Release, one degeneration policy, one Future License declaration.
Milestone Release	The precisely identified release that converts at the Conversion Event.
Initial Target	The immutable monetary target for the Phase (Estimated Development Cost × Target Multiple).
Target Multiple	A declared commercial hypothesis multiplier (0x/1x/10x/100x/1000x classes, §7.4).
Development Credit	Settled payment explicitly allocated toward the Initial Target.
Remission Credit	Transparent, non-revenue reduction of the Outstanding Target under the degeneration policy.
Outstanding Target	max(0, T0 − C − R).
Conversion Event	The moment the Outstanding Target reaches zero.
Future License	The permissive license (MIT or Apache-2.0 initially) applied at conversion.
Trust Service	Publication/accounting/evidence infrastructure; no discretionary conversion authority.
Monetization Profile / Extension	A standardized or project-specific payment-classification declaration conforming to the extension contract (§12).

6.2 Core lifecycle

Five verbs (§9): Define → Allocate → Credit / Remit → Convert. See the state diagram and rule set in specs/TargetRevenueLicenseConcept.md §9–§10 (day-to-day reference: specs/TargetRevenueFrameworkCore.md §3–§4) for the authoritative lifecycle and the nine core rules (immutable phase definition, explicit allocation, no duplicate credit, settled-payment recognition, separate remission, automatic conversion, permanent prior freedom, correction without erasure, conversion irreversibility).

6.3 Monetization architecture

The framework distinguishes target-relevant allocation from non-target allocation at the level of a single transaction (§11.1), with six canonical monetization classes — development, operations, ideation, service, consulting, sponsorship — each carrying a default Development Credit allocation (100%, 0%, configurable, 0%, 0%, explicitly declared respectively, §11.2–§11.7). Extensions may add new classes but must conform to the extension contract in §12 and may not alter the core terms.

6.4 Trust Service responsibility boundary

The Trust Service's five core responsibilities — Phase Registry, Extension Registry, Target Ledger, Metrics, Conversion Attestation — and its centralized-first, federation-ready architecture are defined in §14–§15. This PRD treats that section as authoritative for the Trust Service's functional scope; §14.2's responsibility boundary ("observes, records, validates conformance, calculates, publishes, attests" — never discretionary) governs every Trust Service requirement below.

---

7. Scope

7.1 In scope for the framework (all maturity stages)

• The TRSL legal concept and its eventual legally-reviewed drafting.
• The Phase Manifest, Target Ledger, and Conversion Attestation schemas.
• The canonical monetization profile catalog and the extension contract.
• The degeneration/remission policy model.
• The centralized Trust Service and its federation maturity path (Stage 0–6, §15).
• Governance principles for core-versus-extension placement (the "complexity budget" in §20.1).
• Reference documentation, worked examples, and conformance guidance.

7.2 Out of scope

• Final legal license text (requires specialist review, concept §21.5).
• A final degeneration formula (open design question; Stage 0 pilot formula only in OpenQuestions-WorkingDefaults.md Q7–Q8).
• Tax and statutory accounting treatment.
• Any specific product's or repository's actual TRSL Phase declarations — this repository is the framework, not a consumer of it.
• A production hosted Trust Service (requirements live here; Stage 0 delivers offline schemas/fold/examples only — see §12 Phase 4 and SCOPE.md).

---

8. Functional requirements

FR-1 — Phase declaration and immutability

Requirement: The framework shall define a Phase Manifest schema capturing the Phase, Milestone Release, Initial Target, Target Multiple, Future License, and degeneration policy, publishable before any Development Credit is accepted (Rule 1, §16 minimal manifest example).

Acceptance criteria:

• A Phase Manifest can be validated as complete against the minimal required field set in §16.
• The Initial Target, once published, cannot be increased for commercial convenience; only corrections for manifest error or explicit Remission are permitted.
• The Milestone Release is identified by an immutable reference (release artifact, source revision, or cryptographic digest).

FR-2 — Payment allocation model

Requirement: Every transaction shall be representable with an explicit development_allocation and non_target_allocation split, independent of its monetization label (§11.1, §5 "central economic distinction").

Acceptance criteria:

• A transaction record can express a monetization label (e.g. hosted-operations) without that label determining the target effect.
• No transaction contributes Development Credit without an explicit allocation rule (Rule 2).
• The same economic value cannot be represented as Development Credit under more than one Phase (Rule 3).

FR-3 — Canonical monetization profile catalog

Requirement: The framework shall publish default allocation rules for the six canonical classes: development (100%), operations (0%, cost-plus with configurable surcharge), ideation (0% or declared), service (0%), consulting (0%), sponsorship (explicitly declared) (§11.2–§11.7).

Acceptance criteria:

• Each canonical profile has a documented default allocation and at least one worked example.
• A project can override a canonical default explicitly (e.g., allocate part of an operations surcharge to development) without violating Rule 2.

FR-4 — Monetization extension contract

Requirement: The framework shall define a six-field extension contract (value, pricing, allocation, recognition, reversal, evidence) that any new monetization mechanism must implement to be registered (§12).

Acceptance criteria:

• An extension can be validated as conforming or non-conforming against the six-field contract.
• A conforming extension cannot redefine Phase, Initial Target, Development Credit, Remission Credit, Outstanding Target, Conversion Event, or Future License.
• The Trust Service can distinguish "registered" (conformant) from "canonical" (reviewed and recommended) extension status (§12.1–§12.2, §14.8).

FR-5 — Target Ledger

Requirement: The framework shall define an append-only ledger entry schema supporting development-credit, remission-credit, credit-reversal, remission-correction, administrative-correction-development, administrative-correction-remission, and conversion-checkpoint entry types (§17).

Acceptance criteria:

• Every ledger entry carries a phase reference, amount, currency, recognition timestamp, applicable extension reference, evidence reference, and cryptographic linkage to the previous entry (§17 example).
• Corrections and reversals are represented as new compensating entries, never as deletion or mutation of prior entries (Rule 8).
• The Outstanding Target can be deterministically recomputed from the full ledger and Phase Manifest at any time.

FR-6 — Degeneration / remission policy

Requirement: The framework shall support a published, deterministic (or objectively calculable) degeneration policy that generates Remission Credit over time when Development Credit progress is insufficient (§13).

Acceptance criteria:

• A degeneration policy is identified by a stable, versioned reference in the Phase Manifest.
• Remission Credit entries are distinguishable from Development Credit entries in every ledger view and metric.
• Operations revenue does not suspend or interact with degeneration calculations (§13.4).
• A Phase can express a Longstop Date, either as a separate maximum-protection rule or as the point where the policy remits the full remaining target (§13.3).

FR-7 — Conversion Event and Attestation

Requirement: The framework shall define the Conversion Event as the objective moment the Outstanding Target reaches zero, and a Conversion Attestation schema documenting it (§18).

Acceptance criteria:

• Conversion can be determined solely from the Phase Manifest and Target Ledger, without requiring any Trust Service declaration (§14.2, §18.3).
• A Conversion Attestation includes Phase identifier, Milestone Release identifier, conversion timestamp, Future License, final credit/remission/outstanding totals, and a supporting ledger checkpoint with signature.
• No later refund, correction, or dispute can revoke a Future License grant already triggered by a valid Conversion Event (Rule 9).

FR-8 — Trust Service: Phase and Extension Registries

Requirement: The Trust Service shall publish an authoritative, versioned registry of Phase declarations and monetization extensions (§14.1).

Acceptance criteria:

• Every registered Phase and extension has a globally unique, stable identifier.
• Registry records are signed and historically append-only.
• A complete Phase evidence package (manifest, ledger, extensions, attestation) can be exported in an open format (§14.4).

FR-9 — Trust Service: Metrics

Requirement: The Trust Service shall calculate and publish target-satisfaction metrics, distinguishing ledger facts, deterministic calculations, forecasts, and recommendations (§14.6).

Acceptance criteria:

• Published metrics include, at minimum, target satisfaction percentage, Development Credit velocity, Remission Credit velocity, and time since last material progress.
• Any projected conversion date is clearly labeled as a forecast and cannot alter the legal conversion mechanism.

FR-10 — Trust Service: evidence tiering

Requirement: The Trust Service shall distinguish public record, confidential audit evidence, and private commercial data (§14.5).

Acceptance criteria:

• Public records expose aggregate Development/Remission Credit, Outstanding Target, applicable extensions, and conversion status without customer-identifying detail.
• Confidential evidence (contracts, invoices, receipts) is accessible only to authorized audit/dispute parties.
• Private commercial data is never required to be uploaded to the Trust Service.
• (Revised 2026-07-29) Breach and termination determinations under specs/TargetRevenueSourceLicense-V1C1.md §7.4 are published as a distinct public conformity signal, with an anonymized Phase-and-category fallback by default; whether a Commercial Entitlement holder is named is governed by the applicable Commercial Use Agreement, a separate deliverable not yet drafted (specs/OpenQuestions-WorkingDefaults.md Q12 item 5).

FR-11 — Successive Phases

Requirement: The framework shall support multiple independently governed, sequential Phases over a software's lifetime, each identifying its base release, included change set, Milestone Release, Initial Target, Future License, degeneration policy, and ledger (§19).

Acceptance criteria:

• A later Phase's restrictions apply only to its own governed improvements.
• Rights already granted for an earlier converted Milestone Release remain permanently available regardless of later Phases (Rule 7).

---

9. Non-functional requirements

NFR-1 — Determinism and reproducibility

Given the same Phase Manifest and ledger entries, any conformant implementation must calculate the same Outstanding Target (§14.4).

NFR-2 — Auditability

Every ledger movement must be traceable to an evidence reference; corrections must be visible as compensating entries, never silent edits (Rule 8, §14.13).

NFR-3 — Federation readiness

Open schemas, signed records, globally unique identifiers, and stable versioning must exist from the first (centralized) implementation, so later replication and independent verification require no data-model migration (§14.4, §15).

NFR-4 — Legal determinacy

The governed software, target, applicable rules, and conversion condition must be identifiable without discretionary interpretation by the licensor or Trust Service (§4.2 design goal, "Legally determinate").

NFR-5 — Resistance to manipulation

The framework must prevent silent target increases, duplicate credits, discretionary postponement of conversion, retroactive rights withdrawal, and opaque degeneration adjustments (§4.6).

NFR-6 — Understandability

The core mechanism must remain explainable in one sentence: "Define a target, credit qualifying payments, remit part of the target over time, and convert the release when the target is satisfied" (§4.1, §9 five verbs).

NFR-7 — Governance discipline (complexity budget)

A proposed addition to the normative core must pass three tests — universal, interoperable, trust-critical — or it belongs in a canonical profile, extension, or project policy instead (§20.1).

---

10. Architecture proposal

The framework is organized into four layers (specs/TargetRevenueLicenseConcept.md §6, mermaid diagram):

Target Revenue Framework
├── Legal Layer
│   ├── Target Revenue Source License
│   └── Commercial and Service Agreements
├── Declarative Layer
│   ├── Phase Manifest
│   ├── Degeneration Policy
│   └── Monetization Profiles and Extensions
├── Trust Layer
│   ├── Phase and Extension Registry
│   ├── Target Ledger
│   ├── Metrics and Forecasts
│   └── Evidence and Attestations
└── Federation Layer
    ├── Open Schemas
    ├── Signed Records
    ├── Replication and Verification
    └── Federated Trust Service Providers

The architectural invariant governing every layer: the license establishes legal rights and automatic conversion; the Trust Service establishes an authoritative and verifiable factual record (§6, closing statement). No component of the Trust Layer may gain discretionary authority over the Legal Layer's conversion mechanism.

---

11. MVP proposal

11.1 MVP scope

The MVP corresponds to the "Proposed Initial Deliverables" already identified in specs/TargetRevenueLicenseConcept.md §25, sequenced so that runnable offline specification lands before a hosted Trust Service:

Tier A — Stage 0 package (current delivery focus; SCOPE.md §5):

1. TargetRevenueFrameworkCore.md — normative terminology, formulas, invariants, lifecycle (extract concept §7–§10, §22) — WP-0003.
2. PhaseManifestSpecification.md / TargetLedgerSpecification.md — field tiers and fold rules — WP-0003.
3. Machine-readable schemas + pure Outstanding Target fold + golden Phase package under examples/ — WP-0002.
4. OpenQuestions-WorkingDefaults.md — provisional defaults for conversion-critical open questions — done (provisional).
5. TargetRevenueSourceLicense-V1C1.md — first candidate operative license text (Version 1, Candidate 1), non-binding — WP-0001 (human accept gate). Supersedes the earlier draft skeleton, archived at history/260729-TargetRevenueSourceLicense-Draft.md. 5a. TargetRevenueCommercialUseAgreement-V1C1.md — companion Commercial Use Agreement candidate the License refers to but does not itself draft — WP-0001 (human accept gate); no dedicated prior-art research pass, less mature than item 5.
6. MonetizationExtensionSpecification.md (or Stage 0 stub) + path to CanonicalMonetizationProfiles.md.

Tier B — After Stage 0 package:

7. TargetDegenerationPolicyResearch.md — comparative models; promote beyond linear-longstop-v0 working default.
8. TrustServiceProductRequirementsDocument.md — dedicated PRD for hosted registry/ledger/metrics/attestation.
9. Hosted reference Trust Service (FR-8–FR-10) — TREV-WP-0006, active as of 2026-07-29.
10. TrustServiceFederationArchitecture.md / TRSL-Governance.md — federation and multi-stakeholder governance.

11.2 MVP non-scope

• A production hosted Trust Service (Stage 0 offline validators/fold only).
• Finalized legal license text.
• A finalized degeneration formula (pilot policy id allowed).
• Any concrete third-party product's production Phase declaration.
• External contributions into governed Milestone Releases (CONTRIBUTING.md).

11.3 MVP acceptance criteria

Stage 0 package is acceptable when a reader (human or agent) can:

• Understand and explain the five-verb lifecycle and seven-term core vocabulary from README + core extract without external sources.
• Construct and offline-validate a Phase Manifest, ledger, and optional Conversion Attestation using published schemas and the golden example.
• Recompute Outstanding Target to zero for the golden Phase with no network service and without requiring an attestation file.
• Classify a novel monetization idea as fitting an existing canonical profile or requiring a new conformant extension (once profiles doc or stub exists).
• Identify, for any given payment, whether and how much Development Credit it would generate under the canonical/working defaults.
• Trace why a specific conversion decision (or non-decision) is correct using only the Phase Manifest and ledger, without Trust Service discretion.

---

12. Roadmap

Workplan mapping (see workplans/, SCOPE.md §4):

Roadmap phase	Workplan / artifact
Phase 0	Concept + this PRD + TSD + SCOPE + working defaults
Phase 1	TREV-WP-0003 normative core extraction — finished
Phase 2	TREV-WP-0001 prior art + TRSL/CUA V1C1 — finished, accepted 2026-07-29
Phase 3	Extension contract (WP-0003, done) + full canonical catalog — TREV-WP-0007
Phase 4a	TREV-WP-0002 schemas, pure fold, golden fixture — finished
Phase 4b	Trust Service PRD + hosted reference implementation — TREV-WP-0006
Phase 5	Degeneration policy promotion — TREV-WP-0007
Phase 6	Federation — design readiness only, not started
Phase 7	Governance + pilot rollout (coulomb-loop, net-kingdom, helix-forge, railiance-*) — TREV-WP-0008

Phase 0 — Concept consolidation (largely complete)

• INTENT.md, SCOPE.md, and specs/TargetRevenueLicenseConcept.md established.
• This PRD and TSD translate the concept into product goals, requirements, and schema orientation.
• Stage 0 working defaults published; SWOT assessment under history/260728-SWOT-Assessment.md.

Phase 1 — Normative core extraction (active — WP-0003)

• Produce TargetRevenueFrameworkCore.md, PhaseManifestSpecification.md, TargetLedgerSpecification.md as stable, versioned normative documents distinct from the exploratory concept draft.

Phase 2 — Legal drafting basis (active — WP-0001)

• Produce TargetRevenueSourceLicense-V1C1.md for specialist legal review (automatic conditional grants, standard-terms law, contributor rights, cross-border enforceability — concept §21.5).
• Produce TargetRevenueCommercialUseAgreement-V1C1.md, the companion Commercial Use Agreement template referenced throughout the License (concept §21.2).
• Human accept required before a future candidate can become official V1.0.

Phase 3 — Extension and profile catalog

• Produce MonetizationExtensionSpecification.md and CanonicalMonetizationProfiles.md.
• Working defaults already list Stage 0 extension catalog targets and evidence tiers; research may refine (§14 items 4, 10, 11).

Phase 4a — Runnable specification foundation (finished — WP-0002)

• Machine-readable schemas, pure Outstanding Target fold, offline validators, golden Phase package.
• Conversion always recomputable without attestation or network service.

Phase 4b — Hosted Trust Service (active — WP-0006, unblocked 2026-07-29)

• Produce TrustServiceProductRequirementsDocument.md.
• Implement a centralized reference Trust Service satisfying FR-8–FR-10.
• Unblocked once Phase 1 (WP-0003) finished and Stage 0 working defaults were published — both true as of 2026-07-29; see workplans/TREV-WP-0006-trust-service-implementation.md.

Phase 5 — Degeneration policy resolution (active — WP-0007)

• Produce TargetDegenerationPolicyResearch.md; resolve the Longstop-vs-progress-decay relationship (§13.3, §24.7–24.8).
• Stage 0 pilot: trsl:policy:linear-longstop-v0 + mandatory Longstop (OpenQuestions-WorkingDefaults.md Q7–Q8); see workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md for promotion to a v1 formula.

Phase 6 — Federation path

• Produce TrustServiceFederationArchitecture.md; advance through Stage 1 (public verification) toward Stage 2+ (concept §15).
• Out of current SCOPE for delivery; design readiness only.

Phase 7 — Governance formalization (active — WP-0008)

• Produce TRSL-Governance.md covering change process, dispute handling, and conflict-of-interest rules (concept §20.3–§20.4).
• Now includes the Licensor-identity question across multiple product lines (coulomb-loop, net-kingdom, helix-forge, railiance-*) and pilot-rollout preparation; see workplans/TREV-WP-0008-governance-and-pilot-rollout.md. Real Phase declarations remain gated behind that workplan's T05 (legal + governance go-live decision).

---

13. Risks and mitigations

Risk	Impact	Mitigation
"Revenue captured" remains ambiguous across implementations	Disputes, loss of trust in the bargain	Explicit allocation model (FR-2) and canonical profile defaults (FR-3) resolve ambiguity by construction, not interpretation.
Trust Service operator gains de facto discretionary control	Undermines automatic conversion promise	Legal wording establishes conversion as automatic from Manifest + Ledger alone (FR-7); attestation is evidence, not cause (§14.2, §18.3).
Target degeneration used to hide non-progress as fake revenue	Erodes credibility of Development Credit as a signal	Rule 5 and FR-6 require Remission Credit to be structurally distinct from Development Credit in every ledger view.
Extension catalog fragments into incompatible variants	Loses interoperability benefit of a shared framework	Extension contract (FR-4) constrains what an extension may redefine; registered vs. canonical status separates conformance from endorsement.
No fixed Longstop leaves unsuccessful Phases restricted indefinitely	Undermines the "eventual commons" promise	FR-6 requires a Longstop Date or equivalent full-remission point in every degeneration policy.
Overloading the core with every monetization idea	Framework becomes as complex as what it replaces	NFR-7 complexity budget (universal/interoperable/trust-critical test) gates all core additions.
Contributors don't grant sufficient rights for the eventual Future License	Conversion becomes legally impossible for included contributions	Roadmap Phase 2 legal drafting must specify contributor rights requirements (§21.4) before any Phase accepts external contributions.

---

14. Open questions

Carried forward from specs/TargetRevenueLicenseConcept.md §24. Provisional Stage 0 answers live in specs/OpenQuestions-WorkingDefaults.md and do not close these questions permanently.

#	Question	Stage 0 working default (summary)
1	Noncommercial rights during protected Phase?	Doc-level PolyForm-like scope; clause text blocked on legal
2	Definition of commercial use?	Provisional org-production heuristic; legal definition blocked
3	MIT, Apache-2.0, or both?	Both allowed; examples default MIT
4	Target Multiple classes?	Open decimal; 0/1/10/100/1000 as guidance
5	Cost components in target basis?	Effort × rate + direct costs; exclude marketing/overhead by default
6	Currency / FX?	Single native currency per Phase; reject mismatches
7	Progress-sensitive degeneration?	Pilot linear-longstop-v0 only; progress-sensitive blocked on research
8	Fixed Longstop?	Required on every Phase Manifest for Stage 0
9	Public metrics?	Mandatory target/credit/outstanding/status/longstop set
10	Minimum Development Credit evidence?	payment-settled; tiers E0–E2
11	First canonical extensions?	Six named catalog targets; may start as registered
12	Disputes / operator conflict?	Append-only + irrevocable conversion; full SLA later
13	Trust Service discontinuity?	Offline recompute + exportable phase evidence package
14	Crypto / federation protocol?	SHA-256 chain + Ed25519 for Stage 0; federation later
15	Governance path?	Maintainer-controlled until TRSL-Governance.md

---

15. Guiding principle

The Target Revenue Framework succeeds when a Phase's conversion outcome can always be explained from its published Manifest and Ledger alone — never from trust in an operator's discretion.

The license supplies legal certainty. The Trust Service supplies factual certainty. target-revenue, as a repository, succeeds when it makes that separation precise enough to implement, extend, and eventually federate without losing it.