You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a discussion of the behavior of test_reforms.py::test_round_trip_tcja_reform in Issue #2542.
This seems like a very useful test to confirm that parameters are entered correctly in the current_law_policy.json file (though the name is now out of date for that).
That discussion has lead me to think more about how we might better keep track of historical current law policy baselines. In particular, with recent changes to tax law, the 2017_law.json is out of date. This file is useful for moving from a current law baseline just after the TCJA to pre-TCJA law. It does not get one from current law policy in 2021 back to a 2017 law baseline. Now, one could modify the 2017_law.json file to make this happen, but this would require ongoing maintenance efforts -- every time current law changes, one needs to go back and modify the 2017_law.json file. Because reform files layer on top of each other, there's not another way to revert from the current law baseline back to some prior period.
Note that the same is not true of the TCJA.json or CARES.json or ARPA.json as you could, in theory, stack those onto 2017 law and return to 2021 law (that's what test_reforms.py::test_round_trip_tcja_reform is doing). Because these layer on changes to prior law, they are not changing relative to the current law baseline. I say "in theory" because there are changes to parameter values that do not come through changes in major legislation, but through IRS determinations or from fixing typos in the code (let's put these changes aside for a moment).
My view is that it is very valuable to be able to return to historical law baselines (beyond the ability to have the useful unit test noted above). For example, one may want to simulate tax law as it was in a prior time. Or one may want to consider the proposals of elected officials relative to the context they were making them (i.e., tax law at that time).
Given that we want to be able to return to past current law policies, I think we want to do this in a way that requires the least maintenance. Because the reform file for each change in law is stacked on top of the existing baseline, I think the best way to do this is to create a JSON file that specifies each parameter in Tax-Calculator at the "beginning of time". For example, we might define 2017 as the beginning of time -- i.e., the furthest back in time year where current law is specified and from which there exists reform files to move one to the current, current law baseline. We could make a JSON file for this year, e.g., 2017_law.json that specifies every single parameter in Tax-Calculator as it existed in 2017. One could then pass this to a Policy() object and revert to 2017 law. To get any other baseline between 2017 and the present, one would simply layer on the reform file for each change in law from then until now.
A nice property of this is that the original year file (e.g., 2017_law.json) only needs to be updated when new parameters are added to the model, because it is otherwise a fixed set of policy parameters that full specify tax law without reference to any baseline policy. It would require creating a JSON file for each legislative change (and an annual file for other changes noted below). But once created, these files would not need to be maintained except for fixing bugs that affect historical parameter values.
For changes in parameters that aren't due to new legislation that is represented in a JSON reform file:
If fixing an error in the value of a parameter: update the original baseline file (and maybe subsequent legislation files) as appropriate.
If updating according to an IRS determination (e.g., because of an adjustment of an indexed parameter), these could be lumped into a JSON file recording these changes for each year (e.g., 2018_irs_determinations.json or something). These files could then be used in conjunction with legislation to return the the current, current law baseline. e.g.
2017_law -> TJCA -> 2018_irs_determinations -> 2019_irs_determinations -> CARES -> 2020_irs_determinations -> 2021 Budget Reconciliation Act -> ARPA -> July 2021 current law
I'd be interested to hear from others about:
Whether they see value in being able to roll back to past law.
Whether they see problems with the method outlined above.
Whether they have suggestions of other ways to achieve this objective.
There's a discussion of the behavior of
test_reforms.py::test_round_trip_tcja_reform
in Issue #2542.This seems like a very useful test to confirm that parameters are entered correctly in the
current_law_policy.json
file (though the name is now out of date for that).That discussion has lead me to think more about how we might better keep track of historical current law policy baselines. In particular, with recent changes to tax law, the
2017_law.json
is out of date. This file is useful for moving from a current law baseline just after the TCJA to pre-TCJA law. It does not get one from current law policy in 2021 back to a 2017 law baseline. Now, one could modify the2017_law.json
file to make this happen, but this would require ongoing maintenance efforts -- every time current law changes, one needs to go back and modify the2017_law.json
file. Because reform files layer on top of each other, there's not another way to revert from the current law baseline back to some prior period.Note that the same is not true of the
TCJA.json
orCARES.json
orARPA.json
as you could, in theory, stack those onto 2017 law and return to 2021 law (that's whattest_reforms.py::test_round_trip_tcja_reform
is doing). Because these layer on changes to prior law, they are not changing relative to the current law baseline. I say "in theory" because there are changes to parameter values that do not come through changes in major legislation, but through IRS determinations or from fixing typos in the code (let's put these changes aside for a moment).My view is that it is very valuable to be able to return to historical law baselines (beyond the ability to have the useful unit test noted above). For example, one may want to simulate tax law as it was in a prior time. Or one may want to consider the proposals of elected officials relative to the context they were making them (i.e., tax law at that time).
Given that we want to be able to return to past current law policies, I think we want to do this in a way that requires the least maintenance. Because the reform file for each change in law is stacked on top of the existing baseline, I think the best way to do this is to create a JSON file that specifies each parameter in Tax-Calculator at the "beginning of time". For example, we might define 2017 as the beginning of time -- i.e., the furthest back in time year where current law is specified and from which there exists reform files to move one to the current, current law baseline. We could make a JSON file for this year, e.g.,
2017_law.json
that specifies every single parameter in Tax-Calculator as it existed in 2017. One could then pass this to aPolicy()
object and revert to 2017 law. To get any other baseline between 2017 and the present, one would simply layer on the reform file for each change in law from then until now.A nice property of this is that the original year file (e.g.,
2017_law.json
) only needs to be updated when new parameters are added to the model, because it is otherwise a fixed set of policy parameters that full specify tax law without reference to any baseline policy. It would require creating a JSON file for each legislative change (and an annual file for other changes noted below). But once created, these files would not need to be maintained except for fixing bugs that affect historical parameter values.For changes in parameters that aren't due to new legislation that is represented in a JSON reform file:
2018_irs_determinations.json
or something). These files could then be used in conjunction with legislation to return the the current, current law baseline. e.g.I'd be interested to hear from others about:
cc @MattHJensen @hdoupe @andersonfrailey
The text was updated successfully, but these errors were encountered: