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
221
specs/OpenQuestions-WorkingDefaults.md
Normal file
221
specs/OpenQuestions-WorkingDefaults.md
Normal file
|
|
@ -0,0 +1,221 @@
|
|||
# Open Questions — Stage 0 Working Defaults
|
||||
|
||||
**Status:** Provisional (non-normative until promoted into core specs)
|
||||
**Date:** 2026-07-28
|
||||
**Authority:** Unblocks schema enums, golden fixtures, and draft legal skeleton. Does **not** finalize legal policy.
|
||||
**Sources:** PRD §14, concept §24, SWOT I-09
|
||||
**Promotion rule:** Moving a default into `TargetRevenueFrameworkCore.md` or TRSL draft requires human accept (SCOPE §4).
|
||||
|
||||
---
|
||||
|
||||
## How to read this document
|
||||
|
||||
| Label | Meaning |
|
||||
| --- | --- |
|
||||
| **Working default** | Use this in Stage 0 schemas, examples, and validators |
|
||||
| **Blocked on research** | No default yet; do not invent in code as if normative |
|
||||
| **Blocked on legal** | Needs specialist input; skeleton may mark `[LEGAL]` only |
|
||||
|
||||
Each item maps to PRD open question numbers in parentheses.
|
||||
|
||||
---
|
||||
|
||||
## Q1 — Noncommercial rights during protected Phase (1)
|
||||
|
||||
**Working default (documentation only):**
|
||||
During a protected Phase, noncommercial users may view source, evaluate, test, and use for personal, research, and educational purposes consistent with a PolyForm-Noncommercial-style scope — exact clause text is **blocked on legal**.
|
||||
|
||||
**Schema impact:** No mandatory machine field beyond Future License and Phase status.
|
||||
**Not decided:** Contractor-on-behalf-of-enterprise edge cases (see Q2).
|
||||
|
||||
---
|
||||
|
||||
## Q2 — Definition of commercial use (2)
|
||||
|
||||
**Working default:**
|
||||
Treat as **commercial use** any use by or for an organization that is not purely personal, academic research, or recognized non-profit educational classroom use — **provisional**, for examples and risk callouts only.
|
||||
|
||||
**Blocked on legal:** Affiliates, contractors, mixed-purpose, public-sector, and internal-tools-only definitions must appear in TRSL draft with objective wording (AGB/clarity risk).
|
||||
|
||||
**Stage 0 practice:** Golden examples assume a paying “commercial entitlement” for any company production use; do not encode a full classifier in the fold library.
|
||||
|
||||
---
|
||||
|
||||
## Q3 — Future License options (3)
|
||||
|
||||
**Working default:**
|
||||
Both **MIT** and **Apache-2.0** are allowed `phase.future_license` enum values. Phase authors choose one at publication; default in examples is **MIT**.
|
||||
|
||||
**Patent treatment of pre-conversion phase:** Express patent license for permitted uses is **blocked on legal** (WP-0001-T03). Schemas allow Future License enum only; no separate patent field required in Stage 0.
|
||||
|
||||
---
|
||||
|
||||
## Q4 — Target Multiple classes (4)
|
||||
|
||||
**Working default:**
|
||||
`target_multiple` is an **open decimal** ≥ 0. The 0x / 1x / 10x / 100x / 1000x labels are **guidance classes** (concept §7.4), not a closed enum.
|
||||
|
||||
**Stage 0 practice:** Examples use 100. Validators accept any non-negative decimal; may **warn** (not fail) if value is not in `{0,1,10,100,1000}`.
|
||||
|
||||
---
|
||||
|
||||
## Q5 — Development-cost components in target basis (5)
|
||||
|
||||
**Working default:**
|
||||
Target basis transparency fields: `estimated_effort_days`, `daily_rate` (or equivalent published rate), `approved_direct_costs`.
|
||||
`Initial Target = (effort × rate + direct costs) × target_multiple` when basis is fully supplied.
|
||||
|
||||
**Excluded from Stage 0 basis by default:** Marketing, general overhead, unrelated R&D, opportunity cost, and speculative “market value” uplifts not expressed via Target Multiple.
|
||||
|
||||
**Blocked on research/legal:** Employee vs contractor rate disclosure norms; mandatory audit of direct costs.
|
||||
|
||||
---
|
||||
|
||||
## Q6 — Currency and FX (6)
|
||||
|
||||
**Working default:**
|
||||
A Phase has **one native currency** (`phase.initial_target.currency`). All ledger entries for that Phase **must** use the same currency in Stage 0.
|
||||
|
||||
**Schema rule:** Reject entry currency mismatches. No FX conversion in the pure fold.
|
||||
|
||||
**Later:** Optional FX extension may be registered; until then multi-currency Phases are out of scope.
|
||||
|
||||
---
|
||||
|
||||
## Q7 — Progress-sensitive degeneration formula (7)
|
||||
|
||||
**Working default (pilot formula, not final norm):**
|
||||
Publish a versioned policy id `trsl:policy:linear-longstop-v0` defined as:
|
||||
|
||||
- Remission accrues **only** by time toward a declared **Longstop Date** (see Q8).
|
||||
- Between Phase activation `t0` and Longstop `tL`,
|
||||
\( R(t) = T_0 \times \mathrm{clamp}((t - t_0)/(t_L - t_0), 0, 1) \)
|
||||
with discrete ledger `remission-credit` entries computed on a published schedule (e.g. daily or monthly UTC), **or** a single full remission at longstop for minimal implementations.
|
||||
- Development Credit does not change the remission schedule in v0 (no progress-sensitive boost/pause yet).
|
||||
|
||||
**Blocked on research:** Progress-sensitive pause when material Development Credit arrives; diversity-of-payers factors. Track in `TargetDegenerationPolicyResearch.md` (planned).
|
||||
|
||||
---
|
||||
|
||||
## Q8 — Fixed Longstop Date (8)
|
||||
|
||||
**Working default:**
|
||||
**Every Phase MUST declare a Longstop Date** (or equivalent full-remission instant) in the Phase Manifest for Stage 0 conformance.
|
||||
|
||||
**Schema:** Treat `phase.longstop_at` (ISO 8601) as **Required** for Stage 0 validators (extension of TSD §3.1 recommended fields → required under working defaults).
|
||||
|
||||
**Rationale:** Prevents indefinite restriction if the product hypothesis fails (PRD risk table; concept §13.3).
|
||||
|
||||
---
|
||||
|
||||
## Q9 — Public metrics mandatory set (9)
|
||||
|
||||
**Working default — mandatory public facts:**
|
||||
|
||||
- Initial Target, currency
|
||||
- Cumulative Development Credit
|
||||
- Cumulative Remission Credit
|
||||
- Outstanding Target
|
||||
- Conversion status
|
||||
- Last ledger entry id / checkpoint hash
|
||||
- Longstop timestamp
|
||||
|
||||
**Recommended:** Development Credit velocity; time since last material Development Credit; forecast conversion date **labeled as forecast only**.
|
||||
|
||||
**Optional:** Contributor diversity counts; confidence ranges.
|
||||
|
||||
---
|
||||
|
||||
## Q10 — Minimum evidence for Development Credit (10)
|
||||
|
||||
**Working default — tiered evidence references:**
|
||||
|
||||
| Tier | `evidence_reference` | When |
|
||||
| --- | --- | --- |
|
||||
| E0 | Opaque internal id (`confidential:…`) | Allowed in Stage 0 fixtures; insufficient for external audit claims |
|
||||
| E1 | Settled payment reference (processor/id) | Minimum for any public claim of Development Credit in a pilot |
|
||||
| E2 | Contract + invoice + settlement set | Recommended for disputed or high-value credits |
|
||||
|
||||
**Recognition event (see extension contract):** Working default **`payment-settled`** only. Invoice/order without settlement do not create Development Credit in Stage 0 fold inputs.
|
||||
|
||||
**Blocked on legal:** Audit rights wording and confidential evidence disclosure process.
|
||||
|
||||
---
|
||||
|
||||
## Q11 — First canonical extensions (11)
|
||||
|
||||
**Working default — Stage 0 catalog targets:**
|
||||
|
||||
1. `development-license` — default development_allocation 100% of settled development fee (net of tax/refunds per extension)
|
||||
2. `cost-plus-operations` — default development_allocation 0%
|
||||
3. `phase-sponsorship` — development_allocation **explicitly declared** per transaction
|
||||
4. `service-with-development-allocation` — default 0%; explicit split when reusable work enters Milestone
|
||||
5. `product-ideation` — default 0% or declared
|
||||
6. `general-consulting` — default 0%
|
||||
|
||||
Status `canonical` requires documented review; Stage 0 may ship them as `registered` examples first.
|
||||
|
||||
---
|
||||
|
||||
## Q12 — Disputes, audits, operator conflicts (12)
|
||||
|
||||
**Working default (process stub):**
|
||||
|
||||
1. Ledger is append-only; disputes create compensating entries, not silent edits.
|
||||
2. Conversion already triggered remains irrevocable (Rule 9) even if a later dispute reduces Development Credit — shortfall is a commercial/audit matter, not re-restriction.
|
||||
3. When the Trust Service operator is also a Phase licensor, attestations must be independently re-computable offline; public metrics must not depend on private operator judgment.
|
||||
|
||||
**Blocked on governance:** Full dispute SLA and third-party auditor program (PRD Phase 7).
|
||||
|
||||
---
|
||||
|
||||
## Q13 — Trust Service discontinuity (13)
|
||||
|
||||
**Working default:**
|
||||
|
||||
- Conversion is a pure function of Manifest + Ledger; offline recompute must remain possible.
|
||||
- Every Phase SHOULD be exportable as a **phase evidence package** (manifest, ledger chain, extension snapshots, optional attestation).
|
||||
- Operator failure must not be interpretable as “not converted” if Outstanding Target is already zero.
|
||||
|
||||
**Stage 0 delivery:** Specify package layout in WP-0002 golden example; full archival SLA later.
|
||||
|
||||
---
|
||||
|
||||
## Q14 — Cryptography / federation protocol (14)
|
||||
|
||||
**Working default for Stage 0 library:**
|
||||
|
||||
- Hash chain: SHA-256 over a canonical serialization of the previous entry (canonicalization algorithm fixed in schema ADR).
|
||||
- Signatures: **Ed25519** over the same canonical bytes; public keys in a simple key registry file for examples.
|
||||
- Key rotation: append-only key history document; not a multi-party federation protocol.
|
||||
|
||||
**Blocked on research:** Full federation discovery, threshold attestation, multi-operator conflict resolution.
|
||||
|
||||
---
|
||||
|
||||
## Q15 — Governance path (15)
|
||||
|
||||
**Working default:**
|
||||
Founder/maintainer-controlled experimentation under this SCOPE until `TRSL-Governance.md` exists. Core term changes require human accept; extensions may be registered as conformant without being canonical.
|
||||
|
||||
---
|
||||
|
||||
## Schema checklist derived from defaults
|
||||
|
||||
Stage 0 validators SHOULD enforce:
|
||||
|
||||
1. Phase native currency consistency on all entries.
|
||||
2. `longstop_at` present on every Phase Manifest.
|
||||
3. Development Credit entries only with `recognition` consistent with payment-settled inputs (when extension data present).
|
||||
4. `future_license` ∈ {`MIT`, `Apache-2.0`}.
|
||||
5. Closed ledger entry type enum from TSD §3.2.
|
||||
6. Outstanding Target = `max(0, T0 - C - R)` pure fold.
|
||||
7. Conversion Attestation never required to compute conversion status.
|
||||
|
||||
---
|
||||
|
||||
## Revision history
|
||||
|
||||
| Date | Change |
|
||||
| --- | --- |
|
||||
| 2026-07-28 | Initial working defaults from SWOT I-09 / Stage 0 unblocking |
|
||||
|
|
@ -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 |
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,9 @@ It:
|
|||
* 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.
|
||||
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 unless `specs/OpenQuestions-WorkingDefaults.md` states a **Stage 0 working default** for schema unblocking (those defaults remain provisional until human promotion into core specs).
|
||||
|
||||
**Sequencing (SCOPE.md):** Stage 0 technical delivery is offline schemas, pure fold, and golden fixtures (**WP-0002**), not a hosted Trust Service. Hosted registries and multi-user ledger APIs are deferred to PRD Phase 4b.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -28,17 +30,25 @@ Where a term, formula, or rule is already normatively defined in `spec/TargetRev
|
|||
|
||||
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
|
||||
### 1.1 Current state — documentation and Stage 0 foundation
|
||||
|
||||
* `INTENT.md` — durable purpose and strategic boundaries.
|
||||
* `SCOPE.md` — living Stage 0 in/out scope and sequencing rules.
|
||||
* `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.
|
||||
* `specs/OpenQuestions-WorkingDefaults.md` — provisional Stage 0 defaults for open questions.
|
||||
* `workplans/` — TREV-WP-0001 (legal research), TREV-WP-0002 (schemas/fold), TREV-WP-0003 (core extract).
|
||||
* `history/` — dated exploration and assessments, non-normative.
|
||||
* Planned by WP-0002: `schemas/`, `examples/` (machine-readable contracts + golden Phase).
|
||||
|
||||
### 1.2 Target future state — reference Trust Service
|
||||
### 1.2 Near-term target — offline runnable specification (PRD Phase 4a)
|
||||
|
||||
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.
|
||||
JSON Schema (or equivalent), pure Outstanding Target fold, offline validators, and golden fixtures. No requirement for multi-tenant hosting. Conversion status must be computable without network services or attestation files.
|
||||
|
||||
### 1.3 Later target — reference Trust Service (PRD Phase 4b)
|
||||
|
||||
A centralized reference implementation 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. Hosted implementation is **out of scope for WP-0002**.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -86,15 +96,17 @@ The following schemas formalize the YAML sketches already present in `spec/Targe
|
|||
| `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. |
|
||||
| `phase.future_license` | enum (`MIT`, `Apache-2.0`) | Required | Stage 0 closed set per working default Q3; additional Future Licenses require core revision. |
|
||||
| `phase.degeneration_policy` | string (URN, `trsl:policy:<slug>@<version>`) | Required | Stage 0 pilot: `trsl:policy:linear-longstop-v0` (working default Q7). |
|
||||
| `phase.longstop_at` | ISO 8601 timestamp | Required (Stage 0) | Working default Q8: every Phase must declare a full-remission / maximum-protection instant. Promote to permanent core via WP-0003 extract + human accept. |
|
||||
| `phase.ledger` | URL or path URI | Required | Location of the authoritative Target Ledger for this Phase (may be relative path in offline packages). |
|
||||
| `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).
|
||||
- A manifest missing any Required field MUST be rejected at registration or offline validation (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.
|
||||
- `entry.currency` for all ledger entries MUST match `phase.initial_target.currency` in Stage 0 (working default Q6); FX is out of scope for the pure fold.
|
||||
|
||||
### 3.2 Target Ledger Entry
|
||||
|
||||
|
|
@ -228,27 +240,39 @@ No schema field may be optional if its absence would make the Conversion Event's
|
|||
```text
|
||||
target-revenue/
|
||||
├── INTENT.md
|
||||
├── SCOPE.md
|
||||
├── README.md
|
||||
├── CONTRIBUTING.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
|
||||
│ ├── 260728-InitialExploration.md
|
||||
│ └── 260728-SWOT-Assessment.md
|
||||
├── spec/
|
||||
│ └── TargetRevenueLicenseConcept.md # normative concept (singular path, stable)
|
||||
├── specs/
|
||||
│ ├── ProductRequirementsDocument.md
|
||||
│ ├── TechnicalSpecificationDocument.md # this document
|
||||
│ ├── OpenQuestions-WorkingDefaults.md
|
||||
│ └── (near-term extracts / drafts:)
|
||||
│ ├── TargetRevenueFrameworkCore.md # WP-0003
|
||||
│ ├── PhaseManifestSpecification.md # WP-0003
|
||||
│ ├── TargetLedgerSpecification.md # WP-0003
|
||||
│ ├── MonetizationExtensionSpecification.md
|
||||
│ ├── TargetRevenueSourceLicense-Draft.md # WP-0001
|
||||
│ ├── CanonicalMonetizationProfiles.md
|
||||
│ ├── TargetDegenerationPolicyResearch.md
|
||||
│ ├── TrustServiceProductRequirementsDocument.md # before hosted service
|
||||
│ ├── TrustServiceFederationArchitecture.md
|
||||
│ └── TRSL-Governance.md
|
||||
├── workplans/
|
||||
│ ├── TREV-WP-0001-license-prior-art-research.md
|
||||
│ ├── TREV-WP-0002-trust-service-foundation.md
|
||||
│ └── TREV-WP-0003-normative-core-extraction.md
|
||||
├── schemas/ # planned — WP-0002
|
||||
└── examples/ # planned — WP-0002 golden Phase package
|
||||
```
|
||||
|
||||
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.
|
||||
**`spec/` vs `specs/` policy:** The concept document remains under singular `spec/` so git history and existing citations stay valid. New product, technical, research, and extracted normative artifacts go under plural `specs/`. Do not relocate the concept file without an explicit migration note in README and this section.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -268,13 +292,17 @@ Any future inclusion of these concerns requires a PRD revision or an explicit AD
|
|||
|
||||
## 9. Open Technical Questions
|
||||
|
||||
Carried forward from `specs/ProductRequirementsDocument.md` §14 and narrowed to schema-level impact:
|
||||
Carried forward from `specs/ProductRequirementsDocument.md` §14 and narrowed to schema-level impact. Stage 0 working defaults (provisional) from `OpenQuestions-WorkingDefaults.md`:
|
||||
|
||||
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?
|
||||
| # | Question | Stage 0 working default |
|
||||
| --- | --- | --- |
|
||||
| 1 | Currency mismatches vs FX extension? | **Reject** mismatches; single native currency; no FX in fold |
|
||||
| 2 | `target_multiple` closed enum or open decimal? | **Open decimal**; classes are guidance; optional warn |
|
||||
| 3 | `evidence.requirement` grammar? | Free text or short tier tag (E0–E2) until controlled vocab |
|
||||
| 4 | `extension.status` history? | Mutable registry metadata outside Target Ledger for Stage 0 |
|
||||
| 5 | Signature scheme / key rotation? | **SHA-256** chain + **Ed25519** example signatures; append-only key history file |
|
||||
|
||||
Unresolved beyond Stage 0: progress-sensitive degeneration parameters, federation discovery, multi-authority attestation.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue