Skip to content

Refresh OBR figures that had been stale since the ONS anchor, and name the two levers that do not work - #176

Merged
vahid-ahmadi merged 2 commits into
mainfrom
fix/obr-emulator-review
Aug 12, 2026
Merged

Refresh OBR figures that had been stale since the ONS anchor, and name the two levers that do not work#176
vahid-ahmadi merged 2 commits into
mainfrom
fix/obr-emulator-review

Conversation

@vahid-ahmadi

Copy link
Copy Markdown
Contributor

A fresh review of the emulator recomputed every published number and
probed each fiscal instrument. Two things needed changing here.

The free-running scorecard had been stale since PR #22 upstream. The
OSHH ONS anchor landed and these pages went on publishing the pre-anchor
figures, which understated the model's accuracy on every line: real GDP
4.48% not 5.75%, consumption 7.49% not 9.56%, household income 6.27% not
14.15%, real household income 6.03% not 13.86%, business investment 15.73%
not 16.12%, company profits 63.29% not 79.80%, current account 3.60% of
GDP not 4.17%. Six of the eleven computed variables land within band, not
four. Regenerated fig_free_running_data.csv from the model and
recomputed the MAPEs from the CSV rather than transcribing them, so the
chart and the prose now come from the same place.

Two of the four fiscal levers do not work, and nothing said so.
CGIPS moves business investment by exactly 0.0 in all twelve quarters
and leaves a wrong-signed residual GDP effect, against the OBR's published
1.0 — the channel is absent, not weak. TCPRO never converges: for a
sustained +5pp rise the investment response runs £97m at q3, £2,876m at
q12 and £43,387m at q25, compounding 1.21–1.27x every quarter for 25
quarters, because the stabiliser anchors the level rather than the
deviation. Truncating the shock from twelve quarters to eight barely moves
the q12 answer, so the published number is carried by accumulated drift
rather than by the tax rate.

Both now carry a caveat in the obr_shock payload — a docstring does not
reach an MCP caller reading JSON — and on the lever list at /obr/code. The
site already said the government-consumption multiplier is ~1 by
construction against the OBR's published 0.6, and the review confirmed it
is exactly 1.0000 on impact at both £0.1bn and £10bn and still 0.9995 at
quarter 12, with consumption moving £0.64m on a £1,250m shock. That leaves
the household-income lever as the one instrument here with behaviour in it.

Upstream: PolicyEngine/obr-macroeconomic-model#27, which also fixes three
ways to get a confidently wrong answer out of this model — a silent
all-NaN shock reading as "no effect", a corporation-tax rate above 1
returning a wrong-signed finite answer, and a transmission audit that had
published +53.99% GDP for a 1pp corporation-tax rise.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

🤖 Generated with Claude Code

…e the two levers that do not work

A fresh review of the emulator recomputed every published number and
probed each fiscal instrument. Two things needed changing here.

**The free-running scorecard had been stale since PR #22 upstream.** The
`OSHH` ONS anchor landed and these pages went on publishing the pre-anchor
figures, which *understated* the model's accuracy on every line: real GDP
4.48% not 5.75%, consumption 7.49% not 9.56%, household income 6.27% not
14.15%, real household income 6.03% not 13.86%, business investment 15.73%
not 16.12%, company profits 63.29% not 79.80%, current account 3.60% of
GDP not 4.17%. Six of the eleven computed variables land within band, not
four. Regenerated `fig_free_running_data.csv` from the model and
recomputed the MAPEs from the CSV rather than transcribing them, so the
chart and the prose now come from the same place.

**Two of the four fiscal levers do not work, and nothing said so.**
`CGIPS` moves business investment by exactly 0.0 in all twelve quarters
and leaves a wrong-signed residual GDP effect, against the OBR's published
1.0 — the channel is absent, not weak. `TCPRO` never converges: for a
sustained +5pp rise the investment response runs £97m at q3, £2,876m at
q12 and £43,387m at q25, compounding 1.21–1.27x every quarter for 25
quarters, because the stabiliser anchors the level rather than the
deviation. Truncating the shock from twelve quarters to eight barely moves
the q12 answer, so the published number is carried by accumulated drift
rather than by the tax rate.

Both now carry a caveat in the `obr_shock` payload — a docstring does not
reach an MCP caller reading JSON — and on the lever list at /obr/code. The
site already said the government-consumption multiplier is ~1 by
construction against the OBR's published 0.6, and the review confirmed it
is exactly 1.0000 on impact at both £0.1bn and £10bn and still 0.9995 at
quarter 12, with consumption moving £0.64m on a £1,250m shock. That leaves
the household-income lever as the one instrument here with behaviour in it.

Upstream: PolicyEngine/obr-macroeconomic-model#27, which also fixes three
ways to get a confidently wrong answer out of this model — a silent
all-NaN shock reading as "no effect", a corporation-tax rate above 1
returning a wrong-signed finite answer, and a transmission audit that had
published +53.99% GDP for a 1pp corporation-tax rise.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@vercel

vercel Bot commented Aug 12, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
macromod Ready Ready Preview Aug 12, 2026 3:12pm

Request Review

PolicyEngine/obr-macroeconomic-model#27: the multiplier documentation,
the TCPRO domain guard, the transmission-audit fix and the corrected
WB/WP/WV/RDELTA seeds.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@vahid-ahmadi
vahid-ahmadi merged commit 1e8695f into main Aug 12, 2026
7 checks passed
@vahid-ahmadi
vahid-ahmadi deleted the fix/obr-emulator-review branch August 12, 2026 15:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant