Macro→micro feedback: economic-assumptions overlay for dynamic distributional impacts

[MaxGhenis]

The macro→micro half of the loop, per the #macro architecture direction (2026-07-16). Today OG/OBR produce wage, interest-rate, employment, and price paths that never re-enter the microsim — so the suite has no dynamic distributional analysis, the thing that would make it more than the sum of its members.

Design sketch:

1. A macro run (OG steady state or OBR window) emits an EconomicAssumptions object: paths/levels for earnings growth, employment, CPI/RPI, interest rates.
2. policyengine-uk already carries the OBR forecast as parameters (gov.obr.* uprating indices) — the overlay is a reform-shaped object that replaces those parameter values with the model's own paths. No engine surgery: it composes with the policy reform exactly like any other parameter change.
3. Rerun the microsim under (reform + overlay) vs (baseline + baseline overlay) → decile impacts, winners/losers, and revenue with GE feedback.
4. Result = a ScoreResult (Common ScoreResult schema across all scoring adapters #10) with the distributional block filled and assumptions naming the macro model that produced the overlay.

Order of operations note: the overlay must be derived from the reform macro run (which itself consumed the reform via tax functions or the #9 bridge), and the baseline microsim must use the baseline macro run's overlay — document the two-run structure so nobody double-counts the static effect.

This is the CBO/JCT-shaped capability. Depends on #9 (OBR side) and #10 (result schema); the OG side can prototype first since its PolicyEngine linkage already exists.

[vahid-ahmadi]

Design proposal: macro→micro economic-assumptions overlay

Grounded in the current adapters (integration/src/macromod/core.py): pe_population_impact (micro), obr_shock / og_score_reform / score_reform (macro), and the direction set in #9 (micro→macro bridge) and #10 (ScoreResult).

a) Overlay mechanism

Key fact we lean on: pe_population_impact already passes the reform to policyengine.core.Simulation as policy={parameter_path: value} — the same flat dict the whole suite uses. And policyengine-uk carries the OBR Economic and Fiscal Outlook as ordinary parameters (gov.obr.* uprating indices: average earnings, CPI, RPI, employment, bank rate, house prices…). So the overlay needs no engine surgery: it is a reform-shaped dict that overwrites gov.obr.* index values with the macro model's own paths, and it composes with the policy reform by plain dict merge.

EconomicAssumptions (pydantic, in core.py):

• source: "obr-macro" | "og-uk" (+ run metadata: shock/reform, closure, horizon)
• paths: {year: {earnings_growth, employment_growth, cpi_inflation, bank_rate}} — annual, model-relative deltas vs the macro baseline (pp of growth), not levels
• to_parameter_overrides(country) -> dict[str, dict]: converts deltas into gov.obr.* index overrides. Because PE parameters are dated, values are period-keyed ({"2027-01-01": new_index_value}); the override multiplies the published OBR index level by the cumulated model delta. This is deliberately a delta-on-top-of-official-forecast design: the macro baseline never has to reproduce the EFO to be usable.

Producers:

• OG (prototype first, as Macro→micro feedback: economic-assumptions overlay for dynamic distributional impacts #11 says): steady-state w, r, L changes from og_score_reform → a flat permanent delta applied from start_year (crude, honest, shippable — the SS has no transition path).
• OBR (after OBR reform contract: microsim static costing path in, second-round effects out #9 lands): the reform run's quarterly paths for average earnings, employment, CPI, bank rate → annualised deltas vs the OBR baseline run. This is the two-run structure from the issue: reform overlay = reform macro run; baseline microsim keeps stock gov.obr.* (the published forecast is the baseline overlay). Documented in the result to prevent double-counting the static effect.

Employment margin caveat: gov.obr.employment-style indices uprate earnings-linked amounts; PE microdata has no extensive-margin response, so an employment path can only rescale weights/earnings, not move people in/out of work. v1 applies wage + price + rate paths only and names employment as not-applied (see limitations).

b) API shape

One new adapter, symmetric with pe_population_impact and returning toward #10's ScoreResult:

def pe_dynamic_population_impact(
    country: str = "uk",
    reform: dict,                      # flat {parameter_path: value}
    year: int = 2026,
    macro: str = "og",                 # which member produces the overlay
    dataset: str | None = None,
    **macro_kwargs,
) -> dict:  # -> ScoreResult once #10 lands

Internally: (1) run the macro member on reform (reusing og_score_reform / the #9 OBR path, both cached); (2) build EconomicAssumptions; (3) Simulation(policy=reform | overrides) vs the cached _pe_pop_baseline — same decile/winners-losers machinery as today. Result is pe_population_impact's dict plus:

• dynamic: true, macro_model, economic_assumptions (the paths + the exact gov.obr.* overrides applied — full reproducibility),
• static_budgetary_impact_bn and dynamic_budgetary_impact_bn side by side (the CBO/JCT-shaped headline is the gap between them),
• assumptions / caveats lists per Common ScoreResult schema across all scoring adapters #10, e.g. "overlay: OG-UK steady-state wage delta applied as a permanent uprating shift from 2026".

score_reform(model=...) stays macro-only; the dynamic-distributional entry point is this function (and later ScoreResult.distributional filled per #10). One MCP tool + CLI verb mirror it.

c) What this does NOT capture (goes in caveats, not just docs)

• No behavioral response at the micro level: households don't change labour supply, savings, or take-up; the overlay moves incomes exogenously. Elasticity-based responses are a separate, later layer.
• No general-equilibrium consistency / fixed point: one pass macro→micro; the re-simulated micro aggregates are not fed back to re-solve the macro model. We should report the inconsistency (micro aggregate income change vs macro's) rather than iterate.
• No within-distribution heterogeneity of the macro shock: one economy-wide wage path hits every earner proportionally; OG's age/ability wage structure is collapsed (pooled-age config anyway), and sectoral incidence is absent.
• No extensive margin: employment paths not applied in v1 (above).
• OG SS abuse: applying a long-run steady-state delta inside a single budget-window year is a category stretch; the result must say "long-run incidence illustrated on today's population", not a year-y costing.
• Corp tax boundary (per OBR reform contract: microsim static costing path in, second-round effects out #9): a corp-tax reform's overlay only exists via obr_shock/TCPRO; the microsim side of it stays out of scope.

d) Staged plan

1. Slice 1 (shippable now, no dependencies): EconomicAssumptions + to_parameter_overrides + pe_dynamic_population_impact(macro="og") using the existing og_score_reform SS deltas. Test: hand-built overlay of +1% earnings growth moves gov_balance in the right direction and magnitude vs a hand-uprated check; static vs dynamic gap has the expected sign for an income-tax rise.
2. Slice 2: validation harness per the repo's "numbers, not just no-exception" rule — reproduce a known OBR ready-reckoner-style fiscal-drag effect within tolerance; goldens committed.
3. Slice 3 (after Common ScoreResult schema across all scoring adapters #10): return ScoreResult with the distributional block filled; wire into macromod compare.
4. Slice 4 (after OBR reform contract: microsim static costing path in, second-round effects out #9 / upstream obr#9): OBR-produced overlays with genuine year-by-year paths; document the two-run baseline/reform structure in the payload.
5. Slice 5 (optional): report macro/micro aggregate-consistency diagnostic; consider one damped iteration if the gap is material.

e) Open questions for Max / Vahid

1. Which exact gov.obr.* parameters are the sanctioned uprating hooks in current policyengine-uk (and is there a US analogue, or is this UK-only for now)? Do dated {parameter: {date: value}} overrides round-trip through policyengine.core.Simulation(policy=...) today, or only scalar values?
2. Deltas-on-published-forecast (proposed) vs replacing the whole forecast with the macro model's own baseline — agreed that delta form is the right double-counting guard?
3. Is a permanent SS delta from OG acceptable for slice 1, or should we wait for a transition-path config before exposing anything user-facing?
4. Employment: park entirely (proposed) or apply as a weight rescale with a loud caveat?
5. Should the dynamic result always carry the static result alongside (proposed), so the site can never show a dynamic number without its static anchor?