A "last verified on" line covers every row, so it has to print the oldest date in the set

An independent pharmacy reading a page about a federal drug-tracing deadline has one decision to make: trust the figures in front of them, or go open the FDA letter and check it themselves. The line under the table settles that. It says every figure above was re-verified against its primary source on a date, and the reader takes that date at face value.

On DoseTrace, that date is not typed by hand. The repo keeps a register file, FACTS.json, with one entry per claim that can decay: the value, the primary source it came from, and the date it was last re-fetched. Anything on the site that shows a registered figure imports it from there rather than restating it. A helper called claim() throws if the id does not exist, so a typo fails the build instead of rendering an empty cell, and it refuses any entry whose status is not verified, so a claim parked in the middle of a re-check cannot reach a buyer.

The date under the table came from a second helper. It asked the register for the verification date of every claim in the table and returned one of them.

Which one is a different question than it looks

For a single fact, "last verified on" has one answer. For a set of twelve, the sentence is making a promise about all of them at once. The old version returned the newest date in the set. That dates the whole table to whichever single row happened to be re-read most recently, and overstates every other row underneath it.

Truing renders the same line under a comparison of two new W-2 box 12 codes, built from ten registered claims. When that table shipped on 2026-08-10, those ten claims carried verification dates spread across a week: three on 2026-08-08, and the oldest, the revision number of the form you use to correct a filed figure, on 2026-08-01. The page printed 2026-08-08. It was true of three rows out of ten.

The fix is the first element instead of the last

export function asOf(...ids: string[]): string {
  return ids.map((id) => claim(id).asOf).sort()[0];
}

It used to end .sort().slice(-1)[0]. The dates are written year first, then month, then day, so sorting them as plain text sorts them by time, and the earliest one is simply the first thing in the list.

Why it sat there

Look at the third row of the table above. Every one of the twelve claims behind DoseTrace's exemption table was re-verified on the same day, so both readings return 2026-08-11 and the page is correct either way. The two versions of this function only disagree when a register has been partially refreshed, which is the normal state of a register that gets worked through a few rows at a time. A staggered re-check is exactly when the date matters most and exactly when the old code was worst.

The wrong version also fails in the direction that flatters. Re-reading one row on a Monday made a table of a dozen claims look freshly checked, when the work done was one row. There was no signal anywhere that this had happened, because the number that appeared was a real date from a real verification, attached to the wrong scope.

Now the printed date moves only when the stalest claim in the set moves, so re-reading one row cannot make the other eleven look younger than they are.

That product is DoseTrace, and this is how we built it: https://dosetrace.thecompound.tech/

---

One shipped product, taken apart, once a month. What it does, what it cost to build, what the pipeline behind it looks like, and what the numbers did, read off the repository and the live site, not written from memory. Join the list.