Correcting the publication dates on four early posts

Four posts on this site carried publication dates that were older than the site. Not by a rounding error: by 6 to 47 days. This note records what the audit found, what the four dates now read, and how to check the claim yourself in two lookups.

Quick Answer (2026)

A date audit found four early BudgetForge posts stamped with datePublished values that fell before budgetforge.dev existed. The domain was registered on June 16, 2026 at 15:22:58 UTC. The four stamps read April 30, May 14, May 28 and June 10, 2026, so the gaps ran 47, 33, 19 and 6 days on the wrong side of that line. The cause was the initial content import, which carried invented dates rather than real ones. All four are now corrected to timestamps between June 17 and June 19, 2026, each one after the domain existed and consistent with when the record was actually created. No number, table, rate or worked example in any of the four posts changed.

What the audit found

A dated claim is a claim. datePublished is not decoration: it ships in the Article structured data on every post page, it is what a search engine reads to decide how fresh a page is, and it is the thing a reader uses to judge whether a pricing figure is still worth trusting. On a site whose entire product is arithmetic about other people's money, publishing a date we cannot support is the same class of error as publishing a rate we cannot source.

The falsifying fact sits outside this site, which is why nothing internal caught it for two months. Every layer agreed with every other layer. The database said April 30, the rendered byline said April 30, and the structured data said April 30. The registry said the domain did not resolve until June 16.

The four corrections

The first row is listed without a link on purpose. That slug now redirects to the maintained successor teardown, so the correction lives in the record rather than on a page a reader can open. Recording it anyway is the point of a correction notice.

Two of the four also read oddly against their own stamps. The build-versus-buy piece, stamped May 14, cites a scorecard dated June 2026. The LLM workflow costing, stamped May 28, cites a June 2026 starter review. Cross-references get added to older posts over time, so that is not by itself proof of when either piece was written. What it does mean is that under the corrected dates both now cite sources that existed on the day the page says it was published, which was not true before.

How the new dates were chosen

Four constraints, applied in order.

1. Floor. Every new stamp must fall after the registration timestamp of budgetforge.dev, fetched live from the registry rather than taken from a file.
2. Record-anchored. All four records were created on June 18, 2026 between 16:33 and 16:36 UTC. A new stamp is allowed at or after that instant, or up to 24 hours before it, which is the ordinary lead time between finishing a post and slotting it. Nothing was allowed to drift further back than that.
3. Order preserved. The four keep their original relative sequence, because the later pieces build on the earlier ones.
4. Ceiling. The earliest post on this site that was never backdated is stamped June 19, 2026 at 14:00 UTC. All four corrected stamps land before it, so the archive still reads in one direction.

What that produces is a set of earliest defensible timestamps, spread across real hours rather than snapped to a tidy interval. It is not a recovered publication log, because no such log survives.

Verify it yourself in two lookups

Two requests, no account, no tooling beyond curl.

Lookup one, the registry. .dev is not served by the registrar most RDAP examples use, so resolve its RDAP server from the IANA bootstrap file first, then request the domain. Read the event whose eventAction is registration. The response format is specified in RFC 9083.

curl -s https://data.iana.org/rdap/dns.json | grep -o 'pubapi[^"]*'
curl -s https://pubapi.registry.google/rdap/domain/budgetforge.dev \
  | python3 -c 'import sys,json; [print(e["eventAction"], e["eventDate"]) for e in json.load(sys.stdin)["events"]]'

That returns registration 2026-06-16T15:22:58.632Z.

Lookup two, the page. Fetch any post on this site and read the datePublished field out of the Article block in its JSON-LD. The field is defined at schema.org/datePublished.

curl -s https://www.budgetforge.dev/tools/build-vs-buy-when-diy-beats-saas-at-scale \
  | grep -o '"datePublished":"[^"]*"'

If lookup two ever returns a value earlier than lookup one on any page here, that page is wrong and we want to hear about it.

What did not change

Nothing in the analysis. No rate, no fee, no effective-rate ladder, no break-even month, no conversion figure, no source line, no byline. The only edits to the four bodies were the new timestamp and a dated one-line publisher's note appended to each, naming the audit and stating that the text is unchanged. The dateModified on all four now reads the real moment of this correction, September 1, 2026, which is what that field is for.

Limitations, stated plainly

The new dates are the earliest timestamps the surviving record supports. They are a floor, not a recovery. The true drafting dates are not knowable, because the import that created these rows did not preserve them, and inventing a more precise-looking answer would repeat the original error with better manners.

Math check: 47 + 33 + 19 + 6 = 105 days of archive age that never existed, now removed from four posts out of 60.