Add Control Plane + Development Effort Calculator concepts and workplan

specs/TargetRevenueControlPlaneConcept.md: an interactive UI over the hosted Trust Service for the binky tenant, prioritizing interactive Development Credit entry creation. Flags the actual new design gap WP-0006 didn't need to solve: one Licensor token vs. multiple human users needing individually attributable actions - recommends the Control Plane hold the Licensor token server-side and layer its own human-user auth/audit log in front, rather than requiring a WP-0006 auth schema change, while leaving the choice to a human gate (T02). specs/DevelopmentEffortCalculatorConcept.md: turns four metric families (human interaction time via commit-clustering, workplan/task volume, file/line complexity, AI token cost via the state hub's get_token_summary) into target_basis values feeding the framework's own existing Initial Target formula - not a new formula. Presents two combination strategies (labor-cost-anchored vs. composite-index) as alternatives for a human gate (T01) rather than picking one. workplans/TREV-WP-0009-control-plane-and-effort-calculator.md: 5 tasks (two human-gated formula/rights decisions, two implementation tasks, one task to apply the calculator to the real candidate repos already identified in WP-0008). Explicitly does not declare any real Phase - both deliverables feed WP-0008-T05's own gate, they don't bypass it.
2026-07-30 01:29:13 +02:00 · 2026-07-30 01:29:13 +02:00 · b93a60442c
commit b93a60442c
parent dcf6de57a4
4 changed files with 478 additions and 0 deletions
--- a/README.md
+++ b/README.md
@ -81,6 +81,7 @@ The concept's §13 now defines a **Global Contingency Share Determination Rule**
 | [TREV-WP-0006](workplans/TREV-WP-0006-trust-service-implementation.md) | Hosted Trust Service reference implementation (PRD Phase 4b) — **finished**, all 9 tasks done (Postgres-backed registries/ledger/metrics/attestation/breach-record, ADR-0002 accepted, onboarding CLI, hosted conformance suite) |
 | [TREV-WP-0007](workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md) | Degeneration policy + canonical monetization profile catalog — **finished**, all 4 tasks done. `trsl:policy:linear-longstop-v0` confirmed 2026-07-29 as the v1 norm for the first pilot cohort; `progress-paused-longstop-v1` named as the next iteration, not yet adopted |
 | [TREV-WP-0008](workplans/TREV-WP-0008-governance-and-pilot-rollout.md) | Governance formalization + pilot rollout — active; T01–T04 done. `info-tech-canon` dry-run onboarding routine exercised end-to-end 2026-07-29. **Org-wide TRSL license adoption executed 2026-07-30** across ~90 `coulomb`-org repos (`history/260730-TRSL-OrgWideLicenseRollout.md`) — a license-text adoption, not a Phase declaration. T05 (real Phase go-live gate) remains `todo` by design; no Phase exists yet for any repo |
+| [TREV-WP-0009](workplans/TREV-WP-0009-control-plane-and-effort-calculator.md) | Target Revenue Control Plane (interactive UI for the `binky` tenant, incl. interactive Development Credit entry creation) + Development Effort Calculator (turns human time/workplan-task volume/repo size/AI token cost into `target_basis` values) — active, concepts only so far (`specs/TargetRevenueControlPlaneConcept.md`, `specs/DevelopmentEffortCalculatorConcept.md`); T01/T02 human-gated formula/rights decisions not yet made |

 Hub index: [`WORK-RECORDS.md`](WORK-RECORDS.md) · brief: [`.custodian-brief.md`](.custodian-brief.md)

--- a/specs/DevelopmentEffortCalculatorConcept.md
+++ b/specs/DevelopmentEffortCalculatorConcept.md
@ -0,0 +1,209 @@
+# Development Effort Calculator — Concept
+
+Status: Concept v0.1
+Date: 2026-07-30
+Workplan: `workplans/TREV-WP-0009-control-plane-and-effort-calculator.md`
+Primary artifacts: `specs/TargetRevenueFrameworkCore.md` §1.4 (Target Multiple, Initial Target formula), `specs/PhaseManifestSpecification.md` (`target_basis` fields), state hub `get_token_summary`/`get_recent_progress`/`list_tasks` tools
+
+**Scope note:** this is a concept for a **working, explicitly refinable v0
+estimator** — not a final, authoritative valuation methodology. Every
+formula below is a starting point the maintainer expects to iterate on
+once real repos produce real data, consistent with how
+`specs/TargetDegenerationPolicyResearch.md` treated its own formula
+proposal.
+
+---
+
+## 1. What this calculator produces
+
+It does **not** invent a new target-setting mechanism. It produces
+concrete values for the fields `specs/PhaseManifestSpecification.md`
+already defines under `phase.target_basis`:
+
+- `estimated_effort_days`
+- `daily_rate`
+- `approved_direct_costs`
+- `target_multiple`
+
+and lets `specs/TargetRevenueFrameworkCore.md` §1.4's existing formula do
+the rest:
+
+```
+Estimated Development Cost = (estimated_effort_days × daily_rate) + approved_direct_costs
+Initial Target             = Estimated Development Cost × Target Multiple
+```
+
+This calculator's job is narrowly: turn measurable repo activity into
+defensible values for the left-hand side, and turn a repo's Target
+Multiple *classification* (10x/100x/1000x — Incremental/Product-defining/
+Platform-defining) into the right-hand multiplier, per the same guidance
+table already in `specs/TargetRevenueFrameworkCore.md` §1.4. It is a
+value-input tool feeding an existing formula, not a competing formula.
+
+## 2. Input metrics (v0 candidate set)
+
+Four metric families, per the maintainer's request:
+
+### 2a. Human interaction time
+
+**What:** hours a human spent interacting with the repo in any way
+(coding sessions, review, planning conversations).
+
+**Candidate sources, weakest to strongest signal:**
+- Git commit timestamp clustering: group commits into sessions (a gap
+  threshold, e.g. commits within 2 hours of each other belong to the same
+  session), sum session durations. Cheap, works on any repo's existing
+  history, but systematically undercounts (thinking/reading time between
+  commits, non-commit work).
+- State hub `get_recent_progress`/session records for repos already
+  tracked there — likely more accurate for repos actively worked on
+  through this agent/hub workflow, but not available for repos with no
+  hub-tracked history.
+- Explicit human-logged time (a repo's own time-tracking, if it has one) —
+  most accurate where available, not universal.
+
+**v0 default:** commit-timestamp clustering, since it works uniformly
+across every repo without depending on hub coverage — explicitly a
+*floor* estimate (real effort is almost certainly higher), not a
+best-effort true count.
+
+### 2b. Workplan/task volume — complexity index component
+
+**What:** number and status distribution of workplans and tasks
+associated with the repo (state hub `list_tasks`/`list_workplans` scoped
+to the repo, or direct inspection of a `workplans/` directory as this
+repo's own convention already does).
+
+**v0 formula sketch:** `complexity_units_workplans = finished_workplans × 3 + finished_tasks × 1`
+(a workplan is worth more than a bare task, since it implies scoping and
+sequencing work beyond the sum of its tasks) — **weights are placeholders,
+not derived from any data yet**, flagged explicitly for refinement once
+multiple repos' actual effort-vs-workplan-count relationship is known.
+
+### 2c. Repo size — complexity index component
+
+**What:** file count and line count in the repo, as a raw
+complexity/scope proxy.
+
+**v0 formula sketch:** `complexity_units_size = file_count × 0.1 + line_count × 0.001`
+— deliberately crude (a config repo with 10,000 generated lines is not
+"more effort" than a 500-line algorithm-dense repo), which is exactly why
+this is one input among several, not a standalone valuation. **Known
+distortion to correct for in refinement:** vendored/generated
+files/lines, `node_modules`-style dependency trees, and lockfiles
+inflate this signal without reflecting real effort — a v1 refinement
+should exclude common generated/vendored paths (`.gitignore`-aware or an
+explicit exclude list) before counting.
+
+### 2d. AI token cost — estimated and consumed
+
+**What:** the actual $ cost of AI-assisted implementation work on this
+repo, both consumed-to-date and, where a task is still in flight,
+estimated to completion.
+
+**Source:** the state hub already tracks this — `get_token_summary(scope="repo", id=<repo_id>)`
+aggregates recorded token consumption per repo, populated via
+`record_token_event`. This is the **strongest, least speculative** input
+in this whole set, since it is a real, metered cost already being
+recorded for other purposes (token budget policy), not a proxy.
+
+**v0 formula sketch:** `token_cost_usd = tokens_in × input_price_per_token + tokens_out × output_price_per_token`,
+using the actual per-model pricing for whatever model(s) `get_token_summary`
+reports were used — this is not an estimate at all where data exists, it
+is a direct cost figure; it only becomes an *estimate* for effort not yet
+performed (extrapolating from a partial task to its expected completion).
+
+## 3. Combining the metrics — v0 formula (explicitly provisional)
+
+Two candidate combination strategies, presented as alternatives for the
+maintainer to weigh rather than a single forced answer (matching
+`specs/TargetDegenerationPolicyResearch.md`'s own pattern of presenting,
+not silently picking, a design fork):
+
+### Candidate A — labor-cost-anchored (recommended v0 default)
+
+Treat human time as the primary cost driver (`estimated_effort_days`,
+`daily_rate` directly), and route token cost into `approved_direct_costs`
+(a real, metered direct cost, exactly what that field is for per
+`specs/OpenQuestions-WorkingDefaults.md` Q5). The workplan/task-volume and
+repo-size complexity indices (§2b, §2c) are used as a **sanity check /
+adjustment factor** on the human-time estimate — e.g., if commit-timestamp
+clustering suggests very little time but the repo has a large, mature
+workplan/task history, that's a signal the time-tracking input is
+under-counting and should be revised upward, not a separate dollar figure
+of its own.
+
+```
+estimated_effort_days   = (commit-clustered hours) / 8   [sanity-adjusted per §2b/§2c signal]
+daily_rate              = a declared, repo-independent rate (not computed from metrics)
+approved_direct_costs   = token_cost_usd (from §2d)
+target_multiple         = per the Target Multiple classification (§4)
+```
+
+### Candidate B — composite-index-anchored
+
+Convert every metric family into a common "complexity unit" score
+(weighted sum across §2a–§2d, all four as scored inputs, not three
+checking one), then map the total score to a dollar figure via a
+declared $-per-unit rate. More uniform across very different repos
+(a repo with almost no logged human time but a huge, real workplan/task
+history and heavy AI-token spend wouldn't be under-valued the way
+Candidate A might undervalue it), but introduces a second calibration
+constant ($-per-complexity-unit) with even less grounding than
+`daily_rate` has.
+
+**This document does not choose between A and B** — that is exactly the
+kind of working default a future task (see workplan T02) should propose
+and a maintainer should confirm, the same way
+`specs/TargetDegenerationPolicyResearch.md` handled the degeneration
+formula fork.
+
+## 4. Target Multiple classification (the Nx factor)
+
+Reuses `specs/TargetRevenueFrameworkCore.md` §1.4's existing guidance
+table unchanged — this calculator does not redefine what 10x/100x/1000x
+mean, it only needs a repeatable way to *classify* a given repo/Phase
+against that existing table:
+
+| Class | Multiple | Indicative interpretation (unchanged from framework core) |
+|---|---:|---|
+| Commons | 0x | Immediate permissive release or no development monetization target |
+| Recovery | 1x | Direct development cost recovery |
+| Incremental | 10x | Material enhancement of an existing use case |
+| Product-defining | 100x | Significant commercial differentiator or new product capability |
+| Platform-defining | 1000x | New platform, market, ecosystem, or foundational capability |
+
+**v0 approach: human classification, calculator-assisted, not
+calculator-decided.** The calculator can surface signals relevant to the
+choice (e.g., "this repo's capability is consumed by N other repos" as a
+platform-defining signal, drawing on state hub repo-dependency data where
+available) but per `specs/TargetRevenueFrameworkCore.md` §1.4's own
+framing ("represents a product and commercial hypothesis, not an
+objectively measurable claim"), the actual classification choice remains
+a human judgment call, not an automated output. This mirrors
+`specs/PilotPhaseCandidateSurvey.md`'s own indicative classifications,
+which were reasoned, not computed.
+
+## 5. Worked illustration (not a real valuation)
+
+Using `info-tech-canon`'s dry-run draft manifest
+(`examples/pilot-candidates/info-tech-canon-service-surface/manifest.json`)
+purely as a shape check, not a claim that these numbers are its real
+value: 25 estimated effort days × 1000/day = 25,000, + 0 direct costs
+(no real token-cost data pulled for this illustration) = 25,000 Estimated
+Development Cost × 100 (Product-defining) = 2,500,000 — matching the
+draft manifest's existing illustrative figures, which were hand-picked,
+not calculator-derived. A real application of this calculator to
+`info-tech-canon` (or any repo) is future work once §3's formula choice
+is confirmed (workplan T02) and implemented (T03).
+
+## 6. Non-goals
+
+- Choosing Candidate A vs. B — a human decision, workplan T02.
+- Implementing the actual calculator (data collection + formula code) —
+  workplan T03.
+- Producing a real Initial Target for any specific repo — that requires
+  both this calculator's implementation and a human Target Multiple
+  classification decision per repo, neither done here.
+- Replacing or reinterpreting `specs/TargetRevenueFrameworkCore.md` §1.4's
+  existing formula — this calculator feeds it, it does not compete with it.
--- a/specs/TargetRevenueControlPlaneConcept.md
+++ b/specs/TargetRevenueControlPlaneConcept.md
@ -0,0 +1,136 @@
+# Target Revenue Control Plane — Concept
+
+Status: Concept v0.1
+Date: 2026-07-30
+Workplan: `workplans/TREV-WP-0009-control-plane-and-effort-calculator.md`
+Primary artifacts: `specs/TrustServiceProductRequirementsDocument.md`, `src/target_revenue/service/app.py`, `specs/TRSL-Governance.md` §1 (Licensor identity), `scripts/trf_onboard.py`
+
+**Scope note:** this is a concept, not an implementation. It defines what
+the Control Plane UI is for, who uses it, and what it must and must not
+be able to do — building directly on the hosted Trust Service
+(`workplans/TREV-WP-0006-trust-service-implementation.md`, finished) and
+the onboarding mechanism (`specs/TrustServiceOnboarding.md`) rather than
+replacing either.
+
+---
+
+## 1. Purpose
+
+Everything in `scripts/trf_onboard.py` today is a CLI, operated by
+whoever has shell access and the Licensor's token in an environment
+variable. That is adequate for the dry-run routine already exercised
+(`info-tech-canon`), but not adequate for **an actual "binky tenant" user**
+— someone who should be able to interactively register Phases, review
+Phase status, and — the maintainer's specific requirement — **interactively
+create Development Credit ledger entries**, without needing to construct
+raw JSON payloads or hold the Licensor's raw API token directly in their
+own shell environment.
+
+The Control Plane is a web (or equivalent interactive) front end over the
+existing hosted Trust Service API (`service/app.py`), for the `binky`
+tenant specifically, not a replacement for that API or a new Trust
+Service instance.
+
+## 2. Users and rights model — the actual new design gap
+
+**This is the concept's main open design question**, not something WP-0006
+already solved: WP-0006's auth model is **one token per Licensor**
+(`migrations/0001_registries.sql`'s `licensors` table), sufficient for a
+script or CI pipeline acting *as* the Licensor, but not sufficient for
+**multiple human users**, potentially with **different rights**, acting
+*on behalf of* the same Licensor tenant (`binky`).
+
+**Candidate rights tiers** (not yet decided, proposed for workplan T01 to
+resolve):
+
+| Right | Can do |
+|---|---|
+| Viewer | Read Phase status, metrics, ledger, attestations, breach records (all already public per FR-9/FR-10 — a Viewer arguably needs no new auth at all, since these are unauthenticated reads today) |
+| Contributor | Everything Viewer can, plus: submit a *proposed* Development Credit entry for review (not directly appended) |
+| Operator | Everything Contributor can, plus: directly append Development Credit/Remission Credit entries, register new Phases, publish breach/compliance records |
+| Admin | Everything Operator can, plus: manage which human users hold which right within the `binky` tenant |
+
+**Design tension to resolve, not paper over:** WP-0006's Ledger append API
+(`ledger.append_entry`) currently authenticates a single Licensor token,
+not an individual human user — so "Operator Alice" and "Operator Bob"
+both acting for `binky` are currently indistinguishable at the API layer
+(both just look like "the `binky` token"). Either (a) the Control Plane
+issues per-human-user sub-credentials that map to the same underlying
+Licensor identity (requiring a schema/API change in WP-0006's auth
+layer — a real, scoped follow-on task), or (b) the Control Plane holds
+the one Licensor token server-side and layers its own human-user
+authentication/authorization in front of it, recording *which human*
+took an action in its own audit log distinct from the Trust Service's
+own record (simpler, no WP-0006 changes required, but the Trust
+Service's own signed records still only attest "the `binky` Licensor did
+this," not "Alice, acting for `binky`, did this"). **Recommendation: start
+with (b)** — it requires no changes to the already-finished, tested
+WP-0006 auth model, and the Control Plane's own audit log (§5) can carry
+the finer-grained human-attribution that the Trust Service's own
+cryptographic signature does not need to.
+
+## 3. Core interactive flow: creating a Development Credit entry
+
+The maintainer's specific requirement. Concretely, for an Operator-tier
+user:
+
+1. Select a registered Phase (from a list, via `GET /phases/{id}` reads —
+   already public, already implemented).
+2. Fill a form for a new `development-credit` ledger entry: amount,
+   currency, recognized date, evidence reference, applicable Monetization
+   Extension (selected from `specs/CanonicalMonetizationProfiles.md`'s
+   catalog, not free text).
+3. The Control Plane server-side calls `POST /phases/{id}/ledger`
+   (`ledger.append_entry`, already implemented, WP-0006-T04) using the
+   `binky` Licensor token it holds — the human user never sees or handles
+   that token directly.
+4. The Control Plane records, in its own audit log (§5), which human user
+   initiated this specific entry, alongside the Trust Service's own
+   returned signed record.
+5. Display the updated Phase status (`GET /phases/{id}/metrics`, already
+   implemented) immediately after, so the user sees the effect of what
+   they just did.
+
+**Nothing here requires changing the Ledger append API itself** — the
+Control Plane is a client of it, exactly like `scripts/trf_onboard.py` is
+today, just interactive and multi-user rather than single-shot CLI.
+
+## 4. Other interactive capabilities (lower priority than §3)
+
+- Registering a new Phase, using the Development Effort Calculator
+  (`specs/DevelopmentEffortCalculatorConcept.md`) to help populate
+  `target_basis`, rather than requiring the user to hand-author a JSON
+  manifest.
+- Viewing the Breach/Compliance Record history for a Phase and initiating
+  a new breach/cure/determined event (Operator+ only, per License V1C1
+  §7.4's Licensor-determination principle — the Control Plane must not
+  let this become the Control Plane's own discretionary judgment about
+  whether a breach occurred, consistent with TSD §4.1's forbidden-action
+  column).
+- Viewing the Conversion Attestation once a Phase converts (read-only,
+  already public).
+
+## 5. Audit logging — a Control Plane responsibility, not a Trust Service one
+
+Every write action taken through the Control Plane must be logged with:
+which human user, what action, when, and the resulting Trust-Service-
+signed record's id — **in the Control Plane's own storage**, since the
+Trust Service itself has no concept of individual human users under one
+Licensor token (§2). This log is the answer to "who actually clicked the
+button," which matters operationally even though it's not part of the
+Trust Service's own cryptographic guarantees.
+
+## 6. Explicit non-goals
+
+- Replacing `scripts/trf_onboard.py` — the CLI remains valid for
+  scripted/CI use; the Control Plane is for interactive human use.
+- Changing the Trust Service's core guarantees (determinism, append-only,
+  no discretionary conversion authority) — the Control Plane is a client,
+  bound by the same rules any other client is.
+- Deciding the human-user rights model unilaterally — §2 is a proposal
+  for workplan T01 to confirm, not a decided design.
+- Multi-tenant support for Licensors other than `binky` — in scope
+  structurally (the Trust Service already supports multiple Licensors,
+  TS-FR-8), but this concept is scoped to the one tenant that currently
+  exists; extending the UI to other tenants is natural future work, not
+  blocking this concept.
--- a/workplans/TREV-WP-0009-control-plane-and-effort-calculator.md
+++ b/workplans/TREV-WP-0009-control-plane-and-effort-calculator.md
@ -0,0 +1,132 @@
+---
+id: TREV-WP-0009
+type: workplan
+title: "Target Revenue Control Plane and Development Effort Calculator"
+domain: infotech
+repo: target-revenue
+status: active
+owner: claude
+topic_slug: infotech
+created: "2026-07-30"
+updated: "2026-07-30"
+---
+
+# Target Revenue Control Plane and Development Effort Calculator
+
+Builds the two pieces the maintainer identified as needed to move from
+"license text adopted org-wide" (`history/260730-TRSL-OrgWideLicenseRollout.md`)
+toward actually declaring real Phases with defensible Initial Targets:
+
+1. A **Control Plane** — an interactive UI over the hosted Trust Service
+   (`workplans/TREV-WP-0006-trust-service-implementation.md`, finished),
+   usable by a human user with appropriate rights acting as the `binky`
+   tenant, to interactively register Phases and — the specific,
+   named requirement — create Development Credit ledger entries
+   interactively rather than via raw API calls or the CLI.
+2. A **Development Effort Calculator** — turns measurable repo activity
+   (human interaction time, workplan/task volume, file/line complexity,
+   AI token cost) into `target_basis` values
+   (`specs/PhaseManifestSpecification.md`), which combined with a human
+   Target Multiple classification (10x/100x/1000x) produces a proposed
+   Initial Target via the framework's own existing formula
+   (`specs/TargetRevenueFrameworkCore.md` §1.4) — not a new formula.
+
+**Does not include:** declaring any real Phase for any repo. Both
+deliverables here are inputs to that decision
+(`workplans/TREV-WP-0008-governance-and-pilot-rollout.md` T05), not a way
+to bypass it.
+
+## Development Effort Calculator — formula decision (human gate)
+
+```task
+id: TREV-WP-0009-T01
+status: todo
+priority: high
+human_accept_required: true
+```
+
+`specs/DevelopmentEffortCalculatorConcept.md` §3 presents two combination
+strategies without choosing between them: Candidate A (labor-cost-
+anchored — human time drives `estimated_effort_days`/`daily_rate`, token
+cost becomes `approved_direct_costs`, workplan/file metrics are a sanity
+check) or Candidate B (composite-index-anchored — all four metric
+families scored into one complexity index, converted via a $-per-unit
+rate). Confirm one as the adopted v0 approach (or propose a refinement),
+per the same human-gate pattern already used for the degeneration policy
+formula (`workplans/TREV-WP-0007-degeneration-policy-and-canonical-profiles.md` T02).
+Agents may prepare a recommendation and leave this `todo`.
+
+## Control Plane user rights model — decision (human gate)
+
+```task
+id: TREV-WP-0009-T02
+status: todo
+priority: high
+human_accept_required: true
+```
+
+`specs/TargetRevenueControlPlaneConcept.md` §2 proposes a four-tier rights
+model (Viewer/Contributor/Operator/Admin) and recommends option (b) for
+the auth-attribution question (Control Plane holds the one Licensor
+token server-side, layers its own human-user auth/audit log in front of
+it, rather than requiring a WP-0006 schema change for per-human
+sub-credentials). Confirm the rights tiers and the (a)-vs-(b) choice, or
+propose a refinement. Agents may prepare a recommendation and leave this
+`todo`.
+
+## Implement Development Effort Calculator
+
+```task
+id: TREV-WP-0009-T03
+status: todo
+priority: high
+```
+
+Using T01's confirmed formula, implement the calculator: data collection
+(commit-timestamp clustering for human time; workplan/task counts via
+state hub `list_tasks`/`list_workplans` or direct `workplans/` directory
+inspection; file/line counts with generated/vendored-path exclusion per
+`specs/DevelopmentEffortCalculatorConcept.md` §2c's flagged distortion;
+token cost via `get_token_summary(scope="repo", id=...)`), and the
+combination formula itself, producing `target_basis` field values ready
+to drop into a Phase Manifest. Output must show its work (which inputs
+produced which numbers) — a black-box dollar figure with no visible
+derivation would undermine the "transparent, non-gameable" goal
+(`specs/TargetRevenueLicenseConcept.md` §4.6) this whole framework is
+built around.
+
+## Implement Control Plane (backend + interactive UI)
+
+```task
+id: TREV-WP-0009-T04
+status: todo
+priority: high
+```
+
+Using T02's confirmed rights model, implement the Control Plane: human
+user authentication, the rights-tiered action set from
+`specs/TargetRevenueControlPlaneConcept.md` §3–§4 (interactive Development
+Credit entry creation as the priority flow), and the Control Plane's own
+audit log distinct from the Trust Service's signed records (§5). Reuses
+the existing hosted Trust Service API (`service/app.py`) as its backend
+without modification unless T02 specifically selects the
+per-human-sub-credential option, in which case that WP-0006 auth
+extension is this task's prerequisite, not an assumed given.
+
+## Apply calculator to real candidate repos
+
+```task
+id: TREV-WP-0009-T05
+status: todo
+priority: medium
+```
+
+Once T03 is implemented, run it against the real candidates already
+identified (`specs/PilotPhaseCandidateSurvey.md`: `net-kingdom`'s
+`NK-WP-0002`, `railiance-apps`'s `vergabe-teilnahme`, and
+`info-tech-canon`'s service surface) to produce **proposed**, calculator-
+derived `target_basis` values, replacing the hand-picked illustrative
+figures currently in `examples/pilot-candidates/*/manifest.json`. This
+remains draft/non-binding — updating a draft manifest's numbers is not a
+Phase declaration, and does not touch
+`workplans/TREV-WP-0008-governance-and-pilot-rollout.md` T05's own gate.