The D'Arcy Archive
Its own errors, gathered

What This Archive Got Wrong

52 mistakes this archive made and then corrected in public, with what caused each one. An archive that asks to be trusted about other people's errors has to be legible about its own.

Every page here carries a confidence label, and the method only means anything if it is applied to the archive itself. These are errors this site published — not inherited from the family tree, but made here — together with what caused each one and what it should teach the next person.

None of these was quietly edited away. Each correction still stands on the page where the error was made, which is why the links below go to the page rather than to an apology. Two were caught within hours. One stood for a day — and it was the worst kind, a confident correction aimed at the family about their own family.
28 September 2026

was Fixed eight gates that swallowed an unknown flag, said so, and did not check whether anything else in tools/ chose a build directory some other way. Three did, by hardcoding `site/dist` — including crossread.py, the tool written for the exact failure committed as own error 49 that morning.

now agree.py, crossread.py and sitemap.py each set `DIST = os.path.join(ROOT, "site", "dist")` and read no environment. agree.py runs in every build here, so with ARCHIVE_OUT set it has been reporting on the shared dist of 23 September — five days stale. It read 225 sources where the current build has 218, and the seven are not arbitrary: they are SEVEN PLACE PAGES THAT NO LONGER EXIST — /places/berkley, /places/ashton, /places/ashton-underhill, /places/christened-in-berkeley, /places/queensland-australia, /places/about-limerick-city, /places/lt-ehrstaedt. Every one was retired by this archive's own folding of place-name variants in place-same.json. agree.py is the PLACE-NAME AGREEMENT report, so it was checking whether this archive's places agree with each other while reading seven places it had itself abolished. crossread.py is wired into nothing, so the tool this archive reproached itself for not running would have graded the wrong build if it had been. tools/sitemap.py is referenced nowhere at all; the kit's is used instead.

how The eight gates were found by a neighbouring session tripping over one of them, and the fix was scoped to what they had tripped over. «Eight gates fixed» was reported as though it were the class, when it was the instances that shared one symptom — a flag. The ones that never took a flag, and so never had the symptom, were not looked at.

The lesson. THE QUESTION IS NOT «DOES THE FLAG WORK» BUT «HOW MANY WAYS CAN THIS BE CHOSEN, AND WOULD ANYTHING SAY SO». The neighbouring session took that sentence to two other archives and found two more variants — one where the environment is never read but a wrapper happens to substitute it, and one where nothing is read and nothing covers for it. Four shapes of one missing agreement across three archives, and a fifth here found only by asking the question of the tools that had no symptom at all. Everything that names a build directory now asks outdir, and nothing else may. AND A CORRECTION TO HOW THE FIVE GET REMEMBERED, from the session that found two of them: shape 2 — the kit's, environment beats flag — was not right because anybody reasoned it out. It is what the kit converged on AFTER shapes 1 and 3 had been hit and fixed elsewhere. Four of the five were found by hitting them. Only the fifth was found by inspection, and only because a question had been written down first.

Where it was corrected →

28 September 2026

was Told a neighbouring session, and David, that this archive's evidence gate «reads 189 record lines reach 61 of 61 people on every build». It does read that — on this machine. It had never run on a deploy, and nor had nine of the other eleven gates here.

now GitHub Actions builds the published site and runs `npm run build`. build.sh — which is what runs the archive's own gates — runs nowhere but here, because it opens the GEDCOM and the GEDCOM is gitignored. Counted rather than assumed once the question was put: ten of twelve. check_secrets.py, check_decisions.py and check_unpublished.py, all written in the two days before, were among them, so every gate built in response to a fault was itself outside the thing it was built to protect.

how «The build passes» meant the command this session types. It was true, it was checked repeatedly, and it was about a different build from the one the public reads — the same shape as grading a stale dist, one level up. The neighbouring session could see it precisely because it had no access to this machine and could only read what is committed.

The lesson. A CHECK IN THE REPOSITORY IS NOT A CHECK ON THE BUILD, which is the tools' version of the sentence this archive wrote the day before about pages. The ten that need only committed data and built HTML are wired into `npm run build` now and run on every deploy. The two that stay behind stay behind for a reason worth stating: they read the GEDCOM, and CI must never hold it.

Where it was corrected →

28 September 2026

was Published «57 passages of prose reach no page» as the measured backlog of unpublished research, and put the figure in a work list item, the day log and a report to David. The real number was 10. Forty-seven of the fifty-seven were the measuring tool's own normalisation.

now check_unpublished.py compared data against built HTML with whitespace COLLAPSED rather than removed. Stripping tags turns «<strong>ASHLEWORTH</strong>,» into «ASHLEWORTH ,» and the data side has no space before that comma, so any passage whose first seventy characters contained inline bold next to punctuation reported as missing while sitting on its own page. The Ashleworth identification on /swonhungre was one of them. Comparing with whitespace removed entirely took 57 to 10 and the log-only count from 2 to 1.

how The tool had already been corrected once the same day, for stripping markdown from one side and not the other — 201 down to 71 — and the lesson was taken as «fold both sides the same way» rather than «this comparison is the fragile part and will break again». One normalisation bug found is evidence of a normalisation-shaped surface, not of one bug.

The lesson. A MEASUREMENT PUBLISHED AS A BACKLOG IS A CLAIM, and this one was made twice from the same faulty comparison and corrected twice. What survived both corrections is what mattered: the errands page rendering none of its 46 stakes lines, Hannah's mother's death registration on no page, and now Catherine Sneyd's. Those were found by the tool when it was wrong by 130 and when it was wrong by 47, because a real absence survives a bad comparison and a false one does not. THE FINDINGS WERE NEVER THE FRAGILE PART. THE COUNT WAS, AND THE COUNT IS WHAT GOT PUBLISHED.

Where it was corrected →

27 September 2026

was Published, and told David, that «George Pitt D'Arcy died at Parramatta in 1849 and this archive has never searched for a notice». His obituary has been in this archive's own register the whole time — The Sydney Morning Herald, 1849, with the Trove article id beside it. Written in the same hour as a message to a neighbouring archive about checking a claim before making it.

now `person-records.json` carries it under george-pitt-d-arcy-1783: «obituary · died Parramatta 22 Jul 1849, aged 69 · verdict "gout which had flown to the head"», source «Trove, Australian newspapers», link nla.news-article59769271. It was found on the Trove website long before any API key existed, which is exactly why it did not come to mind while reasoning about what the key had just unlocked.

how The holdings data was genuinely new and the pleasure of it did the thinking. «675 issues survive and nobody has looked» is a better sentence than «675 issues survive, and the one thing we wanted from them we already had», so the better sentence got written and the register was never asked. This archive has a tool for exactly this — crossread.py, built in September after Constantine D'Arcy sat published on one page while three others called him unplaced — and it was not run.

The lesson. THE ARCHIVE IS THE FIRST SOURCE TO SEARCH AND IT IS THE ONE THAT GETS SKIPPED. Four times today an instrument returned a zero that meant the wrong question; this is the same shape with no instrument involved, and the register was one grep away. It also matters WHO it was said to: the claim went into a coverage note, into a commit message, and into a report to David, inside an hour of telling another archive that being the party doing the correcting is not evidence. THAT SENTENCE APPLIES TO THE ONE WRITING IT. The finding survives — the holdings are real and an absence across 675 issues is now quotable — but it buys something smaller than was claimed.

Where it was corrected →

27 September 2026

was Told a neighbouring session, flatly and while correcting them, that this archive's kit pin was 2790d85 and not the 8ec58e6 they had read — and advised them to re-check every pin in the estate on the strength of it. They were right. The pin is 8ec58e6. They re-read all ten repositories from both disk and git HEAD before answering.

now Commit 329d58e did set 2790d85 and this archive made it deliberately, which is the whole of why it was remembered. Four commits later `fadb87c` — «A relationship no chart should draw, gated», a session gating a chart that had drawn a two-year-old boy with a wife — moved the pin to 8ec58e6 as a side effect of a commit about something else entirely. This archive then built on top of it three times without noticing.

how The pin was asserted from the memory of having set it rather than read from the file, and it was asserted at the one moment that guarantees it travels: inside a correction issued to somebody else. Being the party doing the correcting is not evidence, and a fact that is one `grep` from certain should never be recalled.

The lesson. THE BUILD HAD BEEN PRINTING IT ALL ALONG. Every run of this archive's gate chain prints «ok pin kit <sha> installed and pinned», and three runs printed 8ec58e6 while this session believed 2790d85. That is the second time in one day the answer was on screen and unread — own error 45 was two page counts disagreeing in a single run, both green. THE PATTERN IS NOT THAT THE INSTRUMENT IS SILENT; IT IS THAT A LINE READING «ok» DOES NOT GET READ. And the neighbouring session's half of this is worth keeping too: a pin that moves inside a commit about something else is invisible to the person who moved it, and to everyone downstream.

Where it was corrected →

27 September 2026

was The spine — the page that draws this archive's own descent — badged the six generations above the Hornby graft «Inferred». Their own person pages badge them «Disputed», and /how-far-back calls the link that reaches them a single unevidenced one. Seven pages, two answers, and the spine was the credulous one.

now `chip()` on /direct-line read a hand-kept table of seven graded people and fell back to the literal "unproven" for everyone else, which the shared Evidence component folds to «Inferred». Eight of the fifteen badges on the page were that fallback. Six were Hornby: Thomas Darcy, Conyers of Hornby Castle, the 1st and 2nd Earls of Holderness, John Darcy Lord Conyers and Robert Darcy — every one of them carrying `graft: "Hornby"` in provenance.json, which is what makes their own pages say disputed. The other two were the living pair at the foot of the line, badged for nothing.

how The vocabulary on that page predates the ladder the seven archives now share, and the page even says so in a comment — it explains that "unproven" folds to "inferred" so the words match everywhere else. That comment is about wording. It never asked whether the FALLBACK was true, and a fallback is an assertion: «inferred» says this archive drew an inference. About these six it drew none; it has an entry for neither.

The lesson. AN UNKNOWN MUST NOT FALL BACK TO A GRADE. Every level on the ladder is a claim, so there is no safe default among them — the only honest fallback is the one that computes the answer, or one that says no answer was given. The fallback is now `grade()` itself, which reads provenance.json and the graft list and is total; confidence.json still wins where it has a row, because those seven carry a written reason that cannot be computed. And it was not found by looking: a neighbouring session wrote to say the kit had been resolving unrecognised values to «Family», which is the same fault one layer along. THE CHECK THAT FOUND IT WAS APPLYING SOMEBODY ELSE'S CORRECTION TO MY OWN CODE — and that session later read this page and credited the find to me as having preceded their message, which is the wrong way round and is corrected here rather than accepted. The same session then put the principle better than this entry first did: the kit's AncChart resolves an unknown to NEUTRAL GREY and its Evidence component resolved one to «Family» — same component family, same author, opposite instincts — and the difference is that GREY IS NOT A CLAIM AND A GRADE IS. Where a fallback cannot be avoided it should land on something that asserts nothing; where it can, it should be a total function and no fallback at all.

Where it was corrected →

27 September 2026

was Published FreeBMD as «unusable — returns the results-page furniture with NO RESULT ROWS for every query», and kept that verdict for a week. FreeBMD works. The search had never been run: the button that was pressed belongs to a different box.

now FreeBMD's Find control is an IMAGE button — `<input type="image" name="find" src="/btnFindLg.gif">` — and carries no text at all. The only submits on the page that carry text are «Find Additional» and «View Saved», and both belong to the saved-search panel further down. Pressing one returns a page with the full results header, the transcription warnings, the key to the symbols, and the line «You must supply the name of a file containing a saved search». Run against the real button, SMITH marriages in the Bristol district in 1852 return a full table, every quarter marked >99% transcribed — and the search this archive wanted returned James Sanigar at 6a 155 in under a minute, free.

how A page was read for text and the control was a picture. Every tool this archive uses to drive a browser reports what it can name, an unlabelled image is nameless, and the two buttons that DID have names were the wrong ones. The failure then dressed itself convincingly: the error line sits below the results furniture, so the page looks like a search that found nothing rather than a search that never happened.

The lesson. THE COST WAS PAID IN THE WRONG CURRENCY. A week of this question went to FindMyPast, which put eleven results behind an account this archive will not open, while the free index that answers it in one query sat marked unusable in the coverage table on the strength of an untested verdict. A control proves a source CAN answer; it does not prove the button was pressed. So the rule gains a clause: before recording a source as broken, show the query returning something — anything — and if it cannot, say the search failed rather than the source did.

Where it was corrected →

27 September 2026

was Wrote a module on 22 September to make every gate grade the build the operator just made, published its docstring as the account of that fault — and left one caller able to defeat it. That caller was the living-person check, on the one rule in this archive that is absolute.

now `tools/outdir.py` was wired into `check_living.py` as an argparse DEFAULT: `ap.add_argument("--dist", default=DIST)`. A default is consulted only when the flag is ABSENT, and `site/package.json` passes `--dist dist` explicitly. So with ARCHIVE_OUT set, every other gate read the new build and this one read the shared `dist` — four days old, 848 pages against 854. It checked 6 fewer pages and 14 fewer names for living-person leakage, found none, and wrote «ok». It also wrote that stale page count into `living.json`, the published file that documents the rule.

how The kit had the same fault and fixed it properly, with `a.dist = _outdir.resolve(a.dist)` AFTER parsing — the environment overriding the flag. This archive read the fix, agreed with it, and implemented the intent rather than the mechanism. A default looks like a rule in the line above it and is not one, and nothing about the code's appearance says so: the variable is named DIST, it holds the right directory, and it is simply never consulted.

The lesson. A CONTROL THAT CANNOT FAIL IS NOT A CONTROL, and the form it took here is that A DEFAULT IS NOT A RULE. The tell was available and went unread for four days: the kit's gate said 858 pages in the same run where this one said 852, and two numbers for one build is the exact signature this module was written to remove — it is in its own docstring. Nobody compared the two lines because both said ok. The check now prints which directory it read whenever the variable is set, so a split verdict is visible without having to notice a discrepancy between two tallies nobody was adding up.

Where it was corrected →

22 September 2026

was Spent nine days, one enquiry and three errands waiting for the father's name on an 1828 marriage entry. English marriage registers did not record fathers until 1837. There has never been a line on that document to wait for.

now Bristol Archives read the register and answered every question the enquiry asked: «records from this time do not list fathers' names, nor abodes, ages, conditions or occupations». Of the seven things asked for, five are not in the record class at all. What is there — by banns, and two witnesses — is what a 1754-to-1837 entry holds, and this archive had read dozens of them.

how Errand 8 wrote the reasoning down: «a Gloucestershire marriage entry names the father, AS HIS SON'S DID IN 1871». The son's named a father because it is of 1871. A true observation about one document was carried back forty-three years into a different record class, and once it was in an errand it was quoted by two more errands and a page without anybody asking where it came from.

The lesson. The archive's own pages hold the refutation: /thomas-sinegar prints the 1871 entry with its father column and the 1828 entry without one, side by side, and has since the day both were found. NOTHING WAS MISSING. The evidence for a wrong belief was already published under the belief. A premise that arrived as a comparison — as HIS SON'S DID — should have carried the date of the thing compared, because that date was the whole difference. And the cost of the fault is not the nine days; it is that a fee was nearly paid, and an errand marked THE STRONGEST INFERENCE HERE, for a document that cannot speak to it.

Where it was corrected →

22 September 2026

was Published SANIGRE as the spelling of Thomas's marriage, called it «the twenty-fifth form of this surname put to one index, the only one that carries this entry», and said it was «confirmed on FindMyPast». The register reads SANIGAR. There was no confirmation.

now England Marriages 1538-1973 is the FamilySearch transcription, and FindMyPast serves that same transcription under the same name. Reading it in two windows is not two readings. The one reading anybody has taken from the register itself is Bristol Archives', on 22 September, and it says SANIGAR — the second commonest form in this archive's own table, in it from the start.

how The two sites look like two sources: different companies, different search forms, different result pages, a fee on one of them. This archive has a rule for exactly this and applies it to censuses — an index is a reading of a document and carries its reader's errors — and did not apply it here, because the spelling was interesting. A form that appears nowhere else made a better paragraph than a form that appears everywhere.

The lesson. NEITHER SPELLING IS ASSERTED HERE NOW. Bristol's is a reading and FamilySearch's is a reading, the image is behind an account this archive will not open, and what is documented is that they disagree. The check is mechanical and was skipped: before calling two records agreement, ask who transcribed each. And a detail that makes the story better is the one to doubt first — this is the second correction in two days where the interesting reading was the wrong one.

Where it was corrected →

21 September 2026

was Wrote a script to stop this archive's build without touching any other archive on the machine, published what it did in a commit message, recommended it to two neighbouring sessions — and never ran it. Run against a live build it selected NOTHING.

now It matched `pgrep -f "$ROOT/"`, on the reasoning that every node process carries its own absolute path in its command line. That is true of node and false of everything else in a build: `bash ./build.sh` is a RELATIVE path and carries no root at all, and neither does `npm run build` nor the `sh -c` wrapper beneath it. Forty seconds into a build, before any astro process exists, there is nothing for it to match. The one pattern it would eventually catch is the one that was never the problem.

how It was written in the same hour as a correction about a bare `pkill` reaping every archive on this machine, and it looked right — the argument for it was sound and the argument was the only thing that was ever checked. A neighbouring session then tested THEIR version of it against four archives building at once, which is the only test worth running for a tool whose whole job is not to touch the other three, and mentioned doing so. That is why this one was tested at all.

The lesson. Selecting on the WORKING DIRECTORY works where the command line does not: every process in a build — the script, npm, the sh wrapper, node, esbuild — has a cwd inside the repository whatever its command line says. Verified against four archives building simultaneously: it took this archive's five and left The Geneology Map's astro and esbuild, Falco's shells and Defranceski's alone. It also has to skip its own shell and every parent of it, because their cwd is this repository too and killing them takes the caller down with the build it asked to stop. THE PATTERN IS THE ONE THIS ARCHIVE SPENT THE DAY NAMING, in the tool built to serve it: an instrument can be working perfectly and be pointed at something else. And the three faults found this way — this, the exit trap reporting a clean pass over a killed build, and a stale-index check asked about the file it does not read — were none of them found by measurement. Measurement only ever checks the thing you already doubted.

Where it was corrected →

21 September 2026

was Put BERKELEY — the place this whole archive is about — in a field in Leicestershire, with six of its people on it, and marked the pin EXACT. Twenty other places are on the same point, among them London, Portsmouth, Somerset, Clarkenwell, Theobalds Palace and St James Palace.

now The point is 52.53102, -1.26491. It is not a mistake about Berkeley; it is the geocode for the word ENGLAND, which sits near the geographic centre of the country. Twenty-one places share it and carry thirty-four people between them. The same thing happens one level down: five places sit on the QUEENSLAND centroid, five on GLOUCESTERSHIRE — Wotton-under-Edge, where Lydia was born, among them — and four on STAFFORDSHIRE. In all, 36 pins are a broader place's coordinate wearing a narrower place's name, and 30 of those are stamped `fix: "exact"`.

how A gazetteer that cannot find a town does not say so. It answers with the smallest thing it did recognise, which for a damaged export string is usually the country at the end of it — and the field that records confidence is set by whether the LOOKUP succeeded, not by whether it answered the question asked. So a failed search for «Christened in Berkeley» returns England, at full precision, with no flag on it anywhere. Nothing about the result distinguishes a town that was found from a country that was settled for.

The lesson. THIS ARCHIVE HAD ALREADY WRITTEN THE RULE AND THEN RAN IT IN ONE DIRECTION ONLY. A comment in tools/atlas.py explains why three hand-documented hamlets are deliberately left off the map: «Wanswell, Hinton and Blakeney were tried and every one of them fell back to its parish's point — three pins on Berkeley and one on Awre, all stamped exact by a gazetteer that had simply not heard of them. That is false precision, and a map that claims it is worse than a map that omits them.» That test was applied to the nine places being added by hand and never once to the hundred and fifty-six already there. It is the same shape as the spelling table a fortnight later: a standard written down, honoured where it was being written, and not turned around to face the existing data. AND IT WAS NOT FOUND BY LOOKING. A neighbouring archive built a graves layer over this map, noticed its burial counts were being multiplied because twenty place-heads appear more than once, and said so. Grouping by head is what they needed; grouping by COORDINATE is what found this. check_atlas.py now refuses any build in which a place stamped exact sits on a coordinate belonging to a place that contains it. AND THE GATE THAT ALREADY EXISTED IS NOT WRONG NOT TO HAVE CAUGHT IT. The shared kit’s checkplaces.py is a WRONG-COUNTRY test, written after an island ended up nine thousand kilometres away in the Philippines. An inherited pin is in the right country at the wrong precision and passes it cleanly. Two orthogonal faults, and a reader counting thirty-six of these would otherwise wonder how a place check let them through. A neighbouring archive ran this test on its own map the same afternoon and found zero inherited pins — but two places genuinely sharing a point, a farm on its nearest town and a district on a town, both flagged approx. Which sharpens the rule better than this archive had it: THE FAULT IS NOT SHARING A COORDINATE, IT IS SHARING ONE WHILE CLAIMING TO BE EXACT. A farm pinned on its nearest town and saying “about here” is telling the truth about what it knows.

Where it was corrected →

21 September 2026

was Published “None, in any spelling” for Sanigers at Chew Magna, with a control beside it, and called the parish closed. There are two of them in the parish register, and one of them answers a question this archive had open.

now Somerset Baptisms holds CHARLES SINAGAR, baptised at Chew Magna in 1816, and WILLIAM SINEGAR, baptised there in 1822 — both children of SIMON and ELIZABETH. Elizabeth Saniger, widow, 60, born Chew Magna, was already on this site, living with her son William Saniger, 27, born Chew Magna, at Oxford Road in Bristol in 1851. The register names her husband and this archive had been calling him nobody.

how IT WAS NEVER A SPELLING PROBLEM, which is what made it invisible. SINEGAR was one of the eight forms in use on the day that null was written, and a plain search for SINEGAR at Chew Magna returns the 1822 baptism on its own. So the query that was run cannot have been the query that was recorded — a place mistyped, a category narrowed, or a page read before it had rendered, which this archive documented as a fault the day before. And the control passed, because the control was a DIFFERENT query at a different place. A control at Berkeley proves the site is working. It cannot prove that the Chew Magna page finished loading.

The lesson. The tightened rule said a control must run in the same session and the same query shape and return rows. All three held here and the null was still false, because «the same shape» silently means «a different value in one field» — and the one field that was different is the one that failed. Where a query can be re-run with a WILDCARD instead of a spelling, the wildcard is the control, because it cannot miss for the reason a list can: `S*N*G*R` at Chew Magna returns four records and two of them are this name. check_controls.py now refuses any new FindMyPast null whose own text claims «any spelling» or «every spelling» without a wildcard in it, and the two rows that failed that check on the day it was written were this one and the Berkeley marriage sweep — both of which have now been re-run.

Where it was corrected →

21 September 2026

was Recounted this surname's spelling table on one stated basis, published it as complete — «24 spellings tried, 19 productive» — and left out SANIGRE. /searched went on saying, in a row written the same day the marriage was found, that Thomas Sinegar's marriage was “Not found, in any spelling, anywhere in Gloucestershire between 1822 and 1838.”

now SANIGRE is the form that carries it. Thomas Sanigre married Martha, Bristol, 1828 — one result in the whole of England Marriages 1538-1973, asked nationally. It is not a new find: /thomas-sinegar has carried it since 13 September and names it there in so many words, «SANIGRE, which hid her brother's marriage». The table rebuilt eight days later did not have it, and the null row beside it was never withdrawn.

how The recount was drawn from this archive's own spelling table, and that table is a list of forms seen in BAPTISM registers. SANIGRE has never appeared in one — it returns nought in England Births & Baptisms, against 158 for SANIGER asked the same way in the same session. So the form was invisible to the source the recount used, while being the single most consequential spelling in the archive. A sweep that takes its list of questions from one set inherits that set's blind spots and reports them as completeness.

The lesson. The archive had already written the rule for this and then broke it in the other direction. On 20 September it refused to add SANIGOR and SYNIGAR to a table counted on a different basis, because mixing bases quietly is a fault; the fix was to recount everything on one basis. That was right, and it cost a spelling — because «one basis» silently became «one basis decides which questions get asked». SANIGRE is now in the table AT NOUGHT, with the reason beside it, which is the only honest place for a form that is empty in one set and decisive in another. The null on /searched is corrected rather than deleted, and the wording is in retired.json so it cannot return. AND THE REAL FIX IS NOT A LONGER LIST. The surname box on this site takes wildcards, and `S*N*G*` asked of Gloucestershire marriages for 1827-1829 returns the Sanigre entry in one query — along with a second thing no list would have shown, one Rodborough marriage of 1827 indexed as both SANIGER and SANIGOR. A spelling list is a guess about a clerk. A wildcard is not, and it costs only strangers, which can be read and discarded. Where a question has a place and a decade, the wildcard is now the first search here.

Where it was corrected →

21 September 2026

was Published “371 baptisms between 1565 and 1909” as the headline of the spelling table, on two pages, having counted 371 rows of a search result.

now 371 is a count of index entries. The five largest forms were read row by row on 21 September: SANIGER's 158 entries are 121 baptisms, SANIGAR's 56 are 45, SAINGER's 30 are 29, SINEGAR's 28 are 27, SINNEGAR's 26 are 26. Two more baptisms appear under two spellings each. TWO HUNDRED AND NINETY-EIGHT ENTRIES ARE 246 BAPTISMS — one row in six is a repeat.

how The set transcribes parish registers AND bishops' transcripts, and some parishes twice over, so one christening can hold four rows: Mary, daughter of Samuell, is indexed four times at Berkeley in 1688. The page's own fine print said so — «this page counts index entries, not children» — while its lede, its dek and the sentence on /sanigers all said baptisms. The unit was correct everywhere except where it was published.

The lesson. The duplication is not uniform, and that is what makes the corrected number worth having rather than just smaller. It is almost entirely in SANIGER and SANIGAR, whose parishes were typed up more than once; SINNEGAR repeats not at all. So an entry count measures how often a parish was transcribed as much as how often a name was written — which is the opposite of what a spelling table is for. An earlier pass had already measured SANIGER at 125 distinct name-year-place strings; that is confirmed, and refined to 121 once Edw and Edward, Wm and William, Jos and Joseph are read as the same man. The remaining 73 entries across 20 small forms have not been counted this way yet, and the page says so.

Where it was corrected →

21 September 2026

was Told every reader of /about — the page that asks to be trusted — that “Living people are not published at all. Not hidden, not gated — absent from the build.” And said it in the FOOTER OF ALL 874 PAGES, where it went further: “Living people are excluded from this build entirely — not their dates and not their names. That is stricter than the estate rule, which names them and gives nothing else.”

now Six living people are named on this site, deliberately: three as the authors of Ken D'Arcy's eulogy, two in the sentence that explains why this archive exists, and one on /bloodline as the living generation the direct line runs down to. Each is listed in living.json with the owner's recorded confirmation. The rule is real and strong — no person page, no birth year, no birthplace, and no name where it would appear as somebody's spouse, parent or child — but it is not what that sentence said.

how The exception was recorded honestly in living.json, where namedNote says the six are named «as sources and as provenance, rather than as tree records». The prose on the page was written from the rule and never re-read against the data beside it. The gate could not catch it either, because it runs under the «named-bare» policy, which permits exactly what the six are — so the check passed every build while the page overstated what the check was checking.

The lesson. Found on 21 September by a peer session's remark about a different policy, which prompted a run under «absent»: it reports eleven leaks and every one of them is one of the six. A claim about an archive's own practice is a claim like any other and should be graded like one. This one was safe to make because the underlying rule is strict — which is the danger: an overclaim in the direction of MORE rigour reads as reassurance and nobody checks it. THE FIRST FIX WAS ALSO TOO SMALL. Correcting the sentence on /about left the same claim standing in the site footer and on the home page, because the first search was for the wording that had been found rather than for every statement of the rule. A sweep for any sentence about the living then turned up three separate regimes being promised: absence in the footer, absence on the home page, and «named and nothing more» on /bloodline, which was the only accurate one. All three now say the same thing, and both retired wordings are in retired.json so they cannot come back. AND THE FIX AFTER THAT WAS STILL NOT RIGHT. Correcting the footer, it typed the word «Six» — an hour after recording that six of this archive's thirty-six errors are numbers typed instead of counted, and in the single most-published sentence on the site. /about's stats strip also still read «2,034 living people, none of them here», a fourth instance the sweep for wordings had missed because it is a template expression and not prose. Both are derived from living.json now, proved by adding a seventh row and watching the footer and the strip both read seven, and read six again when it was removed. A peer session put the general form of it better than this archive had: a claim that is FALSE and unchecked announces itself eventually; a claim that is TRUE and unchecked does not, and goes false silently on the day the data moves.

Where it was corrected →

20 September 2026

was Published “170 distinct catalogue records, 160 of them Berkeley Castle” from a sweep of The National Archives' Discovery API. The true figures are 193 and 183.

now The tool written for that sweep stopped after one page and returned the first hundred records of however many a query had. SWONHUNGRE alone returns 126, so twenty-six of its records were never seen, and the same was true of any term over a hundred.

how Discovery's response carries a field called nextBatchMark, which is exactly what a paging loop looks for, and on this endpoint IT IS ALWAYS EMPTY. The loop read it, found nothing, and stopped — correctly, by its own logic. What made it invisible was that the same response also carries the true `count`, and the tool printed that beside the records it had: “126” in the summary, a hundred records in the file. A truncation that reports the number it is missing is the hardest kind to see.

The lesson. Two days after writing that a null carries the shape of the question that produced it, this archive published a count carrying the shape of a paging bug. The substance survived — every one of the ten non-Berkeley records, which is where the whole value of that sweep lay, was in the first hundred and is unchanged. But it was luck, not method. The tool now uses sps.page, verified by asking for page two of a 232-record query and getting a hundred records none of which were in page one, and it de-duplicates by id so a repeated page cannot inflate a total instead.

Where it was corrected →

20 September 2026

was Published Hannah Saniger's page for weeks with two of its four «written about here» links silently missing — among them her voyage on the General Hewitt, the ship that brought the family to Queensland.

now The map that holds those links, APPEARS_IN in /people/[slug].astro, carried the key «hannah-saniger» twice: once with four links and once with two. In a JavaScript object literal the later entry simply replaces the earlier one.

how It is hand-kept, and it is a plain object with thirty-one keys in no particular order, so a second entry for a name already present looks exactly like an edit to the first. Nothing could tell them apart — not a linter, not a build, not a reader, because a reader sees a list of links and has no way of knowing it is short. She is the direct line, and she lost the most substantial page on it.

The lesson. Found while auditing the other five joins that attach evidence to a person, after the record-row fault of the 17th. The audit expected a second instance of that fault and did not find one: graves.json and households.json do not reach the person page directly, but everything they carry is already there from the family tree. The loss was somewhere nobody was looking, in a data structure whose rules silently permit it. Two of the three checks written that morning were themselves wrong — one could never fail, because it looked for a string that sits in the site navigation, and one reported a grave as missing from a page that states it in full, for want of unescaping an ampersand. Both were caught by trying to make them fail.

Where it was corrected →

17 September 2026

was Printed “No record has been found for them” on the pages of thirty people for whom this archive had read a hundred and thirty records — including Constantine D'Arcy, who has two commissions in the London Gazette, a death notice in the Kentish Gazette, a burial register at Medway Archives and an entry in the Corps roll, and a page of this site written about him.

now One hundred and seventy-six record lines naming fifty-five people in the family tree had been read, graded and published on /register/. Every one of them was dropped before it could reach the person it named.

how build_dossiers.py gathers every person named in a record and gives them a page. Where the family tree also carries the name it skips them — `if e["inTree"]: continue` — on the reasoning that “the rest already have one”. They do have a page. That page never read the records. /people/[slug] is built from provenance.json, which is a hand-kept list of RELATIONSHIP edges and knows nothing of record rows, so a person with six documents and no relationship edge fell through to the sentence written for people with nothing at all. The data was right, the build dropped it silently, and no gate refused. The Mazza archive had the same fault in a different file and the estate landing page caught it there first.

The lesson. An assumption inside a build script is a claim, and claims in this archive carry their evidence. “They already have a page” was never checked against the page. The gate that now refuses this reads register.json — the evidence — and works out who is owed a record; the first version of it read the derived file instead, and when the bug was put back that file emptied and the gate reported “0 of 0, ok”. A control that cannot fail is not a control, and it caught its author out twice in one afternoon.

Where it was corrected →

16 September 2026

was Announced Ann Saniger's 1798 baptism at Berkeley as a new find — “Ann has never had one” — in a block published on the page that had already been carrying her since 13 September.

now She was four blocks further up the same page, in the table of John Saniger's children, as ANN SANIGAR 1798. One vowel apart, the same index entry, on the same screen.

how I opened a record set that named fathers, read the first page of twenty, recognised a name the family tree asserts, and wrote it up against the tree instead of against this archive. The whole point of that page is that this surname is spelled eleven ways; having just written that sentence, I failed to apply it to my own page's contents. Reading the index took an hour; reading the page I was appending to would have taken a minute.

The lesson. Check the page before you add to the page. A find is only a find against what is already published, and an archive that indexes eleven spellings of a name has to search its own text the same way it searches somebody else's.

Where it was corrected →

15 September 2026

was Invented a “Forest side of the family” at AWRE and BLAKENEY, and then built on it — two errands, four coverage rows, an atlas point, and three work-list items, all describing how to reach Sanigers in the Forest of Dean.

now There is no documented Saniger at Awre or Blakeney anywhere in this archive, and never has been. The 1608 muster puts all eleven men of the surname at HALMORE, HINTON and SANIGER in Berkeley, at Wotton-under-Edge, at Woodmancote in Dursley parish, at Dursley itself, at Paganhill in Stroud, and at Alkerton, Kings Stanley and Oxlynch in Stonehouse — the Vale and the Cotswold edge, and not once across the Severn. Rudder mentions Awre 194 times and names no Saniger in the whole book. Bigland's second volume mentions Awre 172 times and Blakeney 4, and names no Saniger at all, while his first volume gives twenty at Berkeley.

how I wrote it into a work-list note in the morning — “Saniger of Awre/Blakeney is exactly the sort of name it prints” — as a throwaway justification for opening a journal. Nothing checked it, because it was mine rather than a source's, and for the rest of the day I read it back as though the archive had told me. By evening it had produced an errand asking Gloucestershire Archives for a run of court rolls from 1387 to 1881, on the strength of a phrase I had made up before lunch.

The lesson. The archive's own rule caught its author out: a claim needs a source named beside it, and that applies hardest to the claims that arrive as background rather than as findings. A premise smuggled in through a to-do list is never graded, never gets a chip, and is never read against anything. It also shows what the control habit is actually worth — the null that exposed this was BIGLAND'S SECOND VOLUME, 172 mentions of Awre and not one of this surname, which is only meaningful because the mention count was taken.

Where it was corrected →

15 September 2026

was Published “Eleven men, four spellings” from the 1608 muster, and named the man living in the hamlet the surname came from JOHN SAINGER — the headline of the whole page, since his name and his address were nearly the same word.

now There are three spellings, and his name is JOHN SANIGER — identical to his address. Gloucestershire Notes & Queries reviewed Maclean's 1902 edition as it appeared and listed its misreadings: “occasionally marred by errors which the editor, whose name is not indicated, ought not to have passed. Thus SAINGER SHOULD READ SANIGER, and probably seiuger is seivyer; the grotesque Grisseote Cliste should be Greffeote Clifte; Cidolls is probably a blunder for Eidolls; Jugley is probably Ingley; Poutinge is doubtless Pontinge; Slinchcombe should be Stinchcombe; and Stimbridge, Slimbridge.”

how The page named its source honestly — “the searchable transcript used here was built from the 1902 edition” — and then treated that edition as the manuscript. A printed text is a reading of a document, not the document, and this one had a reviewer going through its errors within the year. I had searched for what the muster said and never asked what anybody thought of the book it was printed in.

The lesson. When an archive rests on one printed edition, the cheapest next source is not another archive — it is the review of that edition. Somebody with the manuscript in reach has usually already checked it. SAINGER is still a real form of this surname, attested 44 times in the Berkeley registers; it is simply not a 1608 one.

Where it was corrected →

15 September 2026

was Ran the three Sussex sisters through FreeCEN, found nothing, and recorded it as a NULL — “control: SMITH in Sussex 1861 returns the display cap of 1,000, and the six Darcys are themselves enumerated in Brighton, so the county and the town are both covered”.

now The county and the town are not the unit. FreeCEN's Sussex 1851 returns NOUGHT for the surname ARCY — and this archive has the three sisters in the 1851 Sussex census under exactly that surname, at HO107/1646 folio 357 page 59 schedule 172, 22 Western Cottages, Brighton. The piece is simply not in FreeCEN. Smith hits the 1,000-row display cap in 1851, 1861 and 1871 alike, which conceals the gap rather than measuring it.

how I used a common surname as a coverage test, which measures how much a database holds and not whether it holds the thing being looked for. Worse, the cap meant the number could not go up: 1,000 was the ceiling, so it would have looked identical whether Sussex were half-transcribed or whole.

The lesson. Test an index with a record you already know is in it. This archive had one — the sisters in 1851 — and using it took one query and turned a null into an empty. A control that cannot fail is not a control.

Where it was corrected →

15 September 2026

was Printed two different dates for Robert D'Arcy's first commission and never noticed. The timeline, /hornby and three other pages said 1776, from Connolly's Roll. /the-corps said 1778, from a commercial index of the commission registers, and called it “his first commission, and now the earliest record of him anywhere in this archive”.

now 17 JANUARY 1776. The printed Army List of 1781 interleaves each engineer with his seniority date: “Wm. Kesterman 17 Jan. 76 · John Johnson do. · Charles Holloway do. · Thomas Whelpdale do. · John Humfrey do. · James Fiddes do. · Richard Hockings do. · Robert Beatson do. · ROBERT D'ARCY do. · Benjamin Slack 4 Mar.” The men after him break the ditto with their own later dates, which is what makes the chain readable. The 1778 list carries the same run, and Connolly agrees on the year.

how Two numbers for one event sat on two pages for weeks, and the page that was wrong was the one that sounded most authoritative — it named a record series and claimed a superlative. Nothing in the build checks that a date on one page matches the same date on another, and the archive's own cross-reading tool was run against open questions, never against its own figures.

The lesson. When two pages give different dates for one event, that is a finding, not a typo — and it is findable without any new source. The fix that generalises is not this correction; it is that a free contemporary printed list settled in ten minutes what a paid index had got wrong, and neither page had ever been read against the other.

Where it was corrected →

15 September 2026

was Called Robert D'Arcy's career “a blank of twenty-four years” between 1778 and 1802, and said two Barbados christenings were “the only two records that fall inside it”.

now The Corps published its own history in 1889. Whitworth Porter puts Lieutenant Robert D'Arcy at the siege of Fort St Philip's on Minorca in 1781 — three years after the commission, squarely inside the blank — and carries “Robert D'Arcy, Barbados” in a station list, so the posting this archive had inferred from a baptism register was stated outright by the Corps all along. Porter also has him Commanding Engineer at Copenhagen in 1807 and Commanding Royal Engineer at Walcheren in 1809.

how I wrote a sentence about every record that exists after searching the records I happened to have. The book that disproved it is out of copyright, free, full-text searchable, and is the official history of the very corps the page is about — the first place anyone would look, and I had not looked.

The lesson. This is the same error as the Hampshire Chronicle, five weeks later and with the same shape: “the only records that fall inside it” is a claim about everything ever written, and it cost nothing to say “the only two this archive has found”. When a page is about an institution, read that institution's own published history before describing a gap in it.

Where it was corrected →

15 September 2026

was Announced the Morning Herald notice of 1843 as “the first record anywhere to give Robert D'Arcy a corps as well as a rank”. Two older papers had already done it — and the second of them turned up within an hour of my correcting the first.

now The Hampshire Chronicle of 24 March 1823 carries Jean Ward's death: “At Chatham, MRS. D'ARCY, THE WIFE OF MAJOR-GEN. D'ARCY, OF THE ROYAL ENGINEERS.” And the Oxford University and City Herald of 1 November 1806 carries Margaret's own wedding: “MISS D'ARCY, ELDEST DAUGHTER OF COL. D'ARCY, OF THE ROYAL ENGINEERS” — thirty-seven years before the notice I called the first, in the report of the very marriage that page is about.

how I had the find of the fortnight and reached for the strongest sentence available instead of the true one. “The only record anywhere” is a claim about every newspaper ever printed, made after searching a handful — and this one turned up in the British Newspaper Archive, which I had already been searching for other things, the very next day.

The lesson. Say what was searched, not what exists. “The earliest this archive has found” costs nothing and cannot be falsified by tomorrow's search; “the first record anywhere” was falsified twice in one day, the second time by a notice about the very event the page was built on.

Where it was corrected →

14 September 2026

was Wrote that Martha Wakefield “may never have existed” and that she was “not in the family tree either”, after searching for her in Bristol. She is in the tree, with a death date, a cemetery and a plot number — in Queensland.

now The tree gives Martha Wakefield 1836–1899, died 23 April 1899 at Maryborough, Queensland, buried Maryborough Cemetery, Plot Monumental L, Grave 410, and cites its source as “Martha HURFORD (born Wakefield)”. The free Queensland death index confirms a Martha Hurford dying on exactly that date — and names her parents as JOHN Wakefield and a HUGHES, not James Wakefield and Hannah Saniger. So she was real, she was not this family's, and none of that required leaving the desk.

how I searched the country the family came FROM for a woman the archive's own data said died in the country they went TO, under a maiden name she had not used for a decade. Then I published the failure as a finding about her existence.

The lesson. Before searching for somebody, read everything your own files already say about them — especially where and when they died and what they were called by then. A negative result is only evidence if the search could have succeeded.

Where it was corrected →

14 September 2026

was Spent a fortnight calling Constantine D'Arcy unplaced while this archive was publishing his christening, his parents' names and both his commissions on another page.

now Constantine Darcy was christened at St Michael, Barbados on 18 February 1786, father Robert Darcy, mother Jane. That is on /hornby, with the film and batch number, and it has been since the Royal Engineers work of this summer. His sister Jane, christened in the same parish in 1788, is on the same source and the same page. Meanwhile /robert-family listed “Who Constantine was” as an open question, /chatham said his relationship to Robert “has never been established”, and /the-corps displayed a twenty-four-year blank in Robert's career without noticing that two of Robert's children were christened inside it.

how Pages were written one at a time, each carefully sourced, and nobody ever read them against each other. The archive grew faster than its own index. A search tool that would have caught this in one query has been on the site for weeks and I did not use it on my own material.

The lesson. Search your own archive before you search anybody else's. A fact you have already published and not cross-read is worse than a fact you never had, because it makes you confident about the wrong things.

Where it was corrected →

14 September 2026

was Published a nationality audit eleven times over three weeks without ever writing the classifier down.

now The figure was a regular expression I retyped from memory on each pass, and it drifted. Sources moved between the Australian and British columns for reasons that had nothing to do with new records, and the percentages I reported to the reader were therefore approximations of varying quality.

how It was quick to hand-write and it felt like arithmetic rather than method. It is method: the audit is an argument this archive makes about itself, and an argument whose measuring instrument changes shape between readings is not one.

The lesson. If a number is worth publishing repeatedly, the thing that computes it is worth committing. tools/audit.py now runs as part of every build.

Where it was corrected →

13 September 2026

was Declared Hannah Saniger's baptism missing from every reachable index — twice, on two separate days, each time with a control test behind it.

now HANNAH SANIGOR, baptised at Berkeley on 18 August 1804, father JNO SANIGOR. It is in the same FamilySearch index that produced her brothers, and it is on FindMyPast too.

how This site keeps an alias list of surname spellings — eleven forms of Saniger — and SANIGOR was not one of them. Every “not found” I published was really “not found under the ten spellings I thought of”. The control tests were sound and they were testing the wrong thing: they measured whether the parish was covered, never whether my query could match the name.

The lesson. A control test proves the source covers the place. It proves nothing about whether your search string can reach the record. Widen the name before you narrow the conclusion.

Where it was corrected →

13 September 2026

was Named a Martha Wakefield, born about 1836, as one of three daughters left behind when the family sailed in 1854 — on five pages.

now Two of the three died as children: Eliza at nineteen months in 1834, Ellen at five in 1840, both with Bristol baptisms naming James and Hannah. The third produces no birth registration, no baptism and no burial at Bristol under any spelling — because she is not from Bristol. THE CLAUSE “and is not in the family tree” WHICH STOOD HERE UNTIL 14 SEPTEMBER WAS FALSE: she is in it, and it says she died in Queensland. See the entry of 14 September.

how The trio was assembled in an early pass and then repeated, and the repetition did the work that evidence should have. Nobody — me — ever went back to ask where the name had come from.

The lesson. A fact that has been on the site longest is the one least likely to have been checked. Repetition is not corroboration.

Where it was corrected →

13 September 2026

was Reported on several pages that South Leith was not transcribed and that Jean Ward's baptism was therefore out of reach.

now It is indexed, with parents named. Jean Ward, baptised South Leith 19 July 1754, father JOSEPH WARD, mother MARTHA GARDEN — an entire Scottish generation this archive did not have.

how The same fault as Berkeley, on the same afternoon: the free indexes were measured honestly and the conclusion was then widened from “not reachable here” to “not transcribed”, which is a claim about the world rather than about my sources.

The lesson. Name the shelf. “Not in FreeREG” and “not transcribed” are different sentences, and only one of them is true.

Where it was corrected →

13 September 2026

was Announced Jabez and Zillah Wakefield as “two children nobody here had ever heard of”, found in the 1851 census.

now Both are on the General Hewitt passenger register, which this archive transcribed and published in July, together with an Ephraim aged five. They sailed with their parents, married in Queensland in 1863 and 1871, and Jabez was buried there in 1903.

how I checked the finding against the family tree, which does not have them, and not against this archive's own pages, which do. The manifest was three clicks away and I had written the page it sits on.

The lesson. Check a discovery against what the archive already holds before calling it new. The tree is not the archive.

Where it was corrected →

13 September 2026

was Built three days of research, two new pages and the top of the errand list on the claim that Hannah Saniger was not born in Gloucestershire.

now The 1851 census, taken at Drivers Fields in the same house as the 1841 one, gives her birth town as BERKELEY and her birth county as GLOUCESTERSHIRE — which is exactly what the family tree had said from the beginning.

how The whole edifice rested on one tick in the 1841 census: the column that asks only whether a person was born in the same county, yes or no. That is the weakest statement a census makes. I treated it as load-bearing because it was the only thing I had, argued from it for days, excluded 81 households with it, catalogued 36 chapel registers because of it, and built a page for a Somerset parish on the strength of it — without ever putting it beside the next census, which asks WHERE rather than WHETHER and was one search away the entire time.

The lesson. When a single weak datum is carrying an entire line of research, that is the datum to attack first, not the one to build on. And check the same family in the next census before theorising about the last one.

Where it was corrected →

13 September 2026

was Reported repeatedly that the Wakefields could not be found in the 1851 census, and that five of the tree's six Saniger generations at Berkeley could not be tested because the transcript stops in 1677.

now Both are in FindMyPast. The 1851 household is complete, with two children this archive had never heard of, and Berkeley baptisms run straight through the supposed gap with parents named.

how Every null on this site was measured against free indexes. The measuring was right and the conclusion was not: “not reachable from here” quietly became “not there”, which is a statement about a budget rather than about the archives of England.

The lesson. Say which shelf you looked on. An index you have not paid for is not an absence of evidence.

Where it was corrected →

13 September 2026

was Told the reader that the twelve Bristol chapel registers were “digitised, and can be read without leaving the house”.

now All twelve are marked DIGITISED: FALSE in The National Archives' own record details. RG 4 is published through commercial partners, so reading them needs a subscription or a visit.

how I catalogued the pieces carefully — references, dates, denominations, all correct — and then wrote a sentence about access that I had not checked at all. The catalogue lists what a record IS; whether an image exists is a separate field, and I never looked at it until the next pass.

The lesson. Finding a document and being able to read it are two different questions, and an errand list that confuses them wastes the reader's afternoon rather than mine.

Where it was corrected →

13 September 2026

was Published that Chew Magna lay eight miles from Bristol in a parish of roughly 1,800 people, hours after finding it.

now Collinson, writing in 1791, gives “six miles south-west from Bristol … one hundred and seventy houses, and eight hundred and thirty inhabitants”.

how Both numbers were estimates I made while writing the page and did not mark as estimates. Neither was load-bearing, which is exactly why neither got checked — and one of them was propping up a coverage argument about how many register entries the parish should produce.

The lesson. A number written to fill out a sentence is still a number the reader will believe. Either source it or say it is a guess.

Where it was corrected →

13 September 2026

was Treated Portsea as a parish this archive had searched, and read the absence of Joseph D'Arcy's brothers and sisters as though it meant something.

now FreeREG's transcript of Portsea St Mary is twenty-two months long. Five common surnames tested across Hampshire for 1778–1783 return forty-six Portsea entries: all baptisms, twenty in 1780, twenty-five in 1781, one in 1782, and none at all in 1778, 1779 or 1783.

how This site has a rule — establish that a source covers the parish and the window before reporting an absence — and it applied that rule to Berkeley, to Dursley, to Hanley and to eight counties of Sanigers. It never applied it to its own oldest English find. Joseph's baptism was treated as the product of a search when it was the product of a two-year window.

The lesson. Test coverage hardest where the source has already given you something. A hit makes a transcript feel complete, and that is exactly when it is least likely to have been measured.

Where it was corrected →

13 September 2026

was Argued on /berkeley that the archive should stop calling this a Berkeley family — that “of Berkeley” was a label somebody had applied to the whole Vale.

now Saniger is a hamlet in Berkeley parish, in the tithing of Hinton. The Berkeley Castle deeds name people “of Saniger” from before 1291, Bigland writes in 1791 that it was “long held by an old Family of the same Name”, and the older spelling — Swanhanger — is on record from 1377.

how I counted register entries by parish, found 340 at Cam and Dursley against 18 at Berkeley, and let the arithmetic write the conclusion. The counts were right. What they measured was where the family went, not where its name was made, and I never asked whether Saniger was a person or a place.

The lesson. Before you weigh a surname's distribution, find out whether it is a surname. A toponym counted as a surname will always look like it belongs somewhere else.

Where it was corrected →

13 September 2026

was Reported twice in one day that no Samuel Sneyd baptism existed at Madeley for the tree's 1769.

now The Samuel is there, baptised 4 June 1781 — son of William Sneyd, weaver, and Mary Blackbourne, whose thirteen children fill the register between 1769 and 1794. The year 1769 belongs to his eldest brother William, christened three months after the wedding.

how I searched for the tree's DATE instead of the tree's PERSON. The 1781 Samuel appeared in every result list I pulled and I discarded him each time for being twelve years out — while the family he belongs to, with the right father, the right mother and the right trade, was sitting underneath him.

The lesson. A tree's dates are the softest thing in it. When the person fits and only the year is wrong, suspect the year.

Where it was corrected →

13 September 2026

was Said the English origin of this family's Sneyds was “not currently evidenced by anything”, after failing to find two baptisms at Madeley.

now Two of the four links are documented: William Sneyd, weaver, married Mary Blackbourne at Madeley on 27 March 1769; and Samuel Charles Sneyd was baptised at Hanley on 28 April 1811, his father Samuel and mother Elizabeth, exactly as the tree says.

how I searched for baptisms, did not find them, and announced the conclusion — without following up a marriage that was sitting in the same results list, and without ever searching Hanley, the parish the tree plainly names as his birthplace. The negative was published within the hour; the positives took one more query each.

The lesson. A negative is not finished until you have tried the places the claim actually points at. Two absent baptisms are not the same as an unevidenced line, and saying so in public before checking is how an archive overcorrects.

Where it was corrected →

13 September 2026

was Said Miriam Wakefield “married at twenty-one”.

now She married William Hartley Sneyd at Brisbane on 15 November 1859, aged nineteen — Queensland marriage registration 1859/B/255.

how The age was arithmetic from a birth year and an assumed marriage year, and neither the date nor the registration had ever been looked up. The Queensland marriage index is free and this archive has been using it for other people all week.

The lesson. An age you calculated is not a fact you found. If the register that would settle it is one you already have open, look.

Where it was corrected →

13 September 2026

was Reported that five of the six Saniger generations could not be tested, because Berkeley St Mary's transcript stops in 1677.

now They could be tested, three miles away. Dursley St James is transcribed 1577–1951 and Cam St George 1568–1939 — both cover the whole chain, and between them they hold 340 of the 494 Saniger records in the county.

how The coverage of one parish was checked carefully and then treated as the answer to the whole question. The page even said the surname's real centre was Dursley and Cam, and still did not go and look there.

The lesson. Checking coverage is only half the discipline. Having found that one source cannot answer the question, ask which source can — a negative about a parish is not a negative about a family.

Where it was corrected →

10 September 2026

was Computed the family tree's predicted Scottish ancestry as 0.02% and announced that a descendant's DNA estimate — 41.9% Scottish and Welsh — was contradicting the tree.

now The tree predicts 26.6% Scottish. It was never in disagreement with the DNA.

how The method attributed each line of descent to the deepest ancestor on record, rather than the deepest ancestor with a known birthplace. Her great-grandfather was born at St Quivox in Ayrshire; the men above him are in the tree as names with no places at all, so the walk stepped straight past Ayrshire and called that eighth of the pedigree unknown.

The lesson. When a computed result contradicts something the record plainly says, suspect the computation first. A number produced by your own code is not evidence — it is a claim, and it needs checking like any other.

Where it was corrected →

9 September 2026

was Said William Hartley Sneyd was born in 1838, and that his widow's sworn evidence disproved Find a Grave's 30 September 1837.

now He was born on 30 September 1837, and his widow was right.

how He died on 11 September; his birthday was the 30th, nineteen days later. A man born on 30 September 1837 is 64 on 11 September 1902 — exactly what she swore. I did the arithmetic without checking the death date against the birthday. His Queensland death registration then gave the date outright.

The lesson. A stated age is a birth year minus one for everybody whose birthday has not yet come round — which is most of the year, for most people.

Where it was corrected →

9 September 2026

was Read a handwritten Statement of Service as “marched out to Étaples 26.4.16, taken on strength 29.4.16” and published April dates for Arthur Sneyd's arrival in France.

now 26 and 29 July 1916.

how The typed Casualty Form B.103 records the same events in ruled columns and reads unmistakably as July — and July is the only reading consistent with his reverting to the ranks on 29 July.

The lesson. Read the typed form before the clerk's freehand, when both record the same events.

Where it was corrected →

9 September 2026

was Stated that a fourteen-page service dossier for Lindesay Atkinson D'Arcy “is known to exist”.

now No such record could be found under any spelling of his name.

how Nothing was ever checked. The claim had been carried forward on assumption. The search method was then verified by running the same query for his brother-in-law, which returned his dossier at once — so the absence is real.

The lesson. “Is known to exist” is a claim like any other and needs a source.

Where it was corrected →

9 September 2026

was Recommended the Woolwich cadet registers, WO 149, as the best hope for Robert D'Arcy's parentage.

now WO 149 runs from 1790 and is held at Sandhurst. It cannot contain a cadet of the early 1770s.

how The series was recommended without checking its date range.

The lesson. Check what a record set actually covers before sending anybody to it.

Where it was corrected →

10 September 2026

was Called 144 ancestors and twelve generations back to 1654 “what this archive will defend” and “the honest figure”.

now Of those 144, eight rest on a record set. Fifty-six rest only on other people's family trees and seventy-nine on nothing at all. Above generation seven, exactly one of sixty ancestors rests on a record.

how The archive applied its own rule — that a family tree is not a source — to the Hornby descent and to Keele Hall, and never once applied it to the branch it was holding up as solid ground. Nobody counted until somebody asked how far past Brisbane the thing actually went.

The lesson. Audit the ground you are standing on before you audit anybody else's. The claim you have never tested is the claim you believe.

Where it was corrected →

10 September 2026

was Told the family their own founding brief was wrong — that the D'Arcys had married Defranceski, and only the Defranceskis had married Falco.

now The brief was right. Ian Kenneth D'Arcy married Giuseppina Falco, and their daughter is the person this archive is built outward from.

how I looked up the root person's spouse instead of her parents, saw a Defranceski, and published a correction to somebody else's accurate account of their own family. It stood on the site for a day.

The lesson. The worst errors are the confident ones aimed at somebody else. Before correcting a person about their own family, check the thing they would have checked.

Where it was corrected →

10 September 2026

was Published William Hartley Sneyd's title in the Government Printing Office as “Quoin-drawer Overseer”.

now Fount-room Overseer.

how The 1884 volume scanned badly. The 1890 volume prints it plainly, and “fount-room” — where a printing house keeps and distributes its type — is what the job actually was.

The lesson. One bad scan is not a reading. Find the same fact in a second year.

Where it was corrected →

10 September 2026

was Quoted the surgeon of the England as receiving “30 men of the 39th regiment”.

now 39 men, with 6 women and 7 children.

how The figure came from a secondary account. The National Archives' transcription of the journal itself says 39 — and the regiment's own number is presumably how a 9 became a 0.

The lesson. Go to the record. A number that matches something else in the sentence is a number to distrust.

Where it was corrected →

And the errors that came with the tree

These are a different thing, and worth keeping separate: claims inherited from the exported family tree and overturned here. They are somebody else's mistakes, made in good faith, and every one of them is still shown on the page that corrects it rather than deleted.

The tree saidThe record says
John Saniger married Lydia Jones at Berkeley in 1797There is one Lydia marrying at Berkeley between 1790 and 1810 and she is LYDIA JONES, 8 January 1798 — whose husband, on the transcript rather than the result row, is JOHN SAWYER. Berkeley has 272 marriages indexed for 1793-1803, and no Saniger marries there in that decade under any of eight spellings. Lydia herself is real: she dies as LYDIA SANIGAR in the Thornbury district in the September quarter of 1851, GRO volume 11 page 329. It is her maiden name and her wedding that were invented, by somebody who matched four fields in a result row and did not open the fifth. →
Lydia Jones was born 13 March 1770 at Wotton-under-EdgeNo Lydia Jones is baptised anywhere in Gloucestershire between 1765 and 1775 in England Births & Baptisms 1538-1975, against 939 Jones baptisms in the county in the same eleven years. Her age is the one part that holds: the 1841 census puts her birth about 1771. →
Martha Wakefield, 1836–1899, was a daughter of James Wakefield and Hannah SanigerShe is MARTHA HURFORD, who died at Maryborough on 23 April 1899 — and the Queensland death index gives her parents as JOHN WAKEFIELD and a HUGHES. The index records James and Hannah's other children correctly (Ephraim 1868, Aaron 1896, Zillah 1900, Hiram 1905, Miriam 1909), each naming Hannah under a different spelling of Saniger. There is no Martha among them: another man's daughter was grafted onto this family. →
Samuel Sneyd married Elizabeth Oliver at Audlem, Cheshire, 22 October 1809Not found, against a parish indexed twice over — register and bishop's transcript — where a control for Smith returns twenty marriages in the same decade. No Sneyd appears in Audlem's parish registers at all. →
Elizabeth Margaret Oliver was born 7 May 1787 at OswestryOswestry is confirmed by the 1851 census. The date is almost certainly 17 May 1782 — her baptism at St Oswald's, father David, mother Mary — and both censuses put her birth nearer 1780 than 1787. →
John Saniger died on 10 March 1824 at BerkeleyBuried at Berkeley St Mary the Virgin on 16 January 1825, aged 55. The tree is ten months early; the age confirms the 1769 birth it gives him. →
Samuel Sneyd died on 20 September 1856 at No 3, Well St, HanleyHe was buried on 23 September 1855, aged 77, of 91 Well St — and the only Samuel Sneyd death registered in England and Wales between 1854 and 1858 is the September quarter of 1855 at Stoke. The year is wrong and so is the house number. →
The Sneyds descend from Ralph Sneyd of Keele HallDisproved from the Madeley register: the 1742 baptism names the father as William, and Ralph was eighteen. →
Robert D'Arcy was born in 1751 in North YorkshireThe 1751 is arithmetic from an age on a burial register, and nothing places him in Yorkshire. →
Major George Pitt D'Arcy married twice at Chatham in 1810He married Miss Ludlam in 1805 and Maria White in County Wicklow about 1819. →
Arthur Hartley Sneyd was a clerk, buried in FranceA typist, with no known grave. →
Vivian Ernest William Sneyd died between 1919 and 192116 February 1920, registration 1920/B/31382. →
Vivian Claude Sneyd was born at RockhamptonWindsor, Brisbane, on his own attestation paper. →
Read across all 52

The shared cause, counted

An archive that corrects itself silently is asking to be trusted on exactly the point it has just proved it can be wrong about. But the pattern across these 52 is worth more than any one of them, so on 20 September 2026 every error above was re-read and assigned a cause from its own text.

They are not 5 separate faults. They are 5 ways of making a single one: publishing a statement about this archive's own tools, notes or memory as though it were a statement about the world.

CauseHow manyWhat it looks like
About the instrument, not the world 20 A null that described a search box and not a parish; a count that described a paging loop and not a catalogue. The commonest failure here by some distance, and the one the control rule exists to catch.
About what had been read, not what is known 10 Announced as new, or as absent, something this archive already held — twice on the very page being written.
A premise of the archive's own making 10 An assertion written in a note or a to-do list, then read back as though a source had said it. It arrives as background, so nothing grades it.
An edition mistaken for the document 6 A printed transcript, an OCR line or a secondary account treated as the manuscript. A printed text is a reading, not a record.
A number typed instead of counted 6 Every one of these could have been derived from the data and was instead written by a hand that believed it.
The largest group is 20 of 52, and it is the one this archive built a gate for. A null is only a fact about a parish if the search could have found the thing it did not find. That is why every null on /searched/ must name a control, why the build refuses one that does not, and why three separate checks written this month were thrown away for being unable to fail.
This section replaced a sentence that had stopped being true. It used to read “five of the first seven were the same failure: a number or a claim taken from a secondary source”. That was accurate when there were seven. At 52 it is the smallest group of the 5, and the claim had quietly become a typed number of exactly the kind it was describing. The tallies above are counted from the data on every build and cannot drift again.

If you find a 53rd, it belongs here. How claims are labelled → · What is still open →