tegwick
4496244bb8
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.
280 lines
22 KiB
Markdown
280 lines
22 KiB
Markdown
# SWOT Assessment — target-revenue
|
||
|
||
**Date:** 2026-07-28
|
||
**Scope:** Full repository review (concept, specs, workplans, governance metadata, history)
|
||
**Repository state:** Documentation-and-specification only; no application source code
|
||
**Assessor:** Grok (session review)
|
||
|
||
---
|
||
|
||
## 1. Executive summary
|
||
|
||
`target-revenue` is a **high-quality concept repository** for the Target Revenue Framework (TRF): a revenue-triggered, delayed-open-source model that pairs a Target Revenue Source License (TRSL) with a Trust Service for phase manifests, ledgers, extensions, and conversion attestations.
|
||
|
||
The conceptual kernel is unusually clear for a day-zero effort: small vocabulary, explicit allocation rules, automatic/irrevocable conversion, remission distinct from revenue, and federation-ready data discipline. Product and technical orientation documents (PRD, TSD) already translate that concept into goals, FRs/NFRs, schema field tables, and component boundaries. Two active workplans cover license prior-art research and Trust Service bootstrap; neither has started execution (0/12 tasks done).
|
||
|
||
The principal risks are **maturity gap vs. ambition**, **sequencing pressure** (implementation workplan running ahead of normative core extraction), **unresolved design questions** that block a credible MVP, and **structural doc debt** that will slow every subsequent agent and human contributor.
|
||
|
||
This assessment is a SWOT of the *repository and program as currently expressed*, not a legal opinion on TRSL enforceability.
|
||
|
||
---
|
||
|
||
## 2. Inventory snapshot
|
||
|
||
| Path | Role | Lines (approx.) | Maturity |
|
||
| --- | --- | --- | --- |
|
||
| `INTENT.md` | Durable purpose, users, principles, boundaries | 130 | Strong, stable by design |
|
||
| `README.md` | Public entry point | 2 | Minimal |
|
||
| `LICENSE` | Repo license (MIT No Attribution) | short | Present |
|
||
| `spec/TargetRevenueLicenseConcept.md` | Normative concept (terms, rules, lifecycle) | ~1188 | Concept-complete; trailing artifact (`xxx`) |
|
||
| `specs/ProductRequirementsDocument.md` | Product goals, FR/NFR, MVP, roadmap | ~441 | Draft v0.1, strong |
|
||
| `specs/TechnicalSpecificationDocument.md` | Schema tables, component boundaries | ~301 | Pre-implementation orientation |
|
||
| `history/260728-InitialExploration.md` | Dialogue / ideation transcript | ~1959 | Non-normative foundation |
|
||
| `workplans/TREV-WP-0001-…` | Prior-art research for TRSL draft | 6 tasks, all `todo` | Active, well-scoped |
|
||
| `workplans/TREV-WP-0002-…` | Trust Service implementation bootstrap | 6 tasks, all `todo` | Active; sequencing concern |
|
||
| `WORK-RECORDS.md` / `.custodian-brief.md` | Hub-synced work index | generated | Healthy integration |
|
||
| `.repo-classification.yaml` | Domain: infotech (+ financials) | short | Present; empty capability tags |
|
||
|
||
**What is not present (and expected for later maturity):**
|
||
|
||
- Machine-readable schemas (JSON Schema / OpenAPI / protobuf)
|
||
- Any of the 10 MVP deliverables listed in concept §25 / PRD §11.1
|
||
- `SCOPE.md` (referenced by INTENT as the living counterpart to stable INTENT)
|
||
- Implementation code, tests, CI, ADRs, CONTRIBUTING
|
||
- Legal draft text, degeneration formula, worked example package
|
||
- Diagram assets or short “elevator” one-pager beyond INTENT’s one-sentence bargain
|
||
|
||
---
|
||
|
||
## 3. SWOT
|
||
|
||
### Strengths
|
||
|
||
1. **Coherent constitutional core**
|
||
Seven-term vocabulary, five-verb lifecycle, nine core rules, and twelve invariants form a teachable kernel (“define → allocate → credit/remit → convert”). That is a genuine product asset, not just prose.
|
||
|
||
2. **Correct architectural separations**
|
||
License rights vs. Trust Service facts; Development Credit vs. Remission Credit; development monetization vs. operations/services; attestation as evidence not cause. These separations directly attack the usual failure modes of delayed-open and open-core models (discretion, double-counting, fake “revenue captured”).
|
||
|
||
3. **Honest non-goals and risk surface**
|
||
PRD non-goals, concept §5, and PRD risk table already name the hard problems (discretionary operators, indefinite restriction, extension fragmentation, contributor rights). That reduces strategic self-deception.
|
||
|
||
4. **Specification ladder is in place**
|
||
Exploration → concept → INTENT → PRD → TSD is a sound stack. TSD field tables with required/recommended/optional tiers and pure-fold Outstanding Target rules are implementation-ready *as orientation*, not as vaporware.
|
||
|
||
5. **Extensibility without core explosion**
|
||
Six-field monetization extension contract plus “complexity budget” (universal / interoperable / trust-critical) is the right governance reflex for a framework that wants a catalog of profiles.
|
||
|
||
6. **Federation readiness is designed in early**
|
||
Global URNs, append-only hash chains, signable records, export packages, and staged federation maturity (0–6) avoid a later data-model rewrite—if discipline is kept during the first implementation.
|
||
|
||
7. **Operational work system**
|
||
Custodian/State Hub workplans with IDs, WORK-RECORDS, and domain classification mean the repo is already legible to multi-agent and multi-session workflows.
|
||
|
||
8. **Differentiation narrative**
|
||
Relative to BSL/FSL (time-triggered) and simple noncommercial licenses, TRF’s **progress + remission against an immutable development target**, with explicit non-target allocation for ops/services, is a distinctive economic story if it can be made simple enough to adopt.
|
||
|
||
---
|
||
|
||
### Weaknesses
|
||
|
||
1. **Zero execution progress on stated work**
|
||
All 12 tasks across two workplans are `todo`. Concept density is high; delivery evidence is nil. Credibility currently rests entirely on document quality.
|
||
|
||
2. **Sequencing mismatch: implementation before normative core**
|
||
PRD roadmap places normative extraction (Phase 1), legal draft basis (Phase 2), and profiles/extensions (Phase 3) *before* Trust Service implementation (Phase 4). TREV-WP-0002 bootstraps implementation now, while MVP docs (`TargetRevenueFrameworkCore.md`, ledger/manifest specs, etc.) do not exist. Risk: code freezes provisional field names and forces rework when degeneration, FX, and evidence rules resolve.
|
||
|
||
3. **Critical open questions remain open**
|
||
Fifteen design questions (concept §24 / PRD §14) include conversion-adjacent items: commercial-use definition, degeneration formula, Longstop relationship, minimum evidence, currency/FX, contributor rights. Without answers (even provisional defaults), neither legal draft nor ledger semantics can be “done enough” for a pilot Phase.
|
||
|
||
4. **No machine-checkable contract**
|
||
Schemas live as markdown tables and YAML sketches. There is no validator a third party can run offline (despite TSD §5 requiring pure deterministic conformance functions). Drift between concept, PRD, TSD, and future code is currently unguarded.
|
||
|
||
5. **Public entry point is inadequate**
|
||
`README.md` is a single long sentence. New readers cannot find status, “what to read first,” non-OSI terminology guardrails, or links to PRD/concept. Adoption friction starts at the root file.
|
||
|
||
6. **Document topology friction**
|
||
- Normative concept under `spec/` (singular) vs. product/tech under `specs/` (plural)—called out in TSD but still a perpetual footgun.
|
||
- INTENT references `SCOPE.md`, which does not exist.
|
||
- Concept file ends with a stray `xxx` marker (integrity/polish issue).
|
||
- TSD §7 tree omits `workplans/`, `spec/`, and hub metadata files.
|
||
|
||
7. **MVP is documentation-heavy without a thin “worked package”**
|
||
Ten large MVP docs are listed before any runnable example. Missing is a minimal *example phase package* (manifest + sample ledger + fold result + attestation stub) that agents and humans can use as a golden fixture—independent of a full Trust Service.
|
||
|
||
8. **Legal and contributor path is acknowledged but empty**
|
||
Concept §21 and WP-0001 correctly gate final legal text, but there is no interim CLA/DCO policy sketch, no SPDX `LicenseRef-` stub, and no “do not use in production” banner strength proportional to the risk of premature use.
|
||
|
||
9. **Ambition surface vs. single-operator bootstrap**
|
||
INTENT’s maturity target (9 items) reaches multi-provider federation and multi-stakeholder governance. Without a ruthless SCOPE for “Stage 0 only,” every session risks working on Stage 6 problems (crypto federation model, multi-authority phases) while Stage 0 definitions remain unfinished.
|
||
|
||
10. **Classification / discoverability incomplete**
|
||
`.repo-classification.yaml` has empty `capability_tags`. Secondary domain `financials` is correct but not reflected in README or capability language for hub/search tooling.
|
||
|
||
11. **No quality automation**
|
||
No link checks, markdown lint, schema CI, spell/consistency checks on core terms, or “forbidden synonym” guards (e.g., silently reintroducing “Target Revenue Captured” as the conversion metric).
|
||
|
||
12. **Workplan ownership / review model is agent-centric**
|
||
Both workplans list `owner: claude`. Fine for bootstrap, but legal research (WP-0001) and stack ADR (WP-0002-T01) need explicit human checkpoint gates that are not yet encoded as workplan milestones or decision records.
|
||
|
||
---
|
||
|
||
### Opportunities
|
||
|
||
1. **Occupy a clear niche**
|
||
Publish TRF as the first well-specified *development-target-triggered* delayed-commons model with a public, verifiable ledger and default zero allocation for operations revenue—directly answering “what payments unlock the code?”
|
||
|
||
2. **Ship a reference pilot on a real internal product**
|
||
A single Phase on a controlled product (e.g. an ecosystem tool the founder controls) would force degeneration, evidence, and commercial-use definitions to become concrete faster than pure research.
|
||
|
||
3. **JSON Schema + golden fixtures as the “spec that runs”**
|
||
Extract TSD §3 into schemas and a pure fold library *before* a full service. That delivers NFR-1/NFR-3 value with less surface area than WP-0002’s full bootstrap.
|
||
|
||
4. **Canonical profiles as product UX**
|
||
Six default profiles with worked numbers (already sketched in concept §11 and §23) can become the marketing and onboarding surface—many users will never read the license kernel.
|
||
|
||
5. **Prior-art research as public positioning**
|
||
Completing WP-0001 (BSL, FSL, Fair Source, PolyForm, ELv2, SSPL-adjacent, OSI boundaries) yields both legal grounding and a comparison matrix usable for external communication.
|
||
|
||
6. **Hub-native multi-agent delivery**
|
||
With workplans already hub-linked, the repo can become a showcase for disciplined agent execution (ralph-workplan, fix-consistency) if sequencing is fixed and tasks are sliced to token-budget size.
|
||
|
||
7. **Cross-domain framing**
|
||
Secondary `financials` classification and ledger/attestation design open doors to auditor, sponsor, and finance-adjacent tooling without changing the core license story.
|
||
|
||
8. **Contributor and patent profiles as family productization**
|
||
`TRSL-MIT` / `TRSL-ALv2` (already suggested in exploration and concept) can productize Future License choice once patent research (WP-0001-T03) lands.
|
||
|
||
---
|
||
|
||
### Threats
|
||
|
||
1. **Legal and standard-terms risk**
|
||
Automatic conversion, ambiguous “commercial use,” AGB-style clarity duties (e.g. German §307 BGB as flagged in exploration), and cross-border enforceability can invalidate the bargain or scare commercial counsel. Specialist review is mandatory before any real Phase.
|
||
|
||
2. **Trust-service capture (perception or fact)**
|
||
If operators appear able to delay ledgers, withhold attestations, or soft-edit history, the automatic-conversion promise fails socially even if legal text is pure. Centralized Stage 0 amplifies this perception.
|
||
|
||
3. **Complexity / adoption barrier**
|
||
Phase manifests, extensions, dual credit types, and evidence tiers may lose independent developers who would accept a simpler BSL-style Change Date. If the kernel is not explainable in one breath *and* operable with defaults, the framework remains theoretical.
|
||
|
||
4. **Community and terminology backlash**
|
||
Mislabeling pre-conversion software as “Open Source” invites OSI and community rejection. Guardrails exist in docs but not yet in README or contributor templates.
|
||
|
||
5. **Premature implementation lock-in**
|
||
Building storage and APIs before degeneration, FX, and evidence rules settle creates expensive rewrites or, worse, non-deterministic Outstanding Target implementations in the wild.
|
||
|
||
6. **Abandoned-phase reputation risk**
|
||
Without a fixed Longstop or reliable remission, unsuccessful Phases look like permanent proprietary licensing with open-source marketing. That is both a fairness threat and a PR threat.
|
||
|
||
7. **Operator discontinuity**
|
||
If the only Trust Service disappears, users must still recompute conversion from exported packages. Without export tooling and offline fold, discontinuity becomes a license-confidence crisis (open question 13).
|
||
|
||
8. **Competitive simplicity**
|
||
BSL/FSL/Fair Source already ship usable legal text. TRF’s economic sophistication is an advantage only if accompanied by usable instruments; otherwise adopters will choose “good enough” time triggers.
|
||
|
||
9. **Internal scope creep across the founder’s portfolio**
|
||
Monetization classes (ideation, consulting, ops) invite encoding company-wide pricing policy into the framework. Complexity-budget violations would bloat the core and slow convergence.
|
||
|
||
10. **Agent-driven inconsistency**
|
||
Multiple agents editing concept/PRD/TSD/workplans without a term glossary freeze and schema CI can reintroduce synonym drift (“Revenue Credit” vs “Development Credit”) that the framework was designed to eliminate.
|
||
|
||
---
|
||
|
||
## 4. Improvements addressing the most relevant weaknesses
|
||
|
||
Improvements are ordered by **leverage on trust, correctness, and near-term delivery**. Each item maps to one or more weaknesses above.
|
||
|
||
### P0 — Unblock clarity and stop self-inflicted friction (days)
|
||
|
||
| # | Improvement | Weaknesses addressed | Concrete action |
|
||
| --- | ---: | --- | --- |
|
||
| I-01 | **Expand README into an orientation map** | W5, W8, T4 | Status (concept/spec only; not production legal text); one-sentence bargain; terminology guardrail (source-available ≠ OSI Open Source pre-conversion); reading order (INTENT → concept §1–10 → PRD → TSD); links to workplans and open questions; “do not attach TRSL to production code yet.” |
|
||
| I-02 | **Add `SCOPE.md` as living counterpart to INTENT** | W6, W9 | Declare current maturity: Stage 0 concept + orientation specs; in-scope now (normative extraction, prior art, golden example package); out-of-scope now (production Trust Service, federation Stage 2+, multi-stakeholder governance). Close the INTENT→SCOPE gap intentionally. |
|
||
| I-03 | **Doc hygiene pass** | W6 | Remove trailing `xxx` from concept doc; decide and document `spec/` vs `specs/` policy (keep concept in `spec/` with a root pointer, or migrate with redirects in README); update TSD §7 tree to match reality. |
|
||
| I-04 | **Encode human gates on legal/stack decisions** | W12, T1 | In WP-0001 and WP-0002, mark T06 (license skeleton) and T01 (stack ADR) as requiring explicit human accept before downstream tasks claim completion. Prefer decision records under `decisions/` or hub `resolve_decision` when available. |
|
||
|
||
### P1 — Fix sequencing and create runnable specification (1–2 weeks)
|
||
|
||
| # | Improvement | Weaknesses addressed | Concrete action |
|
||
| --- | ---: | --- | --- |
|
||
| I-05 | **Resequence or split WP-0002** | W2, W3, T5 | Prefer: (a) pause implementation tasks T02–T06 until Phase 1 normative docs exist; or (b) rewrite WP-0002 as “schema + pure fold library + golden fixture” without service hosting; keep T01 ADR only if needed for that thin library. Align workplan status narrative with PRD Phases 1→4. |
|
||
| I-06 | **Extract normative core docs (PRD Phase 1)** | W2, W7 | Produce at minimum: `TargetRevenueFrameworkCore.md`, `PhaseManifestSpecification.md`, `TargetLedgerSpecification.md` by *extracting* concept §7–10, §16–18 and TSD §3—not rewriting. Freeze term glossary and formulas there. |
|
||
| I-07 | **Machine-readable schemas + offline validators** | W4, W11, T10 | JSON Schema (or equivalent) for Phase Manifest, Ledger Entry, Extension Contract, Conversion Attestation; pure Outstanding Target fold; CLI or library `validate` / `fold` commands. Makes TSD §5 real. |
|
||
| I-08 | **Golden Phase package (concept §23)** | W7, T7 | Directory e.g. `examples/phase-001/` with manifest, ledger entries, expected outstanding series, conversion attestation stub. Wire to automated tests. This is the cheapest credibility boost for NFR-1. |
|
||
| I-09 | **Provisional defaults for blocking open questions** | W3, T6 | Publish `specs/OpenQuestions-WorkingDefaults.md` (or PRD appendix) with *non-final* choices: Longstop required yes/no; currency = phase-native only for v0; recognition = payment-settled only; minimum evidence levels; commercial-use pointer to a working definition. Mark each as provisional pending research. Unblocks schema enums and legal skeleton. |
|
||
|
||
### P2 — Legal grounding and economic completeness (parallel track)
|
||
|
||
| # | Improvement | Weaknesses addressed | Concrete action |
|
||
| --- | ---: | --- | --- |
|
||
| I-10 | **Execute WP-0001 fully** | W3, W8, O5 | Complete prior-art matrix (T01), terminology guardrails (T02), patent/Future License rec (T03), CLA vs DCO (T04), jurisdiction clarity flags (T05), non-binding `TargetRevenueSourceLicense-Draft.md` skeleton (T06). |
|
||
| I-11 | **Degeneration policy research as first-class artifact** | W3, T6 | `TargetDegenerationPolicyResearch.md` with 2–3 candidate formulas (fixed longstop only; linear time remission; progress-sensitive + longstop floor), worked numbers, and a recommended default for Stage 0 pilots. |
|
||
| I-12 | **Canonical monetization profiles doc** | W7, O4 | Six profiles with YAML examples, default allocation, and one “gotcha” each (e.g. ops surcharge must not silently count). Becomes onboarding surface. |
|
||
| I-13 | **Contributor rights interim policy** | W8, T1 | Even before final CLA: `CONTRIBUTING.md` stating that external contributions are not accepted into governed Milestone Releases until rights instrument exists; DCO optional for docs-only. Prevents accidental unconvertible code. |
|
||
|
||
### P3 — Trust, governance, and growth hygiene (after Stage 0 core)
|
||
|
||
| # | Improvement | Weaknesses addressed | Concrete action |
|
||
| --- | ---: | --- | --- |
|
||
| I-14 | **Trust Service PRD before full service code** | W2, T2 | Per original MVP list: `TrustServiceProductRequirementsDocument.md` focused on Stage 0–1 (centralized + public verification/export). Implementation follows schemas + pure fold, not the reverse. |
|
||
| I-15 | **Export / discontinuity story** | T7, open Q13 | Specify offline phase evidence package format and operator continuity policy *as docs* even while service is toy-grade. |
|
||
| I-16 | **Lightweight CI** | W11, T10 | Link check; glossary consistency (forbidden synonyms); schema validate on `examples/`; markdown structure checks. |
|
||
| I-17 | **Capability tags and discovery** | W10 | Fill `.repo-classification.yaml` tags (e.g. licensing, monetization-framework, delayed-open-source, trust-ledger). Reflect in README. |
|
||
| I-18 | **Governance sketch (lightweight)** | W9, O6 | Short `TRSL-Governance-Draft.md`: who can change core terms, how extensions get `canonical`, conflict-of-interest when operator is also licensor—enough for Stage 0 honesty, not multi-stakeholder final form. |
|
||
|
||
---
|
||
|
||
## 5. Recommended near-term sequence
|
||
|
||
```text
|
||
1. I-01…I-04 Doc entry + SCOPE + hygiene + human gates
|
||
2. I-05 Re-scope WP-0002 so implementation does not outrun norms
|
||
3. I-06…I-08 Core extract + JSON Schema + golden example
|
||
4. I-09 Working defaults for open questions
|
||
5. I-10…I-12 Prior art, degeneration research, canonical profiles (// parallel with 3–4)
|
||
6. I-13 CONTRIBUTING / no premature external Phase code
|
||
7. I-14…I-18 Trust Service PRD, export story, CI, tags, light governance
|
||
8. Only then Full registry/ledger service implementation (original WP-0002 T02–T06 or successor)
|
||
```
|
||
|
||
**Success signal for the next milestone (suggested “Stage 0 package”):**
|
||
|
||
- A newcomer can explain the five-verb lifecycle from README + core doc alone.
|
||
- Offline tools validate a golden Phase and recompute Outstanding Target to zero without any network service.
|
||
- Open questions have provisional defaults or explicit “blocked on legal” labels.
|
||
- WP-0001 research artifact exists; legal draft is marked non-binding and not used in production.
|
||
- SCOPE.md honestly states what is *not* yet claimed.
|
||
|
||
---
|
||
|
||
## 6. Overall judgment
|
||
|
||
| Dimension | Rating (1–5) | Note |
|
||
| --- | ---: | --- |
|
||
| Conceptual clarity | 5 | Rarely this clean at concept stage |
|
||
| Specification completeness | 3.5 | Strong orientation; missing normative extract + schemas |
|
||
| Legal readiness | 1.5 | Correctly deferred; research workplan exists, not executed |
|
||
| Implementation readiness | 2 | TSD is enough to start a *library*; not enough for a stable *service* |
|
||
| Governance / process | 3 | Hub-integrated workplans; human gates and SCOPE incomplete |
|
||
| Adoption readiness | 1.5 | README and example package insufficient for external use |
|
||
| Strategic differentiation | 4 | Credible niche if simplicity and trust are preserved |
|
||
|
||
**Bottom line:** The repository’s strength is intellectual architecture; its weakness is unfinished operationalization and a slight rush toward Trust Service code before the normative and legal floor is nailed down. The highest-ROI improvements are **orientation (README/SCOPE), resequencing implementation behind extractable schemas and a golden fold example, executing prior-art research, and publishing provisional defaults for conversion-critical open questions.** Do those before expanding federation, multi-provider, or catalog breadth.
|
||
|
||
---
|
||
|
||
## 7. Sources reviewed
|
||
|
||
- `README.md`, `INTENT.md`, `LICENSE`
|
||
- `spec/TargetRevenueLicenseConcept.md` (full)
|
||
- `specs/ProductRequirementsDocument.md`, `specs/TechnicalSpecificationDocument.md`
|
||
- `history/260728-InitialExploration.md` (structure and conclusions)
|
||
- `workplans/TREV-WP-0001-license-prior-art-research.md`
|
||
- `workplans/TREV-WP-0002-trust-service-implementation-bootstrap.md`
|
||
- `WORK-RECORDS.md`, `.custodian-brief.md`, `.repo-classification.yaml`
|
||
- Git history (initial concept → PRD/TSD/workplans → classification/consistency sync)
|
||
|
||
---
|
||
|
||
*This document is an assessment artifact under `history/`. It is non-normative and does not amend INTENT, concept, PRD, or TSD.*
|