What a long-standing error in a math database means for anyone who copies reference values

What this explainer covers

From December 2011 to July 2026, more than 14 years, an entry in the OEIS, a public database of number sequences, listed one of its values as 1,150,036. The right value is 11,500,336: the same digits with a 3 put back. A Claude agent I had sent to look for new research projects noticed that two related entries did not add up to the listed number. The right value was then confirmed by two routes that do not depend on each other, and the entry now carries the correction. If you copy values from reference tables, this is a real case of a published number that was wrong for years, and of two cheap checks that expose this kind of error.

Animation, no sound. Two columns of rows: a published table on the left, a fresh recomputation on the right. A highlight moves down the right column, filling each row with digits; each row matches its published row and gets a check mark. At one row the recomputed value has one more digit than the published one; the gap in the published value is outlined, the row is highlighted and marked not equal. Then the missing digit drops into place, the mark becomes a check, the remaining rows also match, and the number 14 appears with the word years. Digits are drawn as blank cells.

What the OEIS is#

The OEIS (Online Encyclopedia of Integer Sequences) is the public database of number sequences that mathematicians use and cite. Each entry lists the terms of one sequence, for example how many structures of a certain kind exist at each size. People use it the way anyone who works with data uses a reference table: they look up a value, or compare their own output against it to see whether their code is right. New terms and corrections are posted as public drafts, and editors read them before approving them.

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 differ only in the names of their items count once. The wrong value was the one for size 13, that is, for posets with 13 items.

Another OEIS entry, A003430, uses a stricter definition of N-free that leaves out some posets this entry counts. Mixing up the two could make counts disagree, which is why the confirmation below checks that this was not the cause.

How the wrong value stayed in the entry#

The wrong value was there from the entry's first version in December 2011, as the entry's history page↗ shows. The value for size 12 was missing until 2021, when someone editing the entry filled it in. Adding a value does not involve recomputing the ones already listed, so the value for size 13 stayed as it was. The value for size 14 was also listed by July 2026, and it was right.

Recomputing the value was not a big job once a counting program existed. The from-scratch count described below needed a little under an hour on one computer to get through 13 items. Each further size costs a lot more: going on to 14 items took about 25 hours more. What most likely kept the wrong value in place is that nothing in how the entry is kept up prompts anyone to recompute an old value, and people who use a listed value usually copy it.

How it was spotted#

In July 2026 I had eight Claude agents scouting at the same time for research projects worth taking on, each in a different field, from physics and chemistry to computer vision and discrete math. Each was told what kind of project I wanted: new, publishable, and something I could do alone on one computer with public data. Each checked its ideas against live web and OEIS searches to see whether someone had already done them, and rated them. None of them was asked to look for errors.

The one covering discrete math and the OEIS proposed extending this family of entries. While sizing it up, it 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. The agent wrote this up as one line of its proposal, a quick fix to send along with the extension.

This check has only been possible since November 2021, when the entry for the disconnected posets, A349367, was created, less than five years before the agent ran it.

How it was confirmed and corrected#

A sum like that is a strong hint, but I decided not to send a correction on it alone. I had Claude agents confirm the value by two routes: one through the database and one from scratch.

The first route trusts the database. It redid the sum from the live entries, and it also rebuilt the total from the connected counts in A202180 alone, using a standard formula (the Euler transform) that treats every poset as a collection of connected pieces, repeats allowed. Both gave 11,500,336. Both lean on the listed connected counts, so together they make one route.

The second route uses nothing from the database. A counting program written for this project lists every N-free poset with 13 items from scratch. Before its answer for size 13 was believed, it had to reproduce every listed value through size 12, and it did. That also rules out the two definitions of N-free as the cause: a count under this entry's own definition matches every listed value through size 12 and differs only at size 13. The program was run twice, in two separate sessions, and both runs gave 11,500,336. Both runs used the same program, so the second one guards against a crashed or corrupted run, not against a bug in the program. What tests the program itself is that it reproduced the listed values through size 12.

I submitted the correction with the evidence from both routes, and the OEIS editors approved it in July 2026. Of the listed values it changed only the one for size 13, and the entry now credits the correction to me by name. I do not know of anyone outside this project who has recomputed the value. The longer story, including the next value I added to the entry in August 2026, is in How I found and fixed a number that was wrong in the OEIS for over a decade.

If your work depends on copied reference values#

The closest thing in everyday data work is a lookup table that a pipeline joins against: a set of conversion factors, a published constant, a column of benchmark values, a code list. Those values are usually copied rather than checked again, and a value nobody has rechecked since it was entered looks just as settled as one that has been.

Two standard data-quality checks flag this error without recomputing anything. The first is the one the agent ran: when related tables must agree, test that they do. If tables in your own data must satisfy an identity like "connected plus disconnected equals total", assert it in code and run it whenever any of them changes.

The second is to check each value against its neighbors. In July 2026 the entry listed 1,996,922 for size 12, then 1,150,036 for size 13, then 69,269,925 for size 14. That is a drop, then a jump of about 60 times. With the right value, each step is about 6 times. A dropped or extra digit usually changes a value about tenfold, as it did here, so an outlier test on the logarithms of neighboring values can flag it. This only works for tables whose values should grow or shrink steadily, and it misses a wrong digit that leaves the size of the number about the same. The first check can still catch that kind, as long as the related tables are right.

An OEIS term can be recomputed from its definition, which is a strong check if the program doing it has itself been tested. Most everyday reference data cannot, because a survey estimate or a measured constant depends on data you do not have. For those values the two checks above, plus a second published source, are what you have. And if you find an error, send it to the source with evidence the maintainer can check, so the fix reaches everyone who uses the table.

One value in one entry#

This case shows that a wrong value can stay in an edited reference table for years when nothing prompts anyone to recompute it. It does not show that the OEIS is unreliable in general, and it gives no error rate, since it is one value in one entry. I also do not know whether anyone used the wrong value in their own work.

For specialists: the exact definition and the two routes

A202182 counts unlabeled posets (counted up to isomorphism) that are N-free in the sense of the entry's comment, which uses covering relations. Say that y covers x when x is below y with nothing in between. The poset contains an N if it has four elements a, b, c, d such that b covers a, b covers c and d covers c, with no other comparabilities among the four. The entry's example gives a five-element poset that is N-free in this sense but is excluded under the definition used by A003430. Under A202182's own definition the from-scratch count also matches the companion entries A202180 (connected) and A349367 (disconnected) through n = 13. The entry's offset is 1, so its thirteenth term is the count for n = 13.

The first route used the identity A202180(n) + A349367(n) = A202182(n), recomputed from the live entries as they stood in July 2026, which fails only at n = 13, and the Euler transform of A202180, which rebuilds A202182 from its connected counts and gives 11,500,336 at n = 13 while matching every other listed term. The second route was a direct enumeration of N-free posets by orderly generation, adding a new maximal element above an order ideal at each step (deleting a maximal element changes no cover relation among the others, so N-freeness is preserved). It was run to n = 13 in two separate sessions with the same code; both runs reproduced the listed terms through n = 12 and gave 11,500,336 at n = 13, and the first run, left going, also reproduced the listed term at n = 14. That is four computations by two routes. In August 2026 a rewritten enumerator, used to compute the term at n = 15, first reproduced the family's published tables through n = 14.

@misc{orden2026explainerreferencetablescanbewrong,
  author       = {Tyler Satchel Orden},
  title        = {What a long-standing error in a math database means for anyone who copies reference values},
  year         = {2026},
  howpublished = {Cyborg Mathematics},
  url    = {https://cyborgmathematics.com/writing/explainer-reference-tables-can-be-wrong}
}