Tax and benefit reform — PolicyEngine Macro

01 — where it stands

The numbers, as the snapshot stores them.

PE-MICROSIM

UK, US

microsimulation

Horizon: single policy year
Runtime: sub-second household; minutes population
Access: hosted, CLI, Python

OBR-MACRO BRIDGE

UK

macroeconometric

Horizon: quarterly, typically 3-5 years
Runtime: seconds for raw shocks; minutes for translated reform scenarios
Access: hosted, CLI, Python

PSL-OG+MICROSIM

UK

olg-ge overlay on microsimulation

Horizon: one policy year under long-run steady-state assumptions
Runtime: two OG steady-state solves (baseline cached; >10 min cold) + one microsim run
Access: CLI, Python

This is the one topic with no official series behind it, so there is no vintage to date: what stands is a capability, and the cards above are read straight out of the committed capability registry rather than written by hand. A reform is one {parameter_path: value} dictionary, and the same dictionary is accepted by every route below.

02 — what the models see

The model view, and the same breath its limits.

pe-microsim is the scorer: it applies the reform to household microdata and reports taxes, benefits, net_income, revenue, distribution. It is production-ready for selected household applications, and its uncertainty is none for household arithmetic; survey/calibration uncertainty for population estimates. The limit is structural, and it is the reason this topic needs a bridge at all:

pe-microsim cannot answer GDP, inflation, interest rates and macro feedback. A costing from it is a static costing.
The OBR emulator supplies the macro feedback through a reviewed reform translation, but only for economic_shock, translated_policy_scenario, and it cannot answer arbitrary statutory reform incidence and borrowing through the current adapter.
psl-og+microsim goes further — olg-ge overlay on microsimulation — but is experimental; local-only (oguk excluded from the hosted image), and until PSLmodels/OG-UK#68 the OG solve needs its own environment — use the two-step --og-payload pipeline.
psl-og+microsim also cannot answer transition paths (steady-state factor applied flat), price-level effects (the OG model is real) and distributional incidence of effective-labour changes (reported, not allocated).

Nothing here averages those answers together. They use different horizons and mechanisms, so the comparison command prints them side by side with an explicit comparability field on every row and a warning that related-but-not-like-for-like results must not be added, averaged or ranked.

Reform scoring is the one place where the macro models and the household model meet — see how a score is put together →

03 — run it yourself

Every number above is a command away.

One reform vocabulary, three routes. The static costing first, then the same reform through the macro bridge, then both side by side:

pe-macro parameters   # curated reform parameter paths, live-resolved
pe-macro score --country uk --reform '{"gov.hmrc.income_tax.rates.uk[0].rate":0.21}' --model microsim   # static population costing
pe-macro score --country uk --reform '{"gov.hmrc.income_tax.rates.uk[0].rate":0.21}' --model obr   # the same reform with OBR macro feedback
pe-macro compare --country uk --reform '{"gov.hmrc.income_tax.rates.uk[0].rate":0.21}' --models microsim,obr   # both, with comparability warnings

Over MCP: list_reform_parameters, score_reform, population_reform_impact for the population costing, household_reform_impact for a single household, and dynamic_reform_impact for the psl-og+microsim overlay. recommend_model routes a question to a model, or refuses. Connect a client →

04 — the data behind it

Source, coverage, and the immutable file.

There is no vintage table on this page because no series in the store feeds a reform score. The provenance is different in kind: the microdata and parameter tree come from the PolicyEngine country package, and the registry describes that vintage as “country package and dataset dependent; recorded per run”. Every run records its own, which is why two scores taken months apart can differ without either being wrong.

The store still matters here, one step removed: it holds the outturns the macro side of any score is judged against, and the dated snapshots that make a past score reproducible.

Dated, immutable JSON snapshots of every series this site reads — browse the store, its release calendar, and the as-of recipe →

What would a reform do — and how far can the models follow it?

The numbers, as the snapshot stores them.

The model view, and the same breath its limits.

Every number above is a command away.

Source, coverage, and the immutable file.