# F1-conf-01 — 12-month CPI inflation (CPIAUCSL, SA) from two data 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 level taken from the most recent vintage that has a value for that month. Then report the window mean, the sub-period means (2001-01…2013-12 and 2014-01…2026-09), five named months, and the months of the maximum and minimum.

# Data and exclusions

• cpi_vintage_2016-07-15.csv (834 rows, 1947-01…2016-06) and cpi_vintage_2026-10-28.csv (153 rows, 2014-01…2026-09) are the authoritative inputs. Neither file has duplicate dates or gaps in its rows.
• Splice: I used the 2026-10-28 value for every month from 2014-01 onward that has a value. For all earlier months I used the 2016-07-15 value.
• Missing value: the 2026-10-28 vintage has an empty cell for 2025-10. The 2016 vintage ends at 2016-06, so no source has a value for that month. I did not interpolate or impute it, so g_{2025-10} cannot be computed. g_{2026-10} would also need the 2025-10 level, but that month falls outside the window. g_{2025-11} and later have a lag of 2024-11 or later, so they can be computed.
• The vintages disagree where they overlap: 30 months (2014-01…2016-06) appear in both files. The newer value minus the older one ranges from −0.455 to +0.330 index points, reflecting revisions and seasonal-factor updates. As the rules require, the newer value is used.
• The assembled file has errors (cpi_assembled.csv, 957 rows). I read it only to check it against the two vintage files, and none of the estimates use it. It has three problems:
  1. It keeps the 2016 vintage for 2014-01…2016-06, when the newer vintage should take priority.
  2. It leaves out 2016-07. As a result, every 2026-vintage value after that point is dated one month too late, and the file ends with a spurious 2026-10 row.
  3. Overall, 152 of the 956 months it shares with the correct splice have different values.
• Exclusion ledger (out/exclusions.csv): 309 window months → 308 after dropping months with no index level (2025-10) → 308 after dropping months with no lag-12 level (none). n_analysed = 308 and 1 month is missing.

# Method

• I built the spliced monthly level series as described above and computed g_t on a complete calendar index, so that a missing level stays missing and the lag is never shifted across a gap.
• All means are simple averages over the months where g_t could be computed. The window mean therefore covers 308 months, and the 2014–2026 mean covers 152 of 153 months.
• The code is deterministic and uses no randomness (out/analysis.py).

# Results

Exact values are in out/results.json.

# Uncertainty

• These are computations on published data, not estimates from a sample, so there is no sampling error. The uncertainty comes from data revisions and from how the vintages are spliced.
• The newest vintage stops at 2014-01, so for 2014-01…2014-12 the numerator comes from the 2026 vintage and the lag (2013) from the 2016 vintage.
• I checked how much this matters by recomputing 2014 using the 2016 vintage alone:
  • the 2014 mean barely changes: 1.6117 % with the mixed vintages versus 1.6114 % with the old vintage alone;
  • individual months move more: g_{2014-06} is 2.098 % (mixed) versus 2.005 % (old vintage only).
• Later revisions to the latest vintage could move recent months, especially 2026.

# Limitations and open issues

• Result is partial: g_t cannot be computed for 2025-10 because no vintage has a value for that month. The window mean and the 2014–2026 mean leave that month out rather than imputing it.
• Mixed vintages in 2014: the 2014 growth rates divide a 2026-vintage level by a 2016-vintage level. This follows the stated rule, but the two levels come from different seasonal-adjustment vintages. A fully consistent series would need the 2026 vintage for 2013 as well, which is not among the inputs.
• The assembled file is unreliable (see above) and should not be used.