PolicyEngine / PolicyEngine/microcosm
SSI take-up: seed an asset gradient in claiming propensity (attributes only, no reform-referential behavior), anchored to MSP asset-test natural experiments
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 4
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 94
Description
Problem
takes_up_ssi_if_eligible is seeded as a band-constant Bernoulli, solved so baseline caseloads reconcile to SSA by age band. The flag is a person attribute, but a constant one — so people holding $2k–$20k in countable assets inherit the claiming rate of a population screened to hold under $2k. For the SSI resource-limit class the assumption is the estimate: elderly carry ~70% of the $10k/$20k cost, and against CBPP's published elimination elderly row (115k) we produce 694k — a 6× gap that is entirely claiming, not eligibility (both datasets agree the excluded pool skews heavily elderly; ours: ~1.5M income-eligible seniors excluded solely by assets, avg potential benefit ~$580/mo).
Design principle (owner-adjudicated)
Person attributes stay independent of the tax-benefit system — no reform-referential behavior (an earlier draft of this issue proposed a newly-eligible claiming factor; retracted for exactly this reason). The fix is a gradient in the seed itself, over policy-invariant attributes.
Proposal
- Asset gradient in the take-up propensity. Seed
takes_up_ssi_if_eligiblefrom P(claim | countable assets, age band, demographics) — attributes only. Calibration constrains the intercepts: the propensity averaged over each band's under-$2k population must still reconcile to SSA's caseload (the #524 delivery gate unchanged in role). Reform behavior then emerges from attributes: high-asset newly-eligible people claim less because of what they hold, with no reform-margin logic anywhere. - Slope estimation, three anchors: (a) the truncated $0–$2k range in SIPP (income/assets/receipt jointly observed); (b) CBPP's published adult-equation
log_countable_assetscoefficient — the same attribute-based object from the same survey family; (c) state Medicare Savings Program asset-test eliminations — direct observations of senior claiming across the asset range that is out-of-support in SSI data by construction — plus the 1985–89 SSI limit step-ups and SNAP BBCE removals. Add (c) to the reform-validation suite as hard rows so the gradient is gated by observed enrollment responses. - Diagnostics, not dials: reform outputs report realized claiming by asset band among the newly eligible (pure measurement; no behavioral parameter).
- Explicitly out of scope here: benefit-size response (regime-dependent → belongs engine-side as a behavioral response with a stored policy-invariant latent, like elasticities, if ever); OACT phase-in (a reporting adjustment for administrative-score comparisons, never a person attribute).
Acceptance sketch
Baseline bands still reconcile to SSA; the CBPP adult row (154k, currently matched at 0.5%) must not regress; the elderly row moves from the estimated gradient rather than an inherited constant, with the MSP-anchor rows green. The ssi-asset-limits rerun harness produces the acceptance table per candidate in ~15 min.
Relates #374 (the residual this closes), #453 (child row), #524/#507 (baseline banding this builds on).
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 by tracing the takes_up_ssi_if_eligible entry point and the existing baseline banding from #524/#507. Review the ssi-asset-limits rerun harness and reform-validation suite, then compare candidate gradients against the SSA bands, CBPP adult and elderly rows, and MSP-anchor rows. Done means the baseline and adult row still reconcile and the acceptance table is green without reform-referential behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- data
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100