tegwick
19402f3115
Establishes specs/ProductRequirementsDocument.md and specs/TechnicalSpecificationDocument.md, plus two workplans: prior-art research for the TargetRevenueSourceLicense draft, and bootstrapping the Trust Service reference implementation. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
126 lines
4.7 KiB
Markdown
126 lines
4.7 KiB
Markdown
---
|
|
id: TREV-WP-0002
|
|
type: workplan
|
|
title: "Trust Service implementation bootstrap"
|
|
domain: infotech
|
|
repo: target-revenue
|
|
status: active
|
|
owner: claude
|
|
topic_slug: infotech
|
|
created: "2026-07-28"
|
|
updated: "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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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).
|