How this archive decides what it knows
Method
An archive is only worth reading if it says which of its claims are documents, which are inferences, and which are things the family remembers. These are the rules, and they are the same rules as The Falco Archive.
Added 14 September 2026
Every negative in this archive, audited
Twice in one week a search that had been closed turned out to be open. So each negative was re-read — not to repeat it, but to ask what set its window. Twelve have been audited and seven had already failed, not because the reading was careless but because the window came from a declared age or an assumed eldest child, and the search then honoured that window exactly.
The rule that falls out of it, and the five negatives still standing in the same shape, are on The Audit.
The instruments
How this archive reads, as opposed to what it found
A finding belongs to a person and lives on Corrections or What Has Been Read. An instrument belongs to a record series, and will be wanted by whoever reads it next — including the other six archives in this estate, which use the same registers in different towns. Every one of these was learnt twice before it was written down once.
Every instrument here carries a caution, and that is not decoration. A method described without the way it fails is how a method becomes a superstition. The annual Tavola is the best tool in this archive and it changes its alphabetical key between adjacent years, which has already produced one confident, complete and entirely false negative.
Scilla and Piedimonte, every civil year that has one
The annual Tavola — An alphabetical index bound at the end of a year's register. Scilla's names BOTH SPOUSES and ALL FOUR PARENTS -- and marks a dead parent with «fu». A death Tavola is the same form, and for a married person the parents column carries the SPOUSE instead.
Read the A section and a whole year is one crop. Three brothers for Filippo Arena, a death bracketed to ten years by a single «fu», and then that death exact to the hour, all came out of twenty-seven Tavole read this way.
Caution. THE KEY CHANGES BETWEEN ADJACENT YEARS. 1818 alphabetises by the groom's GIVEN name, 1819 by surname. Some years have no A section at all. And the «Num. d'ordine» is the INDEX ROW, not the act number -- carry the DATE across and walk the register, which runs in date order.
Unindexed marriage volumes, napoleonic and restauration
The act-head montage — In these registers an opening puts the END of one act on the left page and the HEAD of the next on the right -- number, date, groom, age, trade, father. The napoleonic form adds the bride.
Crop that band (pct:52,18,46,26 at width 900), tile ten to a sheet, and a forty-act volume is four images instead of forty openings. 1815, 1816 and 1817 fell in an afternoon, against the 2,191 processetti thumbnails that had been budgeted.
Caution. It shows the GROOM. A woman's marriage still needs the Tavola or a second band. And find the volume's END -- these close on the sindaco's statement -- before writing any negative.
Scilla 1810-1865, Piedimonte 1841-1860, Briatico, Zambrone
The marriage processetti — The papers filed to get a licence: the BIRTH EXTRACTS of both spouses and the DEATH ACTS of dead parents, copied out of the PARISH books -- which begin decades before the state did.
Find the wrapper: «<year> | <folios> | N.o <bundle> | <comune> | Documenti per il Matrimonio di <A> e <B> | fogli <n>». Scan at five-image spacing, then step two. Scilla's 1815 bundle 29 gave two exact birth dates, corrected a given name, and reached GENERATION NINE.
Caution. Read it EVEN WHEN THE ACT IS ALREADY IN HAND. At Scilla the register beat the bundle and the bundle then beat the register: it corrected «Setteria» to LITTERIA and settled a five-year age dispute the act could not.
Italian-era birth acts, both countries
The marginal annotation — A column beside the act, filled in decades later, recording the subject's marriage: «unita in matrimonio con X di Y con atto del <date> iscritto in <comune>».
It identifies by SPOUSE, which is usually the one thing already known. One crop eliminated the only Maria Nicotra born at Piedimonte in 1875 -- she married a Nicito there in 1891.
Caution. A PRESENT annotation is free evidence; a BLANK one is silence. Giuseppe Arena demonstrably married at Scilla in 1885 and his box is empty. And the box moves: left column in 1852-53, right in 1860.
Antenati, any comune
The register index, at s_size=500 — `?localita=X&s_size=500` returns a comune's whole holding in one page load, fondo by fondo.
It is how Piedimonte turned out to have 457 registers where this archive had listed 103, and how nine volumes of Riveli di anime e di terre from 1714 were found at all.
Caution. 500 IS THE CEILING and above it the request times out, so a listing can silently be a SAMPLE. The true total is in the result facets as «Archivio di Stato di … (N)». Compare the two. And `?citta=` returns zero in silence.
Antenati
The container fetch, from inside the origin — The ark-to-container step is what the image server needs, and it normally costs a rate-limited page load apiece.
Fetched in page context from a tab already on the origin, six at a time and five seconds apart: twenty-one containers in one sitting with no 403, where twenty-one navigations would have locked the session out repeatedly.
Caution. IMAGES ARE NEVER THROTTLED, HTML ALWAYS IS. When the limiter bites, switch to image work -- two whole unindexed volumes were read while it was down.
Sicily, Deputazione del Regno -- Piedimonte has 1714 and 1747-1752
The Riveli di anime e di terre — A household tax return sworn by the head of the house: the house, the head, his wife, his children. A century before civil registration in Sicily.
The 1747-48 volume opens with fourteen images of alphabetical index, letter tabs cut into the fore-edge. Folio = image - 16 in that container.
Caution. THE INDEX IS BY GIVEN NAME, so there is no shortcut to one surname. AND AT PIEDIMONTE ONLY THE HEAD'S AGE IS GIVEN -- the wife and children are named and not aged. It gives the household and the house, not birth years.
Queensland, births 1829-1926, marriages to 1951, deaths to 1996
The Queensland BDM download endpoint — `downloadSearch` returns a whole result set as CSV in one GET, with the MOTHER and PARENT columns.
Sweeping NICOTRA and three spellings of CASSANETI showed that «Cassaneti» appears exactly ONCE in the entire Queensland index -- on the registration this archive took the spelling from.
Caution. IT REFUSES CURL WITH A 403 and works from inside the site's own origin. `fathersname` and `mothersname` RANK, they do not FILTER. And the windows CLOSE -- a 1949 migration is outside the birth window entirely.
Australia, alien registration after 1945
NAA RecordSearch item titles — The item TITLE carries the particulars, so a NameSearch settles a question even when nothing is digitised: «Mazza [nee Nicotra], Maria -- arrived Sydney 20 April 1962».
One line gave a maiden name from an Australian government record and an arrival the family tree did not have, for a woman fourteen years of Italian birth indexes had failed to find.
Caution. Run it on the MARRIED surname AND the maiden name before sweeping any Italian comune. A birthplace stated by the person outranks one inferred from her husband's town.
Any ledger, foliated register or index with running totals
A source that carries its own arithmetic — A double-entry book closes each page with a total and opens the next with a «riporto». So the document states, in its own hand, whether your reading of it is complete.
The 1714 Piedimonte riveli index is seventeen images. Twelve were read and two pages looked like blank versos at thumbnail size. p6 closes at 1468 and p8 opens at 2556 -- eleven households looked straight past, and a negative eleven households short would have read exactly like a complete one.
Caution. IT IS THE ONLY CHECK THAT COMES FROM INSIDE THE DOCUMENT rather than from a second source, and it is the reason to fetch the thing you are about to skip. It works on act numbers and folio numbers too: a jump in either says a frame is missing or a page was not photographed. It does NOT tell you the reading was CORRECT, only that it was whole.
Any comune -- reported from Arienzo, Caserta, by the Falco archive
The Tavola that stops early, or is blank — A Tavola can be present, properly headed, ruled and filled in -- AND STOP AT C. Arienzo births 1832 runs Anzivino, Andrea, Arrigale, Ambrosio, Bernardo, Balletta, Crisci, Cimmino, and the volume ends. The 1834 death index there is a single leaf covering A to C, marked END. And Arienzo births 1836 has a printed heading, ruled columns and EVERY CELL EMPTY.
«A search that reaches the C page and finds nothing has not reached F.» This archive's own Tavola sweeps survive it for one reason worth stating: where a year appeared to have NO A SECTION, the entry NUMBERING was checked -- a Tavola opening at B with entry 1 has no A entries, where a Tavola opening at B with entry 12 is missing a page.
Caution. CHECK THE LAST LETTER THE TAVOLA ACTUALLY REACHES, not just its alphabetical key. And a BLANK Tavola is nastier than an absent one, because it files itself in a note as «not read» and somebody opens it again. Reported by the Falco archive, 21 September 2026.
Italian birth registers, both countries
The declarant is not the father — A birth act opens on a right page naming whoever PRESENTED the child, and the PARENTS are named at the top of the next left page. In some years the presenter is the father; in others act after act is presented by the LEVATRICE, the midwife.
A band sweep of the declarant line works perfectly in a year of fathers and SILENTLY DROPS EVERY FATHER WHOSE CHILD THE MIDWIFE CARRIED. It cost the Falco archive a full re-sweep of a 128-image volume.
Caution. IF YOU ARE BANDING A BIRTH VOLUME, BAND THE PARENTS LINE, NOT THE DECLARANT LINE. The failure produces a clean, complete-looking, confident negative -- which is the only kind that survives review. This archive's own montage sweeps are of MARRIAGE volumes, where the band carries the groom and his father, so they are not exposed; its birth work has been index-first. Reported by the Falco archive, 21 September 2026.
Italian-era «Matrimoni, allegati» -- Piedimonte 1866+, and any comune filming the allegati separately from the acts
The «vivente» field in a publication certificate — The printed «CERTIFICATO di seguita pubblicazione di matrimonio senza opposizione» has a blank for each spouse reading «figlio del ____ ... e della ____». The clerk fills it with VIVENTE or with FU. It is a POSITIVE statement about all four parents, with a trade and a residence beside each, on a dated form -- not the absence of a marker but the marker itself.
Find the fascicolo by its wrapper: «Fasc.o N.o 15» is printed at the head of the divider page, so one banded crop of the top-right corners across a dozen images locates any bundle. At Piedimonte in 1871 the bundles run about three images apart. The certificate is on the RIGHT page of the opening after the divider; the divider's verso is blank.
Caution. THE ALLEGATI ARE NOT THE PROCESSETTI AND WILL NOT ANSWER THE SAME QUESTIONS. The Bourbon-era «Matrimoni, processetti» carry the spouses' BIRTH EXTRACTS and their dead parents' DEATH ACTS. The Italian-era «Matrimoni, allegati» of 1871 at Piedimonte carry the publication certificate and little else -- no birth extract, no death act. Reasoning from one to the other plans a search the volume cannot answer. What the allegati have that the processetti do not is this vivente/fu field.
Any record surviving in more than one copy -- an act and its allegato, an act and its duplicate, a parish book and its civil certification
One hand, one occasion, ONE WITNESS — An act and the certificate filed beside it look like independent confirmation -- different volume, different printed form, different date -- and they are not. The same uffiziale wrote both, in the same fortnight, from the same declaration by the same people.
Before counting a second document as confirmation, ask who wrote it, when, and from whose mouth. Confirmation requires a DIFFERENT DECLARANT or a DIFFERENT OCCASION: a birth act against a marriage act, a marriage act against a death act, an Italian act against an Australian one.
Caution. IT COST NOTHING HERE ONLY BECAUSE IT WAS CHECKED. Leonarda Bonanno is «d'anni ventitré compiuti» in BOTH the 1871 marriage act and the 1871 publication certificate, and both are four years wrong against her 1843 birth act. Two documents, one error, perfect agreement. A reader who counted them as two would have moved her birth by four years on the strength of a single clerk's afternoon. AND THE LERENA ARCHIVE HAS WIDENED IT PAST OFFICES AND WEEKS. Two of its own index entries -- different collections, different films, DIFFERENT INDEXERS -- agreed on a day and on a named pair of godparents, and were one baptism of 31 December 1865 certified twice. Worse and older: three baptisms at La Mauricia, Montevideo, in January 1846 give the birth year in identical words, «del pasado ano cuarenta y tres», including one for an unrelated family -- one priest, one sitting, one hand. THE RULE IS NOT ABOUT PROXIMITY IN TIME. Copies made forty years apart are still one witness if one hand made them from one occasion.
Reported by the Lerena archive from FamilySearch's «Uruguay, registros parroquiales»; the same shape wherever older acts were certified into a later register
An index whose fields come from two different documents — Uruguay's Ley de 9 de Julio de 1888 had older parish baptisms certified into the civil register, so whole volumes are 1896 COPIES of much older acts. The indexer takes the YEAR off the certificate and the DAY AND MONTH off the act inside it. The result is a date that is complete, plausible, and up to forty-four years wrong -- 21 November 1852 indexed as 21 November 1896.
Two tells, both free on the results page. (1) TWO CHILDREN OF ONE COUPLE WITH THE SAME INDEXED BIRTH DATE -- they were really born on that day, in different years. (2) AN ANACHRONISTIC GODPARENT, or any named party who cannot have been alive. A parent-pair search that returns children born after their father's death is the same signal.
Caution. THE PART THAT IS WRONG IS THE PART NO FACET EXPOSES, which is the family this archive's own failures belong to: a count sitting unparsed on the page, a partial index section read as a clean negative, a 403 that parses as zero. The index is not noise -- it is PARTIALLY RIGHT, and the right part makes the wrong part look trustworthy. Never take a date off an index whose source might be a certified copy without opening the act.
Any search form with more than one field -- FamilySearch, Antenati, Ancestry, the Queensland BDM
A control licenses the SHAPE, not the VALUE — This archive's standing rule is that a zero is not recordable until a control query, in the same form and the same session, returns a known result. THE RULE IS NECESSARY AND IT IS NOT SUFFICIENT. A passing control proves the form works, the session is not throttled and the shape of the query is right. It proves NOTHING about the particular VALUE you typed into the extra field.
Reported by the Lerena archive, 21 September 2026, from its own data. A parent-pair query on Avelino Lerena with mother «Celedonia Villademoros» returned a clean, twice-read ZERO. Deleting the mother's SURNAME and keeping only «Celedonia» returned SEVEN -- two of them christenings that archive had already published on its own pages, and one of them DISPLAYING the mother as «Celedonia Villademoros», spelled exactly as asked. The mother's whole name sits unparsed in the given-name field, so supplying a surname excludes every record the parser failed on. A control had been run in the same session and the same shape -- Alberto Lerena with Maria Ines Larriera, sixteen records -- AND IT PASSED. Its passing is what made the zero look trustworthy.
Caution. THE DIFFERENCE WAS THAT LARRIERA HAS ONE SPELLING AND VILLADEMOROS HAS FOUR. So: EVERY EXTRA PARAMETER IS A FILTER THAT CAN EXCLUDE ON A FIELD THE SOURCE FAILED TO PARSE, and the more precise the query looks the more it can be hiding. Before recording a zero, RE-RUN IT WITH THE MOST SUSPECT PARAMETER REMOVED -- the rare surname, the place, the date range -- and see whether the count moves. What actually caught this was that the archive already held two of the hidden records; nothing in the query could have. This archive's own «localita=» caution is the same fault seen from the other side: the parameter matched places it should not have. Both are the same rule -- a field you did not put there yourself is a field you do not control.
Antenati's «cerca per nome»; any derived index that does not cover every source
A nil from an index is a fact about the INDEX — A name-index query that returns nothing is reporting that the index holds nothing. It is NOT reporting that the registers hold nothing. The two are indistinguishable from inside the query, and the nil looks like research.
Before recording an index nil as evidence about a family, establish whether the comune is indexed AT ALL. At Antenati only some are: Scilla deaths 1911-1943, Pizzo births 1868-1903, Catania deaths 1911+. Piedimonte Etneo, Mascali, Briatico, Zambrone, San Costantino Calabro and Potenzoni are NOT. Confirm a zero by the presence of «Nessun risultato trovato» -- the zero page contains NO «N risultati» string, so a count regex returns nothing and a throttled page looks identical.
Caution. PROVEN AGAINST THIS ARCHIVE'S OWN DATA, THREE HOURS APART. «cognome=Cassaniti» returns nothing for the whole of Italy, and it was recorded as a control-tested real negative. The same afternoon this archive read CASSANITI GAETANO in the Piedimonte 1848 birth Tavola and VENERA CASSANITI in two separate acts. The family was in the registers the whole time. The nil was true and meant nothing.
Any index, corpus or search form standing between you and a register
Coverage fails in THREE places and all three look like one zero — «Not covered» is not one thing. The Lerena archive, putting its own cases beside this archive's, found three distinct failures that render an identical empty page. (1) AT THE COLLECTION -- the corpus does not hold that record type at all. Its Andalusian full-text corpus holds nobility and notarial records and NO PARISH REGISTERS; this archive's Piedimonte and Mascali are the same failure, comuni the name index never covered. (2) AT THE QUERY SHAPE -- the indexed name is a compound, «Lerena y Armenta», that exact matching cannot reach. (3) AT A SINGLE FIELD -- the source failed to parse the mother's surname, so asking for it excluded the records that display it correctly.
Name which of the three you have ruled out before filing a nil. The cheapest discriminators: drop the most specific parameter and see if the count moves (catches 3); try a substring or a variant spelling (catches 2); and look up whether the comune, parish or year range is in the index at all (catches 1). ONLY THE THIRD KIND IS EVER EVIDENCE ABOUT A FAMILY -- and only after the first two are excluded.
Caution. ONLY ONE OF THE FOUR NULLS THE LERENA ARCHIVE PUBLISHED SURVIVED SCRUTINY, and it survived for a reason that is not visible on the results page: its control had established that the parish books were INDEXED AND DATED. The other three read identically. SO THE PART OF A NIL THAT AGES WELL IS NOT THE QUERY AND NOT THE COUNT -- it is the sentence saying WHAT THE INSTRUMENT COULD HAVE REACHED. A searched row that records only «returned nothing» is unfalsifiable a week later.
Any builder that folds many rows into one key -- a per-place, per-comune or per-person summary
The reversal test: does a file's ORDER decide what you publish? — A many-to-one join written with `=` in a loop lets the LAST ROW WIN. It renders correctly for as long as the file happens to be in a helpful order, and then changes meaning when somebody appends a row. The failure looks like a data update, not a bug.
REVERSE THE SOURCE FILE AND RE-RUN THE BUILDER. Identical output means the fold has a rule. Different output means the file's order is deciding what you say, and nobody wrote that rule down. Restore the file in a `finally`, and compute the reversed text BEFORE opening the file for writing.
Caution. COMPARE FACTS, NOT BYTES. Most builders emit a LIST in file order, so reversing the input reverses the list and the bytes differ for a reason that is presentation and not data loss -- six of this archive's eight pairs «failed» that way and every one was benign. Canonicalise both outputs by sorting every list by its own contents, then compare. Six false alarms became one true one: a question number that was really a row position, rendered on the page as though it were an identity.
Giarre, Catania, annual birth Tavole -- and any index with late-registered acts
The alphabet is repeated at the END of the index — An annual Tavola that runs A to Z looks finished at Z. IT IS NOT. Giarre's clerks APPEND EXTRA LETTER-SECTIONS AFTER Z for acts registered after the index was drawn up, and they say so: the Osservazioni column of the 1848 index reads «IN FINE DELL'ALFABETO RIPORTATA ALTRA VOLTA LA LETTERA M». 1848 appends F and M; 1841 appends F and B; 1842 and 1843 append others.
AFTER READING A SECTION, READ THE LAST TWO OR THREE IMAGES OF THE VOLUME as well, and look for a second run of headings. A band of the name column across the final openings shows them at a glance. Only then is «the section is empty» a finished reading.
Caution. THIS IS THIS ARCHIVE'S OLDEST MISTAKE IN A NEW PLACE. The rule was already «find the section's END before writing not there» -- learned when a name sat four entries past where a reading stopped, and again when an index section ran across a page break. Here the section's end is not even in the same part of the book: the alphabet finishes, and then starts again. A negative taken from the main run alone is INCOMPLETE, not wrong, and must be recorded as incomplete. AND THE APPENDIX IS A HABIT, NOT A RULE, WHICH IS THE SHARPER HALF OF THIS. Of eleven Giarre years, NINE append something after Z -- T, P, B, F, R, M, C, G in various combinations -- and TWO APPEND NOTHING AT ALL. 1846 ends at Z with a blank facing page; 1847 ends at Z with two more Zappala. So a volume with no appendix looks EXACTLY LIKE a volume whose appendix you have not reached, and «I saw no second run of headings» is only a finished reading if you went to the LAST IMAGE and saw the blank.
Any search form -- Antenati, FamilySearch, NAA, the Queensland BDM
A control that CANNOT be zero, and a second search path — This archive's rule was: a zero is not recordable until a control in the same form and session returns a known result. The Lerena archive ran exactly that rule and the zero was still false. Its FamilySearch session had expired; the search printed «Historical Record Search Results (0)» and «No Results Found» for every query, stably, across two reads and a ninety-second wait -- and its control, chosen because it OUGHT to return records, had passed that morning.
THREE THINGS FIX IT. (1) THE CONTROL MUST BE ARITHMETICALLY IMPOSSIBLE TO BE ZERO, not merely likely to return something. «Gonzalez in Uruguay» cannot be nil in a collection of millions; «Arena at Scilla» merely ought not to be. (2) THE CONTROL MUST BE RECENT -- healthy this morning is not healthy now; run it in the same minute as the query it guards. (3) ASK A SECOND SEARCH PATH ON THE SAME SOURCE. Where a provider has two, they fail differently: FamilySearch's full-text search redirected honestly to a sign-in page in the same minute that its record search was manufacturing nulls.
Caution. AND WHEN A NULL LOOKS LIKE A DISCOVERY, SUSPECT IT HARDEST. The Lerena archive was drafting a real and rather good mechanism -- that parent-pair queries reach only the keyed index and cannot see full-text-only acts -- which explained every observation it had and was built entirely on an expired cookie. A mechanism that explains all the evidence is exactly what an outage manufactures. THE ONE CLASS THAT STAYS SAFE: a zero that a DELETED PARAMETER TURNED INTO A RESULT, because a positive result proves the service was answering at that moment. Only zeros that stayed zero are in doubt. TESTED AGAINST ANTENATI, 21 September, and it holds there for a structural reason: the register search is PUBLIC AND STATELESS -- signed-out output is byte-identical to signed-in -- so there is no session to expire. Its true zero is a 266 KB page carrying «Nessun risultato trovato»; its throttle is 520 bytes titled «403 Forbidden». Distinguishable by size alone.
Mascali, Catania — and to be tested at every new comune before anything is cleared
The sections of an index are not always in alphabetical order — An annual Tavola looks alphabetical, so the fast way to clear a year is to find the M section and check it into the next letter: if M runs straight into P, there is no N and the year is a negative in one look. AT MASCALI THAT REASONING IS INVALID. The marriage Tavola of 1847 writes its headings C, then N, then M. 1841 and 1835 put V before S. It is not one clerk slipping — it is how that office worked, and the plate on the Mascali page shows it.
READ ONE WHOLE TAVOLA AT A NEW COMUNE FIRST, first heading to «Fine», before trusting any junction. tools/montage_pages.py makes that affordable: it crops the same narrow strip from several pages and stands them side by side, so a volume's whole table is one look. Riposto's are ordered and complete; Mascali's are not. Where a sweep has already been done at the junction, do not quietly keep the negatives — mark them PROVISIONAL and say so on the page.
Caution. THIS COST NINE PUBLISHED NEGATIVES THEIR CERTAINTY. The Mascali birth years 1839-1848 were cleared at the junction before this was known, and they are now marked provisional on the Mascali page and on work-list row 180. WHAT WAS FOUND IS UNTOUCHED — Alfio Nicotra and Carmela Sudieri are still there in 1840 and 1847. Only the NEGATIVES are weaker than they were written. And note the shape: this is the SAME FAILURE as the appendix after Z, one row above — both are «the section's end is not where you assume», and this archive has now met it three times.
The five words
All seven of these family archives grade a claim with the same five words, so a level means the same thing wherever you meet it. The word is always printed next to the colour, because a reader should never have to know the palette to know the confidence.
- Documented
- A record was read, and it says this. The source is named.
- Probable
- The evidence points one way and nothing found so far points the other. Not proven.
- Inferred
- Reasoned from what is known — a gap of the right size, a name in the right place — rather than witnessed in a record.
- Family
- Told, remembered, or written on a family chart. Kept, because discarding it would lose the lead; labelled, because it is not evidence.
- Disputed
- Two sources disagree and neither has been ruled out. Both are shown.
Not claimed
Some pages carry this instead. It states the thing a reader is likely to assume — the connection that would be tidy, the identification that almost works — and says plainly that this archive does not assert it. An archive is judged as much by what it refuses to say as by what it says.
Almost everything in this archive currently sits at the family level of the ladder above: asserted by the family tree, and not yet by a document. The tree this site was built from is a MyHeritage tree contributed by Michael Mazza and relatives. Where it cites Ancestry indexes, this site says so; where it cites nothing — which is most of it — this site says that too. Converting those assertions into documents is the work.
Dates, and who does not get one
The companion Falco archive names living relatives and publishes nothing else about them at all. That rule was tried here first and it failed badly: the test it rests on treats a person as possibly alive unless the tree records a death — and 411 of these 707 people have no death recorded, because most of this tree is undated, not alive. Only 95 people in it have a death anywhere. Suppressing seven-tenths of an archive makes it unreadable without making anybody safer.
So this archive uses a narrower rule, set by David on 10 September 2026:
Anyone who would be 80 or younger today, and whose death is not recorded, has their dates withheld. Their name, their places, their family, their photographs and their records are all published. Only the dates are held back.
That covers 131 people. It deliberately does not cover anyone the tree records as dead: a death date is a documented fact about a person with no remaining interest in privacy, and withholding it would gut the archive — Mary Rosa Mazza died at sixteen, and an archive that will not say so is not telling the truth about this family.
The withheld dates are stripped in the build, not hidden by the page. They
are not in the HTML, not in the JSON the page loads, and not recoverable from the published
site. Both rules are switches in tools/build.py —
SUPPRESS_LIVING and AGE_THRESHOLD — so either can be tightened in one
line and a rebuild.
A removal request is honoured within days, without argument and without requiring a reason.
Why the archive refuses to merge 57 names
The export contains four men called Rosario Mazza, four called Giuseppe Arena, three called Orazio Mazza and four called Maria Mazza — most of them with no date of any kind. In three southern Italian towns where the same fifteen forenames circulate for two centuries, and where a grandson is named for his grandfather by rule, that is exactly what you would expect.
An earlier version of this build merged people on name and name alone. It fused four unrelated Rosario Mazza stubs into one man and produced an eleven-generation Mazza descent that no record supports — a pedigree manufactured by a bug. The rule now is:
A shared name is not evidence. Two records are the same person only if they give the same birth year, or if they sit in the same place in the family — the same parents, or the same spouse and children. Anything less is recorded as an open question and left as two people.
Under that rule 22 genuine duplicates were merged — including the whole of Frank Mazza's household, which the tree holds twice — and 57 shared names were left standing apart. The archive would rather be visibly incomplete than invisibly wrong.
And one way the rule was too strict
A rule that keys on the exact name is defeated by a single middle initial. The tree holds Joseph A Polistena and Joseph Polistena as two men — same wife, same full death date, 15 February 2012, same grave at Arneytown, New Jersey. It also holds Michael Mazza and Michael Rocco Mazza, same parents, both born 1988. One man each time, and the first version of this build refused to join either.
So names are compared a second time at a looser key — surname plus first forename, middle names and initials dropped — and because that test is weaker, the corroboration demanded is stronger: an identical full death date, or identical parents and identical spouse, or the same birth year plus one of those. Across the whole export that widened rule found exactly two further people, and both are named on this page rather than merged quietly.
One tree, or 10 pieces?
The export is not a tree. It is 10 disconnected components: one of 577 people, one of 7, and twelve fragments. A family-tree program will draw them on one canvas and let you believe they are one family. This site labels every person with the component they belong to and refuses to imply a join that no record makes. What it would take to join them →