← Oop vrae

Vrae wat beantwoord is

42 questions this project set itself and has since answered. Each one carries what was expected, what was actually found, and what settled it. Some were answered by proving the expectation wrong.

  1. Morgen or hectares? extent_text may be inconsistent LEAD-0007

    Are the figures in parcels.extent_text really morgen, or are some of them hectares mislabelled as morgen?

    Wat dit sou uitmaak: Reading the figure and its unit directly off the diagrams for the nine flagged parcels.

    Wat dit beslis het: Found 29 Jul 2026 by cross-checking the cadastre against extent_text. Per section 10, reported and not silently corrected: the fix is to read the diagrams, not to pick a factor. Until it is settled, treat extent_text as the historic record AS TRANSCRIBED and sg_area_ha as the modern measured area, and do not present either as confirming the other. | CLOSED 1 Aug 2026, AND THE ANSWER IS THAT THE UNIT IS MORGEN. Tested rather than assumed: for every one of the ten parcels whose stated extent still disagrees with its cadastre polygon, reading the figure as HECTARES makes the fit WORSE, not better. Oorlogs Kloof 16,124 against a ratio of 0.42 as morgen and 0.36 as hectares; Bloemendaal 0.52 against 0.45; Witberg 0.60 against 0.52. If any figure had been hectares mislabelled, its ratio would have moved towards 1 and none does. So extent_text is trustworthy as to unit. THE RESIDUAL DISAGREEMENT IS A DIFFERENT QUESTION and it is subdivision: the historic figure is the whole original farm and the polygon matched is one modern portion of it, which is the Modderdrift pattern written up on PAR-000099. One outlier does not fit that: Swanepoel's Aanleg is 2,000 morgen against a cadastre polygon of 11,464 ha, six times LARGER, which reads as a match to a consolidated modern farm and is worth its own look. Recorded on the parcel rather than reopened here.

    Middelwater · Groot Rivier (Varsche Fontein Nr. 27 Gdlt 2) · Plaat Fontein (Varsche Fontein Nr. 27 Gdlt 3) · Kopjes Kraal · Kromrivier (Kopjes Kraal Nr. 123 Gdlt 1) · Brand Kraal (Rondabel Nr. 124 Gdlt 3)

    geopen 2026-07-29

  2. Which Rondabel - Tarka (east) or Traka (Koup)? LEAD-0014

    Do the 1818 du Plessis and 1823 de Bruin inventories ('leeningsplaats Rondabel aan de Tarca / in Tarka') describe the Prince Albert Rondabel No. 124 (PAR-000009), or a namesake loan farm in the eastern-Cape Tarka?

    Wat ons verwag het: Genuinely uncertain. EAST: the 'Tarka' reading; the 600 Rd sheep debt to a Grahamstown butcher (1823); the 1815 Graaff-Reinet baptism. KOUP: Tarca/Traka spelling drift is normal; Zacharias de Beer (the Kweekvallei / Prince Albert family) as a debtor; and Graaff-Reinet was the whole Koup's church before 1820 (PLC-000013), so the baptism does not discriminate.

    Wat dit sou uitmaak: Placing Greyling's or van Wyk's veldkornetskap, or a loan-farm register entry locating the leeningsplaats Rondabel.

    Wat dit beslis het: Opened 30 Jul 2026, when FS LW51-CXR was identified as the 1823 widow. The risk was first flagged in the DOC-0033 transcription analysis as a same-name trap. Cross-bearing with LEAD-0013 (what 'district Albert' means). | 30 Jul 2026, later: Frans, on reading the full TANAP transcription of MOOC8/38.12, is DOUBTFUL of the de Bruin connection to PAR-000009 and is gathering more evidence. Additional east-leaning signals from the transcription: sons-in-law Krugel (Andszoon), Grobbelaar (Nicolaaszoon) and Jordaan (Gerritzoon) - three checkable marriage locations; witness George Aldrich, an English name; creditor wed. Theunis de Bruin. Treat the loan-farm era of the farm page as DISPUTED pending resolution. Note the person identification (PER-000049 = FS LW51-CXR) and the second-cousinship stand independently of this lead - only the farm link is in question. | 30 Jul 2026, MOOC8/44.48 (SRC-128) SHIFTS THIS LEAD MATERIALLY: when a clerk meant the Koup farm he wrote 'the place Rondavel ... field cornetcy of Hermanus van der Westhuisen in the Traka district of Beaufort' - farm, ward, region and district all named. The 1818/1823 inventories name none of these, say 'Tarka', and sold sheep to Grahamstown. The Koup Rondabel also now HAS its own documented loan-farm household (the Venters, OWN-000064) with a very different material profile (707 sheep vs de Bruin's 1,540, no slaves vs three). Working position strengthens: de Bruin/du Plessis PROBABLY an eastern namesake farm - still awaiting Frans's further evidence before OWN-000025 and the 1818/1823 rows are detached from PAR-000009. | ANSWERED 31 Jul 2026, from the day's own imports. The question assumed Traka might be an EASTERN namesake. It is not: Rondabel's own 1833 diagram (DOC-0023) places it in the FIELD CORNETCY OF TRAKA, and so do Vrolikheid, Oorlogs Kloof and Klipfontein on theirs. Traka was the ward these farms sat in, later renamed Kredouw. So the 1818 du Plessis and 1823 de Bruin inventories - 'leeningsplaats Rondabel aan de Tarca / in Tarka' - describe OUR Rondabel. Which means the 1823 widow Aletta Johanna Oosthuizen, second cousin of the root ancestor, was on this ground before the family reached Middelwater. | CORROBORATED, AND THE GEOGRAPHY UNDER THE NAME, 8 Aug 2026. This lead was answered on 31 Jul from the field cornetcy on Rondabel's own 1833 diagram. Three sheets that arrived in the two days since name Traka independently, from a document series that had nothing to do with the original question, and they turn an administrative label into a place on the ground. * DOORN KRAAL No. 116 (DOC-0248, diagram 1154/1863; DOC-0250, diagram 2103/1903) place that farm in the FIELD CORNETCY OF TRAKA, division of Beaufort. A different farm from any in the 31 Jul evidence, forty and eighty years apart, and it widens the ward: Traka held Doorn Kraal as well as Rondabel, Vrolikheid, Oorlogs Kloof and Klipfontein. * LEEUKRAAL No. 24 (DOC-0251, L.G. 8870/47) has the consolidated figure running down the middle of the TRAKA RIVER. The ward is named for a river, and the river is on a surveyed diagram. * TRAKAS KUILEN No. 15 (DOC-0255, SG 1283/1955) is a FARM named for the kuile of that river - the pools. PLC-000043 held the name from 7 Aug, read off the Leeukraal sheet, before this project had a row for the farm at all; PAR-000180 is the farm. So Traka is a river, the pools in it, a farm named for those pools, and the field cornetcy the whole basin was administered as - later renamed Kredouw. Nothing here reopens the lead. It removes the last of the reason to doubt it: an eastern Tarka namesake would have to explain why four separate surveyors, between 1833 and 1955, wrote Traka onto diagrams of ground in this basin. ONE MORE THING THE DOORN KRAAL SHEETS SAY, and it belongs beside LEAD-0013: both give the division as 'Beaufort, now Prince Albert'. That is the same administrative history that decides who counts as part of this project - Beaufort West was the district the Koup was governed from until Prince Albert was founded, which is why the scope rule on completeness.html treats a Beaufort West record as this region and not as somewhere a family came from.

    Rondabel · Doorn Kraal Nr. 116 · Leeukraal Nr. 24 (consolidated) · Trakas Kuilen Nr. 15 · Trakas Kuilen Nr. 15 Gdlt 1

    geopen 2026-07-30

  3. match_cadastre.py no longer reproduces the geometry on disk LEAD-0017

    Re-running match_cadastre.py against the current CSVs changes 11 parcels and does not reproduce what is in parcels.csv. Which is right?

    Wat ons verwag het: Some centroids were hand-entered rather than produced by the script - the Rhemhoogte and Oorlogs Kloof group carry 4-decimal values where the script writes 6, which is the signature of a hand entry.

    Wat dit sou uitmaak: Deciding per parcel whether the script's match or the hand entry is correct, then either fixing the script's name-matching or recording the hand values as deliberate.

    Wat dit beslis het: | CLOSED 1 Aug 2026. match_cadastre.py is idempotent again: a re-run against the current CSVs changes nothing, verified by diffing parcels.csv before and after. The eleven drifting parcels were symptoms of three faults fixed today. (1) The script read <repo>/geo/ while fetch_cadastre.py wrote data/geo/, so it was matching against a stale three-division pull. (2) It derived farm and portion by parsing a CSG_link URL and skipped any feature without one, which silently dropped every national polygon; it reads the 21-digit key now. (3) A hand-set key that named no feature fell back to the farm NUMBER and re-derived a wrong answer, which is what overwrote Oorlogskloof twice; a parcel that has been looked at and has no correct polygon now carries the NO-POLYGON sentinel and is left alone.

    Rietfontein · Faans Kraal (Vrolikheid Nr. 177 Gdlt 4) · Rietfontein (Zeekoegat district) · Swanepoel's Aanleg (Swanepoelsaanleg) · Oorlogs Kloof Nr. 172 (Roode Els Bosch and Oorlogs Kloof) · Oorlogs Kloof Nr. 175 (1940 consolidation)

    geopen 2026-07-30

  4. Which congregation baptised Jan de Bruijn in 1769? LEAD-0030

    The register page (SRC-168) gives the entry in full but not the church. If it is Roodezand/Tulbagh, the de Bruin family is a Tulbagh family and the Vrolykheid name-transfer of LEAD-0010 has a documented carrier. If it is Drakenstein or Swellendam, it does not.

    Wat ons verwag het: Genuinely open, and the surnames cut both ways. The opening is dominated by van der Merwe, du Plessis, du Preez, Viljoen, Joubert and Cronje, which is Drakenstein/Paarl Huguenot stock; but it also carries Venter, van Jaarsveld, Prinsloo, van Rensburg, Potgieter, Steijn and Liebenberg, who are trekboer families baptising at whatever congregation they could reach - and in 1769 the choice inland was Roodezand (Tulbagh) or Swellendam, since Graaff-Reinet was not founded until 1786. Note against the Tulbagh hypothesis: Jan Louis Venter (PER-000120) is recorded as born in the DRAKENSTEIN.

    Wat dit sou uitmaak: The waypoint. This is a thirty-second lookup, not a research task.

    Wat dit beslis het: Also on the same opening and worth chasing separately: entry 16, Jan Adriaan Venter x Cornelia Smit baptising a daughter Cornelia on 2 April 1769, witnesses Albert van Jaarsvelt and Hester Venter; and entry 25, Anna Martha Venter with Pieter Venter as witness. Whichever congregation this is, the de Bruijns and the Venters were in it together in 1769. | ANSWERED 31 Jul 2026, same day it was opened. The register is the TULBAGH ('t Land van Waveren) doopboek, begun 1743 - Jan de Bruin was baptised at Tulbagh, 16 April 1769. SRC-169.

    Jan de Bruin · Hendrik de Bruijn · Anna Loots · Rondabel · Vrolikheid · Vrolykheid Nr. 61 (Tulbagh)

    geopen 2026-07-31

  5. Going live: the decisions that have to be made before anything is published LEAD-0050

    What must be settled before this site goes on a public domain?

    Wat ons verwag het: Four are decisions, not work: (1) the FAMILY EXEMPTION - 16 living people including two minors - must come off for a public tier; (2) FAMILYSEARCH-DERIVED SCANS (24 sources) probably cannot be republished under their terms, so publish citation + transcription + ark link and NOT the image; (3) LEAD-0046, the 20 raster scans that never went through the document date gate; (4) the Afrikaans-first question, which is a translation job across 17 stories, not a switch.

    Wat dit sou uitmaak: on each, then a build with PUBLIC_RELEASE=True that passes the leak tests.

    Wat dit beslis het: A SHARED PASSWORD IS NOT A PRIVACY CONTROL AND MUST NOT BE TREATED AS ONE. It keeps material out of search engines and away from casual visitors. It does not survive being forwarded, and it is not a lawful basis for publishing personal information about living people. So the tiering is: PUBLIC = the history; GATED = the working apparatus (notes, leads, open questions) about people who are DEAD; LOCAL ONLY = living people. The password moves the second tier, never the third. | CLOSED 1 Aug 2026, the day the site went live. What was decided: the site ships as TWO builds from one tree, `build_site.py --public` for the public one and `build_site.py` for the full one, with the difference being exactly the 13 living family members. Frans chose the hybrid and accepted the risk in those words. The public build is at mense-van-die-koup.vercel.app. The private build is NOT deployed and the runbook says why: Vercel password protection has to be switched on BEFORE any real content goes up, or the full site including living people sits on a public URL for the length of that gap. This lead's own warning stands and is repeated in DEPLOY.md, that a shared password is not a privacy control. The remaining launch work is the Afrikaans translation, which is tracked as work rather than as a decision.

    geopen 2026-08-01

  6. Where is Kriedouw, and were the Oosthuizens there in July 1821? LEAD-0052

    The Beaufort West register puts the direct-ancestor couple's son born 'aan KRIEDOUW' on 26 July 1821. Most entries on the page say the same. Where is it, and how does it sit against the belief that the family established at Middelwater about 1821?

    Wat ons verwag het: That Kriedouw is a ward or a district the minister was covering rather than the family's own farm - it recurs on most entries on the page, which is not how a farm name behaves. If so it dates their REGION in July 1821 and not their address. EITHER WAY IT IS EVIDENCE OF A KIND THIS PROJECT RARELY GETS. Unlike the tree's place strings, which 5 treats as hostile because they were auto-geocoded, this is a PRIMARY record written by a clerk who was there. It still needs resolving to a gazetteer before it earns a map pin - fail closed - but it is a claim from the right kind of source.

    Wat dit sou uitmaak: A gazetteer or a map fixing Kriedouw, or an opgaafrol entry putting the couple on a named farm in 1820-22.

    Wat dit beslis het: Priority 1 because EVT-000002 dates the Oosthuizen establishment at Middelwater to about 1821 with a tilde, and this is a dated primary record of the same family in the same year at a named place. It either corroborates the arrival, refines it, or moves it. | [1 Aug 2026, re-read of DOC-0068 and DOC-0072] *** CLOSED, AND ANSWERED EXACTLY AS PREDICTED. *** This lead guessed that Kriedouw was 'a ward or a district the minister was covering rather than the family's own farm'. It is. Both 1934 diagrams of Vrolykheid's portions carry the printed words 'situate in the Field Cornetcy of', with TRAKA STRUCK OUT AND KREDOUW WRITTEN IN BY HAND. KREDOUW IS A FIELD CORNETCY - a veldkornetskap - in the Prince Albert division. SO WHAT THE 1821 BAPTISM ACTUALLY SAYS is that the direct-ancestor couple were IN THE KREDOUW WARD in July 1821, not on a farm called Kriedouw. It dates their REGION, which is still worth having: it is a primary record of where they were in the very year the family is thought to have established at Middelwater, and Vrolykheid - which is in that ward - adjoins Middelwater. It does NOT give an address and it earns no map pin. Worth keeping in view: the ward NAME changed. The surveyor struck out Traka twice in 1934, so Traka and Kredouw were both current at different times for overlapping ground, which is exactly the sort of thing that makes nineteenth-century place references slippery.

    Cornelis Andries Oosthuizen · Johanna Machteld Petronella Strydom

    geopen 2026-08-01

  7. Where is Drooge Kloof, the house Frans's father grew up in? LEAD-0064

    Drooge Kloof is a werf name in family use - Frans's father grew up in the house - and it is NOT a farm name in the Prince Albert cadastre. It appears twice in the paper, on two DIFFERENT pieces of ground: as the Government ground annexed into Middelwater No. 169 by the 1833 diagram, and as a struck-through 'Droege Kloof' against Portion 3 of Bloemendal Annex No. 164 on its 1913 verso. Which one is the family's?

    Wat ons verwag het: The Middelwater one, on the balance of what else is known: this family's ground is Middelwater, and A.J.H. Oosthuizen gave 'Droogekloof, Prince Albert' as his residence in 1922, four years before the Bloemendal Annex portion was transferred away in 1926. But that is an argument, not evidence, and the two are 25 km apart.

    Wat dit sou uitmaak: Frans saying which farm the house is on, or a coordinate.

    Wat dit beslis het: The general point is worth more than this one farm: THE CADASTRE RECORDS TITLE, NOT WHAT PEOPLE CALL THE GROUND THEY LIVE ON. Vischat on Rondabel is the same class (LEAD-0018), and there will be more. Such names need a location from family knowledge and should never be matched to a cadastral polygon by name. CLOSED 2 Aug 2026, SAME DAY IT WAS OPENED, and it should never have been opened. Frans had already pinned the house on 31 July: PLC-000035 'Droge Kloof (werf)' sits inside Middelwater, verified by point-in-polygon. The model also already carried the sharper version of this question as LEAD-0023, which asks whether MIDDELWATER PORTION 3 was known as Droge Kloof. I asked a question the record had answered because I did not read places.csv or the open leads before opening it — the STATE move in LOOP.md exists precisely to stop that, and I skipped it. Kept rather than deleted so the duplicate is on the record.

    Almero Jacobus Hitge Oosthuizen · Drooge Kloof · Middelwater · Bloemendal Annex Nr. 164

    geopen 2026-08-02

  8. Is the stamvader in this model twice - PER-000296 and PER-000559? LEAD-0113

    PER-000296 Johannes "Jan" Oosthuijsz (stamvader) and PER-000559 Johannes Oosthuizen share an identical death date, share a wife, and one of them is the recorded father of the other's son. Are they one man, and if so which FamilySearch profile survives - LCJN-657 or GW32-G7M?

    Wat ons verwag het: One man. Identical death ../1730-11-04, 1672 is one of the two birth years PER-000296 already carries, both married to PER-000297, and PER-000559 was created on 31 Jul 2026 by the kin_sweep one-degree pull - the pull that matched on tree id alone and duplicated people carrying no tree id. The stamvader carries no tree id. LCJN-657 should survive: it is the id FamilySearch itself puts on Jacobus's father in the family view, and the id this project reached independently.

    Wat dit sou uitmaak: Either FamilySearch merges them, or one profile turns out to hold a source the other does not and they are two men.

    Wat dit beslis het: UNI-000220 (PER-000559 + PER-000297) is the duplicate of UNI-000038 and should go with the merge. merge_person.py re-points references, so run it rather than editing by hand. | CLOSED 6 Aug 2026, SETTLED UPSTREAM AND BEFORE THIS PROJECT ASKED. Frans sent the FamilySearch page for GW32-G7M: 'This person was deleted by merge. Surviving person: Johannes Oosthuijsz. ID numbers: GW32-G7M and LCJN-657.' Merged there on 19 October 2024, by another researcher, more than a year before this model duplicated him. The surviving id is LCJN-657 - the id PER-000296 already carried and reached on its own evidence. PER-000559 merged into PER-000296. THREE THINGS CAME ACROSS WITH IT AND ONLY ONE WAS WANTED: the tree id, which the stamvader lacked and now has; the retired FamilySearch id, kept as a door; and the GRIJPSKERKE PARENTAGE, which this project has weighed and REFUSED - that row is marked confidence=excluded, not deleted. UNI-000220 became an exact duplicate of UNI-000038 and was retired in known_issues.txt. Two checks added the same day: one couple recorded as two unions, and a merge that retired a FamilySearch id the survivor does not carry.

    Johannes "Jan" Oosthuijsz (stamvader) · Jacobus Oosthuizen (b.1722) · Johanna Martens · Johannes Oosthuizen (1648-1682) [REJECTED]

    geopen 2026-08-06

  9. Import the nine Cape descent chains - they are Frans's own ancestry, generation 9 to 13 LEAD-0116

    Eight of S021's ten have no recorded child in this model, so the site names a descent it cannot walk. The private tree holds every chain. Importing them means about fifty new person rows across the de Wet, Mocke, Duminy, Snyman, van Dyk, Janse van Vuuren, Smuts and du Preez lines. Is that in scope?

    Wat ons verwag het: IN SCOPE, and the earlier doubt was based on a misreading. 6 takes 'Frans's direct ancestors to generation 13 together with their siblings and spouses', and these ten sit at generations 9 to 13 of exactly that pedigree. The chains run through the maternal and married-in families rather than the Oosthuizen line, which is what made them look outward at first glance. They are not outward. They are the other strands of the same braid.

    Wat dit sou uitmaak: Frans deciding. A middle course exists: import only the chains that reach families the site actually writes about, and leave the rest as a stated gap on the page.

    Wat dit beslis het: The two that DO walk are Catharina van Malabar, five generations to PER-000001, and Louis van Bengale, whose line runs two generations to Clara Herbst and stops. Louis is also the only one of the ten with support from outside the family tree - Boeseken and Cairns on Tulbagh - so his chain is the best candidate if only one is done. | [6 Aug 2026, SUPERSEDING THIS LEAD'S OWN SCOPE DOUBT] Raised to priority 1. The 9a objection does not hold: following a NEIGHBOUR's family outward is out of scope, and this is Frans's own ancestry through his mother's side and the families that married in. About fifty rows, kinship only, no places per 5. The one judgement left is generation 13 as the honest limit, and these chains sit inside it. | [13 Aug 2026] DECIDED: IMPORT ALL NINE. Scheduled as a research pass. | [13 Aug 2026, CLOSED - THE IMPORT WAS ALREADY DONE] Executing the decision found the work complete: the fifty thin rows entered people.csv on 6 Aug (the PER-001449 to PER-001499 block) and every later pass built on them. Verified against the parentage graph this day: NINE of the ten chains walk end to end - eight reach Frans (PER-000438), Catharina van Malabar reaches the root couple (PER-000001) - and the checks watch *a page claims a descent the parentage table cannot walk* fires zero times. The tenth, Maria van Bengale (b.1638), stops at Marij Zacharias BY DECISION, not by gap: the excluded parentage row on PER-001474 records the tree contradicting itself on that branch (LEAD-0118), and re-importing the same edge would overturn an exclusion. gen_people_tree.py --chains now re-derives all ten from the private tree and emits nothing new, which is the closure test and can be re-run. What remains is not import: familysearch_id is blank on the imported block - the research pass half of the decision - and LEAD-0118 still holds the tenth chain.

    Catharina van Malabar · Angela van Bengale · Elisabeth Rebecca van Bengalen · Louis van Bengale · Souwa van Madagascar · Claesje van Angola

    geopen 2026-08-06

  10. Who was Jan Nijs's mother? Twenty-one years say Jacob had two wives LEAD-0118

    Where does the Maria van Bengale (b.1638) descent actually run? The tree gives Marij Zacharias born 1660, married December 1672, with a son born about 1671. Which date is wrong, or is a generation missing between them?

    Wat ons verwag het: TWO WIVES, and Jan by the first. It is the most economical reading on the table and it needs no date to be wrong. Jacob Jansz de Nijs was born about 1650: he is 21 at Jan's birth about 1671 and 42 at Maria's baptism in January 1692, and TWENTY-ONE YEARS separate those two children. One wife could just span it - she would have to be born about 1651-1655 and be near forty in 1692 - but two marriages is the ordinary shape of a gap like that, and the second wife is the one the 1692 register names, Janna Marij Bousijn. On that reading she is simply not Jan's mother, and Jan's mother is a first wife who is not in any record this project has seen.

    Wat dit sou uitmaak: A baptism naming Jan de Nys's mother, or the 1672 marriage entry itself. Failing those, any record naming Jacob Jansz de Nijs's wife before 1692 - if she is not Marij Zacharias, this descent is not this family's.

    Wat dit beslis het: Note what this does NOT put in doubt: Maria van Bengale's own dates, 1638 to 21 May 1665, are the sharpest of any of S021's ten and match the tree exactly. It is the generation below her that will not add up. | [6 Aug 2026, LATER THE SAME DAY] THE ANSWER IS PROBABLY NOT A DATE AT ALL. The Amsterdam baptism of 9 January 1692 (SRC-298) names the mother of Maria de Nijs as JANNA MARIJ BOUSIJN, wife of Jacob de Nijs - and FamilySearch has that index record ATTACHED TO TWO PROFILES AT ONCE, Johanna Maria Boesijns and Marij Zacharias (LJR9-7H8), the Cape-born daughter of Maria van Bengale. Bousijn is not Zacharias and Amsterdam is not the Cape. TWO WOMEN HAVE BEEN RECORDED AS ONE, upstream, and the splice came into the private tree with everything else. That explains an arithmetic no single wrong date could: a bride of twelve, a son born before the wedding, and a grandmother of twelve, all at once. THE CONSEQUENCE FOR THIS SITE, STATED PLAINLY: if the splice is real, MARIA VAN BENGALE (b.1638) MAY NOT BE AN ANCESTOR OF THIS FAMILY AT ALL, and one of S021's ten falls away. The parentage link is already excluded, so the model asserts nothing - but S021 still lists her, and it should keep listing her with the doubt attached rather than quietly dropping her. Deciding on this evidence alone would be doing the same thing that caused it. | A SECOND WIFE WAS PUT TO THE TREE AND THE TREE HOLDS ONLY ONE. Jacob Jansz De Nijs, born about 1650, has exactly one family in the private tree: Marij Zacharias, married 4 December 1672, one child, Jan De Nys born about 1671. No Janna Marij Bousijn appears anywhere in it, under that spelling or as Boesijns. THE QUESTION IS STILL THE RIGHT ONE, and it splits the problem in two. A second wife would explain the 1692 Amsterdam baptism cleanly - a man of forty-two baptising a daughter by a later wife, with FamilySearch simply attaching the record to the wrong one of the two - and BOTH WIVES BEING CALLED MARIJ is exactly the trap this project already knows about, the same one behind the 'one person married to two people of the same name' check. But it does not touch the arithmetic, because the arithmetic fails at the FIRST marriage, not the second: Marij Zacharias born 1660 is twelve in December 1672 and eleven when Jan is born. SO THE SHARPER VERSION OF THE SAME IDEA IS THE ONE TO TEST: that the 1672 marriage and Jan's birth belong to a first wife who was NOT Marij Zacharias, and that the Cape-born Marij Zacharias has been attached to this family on the strength of a shared given name. The tree's own places, hostile as they are, point that way - Amsterdam, Duesseldorf, Mauritius in 1695, Cape Town by 1699 - which is a Dutch family moving east, with one Cape-born woman spliced into it. | TWO CAPE DOCUMENTS NOW SIT AROUND THE GAP WITHOUT CLOSING IT, which is worth saying precisely rather than letting them look like progress on the question. SRC-299, the estate inventory of 22 May 1713, names Jan Nijs's WIFE (Lijsbet Janse de Rode) and his three CHILDREN. SRC-300, a baptism of 3 April 1701, names him with a wife Elisabeth. Both are about the generation BELOW him and the one BESIDE him. LEAD-0118 is about the generation ABOVE him, and neither document touches it. WHAT THEY DO CHANGE: Jan is now a documented Cape burger, dead by May 1713, with a wife and children in the record - so the question is no longer whether he existed or where he lived, it is only who his mother was. That is a narrower and better question than the one this lead opened with. The record to look for is his own baptism, or a marriage entry for him naming his parents. He was born about 1671, so a Cape baptism would be in the same register series as SRC-300 and roughly thirty years earlier in it. | [6 Aug 2026, FRANS] 'there is 20 years between jan de nys and mary de nys. jan may have had a different mother.' TWENTY-ONE YEARS, and it is the best explanation yet because it is the only one that requires nothing to be wrong. IT ALSO ESCAPES THE VICE THAT DEFEATED EVERY DATE FIX. The arithmetic is caught between two links: Maria van Bengale born 1638 is a comfortable 22 at Marij Zacharias's birth in 1660, but Marij is then 11 at Jan's birth and 12 at the 1672 marriage. Move Marij's birth back to about 1650 to rescue the marriage and Maria van Bengale becomes 12 at HER daughter's birth. No single correction can satisfy both ends. Two wives dissolves it instead of solving it: Marij Zacharias keeps her 1660 birth and her mother, and simply is not Jan's mother. AND THAT IS THE STING FOR THIS SITE. The descent S021 claims runs Maria van Bengale -> Marij Zacharias -> JAN -> Anna Johanna and onward. Jan is the link. If Jan's mother is a first wife who is not Marij Zacharias, the chain breaks at exactly that point and MARIA VAN BENGALE IS NOT AN ANCESTOR OF THIS FAMILY - and she comes off the ten. The cleanest explanation is also the one that costs the most. WHAT WOULD SETTLE IT, in order of how easy it is to get: a marriage entry for Jacob before 1671 naming the bride; Jan's own baptism, about 1671, naming his mother; or a second Amsterdam or Cape marriage for Jacob to Janna Marij Bousijn, which would date the second union and confirm the first was somebody else's. | THE FAMILYSEARCH FAMILY VIEW SETTLES THE SHAPE OF IT, whatever is still open about the names. Jacob Jansz De Nijs (LJR9-74B) and Marij Zacharias (LJR9-7H8) are shown married 4 DECEMBER 1672 AT MAURITIUS with THREE children: JAN 1671, MARY 1691, MARIA 1692. A son a year BEFORE the wedding and two daughters twenty years AFTER him. FamilySearch is carrying the same impossibility this project's own check found, and it is carrying it on the page. The two daughters are also almost certainly ONE PERSON TWICE: Mary De Nys 1691 is 9VZF-514 and Maria de Nijs 1692 is 9VZF-S14 - the same id but for a 5 against an S - and 1692 is the Amsterdam baptism, SRC-298. SO THE READING THAT FITS EVERY DOCUMENT AT ONCE: Jacob's LATER wife bore the child baptised at Amsterdam in January 1692, and the register names her JANNA MARIJ BOUSIJN. Whether 'Marij Zacharias' on FamilySearch IS that Amsterdam woman under a wrong surname, or a separate Cape woman spliced in beside her, the consequence for this site is the same: JAN, BORN 1671, IS BY AN EARLIER WIFE WHO IS IN NONE OF THESE RECORDS. His mother is unknown, and the line from Maria van Bengale runs through him. A SEPARATE AND CLEANER RESULT CAME OUT OF THE SAME SCREEN, and it is worth not losing: Jan's OWN marriage is fully corroborated. Lijsbet Jansz Fockese de Roode, 8 August 1694 at Mauritius, four children, three of whom are exactly the three the 1713 inventory names. Everything one generation below Jan is now solid; everything one generation above him is now openly unknown. | CLOSED 6 Aug 2026, AND NOT BY A DATE. A published Cape genealogy [SRC-301] gives him outright: 'Jan Nys, ook genoem Jan de Rye. v. DUSSELDORF. trou Mauritius (as SOLDAAT) 8.8.1694 met Lysbeth Fockese Roda. In 1696 is hy boswagter op Mauritius en in 1699 burger aan die Kaap. oorlede 1713.' He was a German who came out as a VOC soldier. He has no Cape parents at all, so the question this lead asked - who was his mother - has no answer at the Cape and never did. THE ANSWER WAS SITTING IN A PLACE STRING THE WHOLE TIME. The tree gives his birth as Duesseldorf, and this project discounted it because 5 makes the family-tree's places hostile evidence. Here the PLACE was right and the PARENTAGE was wrong, which is the reverse of the failure that rule was written for. Worth remembering before the next place string is thrown away: a place that does not fit the family may be telling you the family is wrong rather than the place. The line of reasoning that got here belongs to Frans and is worth recording in order: two wives, from a twenty-one year gap between children; then the FamilySearch view showing a son born a year before his parents' wedding; then the biography. Each step made the next one visible. Nothing in this project's own checks could have reached it - they can tell you an arithmetic refuses, not that a man arrived by ship.

    Maria van Bengale (b.1638) · Marij Zacharias · Jan Nys van Dusseldorf

    geopen 2026-08-06

  11. The eight other children on Schalk Willem van der Merwe's 1866 death notice have no rows LEAD-0144

    Death notice 2786 names all nine children in order: Jacobus Adriaan, Carel Aaron, Maria Catharina Elizabeth, Schalk Willem Jacobus, Anna Jacoba Louw, Johanna Christina Adriana, Jacobus Nel, Francois Jacobus and Elizabeth Susanna Louw. Only the first is in this model. Should the other eight be here?

    Wat ons verwag het: THEY QUALIFY AND THEY WERE NOT ADDED, WHICH IS A DECISION FOR FRANS. 6 puts the siblings of a direct ancestor in scope. Against that, R3 says depth is free and breadth is not, and eight rows carrying a name and nothing else is the thin-record shape this project has been moving away from. The transcription holds every name, so nothing is lost by waiting.

    Wat dit sou uitmaak: Frans saying whether siblings of a direct ancestor get rows when a document names them all.

    Wat dit beslis het: Opened 9 Aug 2026. Deliberately not acted on: people are not added in bulk without a decision first. | [11 Aug 2026, SRC-388] THE FAMILYSEARCH SIDE OF THE SAME LIST IS NOW HELD, WITH IDS, and the two sources disagree on the count. Death Notice 2786 names NINE children; FamilySearch gives TWELVE. The three FamilySearch has and the notice does not are Jacobus Adriaan 1814-1868 (LZ8C-1C5), Elsje Johanna Jacoba 1815-1860 (L5RN-X1X) and Petrus Johannes Jacobus 1825- (LZ8C-1NS). One of those is very likely a duplicate of the direct ancestor (FIX-0005); the other two may simply have died before their father without issue, which is why a death notice would leave them out - the form asks who the heirs are, not who was ever born. SO THE NOTICE IS THE BETTER LIST OF HEIRS AND THE WORSE LIST OF CHILDREN, and the ids are what would make the import cheap if it is wanted: eight rows, all with FamilySearch ids and both dates, all deceased long before 1936. Still not acted on. | CLOSED 11 Aug 2026 on a decision to import the siblings, each required to carry a FamilySearch id because the family-tree is old. All eight are now rows, each with a FamilySearch id, together with the other three children of Carel Aaron's first marriage, the two of his second, and two generations of van Heerdens with their siblings - 41 people in all. SRC-391. THE ANSWER TO THE LEAD'S OWN QUESTION, "should the other eight be here?", turned out to be yes for a reason the lead did not anticipate: the point of the import is not the people, it is the IDS. The family-tree this project was built from is a stale copy and its ids cannot be re-checked against the live tree. An FS id can.

    geopen 2026-08-09

  12. The Calvinia baptism register names a woman dead ten years as the mother of Frans Jacobus Wilhelmus van der Merwe LEAD-0152

    Janet Melville reads the Calvinia baptism register as giving Francois, son of Schalk Willem Burger van der Merwe and Anna Maria Visagie. Anna Maria Visagie died in 1853 and he was born in 1863. Which is wrong: the register, the reading of it, or her death year?

    Wat ons verwag het: THE ENTRY IS PROBABLY BEING READ OFF THE WRONG LINE, or the compiler carried the first wife's name forward from an earlier child. Melville herself resolved it that way when Frans put the dates to her - "hy is van die 2de vrou" - and she is the one who read the register. The alternative, that Anna Maria Visagie died later than 1853, is possible and nothing here tests it.

    Wat dit sou uitmaak: The 1863 baptism entry, read directly, with the mother's name as written.

    Wat dit beslis het: Opened 10 Aug 2026 from the Melville correspondence. | CLOSED 11 Aug 2026 by reading the register itself, SRC-378. Entry 62 gives "Kind van: Schalk Willem Burger v.d. Merwe en ELSJE JOHANNA V.D. MERWE". Anna Maria Visagie is not in the entry. The answer was the one this lead predicted - the name was taken off the wrong part of the page - and the mechanism is now visible: TWO VISAGIE WOMEN STAND IN THE WITNESS COLUMN OF THIS SAME ENTRY, paired with two van der Merwe men. The register also reads FRANS JACOBUS WILHELMUS, not Francois, so the second half of SRC-373's central statement does not survive either. Nothing in the model changed as a result, which is the point: it was already right, and it is now right on evidence instead of on a compiler's conclusion.

    geopen 2026-08-10

  13. Brasse Fontein 371 is pinned 110 km from a farm its own diagram says it adjoins LEAD-0173

    The 1878 diagram gives Brasse Fontein 371's southern boundary as "Riet Kolk of Oude Muur" and places it in the field-cornetcy of Achter Hantam. The Calvinia cadastre's parcel 371 sits 110 km east of Oude Muur 619. Which is wrong: the pin, or the assumption that the boundary means the family's Oude Muur?

    Wat ons verwag het: THE PIN IS PROBABLY WRONG. Achter Hantam is the Hantam, and the polygon is out in the country east of it. A cadastre matched on a bare farm NUMBER is exactly the failure this project has hit repeatedly - it withdrew a Matjiesfontein pin for the same reason a week ago. IF THE PIN IS WRONG AND THE FARM ADJOINS OUDE MUUR, IT MATTERS A GREAT DEAL: Christina Elizabeth Nel died at Brasfontein in 1895 and her husband was recorded on Oude Muur in 1897, and the two would be neighbouring ground rather than a hundred kilometres apart.

    Wat dit sou uitmaak: Any one of the five named neighbours located in the cadastre.

    Wat dit beslis het: Opened 11 Aug 2026 on reading the diagram, an hour after the pin was added. | CLOSED 11 Aug 2026, WITHIN THE HOUR, AND THE PIN WAS RIGHT. The lead predicted the pin was wrong because Achter Hantam is the Hantam. It is not: the five farms the diagram names as neighbours all sit within 14 km of the pinned polygon and all of them are ~100 km from Oude Muur 619. RIET KOLK No. 385 is the "Riet Kolk of Oude Muur" of the boundary - A SECOND FARM OF THAT NAME. So Brasse Fontein does not adjoin the family's Oude Muur, Christina Elizabeth Nel died 100 km east of where her husband was living two years later, and the project now knows of THREE pieces of ground called Oude Muur. Checking the neighbours cost one query and it was the right check.

    Brasse Fontein Nr. 371 · Oude Muur Nr. 619

    geopen 2026-08-11

  14. Where exactly is Vischat / 'fisgat', and what is its real name? LEAD-0018

    Vischat is where Frans's grandfather Hendrik Lodewyk Malherbe Oosthuizen farmed until 1979 and where his father CJJ grew up, yet the model has no ground for it: no extent, no geometry, no ownership row, no document. Which parcel does it actually sit on, and is the name Vischgat/Visgat?

    Wat ons verwag het: A werf on one of the farms the family held rather than a farm in its own right. The farm_no cell reads '124/142' = Rondable + Frans Kraal, and Tokkie Marincowitz - who BOUGHT Vischat - farmed Rondabel until 2003, so Rondable No.124 is at least as likely as the 'in Frans Kraal' note suggests. The name is probably VISCHGAT ('fish pool').

    Wat dit sou uitmaak: The purchase deed - it will name the parcel Vischat forms part of. Failing that, a topo sheet showing the werf, or CJJ simply saying which farm it was on.

    Wat dit beslis het: RESOLVED 31 Jul 2026. 19"S 22°37'05.06"E, which point-in-polygon puts inside PAR-000009 RONDABEL, 5.2 km from the Rondawel werf. The lead's own prediction was right - 'Rondable No.124 is at least as likely as the in-Frans-Kraal note suggests'. Recorded as PLC-000034. What is NOT resolved is the spelling and the name's origin, which is now LEAD-0024.

    Hendrik Lodewyk Malherbe Oosthuizen · Christiaan Johannes Joubert Oosthuizen · Gert Annis Oosthuizen Marincowitz · Vischat · Faans Kraal (Vrolikheid Nr. 177 Gdlt 4) · Rondabel · Vrolikheid

    geopen 2026-07-30

  15. Are the two 1839 Ockert Almeros one man, or did the root couple really have two? LEAD-0033

    PER-000133 (FS GVZF-ZHH, b. 8 Jul 1839, baptised 20 Aug 1839) and PER-000364 (FS G6ZT-D65, b. 1839) are both Ockert Almero Oosthuizen and both children of the root couple. Different family-tree records, different FamilySearch ids. One man or two?

    Wat ons verwag het: One man, recorded twice. Two sons of the same name in the same year is only possible as twins, and the vernoemingspatroon's name-reuse rule requires the first child to have DIED before the name is used again - which cannot happen inside one year. PER-000133 carries a baptism date of 20 Aug 1839 and PER-000364 carries nothing but the year, which is the usual shape of a duplicate rather than of a twin.

    Wat dit sou uitmaak: The register page. Twins would be entered together, as the 1825 Swellendam page shows.

    Wat dit beslis het: Detector gap this exposed: fs_corrections.py finds our-duplicates by a shared FamilySearch id and familysearch-duplicates by identical name AND identical birth string. This pair has neither - different ids, and '1839' against '1839-07-08'. It slipped through both. The precision-aware comparison already written for merge_person.refines() would catch it. | ACTED ON 5 Aug 2026, AND SAY WHICH TEST DID IT. PER-000364 was merged into PER-000133 through merge_person.py. What settled it was NOT the register page this lead asked for - that has still not been read. It was the sibship arithmetic: the root couple carried sixteen children in parentage, 5b's independently tested count is fourteen, and SRC-077 names thirteen surviving in 1859. Dropping this pair and the Susanna Catharina pair (PER-000461 into PER-000123) gives fourteen. The merge brought a wife and twelve children onto PER-000133, which contradicts Pottas's 'unmarried' and sharpens the SRC-077 omission - both written onto that row rather than resolved. THE REGISTER PAGE FOR AUGUST 1839 IS STILL WORTH READING, and now has a second question to answer: whose children are PER-001088 to PER-001099.

    Ockert Almero Oosthuizen (b.1839) · Ockert Almero Oosthuizen · Adriana Cecilia Venter

    geopen 2026-07-31

  16. Duplicate candidates from the one-degree pull, settled on FamilySearch ids LEAD-0035

    38 people added on 31 Jul 2026 share a name AND a birth YEAR with somebody already in the model, and 32 share a name with no date at all. Are they the same people?

    Wat ons verwag het: Most of the year-matches ARE duplicates and most of the undated ones are not - a thin tree record with no date is usually a different person of a repeated name rather than a second copy.

    Wat dit sou uitmaak: A full birth or baptism date on either side of a pair. Name plus YEAR is not enough here and must not be treated as enough.

    Wat dit beslis het: CLOSED 31 Jul 2026, the same day it was opened, and closed by the right key. s that are unique - so you should be able to see when it is duplicate or different." He was right and the key was already in the record: MacFamilyTree writes the FamilySearch person id into a custom _FID tag and 44,141 of the tree's 44,143 individuals carry one. The sqlite export drops that column, which is the whole reason the pull matched on tree id alone and duplicated people who had no tree id. | 853 FamilySearch ids stamped onto the model from the family-tree; 55 pairs then proved to be one person recorded twice and were merged. That is EIGHT TIMES what name-and-date matching had found, and it caught pairs no name test could: Eugene against Eugenius, 'Caroline Mircle' against 'Caroline Merle', 'Pieter Cornelis Oosthuizen' against 'Pieter Cornelis Oosthuisen'. | The other direction matters as much: of 350 same-name pairs among live people, 329 are now PROVEN DISTINCT because both sides carry a FamilySearch id and the ids differ. Those are no longer candidates for anything. 21 remain undecidable, all because one side or the other has no FamilySearch id at all - see LEAD-0036.

    Ockert Almero Oosthuizen · Anna Helena Roscher · Daniel Johannes Oosthuizen (b.1811) · Anna Magdalena Oosthuizen (b.1818) · Jacobus Johannis Oosthuÿsen (b.1849) · Charles Frederick Marincowitz (b.1878)

    geopen 2026-07-31

  17. The surname column was blank on 62% of people, fixed, and the lesson LEAD-0042

    796 of 1,270 live people have no surname recorded. What can safely be counted by surname, and what cannot?

    Wat ons verwag het: Nothing aggregate. The gap is not random - it is worst on the imported one-degree rows, which is precisely where a family tally would draw its numbers from.

    Wat dit sou uitmaak: Populating it from the family-tree's own SURN field via kin_sweep.

    Wat dit beslis het: CLOSED 31 Jul 2026, same day. FIXED: kin_sweep --fill-names reads the family-tree's own SURN and GIVN tags, which the sqlite export drops, and filled 848 surnames, 191 given names, 118 dates and 472 line assignments. Coverage 38% -> 99%. The 8 rows still without a surname are two entities and six single-name people, and every one is correct. | AND THE STING IN IT: the 'Botha x Oosthuizen, 5 times' finding that this lead was opened to warn against IS REAL. Recomputed on complete data it is still the commonest cross-surname pairing in the district. The artefact was my CORRECTION of it, not the original - I recomputed on 'recorded surnames only', which was the same broken 38%, and declared a true finding false. A partial dataset does not only produce false positives; it produces confident false NEGATIVES, and those are worse because nobody goes back to check them. | THE REAL LESSON, now in AUDIT.md as stage 1a: every check in this project looked for data that was WRONG and none looked for data that was ABSENT.

    geopen 2026-07-31

  18. Images of documents are not date-gated the way PDFs are - should they be? LEAD-0046

    A PDF of a document is published only if the document is dated before 1936, because no text check in this build can see inside one. A JPEG rendered from a .tif or .jpg scan is exactly as opaque, and has never been put through that gate. 20 published renderings are of documents that are undated or dated 1936 or later. Tighten the gate, or narrow it?

    Wat ons verwag het: Neither extreme. Most of the 20 are SG diagrams with no date FIELD rather than no date - the diagram year is often in the filename or the deed reference, so filling those in removes most of the problem without withholding anything. The real decision is the handful genuinely dated after 1936, of which DOC-0017 (a 1939 death notice, quoted in S002) is the clear case: the subject died in 1939 and is certainly beyond privacy, but the mechanical rule cannot know that.

    Wat dit sou uitmaak: on whether a document's date should govern its IMAGE as well as its PDF - and, if yes, dates filled in for the diagrams that merely lack the field.

    Wat dit beslis het: FOUND BY THE TEST WRITTEN FOR A DIFFERENT BUG. L15 was added because the new PDF-preview feature shipped a page-one JPEG of every WITHHELD PDF, including two 2013 deeds searches naming current registered owners. That is fixed. The test then reported this, which is older and wider and is NOT being changed silently, because tightening it would pull evidence off live pages. | CLOSED 1 Aug 2026. The answer was yes, and the hole was bigger than the lead said. derive_images() in build_site.py was a THIRD consumer of sources/ with no gate on it at all, so every raster went to the site regardless of date while copy_scans() and derive_pdf_previews() both checked. It now calls the same scan_is_publishable(). 40 rasters are withheld as a result: 9 diagrams dated 1937 to 1990, a 1939 and an undated death notice, an undated plot plan, and 10 FamilySearch-sourced images that were being republished against Frans's cite-and-link decision. Two other defects fell out of it. _doc_year() took the MINIMUM of every date on a row, so a document whose dates straddled 1936 published on its oldest one; it now takes the latest CONTENT date and treats image_edtf as the copy date rather than content. And a verso, which carries no date of its own, now inherits its front's, so the backs of thirteen diagrams are not collateral. Caught by DOC-0157, a 1939 partition diagram that came in through the inbox and published silently. The leak test now FAILS on a raster instead of reporting one.

    geopen 2026-08-01

  19. Were Jacobus and Wynand van Zyl twins, born 6 December 1809? LEAD-0048

    The van Zyl family history says Jacobus and Wynand were TWINS, both born 6/12/1809. The model has Jacobus at 20 Sep 1809 and Wynand at 1808. Which is right?

    Wat ons verwag het: The baptism register decides it and nothing else will. Twins are unusually easy to confirm - two entries on one day, often on one line - so this is a cheap question with a clean answer. Worth noting the stakes: if they were twins, then TWO TWIN BROTHERS MARRIED TWO SISTERS off one Karoo farm, which is a considerably better fact than two brothers doing so.

    Wat dit sou uitmaak: A baptism entry for either brother giving a date, or both on one day.

    Wat dit beslis het: Also unresolved on the same rows: PER-001263 and PER-001264 look like each other's duplicate - two Wynand van Zyls, both 1808, both recorded as spouse of Johanna Jacomina Oosthuizen. Settle the twin question and the merge probably settles with it. | [1 Aug 2026, SRC-180 - the baptism register] CLOSED, AND ANSWERED NO, ON THE SAME DAY IT WAS OPENED. The register has both entries consecutively on page 148: Wijnand 'geb: den 3 Junij 1808' and Jacobus 'geb: den 20 September 1809', same parents, BOTH BAPTISED 6 DECEMBER 1809. They were baptised together and born fifteen months apart. The family history read the shared baptism date as a shared birthday. THE LESSON IS THE USEFUL PART, and it is the ordinary shape of this error: a family history records a DATE it found attached to two people and infers a RELATIONSHIP from it. So the answer to 'were two twin brothers married to two sisters' is no - but two brothers were, and that was never in doubt. Also worth noting the model needed no correction: both dates were already right.

    Jacobus Stephanus van Zyl · Wynand van Zyl

    geopen 2026-08-01

  20. Two Prince Albert parcels numbered 172, and a Haggas the cadastre extract cannot see LEAD-0053

    What is the 1,420 ha parcel also numbered 172 at (-33.3165, 22.8003), and where exactly is Haggas No. 145?

    Wat ons verwag het: On 172: probably a detached piece of the same farm, or a portion the extract has typed as a farm. Both features carry RD=PRINCE ALBERT and the SAME CSG link, so they are not two different registration divisions - which makes this a different bug from Haggas, and a subtler one. On HAGGAS: it is NOT IN THE CADASTRE FILES AT ALL - no feature named Haggas or Haggis anywhere, and farm 145 in the Prince Albert extract is ROODE PUNT WES at lon 21.65, nowhere near. But the official CSG viewer plainly shows a 143/144/145/147/148 block immediately east and south-east of Oorlogs Kloof 175, exactly where both 1833 and 1863 diagrams put Haggis. THE EXTRACT SIMPLY DOES NOT REACH THAT FAR EAST. That is a gap in our download, not in the record.

    Wat dit sou uitmaak: A cadastre feature named Haggas with a PRCL_KEY, touching Oorlogs Kloof on its east or south.

    Wat dit beslis het: Raised by Frans spotting a hole in the map between Vrolikheid and Oorlogs Kloof, and by his screenshot of the official CSG viewer showing RE/172 hard against 1/177. The Oorlogskloof half is FIXED; this lead is the residue. | CLOSED 1 Aug 2026. Haggas, Karee Rivier and Spitskop are all drawn, from the Council for Geoscience's national cadastre (layers 9 and 8), which serves the Eastern Cape and therefore Willowmore. fetch_cadastre.py now falls back to it for divisions the Western Cape service cannot serve, and normalises MAJ_REGION/TAG_VALUE into the RD_name/P_FARMNAME shape every consumer already expects.

    Oorlogs Kloof Nr. 172 (Roode Els Bosch and Oorlogs Kloof) · Haggas Nr. 145

    geopen 2026-08-01

  21. Two Rietfontein rows: one farm, or one farm and a phantom? LEAD-0058

    Should PAR-000010 "Rietfontein" and PAR-000052 "Rietfontein (Zeekoegat district)" be one row, and does PAR-000010 describe a farm that ever existed?

    Wat ons verwag het: PAR-000010 is probably a phantom. Its only support is one unsourced legacy line saying a portion of Middelwater No. 169 became Rietfontein, and the 1883 verso (DOC-0039) lists no such deduction from 169.

    Wat dit sou uitmaak: Either a Middelwater deduction table naming a Rietfontein, which would make PAR-000010 real and separate, or the absence of one across the full set, which would retire it into PAR-000052.

    Wat dit beslis het: Raised by , spotting that both rows showed the same index number 38/56. That part is now fixed: both were wearing Ptn 38 of Rietfontein No. 56 and neither is pinned any more. Merging or retiring a parcel id is a decision for Frans, not a cleanup, because ids are permanent. | [CLOSED 9 Aug 2026] FOLDED INTO LEAD-0080, which asks the same Rietfontein question as one of its three parts and carries the other two with it. Nothing is lost: the detail from here, that both rows were wearing Ptn 38 of Rietfontein No. 56 and that neither is pinned any more, is carried across. Merging or retiring a parcel id remains a decision for Frans.

    Rietfontein · Rietfontein (Zeekoegat district)

    geopen 2026-08-01

  22. A township in East London had been entered as a Karoo farm LEAD-0061

    Was the parcel created from DOC-0032 a real farm, and how many others rest on a document nobody opened?

    Wat ons verwag het: Retire it. Nothing references it and the document it rests on is about ground 500 km away.

    Wat dit sou uitmaak: Ids are permanent, so retiring means marking the row, not deleting it.

    Wat dit beslis het: Raised 1 Aug 2026, on an audit of whether all the source files had been mined. Two other things fell out of the same audit: DOC-0003's entire extraction was the word "consolidation" for a diagram that names two grantees and two grant dates, and the Klein Sleutlefontein scans were on disk under DOC-0091/0092, ids belonging to two estate inventories. | CLOSED 1 Aug 2026, the same day. The parcel is retired: the row is removed from parcels.csv and the id is never reused, which is what retiring means here. Nothing referenced it - no ownership, no neighbours, no story links, no parcel links, no residences, all verified zero before removing it - and the full record of what the sheet actually is lives on DOC-0032 and SRC-045, which are corrected rather than deleted because the document is real, it is simply about East London. PROOF THE CHECK WORKS: build_land_db.py refused the first rebuild after the row went, because this lead still named PAR-000037 in three of its own fields. A retired id cannot be left pointed at.

    geopen 2026-08-01

  23. "[?Hoeagus]" is HAGGAS No. 145 - RESOLVED by the widow's own death notice LEAD-0072

    What is the place written as the residence in field 8 of death notice No. 682 of 1863, and where is it?

    Wat ons verwag het: A werf or farm in the District of Prince Albert. The word is not confidently read - recorded as "[?Hoeagus]" - and it matches NO farm name in the Prince Albert or Beaufort West cadastre, which was checked name by name including every name beginning with H. That absence is not evidence against it. This project's second place rule says the cadastre records TITLE, not what people call the ground they live on, and Drooge Kloof and Vischat are already on the books as real places with no polygon. A man can die at a werf that never reached a diagram.

    Wat dit sou uitmaak: A clearer image of field 8, or the estate inventory naming where his stock and ground lay.

    Wat dit beslis het: CLOSED 4 Aug 2026. The farm is HAGGAS No. 145 (PAR-000094), surveyed 1833 for P. VAN DER WESTHUIZEN, which is the dead woman's own surname. Recorded as a RESIDENCE, not ownership, at Frans's explicit caution: "it says they lived there, not necessarily owned it." One discrepancy stays open - the cadastre puts farm 145 in the Willowmore division while both notices say Prince Albert - and is noted on the parcel rather than argued away.

    Cornelis Petrus Janse van Vuuren · Wilgemond Nr. 179

    geopen 2026-08-03

  24. Three farms carry the same name twice or three times, and ten story links are held back because of it LEAD-0080

    Which Rietfontein, which De Claar Stroom, and is Sleutelfontein (Groot and Klein) a real parcel or a composite of two?

    Wat ons verwag het: A cross-reference audit on 4 Aug 2026 found 22 farms named in a story's prose with no link to that story. Twelve were added. TEN WERE DELIBERATELY NOT ADDED, because the name in the prose matches more than one parcel row and guessing which one would be the namesake error this project keeps making. RIETFONTEIN, THREE ROWS: PAR-000010 (called a subdivision of Middelwater, its own note says "[TO VERIFY - probably wrong]"), PAR-000052 (Zeekoegat district, granted c.1858 to J.S. de Villiers), and PAR-000156 (Riet Fontein No. 12, established from its own diagrams on 4 Aug 2026). Two stories mention a Rietfontein - the gold rush and the Middelwater history - and neither can be linked until it is known which. LEAD-0058 already asks half of this. DE CLAAR STROOM, TWO ROWS: PAR-000004, the 1777 loan farm and parent of Middelwater and Klaarstroom, and PAR-000097, Klaarstroom No. 178. Four stories name it. The two are genuinely different things - a parent loan farm and a modern farm - so each mention needs reading, not a bulk link. LEAD-0039 is the same question. SLEUTELFONTEIN: PAR-000098 is "Sleutelfontein (Groot and Klein)", described in its own notes as TWO farms, while PAR-000071 and PAR-000072 hold Groot Sluitel Fontein No. 126 and its portion separately. A row that is two farms cannot be linked as one place.

    Wat dit sou uitmaak: For each mention, which parcel the sentence means. For Sleutelfontein, whether PAR-000098 should exist at all given PAR-000071/072.

    Wat dit beslis het: [4 Aug 2026] THE SLEUTELFONTEIN THIRD IS ANSWERED, by Frans and [FAMILY]: "Klein and Groot sleutel fonteint had various spellings over the years. sleutel, sluitel, etc but seems it was always 2 distinct farms - at least since surveyd." So PAR-000098 stays what it was already made on 3 Aug - a COLLECTIVE REFERENCE resolving to PAR-000071 (Groot, No. 126) and PAR-000073 (Klein, No. 127) - and STO-0020 now links all three: the collective name the source used, and the two farms it means. THE LEAD REMAINS OPEN for the other two thirds, Rietfontein (three rows) and De Claar Stroom (two), which are untouched by this. Note for anyone reading the two rows: KLEIN SLEUTELFONTEIN IS THE LARGER FARM, 14 398,3 ha against 4 199,1 - so the names cannot be used to guess which row a document means. | [4 Aug 2026] THE DE CLAAR STROOM THIRD IS ANSWERED, by [FAMILY] De claar stroom 178 and the other overlapping farm is the same. PAR-000004 (the 1777 loan farm) and PAR-000097 (Klaarstroom No. 178) are one piece of ground recorded under two epochs, not two farms. PLK-000053 changed from 'subdivision' to 'same_as' - a farm cannot be a subdivision of itself - and both parcel rows now say so. Checked before acting: no polygon really overlaps 178 apart from neighbours' shared edges, so the overlap is between the RECORDS. ONLY RIETFONTEIN REMAINS OPEN on this lead: three rows, PAR-000010, PAR-000052 and PAR-000156, with two stories that cannot be linked until it is known which one they mean. | [9 Aug 2026] ABSORBED LEAD-0058, the Rietfontein third of this question asked on its own. Carried across: Frans spotted on 1 Aug that PAR-000010 and PAR-000052 both showed index number 38/56, so both were wearing Ptn 38 of Rietfontein No. 56; neither is pinned any more. The open part is whether PAR-000010 describes a farm that ever existed, or is a phantom of the same name. Note that farm 12 is a THIRD Rietfontein and is its own question, LEAD-0085. | [13 Aug 2026] CLOSED - ALL THREE THIRDS ANSWERED. Sleutelfontein by Frans on 4 Aug (two distinct farms; PAR-000098 a collective reference). Rietfontein by Frans on 13 Aug: the S011 subdivision sentence means PAR-000052 - the Zeekoegat farm - not Riet Fontein No. 12; S002 was already linked to PAR-000052. De Claar Stroom by Frans on 13 Aug: the S011 chain row means PAR-000004 - the 1777 parent loan farm. Links written; whether PAR-000052 and PAR-000156 are one farm remains LEAD-0058 and is NOT decided here.

    Rietfontein · Rietfontein (Zeekoegat district) · Rietfontein Nr. 12 · De Claar Stroom (the 1777 loan farm) · De Claar Stroom (Klaarstroom Nr. 178) · Sleutelfontein (Groot and Klein)

    geopen 2026-08-04

  25. Four portions have a polygon in geo/ that match_cadastre.py still will not pick up LEAD-0084

    Why does the matcher miss PAR-000023, PAR-000058, PAR-000069 and PAR-000144 when their exact PRCL_KEYs are present?

    Wat ons verwag het: A KEYING FAULT IN THE MATCHER, not a data fault. The two causes found on 4 Aug were both in the data - a blank plc_id, and an sg_farm_key of NO-POLYGON asserting an absence that was untrue - and fixing those placed six parcels. These four survive that fix: their division, farm number and portion number are all filled and the key each one implies is present in geo/. So the remaining suspect is how match_cadastre.py builds or normalises its key for a portion.

    Wat dit sou uitmaak: Printing the matcher's computed key beside the cadastre key for one of these four.

    Wat dit beslis het: Listed in known_issues.txt so the build is not blocked while they stand. | *** [4 Aug 2026] CLOSED, AND THE PREDICTION IN THIS LEAD WAS WRONG. *** It said the cause was "a keying fault in the matcher, not a data fault". It is neither. All five polygons carry WSTATUS='H' - SUPERSEDED - and match_cadastre.py keeps superseded features out of the name and farm-number indexes deliberately, holding them by LPI alone so that only an explicit PIN can reach one. The matcher was doing exactly what it was built to do, and the loader says so in a comment written on 2 Aug. WHAT WAS ACTUALLY REQUIRED was a judgement per parcel: is the superseded shape the right historical ground? Judged on extent, the same test that justified the Modderdrift Portion 4 pin. THREE PINNED: Spreeufontein Portion 4 (5 223,1 ha against 5 240,5, 0,3%), Annex Modderdrift (2 036,0 against 2 043,4, 0,4%) and Rhemhoogte Portion 6 (4 728,2 against 4 781,2, 1,1%). TWO REFUSED: Botterkraal, where our 3 418 morgen is 2 927,6 ha against the polygon's 1 653,8 - 77% apart, not the same ground - and Rhemhoogte Portion 7 at 4,65 ha against 5,6, which is 20% and no corroboration even though the absolute gap is under a hectare. Those two stay unplaced, which is honest; a wrong pin would not be. THE CHECK THAT RAISED THIS WAS ALSO WRONG and is fixed: it now ignores WSTATUS='H' features, so it no longer accuses the matcher of missing what it is designed to skip.

    Lot B (Spreeufontein Nr. 26 Gdlt 4) · Botterkraal (Jansenskraal Nr. 104 Gdlt 2) · Annex Modderdrift (Rhemhoogte Nr. 125 Gdlt 3) · Swartskraal (Rhemhoogte Nr. 125 Gdlt 6)

    geopen 2026-08-04

  26. Nine diagram sheets named in the model that no longer exist on disk LEAD-0095

    Re-pull nine Surveyor-General sheets whose archive references this model records but whose images were never kept. What do their versos carry?

    Wat ons verwag het: MOSTLY VERSOS WITH DEDUCTION TABLES, and therefore mostly PORTION NAMES. That is what the second sheet of a diagram usually is in this collection, and 8 says so in as many words - 'the back of the sheet is where the deduction table lives, which is where the portion names and the later history live, so that is exactly the half worth losing'. The Klein Valie No. 182 batch of 5 Aug 2026 is the worked example of the payoff: nine portions, eight of them named, every name read off a sheet. Four of the seven affected rows are farms whose portions this model still holds unnamed or unnumbered.

    Wat dit sou uitmaak: Re-pulling the nine files. Each then gets its OWN DOC- row per 8, never a second filename on an existing row.

    Wat dit beslis het: The rule this breaks is 8, 'A SHEET IS A ROW', which was itself written on 3 Aug 2026 after the same mistake was made and corrected that morning. These seven rows pre-date the rule or slipped past it. CLOSED 5 Aug 2026, the same day: Frans re-pulled all nine sheets from the Surveyor-General. Each now has its own DOC- row (DOC-0238 to DOC-0246) and the seven parent rows carry a single filename again. THE VERSOS WERE WORTH IT - between them they carry the full eight-portion deduction table for Minnies Kraal No. 112, six named portions of Rondabel, and the one line that resolves the biggest extent anomaly in the model (see LEAD-0093).

    Plaas 215 · Minnies Kraal Nr. 112 · Groot Sleutelfontein (Rhemhoogte Nr. 125 Gdlt 2) · Modderdrift Nr. 239 · Swartskraal (Rhemhoogte Nr. 125 Gdlt 5) · Rondawel (Rondabel Nr. 124 Gdlt 1)

    geopen 2026-08-05

  27. Whose grave is on Vredendal, 24 July 1886? LEAD-0120

    A slate headstone lying flat on Vredendal is cut for a burial of 24 July 1886. The surname reads as Botha and is not certain, the given name and the age are illegible on the photograph. Who is buried there, and is it one grave or a family plot?

    Wat ons verwag het: Not an ancestor, on present evidence - no Botha holds Vredendal in this model, and the van der Merwes come to it in the 1950s. More likely an earlier occupier of the ground or a neighbour buried where he died. That would make it the kind of grave this project should hold anyway: the people on the land, not only the family.

    Wat dit sou uitmaak: A readable surname and age from the stone, or a death notice for a Botha at Spreeufontein in July 1886.

    Wat dit beslis het: The same photograph places Vredendal inside Spreeufontein Portion 1, which had been an open question on PAR-000006. That part is recorded there at medium confidence. A second geotagged photograph, at the werf, would firm both up at once. | [CLOSED 9 Aug 2026] ANSWERED. The stone is GRV-0025 and the burial is ENGELA SUSARA NIEHAUS, born BOTES (PER-001526), who died on 24 July 1886 aged 49 years 2 months 22 days. The inscription reads in full and is transcribed on STO-0033. THE SURNAME THAT 'READ AS BOTHA' IS BOTES, which is worth keeping: the two are one letter apart on a weathered slate and the district holds both families. It is also NOT one grave but a plot of at least five, with two Botma stones of 1910 and 1939 beside it and a fifth name on the eGGSA list this project has not seen. The 'medium confidence' on the portion, mentioned in the note above, is also gone:

    Vredendal (Spreeufontein Nr. 26 Gdlt 1)

    geopen 2026-08-06

  28. Three Botes dead in one year at Saairivier, 1904 LEAD-0132

    Barend Stefanus Botes (b.1882), Hendrik Willem Botes (b.1883) and Gertruida Elezabeth Jacoba Botes born Niehaus (b.1862) all died in 1904 and lie in one small ground on Blaauw Draay 3 near Leeu-Gamka. What killed three of one household in one year, and are they the Botes and Niehaus of Varsche Fontein and Vredendal?

    Wat ons verwag het: A mother and two grown sons. The ages fit - she was 42 and they were 21 and 22 - and a single year points at disease or an accident rather than ordinary mortality.

    Wat dit sou uitmaak: Three death notices, which would give parents, cause and estate.

    Wat dit beslis het: Raised 7 Aug 2026 with the Leeu Gamka sweep to keep grounds where people relate. | [7 Aug 2026] ANSWERED FROM FAMILYSEARCH. She is Gertruida Elizabeth Jacoba Niehaus, KLYD-KST, born Prince Albert 8 May 1862, married Andreas Stefanus Botes there on 13 December 1880, died 22 April 1904 - and her parents are Hendrik Willem Storm Niehaus [PER-001527] and Engela Susara Botes [PER-001526], the couple of the Vredendal stone. The two young men beside her are her sons, and one of them carries her father's names. WHAT KILLED THREE OF THEM IN 1904 IS STILL OPEN.

    geopen 2026-08-07

  29. The Calvinia cemetery is photographed, and the grave of Schalk Willem Burger van der Merwe is in it LEAD-0153

    Frans photographed the Calvinia cemetery in August 2013 beside the grave of SWB van der Merwe (1833-1904). Janet Melville reported the cemetery had by then been shot for eGGSA. What do the stones say, and which of this line lie there?

    Wat ons verwag het: SEVERAL OF THIS LINE SHOULD BE THERE. Jacobus Adriaan van der Merwe died at Calvinia in 1855 and was buried there; Schalk Willem Burger died on Oude Muur in 1904 and his stone is in the town cemetery. A photographed cemetery is the cheapest gravestone evidence this project can get, and eGGSA is already a source it uses.

    Wat dit sou uitmaak: Transcriptions of the van der Merwe stones in the Calvinia cemetery.

    Wat dit beslis het: Opened 10 Aug 2026 from the Melville correspondence. | CLOSED 11 Aug 2026. The stone is photographed and indexed: "MERWE VD Schalk W.B. 1833-1904" in the Calvinia main cemetery, eGGSA, and the identification rests on the initials, the surname and both years against a baptism register and a death registration. GRV row added. THE WIDER QUESTION THE LEAD ASKED - which of this line lie in that cemetery - is answered differently than expected: Calvinia's main cemetery holds over a hundred van der Merwe stones and only ONE of them is a person this model holds. The others are a district full of the surname. Two more direct ancestors were found in the same sweep, but in other towns: PER-000762 at Brandvlei and PER-000219 with his wife at Williston. SRC-389.

    geopen 2026-08-10

  30. Welbedacht is a family farm this project has never entered LEAD-0169

    Jacobus Alewyn van der Merwe was known as "Kwaai Koos Welbedacht". His daughter was born there in 1835 and married there in 1854, and his wife died there in 1855. Which Welbedacht, and can it be matched to the cadastre?

    Wat ons verwag het: IT IS IN THE CALVINIA DIVISION AND THERE ARE AT LEAST TWO CANDIDATES. The CSG name index, asked on 11 Aug 2026 for a different reason, returned WELBEDAGT No. 555 and WELBEDACHTE No. 611, both CALVINIA, as well as WELBEDACHT No. 537 and No. 139 in CLANWILLIAM. The 1854 marriage register puts the wedding "op de plaats Welbedacht" in the PAROCHIE VAN CALVINIA, DISTRIKT VAN CLANWILLIAM, which in 1854 is not a contradiction - Calvinia was a parish inside Clanwilliam - so the district on the sheet does not choose between them. THE OTHER BRANCH'S GROUND SHOULD SETTLE IT BY PROXIMITY. Oude Muur is at -31.333, 19.291 and Tygerhoek at -31.464, 19.707. Jacobus Alewyn is Jacobus Adriaan's brother, so Welbedacht should be in the same country, and the two Calvinia candidates can be measured against it the way farm 601 and 791 were for LEAD-0151.

    Wat dit sou uitmaak: A diagram or deed naming a van der Merwe on Welbedagt No. 555.

    Wat dit beslis het: Opened 11 Aug 2026 from the FamilySearch note "Bekend as Kwaai Koos Welbedacht" and the 1854 marriage register. | [11 Aug 2026] PART-ANSWERED THE SAME HOUR, from the cadastre already on disk. The Calvinia division holds exactly ONE farm whose name begins WELBED - no. 555, WELBEDAGT, at -31.3032, 19.9192 - and it is 26.9 km from Tygerhoek and 59.7 km from Oude Muur, so it sits in the same country as the rest of this branch. It is now PAR-000199 with its cadastral polygon and is drawn on the map. WHAT IS STILL OPEN is the half that matters: no document puts a van der Merwe on that title. One candidate in the right division at the right distance is a good identification and it is not proof, and this project has spent the day watching farm-name matches fail. The next step is the CSG document index for Calvinia 555. | [CLOSED 11 Aug 2026, SRC-417/DOC-0291] WELBEDACHT IS WELBEDAGT No. 555, CALVINIA, and it is PAR-000199, which was already in this model with a matched polygon at -31.3032, 19.9192. The 1823 manuscript names it in words: the loan place Welbedagt, 4031 morgen 188 square roods, measured for CAREL AARON VAN DER MERWE in erfpacht on 2 June 1823. So the farm behind the byname "Kwaai Koos Welbedacht" was his FATHER'S ground before it was his.

    geopen 2026-08-11

  31. Is GW32-G7M the Oosthuizen stamvader this model already holds, or an extra generation? LEAD-0171

    The son's family-tree runs the Oosthuizen father-line Jacobus 1722-1802 -> Johannes Oosthuizen 1672-1730 (GW32-G7M) -> Johannes Oosthuizen 1648-1682. This model's stamvader is Johannes "Jan" Oosthuijsz, LCJN-657, born 1665. Same man, or a generation this project lacks?

    Wat ons verwag het: PROBABLY THE SAME MAN, seven years apart on a birth year, which is ordinary for this period. Against that, the family-tree disagrees with this model on the stamvader's own birth as well - 1675 against 1665 - so it has him twice at two dates, which is what a duplicate looks like. This model's row rests on SRC-101 and SRC-102, Amsterdam and Leiden baptisms.

    Wat dit sou uitmaak: Whether the two ids are one person on FamilySearch, or two.

    Wat dit beslis het: Opened 11 Aug 2026 during the six-person import from the family-tree. | CLOSED THE SAME HOUR, WITHDRAWN AS A QUESTION, AND WRONGLY OPENED. This project settled the question long ago and the answer was sitting in the model: GW32-G7M is PER-000559, ALREADY TOMBSTONED as status='duplicate' of PER-000296, and PER-000296 carries the birth as the EDTF range 1665/1672, which holds BOTH readings on purpose, with the same death of 4 November 1730. Same man, one id retired, no missing generation. THE MISTAKE WAS THE SAME ONE MADE TWICE EARLIER ON 11 AUGUST with FIX-0007 and FIX-0008: the comparison excluded status='duplicate' rows, so a tombstoned id looked like an absent one. CHECK TOMBSTONES BEFORE CONCLUDING SOMETHING IS MISSING - that is now three for three in one day.

    Johannes "Jan" Oosthuijsz (stamvader)

    geopen 2026-08-11

  32. Read the diagrams for Brasse Fontein 371 and Welbedagt 555 LEAD-0172

    Five SG diagrams are in the inbox unread: 10051901 and 10051902 for farm 371 in two parts, 10052409 for 371, and 10053943 and 10053944 for Welbedagt 555. Do any of them name a van Wyk, a Nel or a van der Merwe on the title or a boundary?

    Wat ons verwag het: BOTH FARMS ARE IDENTIFIED BY INFERENCE AND NEITHER IS PROVEN. Brasse Fontein 371 is where Christina Elizabeth Nel died and Welbedagt 555 is the only farm of that name in the division and Jacobus Alewyn van der Merwe was known as "Kwaai Koos Welbedacht". A diagram naming the family on either would turn an inference into a fact, and this project has watched farm-name matches fail all week.

    Wat dit sou uitmaak: A van Wyk on the title of 371, or a van der Merwe on 555.

    Wat dit beslis het: Opened 11 Aug 2026. The diagrams arrived while the data was being written and have not been read. | [CLOSED 11 Aug 2026, SRC-415 to SRC-418] ALL FOUR SHEETS READ, AND THE ANSWER IS SPLIT. WELBEDAGT 555: yes, and better than asked - the 1823 diagram was measured FOR CAREL AARON VAN DER MERWE himself. BRASSE FONTEIN 371: a van der Merwe is on a title, but in 1915, not 1890 - Portion 2 (Brassefontein West) was transferred to JACOBUS A. VAN DER MERWE by deed 8683 on 30 December 1915, twenty years after Christina Elizabeth Nel died there. AND THE GRANTEE IS NOT A VAN WYK. Both portions read "granted to M.J. VAN DYK December 12th 1890", and the initial letter matches the D of December on the same typed line. The family report of a van Wyk grant is NOT confirmed by these sheets; it may still be true of the Remainder, which neither sheet describes. No Nel appears on either.

    Brasse Fontein Nr. 371 · Welbedagt Nr. 555

    geopen 2026-08-11

  33. Which Bloemendal did Tokkie own, and when did he hold it and Tabaklande? LEAD-0187

    [FAMILY] Tokkie also owned Bloemendal and Tabaklande. Tabaklande is unambiguous - farm 164 portion 2, now PAR-000201. BLOEMENDAL IS NOT: this district has three farms of that name and a fourth thing called Bloemendal inside one of them. Bloemendal Annex No. 164 (PAR-000128), Bloemendaal No. 165 (PAR-000093), Bloemendal A No. 166 (PAR-000129), and the 2023 valuation roll also names farm 165 portion 2 'Bloemendal' at 15.4 ha. Which one is it, and what are the dates of both holdings?

    Wat ons verwag het: Tabaklande is a portion of Bloemendal Annex No. 164, so 'Bloemendal and Tabaklande' most naturally means the Annex and a piece of it. Against that, Bloemendaal No. 165 is the larger farm and the plainer referent of the bare name. Suggestive, not evidence: this project has been caught before by a name that looked like it could only mean one thing.

    Wat dit sou uitmaak: Frans naming which Bloemendal, or a deeds report showing the transfers in and out.

    Wat dit beslis het: Opened 13 Aug 2026. The ownership row OWN-000104 records the Tabaklande holding at LOW confidence with no dates, because family knowledge gave the fact and not the years; nothing here invents a range. NO OWNERSHIP ROW WAS CREATED FOR BLOEMENDAL AT ALL, because a span has to point at one parcel and there are three candidates - recording it against the likeliest would have manufactured a fact out of a guess. | [13 Aug 2026] OWN-000105 now records the holding against Bloemendal Annex No. 164 (PAR-000128), because Tabaklande is that farm's portion 2 and he named the two together - a pairing, not a document. The lead stays OPEN on the question it was opened for: which of the three Bloemendals. A deeds search on farms 164, 165 and 166 settles it, and so does one word from Frans. | [14 Aug 2026] CLOSED, AND THE ANSWER WAS NOT THE ONE THIS LEAD'S OWN HYPOTHESIS PREFERRED. Frans gave a coordinate, -33.273998, 22.375727; it falls inside BLOEMENDAL A No. 166 (PAR-000129), and he confirmed: "that is the farm Tokkie had... he had Tabaklande too". So the two holdings are two separate farms 1.9 km apart, not a farm and its own portion, and the pairing argument that put OWN-000105 on Bloemendal Annex No. 164 was wrong. Worth keeping as a worked example: three farms of one name inside 2 km, and no amount of reasoning about which reading was more natural could separate them - a point on the ground did it in one move. What is still open is not this lead: the DATES of both holdings, which a WinDeed search on farms 166 and 164 portion 2 would give. | [14 Aug 2026] THE ANSWER RECORDED YESTERDAY WAS WRONG, AND SO WAS THE MORAL DRAWN FROM IT. 274613 / 22.388809 - and it falls inside BLOEMENDAAL No. 165 (PAR-000093), 1.22 km from the point that closed this lead and inside a different farm. The holding moves there. Note what this does to the sentence written above, that "a point on the ground did it in one move": the point did move it, twice, and the second move was to a third farm. The lead stays CLOSED on which Bloemendal, now farm 165, and the DATES of both holdings remain open - a WinDeed search on farm 165 and on farm 164 portion 2 is the way to settle them.

    Gert Annis Oosthuizen Marincowitz · Tabaklande (Bloemendal Annex Nr. 164 Gdlt 2) · Bloemendal Annex Nr. 164 · Bloemendaal Nr. 165 · Bloemendal A Nr. 166

    geopen 2026-08-13

  34. Seven people carry a hand-entered FamilySearch id that the family-tree disagrees with LEAD-0019

    Backfilling familysearch_id from the family-tree's _FID tag agreed with the hand-entered value on 103 of 110 people and disagreed on 7. Which id is current for each - or do both resolve to the same person after a merge?

    Wat ons verwag het: Most likely FamilySearch merges: when two profiles are merged the losing id redirects to the survivor, so both ids can be 'right' and resolve to one person. Three of the seven family-tree ids share a GHF6- prefix (GHF6-4KQ, GHF6-HMP, GHF6-4KH), which is the signature of a duplicate cluster rather than seven independent errors. The alternative - that a person was matched to the wrong profile - is the one that would matter, and it cannot be ruled out from here.

    Wat dit sou uitmaak: A redirect proves a merge and the survivor id is the one to keep. Two live, distinct profiles means one of them is the wrong person, and the vitals decide which.

    Wat dit beslis het: Low priority - the site links to whichever id is recorded and a merged id still resolves. It becomes urgent only if one turns out to be a wrong-person match. | [CLOSED 9 Aug 2026] DUPLICATE OF LEAD-0036, which asks the same question over a superset of the same people. This lead's seven (PER-000056, 000134, 000158, 000383, 000443, 000455, 000470) are all nine of LEAD-0036's less PER-000211 and PER-000246. Same test, same fix, one opened hours after the other on 31 Jul 2026. Work it on LEAD-0036.

    Gerolm Samuel Marincowitz · Hendrik Johannes Oosthuizen · Roelof Daniel Jacobus Oosthuysen · Ockert Almero Oosthuizen · Adriana Cecilia Oosthuizen · John Peter Oosthuizen

    geopen 2026-07-31

  35. What should farm 12 be called on this site - Riet Fontein or Minnies Kraal? LEAD-0085

    The farm's own 1839 and 1868 diagrams title it RIET FONTEIN No 12; the modern cadastre and local usage call it MINNIES KRAAL. Which name should the map and the pages carry?

    Wat ons verwag het: A RENAME WITH A DATE SOMEWHERE IN BETWEEN, which nobody here has yet found. The identification of the two as one farm is not in doubt - the 1868 diagram gives 15 167 morgen 520 sq roods = 12 991,0 ha against the cadastre's 12 957,1 ha for farm 12, 0,26% apart, and the 1839 diagram's boundary list names Antjes fontein and Riet Port, which are exactly the farms the polygon touches. What is missing is WHEN and BY WHAT INSTRUMENT the name changed.

    Wat dit sou uitmaak: A dated document carrying the name Minnies Kraal for farm 12, or a deed recording the change.

    Wat dit beslis het: Applies to the three portions too - PAR-000158/159/160 are currently named Minnies Kraal Remainder, Portion 1 and Portion 2, following the cadastre. 5 Aug 2026: the 1990 Farm 215 consolidation sheet (DOC-0238) names farm 12 RIETFONTEIN, twice, on its neighbour ring. That is a Surveyor-General sheet using the name 150 years after the 1839 diagram did, which narrows the question from 'which name is right' to 'when did local usage diverge from the sheets'. | CLOSED 10 Aug 2026. RIETFONTEIN, on the farm's own diagrams. SG 5774/58 of May 1958 [SRC-350] titles it 'Gedeelte 1 van die plaas RIETFONTEIN Nr 12' and SG 8388/1994 [SRC-352/353] titles it 'PORTION 2 OF THE FARM RIETFONTEIN NO. 12'. Two surveyors, thirty-six years apart, one name, and neither sheet says Minnies Kraal. The four farm-12 rows are renamed. The cadastre's MINNIES KRAAL for farm 12 is now itself the open question, LEAD-0147.

    Rietfontein Nr. 12 · Rietfontein Nr. 12 Restant · Rietfontein Nr. 12 Gdlt 1 · Rietfontein Nr. 12 Gdlt 2

    geopen 2026-08-04

  36. Okkert Jacobus Oosthuizen, dead in 1842 on Uitnood in the Swartberge LEAD-0134

    A stone on Uitnood 147, 23 km from Klaarstroom, reads OOSTHUISEN Okkert Jacobus and gives 1842 and no birth year. Who was he, and what was an Oosthuizen doing on that ground sixteen years before this project's root couple died?

    Wat ons verwag het: A brother or a cousin of Ockert Almero Oosthuizen. The name Ockert Jacobus recurs hard in this family - the model holds eleven of them - so he is very likely of the same stock.

    Wat dit sou uitmaak: A death notice of 1842, which would give his age, his parents and his estate.

    Wat dit beslis het: Raised 7 Aug 2026 from the Willowmore eGGSA sweep, run by radius from Klaarstroom. | [7 Aug 2026] CLOSED THE SAME DAY. The rest of the stone reads: died 9 October 1842, aged 2 years and 10 months. He is Ockert Jacobus Oosthuizen [PER-000848], born 28 November 1839, a son of Gert Adriaan Oosthuizen - a person already in this project whose death date was blank. The lead assumed an adult of the root couple's generation and was wrong about that; the age on the stone is what settled it. WHAT REMAINS is the household: a child buried on Uitnood in 1842 means Gert Adriaan Oosthuizen was on or near that ground, 23 km from Klaarstroom, seventeen years before the root couple died. That is worth its own question.

    geopen 2026-08-07

  37. Is Jacobus Johannes Gideon Nel the father of Christina Elizabeth Nel? LEAD-0159

    He stands at the 1887 baptism of her first recorded child, and her son born the next year is christened Jacobus Johannes Gideon. Is he her father?

    Wat ons verwag het: VERY LIKELY, ON THE NAMING ORDER AND NOTHING ELSE. The Cape pattern gives the second son the mother's father's name, the witness is present at the elder sibling's font, and the family was of Brandvlei where she was living when she married in 1885. That is a pattern, not a parentage, and this record does not join people on a name.

    Wat dit sou uitmaak: Her baptism entry, naming her parents.

    Wat dit beslis het: Opened 11 Aug 2026 from the six register photographs | CLOSED 11 Aug 2026, ANSWERED YES, AND WITH MORE THAN WAS ASKED. The Calvinia baptism index for 1867 (SRC-399) and her 1895 death notice (SRC-400) both name her parents as JACOBUS JOHANNES GIDEON NEL and ANNA JACOBA VAN WYK. The lead reasoned from the Cape naming order alone and got it right; what it did not see is that BOTH of the 1887 witnesses were her parents, so two of the four names at that font are the child's maternal grandparents. Both are now rows here.

    geopen 2026-08-11

  38. Did Anna Maria Visagie belong to this Schalk Willem Burger van der Merwe at all? LEAD-0160

    She entered this model on Janet Melville's reading of the 1863 Calvinia baptism register. That register has now been read directly and does not mention her. Was she ever his wife?

    Wat ons verwag het: SHE PROBABLY BELONGS TO A DIFFERENT MAN OF THE SAME NAME. Two things point that way. The reading that produced her is demonstrably wrong on the same page. And this Schalk Willem Burger was born on 23 February 1833, so a wife who died in 1853 would have married him before he was twenty-one. Melville's report is keyed to Van der Merwe [70897], a number this project cannot resolve, and the name recurs in the family. Against that, she gave a death year, which suggests she had a death notice in front of her for somebody.

    Wat dit sou uitmaak: A death notice for Anna Maria Visagie naming her husband.

    Wat dit beslis het: Opened 11 Aug 2026 from the six register photographs | CLOSED 11 Aug 2026, ANSWERED YES, and this lead was wrong. The Hantam marriage register (SRC-383) has the marriage on 13 January 1851 with his own father consenting by name. The argument this lead made - that a wife dead in 1853 would have meant marrying before he was twenty-one, and that she therefore probably belonged to a different man of the same name - was sound reasoning from the wrong premise. He married at seventeen. Worth keeping visible: the lead was opened the same morning the register arrived, and the register was three hours away.

    geopen 2026-08-11

  39. Two Visagie households, each with a van der Merwe mother, marry into this line LEAD-0161

    Izaak Heremias Visagie married Johanna Sophia van der Merwe in 1812 and Hendrik Johannes Visagie married Louisa Jacoba van der Merwe about 1828. One supplied a first wife to this line in 1851 and both supplied a witness at a font in 1863. How are the two Visagie men related, and where do their van der Merwe wives sit in this pedigree?

    Wat ons verwag het: THE TWO VISAGIE MEN ARE VERY LIKELY BROTHERS - born 1792 and 1801, both in the same district, both marrying van der Merwe women within about sixteen years of each other, and their children christened across the same small set of names. The van der Merwe wives are the more useful question: if either is a daughter of Carel Aaron van der Merwe (PER-001639), then Schalk Willem Burger's first marriage in 1851 was to a first cousin, which is exactly the pattern his SECOND marriage follows. Nothing here tests that and it is not asserted.

    Wat dit sou uitmaak: Parentages for Johanna Sophia van der Merwe 1796-1872 and Louisa Jacoba van der Merwe 1802-1845.

    Wat dit beslis het: Opened 11 Aug 2026 from the FamilySearch pages | CLOSED 11 Aug 2026, THE SAME DAY IT WAS OPENED, and the prediction it made was right. It guessed that if either Visagie wife were a daughter of Carel Aaron van der Merwe then the 1851 marriage was a cousin marriage. BOTH ARE HIS DAUGHTERS. Johanna Sophia van der Merwe 1796-1872 (LWFG-THQ) and Louisa Jacoba van der Merwe 1802-1845 (LZ2Z-2XD) appear in Carel Aaron's own child list on FamilySearch under the very ids recorded from the Visagie side hours earlier (SRC-386, SRC-388). THAT IS AN IDENTIFICATION BY ID, NOT BY NAME, which is the only kind this project accepts here. So the two Visagie men married two sisters, and every Visagie standing beside this family - the first wife in 1851, both witnesses in 1863 - is a descendant of Carel Aaron coming back round. The remaining half of the question, how Izaak Heremias and Hendrik Johannes Visagie are related to each other, is NOT answered and is not pursued: under 9a that is their community, not this line's ancestry.

    geopen 2026-08-11

  40. Was Oupa Walters kin to Paul Kruger, or to Jan Smuts? LEAD-0164

    The 1987 memoir says Jacobus Abraham Walters (1877-1962) was a cousin of President Paul Kruger. Frans's own recollection is that the connection was to Jan Smuts. Which, and how?

    Wat ons verwag het: BOTH SURNAMES ARE ALREADY IN HIS HOUSEHOLD AND THEY POINT DIFFERENT WAYS. His wife is MAGDALENA MARIA KRUGER, so a Kruger link runs through her and he is kin by marriage - which fits a memory that has drifted one step. His son born 1911 is JACOBUS ABRAHAM SMUTS WALTERS, and in this family a surname used as a given name means a surname in the ancestry, not a hero. So the memoir has the right family and possibly the wrong president, and the Smuts name has the better claim to be genealogical. GENERATION FAVOURS SMUTS TOO: a man born 1877 is a natural cousin of Smuts, born 1870, and an awkward one of Kruger, born 1825.

    Wat dit sou uitmaak: A documented descent joining either family, or the missing first page of the memoir.

    Wat dit beslis het: Opened 11 Aug 2026 from the 1987 memoir. | CLOSED 11 Aug 2026 by the missing first page of the typescript (SRC-395), which the memoir itself had pointed at. THE ANSWER IS BOTH, AND NEITHER IN THE WAY THE MEMOIR PUT IT. The KRUGER is Oupa Walters's WIFE's maiden name - "die Carnarvon Kruger's" - so a Kruger kinship runs through her and he is kin by marriage, which is what this project deduced from the model before the page arrived. The SMUTS is real too and older: her mother was born Smuts. But the Smuts in Jacobus Abraham SMUTS Walters's name is neither of those - GENERAL JAN SMUTS STOOD GODFATHER to him in 1911, after his parents had promised the unborn child to Smuts because they could not afford another. Frans's instinct that Smuts was the real connection was right; the mechanism is a godparent, not a cousin. What is still undocumented is whether either presidential kinship is genealogical at all. LEAD-0166.

    geopen 2026-08-11

  41. A leak test fired on my own prose, not on a broken gate LEAD-0177

    Why did the public build report blocked media as named in data.json when the export drops those rows on rights?

    Wat dit beslis het: TWO RULES COME OUT OF THIS AND BOTH ARE CHEAP. Describe a withheld item in WORDS, never by id, in anything the public build emits - an id is a handle, and a published page naming the id of a withheld photograph tells a reader exactly what to ask for. And CHECK THE IMG STEM IS FREE before filing: media ids and image stems are numbered independently here and they had drifted apart, so the next free MED number was not the next free IMG number. The real cost was a wrong finding written down as a fact, which is the 5a note 5 mistake - an inference stated as a finding.

    geopen 2026-08-11

  42. Mev. Oosthuizen, killed September 1793 - CLOSED, the record is the north-west Cape LEAD-0180

    The Council of Policy record of 27 September 1793 names an OOSTHUIZEN woman, given only as 'Mev.', among three people killed in the Swellendam district. Who was she, and was she on this project's ground?

    Wat ons verwag het: Probably not resolvable from the summary alone. 'Mev.' with no forename is how the clerk wrote it, and the depositions themselves - which would name her - are the part not transcribed here.

    Wat dit sou uitmaak: A forename in the depositions, or a Swellendam estate record of 1793-94 for an Oosthuizen woman. Either would also settle the place question, which the summary cannot.

    Wat dit beslis het: CLOSED THE SAME DAY IT WAS OPENED, on the Dutch transcription. Answering the question the lead asked - was she on this project's ground - NO, and the candidate work below is void. The killing was 'in het Gebergte tusschen Namaqualand en de Oliphantsrivier', with Picqueniersklooff named alongside: the north-west Cape, not the Koup. Swellendam is where the report was WRITTEN, not where the people died. And she is 'een Huisvrouw van Jemand genaamd Oosthuizen' - the record never held a forename, so no source could have supplied one. THE THREE TREE CANDIDATES ARE WITHDRAWN, not merely unproven. Johanna Jonker, Hester Gouws and Johanna Petronella Oosthuizen were ranked mainly on Swellendam and on death-date bands around 1793, and the district was the artefact. Johanna Jonker's 'died before 1794 at Swellendam' is now evidence of nothing in particular. Do not resurrect this matching. WHAT WENT WRONG IS WORTH MORE THAN THE LEAD WAS. Three separate index features each pointed the wrong way and agreed with each other: the locations array carried Coupasberg, Couga and Zwartenberg for an entry whose text contains none of them; the English summary said 'Swellendam district'; and the person index rendered an unnamed woman as 'OOSTHUIZEN, (Mev., Vermoorde)', which reads exactly like a named person. An index is a finding aid. The transcription is the evidence. This project already knew that - 5a note 5, an inference is not a finding - and it still took reading the Dutch to catch it. STATUS: closed. The out-of-scope reason is the whole of this note and the title; the status vocabulary here is open/closed/parked and does not need widening to carry it.

    geopen 2026-08-12

Terug na die oop vrae