target-revenue/workplans/TREV-WP-0002-trust-service-implementation-bootstrap.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated
TREV-WP-0002	workplan	Trust Service implementation bootstrap	infotech	target-revenue	active	claude	infotech	2026-07-28	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

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

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

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

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

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

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).