PolicyEngine / PolicyEngine/microcosm
Thread TANF enrollment and add ACF caseload constraints before publishing payable eligibility
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 4
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 94
Description
From scorecard diagnosis batch 1, item #2 (classification: pe_gap, confidence high; full memo: PolicyEngine/policyengine-scorecard diagnosis/DIAGNOSES.md).
Divergence
PE payable-under-forced persons are 8.496M versus Urban's 11.398M, a 2.902M (25.46%) shortfall; baseline / forced yields 40.84%, 22.34 points above Urban's 18.5%. Twenty-three of 51 PE state totals are below half Urban; DE (0.002 vs 28k), IN (0.56 vs 191k), and TX (109 vs 953k) are below 1%, while NY is 1.626M vs 690k (2.36 times Urban). Negative state gaps sum to 4.395M and positive gaps to 1.491M. The consumed national ACF cash target still misses by $2.815B; California alone contributes $2.484B, or 88.3%, of that net national shortfall.
Proposed fix
Build P seeds takes_up_tanf_if_eligible but does not thread a TANF/public-assistance receipt anchor into is_tanf_enrolled. In PE-US 1.764.6 that input defaults false, so forced take-up continues to run applicant branches in states such as TX, IN, and DE. Add a documented ASEC PAW/receipt mapping with ambiguity handling; expose a national positive-under-forced payable-eligibility variable; compile ACF average-month family and recipient count validations; add state forced-payable and dollar diagnostics; and investigate DE/IN/TX near-zero support plus NY over-support. Require the national consumed cash target and state caseload checks to pass before treating TANF rates as publishable.
Evidence
- c80b6c4:data/comparison.json, TANF/US/total rows: eligible_count is held_out and participation_rate is seed_source, based on the ASPE 0.219 TRIM3 rate; it is not independent validation.
- PEUS@92e6052d3e:policyengine_us/variables/gov/hhs/tanf/cash/tanf.py:3-80 enumerates and sums all 51 state/DC cash programs, ruling out a simple missing-state aggregator stub.
- PEUS@92e6052d3e:policyengine_us/variables/gov/hhs/tanf/cash/eligibility/is_tanf_enrolled.py:4-9 is an input-only Boolean; unspecified Booleans default false under policyengine-core variables/config.py:8-15 and variables/variable.py:196-201.
- POP@8828dee:packages/populace-build/src/populace/build/us/take_up_contract.json:30-45 seeds TANF at 0.219 but states that no ASEC PAW receipt anchor is threaded through the base spine.
- PEUS@92e6052d3e TX tx_tanf_income_eligible.py:14-40, IN in_tanf_countable_income_eligible.py:17-44, and DE de_tanf_net_income_eligible.py:12-28 branch on is_tanf_enrolled, so forced take-up still uses applicant rules when that input is false.
- POP@8828dee:tools/build_us_target_parity_manifest.py:469-507 defers ACF family and recipient counts because no TANF receipt indicator is wired; only cash dollars are compiled.
- Build P calibration_diagnostics.json, hhs_acf_tanf FY2024 US basic assistance: $7,788,317,474.55 target versus $4,973,467,154.25 final (-36.1419566%); this divergence is on a consumed target.
- data/pe/pe_metrics.json: full-participation positive TANF persons = 8,495,755.523 and baseline persons = 3,469,582.981.
🤖 Generated with Claude Code
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with policyengine_us/variables/gov/hhs/tanf/cash/eligibility/is_tanf_enrolled.py and the cited state eligibility files to trace how the missing receipt anchor affects forced take-up. Review packages/populace-build/src/populace/build/us/take_up_contract.json and tools/build_us_target_parity_manifest.py, then use the cited calibration and metric outputs to define completion: ACF family and recipient validations, state diagnostics, and national cash targets pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, data, testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100