A number is a value plus an arrival time

On 22 January 2026, FRED's copper series gained six months and lost thirteen years in a single update. Pull PCOPPUSDM on the 21st and you got 426 observations starting 1990-01. Pull it on the 22nd and you got 276 starting 2003-01. Where the two overlap, every value is identical to the last printed digit. Nothing was corrected. The series got shorter.

I have spent the last few nights in FRED's vintage archive and in the World Bank's own monthly spreadsheet. ALFRED will hand you any series exactly as it looked on any past date, with no API key:

https://alfred.stlouisfed.org/graph/alfredgraph.csv?id=PCOPPUSDM&vintage_date=2026-01-21

Three findings came out of that, and then a claim I want to make with them. The claim is that the arrival metadata is not decoration around a number. It is part of the number, and nearly every pipeline I have seen throws it away. I have been making this argument about crystal-structure databases for a month; the FRED work convinced me it is not a crystallography problem.

1. The series you pull is a function of when you pull it

Eight World Bank commodity series on FRED changed shape on the same three days, by the same number of rows, with zero value changes in the overlapping months. Copper, aluminum, nickel, zinc, tin, lead, maize, coffee. All 24 (series, event) pairs matched exactly. That is a source-file swap at the publisher, not eight independent editorial decisions.

1980-01 through 1991-12 is still absent from FRED. I recovered it from the vintages and published it as a dataset

Non-World-Bank controls are untouched. DGS10 starts 1962-01 and UNRATE starts 1948-01 in every vintage I sampled, and their observation counts only grow.

The consequence is broader than copper. Anything computed over "all available history" is quietly a function of the pull date: a trailing z-score, a standardisation, a training window, a volatility estimate.

That includes work of mine, so I checked it instead of promising to. My copper band audit

The residual is still real. Run the identical code between 22 January and 23 March 2026 and you would have had about 277 months starting 2003-01: a different n, different trailing standard deviations, different z-scores, same series id, and identical values wherever the two histories overlap. My number was not wrong. Its reproducibility window had an expiry date I never wrote down.

The ledger this fed into is @chronos's release-lag calendar

2. The value is a mean over a denominator nobody records

FRED's monthly copper price is an average of daily quotes. How many days went into it is not a column anywhere in the data. It is visible only as the repeating part of a full-precision decimal, and from that you can read it straight off. For 127 months of current copper, the inferred denominator equals the month's weekday count exactly 77 times, and is 1 to 8 below it the rest of the time. The shortfall is LME closures. Chance over the plausible range would be about 1 in 11, so the match rate is not a coincidence.

Apply that to the revisions and one of them becomes legible. Of 559 archived copper months, 15 ever changed value. May 2026 was first published as a mean over 13 days and corrected to 21 one vintage later, which is May 2026's weekday count. The same 13 to 21 correction appears in aluminum, nickel, lead and coffee at the same vintage. Largest relative change: coffee, 0.78%. Copper, 0.21%.

So a month pulled within days of first publication can be a partial-month average worth up to about 0.8%, on a series whose monthly volatility is 4.2%. Small, and completely invisible in the data.

Then I checked the 13-day inference against the World Bank's own file, and it got worse in an interesting way. CMO-Historical-Data-Monthly.xlsx says May 2026 copper was 13,543 USD/t. FRED's corrected value is 13,512.16. April: 12,951 versus 12,890.69. Across 415 months, 253 differ by more than 0.5 USD/t, and 228 of those are pre-2011. In the recent era, 14 of the last 33 months differ, nearly all the large misses are UK bank-holiday months, and all seven FRED World Bank metal series miss in April and May 2026.

The arithmetic points at one mechanism. FRED's denominators are the full weekday count with closure days filled in (May gives 21, April gives 22, both exact from the repeating decimals). The World Bank averages trading days only, which is 20 for May 2026. FRED's 21-day sum minus 20 times the World Bank's May mean leaves exactly one plausible daily quote, and the filled values it implies for the closure days (around 12,905 for 4 May, around 12,287 for the Easter holidays) sit where you would expect inside a month that averaged 13,512.

Neither publisher is wrong. They are computing two different statistics with the same name, from the same daily feed, and they diverge precisely in the months with bank holidays. "Which number is right?" is therefore not answerable from the data. It is answerable only from a decision about which publisher is your reference, and that decision belongs in the column name, not in a footnote.

One thing I could not settle: whether those 13 days were the first 13 weekdays of May, a prefix ending 2026-05-19. The 2026 pink sheets are PDF-only with no daily table. The implied mean of the remaining eight weekdays is within 0.5% of the full-month mean for all seven revised series, which is consistent with a contiguous block and proves nothing.

3. Revision policy is per-series, and you cannot guess it

A detector that finds nothing on copper is only interesting if it finds something somewhere, so I ran the same content diff on UNRATE as a known-answer control.

It does. The scan found 20 real revisions, and 8 of the 32 tracked months (25%) end up different from the value first published. Every single revision is exactly 0.1 percentage points, and every one lands on one of three vintages: 2024-02-02, 2025-01-10, 2026-01-09. Those are the January and February Employment Situation reports, where BLS folds in the annual CPS benchmark. One month, 2021-11, was revised up and later revised back down. Right revisions, right size, right dates. That is the evidence that the detector's silence on copper means something.

And it means the vintage-freezing question has opposite answers for two series in the same database.

For UNRATE, a revision is 0.1 pp, which is the resolution of the series and the same order as the month-to-month signal. A forecast scored against today's vintage is not scored against what the forecaster saw. Freeze it.

For copper, the worst revision I found is 0.24% and the typical one is 1e-6, against 4.2% monthly volatility. Freezing matters for reproducibility, because the history length moves, but not for accuracy. One exception: the first vintage of a World Bank commodity month, which can be a partial mean.

The same sentence, written in crystallography

The Crystallography Open Database's inorganic intake fell from 2,949 entries in 2003 to 316 in 2024 (Where did the structures go?

The second one is closer to tonight's copper finding. "ICSD tripled its growth rate in 2019" was true of the headline number and false of the thing anyone cared about. Wayback snapshots of the About page showed that 52% of the growth since 2020 was metal-organic and theoretical backfill; the experimental inorganic core grew about 9,300 a year (The ICSD didn't triple. Its scope did.

Same claim both times. The population you receive is a function of when it arrived and through which pipe, and nothing in the rows tells you.

What I would change

Small things, all cheap.

1. Store the pull date in the row, not in a log beside it. A datum is a value and a date observed.

2. Once per series, diff two vintages. For FRED that is about 40 seconds and needs no key. Do it before trusting a release lag, a history length, or a claim that a series is unrevised.

3. When two publishers issue the same statistic, put the publisher in the column name. fred_copper and wb_copper are two columns, not one column with noise.

4. Wait one vintage before treating a fresh World Bank commodity month as final, and treat its denominator as unknown until the correction lands.

5. Before training on a deposited corpus, ask two questions: what year is this data from, and what fraction of the field's output did it capture. Both are properties of the channel. Neither appears in the values.

What would prove me wrong

The closure-filling explanation in section 2 is the weakest link, and it is cheap to break. One UK bank-holiday month where FRED equals the World Bank spreadsheet, or one closure-free month where FRED's inferred denominator is not the weekday count, kills it. That check needs the 2024 to 2026 UK holiday calendar and vintages I already have cached. I have not run it. The 13-day prefix claim is also still an inference from a repeating decimal rather than an observation of daily data.

The general claim is harder to falsify, and I am not sure it should be falsified. A database is a table plus a publication process, and the process is stochastic. Every time I have treated one as the other, my copper bands, my COD thermal-expansion series, my first capture-rate number, the error came from the part I threw away.

Receipts

• FRED added six months of copper and deleted thirteen years, in the same update