Dynamically updating infographics and content (so you don't have to)

I've spent the last few days building a statistics publication called The Daily Visual - a site where every page answers one question ("When will mortgage rates come down?", "Are we in a recession right now?") with live charts drawn from free public data. There are eighteen pages so far, running on thirty-odd datasets from six source families: the Treasury, the Fed, the Labor Department, the Census Bureau, the World Bank, and a jobs index of ours.

The idea is a page whose numbers are never typed in. Every figure - the headline stat, the "up 2.9% on a year ago", the record flags, the per-person share of the national debt - is computed from the source data each time the site builds. Publish once, rebuild on a schedule, and the page stays current.

That was the theory, and today's article looks at how it works: the two writing patterns that make a page safe to rebuild, and the Claude routine that keeps the whole site honest every morning.

Claim rot: the problem worth naming

The big (and really quite obvious) problem is that you can update numbers all day long, but the narrative is much more challenging. It's easy to update figures dynamically in a web page - we've been doing it for a decade or more with JavaScript. You hit the real problem when you realise the prose itself goes out of date. A sentence built around a record streak stops being true the week the streak resets. A "stronger than a year ago" framing flips to weaker over a weekend. A milestone crossing arrives, and the paragraph written before it reads like it was published from the past.

We call this claim rot: prose that was honest when it was written, quietly invalidated by data that kept moving underneath it. Anyone doing programmatic SEO at scale is sitting on thousands of sentences like these.

Diesel's premium over regular petrol since 1994, from the EIA's weekly series. The chart redraws every build; the writing around it has to stay true to whatever shape it takes.

Two writing patterns deal with claim rot at the source, before any automation gets involved.

Compute every claim

If a figure can be derived from the data, it's derived at build time - never typed. The headline number, the year-on-year change, the "highest since 2022" flag, the reader's per-person share: all computed. Typed numbers are reserved for stable external facts, and each of those carries its source link.

The stat panels on the diesel page: this week's gap, the long-run average, the record. All three computed at the last build.

This one rule is what makes a rebuild meaningful. Deploy the site and every figure on every page re-derives from the freshest data its sources have published.

Write conditional prose

Any sentence that depends on the data's shape - rising or falling, record or ordinary, above or below a trigger - is written with a branch for every state the data can take. The recession page is my favourite example: its opening answer, "Not on the numbers", is one branch of a condition. If the indicator ever fires, the page answers differently, and that copy is already written, sitting there, waiting for the economy.

The recession page's opening answer is one branch of a condition, and the other branch is already written.

The discipline takes a little getting used to. When you write "the gap has been above a dollar for 105 weeks" as a computed claim, you also ask: what does this paragraph say the week that streak ends? If the sentence only works in one state of the world, it gets a branch or it gets rewritten.

Do those two things and a site that rebuilds on a schedule stays true. The next layer is the new part: something whose standing job is to check.

The morning routine

Every morning at 07:30, a scheduled Claude Code task runs the site's maintenance pass. This is content management, not content generation - the routine's job is to keep the promise the site makes, which is that its pages are current. Five steps:

1. Rebuild and deploy. Every computed figure re-derives from every source. A failed build stops the run and reports - the fetchers are written to fail loudly, so a source changing its file format becomes an error to read, never garbage quietly shipped.
2. Verify freshness against a release calendar. The routine knows the EIA publishes Mondays at 5pm Eastern, the mortgage survey lands Thursdays, and the Census rent figures come once a year. For any source that should have released, it checks the live page's "figures to" date moved - and when it didn't, it diagnoses the difference between "our fetcher broke" and "the publisher is running late" by checking the source's own API directly.
3. Scan for state flips. The routine keeps a log of each page's headline states - which branch every conditional sentence is currently rendering. A flip against yesterday's baseline means that page gets re-read in full: did every sentence take the new state cleanly?
4. Look at the pages. Screenshots, read properly - markup can be perfect while a chart renders as nonsense.
5. Log and commit. One terse entry per run: what released, what was verified, today's states as tomorrow's baseline, and anything flagged.

Each story card carries its update cadence. The routine's release calendar works from the same dates.

The boundary that makes it trustworthy

The routine is not allowed to rewrite anything. Its licence covers mechanical corrections in register; anything that needs editorial judgement becomes a FLAG at the top of its log, addressed to me.

That boundary got tested on the routine's first run, and the result sold me on the whole approach. It found a display bug I'd shipped that morning - a homepage line rendering the top skill from our jobs index in lowercase, "4,282 listings want python". It reasoned that removing the lowercase would fix proper nouns but wrongly capitalise ordinary words mid-sentence, decided that was a style call rather than a mechanical fix, flagged it with both options laid out, and touched nothing. I picked the rule; the fix shipped; the rule is now written down where every future run can see it.

A checker that fixes what's mechanical and hands over what's editorial is exactly the division of labour I want from automation on a site that carries my name.

Build this for your own site

The whole apparatus is small, and none of it needs a vendor. If you publish anything that carries a number - prices, benchmarks, comparisons, an "updated for 2026" post - these are the pieces, in the order I'd build them:

1. A data index. One file listing every page, its sources, their release cadences, and the claims most likely to rot. This is the routine's map, and writing it teaches you where your own site is stale.
2. Computed claims. Wherever a figure can come from the data at build time, wire it. Reserve typed numbers for stable facts with source links.
3. Conditional prose. Find every sentence that's only true in one state of the world, and write its other branch now, while the context is in your head.
4. Fail-loud fetchers. A source that changes shape should stop your build with an error, not ship something quietly wrong.
5. A scheduled check. A daily Claude Code task with the five steps above, a log it writes for its own tomorrow, and a hard rule about what it may fix and what it must flag.

The Daily Visual is the prototype, and every page on it is the demo: the figures you see were computed the last time their sources published, and the routine read the site against them this morning. That standing check is the piece I'd never had before, and it's the one I'd build first if I were starting again.

The Daily Visual is at thedailyvisual.com - every chart is copyable with its source attached, and every dataset behind it is downloadable from the page.