# 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 summaries asked for are the window mean, the means for 2001–2013 and 2014–2026, five named months, and the maximum and minimum.

# Data and exclusions

I read three files (n_input_rows): the 2016-07-15 vintage (834 rows, 1947-01..2016-06), the 2026-10-28 vintage (153 rows, 2014-01..2026-09) and the hand-assembled file (957 rows). All problems found are listed in data_issues:

• The 2026-10-28 vintage has no value for 2025-10. I did not impute it. As a result g(2025-10) is missing (missing_growth_months, n_months_missing_growth = 1). g(2026-10) would also be missing, but that month is outside the window.
• The two vintages overlap for 2014-01..2016-06, and the values differ (revisions). For every month from 2014-01 on I used the 2026-10-28 vintage.
• The assembled file has errors. For 2014-01..2016-06 it uses the older vintage. It is missing 2016-07. From 2016-08 on, every value sits one month later than it should, which creates a spurious 2026-10 row and puts the missing value at 2025-11. So I read this file only to audit it and did not use it in any calculation.
• For the 12 months of 2014 (n_months_mixed_vintage_growth), P_t comes from the new vintage and P_{t−12} from the old one. This is what the stated rule implies, so I kept these months.

Exclusion ledger (out/exclusions.csv): the combined monthly series has 957 months. Restricting to the window leaves 309 (n_window_months). Dropping the month with no level (2025-10) leaves 308. Dropping months with no lagged level removes none, leaving 308 = n_analysed.

# Method

I built the combined series from the two vintage files only: the 2016-07-15 vintage for months before 2014-01 and the 2026-10-28 vintage for 2014-01..2026-09. I checked that the dates form a gap-free monthly sequence and then took the 12-month lag by position. g_t is computed only where both levels exist. There is no randomness (random_seed = null). out/analysis.py regenerates every output.

# Results

• Window months with a computable g_t: n_months_growth = 308. The first is first_growth_month = 2001-01 and the last level is at last_month = 2026-09.
• Mean g_t over the window: mean_growth_12m = 2.574 %. The 2001-01..2013-12 baseline (mean_growth_12m_2001_2013) is 2.361 % over 156 months. The 2014-01..2026-09 mean (mean_growth_12m_2014_2026) is 2.793 % over 152 months, with 2025-10 excluded.
• Named months: growth_2014_06 = 2.098 %, growth_2016_07 = 0.868 %, growth_2020_05 = 0.198 %, growth_2022_06 = 8.979 %, growth_2026_09 = 3.717 %.
• Maximum: max_growth_12m = 8.979 % in max_growth_month = 2022-06. Minimum: min_growth_12m = −1.959 % in min_growth_month = 2009-07.
• feasibility = "partial", because one month (2025-10) has no computable g_t (feasibility_reason). Every other window month was computed.

# Uncertainty

These are exact calculations on published index levels, not sample estimates, so I report no sampling standard errors. As a descriptive figure, the standard deviation of g_t across the window is sd_growth_12m = 1.741 pp. The main uncertainty is data revision: values from 2014 onward will keep changing in later vintages. Vintage choice matters at the 0.1 pp level. For example, g(2014-06) is 2.098 % under the stated rule but 2.005 % if only the 2016 vintage is used (sens_growth_2014_06_old_vintage_only).

# Limitations and open issues

• g(2025-10) cannot be computed because the source has no value for that month. I did not impute it, as the task requires. The 2014–2026 mean and the window mean therefore cover 152 and 308 months.
• For 2014 the growth rates mix the two vintages, which follows from the rule. They are not consistent within a single vintage.
• The hand-assembled file is faulty (see data_issues) and was not used. Results computed from it would differ from those reported here.
• The SHA-256 values in data/README.md refer to the raw downloads. They do not match the reformatted files (see out/state/data_audit.md), so file integrity could not be checked against them.