PolicyEngine / PolicyEngine/policyengine-us

Uprating-index parameters are app-exposed household reform controls with no effect after #9077

Open
#9,078 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
162
Forks
212
Avg merge
3d 3h
Merged PRs (30d)
97

Description

## Context

#9077 (fixing #9075) applies the reform set after the parameter processing pipeline. That fix has a deliberate side effect on a separate, mostly-hidden surface: reforms on **uprating index series** no longer cascade into derived uprating.

Under the old ordering, a reform on `gov.bls.cpi.c_cpi_u` applied before `set_all_uprating_parameters` flowed into `gov.irs.uprating` and from there into every IRS-uprated deduction, bracket, and threshold:

```python
from policyengine_core.reforms import Reform
from policyengine_us.system import CountryTaxBenefitSystem, system

reform = Reform.from_dict(
{"gov.bls.cpi.c_cpi_u": {"2026-02-01.2026-12-31": 500}}, "us"
)
reformed = CountryTaxBenefitSystem(reform=(reform,))
reformed.parameters.get_child("gov.irs.deductions.standard.amount.SINGLE")("2027-01-01")
# old ordering: 30,950 (cascaded); new ordering: 16,500 (baseline; only the c_cpi_u leaf changes)
```

## Why this needs a decision

`c_cpi_u` (and the other CPI series) have public labels and `economy: false` but **no `household: false`** — the API defaults `household` to `true`, so app v2 offers them as editable household reform controls (confirmed in the checked-in `US_Metadata.json`). After #9077 the control still edits the leaf but has no downstream effect: an editable control that does nothing.

The cascade was never a designed contract: no test, no documentation promising it, no in-repo or policyengine.py consumer, and society-wide runs already excluded it via `economy: false`. The supported pattern for economic-assumption scenarios is explicit post-uprating value-writing, as in `reforms/ssa/trustees_core_thresholds.py`.

## Options

1. **Retire the control (recommended)**: add `household: false` to the uprating-index series that the pipeline reads (`gov.bls.cpi.c_cpi_u`, `cpi_u`, `cpi_w`, `gov.ssa.nawi`, and the other inputs of `set_all_uprating_parameters`), so the app stops offering dead levers, and document that index parameters are pipeline inputs, not reformable policy levers.
2. **Support it explicitly**: define an economic-assumptions reform mechanism that re-derives dependent uprating from reformed index series (with regression tests) — noting that a naive re-derivation reintroduces the #9075 bug class for future-dated index reforms.

Surfaced by adversarial cross-model review of #9077.

Contributor guide

Open the contributing guide

Research direction

Start by reading the parameter processing pipeline, set_all_uprating_parameters, the checked-in US_Metadata.json, and reforms/ssa/trustees_core_thresholds.py. Confirm which uprating-index inputs are exposed as household controls and verify the chosen option with regression tests: either the controls are no longer exposed, or reforms explicitly recalculate dependent uprating without reintroducing the #9075 behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.