Finding and fixing a number that was wrong in the OEIS for over a decade

The OEIS (the Online Encyclopedia of Integer Sequences) is the public database of number sequences that mathematicians use and cite. For more than 14 years, from December 2011 to July 2026, one of its entries listed a number with a digit missing. Its thirteenth term read 1,150,036. The right value is 11,500,336. Put them side by side and the short one is the long one with a 3 left out. A Claude agent working under my direction spotted it; I had the right value confirmed two ways and sent in the correction, and the entry now carries it.

This page tells that story step by step. A separate explainer covers what the case means for anyone who copies values from reference tables, with two cheap checks that catch this kind of error.

What the entry counts#

The entry is A202182. It counts N-free posets of each size. A poset is a set of items where some pairs are ranked one above the other and some are not, and the ranking is consistent: if a is below b and b is below c, then a is below c. Draw each item as a dot, with a line up to each item directly above it. The poset is N-free if no four dots form the letter N: two at the bottom and two at the top, joined by three lines that go up, down and up again, with no other ranking among those four. Posets that are the same apart from the names of their items count once. The size of a poset is its number of items, and the entry's thirteenth term is the count for size 13.

Each new term takes a lot of computing, so once a value is in the table, people usually copy it rather than recompute it.

Why it stayed wrong so long#

The wrong value was there from the entry's first version in 2011. In 2021 someone editing the entry filled in the term just before it, the twelfth, which had been missing. Adding a new term gives no reason to recompute the ones already listed, which is presumably why the thirteenth stayed as it was.

How it was spotted#

In July 2026 I had eight Claude agents scouting for new projects, each in a different area. The one covering discrete math and the OEIS compared A202182 with its two companion entries, which split the same posets in two: those that come in one connected piece (A202180) and those that do not (A349367). For any size, those two counts should add up to the total in A202182. For size 13 they are 8,840,306 and 2,660,030, which add up to 11,500,336, not the listed 1,150,036.

How it was confirmed#

A sum like that is a strong hint, but I did not want to send a correction based on it alone. Before submitting anything, I had Claude agents work the value out by two routes that do not depend on each other:

1. Through the database. The agents redid the sum from the live entries: it fails at size 13 and holds at every other size. They also rebuilt the total from the connected counts alone, with a standard formula that assembles posets from their connected pieces (the Euler transform); it gave 11,500,336 and matched every other listed term. Both of these start from the listed connected counts, so together they are one route.
2. From scratch. A program that a Claude agent wrote for this project listed every N-free poset with 13 items, after first reproducing every listed value through size 12. It was run twice, in two separate sessions, with the same code. Both runs gave 11,500,336, split into 8,840,306 connected and 2,660,030 not.

The correction#

I submitted the correction with the evidence from both routes, including the recomputed values of the terms around it, and the OEIS editors approved it in July 2026. Only the thirteenth term changed, and the entry credits the correction to me by name. In August 2026 I added the next new term to the same entry (the fourteenth was already listed), the fifteenth, 435,034,695. It came from a rewritten enumerator that first reproduced the family's published tables through size 14, and the number of disconnected posets it implies matches the separately published value in A349367 exactly.

For readers in software:how the software was built, and which parts you could reuse

What found this bug was a cross-table invariant: two derived tables must add up to a third. A single table can be wrong for years with nothing inside it to contradict it. If related tables in a dataset must satisfy an identity like this, it is worth asserting it and checking it whenever any of them changes. A value that is expensive to recompute usually gets copied from the last place it appeared, and nobody recomputes it.

@misc{orden2026oeistypohunt,
  author       = {Tyler Satchel Orden},
  title        = {Finding and fixing a number that was wrong in the OEIS for over a decade},
  year         = {2026},
  howpublished = {Cyborg Mathematics},
  url    = {https://cyborgmathematics.com/writing/oeis-typo-hunt}
}