Guide · New to this

Recount the total from the list, and count each item once

My total read 34 in late August and 34 in early September, and the list underneath was wrong twice in between. Copied totals drift from the lists they come from. Decide what one item is, count each one once, and check that the parts add up.

I'm Tyler Orden, an independent researcher who does mathematics with AI agents. My research record is at Cyborg Mathematics.

A headcount on a slide, a customer total in a monthly report, the number of open deals: totals like these get copied from one document to the next, and nobody recounts them because the number looks familiar. Before you present one, recount it from the list it came from, such as the team roster or the customer export. Decide first what one item is (a person or a role, a customer or an account), then check the list for anything counted twice. If an AI wrote the total for you, ask it to list every item it counted.

For teams: name one owner for each headline number. The owner produces it from the list, never by editing the old figure, and keeps the list next to the number with the date it was counted, in the deck's appendix or the shared sheet. Anyone else, person or AI, who quotes the number copies it from there, with its date.

Check a total an AI gave you

List every item you counted to get this total, one per line, each with its ID or name. Then tell me: does any ID appear twice? If the total is split into categories, put each item in exactly one category, show the count for each category, and show that the categories add up to the total.

Here is the case that taught me this. My research is mathematics, and many of the results go into the OEIS, the public database of number sequences that mathematicians use. Each entry there credits the people who worked on it, on the author line or in a dated note: I created the entry, added new values to it, corrected it, or added a signed comment and data file. I keep a count of the entries that credit me. Claude, the AI agent that runs the project, keeps that count on the project's status page, as a total with a breakdown by kind.

Here is what the records said, and what was true. The count was 34 at the time of this story; it is 43 as of October 20, 2026. In short: between late August and September 6 the list was wrong twice and fixed twice, and the total ended where it started.

Date	Records said	True	What was wrong, and how it came out
August 27	34	33	One entry had been counted twice, once for added values and once for a correction.
August 29	34	33	A recount from the live database, made for my research site, listed 33. Nothing in the process compared it with the 34 on the status page.
September 3	33	33	An AI helper checking the project’s documents read the August 29 recount and saw the mismatch. Claude searched the live database, confirmed 33 and corrected the records.
September 5	33, with a breakdown of 11 created, 21 extended and 2 corrected, which adds up to 34	33: 10 created, 21 extended, 2 corrected	A helper’s live search found one entry counted both as created by me and as extended.
September 6	34	34: 10 created, 21 extended, 2 corrected, 1 commented	A comment and data file of mine were published on another entry. Counting a comment is a choice: under a stricter rule that counts only entries I created, extended or corrected, the total stayed 33.

So the total ended at the same 34 it showed in August. Anyone who compared only the late-August total with the September 6 total saw no change, while the list underneath had been wrong twice and fixed twice.

The root cause was that the records never said what one item was. Was it an entry, or a credit? One entry can carry two kinds of credit, and when the count was built by adding up kinds, that entry was counted twice. The count now works this way: each distinct entry is counted once, by its ID number in the database, and placed under exactly one kind of credit, read from the entry itself. The kinds then have to add up to the total, in the same document.

On September 5 the total and its breakdown disagreed because on the status page they were typed in separately. My research site has calculated its total from the itemized list since August, so there the total cannot disagree with its parts. That is necessary and not enough: if the same item sits in two parts, a total calculated from the parts is wrong too. Counting distinct IDs is what catches that.

The recount itself had to be checked too. A search of the database for my surname on September 6 returned 47 entries, and 13 were not mine (other mathematicians with the same surname, and one entry that simply contains the Spanish word "órdenes"). As a cross-check, a separate search of the database's author lines found exactly the 10 entries I created. 47 minus 13 is 34, which matched the itemized list.