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