PolicyEngine / PolicyEngine/uk-ai-study
Two-paper split: static tax-benefit incidence (A) and dynamic OG-UK transition (B)
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Follow-up to #12. Records the decision to split this work into two self-contained papers rather than one mixed-method paper, and what each needs.
Why split
The concern that prompted this: answering some questions with PolicyEngine and others with OG-UK looks like method-shopping unless the division is structural and declared in advance. Two failure modes:
- Parallel models. "OG says growth is X, PolicyEngine says poverty is Y" — a reader cannot tell whether the two describe the same world, and if they would disagree on something both can compute, the convenient one has been picked silently.
- Binding the finished to the unfinished. Paper A is weeks away; Paper B is 6–12 months and gated on an unresolved OG-Core question. Combining them means the completed work waits.
Splitting removes both. Each paper has one coherent method; B cites A for the microsimulation layer.
Paper A — static tax-benefit incidence
Question. What does an AI shock do to UK households and the Exchequer in the impact year, and how much does the safety net absorb?
Method. PolicyEngine UK on FRS 2024-25, this repo's existing pipeline. Already run for the Korinek et al. (2026) scenarios in #12.
Status. Results exist. Blockers before it is publishable:
-
knowledge_groupsis wrong. Korinek et al. define cognitive occupations as "management, professional, sales, and office jobs" (contrasted with "construction workers or electricians").anthropic.pycurrently uses SOC2020 major groups 1–3, which excludes group 4 (administrative and secretarial — 2.585m jobs, and the highest C-AIOE of any group at 0.744) and group 7 (sales and customer service — 1.506m jobs). That is ~4.1m workers on the +33.6% side who belong on the −11.5% side. Should be(1, 2, 3, 4, 7). This will move the headline and probably worsen poverty, since admin and sales sit closer to the means-tested part of the distribution. - No Monte Carlo. Every figure in #12 is a single seed-0 draw.
REVISION_PLAN.mditem 6 documents seed noise flipping decile signs inresults/low.json. Needs 20–50 paired draws with mean ± SD before anything is quotable. - Relative poverty. The +4.18pp headline is on an anchored line, in a scenario where the median moves a lot. Needs
in_relative_poverty_bhcalongside (REVISION_PLAN.mditem 9). - Capital channel is a lower bound. A 1.37× scaling of all capital income yields +0.0005 Gini, because FRS
savings_interest_income/dividend_incomemisses pensions, retained earnings and unrealised gains. The US work found excluding pensions halved the estimate. State this rather than reporting the number as the answer. -
REVISION_PLAN.mdPhase 0 (M1 denominator, M2 wage-bill conservation) still open.
Findings that already survive. The stock-to-flow conversion dominates everything: their 17.9% is a 2030 unemployment stock, the model needs an annual flow, and Little's law makes assumed duration matter more than the choice of scenario — the poverty effect flips sign between 6-month and 2-year duration. That constrains anyone scoring these scenarios in any country.
Paper B — dynamic transition path
Question. What is the path of UK macro and distributional outcomes to 2045 under AI automation, who bears it by birth cohort, and is the shock even on a feasible growth path?
Method. run_transition_path() in OG-UK (8-sector ONS Blue Book calibration, OLG S=80), with each year's factor prices passed down to PolicyEngine — standard top-down macro-micro linking, run sequentially so every downstream number inherits one macro path. Plan drafted at ogmodels/OG-UK/docs/plans/AI_MACRO_PLAN.md.
The debate it enters. Moll & Imas (9 Sept 2026, Ghosts of Electricity) argue double-digit growth is unlikely and 4–5% is the reasonable baseline. Their Assumption 2 — which they call the one that "matters most" — is the elasticity of substitution: Jones & Tonetti's ~0.2 against Epoch's 0.5–10. Nobody has run that disagreement through a calibrated multi-sector model of a second economy with a real tax system attached.
Blockers, from reading the installed ogcore:
-
gammais not time-varying (indexed[M], not[T, M]). Moll & Imas's mechanism is automation raising the exponent on capital, α from ⅓ → 1. Not directly implementable. Routes: (1) automation as sector-biasedZ[t, m], which is free but is a productivity channel and will not move the labour share within a sector; (2) a cross-sectorgammagradient with composition shifting; (3) patch OG-Core for time-varyinggamma— a real upstream contribution, scope unknown. -
epsilonis not time-varying either (indexed[M]). Fine for a sweep across fixed values; rules out an automation path that changes substitutability over time. -
alpha_T = 0.06— transfers are an exogenous share of GDP. Can take a trajectory but cannot respond to need, so the welfare state cannot act as a stabiliser. The automatic-stabiliser question belongs in Paper A, not here. Do not conflate them. -
lambdasand theeability matrix look like OG-Core defaults (0.25/0.25/0.20/0.10/0.10/0.09/0.01). Need to confirm they were calibrated to UK data rather than inherited from OG-USA. If inherited, the lifetime-income groups are not UK groups and that must be fixed or disclosed. - Does
multi_sector=Trueconverge on current hardware, and how long does one transition path take?
What OG-UK can and cannot produce distributionally. J=7 lifetime-income groups (0–25, 25–50, 50–70, 70–80, 80–90, 90–99, 99–100) × 80 ages. Not annual-income deciles — a different object, and the two rankings will not line up. No household structure, so no poverty line, no equivalisation, no BHC/AHC. Its advantage is the explicit top 1%, which a decile split hides inside decile 10 — and the capital-share story lives in exactly that group.
What it cannot do at all. Follow individual households through time. OG-Core solves for J × S = 560 representative agents; the FRS is used to fit tax functions and the ability matrix, then discarded. The deliverable is a trajectory of distributional outcomes, not trajectories of households. True household paths would need dynamic microsimulation (SAGE, PENSIM, DYNASIM), which is a different model class with no general equilibrium.
Discipline for the split
Three rules, to be fixed before either paper is run:
- The division is structural and declared in advance. OG gets what only GE can represent (endogenous prices, capital accumulation, cohorts, debt feasibility). PolicyEngine gets what only the real tax code can (poverty, deciles, caseloads, geography). Written down beforehand it is a division of labour; chosen after seeing results it is method-shopping.
- Validate on the overlap. Both models can produce an aggregate revenue figure and some notion of distribution across income groups. Run both on the same shock and compare before using either for its own domain. If they disagree, the likely cause is that OG-UK's fitted tax functions smooth away the kinks (UC taper, personal-allowance withdrawal) where PolicyEngine's distributional action lives — measuring that gap is a methods result worth reporting.
- Every number labelled with its source model, in every table and figure.
Sequencing
- Paper A blockers above, then publish. Weeks.
- Paper B Phase 0 (feasibility) in parallel — mostly waiting on solver runs.
- Paper B Phase 1 (the elasticity sweep) as the paper.
Related: #12.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with REVISION_PLAN.md and anthropic.py for Paper A, then read run_transition_path() and ogmodels/OG-UK/docs/plans/AI_MACRO_PLAN.md for Paper B. Check the installed OG-Core definitions of gamma, epsilon, alpha_T, lambdas, and the e matrix before choosing a scope. Done means the selected paper’s blockers are resolved, validated, and its outputs are clearly attributed to the appropriate model.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- data
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100