Skip to content

Define a fiscal closure rule for FRA (production tax / deficit calibration) #146

Description

@agurgone

Context

A full-horizon sweep of production_tax_vector_scale (seed 68, t_max=50; see run_model/config/country_config_FRA.yaml) found no scale value reaches France's 15.8% (2014 S13) products+production tax-share target without triggering a deficit/debt blowup:

scale tax share (t=1) deficit/GDP (t1→t50) debt/annual GDP (t1→t50) corporate tax (t1→t50)
1.0 8.25% 25.8%→23.7% 1.09×→2.92× €32.5bn→€50.6bn
2.0 9.82% 24.9%→21.0% 1.09×→2.84× €29.4bn→€43.3bn
3.5 12.21% 23.4%→25.2% 1.08×→3.07× €24.7bn→€31.9bn (flat)
5.683422794 16.52% 20.5%→51.3% 1.07×→4.38× €19.95bn→€32.4bn (collapses, barely recovers)

production_tax_vector_scale is currently retuned to 2.0 (commit db6268e2) as a stopgap — it avoids the blowup and is multi-seed validated (seeds 15/68/232: deficit converges to 21.0–21.2%, debt to 2.84–2.93× annual GDP, no divergence) — but it does not hit the historical tax-share target, and picking a single multiplier by hand isn't a real fix. This issue is to decide on an explicit fiscal-closure rule instead.

Separately, and probably the bigger issue: the deficit runs 17–25% of GDP at every scale tested, driven by government consumption and social transfers (unemployment benefits alone grew >5× over a 50-period horizon at scale=5.683), not by production tax. Any closure rule should account for this.

Accounting clarification (why this isn't a simple tuning problem)

profit = revenue − costs − production tax
corporate tax = profit × corporate tax rate

Production tax is money the firm already paid out in cash; it is correctly deducted before corporate tax is computed. If it weren't, the firm would be taxed twice on the same money — once as production tax, once as corporate tax on income it never had. This is standard, defensible tax accounting, not a modeling bug. It does mean, mechanically, that raising production_tax_vector_scale to hit a products/production tax-share target will always erode the corporate-tax base as a side effect — that trade-off is real and shouldn't be engineered away by changing what counts as deductible.

Proposed alternatives

# Option Pros Cons
1 Debt-stabilizing tax feedback: τ_t = τ* + φ·(debt/GDP_{t-1} − target) Standard DSGE/HANK-comparable closure rule. One feedback parameter to identify. Endogenizes what was a manual search this session. If routed through production_tax_vector_scale, inherits the corporate-tax-erosion coupling above — could recreate the same problem as a slow oscillation. Doesn't touch the actual diagnosed driver (expenditure). Needs a target ratio and a smoothing speed; risks the same "correct direction, too slow" failure already found in SmoothTaylorRule (rho=0.904).
2 Primary-balance / expenditure rule: revenue − non-interest expenditure tracks a target Targets what the sweep actually found — expenditure, not production tax, drives the 17–25% deficit floor. Leaves the tax side untouched. Standard IMF/DSA-style debt-sustainability approach. Capping unemployment benefits/pensions in a downturn removes automatic stabilizers. Requires deciding which expenditure lines are "controllable" (pensions vs. cyclical unemployment support) — a real economic judgment. Has to interact with or replace the existing government-consumption setter.
3 Expenditure growth cap / "debt brake": spending growth ≤ trend GDP growth, no feedback loop Simplest to reason about — one ceiling, no loop to tune. Directly bounds the exact failure mode found (unemployment benefits growing >5× over the horizon). Well-precedented (Swiss/German debt brakes). Purely mechanical, blind to the debt level it's meant to protect. Can't distinguish a real recession (benefits should rise) from structural drift. Doesn't touch revenue at all.
4 Hybrid: expenditure cap/rule + tax feedback Most complete; matches how EU-style frameworks pair an expenditure benchmark with a revenue rule. Each side compensates for the other's failure mode. Most parameters to identify (two feedback coefficients + target + cap) — cuts against structural interpretability/identifiability priorities. Most surface area for the same class of bug found this session, now with two coupled loops.
5 Corporate tax rate adjustment: raise the corporate tax rate to compensate for the base shrinking when production tax rises Keeps the deductibility accounting correct (see above) while still letting production tax rise. Explicit, visible lever — easy to defend/audit. Extra free parameter to justify; needs its own target/rationale. Doesn't address the expenditure-side deficit floor.
6 Stop targeting the products/production tax-share sub-category in isolation The ICIO/ESA production-tax line was already flagged elsewhere as not a clean one-to-one match to the model's product-tax total. Smallest change: calibrate to total tax revenue share and let this one sub-share float. Doesn't hit the specific 15.8% products/production benchmark, if that sub-category match is needed for validation elsewhere.

Rejected approach: decoupling the corporate-tax base from production-tax deductibility

Initially considered: compute corporate tax on a profit figure that ignores the actual production tax paid, so raising production tax wouldn't shrink the corporate-tax base. Rejected — this would tax the firm on money it already handed over as production tax, i.e. real double taxation, not a fix. It would make the model less correct, not more. Documented here so it isn't re-proposed without this context.

Recommendation

Lead with option 2, given this session's evidence that expenditure (not production tax) is the dominant deficit driver. Pair with option 5 or 6 if the 15.8% products/production tax-share benchmark specifically still needs to be matched for validation purposes. 1, 3, and 4 are documented for completeness but are lower priority given the identifiability/interpretability cost relative to the evidence so far.


🤖 Generated with Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions