DEV Community: Jeremiah Say

Battery date codes: why K5 can mean three different months

Jeremiah Say — Wed, 11 Nov 2026 13:00:01 +0000

What does the date code on a car battery mean? On most brands it's a letter for the month and a digit for the year, so C3 means March 2023. That's Interstate's own example, and it sounds like a five-minute regex.

Then you read the same code across brands. K5 is November 2025 on an Interstate. On a Deka it's October 2025. On a NorthStar it's September 2025.

Same two characters, three different months, and that's before you get to the missing decade.

I built a battery date code decoder that covers 13 brands, 10 of them with a rule from the maker. This post covers the parsing problems I hit, and how the decoder handles a code it can't settle. The rules are open data, so you can use them yourself.

Trap 1: the month letters aren't one alphabet

There are three keys in use, and the difference comes from skipped letters. Deka's key leaves out I. NorthStar's leaves out E and I.

{
  "al":   "ABCDEFGHIJKL",
  "noi":  "ABCDEFGHJKLM",
  "noei": "ABCDFGHJKLMN"
}

So a month isn't a letter minus 64. It's a position in a key, and the key belongs to the brand:

month = data["keys"][rule["key"]].find(letter) + 1

If a letter isn't in the key, find gives you 0, which means no reading. That matters: I is a real month on an Interstate and not a month at all on a Deka.

The practical result is that if you don't know the brand, you can't give one answer. You have to give several.

Trap 2: the decade is missing

C3 holds one year digit. March 2023 and March 2013 are both valid, and so is March 2033 if you're careless.

The decoder picks the latest year that ends in that digit and isn't in the future:

function lastDigit(d, m, now) { // the latest year ending in d that isn't ahead of this month
  var y = now.y - (((now.y - d) % 10) + 10) % 10;
  return (y === now.y && m > now.m) ? y - 10 : y;
}

The month check is the part that's easy to forget. In November 2026, C6 is March 2026. In February 2026, the same code can't be March 2026 yet, so it has to be March 2016.

The older reading never goes away, though. The result always says "or March 2013", because a battery that old can still be sitting in a car. One optional input can settle it: a label can't be older than the © year printed on it. That's our reasoning, not a maker's rule, and the page says so.

Trap 3: some codes aren't letters at all

The 13 brands use several formats, and each gets its own small reader:

Format	Brand	Example	Means
Letter, digit	Interstate	`C3`	March 2023
Series letter, month, year digit, plant	ACDelco	`P094N`	September 2014
Year digit, day of the year	OPTIMA	`6086`	March 27, 2026
Month number, year digit	Motorcraft	`3-2`	March 2022
Sticker	Deka	`3/23`	March 2023

ODYSSEY adds a 12-digit code that ends in the month and year, and U.S. Battery's AGM line uses DDMMYY or YYMMDD. A table of small functions, keyed by a short format name, kept this tidy. Each brand then lists which readers apply to it, and adding a brand is a data change:

var READ = {
  ld: function (c, r, keys, now) { // letter, digit, then anything: a longer stamped code starts this way
    var x = c.match(/^([A-Z])-?([0-9])/);
    if (!x) return null;
    var m = keys[r.key].indexOf(x[1]) + 1;
    if (!m) return null;
    return { y: lastDigit(+x[2], m, now), m: m, decade: true };
  },
  nd: function (c, r, keys, now) { // month number, then one year digit: Ford's 3-2
    var x = c.match(/^([0-9]{1,2})[\/-]([0-9])$/);
    return x && +x[1] >= 1 && +x[1] <= 12
      ? { y: lastDigit(+x[2], +x[1], now), m: +x[1], decade: true } : null;
  }
};

Trap 4: leap years move a date by a day

OPTIMA's format is a year digit and a day number, so 6086 is day 86 of a year ending in 6. Ten years back is not the same date:

Day 86 of 2026 is March 27.
Day 86 of 2016 is March 26, because 2016 was a leap year.

If you show "or ten years earlier", you can't just subtract 10 from the year. Recalculate from the day number:

function dayOf(y, n) { // day n of year y as a month and day
  var t = new Date(Date.UTC(y, 0, n));
  return t.getUTCFullYear() === y ? { m: t.getUTCMonth() + 1, d: t.getUTCDate() } : null;
}

Date.UTC(y, 0, n) lets January overflow into the right month for you, and the year check rejects day 366 in an ordinary year.

Trap 5: four digits can be two different things

With no brand picked, 1224 matches two formats:

December 2024, as month and year. That rule is only Reported, for Duralast and Duracell.
August 12, 2021, as an OPTIMA serial: year digit 1, day 224.

Neither reading can be ruled out, so the decoder shows both. And 2026 typed on its own looks like a four-digit code, but it's far more likely someone typing the year, so a bare year doesn't get read as an OPTIMA serial unless OPTIMA is picked.

The sort order is a product decision too. Rules from a maker usually outrank rules from a seller's guide, but a four-digit code with no brand gets the month-and-year reading first, with the OPTIMA serial after it.

Trap 6: people type what they see

Battery stamps are worn, and O and 0 look alike. If a code gives no reading and it contains an O, the decoder tries again with zeros:

if (!r.readings.length && !r.recall && c.indexOf('O') >= 0) { // the letter O typed for a zero: KO for K0
  var z = pass(c.replace(/O/g, '0'), brand, data, now);
  if (z.readings.length) { z.typed = c; return z; }
}

It records what you typed, so the result can show the swap instead of hiding it. The retry only runs after a clean read fails, so it can't change a code that already works.

Trap 7: what the date marks

Even a correct decode doesn't tell you the battery's birthday. Interstate's own wording says the code shows when the battery "shipped from the manufacturing plant". ACDelco's marks when it was made. For a warranty argument, that gap can matter, so each brand carries a marks field and the result says which one it is.

Sources get a tier, and some brands get no answer

This was the most useful design decision. Every rule has a tier:

{ "t": "ld", "key": "al", "tier": "maker" }

Ten brands have a rule from the maker. Duralast, EverStart and Duracell have only what we found in sellers' guides or how-to articles, so those results are marked Reported. A rule from the brand's own warranty sheet and a rule from a blog aren't the same strength.

Seven brands get no decode at all. Autocraft, MotoMaster, Super Start, NAPA and DieHard have no rule from any source we'd stand behind. For Varta and Exide, guides disagree with each other. A confident wrong date is worse than "we don't know", so the decoder says that instead. For the five with no rule, a user can still borrow the common pattern, and the result is marked as a guess.

Testing it

Every maker's printed example runs through the decoder in test_battery_code.mjs, and the build fails if any of them gives the wrong month. The suite has 60 checks, including the traps above.

Pin now in your tests. The whole decoder depends on the current date, and a test that says "C6 means March 2026" will start lying the moment the decade turns:

const now = { y: 2026, m: 11, d: 7 };

There's one bug I haven't fixed. Battery group sizes such as H6 also fit the letter-and-digit pattern, so typing one reads as August 2026 on most brands. Nothing in a two-character string tells them apart, and I haven't found a source to build the warning on yet.

Use the data

The rules are open under CC BY 4.0 at /data/battery-date-codes.json, with CORS on. Here's a complete reader for the letter-and-digit format, which is the same logic in Python:

#!/usr/bin/env python3
"""Read a letter-and-digit battery date code with the open Who Actually Makes dataset. Standard library only."""
import datetime, json, sys, urllib.request

URL = "https://whoactuallymakes.com/data/battery-date-codes.json"
req = urllib.request.Request(URL, headers={"User-Agent": "battery-date-example/1.0"})
data = json.load(urllib.request.urlopen(req, timeout=30))


def last_digit_year(digit, month, today):
    """The latest year ending in this digit that isn't ahead of the current month."""
    year = today.year - ((today.year - digit) % 10)
    if year == today.year and month > today.month:
        year -= 10
    return year


def read(code, today):
    letter, digit = code[0].upper(), int(code[1])
    for brand in data["brands"]:
        for rule in brand.get("rules", []):
            if rule["t"] != "ld":
                continue
            month = data["keys"][rule["key"]].find(letter) + 1
            if month:
                who = "maker" if rule["tier"] == "maker" else "reported"
                year = last_digit_year(digit, month, today)
                yield f"{datetime.date(year, month, 1):%B %Y}", brand["name"], who


today = datetime.date(2026, 11, 7)
for reading, brand, who in read(sys.argv[1] if len(sys.argv) > 1 else "K5", today):
    print(f"{reading:16} {brand:22} {who}")

Running it for K5 prints:

The dataset is listed with the others on our open data page, and how we know explains how sources get graded. Every maker rule on the page links to the record it came from, with the date it was read.

Limits

A maker can change its format, and the rules only cover what we could read.
A date code doesn't show how a battery was stored or how much life it has left.
Some maker sources are old, and each rule on the page shows its date.

AI assistants helped read the records and draft this post, as they do on the site. The examples were run on 7 November 2026.

What is EU 42 in US shoe sizes? 11 brands' official charts disagree

Jeremiah Say — Tue, 10 Nov 2026 13:00:01 +0000

What is EU 42 in US shoe sizes? Most converters give one number with total confidence. I went to the source and read the official size charts from 11 brands, and this is what they print for a men's EU 42:

US men's size	Charts	Brands
8.5	6	adidas, ASICS, Converse, Nike, Salomon, Timberland
9	3	Clarks, Skechers, Vans

So there are two right answers. Which one applies depends on the shoe you're buying.

That killed my plan for the shoe size converter on Toggle9. I'd expected to write a conversion function. There's no function to write, so the tool is a lookup across 15 charts with 339 rows, and its answer includes how many charts agree.

This post covers the shortcuts I tested, why they fail, and how the lookup works. The data is public if you'd like to build on it.

One label, nine answers

Run it the other way and it gets worse. Here's what 9 men's charts print for a US men's 9, using one chart per brand:

Measure	What the charts say
EU	42 (3 charts), 42.5 (3), 42⅔ (2), 43 (1)
UK	8 (6 charts), 8.5 (3)
Length	26.2 cm to 27.0 cm across 7 charts that give one

That's 0.8 cm of disagreement over the same label, from the people who make the shoes.

The shortcuts, tested

Size guides are full of quick rules. I ran the common ones against every chart row that has both columns:

Shortcut	Rows	Exact	Within half a size	Worst miss
EU = US men's + 33	251	12%	36%	6
EU = US women's + 31	228	14%	36%	6.5
UK = US women's − 2	228	24%	93%	1
UK = US men's − 1	251	71%	100%	0.5
US men's = US women's − 1.5	140	84%	100%	0.5

The EU rules are the bad ones, and the reason is in the data. The gap between US and EU isn't constant. On Converse's men's chart, US 6 is EU 38.5, a gap of 32.5. US 23 is EU 62, a gap of 39. A fixed offset can't track a gap that grows, which is why the worst misses are at the big end of the chart.

The women's-to-men's rule looks safest at 84%, but it's a good example of why the 16% matters. A women's 10 is a men's 8.5 on Nike and Vans. On adidas it's a men's 9. If a shoe only comes in men's sizes, that half size depends on the brand.

Three things that make charts hard to compare

EU sizes come in thirds. adidas prints 42⅔. In a JSON file that becomes 42.67, and now === won't find it when somebody types 42 2/3, so lookups need a tolerance:

const close = (a, b, t) => a != null && Math.abs(a - b) <= t;

"Length" doesn't mean one thing. Seven charts say foot length. adidas says heel to toe. Others label the column CM or Length, and three give no length at all. Comparing those columns is fair as "what each chart prints", but you can't call it one measurement. That's why the tool shows the column name beside the number.

US sizes are split by gender, and UK and EU usually aren't. So one UK size has two US answers, and a converter has to ask which US scale you mean.

The lookup

The core is small. Given a label, find it in every chart that carries it, then report the answers with their counts:

function answers(charts, have, value, want) {
  const tally = {};
  for (const chart of charts) {
    const row = chart.rows.find(r => Math.abs((r[have] ?? Infinity) - value) < 0.2);
    if (row && row[want] != null) (tally[row[want]] ||= []).push(chart.brand);
  }
  return Object.entries(tally).sort((a, b) => b[1].length - a[1].length);
}

answers(mensCharts, EU, 42, US_MEN);
// [["8.5", ["adidas", "ASICS", "Converse", "Nike", "Salomon", "Timberland"]],
//  ["9",   ["Clarks", "Skechers", "Vans"]]]

The design decision is in the return value. It's a list, not a number. The page leads with the most common answer because that's what people came for, then shows who says what. If you know the brand, it answers from that brand's chart alone.

Two choices are worth stealing:

Count each brand once. Nike has a men's and a women's chart that both carry men's sizes. Count both and Nike gets two votes.
Say "the chart says", never "this will fit". A size chart isn't a fit guarantee, and the tool doesn't pretend it is.

That's also why the tool starts from the foot when it can. You can enter a length in centimetres, or use the printable foot size sheet, and then every label becomes a comparison against one measurement.

What the data doesn't cover

I aimed for about 30 brands and got 11. Several sites gave me nothing readable: Crocs put up a bot challenge, New Balance returned an error page, and Puma, HOKA, Birkenstock and others had no chart I could read. I don't work around blocks, so those brands aren't in the data and I haven't filled the gaps from third-party tables.

Also, ASICS covers men's sizes only and Brooks covers women's only. There's an international standard for this, ISO 19407, but it's paywalled, and I didn't use it. These are brands' published charts, read on 7 November 2026, and any of them can change.

Use the data

Both summary tables are free to download:

The shoe size conversion tool runs in your browser and takes EU, US, UK or centimetres, with the brand charts side by side.

Every Toggle9 tool cites its sources and is re-checked on a schedule: how we check our tools explains the tests.

AI assistants helped build the tool and draft this post. The figures come from the test script run on 7 November 2026.

CPF contribution calculation in code: 2 common shortcuts fail half the time

Jeremiah Say — Mon, 09 Nov 2026 13:00:01 +0000

Singapore's CPF contribution looks like a one-line calculation. Take the wage, multiply by a rate, done. If you're building payroll, an HR tool or a salary calculator, that line is where the bugs start, because CPF Board's rule has three steps and they're in a particular order.

So I tested it. I took five shortcuts I'd expect to find in real code and ran each one against every wage from S$750.01 to S$8,000, one cent at a time. That's 725,000 wages in each of CPF's five age bands. The right answers use integers only, so floats can't affect them.

Two shortcuts fail on about half of all wages. The one I expected to fail, floating-point, didn't fail at all.

CPF Board's rule

These steps come from the CPF contribution rate table from 1 January 2026:

Work out the total contribution and round it to the nearest dollar. Below 50 cents goes down. 50 cents and above goes up.
Work out the employee's share and round it down to the nearest dollar.
Employer's share = total − employee's share.

The third step is the one people miss. The employer's rate never gets rounded on its own. That share is whatever's left.

For wages above S$750 at age 55 and below, the total rate is 37% and the employee's rate is 20%. Ordinary wages (OW) count only up to the S$8,000 monthly ceiling, which gives the table's maximums of S$2,960 and S$1,600.

Here's a worked example for a S$4,321.50 wage:

Step	Sum	Result
Total	37% × 4,321.50 = 1,598.955	S$1,599
Employee	20% × 4,321.50 = 864.30	S$864
Employer	1,599 − 864	S$735

The results

Share of wages from S$750.01 to S$8,000 that get the wrong answer, at age 55 and below, on the 2026 rates:

Shortcut	Wrong wages	Share
Round the employee's share to nearest	362,500	50.00%
Round the employer's share, then add the employee's	361,735	49.89%
Round to cents first, then to dollars	3,618	0.50%
Python's `round()` on the total	36	0.005%
Use floats, with the right rule	0	0%

The other age bands look much the same. The largest figure for the two big failures is 50.07%, and each error is one dollar. One dollar sounds harmless, but the employee and employer columns won't match what CPF expects.

Failure 1: rounding the employee's share to nearest

employee = round(wage * 0.20)   # wrong

Half of all wages land on or above 50 cents, so half get rounded up, and the employee overpays by a dollar. CPF's page says the cents "should always be dropped" for this share.

Failure 2: giving the employer its own rounding

employer = round(wage * 0.17)   # wrong
employee = floor(wage * 0.20)
total = employer + employee

I found this one described in at least one HR glossary, and it reads sensibly. But 17% plus 20% are rounded separately here, so the total can drift a dollar from 37% of the wage rounded once. It disagreed with CPF's rule on 49.89% of wages.

Failure 3: rounding twice

total = round_half_up(round(wage * 0.37, 2))   # wrong

Money code often rounds to cents at every step. Here that creates a double rounding error. On a wage of S$752.69, 37% is 278.4953. That's below 50 cents, so the total is S$278. Round to cents first and you get 278.50, which rounds up to S$279.

This hits about 1 in 200 wages. Nearly all of those wages have cents in them, so it can pass every test that uses round numbers. At 37%, not one whole-dollar wage trips it.

Failure 4: banker's rounding

Python's built-in round() sends ties to the nearest even number. CPF sends them up.

>>> round(850 * 37 / 100)    # 314.5
314

CPF's answer for S$850 is S$315. This fails rarely but on very normal wages: 36 whole-dollar amounts at 37%, such as S$850 and S$1,050. The worst band is above 60 to 65, where 906 whole-dollar wages fail, because a 25% rate lands on exact 50-cent ties far more often. numpy.round and the default Decimal context behave the same way, so set the rounding mode yourself. JavaScript's Math.round and PHP's round both send these positive ties up.

The one that didn't fail: floats

I expected this to be the headline. Floating-point has burned me before, so I tested wage * 37 / 100 with the correct rule on the 2026 and 2027 rates, and wage * 0.37 on the 2026 rates. Both gave 0 wrong answers across all five bands.

Don't read that as "floats are safe for money". It only covers this range and these rates. Integers still cost you nothing here, and you won't need to rerun the proof when the rates change.

Bonus months: round once

When ordinary and additional wages (AW) land in the same month, CPF's note 4 says to compute the contributions for both, sum them, and then apply the rounding rules. So you round once, on the sum.

total = half_up(ow * 0.37) + half_up(aw * 0.37)   # wrong

I tested 207 million OW and AW pairs at 37%, with AW up to S$2,000 in 7-cent steps, and rounding them apart gave the wrong total on 25.00% of them. With OW of S$751 and AW of S$1.41, the correct total is S$278, and rounding apart gives S$279.

Also note that the OW ceiling caps only the ordinary wage. Additional wages have their own annual ceiling of S$102,000 minus the OW subject to CPF for the year, and a bonus can take you well past S$2,960 in one month.

A small correct version

This covers wages above S$750. Everything is in cents and tenths of a percent, so nothing can drift:

OW_CEILING = 800_000  # S$8,000, in cents

def cpf(ow_cents, aw_cents, total_rate, employee_rate):
    """Rates in tenths of a percent: 370 means 37%. Returns whole dollars."""
    wage = min(ow_cents, OW_CEILING) + aw_cents
    total = (wage * total_rate + 50_000) // 100_000
    employee = wage * employee_rate // 100_000
    return total, employee, total - employee

print(cpf(432_150, 0, 370, 200))  # (1599, 864, 735)
print(cpf(1_000_000, 0, 370, 200))  # (2960, 1600, 1360)

Wages of S$750 and below need CPF's lower bands, which include a phase-in formula, and you'll need to check the AW ceiling before you call this. The live rates and age bands are on our CPF contribution rates page, which reads them from CPF Board.

Rates change, so make them data

Don't hard-code the percentages. The rates for ages above 55 to 65 go up on 1 January 2027: above 55 to 60 moves from 34% to 35.5%, and above 60 to 65 from 25% to 26%. That shifts the failure counts. Banker's rounding in the above-60 band falls from 906 wages to 72, because 26% lands on far fewer exact ties than 25%.

I also ran the formula behind the Numbers.sg CPF calculator through the same sweep, this time including the low bands: every wage from S$0.01 to S$8,000 in all five age bands, 4,000,000 checks on the 2026 rates, with 0 wrong answers.

Limits

These are the rates for Singapore Citizens and third-year-onward PRs in the private sector. Other groups have other tables.
Each dollar error is a modelled difference against CPF's written rule. I haven't sampled how real payroll products behave.
For a real submission, check the result with CPF Board's own CPF contribution calculator.

Numbers.sg reads every figure from the agency that publishes it. The update schedule shows when each one is checked next, and about Numbers.sg covers who runs the site.

AI assistants helped draft this post and write the test. The results come from the script below, run on 7 November 2026.

The full test script (Python, needs numpy)

#!/usr/bin/env python3
"""Test common CPF rounding shortcuts against CPF Board's rule, for every wage from $750.01 to $8,000
in steps of one cent, across the age bands of the rate tables from 1 Jan 2026 and 1 Jan 2027.
The right answers use integers only, so floats can't affect them. Needs numpy."""
import numpy as np

Y2026 = {"55 and below": (37, 20), "above 55 to 60": (34, 18), "above 60 to 65": (25, 12.5),
         "above 65 to 70": (16.5, 7.5), "above 70": (12.5, 5)}
Y2027 = {**Y2026, "above 55 to 60": (35.5, 19), "above 60 to 65": (26, 13)}
W = np.arange(75001, 800001, dtype=np.int64)  # wages in cents
WHOLE = W % 100 == 0


def half_up(cents, pct):
    return (cents * round(pct * 10) + 50_000) // 100_000


def floored(cents, pct):
    return cents * round(pct * 10) // 100_000


def shortcuts(tp, ep):
    T, E, w = half_up(W, tp), floored(W, ep), W / 100
    ft, fe, fr = w * tp / 100, w * ep / 100, w * (tp - ep) / 100
    up = lambda x: np.floor(x + 0.5).astype(np.int64)
    return {
        "floats, otherwise the right rule": (up(ft) != T) | (np.floor(fe).astype(np.int64) != E),
        "banker's rounding on the total (Python round)": np.round(ft).astype(np.int64) != T,
        "round to cents first, then to dollars": up(np.round(ft, 2)) != T,
        "round the employee share to nearest": up(fe) != E,
        "round employer share, add floored employee share": up(fr) + np.floor(fe).astype(np.int64) != T,
    }


def report(name, bands):
    print(f"\n{name}: {len(W):,} wages per band, {WHOLE.sum():,} of them whole dollars")
    res = {b: shortcuts(*r) for b, r in bands.items()}
    for s in next(iter(res.values())):
        print(s)
        for b in bands:
            bad = res[b][s]
            print(f"  {b:16}{bad.sum():9,} wrong ({bad.mean() * 100:6.2f}%)   whole dollars:{bad[WHOLE].sum():7,}")


def bonus_month():
    """OW $751 to $8,000 and AW $0.01 to $2,000 at 37%: round the sum once, or round OW and AW apart."""
    ow = np.arange(751, 8001, dtype=np.int64)[:, None] * 100
    aw = np.arange(1, 200001, 7, dtype=np.int64)[None, :]
    once = half_up(ow + aw, 37)
    apart = half_up(ow, 37) + half_up(aw, 37)
    bad = once != apart
    print(f"\nBonus month: {bad.size:,} OW and AW pairs, {bad.sum():,} wrong ({bad.mean() * 100:.2f}%)")
    i = np.argwhere(bad)[0]
    print("first:", ow[i[0], 0] / 100, aw[0, i[1]] / 100, "once", once[i[0], i[1]], "apart", apart[i[0], i[1]])


report("2026", Y2026)
report("2027", Y2027)
bonus_month()
for w, tp in [(850, 37), (1050, 37)]:
    print(w, "round:", round(w * tp / 100), "CPF:", half_up(np.int64(w * 100), tp))
s = shortcuts(37, 20)["round to cents first, then to dollars"]
print("cents-first example:", W[s][:3] / 100, [W[s][0] / 100 * 0.37])

Who makes Kirkland medicine? I traced 47 labels through DailyMed and openFDA

Jeremiah Say — Sat, 07 Nov 2026 13:00:02 +0000

Who makes Kirkland medicine? The box says Costco. The US government's drug label library says Costco too, because Costco is the labeler. But the same label file usually holds one more clue: an FDA application number, an establishment, or a small printed line such as "Distributed By Perrigo".

So I wrote a script that follows those clues through two free public APIs. On 7 November 2026 it listed 50 Costco labels, dropped the 3 last updated in 2010, and traced the other 47:

Company	Labels
Perrigo	28
LNK International	8
Not named	2
PPI-DAC	2
Bionpharma, Patheon Softgels, Dexcel Pharma, Amneal, Guardian Drug Company, Ohm Laboratories, PL Developments	1 each

The headline is easy. The interesting part is what those rows can and can't prove, because 19 of the 47 rest on evidence that doesn't show who made the pills.

This post covers the join, the strength of each kind of evidence, and four traps in the data. The full script is at the end. It uses only the Python standard library.

The two APIs

DailyMed is the US National Library of Medicine's library of drug labels. Its REST API lists labels by labeler and returns each one as a Structured Product Labeling (SPL) XML file:

DM = "https://dailymed.nlm.nih.gov/dailymed/services/v2"

def labels():
    page, out = 1, []
    while True:
        d = json.loads(get(f"{DM}/spls.json?labeler=Costco&pagesize=100&page={page}"))
        out += d["data"]
        if page >= d["metadata"]["total_pages"]:
            return out
        page += 1

openFDA publishes Drugs@FDA as JSON. Give it an application number and it returns the company that holds that approval:

FDA = "https://api.fda.gov/drug/drugsfda.json"

def holder(app, cache={}):
    if app not in cache:
        q = urllib.parse.quote(f'application_number:"{app}"')
        try:
            cache[app] = json.loads(get(f"{FDA}?search={q}"))["results"][0]["sponsor_name"]
        except Exception:
            cache[app] = None
        time.sleep(0.3)
    return cache[app]

The join key is the application number inside the SPL file. It sits in an extension attribute, and for a job this small a regex is enough:

def application(xml):
    m = re.search(r'extension="((?:ANDA|NDA|BLA)\d{6})"', xml)
    return m.group(1) if m else None

That's the whole pipeline: labeler to label, label to application, application to holder. A naive version stops here and prints "made by". It would be wrong.

Not all evidence is the same strength

An FDA approval holder has permission to market a drug. It can still use someone else's plant. A distributor sells a product, and it may not have made it. So the script keeps the strongest clue it finds and records which kind it was.

It tries these in order:

The file lists a company as an establishment doing manufacture. That's a filed statement about an operation.
The label prints a line such as "Manufactured by", "Packaged by" or "Distributed by", naming a company.
Only the FDA approval holder is known.

if plant:
    company, how = plant, "file lists it as a manufacturer"
elif who:
    company, how = who, f"label says {verb} by"
elif held:
    company, how = HOLDERS.get(held, held), "FDA approval holder only"
else:
    company, how = "Not named", "nothing to go on"

Here's how the 47 labels split:

Evidence	Labels
File lists a manufacturer	10
Label says "Manufactured by"	1
Label says "Packaged by"	5
Label says "Distributed by"	10
FDA approval holder only	19
No company on the label file	2

Only 11 labels reach the top two rows. That's why the title says "lead to" and not "are made by".

Perrigo's 28 break down like this: 1 "Manufactured by", 5 "Packaged by", 9 "Distributed by" and 13 approval holder only. LNK's 8 are all establishment listings, and 5 of those have no application number at all, so a holder lookup alone would have missed them.

Trap 1: one company, four spellings

openFDA doesn't give you a company ID. It gives you a sponsor name, and FDA's short form varies. Perrigo arrived as:

PERRIGO R AND D
PERRIGO PHARMA INTL
PERRIGO
L PERRIGO CO

A plain Counter on that field makes Perrigo look like four mid-sized suppliers, and the biggest would hold 11 labels instead of 28. You need an explicit alias table, and each alias is a decision you should be able to defend:

HOLDERS = {"PERRIGO": "Perrigo", "PERRIGO R AND D": "Perrigo", "PERRIGO PHARMA INTL": "Perrigo",
           "L PERRIGO CO": "Perrigo", "LNK": "LNK International"}

The fifth spelling is the one to leave alone. PPI-DAC holds 4 of these applications. No record I hold ties that string to a named company, so it stays as written. Two of those 4 labels print "Packaged By Perrigo", which is why they count for Perrigo. The other 2 stay as PPI-DAC.

Fuzzy matching could merge it without asking. Guessing a company name is the one mistake this dataset can't afford.

Trap 2: the two sources disagree

Kirkland Aller-Flo prints "Distributed By Perrigo". openFDA gives the holder of its application, ANDA207957, as HIKMA.

Neither record is wrong. They answer different questions: who sells it on, and who holds the approval. If you collapse both into a single maker column, you lose that. So keep the holder and the printed line side by side, and let the row say which one you used.

Trap 3: no application number doesn't mean no data

9 of the 47 labels have no application number, including Kirkland acetaminophen and low dose aspirin. They're sold under FDA's over-the-counter monograph rules instead of a drug-by-drug approval, so there's nothing to join on.

If your script treats a failed join as "unknown", those labels vanish. Reading the SPL's establishment list recovers most of them:

def establishment(root):
    """A company the file lists as doing the manufacture, other than Costco."""
    for e in root.findall(".//h:assignedEntity", NS):
        name = e.findtext("h:assignedOrganization/h:name", default="", namespaces=NS)
        ops = {c.get("displayName", "").lower()
               for c in e.findall(".//h:performance/h:actDefinition/h:code", NS)}
        if "manufacture" in ops and known(name):
            return known(name)

Trap 4: a matching number doesn't mean the same pills

The tempting next step is comparing Kirkland with name brands. In our Kirkland vs name brands table, 6 of the 41 medicine comparisons list one FDA application number on both labels. Kirkland Ibuprofen IB and Motrin IB, for example, both rely on ANDA077349, held by Perrigo.

That's the closest thing to "the same product" a public record gives you. It still doesn't show the same plant or the same lot. It only shows that both labels rely on one approval.

So who makes what?

These are the answers for the most searched products, with the evidence level each one reaches:

Kirkland minoxidil: Perrigo. The 5% solution label says "Manufactured By Perrigo Yeruham 80500, Israel". The foam says "Distributed By Perrigo", and FDA gives Perrigo as the holder of ANDA091344.
Kirkland sleep aid: LNK International. The file lists LNK as doing the manufacture, and FDA gives LNK as the holder of ANDA040564.
Kirkland allergy medicine: it depends on the box. Aller-Tec, Aller-Fex and most AllerClear labels trace to Perrigo through their FDA approvals, while one AllerClear D 24 Hour label says "Manufactured by: Ohm Laboratories".
Kirkland ibuprofen: four companies, depending on the pack.

You can search all 44 products by name, Costco item number, NDC or pill mark on the Kirkland medicine page. The 47 labels fill 44 rows because one medicine can have more than one label. We don't test medicines or give medical advice, so ask a pharmacist which one suits you.

Limits

A record names a company. It doesn't say which plant made the bottle in your hand.
The company list in the script is short on purpose, so it can miss a name. Writing this post caught that on our own site: the page said the Kirkland stool softener's file named no company, but the label says "Distributed by: PL Developments". We fixed it and logged it on our corrections page. That line names a distributor, not a maker.
These are labels on DailyMed with Costco as the labeler, not a sample of everything Costco sells.
The label file may not match an older pack still on a shelf.
FDA asks anyone using openFDA not to rely on it for medical care decisions.

Data provided by the U.S. Food and Drug Administration (https://open.fda.gov). This post isn't endorsed by FDA.

The stamps, evidence quotes and SHA-256 fingerprints behind the site are explained on how we know, and the records are open data under CC BY 4.0, also on GitHub and archived on Zenodo with a DOI. Every claim is re-checked within six months, on the dates in our update schedule.

AI assistants helped read the records and draft this post, as they do on the site. The numbers come from the script below, run on 7 November 2026.

The full script (stdlib only)

#!/usr/bin/env python3
"""Trace Costco's Kirkland Signature drug labels from DailyMed to the company behind them.
Standard library only. Writes labels.json and prints the tally."""
import collections, json, re, time, urllib.parse, urllib.request
import xml.etree.ElementTree as ET

UA = {"User-Agent": "kirkland-label-trace/1.0"}
DM = "https://dailymed.nlm.nih.gov/dailymed/services/v2"
FDA = "https://api.fda.gov/drug/drugsfda.json"
NS = {"h": "urn:hl7-org:v3"}
LINE = re.compile(r"(Manufactured|Distributed|Packaged|Made)\s+by:?\s*(.{0,40})", re.I)
HOLDERS = {"PERRIGO": "Perrigo", "PERRIGO R AND D": "Perrigo", "PERRIGO PHARMA INTL": "Perrigo",
           "L PERRIGO CO": "Perrigo", "LNK": "LNK International"}
KNOWN = {"perrigo": "Perrigo", "lnk": "LNK International", "ohm lab": "Ohm Laboratories",
         "guardian drug": "Guardian Drug Company"}
DISTRIBUTORS = {"pl developments": "PL Developments"}  # last resort: used only when nothing better names a company


def get(url):
    with urllib.request.urlopen(urllib.request.Request(url, headers=UA), timeout=60) as r:
        return r.read().decode("utf-8", "replace")


def labels():
    page, out = 1, []
    while True:
        d = json.loads(get(f"{DM}/spls.json?labeler=Costco&pagesize=100&page={page}"))
        out += d["data"]
        if page >= d["metadata"]["total_pages"]:
            return out
        page += 1


def known(text, names=KNOWN):
    t = text.lower()
    return next((v for k, v in names.items() if k in t), None)


def application(xml):
    m = re.search(r'extension="((?:ANDA|NDA|BLA)\d{6})"', xml)
    return m.group(1) if m else None


def establishment(root):
    """A company the file lists as doing the manufacture, other than Costco."""
    for e in root.findall(".//h:assignedEntity", NS):
        name = e.findtext("h:assignedOrganization/h:name", default="", namespaces=NS)
        ops = {c.get("displayName", "").lower() for c in e.findall(".//h:performance/h:actDefinition/h:code", NS)}
        if "manufacture" in ops and known(name):
            return known(name)


def printed_line(root, names=KNOWN):
    text = " ".join(ET.tostring(root, encoding="unicode", method="text").split())
    for verb, rest in LINE.findall(text):
        if known(rest, names):
            return known(rest, names), verb.lower()
    return None, None


def holder(app, cache={}):
    if app not in cache:
        q = urllib.parse.quote(f'application_number:"{app}"')
        try:
            cache[app] = json.loads(get(f"{FDA}?search={q}"))["results"][0]["sponsor_name"]
        except Exception:
            cache[app] = None
        time.sleep(0.3)
    return cache[app]


def trace(s):
    xml = get(f"{DM}/spls/{s['setid']}.xml")
    root = ET.fromstring(xml)
    app = application(xml)
    held = holder(app) if app else None
    plant = establishment(root)
    who, verb = printed_line(root)
    if plant:
        company, how = plant, "file lists it as a manufacturer"
    elif who:
        company, how = who, f"label says {verb} by"
    elif held:
        company, how = HOLDERS.get(held, held), "FDA approval holder only"
    elif printed_line(root, DISTRIBUTORS)[0]:
        company, how = printed_line(root, DISTRIBUTORS)[0], "label says distributed by"
    else:
        company, how = "Not named", "no company on the label file"
    return {"setid": s["setid"], "title": s["title"], "published": s["published_date"],
            "application": app, "holder": held, "company": company, "how": how}


def main():
    all_labels = labels()
    rows = [trace(s) for s in all_labels if not s["published_date"].endswith("2010")]
    json.dump(rows, open("labels.json", "w"), indent=1)
    print(len(all_labels), "labels listed,", len(rows), "after dropping those last updated in 2010")
    for name, n in collections.Counter(r["company"] for r in rows).most_common():
        print(f"{n:3} {name}")
    print()
    for k, n in collections.Counter(r["how"].split(" by")[0] for r in rows).most_common():
        print(f"{n:3} {k}")


if __name__ == "__main__":
    main()

Turning a drawing into a dot-to-dot puzzle: Moore tracing, Visvalingam–Whyatt and a label placer

Jeremiah Say — Fri, 30 Oct 2026 13:00:03 +0000

A dot-to-dot looks like the simplest printable there is. Then you try to generate one and find three separate problems:

Which points become dots? Too few on the T. rex's jaw and it turns into a potato. Too many on its claws and the rest of the outline gets none.
How do you offer 20, 50 or 100 dots of the same picture without hand-placing every version?
Where does each number go? A number that sits nearer to dot 18 than to dot 17 will send a six-year-old the wrong way.

I built the dot to dot printables on Toggle9 with 17 pictures: 10 dinosaurs, a Pteranodon and 6 Christmas pictures. You pick a picture, a count (20, 30, 50, 75 or 100 dots) and how to count (1s, 2s, 5s, 10s, or the alphabet in capitals or small letters). Here's the same T. rex at three counts, made by the code in this post:

The work is split in two. A Python build step turns each drawing into a ranked list of outline points, once. The browser then picks the dots and places the numbers each time you change a setting. The code below is trimmed from the real files, but the logic is unchanged.

Step 1: find the outline

The source is a line drawing: black lines on white. The dots should follow the outer outline. Everything inside it (the eye, the mouth, the arm) stays as a printed line, so the finished picture still looks like a T. rex.

Finding the outer outline of a line drawing is harder than it sounds, because a line drawing has gaps where lines nearly meet. A flood fill from the edge of the image would leak through the gap under the jaw and into the body. So the build step first thickens the lines a little to close the gaps, floods from the border, and then shrinks the result back:

def silhouette(a, close=4):
    g = grow(a, close)                       # thicken lines by 4 px: small gaps close
    lab, sizes = components(~g)              # label the empty regions
    border = set(np.unique(np.concatenate([lab[0], lab[-1], lab[:, 0], lab[:, -1]]))) - {0}
    sil = ~np.isin(lab, list(border))        # everything not reachable from the edge
    sil = shrink(sil, close)                 # back to the ink's real outer edge
    lab2, sz2 = components(sil); sz2[0] = 0
    return lab2 == sz2.argmax()              # keep the biggest piece

Step 2: trace it

Now there's a solid shape. A Moore-neighbour trace walks round its edge: from the current edge pixel, look at the 8 neighbours clockwise, starting just after the one you came from, and step to the first one that's inside the shape. Stop when you're back at the start.

D = [(-1, 0), (-1, 1), (0, 1), (1, 1), (1, 0), (1, -1), (0, -1), (-1, -1)]
cur, back = start, 6          # start at the top-left pixel; west of it is outside
out = [cur]
while True:
    for k in range(1, 9):
        j = (back + k) % 8
        y, x = cur[0] + D[j][0], cur[1] + D[j][1]
        if inside(y, x):
            oy, ox = cur[0] + D[(j - 1) % 8][0], cur[1] + D[(j - 1) % 8][1]
            back = D.index((oy - y, ox - x))   # remember the last outside pixel we looked at
            cur = (y, x); break
    if cur == start: break
    out.append(cur)

The trace is resampled every 3 pixels and lightly smoothed, so the outline doesn't have a pixel staircase. Then there's one detail that's easy to miss. The trace runs along the outer edge of a 9-pixel line, so every point gets moved inward by half a line width. Otherwise the dots float just outside the drawing.

Step 3: rank every point by how much it matters

This is the step that makes "any count from 20 to 100" possible. Instead of choosing 50 dots, the build step ranks every point on the outline, using the Visvalingam–Whyatt algorithm.

For each point, take the triangle it forms with its two neighbours. A small triangle means removing the point barely changes the shape. Repeatedly remove the point with the smallest triangle, recompute its two neighbours, and record the order things were removed in. The last points to go are the ones the shape can't do without: the tip of the snout, the corner of the tail.

def importance(p):
    n = len(p)
    prev = [(i - 1) % n for i in range(n)]; nxt = [(i + 1) % n for i in range(n)]
    area = lambda i: abs((p[prev[i]][0] - p[i][0]) * (p[nxt[i]][1] - p[i][1])
                       - (p[nxt[i]][0] - p[i][0]) * (p[prev[i]][1] - p[i][1])) / 2
    alive = [True] * n; cur = [area(i) for i in range(n)]
    h = [(cur[i], i) for i in range(n)]; heapq.heapify(h)
    order = np.zeros(n, int); r = 0; last = 0.0
    while h and r < n - 3:
        a, i = heapq.heappop(h)
        if not alive[i] or a != cur[i]: continue        # stale heap entry
        last = max(last, a)        # a point can't be worth less than the one removed before it
        alive[i] = False; order[i] = r; r += 1
        pi, ni = prev[i], nxt[i]; nxt[pi] = ni; prev[ni] = pi
        for j in (pi, ni):
            cur[j] = max(area(j), last); heapq.heappush(h, (cur[j], j))
    ...

The last = max(...) line is a common fix for Visvalingam–Whyatt. Without it, removing a point can make a neighbour's triangle smaller than the one just removed, and the ranking stops matching what you see.

The build keeps the 300 highest-ranked points per picture, in order round the outline, and writes them to a JSON file with each point's rank. The inner lines go in the same file as an SVG path.

Step 4: pick the dots in the browser

At run time, picking 50 dots could be as simple as "the 50 highest-ranked points". That nearly works. The problem is detail: a claw or a row of spines has lots of sharp corners, so it ranks highly and soaks up the dots. Ten dots on one claw and a straight run of back with none.

So the picker takes points in rank order but skips any point too close to one it already has. It starts with a minimum gap of the outline's length ÷ (n × 1.6), and relaxes the gap by 15% until n points fit:

export function pick(pts, n) {          // pts: [x, y, rank]
  const N = pts.length; if (n >= N) return pts.map((_, i) => i);
  let L = 0;
  for (let i = 0; i < N; i++) { const a = pts[i], b = pts[(i + 1) % N]; L += Math.hypot(b[0] - a[0], b[1] - a[1]); }
  const order = pts.map((_, i) => i).sort((a, b) => pts[a][2] - pts[b][2]);
  let dmin = L / (n * 1.6);
  for (;;) {
    const got = [];
    for (const i of order) {
      const p = pts[i];
      if (got.every(j => Math.hypot(pts[j][0] - p[0], pts[j][1] - p[1]) >= dmin)) got.push(i);
      if (got.length === n) return got.sort((a, b) => a - b);   // back in outline order
    }
    dmin *= 0.85;
  }
}

Sorting the result by index puts the dots back in order round the outline, so dot 1 to dot n traces the shape.

Step 5: place the numbers

This took the most work, and it's the part people notice. Each number needs a spot that's:

next to its own dot, on the outside of the shape where possible,
not on top of another number or another dot,
not across a line the child will draw between two dots,
not on the drawing's inner lines,
and clearly nearer its own dot than any other.

The placer tries 12 angles around the outward direction at 3 distances, and scores each spot. Lower is better:

Problem	Cost
Overlaps a number already placed	1,000
Touches another dot	500
Closer to another dot than to its own	200
Crosses a line between two dots	80
Nearly as close to another dot (within 1.35×)	60
On one of the drawing's inner lines	30
Turned away from straight out, or pushed further out	a little, growing with the angle and distance

Crowded dots are placed first, while there's still room around them. The 60-point rule is the one I added after watching the output: a number can be technically closest to its own dot and still look like it belongs to the next one. To check it was worth having, I ran today's code with and without that rule at 50 dots across all 17 pictures. Without it, 24 of 850 numbers are unclear. With it, 2.

Step 6: test every combination

There are 17 pictures, 5 counts and 6 ways of counting, and phones show the numbers up to 2× bigger than print. That's too many combinations to check by eye, so the tests check all of them:

test('the numbers never sit on another number or another dot, printed or at the phone sizes', () => {
  for (const k of KEYS) for (const n of DOTS) for (const f of (n <= 30 ? [1, 2] : n <= 50 ? [1, 1.3] : [1])) {
    const Lo = layout(A[k], '1', n, Math.min(190 / A[k].w, 230 / A[k].h) / f);
    // ...every pair of number boxes must not overlap, and no number box may cover another dot
  }
});

Another test checks that every picture at every count has the right number of dots, in outline order, and that no two dots are closer than 2.5 dot radii. One Christmas picture failed that at first: the first candy cane was so tall and thin that 100 dots crowded together on it. I redrew it, and it passed.

What I'd do differently

Start from silhouettes, not detailed art. I first tried feeding in the site's detailed coloring-page art. The cute Spinosaurus's outline leaked into its body, and the baby dinosaur lost its egg. Clean, simple line drawings work far better.
Write the "can a child read this?" test first. Overlap tests pass long before the output is good enough for a child to use. The "which dot does this number belong to?" check is the one that matters most.
Keep the slow work at build time. Tracing and ranking run once per drawing in Python. The browser only sorts 300 points and scores a few thousand candidate spots, so changing the count needs no server at all.

You can try it at Toggle9's dot to dot printables. It prints free with no sign-up, with an answer page if you want one.

Have you built anything that puts labels on a drawing or map? I'd like to hear what scoring you ended up with. Label placement turned out to be the most interesting part of this.

I tested my browser-based email checkers against dkimpy, checkdmarc and pyspf: 12,618 results, 76 disagreements

Jeremiah Say — Tue, 27 Oct 2026 13:00:02 +0000

I built five email security tools for Toggle9 that run in the browser: a DKIM checker, a DMARC checker, an SPF checker, an MX lookup and an email header analyzer. There's no backend. DNS queries go from your browser to Cloudflare's public resolver, and DKIM signatures are verified with WebCrypto.

That raises an obvious question: why would anyone trust a JavaScript reimplementation of RFC 6376? There are established open-source libraries for all of this: dkimpy for DKIM, checkdmarc for DMARC and MX, pyspf (the reference implementation of RFC 7208) for SPF, and mail-parser for headers.

So I ran each tool against one of them, on real data, and read every result where they disagreed.

The scoreboard

Tool	Reference	Test set	Compared	Same answer
DKIM checker	dkimpy 1.1.8	510 real emails from 18 public mailing lists	623 signatures	623
Email header analyzer	mail-parser 4.8.0	The same 510 emails	2,333 hops	2,333
DMARC checker	checkdmarc 5.17.2	747 popular domains (Tranco top 500 + top 250 .uk)	705 domains	692 (98.2%)
SPF checker	pyspf 2.0.14	The first 200 of those domains that publish SPF	454 IP checks	451
MX lookup	checkdmarc 5.17.2	746 domains	8,503 checks	8,443

That's 12,618 results and 76 disagreements. The benchmarks ran on 22 and 23 October 2026. The rest of this post is about those 76.

How a browser does DNS

Every tool here needs DNS: TXT records for SPF, DMARC and DKIM keys, MX records, and TLSA and PTR records. Browsers can't send raw DNS queries, but they can use DNS over HTTPS. Cloudflare's resolver answers JSON:

const r = await fetch(`https://cloudflare-dns.com/dns-query?name=${encodeURIComponent(name)}&type=${type}`, {
  headers: { accept: 'application/dns-json' },
  referrerPolicy: 'no-referrer',
  credentials: 'omit',
});
const j = await r.json();
// j.Status: 0 = NOERROR, 3 = NXDOMAIN. j.Answer: [{ name, type, TTL, data }]

The real resolver adds a cache per check, a limit of six queries in flight, a 6-second timeout and one retry. An SPF check can fan out into dozens of lookups, so the cache matters more than you'd expect.

For DMARC, SPF and MX, my tools and the reference libraries queried the same resolver (1.1.1.1), so a difference can't be blamed on two resolvers seeing different DNS.

DKIM: 623 of 623, and why 65 signatures "failed"

DKIM verification is canonicalization (RFC 6376 section 3.4), then a hash, then a signature check. The relaxed header rule fits in a few lines:

export function canonHeader(raw, how) {
  if (how === 'simple') return raw + '\r\n';
  const i = raw.indexOf(':');
  const name = raw.slice(0, i).replace(/[ \t]+$/, '').toLowerCase();
  const val = raw.slice(i + 1).replace(/\r\n(?=[ \t])/g, '').replace(/[ \t]+/g, ' ').replace(/^ | $/g, '');
  return `${name}:${val}\r\n`;
}

WebCrypto handles both DKIM signing algorithms, RSA and Ed25519 (simplified):

if (alg === 'ed25519-sha256')
  return crypto.subtle.importKey('raw', pubKey, { name: 'Ed25519' }, false, ['verify']);
return crypto.subtle.importKey('spki', spki, { name: 'RSASSA-PKCS1-v1_5', hash: 'SHA-256' }, false, ['verify']);

The test set was 510 recent posts to 18 public mailing lists, taken from lore.kernel.org's public git mirrors. They had 623 signatures from 57 domains; two of the signatures used Ed25519. dkimpy and my checker gave the same pass or fail on all 623.

The useful part was the 65 signatures that failed in both. A checker that just says "fail" isn't much help, so mine reads the receiving server's own Authentication-Results header (RFC 8601) to work out when the email changed:

62 had passed when the email arrived, according to the receiving server. They were changed afterwards. In 60 of them, a signed List-Unsubscribe header was missing: the archive removes it before it publishes the email.
3 had already failed on arrival. They were changed on the way.

So most of the "broken DKIM" in that set wasn't broken at delivery. It's what an archive does to an email. That's the line the tool shows: "The email was fine when it was delivered."

Email headers: 2,333 of 2,333

The header analyzer turns Received: headers into a route: which server handed the email to which, when, and how long each hop took. mail-parser parses the same headers. On the same 510 emails, both found the same number of hops in every email, and all 2,333 hops matched on server, time and delay.

DMARC: the benchmark caught my bug

The first DMARC run agreed on everything for 682 of 705 domains (96.7%). I read every difference, and the biggest group was mine to fix.

My checker called it an error when an SPF record reached the same include: from two branches. msn.com, doi.org, grammarly.com and 7 others do this. I'd treated a repeat as a loop. Nothing in RFC 7208 makes a repeated include an error. Real loops get caught by the 10-lookup limit, and a repeat just counts against that limit. The fix: follow the repeat, count it again, and show a warning.

The second run agreed on 692 of 705 (98.2%). I read the 13 that were left by hand, against the RFCs:

Domains	What happened	Who's right
www.gov.uk, legislation.gov.uk, account.gov.uk, data.gov.uk	No DMARC record of their own. The parent gov.uk record's `sp=none` applies to subdomains (RFC 9989).	Mine
gcdn.co, thomsonreuters.co.uk	SPF includes a name that doesn't exist in DNS, which is a permerror (RFC 7208 section 5.2)	Mine
weather.com	An unrelated TXT record at `_dmarc` alongside the real one; checkdmarc rejects it	Mine
autodesk.com	An `=` in the local part of a `ruf` address, which the standard allows	Mine
alibabadns.com	`v=SPF1` in capitals. The ABNF is case-insensitive.	Mine
globo.com	`rua=mailto: dmarc@…` with a space. Both call the address invalid; checkdmarc then rejects the whole record, but RFC 9989 keeps `p=none`.	Mine
iiko.it, who.int	15 and 17 DNS lookups (iiko.it confirmed by hand through 1.1.1.1). checkdmarc stops counting early.	Mine
ozon.ru	checkdmarc timed out	Neither

"Mine" is my reading of the standards, written up with the RFC section each time. You don't have to take my word for it: the domains are real, so you can check them.

None of this makes checkdmarc a bad library. Rejecting a record the standards would accept is a reasonable choice for a tool that audits your own domain. Mine follows the standards' wording, because its job is to explain what a receiver should do with the record.

SPF: 451 of 454, and the 3 that weren't real

For each of 200 domains, I tested up to four IP addresses: the domain's own mail server, an address inside a range its record lists, an address reserved for documentation that never sends email, and a Google sending address for domains that include Google.

Three results differed: youtube.com, archive.org and youtube-nocookie.com, all for the same Google address. Large providers' DNS answers rotate, so an address can be listed in one lookup and missing from the next. Run again side by side, both tools agreed on all three.

MX: 8,443 of 8,503, and the rotation problem

The MX lookup checks a lot per domain: the MX hosts, their addresses, reverse DNS (PTR) and whether it points back, TLSA (DANE) records, MTA-STS and TLS reporting. Across 746 domains that came to 8,503 comparisons.

MX host sets matched on all 746 domains. MTA-STS and TLS reporting matched on all 746 too.

The addresses were the hard part. 738 of the 1,246 mail servers answered with a different few of their addresses each time. Google, Microsoft and Proofpoint spread their load that way, so two lookups a few minutes apart rarely agree, from any tool. Comparing those sets directly would only measure luck.

So the benchmark asks each server again over a few seconds. If those lookups turn up every address either tool saw, the server counts as rotating and isn't compared. That left 508 servers with steady answers, and 458 matched exactly. Of the 50 that didn't, 47 are Google or Proofpoint servers of the same rotating kind, whose other address didn't turn up in those few seconds.

The remaining 10 were differences in records. On 26 October I checked each one by hand through 1.1.1.1. In every case, the record my tool found is there:

TLSA: mx.ietf.org, two comcast.net servers and cm.com's Microsoft server publish TLSA records. checkdmarc reported none.
PTR: three servers (nic.ru, debian.org, ebi.ac.uk) have reverse DNS. checkdmarc reported none.
Forward-confirmed PTR: two huawei.com names do resolve back to their addresses.
Addresses: one Outlook server has IPv6 addresses that checkdmarc didn't list.

What I'd tell anyone writing a benchmark like this

A reference library is a witness, not a judge. If you count disagreements as your failures, you end up copying the library's choices. Read each one against the spec.
Read every difference, especially at the start. My first DMARC run had a real bug hiding behind a 96.7% score that looked fine.
Handle rotating answers before comparing. Otherwise you're measuring DNS load balancing, not your code.
Tie the results to the code. Each tool's test file hashes its engine and compares that with the hash stored in its benchmark result. Change the DKIM verifier without re-running the benchmark, and npm test fails:

test('dkim-bench.json was made by the engine that ships', () => {
  const b = JSON.parse(readFileSync(new URL('dkim-bench.json', dir), 'utf8'));
  const h = createHash('sha256')
    .update(readFileSync(new URL('verify.js', dir)))
    .update(readFileSync(new URL('compute.js', dir)))
    .digest('hex').slice(0, 16);
  assert.equal(b.engine, h);
});

So the numbers quoted on each tool's page can't silently drift away from the code.

Try them

All five run in your browser, with no account. When you check a domain, only the DNS names go to Cloudflare's public resolver. Headers and emails you paste are read on your device.

If you check DMARC for a living, I'd like to hear where you think I've read RFC 9989 wrong, especially on those 13.

I audited every network request on 200 tool pages. Here's what "runs in your browser" actually means

Jeremiah Say — Mon, 26 Oct 2026 03:31:55 +0000

Every tool on Toggle9 has a small chip under its title: Runs in your browser. It's an easy thing to write and a hard thing to prove. A chip doesn't stop a script from phoning home, and "we respect your privacy" banners are cheap.

So I tested it. On 26 October 2026 I loaded every published tool page, all 200 of them, in a fresh headless browser and logged every request each page made. Then I did it again with Global Privacy Control switched on, and a third time with the network cut.

This post covers the script, what it found, the one tool where my own label was wrong, and a 35-line version you can point at your own site.

What "runs in your browser" is supposed to mean

For a calculator, it comes down to four things:

The maths runs on your device. The page downloads the tool's JavaScript, and every answer is worked out in your browser as you type. There's no "Calculate" button that posts your numbers to a server.
Your inputs live in the URL fragment. Type a loan amount and the link becomes .../loan-calculator/#a=250000&r=6.5. Refresh or press Back and your inputs come back. Browsers never send the part after #: RFC 3986, section 3.5, says the fragment is "separated from the rest of the URI prior to a dereference" and handled "solely by the user agent".
Recent calculations go in localStorage, which, unlike a cookie, is never attached to a request.
Analytics, where it's on, gets the page address and nothing you typed.

Each of those is a claim about network traffic, so you can test it by watching the network.

The test

The audit is a Node script using Playwright with Chrome's headless shell. For each published tool page it opens a fresh browser context (no cookies, no storage) and runs three passes.

Pass 1, normal load. It records every request for 5 seconds after load. The URL carries a test word in the fragment, #auditprobe=hashtest123. If that word shows up in any request URL or POST body, something is reading the fragment and sending it on.

page.on('request', r => reqs.push({ url: r.url(), post: r.postData() || '' }));
await page.goto(url + '#auditprobe=' + PROBE, { waitUntil: 'load', timeout: 45000 });
await page.waitForTimeout(5000);
// ...
leak: reqs.some(r => r.url.includes(PROBE) || r.post.includes(PROBE))

It also decodes the dl (document location) parameter of every Google Analytics hit and checks it has no # in it.

Pass 2, Global Privacy Control on. GPC is a browser signal (navigator.globalPrivacyControl === true) that means "don't sell or share my data". Brave, DuckDuckGo and Firefox (with a setting) send it. Playwright has no switch for it, so the script fakes it before any page script runs:

await ctx.addInitScript(() =>
  Object.defineProperty(Navigator.prototype, 'globalPrivacyControl', { get: () => true }));

Pass 3, offline. Load the page, cut the network with context.setOffline(true), type 37 into the first number box, and check the answer changed. If the maths really runs locally, losing the network shouldn't matter.

await ctx.setOffline(true);
const before = await p.locator('.t9-tool').innerText();
await inp.fill('37'); await inp.dispatchEvent('input');
await p.waitForTimeout(1200);
return before === (await p.locator('.t9-tool').innerText()) ? 'NO CHANGE' : 'updated';

Four pages run in parallel, from a laptop.

What it found

Where the pages connected	Pages, of 200	With GPC on
toggle9.com (the page, its code, fonts, images, data files)	200	200
googletagmanager.com (loads Google Analytics)	200	0
google-analytics.com (the visit count)	200	0
Anywhere else	0	0

The # test word reached no server on any page, and no Analytics hit carried a fragment.
With GPC on, 0 pages contacted Google.
Offline: 128 of 129 tools with a number box kept updating. The one that didn't is the crossword solver, which fetches its word lists when you search. That's expected, but it's a good reminder that "runs in your browser" doesn't always mean "works without a connection".

No ad networks, no font CDNs, no third-party error trackers. The fonts are served from the site itself, so there's no Google Fonts request either.

How GPC is handled

The analytics loader checks the signal first. If it's set, it clears any old _ga cookies and returns before Google's script is ever added to the page:

function gpc() { return navigator.globalPrivacyControl === true }

if (gpc()) { clear(); return; }          // never load Analytics, wipe old _ga cookies
var c = get();                            // the visitor's saved choice, if any
if (c === 'denied') return;
if (c === 'granted') { load(); return; }
// No choice yet: ask first in the EU, EEA, UK and Switzerland, otherwise load

The important part is the order. GPC wins over everything, including a "yes" saved earlier, so a visitor who turns the signal on later doesn't have to find a settings page.

The tool where my own label was wrong

Not every tool can run entirely on your device. A DMARC checker has to ask DNS for a domain's records, and a mileage calculator needs a road distance from a routing service. Those tools are meant to replace the default line, "Nothing you type leaves this page", with a specific one: what they send, when, and to whom.

When I built the page explaining the chip, I went through every tool's line against what its code actually fetches. The mileage calculator was still showing the default. It sends the two places' map points (rounded to about 11 m) to my server, which asks openrouteservice for the distance. The label said nothing left the page.

Nothing was hidden, since the request was right there in the network tab, but the label was false. I fixed it and logged it as a correction. The build now generates a trust file from every tool's engine, so a tool that fetches anything has to declare what it sends, or it doesn't get the default line.

The lesson I took from it: the network test proves what happens when a page loads, not when you press every button. The audit waits 5 seconds and types into one box. Lookups that only fire on a "Check" button need a second source of truth, and for me that's each tool's own declaration, listed on one page.

What this doesn't prove

To be clear about the limits:

It's my test, not an outside audit. Nobody independent has checked Toggle9.
Loading a page is still a request. Cloudflare and my server see your IP address and which page you opened, like any website.
A fragment is private, not secret. It stays in your browser history, and anyone you share the link with sees your inputs.
Browser extensions can read any page you open. "Runs in your browser" can't protect you from your browser.

Run it on your own site

Here's a stripped-down version you can point at any URL. It lists every host a page contacts in its first 5 seconds, with GPC off and on, and flags it if the # test word reaches a server.

// npm i playwright && npx playwright install chromium
// node who-does-it-call.mjs https://example.com/page [more URLs...]
import { chromium } from 'playwright';

const PROBE = 'hashprobe' + Date.now();
const browser = await chromium.launch();

async function hosts(url, gpc) {
  const ctx = await browser.newContext();
  if (gpc) await ctx.addInitScript(() =>
    Object.defineProperty(Navigator.prototype, 'globalPrivacyControl', { get: () => true }));
  const page = await ctx.newPage();
  const seen = {}; let leaked = false;
  page.on('request', r => {
    if (r.url().includes(PROBE) || (r.postData() || '').includes(PROBE)) leaked = true;
    const u = new URL(r.url());
    if (u.protocol.startsWith('http')) seen[u.host] = (seen[u.host] || 0) + 1;
  });
  await page.goto(`${url}#probe=${PROBE}`, { waitUntil: 'load' });
  await page.waitForTimeout(5000);
  await ctx.close();
  return { seen, leaked };
}

for (const url of process.argv.slice(2)) {
  for (const gpc of [false, true]) {
    const { seen, leaked } = await hosts(url, gpc);
    console.log(`\n${url}  (GPC ${gpc ? 'on' : 'off'})${leaked ? '  ⚠ # word reached a server' : ''}`);
    for (const [h, n] of Object.entries(seen).sort((a, b) => b[1] - a[1])) console.log(`  ${String(n).padStart(3)}  ${h}`);
  }
}
await browser.close();

On one of my pages it prints:

https://toggle9.com/compound-interest-calculator/  (GPC off)
   20  toggle9.com
    2  www.google-analytics.com
    1  www.googletagmanager.com

https://toggle9.com/compound-interest-calculator/  (GPC on)
   19  toggle9.com

Try it on a site you use every day. The list is often longer than you'd guess.

The full results for every tool, with each one's own line about what it sends, are on What "runs in your browser" means.

Have you ever run something like this on your own site? I'd like to know what turned up, especially anything you didn't expect to find.

Your AI agent will credit famous quotes to the wrong person. Here's a LangChain tool that checks them

Jeremiah Say — Thu, 22 Oct 2026 07:52:53 +0000

Paste this into almost any article about leadership and nobody blinks:

"Be the change you wish to see in the world." — Mahatma Gandhi

There's no reliable source that Gandhi said it. The line isn't in his Collected Works; it's a modern condensation of his ideas. "Insanity is doing the same thing over and over again and expecting different results" has no Einstein source either; the earliest known printing is a 1981 Narcotics Anonymous text.

A language model answering from memory has a specific problem here. It has seen the popular credit far more often than the correction. I tested this on 22 October 2026: I gave Claude Sonnet (through the Claude Code CLI, with no tools) five well-known lines and asked "Who said each of these? Answer with the name only." It answered:

1. Ralph Waldo Emerson   ("Do not follow where the path may lead…")
2. Mahatma Gandhi        ("Be the change you wish to see in the world.")
3. Albert Einstein       ("Insanity is doing the same thing over and over…")
4. Seneca                ("Every new beginning comes from some other beginning's end.")
5. Peter Drucker         ("The best way to predict the future is to create it.")

That's the popular credit for all five, and none of them holds up. To its credit, the model then added a note saying several were "commonly misattributed". But the note didn't name the real author of #1 (Muriel Strode) or #4 (Dan Wilson, who wrote it for Semisonic's "Closing Time"), and it called #4 a "Seneca-like paraphrase", which is wrong. The model could tell that something was off. In this run it couldn't say what was right, or show a source.

Now picture that inside an agent that writes captions or summarises articles, where only the name ends up in the output. That's where you want a lookup, not a memory.

I run GraciousQuotes, where every quote has a fact-checked record: a verdict, the reason for it, the source it was traced to, and a public correction log when we get one wrong. So I wrapped those records as LangChain tools, so the agent can look the quote up instead of remembering it. The package was listed in LangChain's integrations directory on 20 October 2026.

This post covers what the tools return, how to use them in an agent and in CI, and three design decisions that took longer than the code.

Install (no key, no sign-up)

pip install langchain-graciousquotes

from langchain_graciousquotes import QuoteAttributionCheck

check = QuoteAttributionCheck()
print(check.invoke({"quote": "Be the change you wish to see in the world"}))

Output, from the live API on 22 October 2026:

Match: exact wording
Verdict: Uncertain. It is often credited to Mahatma Gandhi, but there is no reliable source that Mahatma Gandhi said it.
Status: Disputed
Quote as checked: "Be the change you wish to see in the world."
Credit it as: Often attributed to Mahatma Gandhi
Why: Not in Gandhi's Collected Works; a modern condensation of his ideas.
Traced to: https://en.wikiquote.org/wiki/Mahatma_Gandhi#Misattributed
Record: https://graciousquotes.com/quotes-with-sources/mahatma-gandhi/#q3684
Source: Gracious Quotes (graciousquotes.com). Link the record above when you repeat this.

The answer comes from a reviewed record, so if a verdict changes, the output changes with it.

The three tools

Tool	Name the model sees	What it does
`QuoteAttributionCheck`	`check_quote_attribution`	Verdict for one quote: said by the credited person, uncertain, or credited to the wrong person. Includes the reason, the source and the record link.
`QuoteSearch`	`search_checked_quotes`	Checked quotes by wording, author or verdict (verified, plausible, disputed, misattributed).
`QuoteCitation`	`cite_quote`	MLA 9, APA 7 or Chicago 17 citation for a checked quote, with a warning when it's usually credited to someone else.

In an agent:

from langchain.agents import create_agent
from langchain_graciousquotes import QuoteAttributionCheck, QuoteCitation, QuoteSearch

agent = create_agent(
    "anthropic:claude-sonnet-5-5",  # any tool-calling model
    tools=[QuoteAttributionCheck(), QuoteSearch(), QuoteCitation()],
)
agent.invoke({"messages": [{"role": "user",
    "content": "Did Einstein say the definition of insanity is doing the same thing over and over?"}]})

This needs LangChain 1.0+ and Python 3.10+. The tools work on their own from Python 3.9. Every tool also supports ainvoke.

Check every quote in a draft, with no model at all

You don't need an agent to use these. The more useful thing for me turned out to be a plain script: examples/check_draft.py finds the quotes in a Markdown file or a live URL, reads the name the article gives each one ("Emerson told us", "— Seneca"), and checks both.

Here's the run on the repo's sample draft, 22 October 2026 (trimmed):

4 to fix · 1 unverified · 2 OK

FIX        "Do not follow where the path may lead. Go instead where there is no path and leave a trail."
           Your draft credits: Ralph Waldo Emerson
           Record: Re-credited. No: Ralph Waldo Emerson did not say it. It comes from Muriel Strode.
           Fix: Credit Muriel Strode instead of Ralph Waldo Emerson.

FIX        "The only thing we have to fear is fear itself."
           Your draft credits: Mark Twain
           Record: Verified. Yes: President Franklin D. Roosevelt said it.
           Fix: Credit President Franklin D. Roosevelt instead of Mark Twain. Source: First Inaugural Address (1933).

FIX        "The best way to predict the future is to create it."
           Your draft credits: Peter Drucker
           Fix: No reliable source shows Peter Drucker said it. Write "often attributed to Peter Drucker", or cut it.

UNVERIFIED "The quiet hours before dawn belong to people who keep their own promises."
           Fix: No checked record. Keep the quote only if you can cite where it first appeared.

OK         "insanity is doing the same thing over and over again and expecting different results."
           Your draft credits: Albert Einstein (hedged)
           Note: Fine as written: you already present it as an attribution, which matches the record.

The Emerson line is a good example of why this is worth automating: it is widely credited to Emerson, but it comes from Muriel Strode's poem "Wind-Wafted Wild Flowers", printed in The Open Court in August 1903.

The script exits with code 1 when something needs fixing (--strict also fails on CHECK and UNVERIFIED), so it can block a publish step:

python examples/check_draft.py content/posts/new-post.md || exit 1

Note the last OK. The draft says "often attributed to Einstein", which matches the record, so it passes. A checker that flags every hedged attribution gets switched off within a week.

Three design decisions

1. "No record" is not a verdict

The easy failure is a tool that returns nothing, after which the model fills the gap from memory and sounds just as confident. When there's no checked record, the tool says so explicitly and tells the model not to present a remembered author as confirmed. You can see it in the UNVERIFIED line above. It's the same reason a missing value in a spreadsheet shouldn't be read as zero.

2. The tool description is the model's prompt, so be honest about the limits

The author filter in search_checked_quotes matches the person who really said the quote. That means "show me quotes wrongly credited to Mark Twain" can't be answered by searching for author="Mark Twain"; those records are filed under the real author. I found this while testing, and the tool description now says it directly:

The author filter matches the person who really said it, so it cannot list quotes wrongly credited to someone; use check_quote_attribution for a specific quote instead.

If you only document a limit in the README, the model never reads it. Put it in the description.

3. Every result carries its own credit line

Each result ends with Source: Gracious Quotes … Link the record above when you repeat this. That's a terms of use condition, and it also works in the user's favour: a quote verdict without a link to its evidence is just another claim. With the record link, the reader can check the source themselves.

Testing against LangChain's own conformance suite

The package passes langchain-tests (ToolsUnitTests and ToolsIntegrationTests, sync and async) along with its own behaviour tests. Two things worth knowing if you build a tool package:

Set asyncio_mode = "auto" in your pytest config. Without it, pytest skips the async cases and the run still looks like a pass.
CI runs with no API key on purpose. The API is keyless, so a green build shows that the advertised zero-setup path works for a stranger, not just on my machine. A scheduled run also catches the live API drifting.

A separate CI job builds the create_agent example on Python 3.13 so the guide's code can't quietly break.

Getting listed: file through the web form

LangChain doesn't accept integration PRs. You file an "Integration listing" issue on langchain-ai/docs, a maintainer applies a label, and a bot opens the docs PR. One trap from my first listing (a sister project): an issue created with gh issue create never triggers the automation. It doesn't get the template's labels, so the bot never sees it. Filed again through the web form, it went through in days. For this package: issue filed 9 October, approved and merged on 20 October.

Limits, stated plainly

Coverage is what we've checked. Anything outside the records comes back UNVERIFIED rather than guessed.
Name detection in check_draft.py is a heuristic. When it isn't sure who a draft credits, it reports CHECK, not a firm verdict.
Verdicts can change. When new evidence turns up we update the record and log it on the public corrections page. The full method is on How we source quotes.
Rate limit: 40 requests per 10 seconds per IP. A tool that hits it says so in its result instead of raising.
Bulk copying or training on the records needs a licence. Fetching records because a user asked is fine, with the credit.

Links

Guide and API reference: graciousquotes.com/developers/langchain/
Source (MIT): github.com/graciousquotes/langchain-graciousquotes
PyPI: langchain-graciousquotes
OpenAPI 3.1: graciousquotes.com/developers/openapi.json
Cite it: Say, J. (2026). langchain-graciousquotes [Computer software]. Zenodo. doi.org/10.5281/zenodo.23258870

If you paste in a quote and think our verdict is wrong, open an issue with your source. Corrections with a primary source are the most useful thing anyone can send us.

I'm Jeremiah Say, founder and editor of GraciousQuotes. I research quote attributions against original books, speeches and letters, and I maintain this package. I wrote earlier about how the site matches misremembered quotes.

4.2 / 0.6 = 7.000000000000001: testing calculator formulas against hand-worked examples

Jeremiah Say — Fri, 16 Oct 2026 01:55:05 +0000

A bag of QUIKRETE concrete mix that weighs 80 lb yields 0.60 cubic feet. If your job needs 4.2 cubic feet, you need exactly 7 bags.

Math.ceil(4.2 / 0.6)   // 8
4.2 / 0.6              // 7.000000000000001

JavaScript says 8. That's one wasted bag and an annoyed customer, from a bug that no amount of looking at the code will show you. Between 1 and 200 bags' worth of volume, the naive Math.ceil(volume / perBag) gets 10 of the 200 exact multiples wrong.

I build Toggle9, a set of free calculators that show their working, and bugs like this are the reason every tool goes through the same testing routine. Here it is.

1. Start from the source, not the code

Every number a tool uses comes from a primary source: a standard (NIST defines 1 foot as exactly 0.3048 m), a government table, or a manufacturer's data sheet. For concrete, the bag yields come straight from the QUIKRETE technical data sheet, and the code says so:

// QUIKRETE Concrete Mix (No. 1101) technical data sheet: yield per bag in ft³.
export const BAGS = [
  { lb: 40, ft3: 0.30 },
  { lb: 50, ft3: 0.375 },
  { lb: 60, ft3: 0.45 },
  { lb: 80, ft3: 0.60 },
  { lb: 90, ft3: 0.675 },
];

2. Work the examples by hand, before writing code

Before any code exists, I work a few examples by hand from the source, including the awkward ones: tiny jobs, huge jobs, mixed units, and exact multiples, which is where the 4.2 ÷ 0.6 bug lives.

A worked example for a patio slab, 12 ft × 10 ft × 4 in:

volume = 12 × 10 × (4/12) = 40 ft³
plus 10% for waste = 44 ft³ = 44 / 27 = 1.63 yd³
80 lb bags: 44 / 0.60 = 73.3 → 74 bags
60 lb bags: 44 / 0.45 = 97.8 → 98 bags
ready-mix is sold in quarter yards: 1.63 → 1.75 yd³

Those numbers are worked out by hand, not taken from the code's output. That matters: a test that copies whatever the code printed only proves the code is consistent with itself.

3. Keep the maths in its own file

Each tool's calculation lives in a compute.js that only does maths: no DOM, no formatting, no event handlers. The UI imports it. That rule means a layout change can never change an answer, and the maths can be tested in Node with nothing mocked.

// tools/concrete/compute.js (excerpt)
const n = Math.ceil(ft3 / b.ft3 - 1e-9);

The - 1e-9 is the fix for the opening bug: subtract a tolerance far smaller than any real measurement before rounding up, so floating-point noise above an exact multiple doesn't cost an extra bag.

4. Hand-worked examples become tests

Tests use Node's built-in node:test and assert, with no framework. Values are kept in SI units inside the engine, so tests convert at the edges:

import { test } from 'node:test';
import assert from 'node:assert/strict';
import { partVolume, totals, FT3 } from '../tools/concrete/compute.js';

const FT = 0.3048, IN = 0.0254;
const close = (a, b, eps = 1e-6) => assert.ok(Math.abs(a - b) < eps, `${a} != ${b}`);

test('slab 12 ft x 10 ft x 4 in = 40 ft³', () => {
  close(partVolume('slab', { l: 12 * FT, w: 10 * FT, t: 4 * IN }) / FT3, 40);
});

test('totals with 10% waste: 44 ft³, 1.63 yd³, 74 x 80 lb bags, 98 x 60 lb', () => {
  const t = totals(40 * FT3, 10, 0.25, 'us');
  close(t.ft3, 44); close(t.yd3, 44 / 27);
  assert.equal(t.bags.find(b => b.lb === 80).n, 74);
  assert.equal(t.bags.find(b => b.lb === 60).n, 98);
  close(t.order, 1.75); // 1.63 yd³ rounds up to 1.75 in quarter-yard steps
});

test('exact bag multiples do not round up an extra bag', () => {
  const t = totals(6 * FT3, 0, 0, 'us'); // 6 ft³ = exactly 10 x 80 lb
  assert.equal(t.bags.find(b => b.lb === 80).n, 10);
});

The test names are the worked examples, so a failure reads like a sentence: "steps: 3 steps, 7 in rise, 11 in run, 4 ft wide = 12.83 ft³".

Today the engine has 202 of these across 30 test files, and npm test runs them in about half a second. A tool can't go live unless every one passes, and they all run again before every release.

5. Then check it in real browsers

Unit tests prove the maths. They don't prove that typing 12' 6" into the real input on a phone produces the right number on screen. For that there's a scripted pass (npm run check) that loads every tool in real Chrome and WebKit, at phone and desktop widths, and runs each tool through a scenario:

await typeInto(page, root + ' .t9-part .t9-fields .t9-input', `12' 6"`);
out.push(`length 12' 6": → ${await txt(page, root + ' .t9-fig')}`);
await typeInto(page, root + ' .t9-part .t9-fields .t9-input', `abc`);
out.push(`bad input error: "${await txt(page, root + ' .t9-part .t9-fields .t9-err')}"`);

It also reports console errors and horizontal overflow (a page that's wider than the phone), and a separate pass runs an automated accessibility check with axe-core. WebKit is there because iPhone Safari is where the surprises are.

6. Publish the receipts, and re-check

Each tool page shows "Show the math" with the formula, the sources it uses with links, and the date they were last checked. Sources are re-checked every 12 months, because data sheets and government tables change, and corrections are logged publicly.

The full process, with a real example worked from start to finish, is on How I check every tool. The concrete example above is the concrete calculator, so you can check my 74 bags yourself.

What's the nastiest floating-point rounding bug you've run into? This one would have cost someone a bag of concrete.

Parsing 12' 6" and 2.4 m: measurement input that doesn't annoy people

Jeremiah Say — Fri, 16 Oct 2026 01:55:04 +0000

Most online calculators give you a number box and a unit dropdown. Then someone measures their patio with a tape, gets 12 feet 6 inches, and has to work out that that's 12.5 before they can type anything.

I build Toggle9, a set of free calculators, and I wanted the input box to accept what people actually write down. This post walks through the parser behind it: under 200 lines of plain JavaScript, no dependencies.

What it has to accept

These are real inputs and the values the parser returns (field default unit in brackets):

Typed	Result
`12' 6"`	12.5 ft
`12'-6 1/2"`	12.5417 ft
`12 1/2` or `12½`	12.5 ft
`2.4 m` (in a feet field)	7.874 ft
`2,5` (in a metres field)	2.5 m — decimal comma
`1,250`	1250 — thousands separator
`12' + 3' 6"`	15.5 ft
`(12 + 4) * 2`	32 ft
`12' x 10'` (area field)	120 sq ft
`150 sq ft` (square metres field)	150 sq ft, stored as m²

And it has to refuse some things, with a message a person can act on:

Typed	Message
`12 sq ft` in a length field	That looks like an area; this field needs a length.
`12 apples`	I couldn't read "apples". Try 12.5, 12 1/2 or 12' 6".

Step 1: normalise the mess

Before parsing anything, fold the many ways of writing the same thing into one:

const VULGAR = { '½': '1/2', '¼': '1/4', '¾': '3/4', /* … */ };

export function normalise(raw) {
  let s = String(raw ?? '').trim();
  for (const [k, v] of Object.entries(VULGAR))
    s = s.replace(new RegExp('(\\d)?' + k, 'g'), (m, d) => (d ? d + ' ' : '') + v); // 12½ -> 12 1/2
  s = s.replace(/[×xX](?=\s*[\d(.])/g, '*').replace(/÷/g, '/').replace(/[−–—]/g, '-');
  s = s.replace(/(\d),(\d{3})(?!\d)/g, '$1$2');   // 1,250 -> 1250
  s = s.replace(/(\d),(\d)/g, '$1.$2');            // 2,5 -> 2.5
  s = s.replace(/(\d)-(\d+\/\d+)/g, '$1 $2');      // 3-1/2 -> 3 1/2
  s = s.replace(/(['’′]|\bft|\bfeet|\bfoot)\s*-\s*(?=\d)/gi, '$1 '); // 12'-6" -> 12' 6"
  return s;
}

Two details matter here:

x only becomes multiply when a number follows it, so 12 x 10 is a product but the x inside a unit word is left alone.
The comma rule runs in a fixed order. 1,250 (comma before exactly three digits) is a thousands separator; any other digit,digit is a decimal comma. That reads 2,5 correctly for the many people who write decimals that way, and it's predictable.

Step 2: lex numbers, fractions and units

The lexer produces three kinds of token: numbers, operators and units. Fractions are folded into the number while lexing, because 1/2 next to a number is part of the number, not a division:

const num = /^(\d+(\.\d+)?|\.\d+)/.exec(s.slice(i));
if (num) {
  let v = parseFloat(num[0]); i += num[0].length;
  const frac = /^\/(\d+(\.\d+)?)/.exec(s.slice(i));        // tight a/b is a fraction
  if (frac) { v = v / parseFloat(frac[1]); i += frac[0].length; }
  else {
    const mixed = /^\s+(\d+)\/(\d+)/.exec(s.slice(i));     // 3 1/2
    if (mixed && Number.isInteger(v)) { v += parseInt(mixed[1]) / parseInt(mixed[2]); i += mixed[0].length; }
  }
  t.push({ k: 'num', v });
}

So 48 in / 2 (spaces around the slash) is division, while 1/2 is a fraction.

Units are matched longest-first so sq ft wins over ft, and volume and area words are tried before length words. Each unit token carries its dimension: the power of length (1 = length, 2 = area, 3 = volume). Quote marks (', ", ′, ″, and their curly versions) count as feet and inches, which matters on phones that autocorrect ' into ’.

Step 3: evaluate with dimensions

The evaluator is a small recursive-descent parser (sum → product → quantity) where every value is { v, dim }, always in SI base units (metres, m², m³). Multiplying adds dimensions, dividing subtracts them:

if (op === '*') a = { v: a.v * b.v, dim: a.dim + b.dim };
else            a = { v: a.v / b.v, dim: a.dim - b.dim };

That is how 12' x 10' becomes an area: length × length = dimension 2, so the area field accepts it and a length field rejects it.

Two rules make it feel natural rather than strict:

Adjacent pieces add up. 5' 10" is two quantities side by side with no operator, and people mean "plus". Inside quantity(), while the next token is a number and we're holding a length, keep adding. If the previous unit was feet and the next number has no unit, assume inches:

while (peek()?.k === 'num' && q.dim === 1) {
  const n = take(); let add;
  if (peek()?.k === 'unit' && peek().dim === 1) { const u = take(); add = n.v * LENGTH[u.u]; }
  else if (q.units.at(-1) === 'ft') add = n.v * LENGTH.in;   // 5' 10 -> 5' 10"
  else throw new Error('Add a unit to the second number, e.g. 5 ft 10 in.');
  q = { ...q, v: q.v + add };
}

Bare numbers borrow the field's unit, but only when they need to. In 12' + 4, the 4 has no unit. Adding a length to a plain number would be a dimension error, so plain numbers in a sum are "lifted" to the field's default unit first. In (12 + 4) * 2 nothing has a unit, so the whole thing is evaluated as a plain number and lifted once at the end: 32 ft.

Step 4: errors a person can fix

Every failure returns { ok: false, error } with a sentence the UI shows under the box. Three kinds of error cover nearly everything:

Can't read it: "I couldn't read "apples". Try 12.5, 12 1/2 or 12' 6"." The examples matter more than the error itself.
Wrong kind of quantity: "That looks like an area; this field needs a length." This catches 12 sq ft typed into a length box, which a plain parseFloat would happily turn into 12.
Out of range: "Use a value of 10 or less." Range checks run on the value in the field's unit, not in metres, so the numbers in the message match what the person sees.

Testing it

The parser has its own test file (Node's built-in node:test, no framework), with cases taken from what people actually type: 12' 6 1/2", 12 x 10 into an area field, 2 cu yd into a cubic-feet field. Any input that turns out to be read wrongly gets added as a test case first, then fixed.

Where it's used

The same parser sits behind every measurement box on Toggle9, for example the concrete calculator (slabs, footings and post holes) and the square footage calculator. Try typing 12' 6" x 10' into an area field.

If you've built something similar, I'd like to hear how you handled the ambiguous cases. 5 10 is my current favourite: is that 5 feet 10, or a typo?

Is senior cat food lower in calories? I paired 18 senior foods with their adult twins to check

Jeremiah Say — Fri, 16 Oct 2026 01:55:02 +0000

Most people assume a "senior" cat food is the lighter version of the adult food. I wanted to check that on real labels, so I needed pairs: each senior food next to the adult food it was made from. Same brand, same form, same recipe, with only the life stage changed.

Product catalogues don't record that link anywhere. All you have is the names, and those names are messy:

Science Diet Adult 7+ Senior Vitality Chicken Recipe Cat Food
Science Diet Adult Chicken Recipe Cat Food
Fancy Feast Senior 7+ Paté Chicken Feast Cat Food
Fancy Feast Classic Paté Chicken Feast Gourmet Wet Cat Food

Below is the matcher I wrote, the trap that made the filters necessary, and what the pairs show.

The data

I run PerBowl, which reads US dog and cat food labels (calories, guaranteed analysis, barcodes) and checks them against FDA recall records. On 16 Oct 2026 the site had 39 complete cat foods whose names say senior, mature, aging, 7+ or 11+: 16 dry and 23 wet. Vet diets and kitten foods are left out.

A food counts as "senior" when its name matches this regex:

SENIOR = re.compile(r"senior|mature|aging|vitality|\b7\s?\+|\b11\s?\+|\b1[0-5]\s?\+", re.I)

Every other complete cat food from the same brands can be the adult twin.

Hard rules first, fuzzy matching second

My first attempt was plain fuzzy matching: tokenise both names and take the adult food with the best Jaccard similarity. It found plenty of matches, and too many were wrong. A senior indoor recipe paired with a regular adult recipe, because the long shared tail ("Chicken & Rice Formula Dry Cat Food") outweighed the one word that matters.

So the matcher now runs in two stages:

Hard filters, where any mismatch rules the candidate out: brand, form (dry or wet), the main protein, and the set of "special formula" words. Those are words like indoor, hairball, urinary, sensitive, and texture words like paté or gravy. If one name has a special word the other doesn't, they aren't the same recipe.
Jaccard on what's left, after removing the senior words and the filler every name shares ("cat", "food", "formula", brand-line words like "science diet" or "pro plan"). The best candidate wins if it scores at least 0.6.

import re

SENIOR = re.compile(r"senior|mature|aging|vitality|\b7\s?\+|\b11\s?\+|\b1[0-5]\s?\+", re.I)
STOP = set("cat cats food dry wet formula recipe adult and with for the in canned entree entrée "
           "complete essentials plan pro purina one science diet hill s senior mature aging "
           "vitality natural healthy premium gourmet".split()) | {""}
PROTEINS = ["chicken", "beef", "lamb", "salmon", "turkey", "tuna", "fish", "duck", "whitefish", "ocean"]
SPECIAL = re.compile(r"\b(indoor|weight|light|hairball|urinary|sensitive|digestion|perfect|grain free|"
                     r"liveclear|savory|healthy cuisine|tender|p[aâ]t[eé]|loaf|gravy|minced|stew|naturals)\b", re.I)

def tokens(name):
    name = SENIOR.sub(" ", name).replace("&", " ").lower()
    return set(re.split(r"[^a-z0-9]+", name)) - STOP

def proteins(name):
    words = re.split(r"[^a-z]+", name.lower())
    return [p for p in PROTEINS if p in words]

def specials(name):
    return set(m.lower() for m in SPECIAL.findall(name))

def twin(senior, adults, threshold=0.6):
    best, best_j = None, 0.0
    for a in adults:
        # Hard rules first: same brand, same form, same main protein, same special formulas.
        if (a["brand"], a["form"]) != (senior["brand"], senior["form"]):
            continue
        if proteins(a["name"]) != proteins(senior["name"]):
            continue
        if specials(a["name"]) != specials(senior["name"]):
            continue
        # Then the soft rule: most of the remaining words shared (Jaccard).
        ts, ta = tokens(senior["name"]), tokens(a["name"])
        j = len(ts & ta) / len(ts | ta) if ts | ta else 0
        if j > best_j:
            best, best_j = a, j
    return (best, round(best_j, 2)) if best_j >= threshold else (None, round(best_j, 2))

A few details that matter:

The senior regex runs before tokenising. Otherwise "7+" and "Senior Vitality" count as differences, and good pairs drop below the threshold.
The protein check compares lists, not sets. "Chicken & Salmon" and "Salmon" are different recipes.
An adult food can be the twin of more than one senior food. Hill's sells a 7+, an 11+ and a 7+ Senior Vitality version of the same adult chicken recipe. All three pair with it, which is correct.

Here's the trap from the start of this section, on a made-up name:

>>> s = {"brand": "Purina", "form": "dry", "name": "Pro Plan Adult 7+ Indoor Chicken & Rice Formula Dry Cat Food"}
>>> a = {"brand": "Purina", "form": "dry", "name": "Pro Plan Adult Complete Essentials Chicken & Rice Formula Dry Cat Food"}
# Jaccard alone: {indoor, chicken, rice} vs {chicken, rice} = 0.67, so it passes
# With the special-word filter: "indoor" only on one side, so no twin

Without the filter, a high Jaccard score just means the names share a lot of words. It doesn't mean the recipes are the same.

What the 18 pairs show

Across the 39 senior foods, the matcher found 18 pairs. I compare calories per cup for dry food and per kg for wet. Cans and cups come in different sizes, so those are the only like-for-like units.

Senior version vs its adult twin	Pairs
Fewer calories	9
More calories	8
Exactly the same	1

So it's a coin toss. A few examples:

Senior food	Adult → senior
Pro Plan LiveClear Adult 7+ Prime Plus Chicken & Rice (dry)	494 → 604 kcal/cup (+110)
Pro Plan Adult 7+ Complete Essentials Chicken & Rice (dry)	494 → 545 kcal/cup (+51)
Science Diet Adult 7+ Chicken Recipe (dry)	483 → 393 kcal/cup (−90)
Science Diet Adult 11+ Indoor Chicken Recipe (dry)	327 → 396 kcal/cup (+69)
Science Diet Adult 7+ Tender Tuna Dinner (wet)	1,040 → 903 kcal/kg (−137)
ORIJEN Guardian Senior (dry)	498 → 460 kcal/cup (−38)

All three Purina Pro Plan 7+ dry foods in the set have more calories than their adult versions. Hill's goes both ways: within the same brand, the 7+ chicken recipe is lighter than the adult one and the 11+ indoor recipe is denser.

The medians tell the same story. The middle senior dry cat food has 425 kcal per cup and the middle adult dry food has 420. Senior dry foods range from 324 to 621 kcal per cup.

None of this means the makers are wrong. Older cats aren't one group. Many cats aged roughly 7 to 12 are overweight and do better on fewer calories. Many cats over 12 are thin, and a 2005 review (by a Nestlé Purina researcher, so not independent) found that about a third of them digest fat less well. An independent 2013 study also measured lower digestibility in older cats. A denser senior food can be a deliberate choice for that second group. But "senior" on the bag doesn't tell you which group a food was made for, and AAFCO has no senior nutrient profile. So you have to read the calories.

A second trap: two kinds of protein number

Adding protein and fat columns raised a different problem. Most US labels give only the guaranteed analysis, which is a legal minimum. Hill's also publishes average analyses, and for some Hill's foods the average is the only figure in my data.

A minimum is a floor and an average is a typical value. Put one next to the other and a recipe can look several points richer in protein when nothing about it has changed.

So the rule is in code. A pair uses Hill's averages only when both foods have them, and the table marks those rows "avg". Otherwise both sides use the guaranteed minimums. Both kinds of number are converted to dry matter (water removed), because a wet food at 78% moisture and a dry food at 10% can't be compared as printed.

Even like for like, a few pairs move a lot. Science Diet Adult 7+ Savory Beef Entrée goes from 31% to 40% protein, comparing Hill's averages on both sides. So the rule doesn't hide real differences. It stops you from making fake ones.

Takeaways

Run hard filters before you fuzzy-match. Similarity scores reward shared boilerplate. The words that define a variant are often the words a token score treats as noise.
Normalise the thing you're testing before tokenising. I strip the senior markers because they're the one difference every pair is supposed to have.
Check what kind of number each field holds. A minimum and an average can share a column name and still not be comparable.

The full table, with all 18 pairs and all 39 senior foods sortable from lightest to densest, is on PerBowl's cat food for senior cats page. The usual caveat applies too: if an older cat is losing weight, drinking more or eating differently, see a vet before changing food. A new label won't fix those.

FDA now classifies pet food recalls 4.7x faster than before 2020. Here's the 40-line check, and the trap in it

Jeremiah Say — Fri, 09 Oct 2026 11:00:33 +0000

When a pet food company starts a recall, the record most tools are built on isn't out yet. FDA's classified recall record (the one with the Class I/II/III rating, the exact lot codes and the barcodes) only appears once FDA has reviewed the recall and classified it.

So how long does that take? I counted, for every dog and cat food recall FDA has classified since its Enforcement Reports went online in 2012:

FDA classified it	Recalls	Median days from start to classification	Classified within 30 days
2012–2019	158	140	3%
2020 onward	108	30	51%

That's about 4.7 times faster. Below is the script that produces every number in this post, plus the check I ran before believing it. A drop like this is exactly what a common data bug looks like.

The data

I run PerBowl, which traces US dog and cat foods back to the companies and plants that make them. FDA publishes recalls through its Enforcement Report search, but there's no bulk download filtered to pet food. So I built one and released it as an open dataset under CC BY 4.0:

Of the 3,660 veterinary-category product rows in FDA's Enforcement Reports, I kept 1,232 dog and cat food products. The other 2,428 were animal drugs and devices, livestock feed, food for other animals, and similar. Every dropped row is in excluded.csv with the reason it was dropped, so the filter can be audited.
Those 1,232 products group into 266 recall events, one row each in recalls.csv.
Each event has initiated_date (the firm started the recall) and classified_date (FDA classified it). Both are the earliest date across the event's products.

It's on GitHub, Zenodo and Kaggle. Every release is tagged, so the script below pins the version these numbers came from.

The script

Standard library only. Copy it and run it with python3:

import csv, io, statistics, urllib.request
from datetime import date

VERSION = "v2026-10-09"  # pinned so the numbers reproduce; "main" = latest release
URL = f"https://raw.githubusercontent.com/perbowl/pet-food-recalls/{VERSION}/recalls.csv"
rows = list(csv.DictReader(io.TextIOWrapper(urllib.request.urlopen(URL), encoding="utf-8")))

def days(a, b):
    return (date.fromisoformat(b) - date.fromisoformat(a)).days

def median(v):
    return round(statistics.median(v))

recalls = []
for r in rows:
    if r["initiated_date"] and r["classified_date"]:
        r["lag"] = days(r["initiated_date"], r["classified_date"])
        recalls.append(r)

before = [r["lag"] for r in recalls if r["classified_date"] < "2020-01-01"]
since = [r["lag"] for r in recalls if r["classified_date"] >= "2020-01-01"]
share = lambda v, d: round(100 * sum(x <= d for x in v) / len(v))

print(f"recalls with both dates: {len(recalls)} of {len(rows)}")
print(f"classified 2012-2019: n={len(before)} median={median(before)} days, <=30d {share(before, 30)}%")
print(f"classified 2020 on:   n={len(since)} median={median(since)} days, <=30d {share(since, 30)}%, <=60d {share(since, 60)}%")
print(f"ratio: {median(before) / median(since):.1f}x")

for c in ("Class I", "Class II", "Class III"):
    b = [r["lag"] for r in recalls if r["fda_class"] == c and r["classified_date"] < "2020-01-01"]
    s = [r["lag"] for r in recalls if r["fda_class"] == c and r["classified_date"] >= "2020-01-01"]
    print(f"{c:9}  before {median(b)} (n={len(b)})   since {median(s)} (n={len(s)})")

years = {}
for r in recalls:
    years.setdefault(r["classified_date"][:4], []).append(r["lag"])
for y in sorted(years):
    print(f"{y}  {len(years[y]):3}  {median(years[y]):4}")

# The censoring check (see below): group by the year the FIRM STARTED the recall.
settled = [r["lag"] for r in recalls if "2020-01-01" <= r["initiated_date"] < "2024-01-01"]
print(f"started 2020-2023: n={len(settled)} median={median(settled)} days")
early = [r["lag"] for r in recalls if "2012-01-01" <= r["initiated_date"] < "2016-01-01"]
print(f"started 2012-2015: n={len(early)} median={median(early)} days")

All 266 recalls have both dates, so nothing gets dropped. Since 2020, 86% were classified within 60 days.

It holds for every class

The obvious objection is that the mix of recalls changed. Fewer serious recalls would mean less review work and a faster median. But the drop shows up within each class:

	2012–2019	2020 onward
Class I (reasonable chance of serious harm)	154 days (n=116)	32 days (n=84)
Class II	118 days (n=28)	22 days (n=20)
Class III	64 days (n=14)	29 days (n=4)

Before 2020, the most serious recalls waited the longest. Class III has too few rows since 2020 to mean much on its own.

The trap: you can't see the slow ones yet

This is the part worth taking away, even if you never touch pet food data.

The dataset only contains recalls FDA has already classified. A recall that started in spring 2026 and is still waiting isn't in it at all. Recent years are therefore missing their slowest cases, and the median for "2020 onward" gets pulled down by recalls that simply haven't finished yet. It's right-censoring, and it can make any process look as if it's speeding up.

The fix is to choose a group of recalls that have all had time to finish. Group them by the year the firm started the recall, not the year FDA classified it, and keep only starts from 2020 to 2023. Every one of those has had nearly three years or more to get classified, so if slow ones were still pending, they would be missing from this group and would show up later as very long lags.

started 2020-2023: n=56 median=28 days

28 days, which matches the 30-day median for all recalls since 2020. So the drop isn't caused by unfinished recalls. For comparison, recalls started in 2012–2015 had a median of 158 days.

The year-by-year view is messier

Year classified	Recalls	Median days
2012	11	74
2013	28	138
2014	10	106
2015	10	358
2016	41	232
2017	12	101
2018	25	73
2019	21	135
2020	19	29
2021	18	26
2022	10	42
2023	13	28
2024	11	35
2025	15	37
2026	22	28

Before 2020 the medians jump around, and some years have only 10 recalls. From 2020 on, every year sits between 26 and 42. So it wasn't a gradual improvement. The numbers changed sharply around 2020 and have stayed low since.

Why? The data can't say. In December 2017, an HHS Inspector General audit (A-01-16-01502) found that FDA "could not always ensure that firms initiated recalls promptly." The same month, FDA's commissioner announced a new senior team for difficult recalls. That fits the timing loosely: 2018 was quicker, but 2019 was slow again. I've put the details and sources in the full write-up. I'd treat the cause as an open question.

Why it matters if you build on recall data

A median of 30 days is still a month. Any alert, feed or "is my product recalled?" lookup built only on classified records shows a recall weeks after it started. The company's own announcement usually comes much earlier. My last post covers getting those same-day announcements from one FDA JSON file, and why 21 of the 48 recalls FDA classified from 2024 onward never appeared as announcements at all. You need both sources.

Caveats

The dates are the earliest across a recall's products. A recall that FDA classifies in stages counts from its first classification.
"Dog and cat food" comes from a keyword filter on FDA's product descriptions. It's tuned by hand, and excluded.csv exists so you can check every decision it made.
These are US FDA recalls only. Recalls in other countries aren't included.

Get the data

Dataset page: perbowl.com/recalls/dataset. It covers files, columns and how the dataset is built.
Cite this version: PerBowl (2026), US Dog and Cat Food Recalls (FDA, 2012 onward), version 2026-10-09, doi:10.5281/zenodo.23255874. The concept DOI 10.5281/zenodo.23255873 always points to the latest release.
It's updated monthly. If you find a recall that's misclassified or missing, open an issue on GitHub. Corrections go into the next release.