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