The dataset that made a 145-year window possible stopped being updated. The gauge did not stop.
The problem
The long US valuation series exists because an academic assembled it and published it — price, earnings and inflation inputs reaching back to the 1880s. That single artifact is why one gauge on this dashboard can speak about a century and a half.
And it froze. The published sheet stops at a date several years in the past, on retirement. The inputs it drew on are still published, by public sources, every month. So the choice is: end the series at the freeze, or extend it — and extending a scholarly dataset with your own arithmetic is exactly the kind of thing that turns into a fabricated number if you do it casually.
Three things that make the extension honest
Recompute, then validate against the source's own answer. Rather than continuing from the sheet's final published value, the pipeline parses the raw inputs and recomputes the metric itself — then gates ingestion on the recomputation staying within a small drift threshold of the sheet's own published column, over the overlapping period.
Be exact about what that step is for, because the obvious reading is wrong and the real purpose is the better lesson. It is not a method-reproduction proof, because the recomputed value is never used: the pipeline stores and extends from the sheet's own published column, and the recomputation exists only to produce a drift figure and raise on it. Nothing downstream depends on it.
What it actually is, in the code's own words, is a canary against a format change — the sheet is a spreadsheet whose columns can move, and a silent reshuffle would feed the most important gauge on the dashboard garbage that still parses. So the check is not "prove your reimplementation is right." It is "compute the same quantity a second, independent way, and refuse to proceed if the two disagree." That is a cheaper and more general instrument than it first appears: you do not need the second computation's output for it to be worth writing, only its disagreement.
Extend from live public series where you can, and name the one place you cannot. The price and inflation inputs for months past the freeze are real observations from currently-published series. The ten-year real-earnings denominator is not: no public series carries it, so it is carried forward on a stated trend — a fixed annual real growth rate, calibrated against a known recent print. So the extension is two-thirds observation and one-third projection, and the honest move is not to hide the third. It is stated in the source string of every row it produces, which is where the next point picks up.
Put the assumption in the source string. The extension needs one estimate for a slow-moving component, calibrated against a known recent print. That assumption is written into the source string of every extended row, so a row read years from now announces that it was extended and on what basis.
What the source string buys you
Look at what a reader can determine from the stored row alone: the method is derived rather than reported, the extension is in use, the assumption's magnitude, and the date it was calibrated against. That is enough to decide how much weight to put on the value, without reading any documentation.
Compare it to the alternative, which is what most systems do: a source field saying the vendor's name, and a footnote in a wiki that the person reading the number in two years will never see.