# F1-conf-01 — 12-month CPI inflation (CPIAUCSL, SA) from two ALFRED vintages

# Question

For every month t from 2001-01 to 2026-09, compute g_t = 100 × (P_t / P_{t−12} − 1). P is the CPIAUCSL index level taken from the most recent vintage that covers the month: the 2026-10-28 vintage for 2014-01 onward, and the 2016-07-15 vintage before that. The task asks for the full-window mean, the two sub-period means, five named months, and the maximum and minimum.

# Data and exclusions

• Inputs read: cpi_vintage_2016-07-15.csv (834 rows, 1947-01..2016-06), cpi_vintage_2026-10-28.csv (153 rows, 2014-01..2026-09) and cpi_assembled.csv (957 rows). Neither vintage file has duplicate dates or gaps in the month sequence.

• Missing value: the 2026 vintage has an empty cell for 2025-10, meaning the source published no value for that month. I did not impute it, and I did not fill it from the older vintage (which does not cover that month anyway). So g for 2025-10 is missing. The growth rate for 2026-10 would also need the 2025-10 level, but that month is outside the window. The lagged level for 2025-10 (2024-10) does exist, so nothing else drops out.

• Revisions: the two vintages overlap for 2014-01..2016-06 (30 months), and every one of those 30 values differs between them. The largest gap is 0.455 index points, consistent with seasonal-factor revisions. Following the rule, I used the 2026 vintage for these months.

• Mixed vintages: g_t for 2014-01..2014-12 divides a level from the 2026 vintage by a 2013 level from the 2016 vintage, because the 2026 extract starts in 2014-01. This is what the stated rule implies, but it means numerator and denominator come from different vintages.

• Errors in the hand-assembled file (cpi_assembled.csv):

  1. For the overlap 2014-01..2016-06 it uses the older vintage.
  2. It drops 2016-07.
  3. From 2016-08 onward every value is shifted one month later than in the source. As a result it shows an invented 2026-10 value, and its empty cell sits at 2025-11 instead of 2025-10.
  4. In total, 153 of its rows have values that disagree with the authoritative files.

  I therefore did not use it for any estimate. I read it only to check it and to run one sensitivity comparison (below).

• Exclusion ledger (exclusions.csv): there are 309 months in the window; 1 is dropped because its own level P_t is missing (2025-10); 0 are dropped for a missing P_{t−12}. That leaves 308 analysed months (analytic.csv).

# Method

1. Join the levels: the 2016-07-15 vintage for months before 2014-01, and the 2026-10-28 vintage from 2014-01 on (an empty cell stays missing).
2. Put the series on a complete monthly calendar and compute g_t from the level 12 calendar months earlier.
3. Take simple arithmetic means over the analysed months.

The calculation is deterministic and uses no random numbers. out/analysis.py regenerates every output file.

# Results

Sensitivity (results.json → sensitivity; not part of the estimand):

• Older vintage in the overlap: using the 2016 vintage instead gives g 2014-06 = 2.005 % (vs 2.098 %). The mean over 2014-01..2016-06 is 0.907 % with the old vintage and 0.903 % with the one used. Vintage choice moves individual months by about 0.1 pp but barely moves averages.
• Using the assembled file directly: naive use gives only 306 growth months, a mean of 2.570 %, and g 2026-09 = 3.353 % instead of 3.717 %. The one-month shift biases specific months badly.

# Uncertainty

These are exact calculations on published index levels, not statistical estimates, so I report no sampling standard errors. The uncertainty that matters is data revision: as the sensitivity check shows, revisions between vintages move single-month growth rates by about 0.1 pp. Values before 2014 come from a 2016 vintage and may have been revised since. Monthly g_t values share 11 of their 12 months with their neighbours, so they are strongly autocorrelated. Anyone wanting a standard error for the sub-period means would need a HAC (heteroskedasticity- and autocorrelation-consistent) correction for this overlap. I did not compute one, because the task defines the means as descriptive quantities.

# Limitations and open issues

• I did not check the SHA-256 values in the README against the files, because those hashes refer to the raw downloads, which were reformatted before being stored here.
• 2025-10 is missing at source, so the 2014–2026 sub-period mean averages 152 months, not 153.
• The 2014 growth rates mix vintages, as described above. A full 2026 vintage reaching back to 2013 would remove this.
• I count the result as "complete": every requested quantity is computable under the rules, and the one missing month is reported, not imputed.