DEV Community: Jeremiah Say

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.

Who said this quote? Matching misremembered quotes when people never type them right

Jeremiah Say — Thu, 08 Oct 2026 02:58:16 +0000

Nobody types a famous quote exactly. They type it the way they remember it:

insanity is doing the same thing over and over and expecting different results

The usual wording has an "again" in it. Some people add "the definition of". Some put the attribution on the end: "… - Albert Einstein". A search box that needs every word, or the exact phrase, misses most of these.

I run GraciousQuotes, where each quote carries a verdict (verified, disputed, misattributed and so on) with its source. The Who said this quote? checker takes whatever someone pastes and answers with the closest quote on the site and its verdict. For the line above, it answers:

Match	Credited to	Verdict	Quote
close (0.846)	Albert Einstein	disputed	Insanity is doing the same thing over and over again and expecting different results.

Here's how it gets there, in two stages: a cheap database search to find candidates, then a careful PHP scorer to rank them.

Why plain search wasn't enough

The site's existing search was word-AND: return quotes containing every word typed. For checking quotes that fails in both directions:

It misses. One extra word ("again", "the definition of") and the real quote is gone.
It matches the wrong thing. Common words appear everywhere, so a quote that happens to contain all the same words, in a different order and meaning something else, counts as a hit.

What we actually want to know is: is this the same sentence, give or take a few words? That's about word order, not just shared words.

Step 1: normalise both sides

Before comparing anything, the query and every quote go through the same normalisation: decode HTML entities, strip accents, lowercase, delete apostrophes ("don't" and "dont" are the same word), and turn everything else that isn't a letter or digit into a space.

function gq_qc_norm( $s ) {
  $s = html_entity_decode( wp_strip_all_tags( (string) $s ), ENT_QUOTES, 'UTF-8' );
  $s = remove_accents( $s );
  $s = strtolower( str_replace( array( "'", "\u{2019}", "\u{2018}" ), '', $s ) );
  $s = preg_replace( '/[^a-z0-9]+/', ' ', $s );
  return trim( preg_replace( '/\s+/', ' ', $s ) );
}

The query also loses a trailing credit ("… - Albert Einstein", "… —Mark Twain") and its wrapping quote marks, because people paste them along with the quote.

Step 2: candidates from MySQL FULLTEXT

Scoring every quote in PHP would be slow, so MySQL narrows it down first. Quotes live in a separate FULLTEXT table rebuilt nightly, and the checker asks it in natural-language mode, which ranks by relevance instead of requiring every word:

$rows = $wpdb->get_results( $wpdb->prepare(
  "SELECT quote_id, text, MATCH(text) AGAINST (%s IN NATURAL LANGUAGE MODE) sc
   FROM $t WHERE MATCH(text) AGAINST (%s IN NATURAL LANGUAGE MODE)
   ORDER BY sc DESC LIMIT 120", $qn, $qn ) );

120 candidates is generous. FULLTEXT is good at "these share unusual words" and bad at "these are the same sentence", so the real decision happens in the next step.

Step 3: score word order and coverage

For each candidate, three measures between 0 and 1:

Run: the longest stretch of consecutive words the query and the quote share, divided by the query's length. This is what captures "same sentence": word order matters.
Query coverage: how much of what they typed is in the quote.
Quote coverage: how much of the quote they typed.

The longest common run is the classic dynamic-programming longest-common-substring, over words instead of characters, keeping only the previous row:

function gq_qc_lcs_run( $a, $b ) {
  $best = 0;
  $prev = array_fill( 0, count( $b ) + 1, 0 );
  foreach ( $a as $i => $wa ) {
    $cur = array_fill( 0, count( $b ) + 1, 0 );
    foreach ( $b as $j => $wb ) {
      if ( $wa === $wb ) {
        $cur[ $j + 1 ] = $prev[ $j ] + 1;
        if ( $cur[ $j + 1 ] > $best ) $best = $cur[ $j + 1 ];
      }
    }
    $prev = $cur;
  }
  return $best;
}

Then a weighted score, with the run counting most:

$score = 0.5 * $run + 0.3 * $cov_q + 0.2 * min( 1, $cov_c * 1.5 );
$kind  = $score >= 0.7 && $run >= 0.6 ? 'close' : ( $score >= 0.55 ? 'possible' : 'none' );

Worked through for the insanity example (13 words typed; the quote has 14):

the longest shared run is "insanity is doing the same thing over and over": 9 of 13 words → run 0.692
all 13 typed words are in the quote → query coverage 1.0
13 of the quote's 14 words were typed → quote coverage 0.929, × 1.5 capped at 1 → 1.0
score = 0.5 × 0.692 + 0.3 × 1.0 + 0.2 × 1.0 = 0.846, and the run is above 0.6, so it's close

The × 1.5 on quote coverage means typing most of a long quote counts fully. People usually remember the famous half.

Before any of that, one shortcut: if the typed words appear in order inside the quote (or a quote of at least 4 words appears inside the query), it's an exact match with score 1.0. "Float like a butterfly sting like a bee" is exact against Muhammad Ali's full line, which continues "Rumble, young man, rumble."

Step 4: present answers, not search results

A checker should give one answer, not ten results, so the ranking ends with a few rules:

Ties go to the checked verdict. If two quotes score the same, a verified or misattributed record outranks an unreviewed one.
One card per wording. Quotes whose first 80 normalised characters match are the same quote, shown once.
Look-alikes are noise next to a real match. After an exact match, anything under 0.85 is dropped; after a close match, anything under 0.7.
Variants fold in. Other wordings with the same author and verdict are listed under the top answer instead of repeating it.

Learning from misses

When the checker finds nothing, the query is counted by week (normalised text, first 300 characters, outcome) with no IP address, cookie or account, and rows older than 12 months are deleted. Those misses are the to-do list: they show which quotes people ask about that the site doesn't have yet.

Try it

The checker is free at graciousquotes.com/who-said-this-quote. Paste a quote the way you remember it. The misquotes are the interesting ones.

Same-day pet food recall alerts from one FDA JSON file and a cron job

Jeremiah Say — Thu, 08 Oct 2026 02:58:12 +0000

If your dog's food is recalled, you want to know today, not next month.

I run PerBowl, a site that traces US dog and cat foods back to the companies and plants that make them, with every FDA recall since 2012. When I built recall alerts, I assumed the obvious source was the right one: FDA's classified recall records (the enforcement reports, the ones with a Class I/II/III and full product lists).

It's the wrong source for alerts. I matched 30 dog and cat food recall announcements since January 2024 against FDA's classified records, and the classified record arrived a median of 25 days later, once 91 days later. (The full table and CSV are here.) By then the bag is long empty.

The same-day source: one JSON file

The company announcement, the press release a firm publishes when it recalls a product, shows up on FDA's "Recalls, Market Withdrawals, & Safety Alerts" page the day it's posted. That page is backed by a single JSON file:

https://www.fda.gov/datatables-json/recalls-market-withdrawals.json

No API key, no pagination: about 1,080 rows today, covering every FDA-regulated product (food, drugs, devices, cosmetics, pet food). Each row looks roughly like this:

{
  "field_change_date_2": "08/28/2026",
  "field_company_name": "Northwest Naturals",
  "field_brand_name": "Northwest Naturals",
  "field_product_description": "Chicken Recipe …",
  "field_recall_reason": "Salmonella, Listeria",
  "field_regulated_product_field": "Animal & Veterinary, Pet Food",
  "path": "/safety/recalls-market-withdrawals-safety-alerts/…"
}

Some fields contain HTML, so everything goes through a strip-tags-and-decode step first.

Filtering to dog and cat food

"Pet Food" in the product-type field catches most of them. The rest are filed under "Animal & Veterinary" and need a word check on the product, which then has to exclude things that are animal products but not what a dog or cat owner signed up for:

$pet = str_contains( $types, 'Pet Food' )
  || ( str_contains( $types, 'Animal & Veterinary' )
       && preg_match( '/\b(dogs?|cats?|pets?|canine|feline|kitten|puppy|treats?|pig ears?|bully|chews?|jerky|rawhide|recipe|raw diet)\b/i', $product . ' ' . $brand ) );

// Dog and cat only: other animals' feed and veterinary drugs are not what subscribers asked for.
if ( $pet && ! preg_match( '/\b(dogs?|cats?|canine|feline|kitten|puppy)\b/i', $product )
     && preg_match( '/\b(hedgehog|reptile|bird|parrot|fish|aquarium|rabbit|hamster|horse|equine|cattle|swine|poultry|livestock|chicken feed|layer|sheep|lamb|goat)\b|injection|tablets?|sterile/i', $product . ' ' . $brand ) ) {
  $pet = false;
}

Two lessons from tuning it on real rows:

Keep pig ears and chews. Several Salmonella recalls are treats that never say "dog" in the product line.
"chicken" and "lamb" are not animals here, they're recipes. Which is why "lamb" only excludes a row when no dog or cat word is present, and why "chicken feed" is a phrase, not "chicken".

Only alert on what's new

Every 6 hours the server fetches the file, filters it, and compares each row's path (stable per announcement) with a stored list of paths already seen:

$seen = (array) get_option( 'pb_alerts_seen', array() );
if ( ! $seen ) { // first run: everything already on FDA's list counts as old news
  update_option( 'pb_alerts_seen', array_slice( array_keys( $all ), 0, 1000 ), false );
  return;
}
foreach ( $all as $path => $a ) {
  if ( in_array( $path, $seen, true ) ) continue;
  $seen[] = $path;
  if ( $a['date'] < $cut ) continue;   // an old entry FDA edited: not news
  // … match subscribers by brand, send, remember it for later …
}

Two guards matter:

The first run seeds, it doesn't send. Otherwise switching the feature on would email everyone about the last ten years of recalls.
Anything dated more than 14 days ago is skipped, because an old entry that FDA edits can turn up looking new.

The announcement is remembered too (date, company, brand), so when FDA's classified record arrives weeks later, subscribers to a specific food get a follow-up that says "confirmed: your barcode is on the list" instead of a second "new recall" email.

Recalls that are never announced

Here's the part I didn't expect: of the 48 dog and cat food recalls FDA classified since 2024, 21 (44%) never appeared on the announcement list at all. Those only exist as classified records, so the alert system has two triggers: announcements from the JSON file (same day), and newly imported classified recalls that match no earlier announcement.

(The window starts in 2024 on purpose: FDA's list keeps far fewer older announcements, so any "never announced" count before then would be wrong.)

WordPress cron needed a nudge

The checks run on WP-Cron, which only fires when someone loads a page. With Cloudflare caching HTML at the edge, most visits never reach PHP at all, so the "every 6 hours" check could go a day without running. The fix is a one-line system crontab that runs due events every 15 minutes:

*/15 * * * * cd /path/to/site && wp cron event run --due-now

Plus a daily watchdog that emails me if the FDA check hasn't succeeded in 13 hours, and a Monday summary email. If the summary doesn't arrive, the scheduled jobs have stopped.

What it does now

New FDA dog and cat food recall announcements go out the same day as emails to subscribers (by brand, by specific food, or all recalls), and as posts on Bluesky and X. You can sign up on PerBowl's recall list, which also shows announcements FDA hasn't classified yet.

The announcement-to-classification data, with every pair of dates, is downloadable as CSV if you'd like to dig into it.

A fair Secret Santa draw with exclusions is a matching problem

Jeremiah Say — Thu, 08 Oct 2026 01:39:28 +0000

A Secret Santa draw looks like a shuffle. It stops being one the moment someone says "Ana and Ben are a couple, they can't draw each other" and "nobody gets the same person as last year".

I built the Secret Santa generator on Toggle9 and ended up with three small problems hiding inside it:

Is a draw possible at all with these rules, and if not, why not, in words a person can act on?
How do you pick one so that every valid draw is equally likely?
How many valid draws are there? It turns out people like knowing.

All of it is pure functions over a 0/1 matrix, with no DOM, and randomness passed in so tests can seed it.

The model: an "allowed" matrix

A[i][j] is true when person i may buy for person j. Start with everything allowed except yourself, then switch off exclusions and last year's pairs:

export function allowedMatrix(people, avoid = {}) {
  const idx = new Map(people.map((p, i) => [p.n.toLocaleLowerCase(), i]));
  const A = people.map((_, i) => people.map((__, j) => i !== j));
  people.forEach((p, i) => {
    for (const x of p.no || []) { const j = idx.get(String(x).toLocaleLowerCase()); if (j !== undefined) A[i][j] = false; }
    const last = avoid[p.n];
    if (last !== undefined) { const j = idx.get(String(last).toLocaleLowerCase()); if (j !== undefined) A[i][j] = false; }
  });
  return A;
}

A draw is then a permutation to where A[i][to[i]] holds for everyone. With no extra rules that's a derangement: a permutation with no fixed points. For 6 people there are 265 of them out of 720 shuffles, about 36.8%. (That ratio tends to 1/e, which is why "shuffle until nobody has themselves" works fine for small groups.)

1. Is it possible? Matching, plus Hall's theorem for the "why"

Whether some valid draw exists is a bipartite matching question: givers on one side, receivers on the other, edges where A allows. Kuhn's augmenting-path algorithm answers it in a few lines.

The more interesting part is what to say when it fails. "No valid draw" is useless to a group organiser. Hall's theorem says a perfect matching fails to exist exactly when some group of k givers can only reach fewer than k receivers. And the failing run of Kuhn's algorithm hands you that group: everything reachable from the stuck giver along alternating paths.

for (let i = 0; i < n; i++) {
  if (tryAug(i, Array(n).fill(false))) continue;
  // i cannot be placed: everything reachable from i by alternating paths is the Hall violator
  const gs = new Set([i]), rs = new Set(), queue = [i];
  while (queue.length) {
    const g = queue.shift();
    for (let j = 0; j < n; j++) if (A[g][j] && !rs.has(j)) {
      rs.add(j);
      const m = rec[j];
      if (m >= 0 && !gs.has(m)) { gs.add(m); queue.push(m); }
    }
  }
  return { ok: false, givers: [...gs], receivers: [...rs] };   // receivers.length < givers.length
}

Small example: three people, and Ana and Ben may not draw each other. Ana can only buy for Cal, and so can Ben. The function returns givers: [Ana, Ben], receivers: [Cal], which the page turns into a sentence: Ana and Ben can only buy for Cal: 2 people, 1 person to buy for. Now the organiser knows which rule to drop.

2. Picking one fairly: rejection sampling

The tempting approach is to assign people one at a time, picking a random allowed receiver for each and backtracking when stuck. It finds a draw quickly, but not uniformly: early givers' choices skew who is left for later givers, so some valid draws come up more often than others.

The simplest fair method is also the oldest: shuffle (Fisher–Yates), check against the rules, and try again if it fails.

for (let t = 1; t <= maxTries; t++) {
  const to = shuffle(base.slice(), rnd);
  if (isValid(to, A, opts)) return { to, exact: true, tries: t };
}

Every permutation is equally likely from the shuffle, and we keep only the valid ones, so every valid draw is equally likely too. For a typical office or family group this succeeds within a handful of tries. In a 6-person test with two couples, it took 2.

The catch is a group with so many rules that valid draws are a tiny fraction of all shuffles. After 400,000 tries the code falls back to a randomised depth-first search plus random valid swaps (40·n² attempts), and reports exact: false rather than pretending the result is perfectly uniform. In practice only heavily constrained groups ever reach it.

rnd is passed in: the page uses crypto.getRandomValues, and the tests pass a seeded generator so a draw can be replayed.

Variants: "one big circle" and "no swapping pairs"

Two options change the shape of a valid draw:

One big circle: Ana → Ben → Cal → … → Ana, so gifts can be opened in a chain. Now a draw is a directed Hamiltonian cycle in the allowed graph, not just any permutation. The shuffle step generates a random cycle order instead of a random permutation.
No swaps: if Ana buys for Ben, Ben shouldn't buy for Ana. That forbids 2-cycles.

Both plug into the same isValid check, so the rejection-sampling loop stays the same.

3. Counting the draws

Showing "there are 116 possible draws" is a small thing, but it reassures people that the rules haven't boxed the draw in. Counting depends on the variant:

Plain draw: the number of perfect matchings is the permanent of A. Ryser's formula with a Gray-code walk computes it in O(2ⁿ·n). The intermediate terms overflow exact double precision from about 13 people, so larger groups switch to BigInt (the final count is still small enough for a Number).
Circle: count Hamiltonian cycles with a bitmask DP over subsets, fixed to start at person 0.
No swaps: brute force for up to 9 people.

Above 16 people the page simply doesn't show a count, because 2ⁿ stops being quick enough.

For the same 6 people with two couples who can't draw each other:

Rules	Valid draws
Couples excluded	116
Couples excluded + one big circle	48
Couples excluded + no swaps	64

The reveal links

Once drawn, each person gets their own link with their match encoded after the #, so it is never sent to a server. The text is XOR-scrambled with a random salt so a name doesn't show in a chat preview. That is not encryption, and the page says so: it stops accidental peeking, not a determined snoop.

Tests

The draw has its own test file in Node's built-in node:test, with a seeded random generator so every run is repeatable:

counts match the derangement numbers (OEIS A000166) with no rules, and brute force with rules, including the BigInt path at 13–16 people;
impossible groups must name the givers and receivers that cause it;
every returned draw must pass isValid, in every mode;
fairness: 4 people have 9 possible draws, so 18,000 seeded draws should land on each of them 2,000 times, give or take 10%.

If you'd like to try the edge cases, the generator is free with no sign-up. Three people where two can't draw each other is the quickest way to see the "why not" message.

Summing 50,000 emission line items in the wrong order changes your total

Jeremiah Say — Fri, 12 Jun 2026 06:38:12 +0000

Floating-point addition isn't associative. For a corporate inventory with tens of thousands of rows, naive summation drifts — and the number you disclose depends on row order. Here's why, and the fix.

Here's a result that should bother anyone building carbon software. Take a corporate emissions inventory — tens of thousands of line items, each a number in tonnes CO₂e. Sum it. Now sort the same rows differently and sum again. The totals don't match. Not by much — maybe the third or fourth decimal place — but they don't match, and nothing in your code changed except the order.

If you've never seen this, open a console:

0.1 + 0.2 === 0.3   // false

That's the same bug, scaled up to a reporting deliverable.

Why order changes the answer

IEEE 754 doubles have 52 bits of mantissa. That's about 15–16 significant decimal digits of precision — generous, until you add numbers of very different magnitudes.

When you add a small number to a large running total, the small number gets shifted right to line up the exponents before the addition happens. Bits that fall off the end of the mantissa are gone. Add a 0.0001 tCO₂e line to a running total of 80000.0 and there simply aren't enough mantissa bits to hold both the 80,000 and the 0.0001 — the small value is partially or completely swallowed.

Float addition, as a result, isn't associative. (a + b) + c is not guaranteed to equal a + (b + c). Sum your rows largest-first and the small values vanish early against a big accumulator. Sum smallest-first and they accumulate into something large enough to survive. Same data, different total.

Here's the effect, deliberately constructed to be visible:

const big = 80000;
const smalls = Array(50000).fill(0.0001);

// small values first, then the big one
let a = 0;
for (const x of [...smalls, big]) a += x;

// big value first, then the smalls
let b = 0;
for (const x of [big, ...smalls]) b += x;

console.log(a); // 80004.99999999...
console.log(b); // 80004.99999999... but not the same trailing digits
console.log(a === b); // false

The 50,000 small lines should contribute exactly 5.0. Depending on order, some of that contribution erodes against the large accumulator.

Why this matters for an inventory specifically

In most software a fourth-decimal drift is noise. In greenhouse gas accounting it's a problem for one specific reason: your numbers get re-run by someone else.

An assurance provider performing limited or reasonable assurance will rebuild your total from the underlying activity data. If their sum and your disclosed sum disagree — even slightly, even for a reason as defensible as floating-point order — that's a discrepancy someone has to explain. Reproducibility isn't a nice-to-have in this context; non-reproducibility is an audit finding.

And inventories are exactly the shape that triggers the problem: a handful of very large line items (grid electricity for a head office, a corporate vehicle fleet) sitting in the same sum as thousands of tiny ones (individual business trips, small fugitive losses). Large magnitude spread, high row count — the two conditions that make naive summation drift.

The fix: compensated summation

Kahan summation (also called compensated summation) keeps a second variable that tracks the low-order bits naive addition throws away, and feeds them back in on the next iteration.

function kahanSum(values) {
  let sum = 0;
  let c = 0; // running compensation for lost low-order bits
  for (const value of values) {
    const y = value - c;      // bring back what we lost last time
    const t = sum + y;        // the lossy addition
    c = (t - sum) - y;        // recover exactly what got dropped
    sum = t;
  }
  return sum;
}

The trick is the third line. (t - sum) recovers the part of y that actually made it into the sum; subtracting y leaves the part that didn't — the error term. You carry that error into the next iteration and add it back. The compensation c is, in effect, the bits that fell off the mantissa, saved for next time.

Run the earlier example through kahanSum and both orderings return the same total, accurate to the precision you'd expect from the inputs.

It's not magic — it can't manufacture precision the inputs never had — but it removes the order-dependence and recovers the low-order bits that naive summation discards. For an inventory total that someone else is going to re-derive, that order-independence is the property you actually want.

When this is overkill

Most of the time you don't need this. The drift only becomes material when row count and magnitude spread are both high:

A few dozen rows of similar magnitude: don't bother. The error is far below any rounding you'd disclose at.
Thousands of rows, similar magnitude: borderline. Usually fine, but cheap to be safe.
Thousands of rows with a wide magnitude spread (large facility totals summed alongside tiny per-trip lines): use compensated summation. This is the inventory case.

A rough mental threshold: if your largest line item is several orders of magnitude bigger than your smallest, and you have enough small lines that their collective contribution matters, naive summation can lose a material slice of the small-line total. That's most real corporate inventories.

If you want to avoid the question entirely, you can sum in fixed-point — work in integer grams or integer kg CO₂e instead of fractional tonnes — and convert only at display time. That sidesteps float drift at the cost of carrying integers around. Compensated summation is the less invasive change if you're already float-based.

The uncomfortable part

Most carbon calculators never hit this, and that's exactly the problem. They're tested against toy datasets — a dozen rows, a worked example from a guidance document — where naive summation is indistinguishable from compensated. The bug doesn't exist at demo scale. It surfaces at real inventory scale, in production, in the one number a company actually discloses, and it surfaces as an unexplained discrepancy in someone else's spreadsheet.

If you're building anything that sums emissions data for disclosure, this is worth eight lines of defensive code. I build carbon calculators where the methodology and provenance are the whole point, and order-independent summation is one of those things that costs almost nothing to get right and is genuinely awkward to explain after the fact.

Sort your rows however you like. The total shouldn't care.

I Built a Carbon Calculator Where the Emission Factor Doesn't Exist

Jeremiah Say — Wed, 03 Jun 2026 05:37:36 +0000

Most emissions calculators are a lookup table with a UI bolted on. You pick "diesel," the code fetches 2.51 kgCO₂e/litre from a factor table, multiplies by your input, done. I've built about a thousand of these. The refrigerant one broke the pattern, and the reason it broke is a small idea that's worth sharing if you ever model physical systems in code.

For refrigerant leakage, there is no emission factor to look up. The factor is the global warming potential of the gas itself.

Let me explain what that means and why it changed how I structured the data layer.

The 30-second domain primer

When a chiller or supermarket fridge leaks, the refrigerant gas escapes to atmosphere. Different gases trap different amounts of heat. We normalise that to GWP — Global Warming Potential — the warming caused by 1 kg of the gas relative to 1 kg of CO₂ over 100 years.

CO₂ has a GWP of 1. R-410A, a common air-conditioning refrigerant, has a GWP of 2,256. So one leaked kilogram of R-410A is climate-equivalent to 2,256 kg of CO₂ [source: IPCC AR6, WG1 Ch7]. That multiplier is the entire story.

The calculation is almost insultingly simple:

function refrigerantEmissions({ chargeKg, leakRatePct, gwp100 }) {
  const leakedMass = chargeKg * (leakRatePct / 100); // kg of gas
  return leakedMass * gwp100;                         // kg CO₂e
}

No factor table. No unit conversion gymnastics. Three numbers. So why did this one take longer to build than the combustion calculators that do need factor tables?

The actual hard part: the factor is a moving target with two valid values at once

Here's the trap. The IPCC publishes GWP values, and it revises them. AR5 (2014) said R-143a had a GWP of 4,470. AR6 (2021) says 5,810. That's a +30% shift in the answer for the exact same physical leak [source: IPCC AR5 / AR6 WG1].

And — this is the part that breaks naive data modelling — both values are still legally correct right now, depending on who's asking:

EU CSRD reporting → AR6, mandatory.
A 2019 baseline you set under AR5 → still AR5 until you rebaseline.

So the factor isn't a constant. It's a function of (gas, assessment_report). My first instinct — refrigerants["R-410A"].gwp — was wrong, because there is no single .gwp. There are two, and the correct one is a property of the user's reporting context, not the gas.

The data shape that actually works:

const refrigerants = {
  "R-410A": {
    label: "R-410A — Building / split AC (HFC blend)",
    gwp100: { ar6: 2256, ar5: 2088 },  // both live, caller picks
    fgasThreshold: true                 // GWP ≥ 2,500? (regulatory flag)
  },
  // ...50 more
};

The lesson generalises well beyond carbon: when your source of truth revises itself but the old version stays valid, the version is part of the key, not metadata you can flatten away. I've since refactored other calculators the same way.

The drift is not noise — and that's a UX decision, not a data one

For most emission categories, AR5 vs AR6 is sub-1% — genuinely ignorable. For refrigerants it isn't:

Refrigerant	AR5 GWP-100	AR6 GWP-100	Drift
R-32	675	771	+14.2%
R-134a	1,430	1,526	+6.7%
R-143a	4,470	5,810	+30.0%
R-410A	2,088	2,256	+8.0%
R-404A	3,922	4,170	+6.3%

Source: IPCC AR5 (WG1 Ch8) and AR6 (WG1 Ch7) GWP-100 values.

A naive build just exposes a toggle and lets the number silently jump 30%. I think that's a quiet way to mislead a user who doesn't know the chemistry changed under them. So the engine computes the drift and surfaces it inline whenever |drift| ≥ 3% — the user sees "switching to AR6 adds X% on your gas mix" before they export anything.

That's a small rule, but it encodes a position I'll defend: a calculator that can produce two different right answers has a duty to tell you why they differ. Hiding it behind a toggle is technically correct and practically dishonest.

The leak rate is a default, and defaults are a trust contract

The other input — annual leak rate — comes from IPCC Tier 1 defaults by equipment class (Table 7.9 of the 2019 Refinement). Transport refrigeration's published range is 15% to 50%. That's enormous. I store the mid-range as the preset but treat it as explicitly provisional:

const equipmentDefaults = {
  "transport-refrigeration": { preset: 25, range: [15, 50] },
  "supermarket":             { preset: 20, range: [10, 35] },
  "chillers":                { preset: 8,  range: [5, 15]  },
  // ...
};

The engine never lets a default masquerade as a measurement. A measured, documented rate always overrides the preset, and the audit export records which basis was used. If you're building anything where users will be audited on your output, the single most valuable feature is provenance on every number — what it was, where it came from, and whether it was assumed or measured. That's worth more than any chart.

Where this lives

The full thing — all 51 refrigerants, the AR5/AR6 engine, the F-Gas regulatory flags, and an audit-mode export that hashes every result back to its source — is live on GreenCalculus. If you want to see the moving-target factor model in the wild, the Scope 1 refrigerant leakage calculator on GreenCalculus is the cleanest example of the pattern.

If you model physical or regulatory systems in code, the takeaway I'd leave you with: the hard part is rarely the arithmetic. It's that your authoritative source is itself versioned, sometimes contradictory, and always more nuanced than a single number. Build for that from day one and the refactor never comes.

The "Audit Trail" Pattern: Architecture for Immutable Sustainability Data

Jeremiah Say — Fri, 29 May 2026 03:06:36 +0000

In standard CRUD apps, if a user updates their profile name, you overwrite the database row. No big deal. But in CSRD (Corporate Sustainability Reporting Directive) software, overwriting a row is a compliance nightmare.

If an auditor asks, "Why did your Scope 1 emissions for 2024 change between July and October?" and your answer is "A dev ran a migration that updated the emission factors," you've just failed the audit.

To build a compliant carbon engine, you have to move away from "Current State" databases and toward Immutable Data Architectures. This is the pattern I use at GreenCalculus.com to ensure that once a report is "frozen," the data stays frozen—even if the underlying code or emission factors change.

The Problem: The "Floating" Emission Factor

Most carbon calculations look like this in the backend:

$$E = A \times EF$$

Where $E$ is emissions ($tCO_2e$), $A$ is activity data (e.g., liters of diesel), and $EF$ is the Emission Factor.

The mistake is storing only $A$ and looking up $EF$ at runtime. Emission factor sets (like DEFRA or IEA) are updated annually. If you update your factors table to the 2026 set, your 2024 calculations will suddenly change because the runtime lookup finds a new value. This is called Data Drift, and it's an auditor's biggest red flag.

The Solution: The Snapshot Pattern

Instead of linking to a factor, you must persist the snapshot of the calculation at the moment it occurred. You don't just store the result; you store the "receipt" of the math.

The JSON Data Structure

{
  "activity_id": "fuel_log_789",
  "calculated_at": "2026-05-29T10:00:00Z",
  "inputs": {
    "value": 500,
    "unit": "liters"
  },
  "snapshot": {
    "factor_used": 2.6765,
    "factor_source": "DEFRA_2025",
    "gwp_basis": "AR6",
    "formula_version": "v2.1.0"
  },
  "output_tco2e": 1.33825,
  "checksum": "a1b2c3d4..." 
}

Implementation: The Three-Tier Storage Strategy

To achieve this in a standard PHP/JavaScript stack, you need to separate your raw data from your calculated disclosures.

1. The Activity Ledger (Source of Truth)

The ledger stores the raw evidence (e.g., "Invoice #123: 500L Diesel"). Once an entry is verified, it becomes Append-Only. Any corrections are handled via "reversal entries" (credit/debit style), exactly like a financial ledger.

2. The Factor Registry (The Library)

Never delete or UPDATE an old emission factor. Your database schema should treat factors as immutable versions:

CREATE TABLE emission_factors (
    id UUID PRIMARY KEY,
    label TEXT, -- e.g. "Diesel (Average Biofuel Blend)"
    value DECIMAL,
    year INTEGER,
    version_start TIMESTAMP,
    version_end TIMESTAMP -- Null if current
);

3. The Calculation Archive (The Receipt)

This table stores every "point-in-time" result. When an auditor asks for the numbers, you query this table, not a live calculation function.

The Code: A PHP/Laravel Implementation

When a calculation is triggered, we don't just return a number; we return a CalculationReceipt object that contains the entire context, including a hash of the code version used.

class CarbonCalculator {
    public function calculate(Activity $activity): CalculationReceipt {
        // Find the factor that was active at the time the fuel was consumed
        $factor = $this->registry->getFactorFor($activity->type, $activity->consumed_at);

        $total = $activity->value * $factor->value;

        // We store the literal values used, NOT just a foreign key
        return CalculationReceipt::create([
            'activity_id'   => $activity->id,
            'tco2e'         => $total,
            'meta_snapshot' => [
                'factor_name'  => $factor->label,
                'factor_value' => $factor->value,
                'gwp_basis'    => 'AR6',
                'logic_hash'   => hash_file('md5', __FILE__), // Proves which code version ran this
            ],
            'is_frozen' => true
        ]);
    }
}

Audit-Proofing the Frontend

When a user views their "2025 Inventory," the frontend should never trigger a fresh calculation. It should fetch the stored receipts.

However, if a methodology changes (e.g., the EU updates the ESRS E1 guidance), you can run a "What-If" check. If the system detects that a factor has been updated since the receipt was generated, you display a Discrepancy Warning:

⚠️ Methodology Change: A newer emission factor (DEFRA 2026) is available. Your current report uses DEFRA 2025. [Recalculate and Re-verify?]

This puts the power in the hands of the sustainability officer to decide when to "re-state" their figures—a formal requirement in CSRD reporting.

What this architecture prevents

Silent Drifts: You avoid the "Why is our total different than it was yesterday?" slack message.
Audit Failure: You can produce a "lineage report" for every single gram of $CO_2$ in the system.
Regression Bugs: A bug introduced in a new feature won't accidentally corrupt historical data because historical data is physically separated from the calculation engine.

The Golden Rule for CSRD Devs: In carbon accounting, an "edited" record is a liability. Build for the trail, not just the total.

I'm building the data integrity layer for GreenCalculus.com. If you're working on CSRD or ESRS compliance, let's swap notes in the comments.

Floating-point will quietly corrupt your emissions math, and 0.1 + 0.2 already warned you

Jeremiah Say — Sat, 23 May 2026 00:04:20 +0000

Every developer has seen this:

0.1 + 0.2
// 0.30000000000000004

It's the most-shared bug in programming. You learn it, you nod, you move on — because in most code the error is so far down the decimal that nothing notices. A pixel is off by a billionth. A timer fires a nanosecond late. Nobody files a ticket.

Then you build a system whose entire job is to add thousands of numbers together and produce a total that has to match a figure someone calculated by hand. And the rounding error you waved away in the tutorial becomes a line in an audit report that says: the system total does not reconcile to the source data.

That's where I met this bug for real, building the calculation layer at GreenCalculus.com. It runs over a thousand emissions calculators, and every one of them has the same hard requirement: the number the engine produces must reconcile, to the last reported digit, against the number a practitioner gets when they check the math themselves. "Close enough" is a finding. This post is the set of rules that get you from the math looks right to the math reconciles.

Why this bites harder in measurement code than anywhere else

Most software treats numbers as means to an end — coordinates, counters, ratios feeding a render. The exact value rarely is the deliverable.

In emissions accounting, the number is the deliverable. A reported figure of 1,240.37 tCO2e is the product. If an auditor recomputes it and gets 1,240.41, the 0.04 isn't noise — it's an unexplained discrepancy, and unexplained discrepancies are exactly what an audit exists to surface. You don't get to say "floating-point." You get to fix your data model.

Three properties of this domain turn a harmless rounding error into a real defect:

Massive summation. A Scope 3 inventory adds tens of thousands of line items. Error accumulates with count.
Wide dynamic range. You add a 4,000,000 kg figure to a 0.002 kg figure in the same total. This is precisely the case floating-point handles worst.
External reconciliation. The output is checked against an independent calculation. There's no hiding internal drift, because someone outside your system recomputes it.

The float problem, stated precisely

A 64-bit IEEE 754 float (double, JavaScript's only number type) stores 52 bits of mantissa — about 15–17 significant decimal digits. 0.1, 0.2, and 0.3 are not representable exactly in binary, the same way 1/3 isn't representable exactly in decimal. They're stored as the nearest available binary fraction, and the tiny errors survive arithmetic.

(0.1 + 0.2).toFixed(20)
// "0.30000000000000004441"

For a single operation the error is ~10⁻¹⁷. The problem is what happens when you do the operation 50,000 times, and when the operands differ in magnitude by a factor of a billion.

Failure mode 1: the total that won't reconcile

Naive summation of a long list of factors:

function totalEmissions(lineItems) {
  let total = 0;
  for (const item of lineItems) {
    total += item.activity * item.factor;   // each term carries float error
  }
  return total;
}

Each activity * item.factor lands on the nearest representable double, slightly off. Each += rounds again. Over tens of thousands of items the errors are mostly random and partly cancel — but "mostly" is not "exactly," and the residual is deterministic for a given input order. Run the same data through a spreadsheet that sums in a different order and you get a different last digit. Now you have two "correct" totals that disagree, and no way to say which is right.

Fix: control precision at the boundary, not in the loop

Two defensible strategies, depending on stack.

Decimal arithmetic for the money-and-mass path. Store and sum factors as arbitrary-precision decimals so there's no binary-representation error at all:

import Decimal from 'decimal.js';

function totalEmissions(lineItems) {
  return lineItems
    .reduce((acc, item) =>
      acc.plus(new Decimal(item.activity).times(item.factor)),
      new Decimal(0))
    .toNumber();   // convert once, at the very end, after rounding regime applied
}

Decimal is slower. You don't need it everywhere — you need it on the path whose output is a reported figure.

Kahan summation when you must stay in floats. If the hot path can't afford Decimal, compensated summation recovers most of the lost low-order bits by tracking the rounding error and feeding it back in:

function kahanSum(values) {
  let sum = 0;
  let compensation = 0;        // running error term
  for (const v of values) {
    const y = v - compensation;
    const t = sum + y;
    compensation = (t - sum) - y;   // recovers what the addition just dropped
    sum = t;
  }
  return sum;
}

The single addition sum + y loses the low bits of y when sum is large; the next line reconstructs exactly those bits and carries them into the following iteration. For a long sum of mixed-magnitude terms this is the difference between a stable total and one that drifts with input order.

Failure mode 2: the wide-magnitude swallow

This is the one that produces a wrong number, not just an unstable one.

let total = 4_000_000.0;   // a large facility's annual figure, kg
total += 0.002;            // a trace fugitive line, kg
total === 4_000_000.002;   // true here — but stack enough trace lines...

When the accumulator is large and the addend is tiny, the addend's significant bits fall off the bottom of the mantissa and are silently dropped. One trace line is fine. Ten thousand of them, each individually swallowed, is a missing category total. The sum looks authoritative — it's a clean large number — which is exactly why nobody catches it by eye.

Fix: sum within magnitude bands, then combine

Add small things to small things before adding them to big things. Sort ascending and the smallest terms accumulate among themselves into a magnitude the large accumulator can actually absorb:

function bandedSum(values) {
  const ascending = [...values].sort((a, b) => a - b);
  return kahanSum(ascending);   // small-first ordering + compensation
}

Sorting ascending before a compensated sum is a cheap, robust default for "many small, few large." It won't matter on uniform data — but reference-data sums are rarely uniform.

Failure mode 3: the ratio that amplifies

Intensity metrics divide one computed figure by another — emissions per unit revenue, per tonne of product, per kWh. Division doesn't create error, but it amplifies whatever error the operands already carry, and ratios of two nearly-equal slightly-wrong numbers are the worst case.

const intensityA = total2025 / output2025;
const intensityB = total2024 / output2024;
const yoyChange = (intensityA - intensityB) / intensityB;   // tiny - tiny, over tiny

When intensityA and intensityB are close, their difference is dominated by the rounding error in each, and dividing that noisy difference by a small base inflates it into a visible percentage. Your year-on-year intensity change can read as ±0.3% pure artefact.

Fix: defer rounding, widen the working precision

Carry full precision through the entire chain and round once, at presentation. Never round an intermediate that feeds a later division. If the figures are reconciliation-critical, do the division in Decimal too — the cost is trivial relative to one division per report.

Failure mode 4: the unit-boundary shave

Every conversion is a multiply, and every multiply is a place to lose digits. The g → kg → t chain looks innocent:

const grams = 1234567;
const kg = grams / 1000;        // 1234.567
const tonnes = kg / 1000;       // 1.234567
// round-trip back up and compare:
tonnes * 1000 * 1000 === grams; // not guaranteed

Each division lands on the nearest double; chaining them compounds the drift, and a value that round-trips through three units may not come back to where it started. The fix is the same architectural rule that governs the whole post: store in one canonical unit at full precision, convert only at the display boundary. Don't persist the converted value and re-derive from it — persist the canonical value and convert on read.

The rule underneath all four

Every one of these is the same decision made wrong: where does precision get fixed, and how many times. The failures all come from rounding early, rounding repeatedly, or rounding in the middle of a chain that isn't done yet.

The architecture that prevents all four:

One canonical unit, full precision, in storage. No pre-rounded, pre-converted values persisted.
A declared rounding regime, applied once, at the boundary. Half-up, half-even — pick one, document it, apply it where the number leaves the system, never before.
Decimal on any path whose output is a reported figure. Floats are fine for charts and progress bars. They are not fine for the deliverable.
Compensated, magnitude-aware summation wherever you must aggregate many terms in floating point.

This is the same shape as a rule we apply to every figure in the GreenCalculus data layer: a number is meaningless without its declared basis. There, the basis is the GWP version and the emission-factor source. Here, it's the unit and the rounding regime. In both cases the discipline is identical — the number is not just its digits; it's its digits plus the declared rules that produced them. Store the rules with the number, or you can't defend the number.

0.1 + 0.2 was never the bug. It was the warning that your numbers carry rules you haven't written down yet.

The GreenCalculus calculation layer applies these rules across 1,000+ emissions calculators, every one of which has to reconcile against its source data to the last reported digit. Methodology documentation at greencalculus.com.