Adapt specs and workplans to SWOT Stage 0 sequencing
Introduce SCOPE, expanded README, CONTRIBUTING, and provisional open-question defaults. Rescope Trust Service work to offline schemas/fold/fixtures, add normative core extraction workplan, and split PRD roadmap Phase 4 into foundation vs hosted service. Sync workplans with State Hub.
This commit is contained in:
parent
7286b52f07
commit
4496244bb8
16 changed files with 1252 additions and 227 deletions
|
|
@ -1,9 +1,11 @@
|
|||
# target-revenue — Product Requirements Document
|
||||
|
||||
Status: Draft v0.1
|
||||
Status: Draft v0.2
|
||||
Date: 2026-07-28
|
||||
Owner: target-revenue initiative
|
||||
Primary artifacts: `INTENT.md`, `spec/TargetRevenueLicenseConcept.md`, `history/260728-InitialExploration.md`
|
||||
Primary artifacts: `INTENT.md`, `SCOPE.md`, `spec/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 `spec/TargetRevenueLicenseConcept.md`. Where a definitive formula, rule, or schema already exists there, this PRD references it rather than restating it with variation.
|
||||
|
||||
---
|
||||
|
|
@ -153,11 +155,11 @@ The Trust Service's five core responsibilities — Phase Registry, Extension Reg
|
|||
|
||||
### 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).
|
||||
- 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 implementation of the Trust Service (this document specifies requirements; implementation is a separate workplan).
|
||||
- A production hosted Trust Service (requirements live here; Stage 0 delivers offline schemas/fold/examples only — see §12 Phase 4 and `SCOPE.md`).
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -327,74 +329,103 @@ The architectural invariant governing every layer: **the license establishes leg
|
|||
|
||||
### 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):
|
||||
The MVP corresponds to the "Proposed Initial Deliverables" already identified in `spec/TargetRevenueLicenseConcept.md` §25, sequenced so that **runnable offline specification** lands before a hosted Trust Service:
|
||||
|
||||
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.
|
||||
**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-Draft.md` — non-binding legal drafting basis — **WP-0001** (human accept gate).
|
||||
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) — **successor workplan only** after Tier A and Trust Service PRD.
|
||||
10. `TrustServiceFederationArchitecture.md` / `TRSL-Governance.md` — federation and multi-stakeholder governance.
|
||||
|
||||
### 11.2 MVP non-scope
|
||||
|
||||
- A running Trust Service implementation.
|
||||
- A production hosted Trust Service (Stage 0 offline validators/fold only).
|
||||
- Finalized legal license text.
|
||||
- A finalized degeneration formula.
|
||||
- Any concrete product's actual Phase declaration using the framework.
|
||||
- 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
|
||||
|
||||
The MVP is acceptable when a reader (human or agent) can:
|
||||
**Stage 0 package** 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.
|
||||
- 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
|
||||
|
||||
### Phase 0 — Concept consolidation (this repository, current state)
|
||||
Workplan mapping (see `workplans/`, `SCOPE.md` §4):
|
||||
|
||||
- `INTENT.md` and `spec/TargetRevenueLicenseConcept.md` established.
|
||||
- This PRD translates the concept into product goals, scope, and requirements.
|
||||
| Roadmap phase | Workplan / artifact |
|
||||
| --- | --- |
|
||||
| Phase 0 | Concept + this PRD + TSD + SCOPE + working defaults |
|
||||
| Phase 1 | **TREV-WP-0003** normative core extraction |
|
||||
| Phase 2 | **TREV-WP-0001** prior art + TRSL draft skeleton (human gate) |
|
||||
| Phase 3 | Extension/profile docs (WP-0003-T04 stub; full catalog follow-on) |
|
||||
| Phase 4a | **TREV-WP-0002** schemas, pure fold, golden fixture (not hosted service) |
|
||||
| Phase 4b | Trust Service PRD + hosted reference implementation (future workplan) |
|
||||
| Phase 5+ | Degeneration research promotion, federation, governance |
|
||||
|
||||
### Phase 1 — Normative core extraction
|
||||
### Phase 0 — Concept consolidation (largely complete)
|
||||
|
||||
- `INTENT.md`, `SCOPE.md`, and `spec/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
|
||||
### Phase 2 — Legal drafting basis (active — WP-0001)
|
||||
|
||||
- Produce `TargetRevenueSourceLicense-Draft.md` for specialist legal review (automatic conditional grants, standard-terms law, contributor rights, cross-border enforceability — §21.5).
|
||||
- Produce `TargetRevenueSourceLicense-Draft.md` for specialist legal review (automatic conditional grants, standard-terms law, contributor rights, cross-border enforceability — concept §21.5).
|
||||
- Human accept required before marking draft skeleton complete.
|
||||
|
||||
### 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).
|
||||
- Working defaults already list Stage 0 extension catalog targets and evidence tiers; research may refine (§14 items 4, 10, 11).
|
||||
|
||||
### Phase 4 — Trust Service specification and reference implementation
|
||||
### Phase 4a — Runnable specification foundation (active — 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 (blocked until Phase 1 + 4a Stage 0 signal)
|
||||
|
||||
- Produce `TrustServiceProductRequirementsDocument.md`.
|
||||
- Implement a centralized reference Trust Service satisfying FR-8–FR-10.
|
||||
- Must not start under WP-0002; use a successor workplan after SCOPE Stage 0 “done enough” signal.
|
||||
|
||||
### Phase 5 — Degeneration policy resolution
|
||||
|
||||
- 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).
|
||||
|
||||
### Phase 6 — Federation path
|
||||
|
||||
- Produce `TrustServiceFederationArchitecture.md`; advance through Stage 1 (public verification) toward Stage 2+ (§15).
|
||||
- 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
|
||||
|
||||
- Produce `TRSL-Governance.md` covering change process, dispute handling, and conflict-of-interest rules (§20.3–§20.4).
|
||||
- Produce `TRSL-Governance.md` covering change process, dispute handling, and conflict-of-interest rules (concept §20.3–§20.4).
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -414,23 +445,25 @@ The MVP is acceptable when a reader (human or agent) can:
|
|||
|
||||
## 14. Open questions
|
||||
|
||||
Carried forward from `spec/TargetRevenueLicenseConcept.md` §24, unresolved by this PRD:
|
||||
Carried forward from `spec/TargetRevenueLicenseConcept.md` §24. **Provisional Stage 0 answers** live in `specs/OpenQuestions-WorkingDefaults.md` and do not close these questions permanently.
|
||||
|
||||
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?
|
||||
| # | 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 |
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue