obr_shock allows periods up to 40 but always solves 12 quarters, so its cumulative GDP figure is mislabelled

Abierto
  • ¿Algo no está bien?
#217 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 9 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend-api-design

Línea de trabajo

Start with integration/src/policyengine_macro/core.py around obr_shock and the MCP schema in mcp_server.py; trace how periods sets the solved window and how the cumulative GDP figure is built. Implement the recommended 12-quarter cap and carry shock_quarters_beyond_horizon into the payload as a guard. Done when requests above 12 are rejected or capped consistently and the payload cannot label a 12-quarter sum as a longer period.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

Problem

obr_shock accepts periods from 1 to 40 (_OBR_MAX_PERIODS = 40, integration/src/policyengine_macro/core.py:1268-1269; MCP schema mcp_server.py:200, le=40). It then calls run_reform(...) with no start/end (core.py:262-268), so the OBR model always solves its default window, 2025Q1–2027Q4 (12 quarters, obr_macro/reform_analysis.py:613-620).

For periods > 12:

  • results has 12 rows;
  • cumulative_delta_gdp_bn_over_shock_periods sums rows[:periods], which is the same 12 rows, while the payload echoes "periods": 20;
  • the caller reads a 20-quarter cumulative figure that covers only 12 quarters.

PolicyEngine/obr-macroeconomic-model#48 makes run_reform warn in this case and record df.attrs["shock_quarters_beyond_horizon"]. That stops it being silent on the model side, but the macro payload still mislabels the sum.

Options

  1. Cap periods at the solved window. Set _OBR_MAX_PERIODS = 12 and MCP le=12. This is the smallest change.
  2. Solve the window the caller asks for. Pass end so that the window covers periods. The OBR data runs to 2031Q1, so the model supports at most 25 quarters from 2025Q1. Set the cap to 25 and pass end = 2025Q1 + periods - 1. This costs one more template build per new end, because the template cache is keyed on (var, start, end, closure).
  3. Keep 40, but carry shock_quarters_beyond_horizon into the payload and rename the headline field to "over the solved window".

Evidence on longer windows (6 Nov 2026 sweep)

run_reform machinery, window 2025Q1–2031Q1 (25 quarters):

  • CGG solves cleanly over all 25 quarters. A 4-quarter +£1,000m shock gives +£1,000m for q0–q3, then at most £1m of residue. A sustained −£1,000m shock gives −£1,000m ±£1.2m to q24. (The multiplier is the known 1.0 identity, against the OBR's 0.6 tapering to zero.)
  • The household channel (HHDI_ADDFACTOR) is noise-dominated after about q12. A 12-quarter £1,616m/q tax rise lowers GDP by £552m at q11. After the shock ends, GDP does not return toward baseline: it is still −£853m at q24, and the HHDI delta comes back to about −£1.7bn to −£2.2bn in q17–q23. The equal tax cut gives −£217m at q24, the wrong sign. Rise + cut is 125% of the rise's peak, against 10.5% inside the shock window. The likely cause is the undetermined nominal-GDP/investment-deflator pair on the OBR side (PolicyEngine/obr-macroeconomic-model#42).

Recommendation

Option 1 for now: cap periods at 12, and carry shock_quarters_beyond_horizon into the payload as a guard. Option 2 (a longer window, up to 25 quarters) becomes reasonable once the closure in obr-macroeconomic-model#42 is fixed and a sweep shows the household tail returning toward baseline. obr_score_reform is affected the same way: its default 5-year window (2026Q1–2030Q4) reads household-channel quarters past the reliable range.

🤖 Generated with Claude Code

Lenguaje dominante
HTML
Estrellas
3
Forks
0
Merge medio
8 d 15 h
PR fusionados (30 d)
1

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de PolicyEngine/macro

Todos los issues de PolicyEngine/macro

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.