Journey: A retroactive income correction recomputes a SNAP overpayment

Household composition — a single working-age adult, head of household, no dependents (headMember, date of birth 1985-06-15).

Initial reported income — $600/month in wages. That clears the SNAP gross-income test, so the application determines Approved — the starting point for the enrollment and issuances.

Backdated determination — the household, application, and determination are dated as of the first of the month ~3 months ago (asOf), so the paid months precede today.

Enrollment + paid benefits — approval auto-enrolls the household (#1014) and the settlement pass issues + settles the current benefit month at the determination’s net monthly benefit. That settled issuance is exactly the paid row the claim sizes against: the recompute window is pinned to the current month at both ends (the determination’s effective_date is the decision day), so backdated months could never contribute. A mailing address is also seeded so the overpayment notice can resolve its postal recipient (the #1091 gate).

Retroactive correction — $9,000/month in wages, effective as of the determination date. This is a construction extreme (well over any SNAP gross-income limit), so the corrected replay denies and the overpayment is positive.

Recompute inputs — correction-as-of = the determination date; claim basis = Agency error.

A claim opens with a positive amount (the construction extreme guarantees > 0) that equals the settled auto-issuance — the clawback is exactly what was paid.

Its overpayment notice surfaces on the Notices tab, matched by subject identity.

The replay is write-free — it mints no new determination.

The recompute is idempotent — re-running it returns the same claim (same amount, same id), never a second claim.

The aged case is a documented one-command harness bring-up. A determination backdated ~3 months with prior issuances the claim looks back on is neither hand-buildable nor portal-fileable (there is no worker "backdate-determination" action; the signed, snapshotted determination of ADR-002/028 is only reachable through the harness’s live apply→determine path). The paired spec constructs it; the caseworker beats after it are the human-followable part. A worker backdate-determination affordance (#999) would let this journey be filed at the portal front door and gain an applicant view — until then it is worker-only.

The applicant /lookup view is N/A. The given-library case files no portal application, so it carries no ADR-026 reference + passcode — there is no applicant view-back to demo (honest scope, not a portal gap).

Enrollment + issuance are the system’s own production path. Approval auto-enrolls the household (#1014) and the settlement pass issues + settles the current month; the journey waits for that instead of constructing it — a manual backdated enrollment cannot coexist with the auto-enrollment (#1130 one-live-enrollment), and the recompute window is pinned to the current month, so the auto-issuance is exactly the countable paid row.

Issued amounts equal the household’s net monthly benefit. The determination exposes only the household’s net benefit (not a gross maximum allotment), and the auto-enrollment issues that amount — the correct real-world issuance for a household with income.

The overpayment claim has no per-case worker screen. Its human-visible consequence is the overpayment notice on the Notices tab (the last step); the claim itself is verified programmatically in the paired spec.

Demo Runbook (bring-up + reset + credentials)

UAT Facilitator Guide

Journey Walkthroughs (the pairing overview)

Scenario Inventory & Human-Fidelity E2E (epic &61) </content> </invoke>