Add PRD/TSD specs and initial TRSL research + Trust Service workplans

Establishes specs/ProductRequirementsDocument.md and specs/TechnicalSpecificationDocument.md, plus two workplans: prior-art research for the TargetRevenueSourceLicense draft, and bootstrapping the Trust Service reference implementation. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-28 18:22:40 +02:00 · 2026-07-28 18:22:40 +02:00 · 19402f3115
commit 19402f3115
parent 4a98920490
4 changed files with 999 additions and 0 deletions
--- a/specs/ProductRequirementsDocument.md
+++ b/specs/ProductRequirementsDocument.md
@ -0,0 +1,441 @@
+# target-revenue — Product Requirements Document
+
+Status: Draft v0.1
+Date: 2026-07-28
+Owner: target-revenue initiative
+Primary artifacts: `INTENT.md`, `spec/TargetRevenueLicenseConcept.md`, `history/260728-InitialExploration.md`
+Terminology alignment: This document does not redefine terms already normatively defined in `spec/TargetRevenueLicenseConcept.md`. 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, `spec/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 (`spec/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 `spec/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 `spec/TargetRevenueLicenseConcept.md` §7 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 `spec/TargetRevenueLicenseConcept.md` §9–§10 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, §21.5).
+- A final degeneration formula (currently an open design question, §24.6–§24.8).
+- 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 implementation of the Trust Service (this document specifies requirements; implementation is a separate workplan).
+
+---
+
+## 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`, 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.
+
+### 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 (`spec/TargetRevenueLicenseConcept.md` §6, mermaid diagram):
+
+```text
+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 `spec/TargetRevenueLicenseConcept.md` §25, sequenced as a conceptual and documentation MVP (no production Trust Service implementation required yet):
+
+1. `TargetRevenueFrameworkCore.md` — normative terminology, formulas, invariants, lifecycle (extracting and stabilizing §7–§10 and §22 of the concept doc).
+2. `TargetRevenueSourceLicense-Draft.md` — initial legal drafting basis for specialist review.
+3. `PhaseManifestSpecification.md` — required vs. recommended vs. optional manifest fields.
+4. `TargetLedgerSpecification.md` — entry types, recognition, corrections, signatures, calculations.
+5. `TargetDegenerationPolicyResearch.md` — comparative models and candidate formulas.
+6. `MonetizationExtensionSpecification.md` — extension contract, registration, conformance, versioning.
+7. `CanonicalMonetizationProfiles.md` — the six canonical profiles with worked examples.
+8. `TrustServiceProductRequirementsDocument.md` — a dedicated PRD for the registry/ledger/metrics/evidence/attestation service (this document specifies the framework; the Trust Service PRD specifies its implementation).
+9. `TrustServiceFederationArchitecture.md` — signed records, replication, discovery, federation.
+10. `TRSL-Governance.md` — change process, extension review, disputes, conflicts of interest.
+
+### 11.2 MVP non-scope
+
+- A running Trust Service implementation.
+- Finalized legal license text.
+- A finalized degeneration formula.
+- Any concrete product's actual Phase declaration using the framework.
+
+### 11.3 MVP acceptance criteria
+
+The MVP is acceptable when a reader (human or agent) can:
+
+- Understand and explain the five-verb lifecycle and seven-term core vocabulary without consulting external sources.
+- Construct a valid example Phase Manifest, ledger, and Conversion Attestation using only the published schemas.
+- Classify a novel monetization idea as fitting an existing canonical profile or requiring a new conformant extension.
+- Identify, for any given payment, whether and how much Development Credit it would generate under the canonical defaults.
+- Trace why a specific conversion decision (or non-decision) is correct using only the Phase Manifest and ledger, without needing Trust Service discretion.
+
+---
+
+## 12. Roadmap
+
+### Phase 0 — Concept consolidation (this repository, current state)
+
+- `INTENT.md` and `spec/TargetRevenueLicenseConcept.md` established.
+- This PRD translates the concept into product goals, scope, and requirements.
+
+### Phase 1 — Normative core extraction
+
+- Produce `TargetRevenueFrameworkCore.md`, `PhaseManifestSpecification.md`, `TargetLedgerSpecification.md` as stable, versioned normative documents distinct from the exploratory concept draft.
+
+### Phase 2 — Legal drafting basis
+
+- Produce `TargetRevenueSourceLicense-Draft.md` for specialist legal review (automatic conditional grants, standard-terms law, contributor rights, cross-border enforceability — §21.5).
+
+### Phase 3 — Extension and profile catalog
+
+- Produce `MonetizationExtensionSpecification.md` and `CanonicalMonetizationProfiles.md`.
+- Resolve open questions on multiplier-class definitions and minimum evidence requirements (§24.4–§24.10).
+
+### Phase 4 — Trust Service specification and reference implementation
+
+- Produce `TrustServiceProductRequirementsDocument.md`.
+- Implement a centralized reference Trust Service satisfying FR-8–FR-10.
+
+### Phase 5 — Degeneration policy resolution
+
+- Produce `TargetDegenerationPolicyResearch.md`; resolve the Longstop-vs-progress-decay relationship (§13.3, §24.7–24.8).
+
+### Phase 6 — Federation path
+
+- Produce `TrustServiceFederationArchitecture.md`; advance through Stage 1 (public verification) toward Stage 2+ (§15).
+
+### Phase 7 — Governance formalization
+
+- Produce `TRSL-Governance.md` covering change process, dispute handling, and conflict-of-interest rules (§20.3–§20.4).
+
+---
+
+## 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 `spec/TargetRevenueLicenseConcept.md` §24, unresolved by this PRD:
+
+1. What precise rights should noncommercial users receive during a protected Phase?
+2. How should "commercial use" be defined across enterprises, contractors, affiliates, research organizations, and mixed-purpose use?
+3. Should MIT, Apache-2.0, or both be canonical Future License options for a given Phase?
+4. How should the 0x/1x/10x/100x/1000x Target Multiple classes be defined and justified in practice?
+5. Which development-cost components may enter the target basis?
+6. How should currency and foreign-exchange conversion be handled in the ledger?
+7. What is the simplest progress-sensitive degeneration formula?
+8. Should every Phase have a fixed Longstop Date in addition to progress-based degeneration?
+9. Which public metrics are mandatory, recommended, or optional?
+10. What minimum evidence is required to recognize a Development Credit?
+11. Which extensions should be canonical in the first release?
+12. How are disputes, audits, corrections, and operator conflicts of interest handled procedurally?
+13. How can Trust Service discontinuity be handled without impairing already-triggered license conversions?
+14. What cryptographic and protocol model best supports later federation?
+15. What governance path moves the framework from founder-controlled experimentation to a credible multi-stakeholder standard?
+
+---
+
+## 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.
--- a/specs/TechnicalSpecificationDocument.md
+++ b/specs/TechnicalSpecificationDocument.md
@ -0,0 +1,301 @@
+TechnicalSpecificationDocument
+
+*Technical structure for the Target Revenue Framework (TRF)*
+
+# Technical Specification (TSD)
+
+## Target Revenue Framework — Schemas, Layers, and Trust Service Orientation
+
+**PRD-aligned / Pre-Implementation Version**
+
+---
+
+## 0. Positioning and Authority
+
+This Technical Specification derives its authority **exclusively from `specs/ProductRequirementsDocument.md`** and serves as a **design-orientation document**, not a binding implementation plan.
+
+It:
+
+* translates the PRD's functional requirements into concrete data structures, component boundaries, and conformance rules;
+* makes explicit what is **normative now**, what is **deferred to later specification work**, and what is **intentionally left open**;
+* avoids encoding legal text, pricing decisions, or a fixed technology stack — those belong to the Legal Layer, canonical profiles, and future ADRs respectively.
+
+Where a term, formula, or rule is already normatively defined in `spec/TargetRevenueLicenseConcept.md`, this document references it rather than restating it with variation. Where the PRD leaves a question open (PRD §14), this TSD does not resolve it by implication.
+
+---
+
+## 1. System Composition
+
+The Target Revenue Framework, as it exists in this repository, is **currently a specification and schema artifact set**, not a running system. Two composition states apply:
+
+### 1.1 Current state — documentation and schema repository
+
+* `INTENT.md` — durable purpose and strategic boundaries.
+* `spec/TargetRevenueLicenseConcept.md` — normative concept: terminology, formulas, rules, lifecycle.
+* `specs/ProductRequirementsDocument.md` — product goals, scope, functional/non-functional requirements.
+* `specs/TechnicalSpecificationDocument.md` (this document) — schema and component-boundary orientation.
+* `history/` — dated exploration transcripts, non-normative.
+
+### 1.2 Target future state — reference Trust Service
+
+A centralized reference implementation (PRD §11.1 item 8, Roadmap Phase 4) providing the Phase Registry, Extension Registry, Target Ledger, Metrics, and Conversion Attestation responsibilities defined in `spec/TargetRevenueLicenseConcept.md` §14. This TSD specifies the **data model and component boundaries** that implementation must satisfy; it does not select a language, storage engine, or hosting model.
+
+---
+
+## 2. Design Guardrails (Derived from PRD)
+
+The following constraints are **non-negotiable** and shape all downstream schema and implementation decisions:
+
+1. **No discretionary conversion authority anywhere in the system**
+   No component — Trust Service, registry, or metrics engine — may hold a code path whose output is required for a Conversion Event to take legal effect (PRD G6, FR-7).
+
+2. **Core terms are immutable across all schemas**
+   `Phase`, `Milestone Release`, `Initial Target`, `Development Credit`, `Remission Credit`, `Outstanding Target`, `Conversion Event`, `Future License` must carry identical meaning in every schema, API, and extension that references them (PRD G1, §6.1).
+
+3. **Determinism over convenience**
+   Any calculation that determines the Outstanding Target must be reproducible by an independent implementation from the same Phase Manifest and Ledger alone (PRD NFR-1).
+
+4. **Explicit allocation, never inference**
+   No schema may compute a `development_allocation` from a payment amount, monetization label, or heuristic. It must always be an explicit, stored field (PRD FR-2, Rule 2).
+
+5. **Append-only, corrections-not-mutation**
+   No schema may support in-place update or deletion of a settled ledger entry. Corrections are new compensating entries (PRD FR-5, Rule 8).
+
+6. **Federation-ready data shapes from the first implementation**
+   Every identifier must be globally unique and stable independent of hosting location; every authoritative record must be signable and exportable (PRD NFR-3).
+
+---
+
+## 3. Data Model Specifications
+
+The following schemas formalize the YAML sketches already present in `spec/TargetRevenueLicenseConcept.md` (§16, §17, §12, §18) into typed field tables. Field names and semantics are authoritative from that document; this section adds required/recommended/optional tiering and type constraints per PRD FR-1.
+
+### 3.1 Phase Manifest
+
+| Field | Type | Tier | Notes |
+|---|---|---|---|
+| `framework` | string (semver-like tag) | Required | e.g. `TRF-0.1`. |
+| `license` | string (semver-like tag) | Required | e.g. `TRSL-0.1`. |
+| `phase.id` | string (URN, `trsl:phase:<slug>`) | Required | Globally unique; immutable once published. |
+| `phase.milestone_release.name` | string | Required | Human-readable release name. |
+| `phase.milestone_release.source_revision` | string | Required | Immutable VCS reference. |
+| `phase.milestone_release.artifact_sha256` | string (hex digest) | Recommended | Required if a built artifact (not just source) is governed. |
+| `phase.initial_target.amount` | decimal | Required | Immutable once Development Credits are accepted (Rule 1). |
+| `phase.initial_target.currency` | ISO 4217 code | Required | |
+| `phase.target_basis.estimated_effort_days` | decimal | Recommended | Transparency metadata, not legally required. |
+| `phase.target_basis.daily_rate` | decimal | Recommended | |
+| `phase.target_basis.approved_direct_costs` | decimal | Recommended | |
+| `phase.target_basis.target_multiple` | decimal | Recommended | One of the indicative classes (PRD §6.1) or a declared custom value. |
+| `phase.future_license` | enum (`MIT`, `Apache-2.0`, ...) | Required | |
+| `phase.degeneration_policy` | string (URN, `trsl:policy:<slug>@<version>`) | Required | |
+| `phase.ledger` | URL | Required | Location of the authoritative Target Ledger for this Phase. |
+| `extensions[]` | list of `trsl:extension:<id>@<version>` | Optional | Applicable monetization profiles/extensions for this Phase. |
+
+**Validation rules:**
+- A manifest missing any Required field MUST be rejected at registration (not merely flagged).
+- `phase.initial_target.amount` MUST NOT decrease or increase after first publication except through a versioned, historically-visible correction record distinct from ordinary Remission Credit.
+- `phase.id` MUST be immutable and MUST NOT be reused across Phases, including a superseded or abandoned Phase.
+
+### 3.2 Target Ledger Entry
+
+| Field | Type | Tier | Notes |
+|---|---|---|---|
+| `entry.id` | string (URN, `trsl:entry:<ulid>`) | Required | Globally unique, monotonically orderable (ULID or equivalent). |
+| `entry.phase` | string (Phase URN) | Required | Must reference an existing, published Phase Manifest. |
+| `entry.type` | enum: `development-credit`, `remission-credit`, `credit-reversal`, `remission-correction`, `administrative-correction`, `conversion-checkpoint` | Required | Closed set; not extensible per-project (PRD FR-5). |
+| `entry.amount` | decimal | Required | Signed only for reversal/correction types. |
+| `entry.currency` | ISO 4217 code | Required | Must match `phase.initial_target.currency` or declare an explicit FX rule (PRD open question §14.6). |
+| `entry.recognized_at` | ISO 8601 timestamp | Required | Settlement time, not invoice time (Rule 4). |
+| `entry.extension.id` / `entry.extension.version` | string / string | Required for `development-credit`/`remission-credit` | Identifies the monetization profile or degeneration policy that produced the entry. |
+| `entry.evidence_reference` | URI (may be `confidential:` scheme) | Required | Must resolve for authorized auditors even when not public. |
+| `entry.previous_entry_hash` | string (hex digest) | Required | Cryptographic linkage to the prior entry for this Phase (append-only chain). |
+| `entry.signature` | string | Required | Signed by the publishing Trust Service instance. |
+
+**Validation rules:**
+- Entries MUST be append-only; a correction is a new entry referencing the corrected entry's `id`, never an edit.
+- The Outstanding Target for a Phase MUST be computable as a pure fold over its ordered ledger entries plus the Phase Manifest's `initial_target.amount` (PRD NFR-1); no entry type may require external state to interpret.
+- `credit-reversal` and `remission-correction` entries MUST carry a reference to the entry they reverse or correct.
+
+### 3.3 Monetization Extension Contract
+
+| Field | Type | Tier | Notes |
+|---|---|---|---|
+| `extension.id` | string (URN, `trsl:extension:<slug>`) | Required | |
+| `extension.version` | string (semver) | Required | |
+| `value.description` | string | Required | What the payer receives. |
+| `pricing.method` | string | Required | How the payment is calculated. |
+| `allocation.rule` | string (formula or reference) | Required | What portion may become Development Credit. Must be expressible as a pure function of transaction fields. |
+| `recognition.event` | enum: `order`, `invoice`, `payment-settled`, `delivery` | Required | When the allocation becomes eligible. |
+| `reversal.rule` | string | Required | How refunds, chargebacks, or corrections are handled. |
+| `evidence.requirement` | string | Required | What proves the transaction and allocation. |
+| `status` | enum: `registered`, `canonical`, `deprecated` | Required (assigned by Trust Service, not the extension author) | `registered` = conformant; `canonical` = reviewed and recommended (PRD FR-4). |
+
+**Conformance rule (PRD FR-4):** An extension is **admissible only if it passes a conformance check** verifying:
+1. all Required fields are present and well-typed;
+2. `allocation.rule` does not reference or redefine `Phase`, `Initial Target`, `Development Credit`, `Remission Credit`, `Outstanding Target`, `Conversion Event`, or `Future License` — it may only consume transaction-level fields and produce a `development_allocation` output.
+
+A non-conforming extension MUST be rejected at registration, with a field-by-field diff against the contract, not silently accepted with reduced trust.
+
+### 3.4 Transaction Allocation Record
+
+| Field | Type | Tier | Notes |
+|---|---|---|---|
+| `payment.collected_amount` | decimal | Required | |
+| `payment.development_allocation` | decimal | Required | Explicit; MUST NOT be derived from `monetization_type` by any core code path (PRD FR-2). |
+| `payment.non_target_allocation` | decimal | Required | `collected_amount − development_allocation`, after taxes/fees/reversals per the applicable extension. |
+| `payment.phase` | string (Phase URN) | Required | |
+| `payment.monetization_profile` | string (extension URN) | Required | Explanatory label only; has no independent effect on target math. |
+
+### 3.5 Conversion Attestation
+
+| Field | Type | Tier | Notes |
+|---|---|---|---|
+| `attestation.phase` | string (Phase URN) | Required | |
+| `attestation.milestone_release` | string | Required | Matches `phase.milestone_release.name`. |
+| `attestation.conversion_timestamp` | ISO 8601 timestamp | Required | The moment the ledger fold first reaches `Outstanding Target = 0`. |
+| `attestation.future_license` | enum | Required | Copied from the Phase Manifest at conversion time. |
+| `attestation.final_development_credit` | decimal | Required | |
+| `attestation.final_remission_credit` | decimal | Required | |
+| `attestation.final_outstanding_target` | decimal | Required | MUST equal `0`. |
+| `attestation.ledger_checkpoint` | string (hash or entry id) | Required | Points to the last ledger entry included in the fold. |
+| `attestation.signature` | string | Required | |
+
+**Legal-technical rule (PRD FR-7, G6):** The attestation is generated **after** the fact of conversion is already true from the ledger; no code path may treat attestation generation as a precondition for the Future License taking effect. An attestation's absence or delay MUST NOT be interpretable as "not yet converted" by any conformant tooling — tooling must independently recompute conversion status from the raw ledger.
+
+---
+
+## 4. Component Architecture
+
+Maps the four-layer architecture from `specs/ProductRequirementsDocument.md` §10 to concrete technical boundaries:
+
+```text
+Legal Layer            → TRSL text + Commercial/Service Agreements (documents; no runtime component)
+Declarative Layer       → Phase Manifest store, Degeneration Policy registry, Extension registry
+                          (schema validation only; no business logic beyond §3 validation rules)
+Trust Layer             → Registry service, Target Ledger service, Metrics service,
+                          Attestation service (the only components with runtime state)
+Federation Layer        → Export/verification tooling, replication protocol, signature
+                          verification (consumes Trust Layer output; adds no new authority)
+```
+
+**Boundary rule:** Only the Trust Layer holds mutable state (the append-only ledger and registries). The Legal Layer is text; the Declarative Layer is validated-but-static-per-Phase input; the Federation Layer is read-only relative to a single authoritative Trust Service instance. No layer above the Trust Layer may write to it except through the Declarative Layer's validated publication path (Phase Manifest, Extension registration).
+
+### 4.1 Trust Service internal responsibility boundary
+
+Per `spec/TargetRevenueLicenseConcept.md` §14.2, every Trust Service component is limited to: **observe, record, validate conformance, calculate, publish, attest.** None may **decide** whether a conversion occurs — that is a pure function of Manifest + Ledger, computable by any conformant external tool.
+
+| Component | Responsibility | Forbidden |
+|---|---|---|
+| Phase Registry | Store and serve immutable Phase Manifests | Approving or blocking a Phase's validity beyond schema conformance |
+| Extension Registry | Store and serve extension records with `registered`/`canonical` status | Silently promoting an extension to `canonical` without a documented review process (PRD Roadmap Phase 7) |
+| Target Ledger | Append entries; serve the entry chain per Phase | Editing, deleting, or reordering settled entries |
+| Metrics | Calculate and label facts/calculations/forecasts/recommendations distinctly | Presenting a forecast as if it were a ledger fact |
+| Attestation | Publish a signed statement once the ledger fold reaches zero | Requiring its own publication as a condition of conversion |
+
+---
+
+## 5. Conformance Model
+
+Two independent conformance checks are required before this system can be considered specification-complete (PRD MVP acceptance criteria):
+
+1. **Manifest conformance** — a Phase Manifest validates against §3.1's Required-field set and immutability rules.
+2. **Extension conformance** — an extension validates against §3.3's contract and does not redefine core terms.
+
+Both checks MUST be implementable as pure, deterministic validation functions with no dependency on Trust Service runtime state, so that any independent party can conformance-check a Manifest or Extension offline.
+
+---
+
+## 6. Non-Functional Orientation
+
+Translating `specs/ProductRequirementsDocument.md` §9 into technical terms:
+
+### 6.1 Determinism
+Given identical Phase Manifest + Ledger input, Outstanding Target computation MUST be a pure fold with no hidden state, floating-point-order sensitivity, or timezone ambiguity (all timestamps ISO 8601 UTC).
+
+### 6.2 Auditability
+Every ledger entry MUST carry an `evidence_reference` resolvable by an authorized party; the cryptographic chain (`previous_entry_hash`) MUST allow tamper-evidence without requiring trust in the serving infrastructure.
+
+### 6.3 Federation readiness
+All identifiers (`phase.id`, `entry.id`, `extension.id`) MUST be globally unique independent of any single Trust Service's hostname, so records remain meaningful after replication or operator change.
+
+### 6.4 Legal determinacy
+No schema field may be optional if its absence would make the Conversion Event's timing ambiguous (§3.1, §3.2 Required tiers are drawn conservatively for this reason).
+
+---
+
+## 7. Repository Structure (Current and Near-Term)
+
+```text
+target-revenue/
+├── INTENT.md
+├── README.md
+├── LICENSE
+├── history/
+│   └── 260728-InitialExploration.md
+└── specs/
+    ├── ProductRequirementsDocument.md
+    ├── TechnicalSpecificationDocument.md      (this document)
+    └── (near-term, per PRD §11.1 MVP list:)
+        ├── TargetRevenueFrameworkCore.md
+        ├── TargetRevenueSourceLicense-Draft.md
+        ├── PhaseManifestSpecification.md
+        ├── TargetLedgerSpecification.md
+        ├── TargetDegenerationPolicyResearch.md
+        ├── MonetizationExtensionSpecification.md
+        ├── CanonicalMonetizationProfiles.md
+        ├── TrustServiceProductRequirementsDocument.md
+        ├── TrustServiceFederationArchitecture.md
+        └── TRSL-Governance.md
+```
+
+Note that `spec/TargetRevenueLicenseConcept.md` (singular `spec/`) predates the `specs/` directory established by the PRD and this TSD; it remains the normative concept source and is referenced, not moved, to preserve its history.
+
+---
+
+## 8. Out-of-Scope Reinforcement (Explicit)
+
+The following are **explicitly excluded** from this TSD, consistent with `specs/ProductRequirementsDocument.md` §4 and §7.2:
+
+* Final legal license text or clause-level drafting.
+* A finalized degeneration formula (§3.1's `degeneration_policy` is a reference slot, not a formula definition).
+* A concrete technology stack, storage engine, or hosting model for the Trust Service.
+* Any specific product's actual Phase declaration — the schemas above are the contract, not an instance.
+* Tax, statutory revenue-recognition, or accounting-standard treatment of any ledger entry type.
+
+Any future inclusion of these concerns requires a PRD revision or an explicit ADR, not a silent TSD amendment.
+
+---
+
+## 9. Open Technical Questions
+
+Carried forward from `specs/ProductRequirementsDocument.md` §14 and narrowed to schema-level impact:
+
+1. Should `entry.currency` mismatches across a Phase's entries be rejected outright, or resolved via a declared FX-rate extension field?
+2. Should `phase.target_basis.target_multiple` be a closed enum (the five indicative classes) or an open decimal with the classes as guidance only?
+3. What is the minimum `evidence.requirement` string grammar — free text, a controlled vocabulary, or a reference to an external evidence schema?
+4. Should `extension.status` transitions (`registered` → `canonical`) be recorded as their own ledger-like append-only history, or as mutable registry metadata outside the Target Ledger's append-only guarantee?
+5. What signature scheme (and key-rotation record format) should `entry.signature` and `attestation.signature` assume, given the federation-readiness requirement in §6.3?
+
+---
+
+## 10. Traceability Note
+
+This TSD is intentionally **non-binding** with respect to:
+
+* programming language, runtime, or framework choice for a future Trust Service implementation;
+* storage technology (relational, document, event-sourced, or ledger-native);
+* specific cryptographic signature algorithms;
+* UI or API surface design for registry/ledger access.
+
+Its sole purpose is to ensure that any future implementation, extension author, or federated operator can validate their work against the same schemas and boundary rules, keeping technical choices aligned with the product intent defined in `specs/ProductRequirementsDocument.md` and the normative concept in `spec/TargetRevenueLicenseConcept.md`.
+
+---
+
+## 11. Status
+
+* **TSD** is **PRD-aligned**.
+* Safe to use as:
+
+  * schema reference for `PhaseManifestSpecification.md`, `TargetLedgerSpecification.md`, and `MonetizationExtensionSpecification.md` drafting;
+  * conformance-check baseline for future Manifest/Extension validators;
+  * pre-ADR reference for the eventual Trust Service reference implementation.
--- a/workplans/TREV-WP-0001-license-prior-art-research.md
+++ b/workplans/TREV-WP-0001-license-prior-art-research.md
@ -0,0 +1,131 @@
+---
+id: TREV-WP-0001
+type: workplan
+title: "TargetRevenueSourceLicense prior-art and adjacent-concept research"
+domain: infotech
+repo: target-revenue
+status: active
+owner: claude
+topic_slug: infotech
+created: "2026-07-28"
+updated: "2026-07-28"
+---
+
+# TargetRevenueSourceLicense prior-art and adjacent-concept research
+
+Research prior art and adjacent licensing/monetization concepts to ground an
+initial draft of the Target Revenue Source License (TRSL). The concept is
+already established in `spec/TargetRevenueLicenseConcept.md` and
+`specs/ProductRequirementsDocument.md`; `history/260728-InitialExploration.md`
+already surfaces several reference points (Fair Source, PolyForm
+NonCommercial, Business Source License 1.1, FSL, OSI Open Source Definition,
+SPDX `LicenseRef-` conventions, German §31/§307/§32 considerations). This
+workplan deepens and formalizes that groundwork into a research artifact
+sufficient to brief specialist legal drafting (PRD Roadmap Phase 2, MVP
+deliverable `TargetRevenueSourceLicense-Draft.md`).
+
+This workplan does **not** produce final legal text. It produces the research
+basis and an initial non-binding draft skeleton for specialist review, per
+`specs/TechnicalSpecificationDocument.md` §8 (out-of-scope reinforcement).
+
+## Survey delayed-open-source and source-available license models
+
+```task
+id: TREV-WP-0001-T01
+status: todo
+priority: high
+```
+
+Survey and compare structurally similar models: Business Source License 1.1
+(MariaDB), Functional Source License (FSL), PolyForm Noncommercial /
+PolyForm Shield, Fair Source (fair.io), Elastic License 2.0, Sentry's SSPL-
+adjacent choices, and any other revenue- or time-triggered conversion
+licenses. For each, capture: the trigger mechanism (fixed date vs. revenue vs.
+hybrid), the pre-conversion restriction scope, the automatic-conversion legal
+wording, and known criticisms or disputes. Record findings so they can be
+diffed directly against TRSL's Phase/Target/Conversion model in
+`spec/TargetRevenueLicenseConcept.md` §7, §10, §18.
+
+## Survey OSI Open Source Definition and Fair Source boundary framing
+
+```task
+id: TREV-WP-0001-T02
+status: todo
+priority: high
+```
+
+Confirm and document precisely why TRSL's pre-conversion state cannot be
+described as "Open Source" under the OSI Open Source Definition
+(field-of-endeavour non-discrimination), and how Fair Source's "source
+available with limited business-protection restriction, later converts to
+OSI-approved license" framing applies or should be adapted. Produce
+recommended terminology guardrails (source-available vs. open source vs.
+commercially licensed) for use consistently across all TRF documents.
+
+## Survey patent-grant and Future License precedent (MIT vs Apache-2.0)
+
+```task
+id: TREV-WP-0001-T03
+status: todo
+priority: medium
+```
+
+Research the practical and legal tradeoffs between MIT and Apache-2.0 as
+canonical Future Licenses, focusing on: the extent and legal certainty of any
+implied patent grant under MIT, Apache-2.0's explicit patent grant and
+patent-litigation termination clause, and precedent for offering both as
+parallel canonical options (per PRD open question 3 /
+`spec/TargetRevenueLicenseConcept.md` §24.3). Produce a recommendation on
+whether the TRSL pre-conversion phase itself needs an express patent license
+independent of the eventual Future License choice.
+
+## Survey contributor-rights instruments for dual-future licensing
+
+```task
+id: TREV-WP-0001-T04
+status: todo
+priority: medium
+```
+
+Research contributor license agreement (CLA) and copyright assignment
+patterns used by projects that must promise two future states (a restricted
+phase license plus an eventual permissive license) — e.g. how BSL/FSL-based
+projects and other dual/relicensing projects handle contributor rights.
+Compare against the Developer Certificate of Origin (DCO), and determine
+whether a DCO alone is sufficient or whether TRSL requires a broader inbound
+grant (per `history/260728-InitialExploration.md` §8 and
+`spec/TargetRevenueLicenseConcept.md` §21.4).
+
+## Survey jurisdiction-specific standard-terms constraints
+
+```task
+id: TREV-WP-0001-T05
+status: todo
+priority: medium
+```
+
+Deepen the German-law groundwork already sketched in
+`history/260728-InitialExploration.md` §10 (§31 UrhG scoped rights of use,
+§307 BGB standard-terms clarity requirement, §32 UrhG author remuneration)
+and identify whether comparable standard-terms / consumer-protection
+constraints in other jurisdictions relevant to likely early commercial users
+(e.g. US, EU generally) impose similar clarity requirements on terms such as
+"commercial use," "captured," "Development Credit," and "Conversion Event."
+Flag terms that most urgently need objective, litigation-safe definitions.
+
+## Synthesize findings into an initial TRSL draft skeleton
+
+```task
+id: TREV-WP-0001-T06
+status: todo
+priority: high
+```
+
+Using T01–T05, produce `specs/TargetRevenueSourceLicense-Draft.md`: a
+non-binding initial drafting basis (not final legal text) structuring the
+license around the components already identified in
+`spec/TargetRevenueLicenseConcept.md` §21 (permitted noncommercial use,
+commercial-use restriction, automatic Future License conversion, patent
+treatment, termination and cure, warranty/liability exclusions). Explicitly
+mark every clause requiring specialist legal review before use, per
+`spec/TargetRevenueLicenseConcept.md` §21.5.
--- a/workplans/TREV-WP-0002-trust-service-implementation-bootstrap.md
+++ b/workplans/TREV-WP-0002-trust-service-implementation-bootstrap.md
@ -0,0 +1,126 @@
+---
+id: TREV-WP-0002
+type: workplan
+title: "Trust Service implementation bootstrap"
+domain: infotech
+repo: target-revenue
+status: active
+owner: claude
+topic_slug: infotech
+created: "2026-07-28"
+updated: "2026-07-28"
+---
+
+# Trust Service implementation bootstrap
+
+Start the reference implementation of the Trust Service (PRD Roadmap Phase 4,
+`specs/ProductRequirementsDocument.md` §11.1 item 8). The data model and
+component boundaries are already specified in
+`specs/TechnicalSpecificationDocument.md` §3 (Phase Manifest, Target Ledger
+Entry, Extension Contract, Transaction Allocation, Conversion Attestation)
+and §4 (component architecture: Phase Registry, Extension Registry, Target
+Ledger, Metrics, Attestation — observe/record/validate/calculate/publish/
+attest only, never discretionary over conversion).
+
+This workplan bootstraps the implementation; it does not attempt full
+production hardening, federation (PRD Roadmap Phase 6), or governance
+process design (PRD Roadmap Phase 7).
+
+## Record stack and storage ADR
+
+```task
+id: TREV-WP-0002-T01
+status: todo
+priority: high
+```
+
+`specs/TechnicalSpecificationDocument.md` is explicitly non-binding on
+language, runtime, and storage engine (§10 Traceability Note). Before writing
+code, record an ADR choosing an initial implementation stack and storage
+model (relational, document, or event-sourced/append-log-native), justified
+against the append-only, hash-chained, deterministic-fold requirements in
+TSD §3.2 and §6.1. Resolve TSD open question 5 (signature scheme and
+key-rotation record format) as part of the same ADR.
+
+## Implement Phase Manifest validation and Phase Registry
+
+```task
+id: TREV-WP-0002-T02
+status: todo
+priority: high
+```
+
+Implement the Phase Manifest schema from TSD §3.1 with a pure, deterministic
+conformance validator (required-field checks, immutability enforcement on
+`phase.initial_target.amount` and `phase.id`) per TSD §5. Implement the Phase
+Registry component (TSD §4.1) storing and serving published, immutable
+Manifests. Reject non-conformant manifests at registration, not at query
+time.
+
+## Implement the Target Ledger as an append-only, hash-chained store
+
+```task
+id: TREV-WP-0002-T03
+status: todo
+priority: high
+```
+
+Implement the Target Ledger Entry schema from TSD §3.2: the six entry types
+(`development-credit`, `remission-credit`, `credit-reversal`,
+`remission-correction`, `administrative-correction`, `conversion-checkpoint`),
+`previous_entry_hash` chaining, and signature fields. Enforce append-only
+semantics at the storage layer (no update/delete path exists, not merely
+disallowed by convention). Implement the Outstanding Target calculation as a
+pure fold over a Phase's ordered entries plus its Manifest's
+`initial_target.amount`, independently re-runnable by any conformant
+external tool (TSD §3.2 validation rules, §6.1).
+
+## Implement the Extension Registry and conformance validator
+
+```task
+id: TREV-WP-0002-T04
+status: todo
+priority: medium
+```
+
+Implement the Monetization Extension Contract schema from TSD §3.3 and its
+conformance check: required-field validation plus the rule that
+`allocation.rule` may only consume transaction-level fields and must not
+reference or redefine core terms (Phase, Initial Target, Development Credit,
+Remission Credit, Outstanding Target, Conversion Event, Future License).
+Support the `registered` / `canonical` / `deprecated` status field, with
+`canonical` promotion left as a manual, documented action (governance process
+itself is out of scope here — PRD Roadmap Phase 7).
+
+## Implement Conversion detection and Attestation publication
+
+```task
+id: TREV-WP-0002-T05
+status: todo
+priority: high
+```
+
+Implement Conversion Event detection as a pure read over the Target Ledger
+fold (Outstanding Target reaches zero) and Conversion Attestation generation
+per TSD §3.5. Enforce the legal-technical rule that attestation publication
+is evidence of conversion, never a precondition for it — any conformant
+external tool must be able to independently recompute conversion status from
+the raw Manifest and Ledger without waiting for or requiring an attestation
+(TSD §3.5, PRD FR-7/G6).
+
+## Stand up conformance test suite and a worked end-to-end example
+
+```task
+id: TREV-WP-0002-T06
+status: todo
+priority: medium
+```
+
+Build an automated conformance suite exercising: manifest validation (valid
+and deliberately invalid manifests), ledger append-only enforcement and hash
+chain integrity, extension conformance (a conforming and a non-conforming
+extension example), and a full worked Phase lifecycle from the illustrative
+example in `spec/TargetRevenueLicenseConcept.md` §23 (Initial Target
+$100,000, mixed Development/Remission Credit entries, reaching Outstanding
+Target zero, and a generated Conversion Attestation matching that example's
+numbers).