target-revenue/workplans/TREV-WP-0013-remission-credit-automation.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
TREV-WP-0013	workplan	Remission Credit automation (degeneration policy execution)	infotech	target-revenue	active	claude	infotech	2026-07-30	2026-07-30	4a423219-2a3e-413c-b0dc-f8542c2afba1

Remission Credit automation (degeneration policy execution)

Spun out of workplans/TREV-WP-0012-phase-provenance-and-policy-modeling.md (use case 4). Every Phase declares a degeneration_policy (trsl:policy:linear-longstop-v0 is the accepted v1 norm, specs/OpenQuestions-WorkingDefaults.md Q7), which is supposed to generate remission-credit Target Ledger entries over time when Development Credit progress is insufficient (FR-6, specs/ProductRequirementsDocument.md). Nothing in this codebase currently computes or writes these entries. fold.py can consume them if they exist; nothing produces them. This gap predates the Control Plane UI work — it was never in scope for WP-0006 (Trust Service) or WP-0009 (Control Plane), and surfaced now only because reviewing the UI's Phase-registration flow prompted a fuller look at what a Phase's lifecycle actually requires end to end.

Blocked on workplans/TREV-WP-0012-phase-provenance-and-policy-modeling.md T03's decision (how a policy id maps to its spec file) — the implementation here should be checkable against that spec file, per the user's explicit requirement that policy code and policy specification stay verifiably in sync.

id: TREV-WP-0013-T01
status: wait
priority: high
state_hub_task_id: "d6ab7448-c009-4398-b616-560e8085cf1a"

Design the remission calculation and scheduling model. R(t) = T0 × clamp((t - t0)/(tL - t0), 0, 1) (Q7) needs: a chosen recognition cadence (daily/monthly UTC per Q7's own text), an idempotent "has this period's remission already been recorded" check (ledger entries are append-only — a re-run must not double-remit), and a decision on where t0 (Phase activation) comes from if it isn't already a manifest field (registration time? an explicit activated_at?). Cross-check against whatever trsl:policy:linear-longstop-v0's spec file (once WP-0012-T03 lands) says, rather than re-deriving the formula from Q7 prose alone.

id: TREV-WP-0013-T02
status: wait
priority: high
state_hub_task_id: "078da2e7-594b-4bd3-85b6-881a808f1ca2"

Implement and test the calculation as a pure function (mirroring fold.py's determinism discipline) plus whatever writes the resulting remission-credit entries into the hosted Target Ledger — a scheduled job, an on-demand Control Plane action, or both. Decide which actor "submits" these entries for attribution purposes (no human credential naturally owns a policy-driven entry) and record that decision explicitly rather than leaving submitted_by_token implicitly null.

id: TREV-WP-0013-T03
status: wait
priority: medium
state_hub_task_id: "fe12ee80-2868-4857-83ca-04bd7223e270"

Surface it in the Control Plane UI: phase_detail.html's Ledger table already renders remission-credit rows generically once they exist; verify that holds, and add a metrics-level explanation (e.g. next scheduled remission date/amount) if metrics.py doesn't already forecast one.