Preset reforms and economic assumptions

[MattHJensen]

I have noticed two factors that limit the use of both Tax-Calculator and TaxBrain.

1. Reform parameters -- Users must map the reforms that interest them into Tax-Calculator parameters.

2. Economic assumptions -- Users must understand and take stances on key economic assumptions.

Both of these factors are significant hurdles for many/most users.

Proposed Solutions

Reform Parameters

Provide preset JSON reform files for reforms that could be of interest to our users.

Examples include campaign reform proposals, legislative proposals, CBO budget options, executive branch and congressional budgets, etc.

Given that there is judgement involved in mapping reform proposals to Tax-Calculator's parameters, I believe that each proposal should be signed by whoever creates the reform file.

There should also be human readable description of what is modeled by the reform file. For instance, I recently opened a PR (https://github.com/open-source-economics/Tax-Calculator/pull/1135) to add a reform file called "Trump2016.json" to represent Trump's 2016 campaign plan. However, the reform file only includes individual and payroll tax reforms rather than the entire campaign proposal, and that is only explicit in the description.

Once we have these files in Tax-Calculator, we can also upload the file to TaxBrain and distribute the TaxBrain version.

Economic Assumptions

Provide preset JSON assumption files for economic assumptions.

These assumption files should also definitely be signed. We will need to find people who are willing to take a public stance on key assumptions. Alan Viard has expressed willingness to do this, I expect there will be others.

A single author may want to publish several files, perhaps with each file representing a point in a range of potential outcomes. Eventually we may want to move towards having the economic assumptions file to accomodate ranges within one file, but I don't think we are there yet.

Once we have these files in Tax-Calculator and make some UI changes to TaxBrain, we can allow users to choose to a preset from TaxBrain.

Actionable implications for Tax-Calculator

If discussion of this proposal is positive and we choose to move forward, then these are some next steps for Tax-Calculator.

• [ ] Commit more reform files to Tax-Calculator (@codykallen, are you interested in authoring a reform file for the House Republic proposal? I'll start a library of CBO budget options that anyone can contribute to...)
• [ ] Separate our current reform files into two separate files, one for parameter reforms and one for economic assumption.
• [ ] Move meta-data in reform file like titles, author, description, reference etc. from comments to JSON attributes. This will make it easier and more flexible to port the reform files to the TaxBrain GUI.

• [ ] Establish a single source of documentation for how all of the economic assumption parameters work that we can share with potential assumption-stance-takers like Viard. I haven't thought through the best way to do this yet, given that the information is currently scattered and probably incomplete.

  I'll open another issue in TaxBrain to for discussion of implications over there.

@feenberg, @martinholmer, @amy-xu, @gofroggyrun, @codykallen, @talumbau, @peterdsteinberg, @zrisher, @andersonfrailey, @brittainhard

[feenberg]

On Tue, 10 Jan 2017, Matt Jensen wrote:

If discussion of this proposal is positive and we choose to move forward, then these are some next steps for Tax-Calculator.

• Commit more reform files to Tax-Calculator (@codykallen, are you interested in authoring a reform file for the House Republic proposal? I'll start a library of CBO budget options that anyone could contribute to.)
• Separate our current reform files into two separate files, one for parameter reforms and one for economic assumption.
• Move meta-data in reform file like titles, author, description, reference etc. from comments to JSON attributes
• Establish a single source of documentation for how all of the economic assumption parameters work that we can share with potential assumption-stance-takers like Viard. I haven't thought through the best way to do this yet, given that the information is currently scattered and probably incomplete.

I have a feeling I don't understand what you are asking for. Shouldn't we follow the precedent we established with taxbrain, where each set of reform parameters gets an identifier and is easily retrieved on the website with a full description of the reform implied by the web page displayed when the reform is viewed? If we are adding new features to possible reforms in the form of Python code, then should that code be similarly stored and displayed? Is there something else going on?

I note that a long-standing suggestion of mine is an output display listing the difference between the reform and default parameters after the tabular output. In my experience with revenue score reports, only the ones that describe what was estimated are useful. We have the ability to list the parameters that differ from default and that would be very useful. Displaying bits of Python code is less useful, but not useless.

dan

[martinholmer]

@feenberg said with respect to issue #1140:

I note that a long-standing suggestion of mine is an output display listing the difference between the reform and default parameters after the tabular output. ... We have the ability to list the parameters that differ from default and that would be very useful.

I don't use TaxBrain that much so it may be that I don't understand your "long-standing suggestion".

When you are looking at an output display, I can definitely see the importance of knowing the reform that generated that output (that is, the policy parameters that were changed to have values different from those under current-law policy). But can't you see that information with a single click on the Edit Parameters button at the top of the output page? What would be added by your suggestion?

[feenberg]

On Thu, 12 Jan 2017, Martin Holmer wrote:

@feenberg said with respect to issue #1140:

  I note that a long-standing suggestion of mine is an output
  display listing the difference between the reform and default
  parameters after the tabular output. ... We have the ability to
  list the parameters that differ from default and that would be
  very useful.

I don't use TaxBrain that much so it may be that I don't understand your "long-standing suggestion".

When you are looking at an output display, I can definitely see the importance of knowing the reform that generated that output (that is, the policy parameters that were changed to have values different from those under current-law policy). But can't you see that information with a single click on the Edit Parameters button at the top of the output page? What would be added by your suggestion?

Yes, all parameters are available on the edit screen, but the distinction between default and modified values is in the font intensity only. If a user wishes to change a single parameter, a summary of changes would have only a single entry and the change would be clear to the reader. Further, it would be clear that only one change was made. If only the edit page is available, then the reader needs to scan multiple pages of parameters to find the modified one. The edit screen is also likely to be separated from the results page when result are circulated, while a short summary might remain attached.

There is also the issue that using JSON uploads parameters not included in TB can be changed. Will these show up on the edit page?

dan

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.[AHvQVRdPm_IhrfNwusEBOLfXVYSAhDE5ks5rRjo4gaJpZM4LfmcM.gif]

[martinholmer]

@feenberg said a number of things about issue #1140:

Yes, all parameters are available on the edit screen, but the distinction between default and modified values is in the font intensity only. If a user wishes to change a single parameter, a summary of changes would have only a single entry and the change would be clear to the reader. Further, it would be clear that only one change was made. If only the edit page is available, then the reader needs to scan multiple pages of parameters to find the modified one. The edit screen is also likely to be separated from the results page when result are circulated, while a short summary might remain attached.

OK, I see your point. I agree that this would be a significant convenience enhancement to TaxBrain. This is a long-standing TaxBrain enhancement request. Would there be any technical problem with implementing this TaxBrain enhancement?

There is also the issue that using JSON uploads parameters not included in TaxBrain can be changed. Will these show up on the edit page?

That's a good question. I don't know how TaxBrain remembers the input parameters for a file-upload run. It could save the uploaded file or it could save the parameter values implied by the uploaded file. In the second case, it would be easy to show the parameter differences at the bottom of the output page. If the first case is how TaxBrain works, I think there is no need to show parameter difference at the bottom of the output page because the uploaded file (with all the changed parameters) is already being shown at the top of the output page.

@MattHJensen @talumbau

[talumbau]

We save the contents of the file that the user used and display it on the results page. It is persisted in the database so that whenever you come back to that result we have the text used. There is currently no "edit" concept with file-based reforms. Editing a file-based reform by navigating to the form-based input page would not work because the user can construct reforms in the file-based way that are impossible to represent in the form-based way. The other way to edit would be to give the user an in-browser editor for their uploaded reform, but the answer so far is to just let the user modify the file locally and then submit the edited file.

[feenberg]

On Thu, 12 Jan 2017, T.J. Alumbaugh wrote:

We save the contents of the file that the user used and display it on the results page. It is persisted in the database so that whenever you come back to that result we have the text used. There is currently no "edit" concept with file-based reforms. Editing a file-based reform by navigating to the form-based input page would not work because the user can construct reforms in the file-based way that are impossible to represent in the form-based way. The other way to edit would be to give the user an in-browser editor for their uploaded reform, but the answer so far is to just let the user modify the file locally and then submit the edited file.

OK, that sounds good.

dan

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.[AHvQVb7gf49n6B4K6o0HxteXNJVsoMr2ks5rRn6dgaJpZM4LfmcM.gif]

[martinholmer]

@talumbau said:

We save the contents of the file that the user used and display it on the results page. It is persisted in the database so that whenever you come back to that result we have the text used. There is currently no "edit" concept with file-based reforms. Editing a file-based reform by navigating to the form-based input page would not work because the user can construct reforms in the file-based way that are impossible to represent in the form-based way. The other way to edit would be to give the user an in-browser editor for their uploaded reform, but the answer so far is to just let the user modify the file locally and then submit the edited file.

@talumbau, Thanks for the update about how TaxBrain remembers a run that was specified by uploading a reform file. The way things work now seems exactly correct. There is no need to offer a TaxBrain capability for editing upload files; that is best done on the user's local computer.

So, given this information, Dan's requested enhancement would apply to only TaxBrain runs specified on the TaxBrain parameter-value input page. That is perfectly fine with me. So, @talumbau, how difficult would it be to add the parameter differences at the bottom of the TaxBrain output page? @MattHJensen, what kind of priority does this TaxBrain enhancement have?

@MattHJensen @talumbau @feenberg

[MattHJensen]

@talumbau said:

We save the contents of [a reform file] that the user used and display it on the results page. It is persisted in the database so that whenever you come back to that result we have the text used.

This is certainly a useful feature, and it is similar to the one that @feenberg is requesting, except that it only works for reform-file runs and not for GUI runs.

He continued:

There is currently no "edit" concept with file-based reforms. Editing a file-based reform by navigating to the form-based input page would not work because the user can construct reforms in the file-based way that are impossible to represent in the form-based way.

While this is true, I don't think it needs to be forever. If we resolve #1141, then every parameter that is available through a file-based reform would also be available from the TaxBrain gui input page.

Before committing to two-separate paths for how users view reforms on the output page, I'm interested in exploring the idea of unifying how file-based reforms and gui-based reforms work, and thereby buying ourselves the option to unify features like how reforms are viewed on the output page and how parameters are edited.

Unification would also make it easy to transform tax-calculator reform snippets like this one for Trump2016 into TaxBrain GUI input pages, and it would be easier to translate TaxBrain GUI inputs into reform files that could be checked into the Tax-Calculator repo for TC users.

@martinholmer

[martinholmer]

@MattHJensen proposed two sets of reform-file changes in issue #1140:

Separate our current reform files into two separate files, one for parameter reforms and one for economic assumption.

Move meta-data in reform file like titles, author, description, reference etc. from comments to JSON attributes. This will make it easier and more flexible to port the reform files to the TaxBrain GUI.

I'm in agreement about the general goals suggested in issue #1140, but I don't understand why the above two changes are required to meet those goals. All I see is substantial extra work, both initial development work and added overhead using Tax-Calculator and TaxBrain. While is see the costs of these two proposals, I do not see their advantages. @MattHJensen, can you explain what you see as the benefits of making these two changes and why you think the benefits exceed the costs of making these two changes?

@feenberg

[MattHJensen]

@martinholmer, to answer your question, let me start off with an abstract goal and motivation, then provide an example of how those goals and motivations were advanced in the past, and then I'll answer your question directly:

The fundamental goal behind both of these suggestions is two-part:

1. unify how we store tax and economic-related data (data broadly speaking) between TaxBrain and Tax-Calculator.
2. wherever possible, store the important data in Tax-Calculator and Tax-Calculator file formats rather than TaxBrain and TaxBrain file formats.

The motivation behind this goal is that having two ways of storing data is confusing and requires multiple decisions to be made every time there is new data. As much as possible I'd like to move tax- and economic-data storage into Tax-Calculator and out of TaxBrain because the Tax-Calculator team is best suited to make decisions about tax- and economic-data.

Example:

• The grouping of parameters into sections and subsections

  • 1109 unified the treatment of this data between Tax-Calculator and Taxbrain. Before we had to make some fuzzy decisions about how parameters are related when we named them and put them in current_law_policy.json. We then had to make another decision about how they are related when we wanted to include them on TaxBrain. After #1109, a decision only needs to be made once and it is made by the Tax-Calculator team.

Now moving to address @martinholmer's specific questions:

[Why] move meta-data in reform file like titles, author, description, reference etc. from comments to JSON attributes.

If we begin sharing preset reforms, then I think it will be important for shared reforms to have a title, description, references, and reform author -- even if the author is "anon".

We will want to be able to share reforms via TaxBrain GUI input pages, and we will want to be able to share reforms in the format of a reform file. (The TaxBrain GUI will need to be expanded to accomodate entry and display of title, description, references, and author.)

Now let's say that someone creates a reform on TaxBrain, describes it, titles it, adds references, and signs it. Based on the goals and motivations described at the top of this issue, I think it would be much better for all of that data to be stored in in a Tax-Calculator compatible reform file that could be downloaded and shared with Tax-Calculator users as well, not just the parameter reforms themselves.

Similarly, if a Tax-Calculator contributor creates a reform file for Tax-Calculator, as I recently did with the Trump2016.json file, then it would be advantageous for me to be able to upload that reform to TaxBrain and then share a TaxBrain GUI run that includes the title, author, and descriptive text that I added. (#1141 will need to be resolved as well)

As a more general matter, I think the Tax-Calculator team should take the lead on defining which meta data is important and how that meta data should be stored, and then the TaxBrain team should use the same file format to store the data from TaxBrain runs.

Those are the objectives behind my recommendation to store the title, description, author, and references in JSON attributes (or some other widely-used human and machine readable format), and not in comments.

[Why] separate our current reform files into two separate files, one for parameter reforms and one for economic assumption?

As described in this issue, I think a major hurdle for many Tax-Calculator and TaxBrain users is the need to take a stance on key economic assumptions. It would be much easier for many to defer to someone else's assumptions. As with the reforms, we will want to be able to share sets of assumptions across both TaxBrain and Tax-Calculator, and so it makes sense to store assumptions in a format that is both machine and human readable, as we currently do.

The core reason for separating assumption files from reform files is that they will be authored by different people. Let's say that Alan Viard contributes his preferred set of economic assumptions to the Tax-Calculator project. Then a user may want to use assumptions from Alan Viard and a reform from Matt. Currently a user would have to grab the Trump2016.json reform file that I created and then fill out the economic assumptions in that same file with Viard's recommendations. Once they've done that, the concept of "author" for the new file has disappeared. It would make much more sense if the user could just grab a file of economic assumptions that Viard created (or approved), grab Trump2016.json, and run them both in combination. Each file would have clear authorship and purpose.

A secondary reason for separating out the economic assumptions is that downstream models will want to use Tax-Calculator reform files but not use all of the assumptions that are available in Tax-Calculator. For example, the OG-USA project will want to accept Tax-Calculator reform files, but some of the parameters available in Tax-Calculator assumption files may not be compatible with OG-USA. Instead of using Tax-Calculator assumption files, they'll want their own assumption files that, for example, doesn't include the Tax-Calculator substitution effect but instead includes the OG-USA Frisch elasticity.

[martinholmer]

@MattHJensen said in the #1140 conversation:

It would make much more sense if the user could just grab a file of economic assumptions that Viard created (or approved), grab Trump2016.json, and run them both in combination. Each file would have clear authorship and purpose.

A secondary reason for separating out the economic assumptions is that downstream models will want to use Tax-Calculator reform files but not use all of the assumptions that are available in Tax-Calculator. For example, the OG-USA project will want to accept Tax-Calculator reform files, but some of the parameters available in Tax-Calculator assumption files may not be compatible with OG-USA. Instead of using Tax-Calculator assumption files, they'll want their own assumption files that, for example, doesn't include the Tax-Calculator substitution effect but instead includes the OG-USA Frisch elasticity.

OK. Those are good reasons for undertaking all the extra work involved in separating the policy and the economic assumption parameters into two types of files.

I hope the new TaxBrain will somehow be able to do a file-upload run where the assumption file name is unspecified, which means using all the default assumption parameters (that is, static analysis). I will certainly make the new --assump FILENAME option for inctax.py be optional. This will be just like the current --reform FILENAME option which is optional with no reform meaning current-law policy.

@MattHJensen also said:

Similarly, if a Tax-Calculator contributor creates a reform file for Tax-Calculator, as I recently did with the Trump2016.json file, then it would be advantageous for me to be able to upload that reform to TaxBrain and then share a TaxBrain GUI run that includes the title, author, and descriptive text that I added.

I don't understand what you mean by "then share a TaxBrain GUI run that includes the title, author, and descriptive text that I added." Could you explain what you're thinking about? The current upload files can be shared via email. What's the advantage of doing the sharing on TaxBrain? Don't you think there are some TaxBrain users who do not want to share their reform files? TaxBrain is already saving all uploaded reform files according to @talumbau, so in your plan what would be different? Your earlier assertion that the comments in Trump2016.json can be easily mapped into JSON key:value pairs is not convincing given that JSON values cannot be more than one line. How would you enter the nine reform provisions in JSON format?

[feenberg]

I hope the new TaxBrain will somehow be able to do a file-upload run where the assumption file name is unspecified, which means using all the default assumption parameters (that is, static analysis). I will certainly make the new --assump FILENAME option for inctax.py be optional. This will be just like the current --reform FILENAME option which is optional with no reform meaning current-law policy.

@MattHJensen also said:

  Similarly, if a Tax-Calculator contributor creates a reform file
  for Tax-Calculator, as I recently did with the Trump2016.json
  file, then it would be advantageous for me to be able to upload
  that reform to TaxBrain and then share a TaxBrain GUI run that
  includes the title, author, and descriptive text that I added.

I don't understand what you mean by "then share a TaxBrain GUI run that includes the title, author, and descriptive text that I added." Could you explain what you're thinking about? The current upload files can be shared via email. What's the advantage of doing the sharing on TaxBrain? Don't you think there are some TaxBrain users who do not want to share their reform files? TaxBrain is already saving all uploaded reform files according to @talumbau, so in your plan what would be different? Your earlier assertion that the comments in Trump2016.json can be easily mapped into JSON key:value pairs is not convincing given that JSON values cannot be more than one line. How would you enter the nine reform provisions in JSON format?

Let me add my feelings on this subject.

Currently if I modify some parameters in taxbrain one of the important things I get back is a URL, for example:

 www.ospc.org/taxbrain/9619

which I can circulate among interested parties and which includes all the details of the reform. I think what Matt is saying is that if I upload a reform file, the referenced URL should include everything in that file, and should make it explicit to the user. Futher, if the user modifies the file and resubmits, he gets a new URL with all the necessary parameters to rerun the submission. By keeping all the parameters together in a database on our server, and making them readily available for modification there will never be confusion as to what the parameters are for any particular simulation.

I have a vague feeling I might not be on point here - TB doesn't allow uploading a parameter file yet, as far as I can tell. Yet I recall Matt showing me a link to upload a JSON file which I don't see now. Are we discussing what should happen when it does exist?

I know that whenever I see tax scores, I want to know what was scored, and often it isn't possible to find out without phone calls, and even then I usually think I haven't been told everything.

dan

[MattHJensen]

@martinholmer said:

I don't understand what you mean by "then share a TaxBrain GUI run that includes the title, author, and descriptive text that I added." Could you explain what you're thinking about?

The goal I have in mind is for the data behind TaxBrain GUI runs to share the same file structure as reform file runs. If that is the case, then it would be simple to turn reform files into GUI input pages and to turn GUI input pages into reform files.

The reason we might want to turn reform files into GUI input pages is that many TaxBrain users will feel more comfortable modifying and experimenting with a reform in GUI format than in JSON format.

Consider the Trump2016.json reform file. If I wanted to make this available to GUI users on TaxBrain, I would need to go to TaxBrain, manually fill out the same reform, run it, and then save the TaxBrain link. (I'll be able to do this after https://github.com/OpenSourcePolicyCenter/webapp-public/issues/436 is resolved)

But if I duplicate the reform on the TaxBrain GUI manually, then then we'll have two different data representations of the exact same reform, one in the TaxBrain database and one in a Tax-Calculator reform file. Given that Trump2016.json is checked into Tax-Calculator, has reviewed by Tax-Calculator team, and can even be protected w tests, I expect Trump2016.json will be the better version over the long haul.

In my view it would be much better if we could instead populate a TaxBrain GUI page directly from the version of Trump2016.json checked into the version of Tax-Calculator running on TaxBrain. Given that we are headed to accepting and displaying user-supplied titles, descriptions, and authorship on TaxBrain, I think we will want to pull this data from the reform file into the TaxBrain input page, and it will be much easier to do that if the data are stored as data rather than as comments.

Similarly, some users may feel more comfortable creating reforms from scratch on the TaxBrain input page, and they will fill out a title field, a description, references, and authorship when they do so. It would be nice to be able to turn those reforms into reform files so that users could run them locally, check them into tax-calculator, protect them with tests, etc, all with the description, references, authorship, and title intact.

All of that said, I am well aware of the challenges of writing out lots of JSON. Here is one way it would look, below. Maybe there is some middle ground possibility like having title and reform_file_author as attributes but storing the references and textual description of provisions as comments.

{
    "title": "2016 Trump Campaign Tax Plan",
    "reform_file_author": "Matt Jensen",
    "reform_reference": "https://www.donaldjtrump.com/policies/tax-plan",
    "provisions": {
        "p1": "New personal income tax schedule (regular/non-AMT/non-pass-through)",
        "p2": "New pass-through income tax schedule",
        "p3": "New long-term capital gains and qualified dividends tax schedule",
        "p4": "Repeal Alternative Minimum Tax",
        "p5": "Repeal Net Investment Income Tax",
        "p6": "Raise the Standard Deduction",
        "p7": "Repeal the Personal Exemption",
        "p8": "New above the line deduction for child and elder care",
        "p9": "Cap itemized deductions"
    },
    "provision_parameter_map": {
        "p1": "_II_rt*, II_brk*",
        "p2": "_PT_*",
        "p3": "_CG_*",
        "p4": "_AMT_*",
        "p5": "_NIIT_rt",
        "p6": "_STD",
        "p7": "_II_em",
        "p8": "_ALD_Dependents*",
        "p9": "_ID_c"
    },
    "policy": {
        "_II_rt1": {
            "2017": [0.12]
        },
        "_II_brk1": {
            "2017": [
                [37500, 75000, 37500, 37500, 75000, 37500]
            ]
        },
        "_II_rt2": {
            "2017": [0.25]
        },
        "_II_brk2": {
            "2017": [
                [112500, 225000, 112500, 112500, 225000, 112500]
            ]
        },
        "_II_rt3": {
            "2017": [0.25]
        },
        "_II_brk3": {
            "2017": [
                [112500, 225000, 112500, 112500, 225000, 112500]
            ]
        },
        "_II_rt4": {
            "2017": [0.25]
        },
        "_II_brk4": {
            "2017": [
                [112500, 225000, 112500, 112500, 225000, 112500]
            ]
        },
        "_II_rt5": {
            "2017": [0.25]
        },
        "_II_brk5": {
            "2017": [
                [112500, 225000, 112500, 112500, 225000, 112500]
            ]
        },
        "_II_rt6": {
            "2017": [0.25]
        },
        "_II_brk6": {
            "2017": [
                [112500, 225000, 112500, 112500, 225000, 112500]
            ]
        },
        "_II_rt7": {
            "2017": [0.33]
        },
        "_PT_rt1": {
            "2017": [0.12]
        },
        "_PT_brk1": {
            "2017": [
                [37500, 75000, 37500, 37500, 75000, 37500]
            ]
        },
        "_PT_rt2": {
            "2017": [0.15]
        },
        "_PT_brk2": {
            "2017": [
                [112500, 225000, 112500, 112500, 225000, 112500]
            ]
        },
        "_PT_rt3": {
            "2017": [0.15]
        },
        "_PT_brk3": {
            "2017": [
                [112500, 225000, 112500, 112500, 225000, 112500]
            ]
        },
        "_PT_rt4": {
            "2017": [0.15]
        },
        "_PT_brk4": {
            "2017": [
                [112500, 225000, 112500, 112500, 225000, 112500]
            ]
        },
        "_PT_rt5": {
            "2017": [0.15]
        },
        "_PT_brk5": {
            "2017": [
                [112500, 225000, 112500, 112500, 225000, 112500]
            ]
        },
        "_PT_rt6": {
            "2017": [0.15]
        },
        "_PT_brk6": {
            "2017": [
                [112500, 225000, 112500, 112500, 225000, 112500]
            ]
        },
        "_PT_rt7": {
            "2017": [0.15]
        },
        "_CG_brk1": {
            "2017": [
                [37500, 75000, 37500, 37500, 75000, 37500]
            ]
        },
        "_CG_brk2": {
            "2017": [
                [112500, 225000, 112500, 112500, 225000, 112500]
            ]
        },
        "_AMT_rt1": {
            "2017": [0]
        },
        "_AMT_rt2": {
            "2017": [0]
        },
        "_NIIT_rt": {
            "2017": [0]
        },
        "_STD": {
            "2017": [
                [15000, 30000, 15000, 15000, 30000, 15000]
            ]
        },
        "_II_em": {
            "2017": [0]
        },
        "_ALD_Dependents_thd": {
            "2017": [
                [250000, 500000, 250000, 500000, 500000, 250000]
            ]
        },
        "_ALD_Dependents_Elder_c": {
            "2017": [5000]
        },
        "_ALD_Dependents_Child_c": {
            "2017": [7156]
        },
        "_ID_c": {
            "2017": [
                [100000, 200000, 100000, 100000, 200000, 100000]
            ]
        }

    },
    "behavior": {},
    "growth": {},
    "consumption": {}
}

[MattHJensen]

@feenberg, here is the link to the file upload capability: www.ospc.org/taxbrain/file

[feenberg]

On Tue, 10 Jan 2017, Matt Jensen wrote:

Economic Assumptions

Provide preset JSON assumption files for economic assumptions.

These assumption files should also definitely be signed. We will need to find people who are willing to take a public stance on key assumptions. Alan Viard has expressed willingness to do this, I expect there will be others.

A single author may want to publish several files, perhaps with each file representing a point in a range of potential outcomes. Eventually we may want to move towards having the economic assumptions file to accomodate ranges within one file, but I don't think we are there yet.

Once we have these files in Tax-Calculator and make some UI changes to TaxBrain, we can allow users to choose to a preset from TaxBrain.

Do you mean allowing different real growth rates for wages and other incomes? Perhaps a dozen or more parameters? Specified separately each year? Allow for changes in distribution also? Even with so many parameters will it meet the needs of someone wanting their own forecast? I don't necessarily think this feature is highly desirable, but since you mention an author wanting several scenarios it suggests to me a Monte-Carlo option. Rather than evaluating 100,000 records at one set of parameters, then again at another, etc, why not apply the random growth rates randomly to each taxpayer before aggregating.Then the resulting table will show the expected value of revenue over the probability weighted range of growth parameters.

Anyway, an idea, but I don't think we should lead in this sort of thing.

dan

[martinholmer]

@MattHJensen said a number of things in a recent issue #1140 comment:

The goal I have in mind is for the data behind TaxBrain GUI runs to share the same file structure as reform file runs. If that is the case, then it would be simple to turn reform files into GUI input pages and to turn GUI input pages into reform files.

In my view it would be much better if we could instead populate a TaxBrain GUI page directly from the version of Trump2016.json checked into the version of Tax-Calculator running on TaxBrain.

What happens when a new "version of Tax-Calculator running on TaxBrain" changes a checked-in reform or assumption JSON file? When this happens the title is no longer a unique identifier and there may be confusion about older runs. Seems like the metadata absolutely needs to have a date field. Certainly, as a user, I want to know how old a reform or assumption file is. Are TaxBrain users going to be able to see the history of changes over time to a policy reform or economic assumptions file?

Similarly, some users may feel more comfortable creating reforms from scratch on the TaxBrain input page, and they will fill out a title field, a description, references, and authorship when they do so.

Many users who want to use TaxBrain anonymously would be put off If these fields cannot be left blank. Is the plan to make TaxBrain work even if these metadata fields are blank?

All of that said, I am well aware of the challenges of writing out lots of JSON. Here is one way it would look, below. Maybe there is some middle ground possibility like having title and reform_file_author as attributes but storing the references and textual description of provisions as comments.

The example you gave in your comment is instructive. Your text editor seems to have a default indentation spacing in JSON files of 8 characters, but it is 4 characters In Emacs. Even when I reformat in Emacs, several of the lines are longer than 80 characters, which means the file cannot be easily printed from a text editor. Of course, TaxBrain doesn't care about the human readability of JSON value strings, but it is a problem for people viewing/printing these files in a text editor. This goes back to the same issues that lead the PEP8 standard to limit Python source-code lines to be no longer than 79 characters.

SUMMARY

MY UNDERSTANDING: I agree it would be better to split the current JSON file into two file types: a policy reform file and an economic assumptions file. The policy reform file would be required to have at least the "policy" key:value pair and the economic assumptions file would be required to have at least the "behavior", "consumption" and "growth" key-value pairs.

MY MAIN QUESTION: Would all the other key:value pairs in a reform or assumptions file, which are solely for the use of TaxBrain, be ignored by Tax-Calculator when the file is read into Tax-Calculator (just like the comments are ignored)?

There is no information in the metadata fields that is of any use to Tax-Calculator, so I would think Tax-Calculator should not even look for any key:values pairs other than those required. Otherwise, every time TaxBrain needs additional metadata, the Tax-Calculator source code would have to be changed.

[martinholmer]

The conversation in Tax-Calculator issue #1140 ended almost four months ago. Meanwhile there has been quite a bit of progress in implementing the ideas outlined in #1140.

My question is this: is there anything else that needs to be done in furthering the goals of #1140?

If there are some additional things to do, perhaps they could be identified in #1140 or in a new issue.

If there are no additional things to do, then should issue #1140 be closed?

@MattHJensen @feenberg @Amy-Xu @andersonfrailey @GoFroggyRun @codykallen @zrisher @PeterDSteinberg @brittainhard

[martinholmer]

@martinholmer said:

The conversation in Tax-Calculator issue #1140 ended almost four months ago. Meanwhile there has been quite a bit of progress in implementing the ideas outlined in #1140.

My question is this: is there anything else that needs to be done in furthering the goals of #1140?

If there are some additional things to do, perhaps they could be identified in #1140 or in a new issue.

If there are no additional things to do, then should issue #1140 be closed?

@MattHJensen @feenberg @Amy-Xu @andersonfrailey @GoFroggyRun @codykallen @zrisher @PeterDSteinberg @brittainhard

No responses suggests that issue #1140 should be closed.