Review designation that parameters are safe for downstream apps

[MattHJensen]

Currently, Tax-Calculator designates that a parameter is unsafe for downstream apps by leaving off section headers in policy_current_law.json. This approach was implemented in https://github.com/PSLmodels/Tax-Calculator/pull/1109.

This signal is not obvious to downstream apps as evidenced by the discussion in #2372.

We should review how we document parameter safety for downstream projects.

[hdoupe]

@MattHJensen what does it mean for a parameter to be "unsafe"?

[MattHJensen]

what does it mean for a parameter to be "unsafe"?

One example is where neither the PUF-based nor CPS-based data files have the necessary variables to support the use of the parameter. This is problematic in and of itself for users of apps like Tax-Brain that rely on the built in PUF and CPS data files. (Tax-Cruncher gets to ask the user for data so might be able to work around this.) It also means that the parameters are relatively untested, since we focus our testing on parameters for which we have data.

A more complete cataloging of why each parameter is unsafe ought to be undertaken as part of the resolution of this issue. There may be a case to eliminating these parameters and associated logic and then only adding them back when downstream projects have a demonstrated need for them and ability to use them.