e.g. ensure disability includes PIP, check how enhanced and severe align with @DeepakSingh98's spreadsheet. Also compare to external published aggregates.

0-17, 18-64, and 65+

So we can sum them up by household

In order to approximate the TAXBEN modelling, we should include the benefits specified in their 2017 documentation, with 2020 parameters.

This includes:

• Job Seeker's Allowance

• Income Support

• Housing Benefit

• Child Benefit

• Child Tax Credit

• Working Tax Credit

Currently the FRS survey data has adults with net incomes unexplainable from the survey data and current tax system alone (very low tax burdens, unexplainably high tax burdens too). One way to deal with this might be to measure the initial error in the baseline simulation and use this as an adjustment factor.

https://github.com/PSLmodels/openfisca-uk/blob/4c540a20332e9a4455a77d8893ca4e5379d6b8a6/openfisca_uk/variables/person/disability.py#L126

As part of aging #79

absolute_poverty_bhc and absolute_poverty_ahc are parameters that state the poverty thresholds before and after housing costs, against which equivalized household net income is compared to classify household poverty status. It'd be good to have threshold, or maybe thresh, in the parameter names for clarity, e.g. absolute_poverty_threshold_bhc.

This won't have a real effect because the FRS doesn't have capital gains data (per #11 (comment)), but could implement to have it.

Here are the rates: https://www.gov.uk/capital-gains-tax/rates

With stamp duties and inheritance taxes, it represents 5% of tax revenue (1/9 of income tax + NI): https://www.ifs.org.uk/publications/9178

We should add four UBI reforms:

• Flat tax, full UBI

• Progressive tax, partial UBI

• Flat tax, large UBI

• British Freedom Dividend

This would effectively be the marginal tax with respect to a pound of the employer's cost of employment, rather than the worker's pay.

Should be a flag in the calc_mtr function defaulting to False, given it's an unconventional way of reporting MTRs.

To get data to current year

Not all those eligible for benefits claim them, and not all who claim them report them. The former should be dealt with by using the compiled benefit take-up rates by the DWP based on the FRS and administrative data, while keeping the people who already claim them consistent. The latter requires a bit more consideration.

e.g. full, half_child, disability_supplement, disability_supplement_half_child

In household equivalisation, older children (14 <= age < 18) are given a higher weighting than young children (0.33 vs 0.2). The most recent variable statistics generated show the is_older_child variables to have mean and stddev 0 - suggesting that the variable doesn't actually recognise older children. Age being coded here is the problem: the FRS bands the ages in 4-year bands and children don't have that many age bands to choose from. The effect of this is that poverty statistics will be underestimated - we knew this already, but this is potentially a big reason why: if older children are cast as younger children, then household equivalisation factors will be lower, and therefore equivalised household incomes will be higher, causing less to fall below the poverty thresholds. So we need another way to distinguish older children from younger children using the FRS data.

Per our follow up discussion from #30, I'd suggest:

• basic_income_u18 -> age_u18
• basic_income_adult -> age_1864
• basic_income_pensioner -> age_65plus

And then the parameter names can be something like ubi_age_{u18,1864,65plus}, or just ubi_*.

These definitions are too narrow to use for UBI, given that both represent only 0.2% of the population and just not enough records to make reliable judgments about. If we add UBI supplements for different categories of disability, we'll need another way.

We should add weights for optional storage for each entity for aiding analyses of results.

https://pslmodels.github.io/openfisca-uk/ has some long lines

Review how eligibility is modelled, and whether the reporting requirements on some benefits is the best way to account for take-up rates.

The model now has variables for absolute and relative poverty, with references to government reports in #14, but testing these is probably necessary, which can be done with poverty line calculators such as this one to see if they're following the same method/parameters.

UKMOD has many more benefits to use, which we should aim to implement, including:

• Jobseeker’s Allowance (contributory)
• Jobseeker’s Allowance (income-based)
• Employment Support Allowance + Incapacity Benefit (contributory)
• Employment Support Allowance (income based)
• Basic State Retirement Pension
• Earnings related state pension
• Pension Credit
• Winter Fuel Allowance
• Bereavement Benefit
• Maternity Allowance
• Statutory Sick Pay
• Statutory Maternity/Paternity Pay
• Attendance Allowance
• Disability Living Allowance
• Personal Independence Payment
• Severe Disablement Allowance
• Carers Allowance
• Industrial Injuries Disablement Benefit
• War Pension
• Child Benefit
• Child Tax Credit
• Working Tax Credit
• Income Support
• Housing Benefit
• Local Housing Allowance
• Universal Credit
• Council Tax Benefit
• Educational Maintenance Allowance
• Sure Start Maternity Grant
• Benefit cap

Income-based JSA is a means-tested, taxable benefit which can be received together with contributory JSA.

Currently, all investment income is being taxed as capital gains. Is that improperly taxing interest and dividends?

In UBICenter/uk#17 we have an attempt at measuring the poverty gap:

from openfisca_uk import CountryTaxBenefitSystem

reform_equivalized_household_net_income_bhc = (
    reform_df.household_net_income / reform_df.household_equivalisation_bhc)
bhc_pov_gaps = np.maximum(
    bhc_pov_threshold - reform_equivalized_household_net_income_bhc,0)
poverty_gap_bhc = np.sum(bhc_pov_gaps * baseline_df.household_weight)

This is incorrect, since the poverty gap at the per-household level captures the equivalized gap rather than the full household poverty gap.

Seems like there are a couple options here:

1. Add a column/attribute with the true (not equivalized) household poverty threshold, based on household structure.
2. Add a function to de-equivalize a number, which can be applied at the poverty gap calculation stage.

(1) probably involves (2). Doing (1) would make poverty calculations simpler (household_net_income < poverty_threshold), but it would also add more data overhead.

Currently, the openfisca_uk.tools.simulation.Simulation constructor loads data from CSV files. It would be speedier if there were an option to call load_frs() to load the FRS data once, then point to the three DataFrames. Doesn't matter much when running it once, but could help for optimizations with hundreds or thousands of simulations.

Alternatively, if there were a function to replace the reform parameters in an existing Simulation, that could do the trick.

Sources are one area of the documentation which are pretty inconsistent here - we should aim to make them known wherever they have been used. At the moment, the vast majority of implementations have used either GOV.UK or the 2016-2020 UKMOD country report.

I'm noticing a few files that I think are unnecessary and could be removed from the repo:

1. debug.log: this file listed in the .gitignore, but is checked into the master.
2. .vscode directory and files within

@MattHJensen could you give @nikhilwoodruff and me admin rights to this repo?

To make it work like PIP in e.g. #64

Deepak's spreadsheet shows the values of benefits. These aren't used in the simulation, since they don't respond to income (except ESA, which is already modeled) but they're in the data, and will be used for defining more robust disability severity levels for UBI (#59).

Includes:

• PIP
• ESA
• AA
• IIDB
• DLA
• Carer's Allowance
• Constant Care Allowance

Income Tax and National Insurance should be calculated per person. These should generally follow the main marginal rates, but also the following details:

• Self-employed pay different NI rates

• Employees pay normal NI rates

• Personal allowances are reduced after £100k

Should include current disabled flag, plus:

• income-based ESA
• registered disabled
• Equality Act flags
• PIP
• IIDB
  https://github.com/PSLmodels/openfisca-uk/blob/86c76547670ba2d4b6c9b1b66f7139a44a098f02/openfisca_uk/variables/person/disability.py#L13-L20

NB: incapacity benefit and SDA have been rolled into ESA. Constant Attendance Allowance and New Style ESA are absent from FRS. Disability premiums are added into their respective benefits, so can't be disentangled to add to the logic.

It'd be interesting to see how this compares to simulations from Landman Economics.

For example, the RSA report, "A Basic Income for Scotland," uses the Landman model and comes up with these figures:

I think this MTR chart is for a lone parent with two children, as referred to below the chart.

(The report doesn't show equivalent reforms together, but Horizon 2 preserves existing tax rates.)

Not a high priority given the significance of the task, but could be a good validation point.

e.g. basic_income_u18, basic_income_pensioner, etc.

This would make it so that these kinds of reforms wouldn't have to extract features about the person:

https://github.com/nikhilwoodruff/openfisca-uk/blob/e9139d401f03f8a48785049ce3c60fc5c2443746/openfisca_uk/reforms/basic_income/reform_1.py#L50-L54

Tool is called Black, and you can get it as a plugin for VSCode.

Also set line length to 79 characters when you have it installed.

These should align with @DeepakSingh98's spreadsheet, the final columns of which set thresholds for determining whether someone is getting an enhanced/severe level of each benefit. The logic should be OR across all benefits.

Currently we're just using 2016 as start year, but it's actually the current values

We need to add tests to the project, could start with contributory JSA.

We have the amounts received of each TAXBEN core benefit - we should add variables to hold them for testing:

• JSA

• Income Support

• Housing Benefit

• Child Benefit

• Child Tax Credit

• Working Tax Credit

microdf added poverty_rate, deep_poverty_rate, poverty_gap, and squared_poverty_gap in PSLmodels/microdf#160.

openfisca-uk could use this as well, though it'd likely be simpler once PSLmodels/microdf#161 is addressed so the data doesn't have to be put into a DataFrame.

Acceptance Criteria for Transparency and Quality

• Models MUST be released under an OSI-approved open source license or the Creative Commons Public Domain Dedication (CC0).
• Data MUST be publicly available, unless release is restricted by a third party.
• For any data that SHOULD not be disclosed, provided MUST be:
  - A complete descriptive list of all data variables;
  • Descriptive statistics for all data variables for such data (including averages, standard deviations, number of observations, and correlations to other variables), to the extent that the descriptive statistics do not violate the rule against disclosure;
  • Contact information for the individual or entity who has unrestricted access to the data.
• A complete descriptive list of all data variables;
• Descriptive statistics for all data variables for such data (including averages, standard deviations, number of observations, and correlations to other variables), to the extent that the descriptive statistics do not violate the rule against disclosure;
• Contact information for the individual or entity who has unrestricted access to the data.
• Projects MUST have unit tests and SHOULD report code coverage.
• At least one test MUST generate key outputs from source materials, the test MUST be run with every new version, and the outputs of the test MUST be checked into the repository.
• Projects MUST report names and contact information for at least one maintainer.
• Projects MUST have a suggested citation.
• Projects MUST have a project overview.
• Projects MUST have installation directions.
• Project MUST be mirrored in the same GitHub organization as PSL, and therefore they MUST be under version control.
• Projects MUST use a consistent versioning scheme, which SHOULD be semantic versioning. If projects want to use the PSL Package-Builder tool to distribute packages via the Anaconda Cloud PSLmodels channel, there are additional MUST criteria.

Community Criteria

• Projects SHOULD have a public roadmap.
• Projects SHOULD have contributor documentation and guidelines.
• Projects SHOULD have regular office hours, webinars, or standing meetings.
• Projects SHOULD list technical contributors.
• Projects SHOULD list funders.
• Projects SHOULD list user citations and case studies.
• Projects SHOULD include subject matter tags, choosing from ...
• Projects SHOULD include a disclaimer.
• Projects SHOULD have a public issues tracker.
• Projects SHOULD have a changelog.
• Projects MAY have a Stack Overflow channel.
• Projects MAY include a "News" translation of the changelog for users.
• Projects MAY include criteria for participating in cross-model PSL initiatives.
• Projects MAY include a link to a webapp version.
• Projects MAY include a list of consultants.

Interoperability Criteria

• The source code SHOULD be written in an open source language. Python.
• A PSL_catalog.json configuration file to be used for cataloging these criteria MUST be included in the project's repository. Specific instructions for creating this file can be found in the Catalog-Builder Documentation.

Job Seekers' Allowance (contributory) is a benefit based on age, earnings, pension income and eligibility.

Also known as poverty severity index: https://en.wikipedia.org/wiki/Poverty_gap_index#Related_measures

Minor, but as suggested in https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline

The FRS has information on types of accounts; we could use this detail in tax logic in the model.

Following up on #37 (comment), e.g. using https://openfisca.org/doc/coding-the-legislation/legislation_parameters.html#computing-a-parameter-that-depends-on-a-variable-fancy-indexing.

OpenFisca-Core only provides YEAR, MONTH and DAY periods, and all amounts in the FRS are weeklyised, so we've been using ETERNITY so far. It's not too much work to add additional periods in OpenFisca-Core, so if we did add the FRS periods, then we could make the API a lot more intuitive, and likely make analyses involving specific time periods, e.g. phase-in reforms, a lot easier and more accurate, as well as making the internal policy implementations a lot more readable, eliminating the need to internally weeklyise/yearlyise variables, e.g. income tax is calculated on yearlyised income and then weeklyised again - the taxes and benefits have many different payable time periods, e.g. most benefits pay weekly, some monthly, some are one-off and this would be respected by default if we used periods correctly. It would also fix #33 , because all variables would have the correct period metadata.

The documentation of openfisca-uk needs some work. I think a jupyter-book would be a good way to do this, in line with other PSL models. However, we should probably set in stone any interface improvements, e.g #53 before doing this.