Repository navigation
Re-source the rail ridership index to ORR and project rail usage - #2639
Conversation
ORR Table 1220 passenger journeys to 2025-26, held flat after, and rail_usage grown by journeys per person. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Aggregate impact on certified data: passBase Checks: 0 broken by this change, 1 failing on both sides, 0 fixed. Moves flagged for review: 0 (thresholds in Notes
Moves flagged for reviewNone. Spending by benefit and service
Caseloads
Standard reform costings (change in gov_balance)
Standard reforms: change in each reform's target
Household net income by decileNo household's net income changes in any year. No change in any year: receipts by tax head; government balance, each component counted once; model totals; household income totals; population; poverty rates; people in poverty; inequality; mean household net income in each side's own deciles. Checks failing on both base and head (1)
Counted-once checkEach of 88 components was raised by £1 per unit in 2026-27, and every head of its totals was read household by household: its own head must rise by exactly £1, no other tax head may move, no other benefit may rise, and the model's own total must move by what its heads moved. A head that breaks a rule is measured again twice: with every other head held at its baseline value, and with every other head held at its value after the first £1 while the component rises again. It fails where either still shows the response. 0 failed; 0 were skipped.
Provenance
Dataset: Receipts by tax head: head levels
Spending by benefit and service: head levels
Caseloads: head levels
Government balance, each component counted once: head levels
Model totals: head levels
Household income totals: head levels
Population: head levels
Poverty rates: head levels
People in poverty: head levels
Inequality: head levels
Mean household net income in each side's own deciles: head levels
Standard reform costings (change in gov_balance): head levels
Standard reforms: change in each reform's target: head levels
|
|
@juaristi22 could you review this when you have a moment? It corrects 🤖 Generated with Claude Code |
juaristi22
left a comment
There was a problem hiding this comment.
Reviewed b6460a672d254aaed4ab4ed7927c48d9d389c5e6. The ORR Table 1220 original confirms the historical journey values, financial-year mapping and provisional status. The per-person projection avoids double-counting population growth, and its formula path reaches rail subsidy, household benefits and net income.
One nonblocking finding, A1, is attached inline: the new population offset ends in 2030 while population growth continues changing, so total journeys drift below the stated flat forecast from 2031 onward. The synthetic weighted total is about 0.10% below its 2025 level by 2033; extend or derive the offset through the supported horizon and add a post-2030 check.
Validation: 62 repository tests and the additional stored-subsidy control passed. The custom flat-total diagnostic reproduced A1 and failed at its 2032 assertion; its preceding final subsidy/income propagation checks passed. Required hosted checks are green. Review status: COMPLETE; no critical findings or material evidence gaps. The private dataset's reported aggregate totals were not independently reproduced.
| 2027-01-01: -0.0037 # 1 / 1.0037 - 1 | ||
| 2028-01-01: -0.0040 # 1 / 1.0040 - 1 | ||
| 2029-01-01: -0.0044 # 1 / 1.0044 - 1 | ||
| 2030-01-01: -0.0045 # 1 / 1.0045 - 1 |
There was a problem hiding this comment.
A1 — Continue the population offset after 2030 (nonblocking). This final -0.0045 value carries forward into 2031+, but ons.population changes to +0.0043, +0.0042 and +0.0041 in 2031–33. Thus 2031 uses 1.0043 × 0.9955 = 0.99978065 instead of keeping weighted journeys approximately flat. In a native two-household projection, the weighted total falls from 232.81831 in 2025 to 232.57506 in 2033 (−0.10448%); ordinary rounding accounts for only −0.00837% through 2030. This also changes subsidy and household income when rail_usage supplies the formula. Please derive or extend the population offset across the supported projection horizon and test flat totals past 2030; the new test currently stops at 2027. The observed effect is small, so this is nonblocking.
There was a problem hiding this comment.
Agreed, thanks. Fixed in 5f74f93: the offset now runs to 2073, every year ons.population has a value, so the 2030 value no longer carries forward.
While doing it I found a bigger problem of ours: main's ons.population changed to the March 2026 vintage (#2611) after this branch was cut, so every value here, 2021 to 2030 too, was derived from the old series. I merged main (d5b2b07) and re-derived all years from the new one. 2025-26 per person is now (4.7165 / 4.4567) / 1.0030 - 1 = +5.51%, not +5.07%.
Tests: the per-person check now runs over every population year (2021 to 2073), and the two-household projection asserts a flat weighted total in each year 2026 to 2032 (PROJECTION_END_YEAR). Both failed before the fix. The total now drifts by 4-decimal rounding only: -0.0066% by 2032, and -0.0081% by 2039 on the index twins Core uses after 2032.
🤖 Generated with Claude Code
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…opulation main's ons.population is now the March 2026 vintage (#2611), so every year of orr.per_capita.rail_passenger_journeys is re-derived from it. The offset now runs to 2073, as far as ons.population does, so total journeys stay flat after 2030 (review A1). Tests check every population year and a flat weighted total to PROJECTION_END_YEAR. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
juaristi22
left a comment
There was a problem hiding this comment.
Re-reviewed and approved 5f74f93af2188b03c8befdd265ae699d74ec260d. A1 is resolved.
The rail population offset now covers all 53 dated population years through 2073 and matches the updated population series within the stated rounding. The regression checks every dated value and extends the weighted projection through the supported data horizon. The original ORR evidence remains unchanged and checksum-valid.
107 focused checks passed (105 repository tests and two native controls). The exact diagnostic that previously failed now passes without any tolerance change, including the post-2030 weighted totals, final rail-subsidy/income path and stored-subsidy control. No new findings or material evidence gaps in this incremental review.
Hosted lint and YAML checks have passed. The five Python shards and aggregate-impact check are still running; the approval records the completed code/source review and local validation.
|
@juaristi22 thanks for the review. Where each point stands:
Tests run locally: Could you re-review when you have a moment? 🤖 Generated with Claude Code |
Brings in #2589 (ISA inputs), #2639 (rail per person) and #2650. uprating_indices.yaml keeps both per-person blocks (interest and rail journeys). non_cash_isa_cash_interest moves with savings_interest_income to the per-person interest index, so KNOWN_INDEX_OVERRIDES stays empty. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Summary
Part of #1862 (this is the
rail_usageitem; thesavings_interest_incomeitem is #2638, so #1862 stays open until both merge).gov.dft.rail.ridership_indexdid not match ORR: on a 2020-21 = 1.0 base it had 0.40 for 2021-22 and 0.95 for 2024-25, where ORR's journeys give 2.55 and 4.46. Andrail_usagewas never projected: it was not inuprating_indices.yaml, and the index ended in 2029, so the post-2030 fallback ratio was 1.ons.population, so each household'srail_usagegrows by journeys growth net of population growth, a new seriesyoy_growth.orr.per_capita.rail_passenger_journeys(2025: (4.7165 / 4.4567) / 1.0030 - 1 = +5.51% on main's March 2026 population vintage; from 2026, 1 / (1 + population) - 1 for every yearons.populationcovers, to 2073). The weighted total then follows ORR's journeys and stays flat from 2026-27.rail_usagenow declares that series'indicestwin, is listed under it, and leavesKNOWN_UNUPRATED.What reads the index
Only
rail_usage's uprating did; no formula readsgov.dft.rail.ridership_index(the bus fares code has its owngov.dft.bus.ridership_index). The index stays as the sourced series, and a test ties the per-person growth to it and toons.population.rail_usagefeedsrail_subsidy_spending(=rail_usagexfare_index), which feedsdft_subsidy_spendingand sohousehold_benefitsandhousehold_net_income.Aggregate effect
On the Enhanced FRS 2024-25 (cached release, sha256
5ba399ea...b960b6):rail_usagerises 5.51% per household against main from 2025, but no output changes. The dataset storesrail_subsidy_spendingitself (£21.45bn in 2024), so the formula that readsrail_usageis not used, and the stored column grows only with the weights (the same on main and this branch). This PR changes outputs only for a dataset that suppliesrail_usagewithoutrail_subsidy_spending. On such a dataset, 2025-26 rail subsidy would be 5.51% higher than on main.Not in this PR
rail_subsidy_spendingalso meansgov.dft.rail.fare_indexreforms have no effect on that dataset. That is a pre-existing data question for policyengine-uk-data, not changed here.calibrate_rail_subsidy_spending) simulates through policyengine-uk at the calibration year. Its comment increate_datasets.pysays policyengine-uk carriesrail_usageforward unchanged; after this PR it grows by the series above.savings_interest_incomeitem of rail_usage and savings_interest_income are still not uprated by the index they declare #1862 is Project savings interest by interest received per person #2638.Tests
policyengine_uk/tests/test_rail_usage_uprating.py: the index against ORR's journeys, the flat years, the per-person series against the index andons.population, and a projected two-household dataset whose weighted total grows by ORR's 5.83% into 2025-26 and stays flat to 2032-33 (PROJECTION_END_YEAR); the per-person series is checked against the index andons.populationin every population year. On the first push 21 of 22 failed on main (the 2020-21 base value of 1.0 passes on both).test_projection_horizon.pyandtest_uprating_inputs_reach_data.pynamedrail_usageand its old index as the example post-2030 fallback; they now useemployee_pension_contributions_reportedand assertrail_usageis no longer a fallback.Reproducer: policyengine_uk/tests/test_rail_usage_uprating.py::test_ridership_index_is_orr_journeys_on_a_2020_21_base, policyengine_uk/tests/test_rail_usage_uprating.py::test_journeys_are_held_flat_after_2025_26, policyengine_uk/tests/test_rail_usage_uprating.py::test_per_person_growth_is_journeys_growth_net_of_population_growth, policyengine_uk/tests/test_rail_usage_uprating.py::test_projected_rail_usage_tracks_orr_journeys
axiom: n/a: dataset uprating and transport usage data, no policy rule changes
🤖 Generated with Claude Code