Method

The record index is built by transcribing entries into fields. It catalogues principals and parents, and it loses everyone else on the page — witnesses, godparents, deponents, neighbours. The full-text corpus is built by reading the page image, so it finds a name anywhere it appears: in a margin, in a witness list, inside a sworn deposition.

The difference is not academic. A marriage this archive had twice sentenced to an image walk was found by a single phrase search. An ancestor the record index said was “never a principal” across 401 results turns out to have given sworn testimony in his own voice. And a man of this family is signing as a rural magistrate in 1800, inside a probate file filed under somebody else’s name entirely.

On 14 September 2026 this archive nearly recorded three false nulls in ten minutes. FamilySearch’s results page renders the string “Historical Record Search Results (0)” while the query is still running — a complete, composed, confident page that cannot be told apart from a genuinely empty result.

It was caught only by running a control. The same query shape was aimed at Sancho Lerena, a man for whom five records had been pulled twenty minutes earlier. It returned zero too. Since that answer was known to be false, the fault had to be in the query rather than in the name. Waiting longer returned the five records — and then 210, and then 822.

This is the same class of failure as the zero-length response body already logged against this source: the service failing in a way that resembles success. It is worse than an outage, because an outage announces itself.

So the rule: a null is not written down until a control query, in the same form, in the same session, returns a result already known to exist. The archive learned this once before and more expensively, over the 1895 census, where it read an enumerator’s abbreviation as a husband’s surname with no control case and had to retract within the hour. The second time the lesson arrived it cost nothing.

15 September 2026 — the rule decided four questions in one day, and only one of them the way it was expected to

It saved a day of work once. This archive had planned to read three hundred images of a regiment’s chaplaincy book by hand, looking for Sancho Llerena. Before starting, one control — a search for the chaplain’s own name, Berroeta — showed the book was in the full-text index. His absence from it was therefore already evidence, and the three hundred images were never read.

It voided a null that looked clean. Searching Spanish records for Félix Llerena and Rosalía Aguilar returned zero. The control — asking what Andalusian collections exist at all — showed the full-text corpus for Andalusia holds nobility and notarial records, not parish registers. The zero meant not findable by this instrument, not not there.

It voided two more, in the same hour. Two exact-surname searches returned zero with the “No Results Found” line present — normally this archive’s proof that a search ran. The control showed the same query shape could not retrieve a record known to be in the collection, because the indexed surname was a compound (Lerena y Armenta) that exact matching will not reach. A null from a query that cannot find what is there is not a null.

And once it confirmed a negative worth keeping. Sancho’s burial is in no index. The control — a common surname, same city, same decade — returned church burials from his own family’s parish dated 1832, 1833 and 1838. So the records exist, are indexed, and do not contain him. That is the only one of the four that survived, and it is the only one this archive would publish.

21 September 2026 — the control passed, and the null was false anyway

The rule above says a null is not written down until a control in the same form and the same session returns a known result. On 21 September that rule was satisfied and the answer was still a lie.

A parent-pair query on Avelino Lerena and Celedonia Villademoros returned a clean zero. The control — the identical query shape on Alberto Lerena and María Inés Larriera, minutes earlier — had returned sixteen records. Deleting the mother’s surname and keeping only “Celedonia” turned the zero into seven, two of which are christenings already published on this site.

So a control licenses the shape of a query and says nothing about the value you put in it. Larriera has one spelling in this register. Villademoros has four — Villademoros, Villardemoros, Villademoro, and the compound the children carry. The control could not fail, because it was asked about the one surname that could not go wrong. What caught the zero was not method at all: it was that the archive already held two of the records it was hiding.

Which sharpens the older rule rather than replacing it. A nil from a derived index is, in the first instance, a fact about the index. It becomes a fact about the family only when the index’s coverage of the relevant registers has been established — and coverage is not one thing. It can fail at the collection, as it did for Andalusian parish registers; at the query shape, as it did for the compound Lerena y Armenta; or, as here, at a single field the source failed to parse. Three different failures, one identical-looking zero.

This archive publishes negatives as evidence, because most of what it has established is negative. That is exactly why the bar has to keep rising. A published null needs a date, a control, and a statement of what the instrument could have reached.

Nine of these were written in working logs where no reader could see them — found on 20 September 2026 by asking which findings in this archive’s 136 working files reach no page at all. The two dated that day were caught by the habit rather than by luck, which is the only argument for keeping a habit.

On 15 September the working log recorded that the same trap had been seen four times in a month, in four different disguises. It is now twelve.

On the afternoon of 21 September 2026, a query returned “Historical Record Search Results (0)” with “No Results Found” printed beneath it.

That line is the thing this archive has been treating as proof of a real null — the positive assertion of emptiness, as opposed to a heading rendered before the data arrives. The count was stable across two reads twelve seconds apart. It was still zero after a ninety-second wait. And a control on the same query shape had passed earlier the same day.

All of it was wrong. The search was returning zero for everything.

What it actually was

One browser context had lost its authentication — and only one. The two FamilySearch searches handle that completely differently: asked the same question in the same minute, the full-text search redirected to the sign-in page — honest, unmistakable, one navigation — while the record search answered “0 — No Results Found”. The DeepZoom image host went on serving plates throughout, which is why a whole day of reading images had given no warning.

So there is a free test, and it costs one navigation: ask the full-text search anything at all. It admits a lost session. The record search hides one behind a null that satisfies every other rule on this page.

All three nulls held over for re-testing — Luis with Carolina, Carlos Ambrosio with Luisa, Juan Arturo with Isidora — were re-run against a live control and all three are still zero. Nothing was lost but the afternoon.

And the next day, the same guard caught a different fault

A parent-pair query on Sancho with María in Uruguay returned 0 — read twice, with the González control returning 479,660 minutes earlier. This time the service was healthy. The query shape was broken.

• father’s given name Sancho, alone — 10,315
• mother’s given name María, alone — 1,228,708
• both together — 0
• both, plus the two surnames — 6, every one of them real

Two fields matching five and seven figures cannot intersect at nothing in a country where María is the commonest name a mother has. A parent-pair query with given names only returns zero whatever the truth is, and says nothing about it. At least one parent surname must be supplied before a null from this shape means anything.

Arithmetic caught it again, and it is the only guard on this page that has never failed. Notice what it is doing: not asking whether the answer is plausible, but whether the answer is possible.

Three things the other archives on this machine sent back, each better than what this one had

• A negative must carry proof that the instrument reached the place. Not “the search returned nothing” but here is the entry before where it would be, and here is the entry after, with the numbering continuous across the page break. That is a null carrying its own evidence. A control query only borrows evidence from something run nearby. (Luwinski.)
• A positive proves the service was answering for that collection. Where access is per-collection rather than all-or-nothing, a hit in an open collection vouches for nothing in a restricted one. (Defranceski.)
• A service that is honest in one place and fabricates in another, at the same moment, is worse than one that always lies. A consistent liar is caught once and distrusted for ever. This one redirected honestly in one browser and manufactured a null in another, in the same minute, on the same machine. (Booyzen.)

And the thing that hid it longest, which is worth more than any of the rules: the plate host went on serving images perfectly all afternoon, in the same browser, while the search fabricated. A day of successful image reads is not evidence that the search is healthy. Different hosts, different authentication, independent failure — and the one you are watching is not the one that is lying.

What proved it

Two facts, neither of them a matter of judgement:

• Surname González, in Uruguay, returned 0. González is among the commonest surnames in the Spanish-speaking world; the Uruguayan civil registration runs to millions of records. That answer cannot be zero.
• The same URL that had returned ten records that morning returned 0 that afternoon — Avelino Lerena with Ambrosia Traibel, the ten acts this archive had spent the day reading.

What it nearly cost

The zeros looked like a discovery. A man whose baptism this archive has read off the plate — Alberto Octavio Lerena, act 585 of 7 October 1850 — returned nothing when searched by name. The obvious reading was a real and interesting mechanism: that the parent-pair query reaches only the keyed index, and cannot see acts that exist in the full-text corpus alone.

That is a good theory, it explains the evidence, and it is false. It was about to be written up as a finding, with consequences for every null in this archive drawn from a parent-pair query. It was built entirely on an outage.

So the rule gains two words. A control must be recent — the service was healthy in the morning and lying by the afternoon — and its answer must be arithmetically impossible to be zero. A control that merely ought to return something is a control that fails silently alongside the query it was meant to guard.

One class of zero survives untouched, and it is worth naming: a zero that was turned into a result by deleting a parameter. Villademoros 0→7 and Hermenegilda 0→3 both stand, because a positive result proves the service was answering at that moment. Only the zeros that stayed zero are in doubt.

This archive’s standing rule is that an index is not evidence and the image must be opened. On 21 September 2026 it found out how often it had kept that rule.

Sixty-one register rows cited “full-text transcript read” — which means a machine read it — and named no image. That is more than half the rows carrying a source at all. A tool now ranks the unopened plates by how many people depend on each one, because one image can settle seven rows at once.

What the machine got wrong

The 1892 marriage act of Alfredo Justiniano Lerena Traibel gave his bride as Hermenegilda Carolina Gavarro, daughter of Gerónimo Gavarro and Carolina Juárez. The plate says “hija legítima de Don Gerónimo Gavazzo y Doña Carolina Suárez”. Three surnames, wrong for a week, and confirmed wrong by a second image forty-eight years later. Gavazzo is a known Montevideo surname and Gavarro is not, which is the kind of tell that should have prompted the check.

What the machine got wrong in the other direction

The top-ranked unopened plate was the one carrying the archive’s most consequential proper noun: the 1831 baptism at the Cordón where the President of Uruguay stood godfather to Sancho’s grandson. Seven register rows rest on it. It was opened — film 007713388, image 00726 — and the act reads:

“padrinos Dn. Frutuso Ribera, Presidente de la República y su esposa Da. Bernardina Fragoso”

Frutuso Ribera, with a B. The transcript had printed Fructuoso Rivera — the spelling in every history book, and not what the page says. The finding holds and is stronger than it was, because the act states the man’s office and names his wife: in December 1831 the President of the Republic was Fructuoso Rivera and his wife was Bernardina Fragoso. Two independent facts on one line, either of which identifies him alone. The same page spells the grandfather Llerena, with the double L.

Both failures are one failure. A machine transcript is reliable about dates, ages, relationships and formulae, and unreliable about proper nouns — it invents a plausible name where it cannot read one, and it writes the famous spelling over the page’s own where it can. So the rule is not “distrust transcripts”. It is: a transcript is a finding-aid for everything except the names, and the names are usually why you went.

The sweep is finished — sixty-one to nothing

Every one of those rows has now been read off a plate. Twenty images, in one day. The tool reports 0 of 153, and what the sweep actually cost is the argument for having run it:

• Four claims about this family’s spelling were the machine’s, not the scribe’s — Abelino Serena is LERENA; Sancho Lorena is LERENA; the LORENA of an 1889 act is its margin, not its sentence; and Fructuoso Rivera is the history books’ spelling written over the page’s own Frutuso Ribera.
• Five surnames were simply wrong. Gavarro is Gavazzo, Juárez is Suárez, Florencia is Florinda, Seguera is Segueira, and “Del Suando” is Zalsamendi — a Basque name no search for the other could have reached.
• One baptism was in the wrong parish and one citation pointed at the wrong film.
• A birthplace was wrong in a way that changed the family’s shape: María Fernández is “natural de Asturias”, not of Montevideo.
• And about twenty-five people who were standing on the acts had never been entered at all — among them Sancho’s parents-in-law, two grandparents drawn at the apex of a priest’s kinship diagram, a child of Justa Pastora, and Adolfo Lerena.

A zero here is a statement about today, not a property of the archive. Every new row that cites a transcript and names no image puts the count back up, which is the point of printing it: python3 tools/transcript-only.py.

On 21 September 2026 a search for the children of Avelino Lerena and Ambrosia Traibel returned ten records. Three of them were dated 1896 and 1919. Avelino died in 1890. Ambrosia was born around 1820.

The tempting reading is that the index has attached the wrong parents, and that those three are other people’s children. The opposite was true. The parents are right and the dates are wrong, because the film is not a baptism register at all — it is a register of certified copies issued in 1896, and the indexer took the year off the certificate and the day and month off the act inside it.

The act, read off film 008166435, image 02850, opens: “Certifico: que en el libro 1.º de Bautismos … en el folio 135, se lee la partida siguiente … El veinte y uno de Noviembre de 1852”.

Why the book exists is written on every page of it. Each certificate opens “yo Luis Cincinato Bollo, Director General del Registro del Estado Civil, he certificado, de acuerdo con lo dispuesto por la Ley de 9 de Julio de 1888”. Uruguay took registration off the parishes in 1879 and then had the older baptisms copied across. So a family’s whole set of acts can sit in one 1896 volume, decades out of their own order — and the index will date every one of them to 1896. This is not a fault in one record. It is the shape of a collection.

And the index is not noise. It keeps the day and the month and replaces only the year, so it is two thirds of a date and the film supplies the third. The two brothers really were born on 16 March — in 1852 and 1857, five years to the day apart.

On 16 September 2026 this archive drew up a ranked list of files for a researcher going to the National Archives in Pretoria, where the first file costs R2,850. It put two Transvaal death notices first and second.

Both had been sitting on David’s own disk, photographed, since November 2021. The same folder held the 1911 marriage register, which was on the work list as a thing to go and find. Nobody had ever opened it.

The failure was not carelessness about sources. It was a gap in the bookkeeping. This archive kept a careful register of what it had read and no register at all of what it already held — and the two are not the same thing. A document can be in the house, scanned, for five years, and be invisible to an archive that only records its own searching.

What came out of that folder in twenty minutes is on The papers in the house: a marriage act, a religion, a trade nine years earlier than anything else held, a birthplace that closed the very question the trip was to answer, and a blank line on a consular form that says more about the Rosario search than three weeks of reading registers did.

This archive was served from daviddef.github.io/TheLerena/ from the start. It now lives at lerena.defranceski.com, as four sibling archives moved the same week. A project path cannot inherit a parent domain — defranceski.com is itself a Pages site served by its own repository, so a subdomain was the only clean route.

The traps are the point. An Actions deploy that does not carry a CNAME detaches the custom domain, which would have bitten weeks later. Hand-re-pinning a dependency’s commit in package-lock.json updates resolved and leaves integrity as the old tarball’s hash, so npm installs the old code while every pin on display reads correct. And a shared key stops being a key when everybody uses it: five archives on an empty base meant the lookup returned the first one, so the first green build of this move shipped another archive’s accent and a canonical pointing at its domain, on all 1,500 pages.

And the obvious check does not catch that last one. og:site_name reads correct on a wholly broken build, because the component takes it from a prop before it looks the archive up. The reliable tells are canonical, og:url and theme-color.

And a sixth, which this archive was sitting in while the section was written. The recipe said: push the config, then have the owner bind the custom domain, and the gap is about ninety seconds. The gap is however long it takes a person to click. With base at / every link is written site-root, and under the old project path those resolve to daviddef.github.io/about/, which does not exist — 113 of them on the home page, beside a canonical aimed at a domain that did not yet answer. Nothing was lost and nothing was damaged; the archive was simply unreachable by its own navigation. And the “safe order” this page recommended for a few hours is wrong too. Binding the domain first does not cost nothing: binding makes GitHub 301-redirect the project path onto the new domain, so the old address stops being an address, and the still-based build it lands on has its own assets at /TheX/_astro/…, which are gone there. Three sibling archives were live-broken for hours that way. The gap is not eliminated by reordering, only moved — push first and the old host serves root-relative links that 404; bind first and it redirects to a host where the based build 404s. What closes it is the two steps landing within the minute.

And the confirmation step this page added confirmed the breakage. “After binding, check the new host answers” is right in spirit and its test was wrong: the home page answers 200 because the redirect lands you on it, while that build’s stylesheet is 404ing. Fetch a based asset — the stylesheet or favicon at its old path — not the home page. The step meant to prevent looking at intention instead of artefact was itself looking at intention.

What the seven share is one rule, and it is the rule this archive spent the rest of the same day learning in a different language: verify the installed artefact, not the recorded intention. Never “does the pin say the right commit” but “is the new code actually in the installed file”. It is open the plate, not the index — read the act, not the volume label; ask the catalogue, not the breadcrumb.

And it caught its own author, in a measurement. The first count of broken links here was reported as “every internal link on the home page”. It had been piped through sort -u, so it was distinct paths — and its pattern dropped uppercase, digits, deeper paths and anchors. 36 and 113 were both true of the same page. The conclusion did not move, because zero based links is zero either way, but the failure is the list’s own: a measurement that reports what the command asked for rather than what is there. And it is not only a deployment fault — this archive did the same thing twice the same day, counting 208 records for Artigas and 470 for the Cordón parish, both of which were counts of what the query matched rather than of what the place holds, and both of which had to be withdrawn. A count is a claim, and has to mean what it says.

None of this was one session’s work. The kit fix is the Blažević session’s; the og:site_name masking was found by D’Arcy; the lock-file trap and the instructing-comments point were found here; the recipe, and the correction to it, are the Defranceschi session’s. Five archives moving at once is what made two of these visible at all.

On 10 October this archive published that Leandro Lorena and his wife Llanos appear in one record in the index, in any country, and offered it as the model of a properly controlled null. Four of that household were already in the register, entered from the 1895 Buenos Aires census, under the spelling LERENA rather than LORENA. The same day it published a search mechanism as new that another data file had carried for a month.

Neither was a retraction, so every gate stayed green. Corrections records what was taken back; the superseded gate checks the site stopped saying it; drift asks whether a page has fallen behind its data. Nothing asked whether two live claims in two files contradicted each other.

So check-nulls.py now reads every data row asserting a blanket null — true null, only record, in any country, on earth — pulls the names out, folds the surname through the fourteen spellings /name/ publishes, and compares the claim against that person’s register row.

It compares sources, not presence, and the first version got that wrong. Failing on any name the register held reported ninety-one, which is nonsense: half this register is people known from a single document, and “the card is the only record of this household” does not conflict with the household having a row. Being in the register is not the same as having records. The gate now asks whether the register cites the very record the claim concedes. If it cites something else entirely, the archive is holding two answers.

And it was tested against the thing it was built for. Run on the tree as it stood before the error was found, it reports: cajon-985-last-two.tsv says ‘LEANDRO LORENA’ has no record, but ‘Leandro LERENA’ is in the register from a source the claim never mentions: 1895 census, Sección 18. A gate that cannot be shown catching its own case is a gate guarding nobody.

It found one more thing on the way. The duplicates gate had its own hard-coded list of six spellings while /name/ published fourteen — the same two-rows-that-never-meet failure, inside the toolchain. Both now read the one published list, and folding PERENA onto LERENA surfaced eleven same-name pairs the gate had been under-reading for weeks. All eleven were compared and kept apart by hand.

The Montevideo marriage-dispensation register was searched in September by two of the register’s own formulae — “Lerena el impedimento” for a groom, “Lerena feligresa” for a bride, who is always named with her parish. It returned eight Lerena dispensations in seventy-six years. The formulae are adjacencies, and a compound surname sits down in the middle of one: Lerena Juanico feligresa does not contain Lerena feligresa, so a woman can be invisible to the search purely because her surname is two words long.

This page published that on 11 October as a new finding, and it was not one. The archive had worked it out on 14 September, written it down in almost the same words, and used it to find a ninth dispensation — José Pedro Massera’s petition of 19 June 1913 to marry Doña Ema Sixta Lerena Juanico, feligresa de la metropolitana. The errand this work was done against had been stale for a month: the job was half finished and the errand never closed. The correction →

What today adds is the other half. September ran four compound forms. Six had never been run. All eight have now been run to the end of their result sets rather than to the end of the first page — FamilySearch takes count=100 in the results URL, and without it this would have been the ranked-list mistake this archive has already made twice.

The answer is a null, and a controlled one. Two of the eight forms reach the dispensation register and both land on dispensations already held — 1911 through Lerena Cardozo, 1913 through Lerena Juanico. The queries demonstrably hit the target, and there is nothing else in it. There is no tenth Lerena dispensation.

And what it rests on. No compound form touches the register except the two that land on dispensations already known. That is what a controlled null looks like: the method is shown to reach the target before its silence is believed. The errand is closed. What would still overturn it is a compound form nobody here has met — the standing weakness of every surname-based sweep in this archive. The errands →

This family is written Lerena, Llerena, Lorena, Serena, Lerina, Sancio, Gerena and Levena across the registers that hold it. A surname box cannot reach it reliably.

The parents can. Searching for a couple — father Sancho, mother María Fernández — rather than for their surname returned four of Sancho’s children in one query, including two the archive had never met. Godparents, spouses and witnesses work the same way: their names are spelled ordinarily, and they are standing in the same act.

Turned on the central question the same hour, the method found nothing — which is itself the strongest form the central null has yet taken. The open questions →

Living people appear by name only — no dates, no places, no photographs. That is the rule shared across this family’s archives, and it is stricter in practice than it sounds: a birth date and a city together identify a person completely.

Where a living person’s evidence bears on a dead one — a DNA test, a death notice they signed — the inference is published and the person is not. The DNA page → is the worked example.

This rule was broken until 10 September 2026, when the direct-line page was found to be publishing a living person’s exact birth date, two cities and both marriages beneath a caption claiming the details were withheld. Recorded on Corrections.

This archive cites 58 FamilySearch film numbers. Two Montevideo attributions had already failed inspection, which put every catalogue-derived number under suspicion. All 58 were tested on 20 September 2026. Fifty-seven resolve to a real film and not one points at a film that does not exist.

It was done with FamilySearch signed out, because the thumbnail endpoint is public. Two traps are recorded below, and both would have produced false corrections against perfectly good data — one of them caught me.

The two free sources this archive leans on hardest behave in opposite ways, and each punishes the habit the other rewards. Getting them the wrong way round produces a false null on either site, and a false null is the most expensive mistake this archive can make — it closes a door that was never shut.

Both were proved here with controls. On FamilySearch, an exact forename search matches the whole given-name string: exact Maria returns 53 Uruguayan Lerenas and Maria Lili Lerena is not one of them, while exact Maria Lili returns her alone. On FreeBMD the reverse holds — the printed index abbreviates the second forename, so Horace Archibald finds nothing while Horace A is sitting there.

Six FamilySearch trees give Sancho Llerena the same parents — antoniojosed, rosanaic, jfina, nanabal, ladissosa and abal2018. That looks like strong corroboration and it is not corroboration at all. They descend from one published account — one of them carries in its own user name the surname that appears in that work’s acknowledgements — beside a single Spanish tree of undated estimates. Copies are not corroboration.

Documented This archive had already learned the same lesson from a parish book rather than a website: the three Francisco entries of 7 January 1846 that looked like three witnesses were one clerk, writing one page, on one morning. The shape is identical. Counting copies as witnesses is the commonest way an archive talks itself into confidence, and it happens on paper as readily as online.

Documented And where a census meets a reconstruction, the census wins. The two camps disagree about Sancho’s birth by thirteen years: the Uruguayan trees say 1767, antoniojosed says about 1754. The padrón of 1812 records him as 45, which is 1767. The 1754 is what you get if you assume a marriage in 1753 and a first child the year after — so that tree’s “about 1753” marriage is an estimate derived from a guessed birth, not a record of an act.

Documented Which dissolves a coincidence that looked real for an hour. A Lerena marrying an Aguilar at Córdoba in 1753, one year before a Sancho de Lerena y Armenta married an Ana María de Aguilar at Granada in 1754 — two families, two cities, one year apart. There is no coincidence, because the 1753 is not a date from a document. It is a tree’s arithmetic, built on a birth year the census contradicts.

Documented The opposite case is worth naming too: when an index disagrees with itself the way the acts do, the disagreement is in the registers. Dominga Josefa Lerena married a Capitán Don Antonio Ruiz — or Rodríguez — de Carvallo, and the two acts spell him differently. FamilySearch’s own index splits the same way. An index that reproduces a disagreement did not invent it.

Documented And the same discipline run forwards, for once, rather than backwards. A parent-pair query on Félix Llerena and Rosalía Aguilar returned zero from Spain. The page rendered and reported a count, so it was not a blocked page. The control was run before the null was believed, not after: searching ciudad de Córdova and reading the collection names that came back.

They are Nobility Records — Granada 1489–1718 and Écija 1529–1907, Madrid notarial protocols, and induction files of the Orders of Chivalry. The only Córdoba in the whole corpus is Córdoba, VERACRUZ, in Mexico. So the full-text index for Andalusia holds nobility and notarial records and not parish registers: an eighteenth-century Córdoba baptism is not in the corpus being searched. The zero means “not findable by this instrument”, not “not there”, and it is recorded that way.

Inferred One more tier worth stating plainly. Fourteen records sit attached to Sancho Llerena in the tree, and the attachments are secondary — a tree user decided those fourteen are all one man, and the underlying acts have not been read here. One was opened to check and it is a proof of nobility of 1599, from Alcántara, Cáceres, Extremadura. A record can be perfectly genuine and still be attached to the wrong man; the attachment is the claim, not the document.