The Defranceschi Archive
What these sources actually do, as opposed to what they appear to do

Method

Everything this archive learned the hard way about reading Istrian registers online — written down so the next person does not have to learn it the same way.

This page exists because most of what went wrong here went wrong in the same way: a tool answered a question that was not the one being asked, and answered it confidently. None of what follows is theory. Every item was found by getting something wrong and then finding out.

  1. 01

    A number that is typed goes stale the day after

    The working notes carried a backlog line: «161 people with no place · 56 unplaced households · 55 suppressed charts to review by hand». All three were typed once and never recomputed. Checked on 13 September 2026: one household has no place, not 56. And 763 of 1,056 dossiers have no pedigree chart, not 55 — the note was wrong by a factor of fourteen, in the direction that makes the job look done.

    This archive has already recorded the same failure on a public page — «nine parishes» hand-typed beside a computed 1,151, when the real figure was fourteen — and the lesson written then was «any figure a page states should be derived, not typed». The notes were never held to it.

    There is now scripts/audit.py, and publish.sh runs it on every publish: roster and household counts, register rows by status, dossiers without a chart, places holding accepted records that appear on no lane, and towns written in the register under more than one name. That last check is the one that would have caught Vitipolis — it prints «rijeka: Fiume · Rijeka · Vitipolis» in three words.

    A build that cannot fail its own audit is not a check. If the audit script errors, the publish stops.

  2. 02

    Three easy wins, and why none was taken

    162 people in this archive have no place. Broken down, that is 104 from the family tree — which records no place for them, and which is David's worklist, not a machine's — and 55 from the record index, plus three strays.

    The 55 looked mechanical: match the name to a register row and take its place. Run against the whole register, exactly three of the fifty-five match a single place: Josephus Jelčić and Josephus Ruman to Ližnjan, Antonio Franceschi to Almissa.

    None of the three has been applied. All three are joins on a name and nothing else — the precise move this archive has a whole page of corrections about, including a portrait hung on the wrong man and a pedigree spliced at the wrong join. A 2% yield is not worth re-opening that door, and the third is a Franceschi, not a Defranceschi, which is a different question again.

    The useful output was not a fix but a decomposition: «162 unplaced» is one number hiding two different problems, of which 104 cannot be solved here at all. The audit now prints the breakdown, so nobody mistakes it for one backlog.

  3. 03

    The correction I nearly published

    Re-reading image 561, this archive's published transcription — «Andrea Palin q.m Pio» — looked wrong. At the zoom where a page can be scanned in one pass it plainly read «q.m Gio.», Giovanni, which is one of the commonest patronymics in the book, where Pio is rare. A correction was drafted.

    It was checked first, and it was the correction that was wrong. At full magnification the letter has a straight stem and a closed bowl at the top — the same P as in Pasqua and Pinzan four rows away — and nothing like the looped G of Giovanni, Giacomo and Giovanna on the same page. The published reading is right.

    The lesson is the mirror of one already on this page. «Every candidate has to be re-read at full magnification before it is written down» was recorded here about finding a name. It applies exactly as hard to unfinding one. A correction is a claim, and it needs the same evidence as the claim it corrects — and the tell was there to be noticed: the reading that felt wrong was the more common name, which is what a tired eye supplies.

  4. 04

    A frame is two pages, and the left one is off-screen

    A day's reading of the Vodnjan death register nearly went into the archive with a hole in it.

    Each frame of DGS 005497894 photographs a two-page opening, and the viewer opens showing the right-hand page. The left page is off-screen, and zooming out does not reveal it — the zoom steps stop before the frame is fully fitted, so what looks like the whole image is not.

    It was caught by arithmetic, not by looking. Image 564 ended at entry 135 and image 565 appeared to begin at entry 153. Seventeen entries had no frame to live on, which is impossible — so something was being missed. Panning hard left on 565 found book page 162, entries 136–152, sitting there unread.

    The correction is a habit, not a fix: on every frame, pan fully left before reading, and check that the first entry number continues the last one. The entry numbers are a running checksum the register keeps for you, and they are the cheapest verification in this whole project.

    It also means images 562 and 563 are only partly read — their left-hand pages were never opened, and entries 96–119, June to August 1831, are still unread. That is written into the queue rather than quietly left for the next person to trip over.

  5. 05

    Search the place, not the name

    FamilySearch's full-text search was tested on 13 September 2026, after standing at the head of this archive's queue for days as the one question that could make weeks of work unnecessary. The answer is no, and then yes to something else.

    No: the Croatian parish registers are not in it. Searching Gologorica returns nothing from Istria. The plan to read the Vodnjan books opening by opening stands exactly as it was.

    Yes: what is in it, at full text, is the American paper — naturalisation petitions, declarations of intention, passenger and crew manifests. And that changes the question you can ask. Until now this archive searched for a surname. Full text lets you search for the village, and get back everyone who was born there whatever they were called.

    «I was born in Gologorica Austria ... on February 21 1886. My race is So. Italian» — Giovanni Udovicich, petition for citizenship, Brooklyn, 1929. «visible distinctive marks Slavonian race ... I was born in Italian Gologorica Estra, Austria» — a woman's declaration of intention at Tacoma, Washington, who had married a Joseph on 12 November 1893. Neither is a De Franceschi. Both are from a village of a few hundred people that this family also came out of, and that is the point: the emigration was a village, not a surname, and this is the first tool that can see it. Note what the clerks wrote in the race box — «So. Italian» for one, «Slavonian» for the other, for two people out of the same village.

    The counts, corrected. An earlier version of this page reported 1,952 results for Gologorica. That figure was a year scraped out of a collection title by a careless pattern, and it was published under a sentence admitting it looked wrong. The real numbers, counted off the result pages:

    Gologorica 19 · Ližnjan 2 · Gračišće three pages · Crikvenica fifteen · Defranceschi about 9,900.

    And Vodnjan returns nothing, because the Croatian name is younger than every record in the corpus. The town is Dignano there — about 12,200 hits, most of them the other Dignano, in Friuli. Search the name the clerk would have written, not the name on today's map.

    Nineteen is the important number. It is small enough to read end to end, which is what makes a village sweep a piece of work rather than a wish.

  6. 06

    Find the index the clerks already made

    The Corsican archive has no search box — every module wants a commune, a date and a record type, and says so. That looks like the same wall as Vodnjan: images, read by eye, thousands of them.

    It is not, because of one line in a dropdown. Among the record types sits TABLE DÉCENNALE — the alphabetical ten-yearly index French civil registration compiled for every commune between 1793 and 1902. Eleven index pages per commune, read down one letter, against ten years of acts read line by line.

    The general rule: before reading a series, ask whether its own clerks indexed it. French tables décennales, Italian indici decennali, English parish transcripts, Habsburg Namensverzeichnisse — where a bureaucracy had to find its own records again, it built a finding aid, and that finding aid is usually filmed alongside the register and ignored.

    And the corollary, which is the unhappy half: Vodnjan has no such thing. An Austrian Liber Defunctorum was never indexed, which is exactly why that death register has to be read image by image and Corsica does not.

  7. 07

    Test the cheap lever before starting the expensive campaign

    The way to match a project that has read a whole town is to read a whole town — for this family that means Vodnjan, and the death register alone is roughly 105 images and 4,600 entries, at something like fourteen tool operations per image.

    Before any of that, one question is worth a single request: is the text inside these images already machine-readable? FamilySearch has been extending handwriting recognition across its collections. If the Croatian church books are included, the campaign becomes a query. It is untested, and it is recorded as a maybe rather than a plan.

    The general rule is worth keeping past this instance. A route that would take weeks deserves an hour spent looking for a route that takes minutes — and the looking should happen before the first week is spent, not after the third.

  8. 08

    Show the record, not a family reconstructed from it

    759 person pages said only «no family is drawn for this name». True, and useless.

    153 of them turned out to have an indexed entry, and 289 records across the site name other people on the same page — a parent, a spouse, a godparent, a witness. That is worth showing, and it is emphatically not worth drawing as a family.

    So those pages now carry the record itself: the person, what the index says happened, where, and everyone else named on the same entry, each linked if this archive knows them. Under it, in the archive's own words: this is a record, not a family — the index names these people on one page and does not say how they are related; a parent, a spouse and a godparent look identical here.

    The distinction is the whole point. The temptation on a thin page is to promote a co-occurrence into a relationship, and it is how most bad genealogy is made. Showing the raw entry satisfies the reader's question — what do you actually have on this person? — without answering a question the record never answered.

  9. 09

    Look in your own files before you look anywhere else

    Of the 302 people carrying no year at all, the largest single recovery came from nowhere new. 25 of them already had a dated entry somewhere in this project's own data — eighteen in burials.json, three in graves.json, three in the Gologorica file, one in a household — and it had simply never been copied onto the roster row.

    That is the second time in two days. Twelve more had the year sitting in their own indexed record, whose id was already on their row; nobody had followed it.

    The general shape of the error: this archive grew page by page, each page loading its own data file, and a fact entered for one page does not travel to another. Before opening an archive, a film or a login, the cheapest possible search is a sweep of every JSON file in the project for a name and a year. It took one script and it beat every external source tried today.

  10. 10

    Never mine your own prose for dates

    302 people in this archive carried no year at all. Three routes were tried to give them one.

    Two worked and are safe: the person's own indexed record (12 people) and a dated entry in a household (29). Both are a record about that person.

    The third was reading the years out of the archive's own note fields, and it had to be abandoned. Seventy-four notes contain a year; only five yielded an explicit born or died, and one of those five was wrong — a note reading «Giuseppe De Franceschi q.m Pietro and Lucia De Franceschi q.m Pietro, both dead in 1830» was parsed as Pietro died in 1830. It was his children who died in 1830. He was born around 1730.

    The reason is structural and worth stating: a note in this archive is about relationships, and relationships are described using other people's dates. «Dead by 1823, when his daughter married» is a sentence about a daughter. One in five wrong is a catastrophic rate for something applied to hundreds of rows, and no amount of pattern-tightening fixes a source that is talking about somebody else.

  11. 11

    An estimate may reject; it may never confirm

    Where a person is a parent in a dated household, a birth year can be estimated — twenty-seven years before the first child, in a window from thirty-eight to eighteen years before. 64 people now carry such an estimate.

    It is stored in its own field and never written into the date columns, so nothing downstream can mistake it for a record. On a person page it says estimated, not recorded, in the same breath as the number.

    And it is used one way only. It can throw out an absurdity — a household beginning three centuries adrift. It cannot confirm a link, and the page says so. In this pass it rejected nothing, which is the honest outcome to report: the estimates agreed with every household they were tested against, and agreement of that kind is worth very little.

  12. 12

    The index writes Latin in the genitive, and it doubles your families

    Baptism entries name the parents in the genitivefilius Josephi Defranceschi et Mariæ, son of Joseph and of Maria. The indexer transcribes what is written, so the same couple appears as Josephi × Mariæ on one child and Giuseppe × Maria on the next, and any matching done on the raw strings counts them twice.

    Mining the catch for households produced 100 parent-pairs before this was handled and 48 after. The fix has three parts: map the genitive forms to one canonical given name (Valentini → Valentino, Ursulæ → Orsola, Joannis → Giovanni), collapse doubled letters and the -ich / -ć endings so Miccoli and Micoli, Nascovich and Nasković land together, and match on first given name plus surname only, discarding middle names — otherwise Lucia and Lucia Michiela are two women.

    What survives the cleaning still is not proof. Three pairs remain that might be one household each and are deliberately left as two.

  13. 13

    Before you accept a refusal, check your own URL

    A 403 stopped this archive for most of a day, and it was self-inflicted. FamilySearch's Deep Zoom tiles are at …/dgs:FILM_IMAGE/image_files/{level}/{col}_{row}.jpg; the reader had dropped image_files and was requesting a path that does not exist. The security service answered the unknown path with 403 and an Incapsula page, which reads exactly like a ban.

    The correct response to any refusal is still to stop — and that was done. But the first diagnostic should have been: does image.xml still work, and is the tile URL the one the service documents? image.xml was returning 200 the whole time, which was the clue and was not followed. One well-formed request would have settled it.

    A block and a bug produce the same status code. Tell them apart before you write either one down.

  14. 14

    Screenshots are downscaled — do the arithmetic

    The reading canvas is drawn at CSS pixels in a 1194 × 1054 viewport, and the screenshot comes back at 800 × 706 — a 0.67 reduction. Twice today a crop was computed by measuring a feature on the screenshot and multiplying straight into image coordinates, and twice it landed on blank paper.

    The chain is: screenshot px ÷ 0.67 → canvas px ÷ scale → image px. Miss the first step and every crop is a third too far up and to the left. The corollary is worth having too: because the whole viewport is squeezed into 800 px, a bigger canvas yields a sharper screenshot. Drawing at 1190 wide instead of 1020 is free legibility.

  15. 15

    Read the catch before you read the film

    On 10 September the plan was to read a hundred images of the Vodnjan death register by eye. The tile server blocked, so the 1,508-row harvest sitting in the project from the day before was read for parent-pairs instead — and it gave four households the archive did not have, plus two children for households that were already standing.

    The lesson is not that the index beats the film; it does not, and the deaths this reading was after are not in the index at all. The lesson is about order. Reading a register by eye is the most expensive thing this archive does, at roughly one page per minute of attention, and it was about to be spent looking for facts already in hand. Mine what you have harvested before you open the film, and go to the film for what the mining could not answer.

  16. 16

    When the service says stop, stop — again

    FamilySearch's tile endpoint returned 403 from Incapsula on the first request of the session: no CAPTCHA, no retry-after, no negotiation offered. The reading stopped. No user-agent was changed, no pacing was tried, no second route was looked for.

    This is the second time it has happened and the second time nothing was attempted. It is worth writing down twice, because the temptation is strongest exactly when the block lands mid-sentence — the register was open at image 560 and the next fourteen frames were the ones that mattered. The correct move is still to record where you stopped and why, and wait. It is on the Search Register as blocked, with the three deaths it was going to answer named.

  17. 17

    The place parameter does not filter

    On FamilySearch's persona search, q.anyPlace is a relevance boost, not a filter. Tested with ten values — Vižinada, Draguč, Dubrovnik, Vodnjan, Rovinj, Gračišće, Kaštelir, Ližnjan, and the controls «Zzzznowhere» and «Atlantis». Every single one returned the same total: 3,652. An unrecognised place is silently ignored and you get the whole set back, with no error.

    Vižinada and Draguč return identical result sets. f.recordPlace is a real filter but rejects plain town names.

    Never count records by place with these parameters. Any number so derived is a count of however many rows you took off the top of a re-ranked list.

  18. 18

    A results count is not a promise

    FamilySearch's persona search reports 3,652 results and will hand over roughly 1,800. Past that offset it does not error, does not warn, and does not stop — it silently wraps back to page one and serves the same records again, HTTP 200. Offsets 1,800, 2,600 and 3,600 all returned the identical first page, beginning with the same man, XQMM-LVSJ.

    The practical rule: page until the first record repeats, then stop and say so. The catch on The Register is 1,800 raw, 1,508 after de-duplication. It is not 3,652, and the 3,652 must never be quoted as a count of anything retrievable.

  19. 19

    Harvest with the record id in hand

    Every one of the 1,508 rows on The Register carries a live link, because the persona id was written down at the moment the row was taken, not looked up afterwards. Going back for the ids later is the expensive version of the same work, and usually it never happens — which is how a register ends up with a source column full of blanks. Record the id as you go, or the reach cannot be audited.

  20. 20

    A film can carry more than one parish

    The catalogue answers a film-number query with the first creator on the reel, and says nothing about the rest. DGS 005497893 returns «Rimokatolička crkva. Župa Vižinada» — and carries Vižinada's deaths 1754–1831 and Vodnjan's baptisms 1815–1866.

    This archive published a confident correction on the strength of that heading, moving seventy-eight records to the wrong parish, and had to retract it within the hour. Resolve to the film, then open the catalogue item list. Never stop at the film heading.

  21. 21

    An index blank is not an absence

    Thirty-nine Istrian places returned nothing in the eighteen-town sweep — including Gračišće, Gologorica and Crikvenica, where this archive holds register entries in its own files.

    Those registers are on FamilySearch as browse-only images that no volunteer has indexed. The two most important pages this project holds were obtained by writing to an archive, not by searching.

    There is a second reason, discovered later: since the place parameter does not filter, a search can only ever see what ranks into the top hundred of a re-ranked list. A blank is a statement about ranking and indexing, not about a province.

  22. 22

    The best records are in the books nobody has indexed

    The Vodnjan marriage register, 1815–1884, is indexed nowhere on earth — 286 marriage-query arks were resolved against its film and not one is on it.

    Read by eye, opening by opening, it produced in two days: five generations, three separate households, five women who had married out of the name, a priest, a ploughman, a weaver and a shoemaker — and the parents, grandparents and death-brackets of people the indexed baptism register could only name.

    The unindexed book was worth more than every indexed search this project has run. That is the single most useful thing on this page.

  23. 23

    Read the widows' entries first

    A first marriage names the couple. A widow's remarriage names her parents, because the clerk has to establish she is free to marry.

    The deepest generation this archive reached at Vodnjan — Gio. Maria De Franceschi fu Pietro and Michiela Zambaletta fu Cristoforo, a couple who appear in no baptism register on any film — came out of their daughter remarrying at forty-nine. If you are scanning a marriage register for depth, the widows are where it is.

  24. 24

    The patronymic is the only thing worth trusting

    Vodnjan produced four men called Pietro De Franceschi and two called Cristoforo, alive in one small town at the same time. They are told apart by «di Giuseppe» against «q.m Gio: Maria» — the father's name — and by nothing else.

    And the difference between di (father living) and q.m / fu (father dead) is itself evidence: it brackets Giuseppe De Franceschi's death to between November 1828 and February 1833, purely from how his sons are written.

  25. 25

    A formula is not a fact about a person

    «De Parochi licentia» — by the parish priest's licence — appears against Don Stefano De Franceschi at a baptism in 1816 and at a marriage in 1833. This archive read that as his particular standing and published it.

    The very next entry uses the identical formula of Don Pietro Bradamante. It is the register's standard wording for any deputising priest.

    Before making something of a phrase, look for it against somebody else.

  26. 26

    A claim about an unfinished register is a claim about the part you have read

    This archive said, repeatedly, that Don Stefano appeared nineteen times as a witness and never once as the officiant — while sixty openings of that book were still shut. On image 213 he marries a couple himself.

    The honest form of that sentence was always «in the entries read so far». It costs four words.

  27. 27

    Names that will trap you

    In this parish, ruled out by eye rather than by string-matching:

    · Franceschich — a Slavic patronymic out of Buzet. Not this name. · Francin — its own Vodnjan family. Not this name — but Pietro De Franceschi's first wife was a Francin, so the two are a household deep in each other and a loose search produces nonsense in both directions. · De Marchi, De Maria, De Rocchi, Del Carro — the register is full of De surnames in the same hand.

  28. 28

    Check the photograph against something

    A hand-tinted portrait was published here for months as Josip Defranceschi of Crikvenica, the direct line's only likeness. It is from the Imotski branch.

    Every register plate on that same page had been checked against Pazin and Ledenice. The portrait was never checked against anything at all — it carried a name on a card, and the line had a man of that name.

    Two branches' photographs sit in one family collection. So do two branches' pedigrees: the retired 2018 GEDCOM spliced Imotski onto this line too.

  29. 29

    Do not let a pipe hide a failure

    npm run build | tail -2 reports the exit status of tail, not of the build. A broken page went live twice before this was taken seriously.

    There is now a publish script that builds without a pipe, checks that every source page produced an output file, and refuses to commit or push if either fails.

  30. 30

    Check that your own crop is not being cut off

    The tile reader used to read these registers draws a canvas and the browser clips it to the viewport rather than scaling it down. A crop 906 pixels tall in a pane 728 pixels tall silently loses the bottom fifth of every page — with no error and no visible edge.

    This was running for several openings of the Vodnjan death register before it was noticed, and the fix is arithmetic: crop height × scale must be smaller than the pane. Any page scanned before the fix has to be scanned again.

    The general form: when a tool renders rather than reports, measure what it actually gave you against what you asked for.

  31. 31

    When the service says stop, stop

    On 10 September 2026, after two days of reading register images tile by tile, FamilySearch returned 403 — «This request was blocked by our security service» on both the search API and the image service.

    That is a legitimate answer and it was accepted. No proxy, no delay-and-retry, no attempt to look like a different client. This archive does not bypass bot protection, and the reason is not only that it would be wrong: a family archive's only real asset is that its claims can be trusted, and an archive that cheats a source to get them has nothing.

    The practical lesson for anyone reading registers this way: the tile reader is doing hundreds of requests per opening. Read in short sessions, cache what you pull, and expect that a service which has given you five generations in two days may reasonably decide that is enough for now.

None of this is a complaint about the sources. FamilySearch's films are the reason any of this was possible at all, and the volunteers who indexed the baptisms saved months. The point is narrower: these tools answer the question you actually asked, which is often not the question you meant — and the only defence is to open the image.

Compiled 10 September 2026 from this archive's own mistakes. Each item is documented at length on Corrections, and every search behind them is logged in the Search Register.

Corrections → · The Search Register → · The sweep, and the test of it → · What the unindexed book gave →