PolicyEngine / PolicyEngine/policyengine-us
Audit broad is_disabled usage across program-specific disability rules
- Dominant language
- Python
- Stars
- 163
- Forks
- 213
- Avg merge
- 3d 3h
- Merged PRs (30d)
- 96
Description
## Context
During the SSI disability criteria work, we separated `meets_ssi_disability_criteria` from the broad `is_disabled` input. That exposed a broader modeling risk: many formulas use `is_disabled` directly, but disability definitions are often program-specific and legally distinct.
`is_disabled` is useful as a broad demographic/functional flag, but it should not silently stand in for every legal disability definition unless the source explicitly supports that mapping.
## Examples of surfaces to audit
A source scan shows direct `is_disabled` usage in several policy areas, including:
- SNAP work requirement and student exemptions (`gov/usda/snap/...`), while SNAP elderly/disabled special rules separately use `is_usda_disabled`.
- HUD elderly/disabled family logic.
- Medicaid work requirement exemptions.
- VITA eligibility.
- State childcare/special-needs child rules.
- State TANF resource/work-rule exceptions.
- State tax credits, exemptions, and deductions for disabled taxpayers/dependents.
- Transit/reduced-fare programs.
- State supplement and disability-specific assistance programs.
Some may be correct approximations. Others may need program-specific variables such as `is_usda_disabled`, `is_ssi_disabled`, `is_permanently_and_totally_disabled`, `is_hud_disabled`, `is_disabled_for_medicaid`, etc.
## Proposed work
- Inventory all direct `is_disabled` uses in PE-US formulas and classify them by legal concept.
- For each use, document whether broad `is_disabled` is acceptable, whether an existing narrower variable should be used, or whether a new program-specific variable is needed.
- Prioritize high-impact federal programs first: SNAP, HUD, Medicaid, SSI/SSP.
- Add regression tests where replacing broad `is_disabled` changes eligibility/benefit outcomes.
- Coordinate with policyengine-us-data on whether CPS/SIPP have source support for any new program-specific disability inputs, and whether missing inputs should be imputed or left as explicit defaults.
## Related
- #8430
Contributor guide
Research direction
Start with a repository-wide search for direct `is_disabled` uses, beginning with the `gov/usda/snap/...` formulas and the other policy surfaces listed in the issue. Classify each use against the relevant program-specific disability concept, then inspect existing regression tests and policy-engine-us-data support before deciding whether a narrower variable or new input is needed. Done means the prioritized uses are documented, justified, and covered by tests where eligibility or benefit outcomes change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100