Atelier / ← Archive Duchastel · Fiches Duchastel · Français
The proposed format, worked through on real records from the family notes — including the awkward cases: a second marriage to an unnamed wife, a parentage that is only presumed, and a construction date the sources cannot agree on.
Everyone below already appears in duchastel_maison.md. Nothing here is
invented — including the gaps, which are the interesting part.
The earliest known ancestor. Married Jeanne Desombres.
Député de l'Aube. Bought the Crogny estate in 1793, built the château in 1815.
Married Sophie Legoix at Reims, 19 May 1813. Parents not established.
Daughter of Victor André Legoix de Monthoury. Brought Monthoury into the family.
Sold Monthoury to Léon Frassant, 11 July 1938.
Wrote the 1938 letter recording the sale, during a summer stay at Monthoury.
This is the correction that makes everything else work. A person record carries names, sex, birth, death — facts about one individual. It carries no marriages and no parents, because those are facts about a pair or a group, and storing them on one member is what makes them drift.
id: duchastel-louis-francois-1784
type: person
sex: M
name:
given: Louis-François
surname: Duchastel
lineage: duchastel # a facet, not a membership
variants: ["Alexandre Louis-François Duchastel de Montrouge"]
birth: { date: { year: 1784 }, conf: probable }
death: { date: { year: 1863 }, conf: probable }lineage is a facet and not a family objectThe family records themselves carry du Chastel, Duchastel, Duchatel, Dûchatel, and Duchastel de Montrouge — one lineage, five spellings, and people marrying in and out of it constantly. Hard membership would be a lie.
So a lineage is a label for grouping and search. It still gets a page, and that page still lists key members — but the list is curated by hand, not computed. A family page is a story someone chooses to tell, not a set the machine derives.
A union is its own record, referencing its partners. That one move handles every case the family records throw up, and several they have not yet.
id: duchastel-legoix-1813
type: union
kind: marriage # marriage | civil | liaison | unknown
partners: [duchastel-louis-francois-1784, legoix-sophie-1790]
order: 1 # first marriage for both
begin:
date: { year: 1813, month: 5, day: 19 }
place: reims
conf: proven
end:
date: { year: 1860, month: 1, day: 30 }
reason: death # death | divorce | separation | annulment | unknown
conf: proven
A divorce is reason: divorce. A third marriage is another union file with
order: 3. A relationship that produced children without a marriage is
kind: liaison. None of these are special cases in the code — they are values
in a field.
The Montflambert source says Boucher de Crèvecœur married Françoise-Marguerite « en premières noces » — in his first marriage. Which establishes that a second marriage existed, while saying nothing whatsoever about it:
id: crevecoeur-2
type: union
kind: marriage
partners: [boucher-de-crevecoeur-pierre-joseph-nd, null]
order: 2
conf: probable
note: "Implied by « en premières noces ». Spouse unidentified."
A null partner is a legitimate record. The union is drawn in the tree as an
unnamed node, it appears in the research log as an open question, and the day her name
turns up, one field gets filled in — nothing else changes.
This is the “unknown parents that become known later” case. Parentage is a separate record, so it can exist as a guess, be argued with, and be upgraded — all without touching the person.
The Monthoury notes contain a perfect specimen. The archivist writes that one can presume the château belonged to Victor André Legoix, father of Sophie:
id: legoix-sophie-1790-parents
type: parentage
child: legoix-sophie-1790
parents: [legoix-victor-andre-1754]
kind: birth # birth | adoptive | step | presumed
conf: probable
sources: [ad-aisne-baumard-2022]Nothing stops two parentage records naming different fathers for the same child, each with its own confidence and its own sources. That is not a bug in the data — it is an honest picture of an unresolved question, and it is exactly what the research log should be surfacing.
Once it is settled, one conf gets raised and the other is deleted or
demoted. The person record never moves.
Montflambert has a real contradiction sitting in the notes right now. One passage dates the buildings to the seventeenth century; the summary line puts construction at the end of the eighteenth, with three question marks.
built:
date: { year: 1600, qualifier: circa }
conf: disputed
conflict:
- claim: "XVIIe siècle"
source: academie-reims-v87
- claim: "fin XVIIIe"
source: notes-famille
question: montflambert-date-constructionOn the page, that renders as:
Colour is deliberately not used. The ordinal ramp reads by fill — ●Attesté ◐Probable ○Possible — while the two categorical flags get an outline instead, so they read as a different kind of mark rather than a further step down the same scale: ◈Hypothèse ▲Contradiction
This survives greyscale printing, photocopying, every form of colour blindness, and a phone screen in sunlight. If colour is ever wanted, it layers on top as a redundant second signal without changing any data.
Nothing below is written by hand. Every line is collected from the conf and
questions fields in the records above.
Qui a construit le château de Monthoury, et vers quelle année ?
Le château de Montflambert date-t-il du XVIIe ou de la fin du XVIIIe ?
Qui était la seconde épouse de Pierre-Joseph Boucher de Crèvecœur ?
Qui sont les parents de Louis-François Duchastel (1784–1863) ?
Avez-vous une photographie de l'intérieur de Monthoury ?
Où se trouvait exactement la résidence rue Saint-Étienne à Reims ?
Each question has its own anchor, so a cousin can be sent a link to exactly the photograph question rather than to a page of six. Répondre opens a two-field form — no account, no login.
The rule applies to birth dates only. A birth date shows if the birth was at least a century ago, or the death is known and at least ten years past. Death dates, marriage dates, places, and names stay public throughout. Run against the cast, in 2026:
| Person | Birth | Death | Shown | Because |
|---|---|---|---|---|
| Jacques du Chastel | 1624 | 1714 | 1624 – 1714 | Died 312 years ago |
| Sophie Legoix | 1790 | 1860 | 1790 – 1860 | Died 166 years ago |
| Pierre Duchastel | 1915 | 1991 | 1915 – 1991 | Died 35 years ago |
| Jacques William Duchastel | 1888 | unknown | 1888 – ? | Born 138 years ago |
| Michèle, as seen in 2020 | 1945 | 2012 | années 1940 · d. 2012 | Only 8 years since death |
| Michèle, as seen in 2026 | 1945 | 2012 | 1945 – 2012 | 14 years since death |
| A cousin born 1954 | 1954 | living | années 1950 | Living, born 72 years ago |
Jacques William is the instructive row: no death date at all, yet the birth still shows, because 1888 clears the century threshold on its own. Without that clause, every person whose death was never found would be treated as living forever.
Look at the 2020 row. Années 1940 is safe by itself. Put it beside “died 2012” and “died aged 67”, and 1945 has been republished exactly — any two of those three recover the third.
So suppression must cascade to computed values as well as stored ones: age at death, age at marriage, age recorded in a census. That is precisely why it lives in one function instead of being applied page by page.
webtrees hides everything about a living person and prints “Private” as the name — the right call for a site open to strangers. For a family archive it is the wrong trade: a tree becomes unreadable when it is impossible to tell which generation someone belongs to. A decade keeps the structure legible while giving away nothing usable.
The century threshold itself is the genealogical standard — British genealogists publish under a “GEN100” mark to signal it, and it mirrors how the records are governed: birth records restricted 75–100 years, death and marriage records only 50–75.