Allow tax function parameters to vary by `J`

[jdebacker]

One feature of the tax system that the parametric functions in OG-Core have trouble fitting is the presence of non-filers. An income threshold for tax filing introduces a kink in the tax schedule, where marginal tax rates go from zero to some positive number. Our smooth tax functions don't capture this -- and the kink can present challenges to the numerical solution to the household problem.

As a proposal to capture non-filers, I suggest we allow the tax functions to vary by household earnings ability, $J$ (they already can vary by year, $T$, and age, $S$ -- and are progressive functions of earned income). This would allow users to set taxes to 0 for some fraction of the population determined $j$ and thus capture non-filers. Of course, this isn't perfect -- you wouldn't have movement from filer to non-filer since $j$ is exogenous and constant over the life-time of a household. But in many contexts we might deal with (e.g., OG-IND, where ~90% of the population are non-filers for the income tax) there is not that much movement across the filing threshold so the approximation error may not be significant.

Thoughts on this?

cc @rickecon

[jdebacker]

Increasing the dimension of the tax parameters objects could be memory-intensive. In the DEP case, there are 12 parameters in the functions so the size of the array would be TxSx12xJ. And we'd need these for effective tax rates and two marginal tax rates.

Perhaps a more efficient option: Since we only want to capture non-filers. What about a parameter that a length-J vector of 0/1s to indicator not a filer/filer for each ability type? Optionally, this could vary over the time path. But even with that, it would add significantly less to the memory footprint of the parameters object.

[jdebacker]

Note that we won't want to zero out all labor taxes: the payroll tax rate should still be operational (but this is often a linear tax so can easily be addressed but may require some logic to differential between the payroll tax being included with the income tax in the tax function parameters of whether the payroll tax is separately modeled with tau_payroll.

[jdebacker]

I asked Claude Code:

I want to introduce the concept of an income tax non-filer in OG-Core. I
can see two ways to go about this. (1) create a scalar parameter,
"filing_threshold" that represents the income threshold before a household
has to file an income tax return. I would then modify the tax.ETR_income
and tax.MTR_income to return and effective or marginal tax rate of zero if
the income (X+Y) is below the filing_threshold. or (2) create a new
parameter, tax_filer, that is a vector of booleans of length J. Each
element would indicate if that type j is an income tax filer or not. I
would then modify tax.income_tax_liab to return zero if tax_filer = 0 for
that type j. household.FOC_labor and household_FOC_savings would be
modified to return a zero MTR if tax_filer = 0 for the type j.

The advantages of (1) is that it's just a single parameter, it maps more
precisely to tax law that specifies a filing threshold, and it requires just
a couple line changes in the code. The advantages of (2) is that it zeros
out taxes for whole lifetime income groups (the j) so that no household int
he model faces a kink in marginal or effective tax rates where they go from
a zero to positive number. These kinks could prove problematic for the
numerical optimization (such as in SS.solve_for_j).

Can you review the ogcore source code and see if you can think of other
advantages/disadvantages of each approach and help me come up with a plan?

The reply:

⏺ I'll help you analyze these two approaches for introducing non-filers. Let me explore the relevant parts of the OG-Core codebase to understand the implications of each approach.

⏺ Explore(Explore tax and household modules)
⎿  Done (34 tool uses · 63.6k tokens · 3m 14s)

⏺ This is excellent analysis! Based on this exploration, I can add several additional considerations to help you decide:

Additional Advantages/Disadvantages

Approach 1 (Scalar filing_threshold) - Additional Considerations:

Disadvantages not yet mentioned:

1. Behavioral optimization artifacts: Households might bunch just below the threshold, creating unrealistic equilibrium behavior. The smooth approximation reduces but doesn't eliminate this.
2. Payroll tax ambiguity: In reality, workers below the filing threshold still pay payroll taxes. You'd need to handle T_P separately from T_I, which the code already does (tax.py:372-388), but the logic becomes less intuitive.
3. Time-varying complications: If filing thresholds change over time (indexed to inflation, policy changes), you'd need a T-length vector anyway, approaching the complexity of the J-vector.
4. MTR calculation complexity: The marginal tax rate near the threshold becomes problematic - it's technically infinite at the threshold point (discontinuous jump), requiring careful smoothing in both ETR_income and MTR_income.

Advantages not yet mentioned:

1. Easier calibration: You can directly use IRS filing threshold data ($13,850 for single filers in 2023, etc.).
2. Endogenous filing status: As the economy evolves in TPI, households could naturally move in/out of filing status based on income changes.

Approach 2 (J-vector tax_filer) - Additional Considerations:

Disadvantages not yet mentioned:

1. Static filing status: J-types are fixed throughout the simulation. A household in a non-filing J-type can never file, even if their income grows over their lifecycle (though this might be acceptable given J represents lifetime income groups).
2. Calibration challenge: You need to determine which J-types correspond to non-filers. This requires mapping lifetime income groups to annual income filing thresholds, which isn't straightforward.
3. Granularity limitations: If J is small (e.g., J=7), you can only have coarse-grained filing status. You might end up with J-types that mix filers and non-filers.

Advantages not yet mentioned:

1. Consistent with existing model structure: The code already uses J-varying labor_income_tax_noncompliance_rate[t,j] and capital_income_tax_noncompliance_rate[t,j]. This approach fits naturally.
2. Potential for extensions: tax_filer[j] could be continuous (0.0 to 1.0), representing the share of households in group j who file. This avoids the all-or-nothing assumption.
3. Social Security interaction: Since theta[j] (SS replacement rate) already varies by j, you could make SS benefits independent of filing status while still varying by income group.
4. Separate payroll tax: It's trivial to keep T_P = p.tau_payroll * labor_income for all j, regardless of filing status.