F1-conf-01 — 12-month CPI inflation from two data vintages
Question
What was the 12-month growth rate g_t = 100 × (P_t / P_{t−12} − 1) of CPIAUCSL (seasonally adjusted) for each month from 2001-01 to 2026-09? P_t comes from the most recent vintage that covers month t: the 2026-10-28 vintage for 2014-01 … 2026-09, and the 2016-07-15 vintage for earlier months. The report also gives the mean over the window, the means for 2001–2013 and 2014–2026, five named months, and the extremes.
Data and exclusions
-
Inputs (
n_input_rows):cpi_vintage_2016-07-15.csvhas 834 rows covering 1947-01 … 2016-06.cpi_vintage_2026-10-28.csvhas 153 rows covering 2014-01 … 2026-09, and its 2025-10 value is empty.cpi_assembled.csvhas 957 rows. Hashes and the full audit are inout/state/data_audit.md. -
The hand-assembled file contains errors, so I did not use it for estimation (
data_issues):- For 2014-01 … 2016-06 it takes values from the older vintage, which contradicts the most-recent-vintage rule.
- It omits 2016-07.
- From 2016-08 onward every value sits one month later than its true month. As a result it contains a spurious 2026-10 row and shows the missing value at 2025-11 instead of 2025-10.
- 151 of the 955 months it shares with the correct splice have a wrong level.
I read it only to diagnose these problems. All levels come directly from the two vintage files.
-
The two vintages overlap for 2014-01 … 2016-06, and their levels differ by up to 0.455 index points. I used the 2026 vintage throughout the overlap (
data_issues). -
Exclusion ledger (
out/exclusions.csv): the window has 309 months. One month is dropped because P_t is missing (2025-10). No month lacks P_{t−12}. That leavesn_analysed= 308 months, withn_months_missing_growth= 1 (missing_growth_months= ["2025-10"]).
Method
- Splice the two vintages month by month, taking the non-empty value from the most recent vintage that covers the month. I did no interpolation or imputation.
- Compute g_t = 100 × (P_t / P_{t−12} − 1) wherever both levels exist.
- Because of the splice rule, g_t for 2014-01 … 2014-12 divides a 2026-vintage level by a 2016-vintage (2013) level.
- Compute the means and extremes over the computable months only.
The whole procedure is deterministic, uses no random seed (random_seed = null), and is implemented in out/analysis.py.
Results
- The first growth month is 2001-01 (
first_growth_month). The last month with a level is 2026-09 (last_month). g_t can be computed for 308 months (n_months_growth). - Mean g_t over 2001-01 … 2026-09: 2.574% (
mean_growth_12m). - Baseline mean for 2001-01 … 2013-12 (156 months): 2.361% (
mean_growth_12m_2001_2013,n_months_2001_2013). - Mean for 2014-01 … 2026-09 (152 months): 2.793% (
mean_growth_12m_2014_2026,n_months_2014_2026). - Named months:
- 2014-06: 2.098% (
growth_2014_06) - 2016-07: 0.868% (
growth_2016_07) - 2020-05: 0.198% (
growth_2020_05) - 2022-06: 8.979% (
growth_2022_06) - 2026-09: 3.717% (
growth_2026_09)
- 2014-06: 2.098% (
- Maximum: 8.979% in 2022-06 (
max_growth_12m,max_growth_month). Minimum: −1.959% in 2009-07 (min_growth_12m,min_growth_month). - Feasibility is
partial(feasibility,feasibility_reason). Every summary estimand was computed, but g_t for 2025-10 cannot be computed because the source has no index level for that month.
Uncertainty
These numbers are exact arithmetic on published index levels, so they have no sampling uncertainty and I report no confidence intervals. The main source of variation is data revision. Where the vintages overlap, levels differ by up to 0.455 index points (data_issues), so growth rates for 2014–2016 would change somewhat with a different vintage choice. I did not quantify that sensitivity because the task fixes the vintage rule. The 2001–2013 figures reflect the 2016 vintage and could differ in the current vintage, which the task does not provide.
Limitations and open issues
- The 2025-10 level is missing, so g_t for that month is missing. It is left out of the overall mean and the 2014–2026 mean, and is not imputed (
n_months_missing_growth). - The 2014 growth rates mix two vintages (2026 numerator, 2013 denominator from the 2016 vintage). The information rule requires this, but it can introduce a small seasonal-revision artefact.
cpi_assembled.csvwas not used because of the assembly errors listed above. Anyone using it would get mis-dated values from 2016-08 onward.- The README's SHA-256 values refer to the raw downloads before reformatting, so I could not check them against the CSVs provided.