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

---
id: TREV-WP-0013
type: workplan
title: "Remission Credit automation (degeneration policy execution)"
domain: infotech
repo: target-revenue
status: active
owner: claude
topic_slug: infotech
created: "2026-07-30"
updated: "2026-07-30"
state_hub_workstream_id: "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.

```task
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.

```task
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.

```task
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.