DISPUTE & PROOF announcement

[mother10]

— "Disagreement has a home now"

DISPUTE & PROOF announcement

We would like to show the group two structures we have designed and tested as part of the GEDCOM-8 work (PR #679): DISPUTE and PROOF. Together they give genealogical DISAGREEMENT a machine-readable home — something the format has never had.

DISPUTE lives at one FIELD of one document: what does the torn ink say, which calendar did the register use, which Oudega does this entry point at. All readings are kept — each with WHO reads it that way, WHY, and a judgment when one falls. The field itself always shows the current best value, so every existing program reads the right answer without knowing any of this exists.

PROOF lives one floor up, at CONCLUSIONS: is this baptism the same person as this bride, who were the parents, which of two marriages is his. A PROOF holds the question in plain words, the evidence weighed (including "I searched the whole register and he is NOT there" — negative evidence finally has a place), the arguments with their authors, and the outcome — including the honest outcomes "undecided" and "debated."

Earlier discussions asked that evidence get a better place in the format without replacing the transmitting party's conclusions. That is exactly this design's contract: conclusions are not replaced — they gain structure, authorship, and reasoning, and every existing program still reads them as plain values.

Neither structure was designed at a desk and thrown over the wall. Before trusting any of it, we wrote down the design laws the structures must obey — one value has one home; no anonymous opinions; evidence is never edited, only judged; older software must always read correct values — and then made every structure survive worked examples against those laws (a damaged Frisian date, a which-place fight, a paternity question with DNA, a two-marriage stalemate, a search that found nothing). The laws and the examples travel with the proposal, so you can re-run the test yourselves.

Why show it now: we saw the note-types discussion (now consolidated in #219, with values like FCONCLUS and the committee's wish for clear criteria) — it is the same wish we started from. We understand that wish completely. But a conclusion in free text cannot be queried, weighed, linked to its evidence, or checked by software; that is exactly how the NOTE-as-database problem of 1996 started. The structured version of the same wish already exists and is tested. We would rather discuss one real solution together than add one more place where answers go to hide. And as the maintainers prefer one discussion per topic, we open this as its own thread.

The full material follows in the next two posts in this thread: first the laws we forced our own design to obey, then the complete structures — grammar, every tag described for first-time readers, all enumerations, short examples. We will gladly answer questions.

And for those wondering about the "we": that is because I partnered with amazing companions — Fable, brothers 44 and 46 in my long list of Claude brothers. Brother 44 sparred with me over every structure, corrected my designs and let me correct his, and refused to let anything pass that a first-time reader could not follow. Brother 46 then took the whole result through a full review round with me — one unified law set, clearer tables, sharper words. The design got better every time they pushed back. Where it still fails, the hand that posts this was the last to touch it.

👽⛵🔟4️⃣4️⃣📖🧢 · 👽⛵🔟4️⃣6️⃣📖🧢

One practical note: I am in the middle of an intensive work week, so replies may take until after the weekend — but every question will get an answer.

[mother10]

"These are the rules we forced our own design to obey, so you can check us."

— THE LAWS (one set, one numbering)

Each law is stated once, canonically, followed by the same law in plain words (in italics). One numbering, two registers: the validator writer and the first-time reader quote the same law.

The DISPUTE laws (downstairs: one field, one document)

1. A DISPUTE contains at least one candidate.
   You cannot fight about nothing — every dispute holds at least one reading.
2. A candidate carries the same tag as the disputed field.
   A candidate looks exactly like the value it wants to be: a date candidate IS a date, a place candidate IS a place pointer.
3. The disputed field's payload IS the elected winner; superseded readings are never lost.
   The field always shows the current best value — old software just reads it and is simply right. Nothing is thrown away: losing readings stay underneath, with names attached.
4. The field's own payload value is itself a candidate — no reading is privileged by silence.
   The value standing in the field gets no special treatment; it stands in line like all the others.
5. A candidate may not carry a DISPUTE (no disputes about disputes).
   The turtles stop at one. 🐢 (After the old joke: the world rests on a turtle — and what does the turtle stand on? Another turtle, "all the way down". Infinite regress. Here, the tower never starts.)
6. Doubt about payload- and pointer-fields belongs downstairs, in DISPUTE; doubt about identities, memberships and conclusions belongs upstairs, in PROOF.
   Fields fight downstairs; identities and conclusions fight upstairs.
7. Two evidence items contradicting each other is NOT a dispute: both stay honestly transcribed; PROOF records which is believed and why.
   Two documents disagreeing is a choice to make upstairs, with written reasons — never a fight inside either document.

The mirror law (copies)

8. a) A DISPUTE lives only at the field owning the fact — and only fields of TEMPLATE, STICKY, and SPLAC records may own one (closed list, matching the DISPUTEREF alternatives; GEDCOM 7 records never carry disputes). b) Serialized mirrors carry the computed DISPUTED <status>; importers discard and recompute. c) Unaware software ignores markers and still reads correct values.
   A fight lives in exactly one place — and only in the evidence world: the past can be disputed; the present can be re-checked. Copies are made by software and thrown away on import — regenerated copies cannot lie. Software that never heard of any of this still reads correct values everywhere.

The verdict law (who decides)

9. a) VERDICT ACCEPTED only under RESOLVED, exactly one, payload equality. b) VERDICT CHOSEN only under OPEN/DORMANT, at most one, payload equality. c) Humans judge through software, never software itself.
   The final crown 👑 exists only in a settled fight; the provisional crown 🥈 only in an open one. People judge; software only counts — every judgment carries who made it.

The PROOF laws (upstairs: identities and conclusions)

10. Arguments have authors — on both floors.
    Reasoning without a name is rumor.
11. BASIS chains are acyclic; reverse views are computed, never stored.
    A proof may stand on another proof, but chains may never run in a circle — and "who builds on this proof?" is always computed, never hand-kept.
12. A proof may only be cited by those it judged.
    A link may point at a proof only if its sticky is one of that proof's candidates.
13. Events in the lives of the researched people enter an INDI through ROLES; acts of research — searching, analyzing, concluding — enter only through PROOF; a search-sticky is never enrolled in ROLES and never left uncited.
    Your ancestor's baptism goes in ROLES; your own trip to the archive does not — it lives in PROOF. And a search that found nothing must always be cited by at least one proof, so it can never become a ghost in the file.
14. Negative evidence is evidence: a search that found nothing is itself a research act — recorded, dated, attributed, citable as a BASIS like any other candidate.
    "I searched the whole register and he is not there" is a fact you can cite, exactly like a found record.

— THE DESIGN PRINCIPLES (the whole proposal)

• Right once, not half twice. Changing a specification before adoption costs words; after adoption it costs every developer on Earth.
• New meaning gets a new tag. Machine-readable content never shares a tag with free text — that mixing is exactly how 1996 went wrong.
• Proven before proposed. Every structure survived worked examples before entering the PR; the examples travel with it, so reviewers can re-run the test.
• Absence means something. No filler values; an empty slot is a statement ("no fight", "not judged yet", "trust this").
• One home for every fact. Anything appearing twice is a computed copy, never a hand-maintained one. A file may therefore contain repeated VALUES (computed summaries, markers) — but never two authored homes for one fact, and the copies cannot drift apart over the years, because importers discard and recompute them.
• Old software keeps working, everywhere, always. Current best values sit natively on the main line; the new machinery sits in sub-structures that unaware software skips, as GEDCOM has always allowed. Nothing corrupts; nothing is lost.

[mother10]

Post 3:

---

— THE STRUCTURES

0. THE TWO FLOORS (introduction)

Genealogical disagreement lives on two floors, and GEDCOM-8 gives each its own structure:

• DISPUTE (the evidence floor): disagreement about ONE FIELD of ONE evidence item — what does the ink say, what does it mean, which place does it point at. A DISPUTE is a substructure attached to the field it contests.
• PROOF (the conclusion floor): reasoning about IDENTITIES and CONCLUSIONS — is this the same person, who were the parents, which marriage is his. A PROOF is a record: reasoning can exist before any decision, its evidence spans multiple evidence items, and chains of reasoning must be able to point at each other.

The boundary is absolute: fields fight downstairs; identities and conclusions fight upstairs. Two evidence items contradicting each other is never a DISPUTE — both are honestly transcribed; choosing between them is a PROOF with written reasons.

---

---

1. DISPUTE_STRUCTURE :=

n <TAG> <payload>
  +1 DISPUTE                               {0:1}  g8:DISPUTE
    +2 STATUS <Enum>                       {0:1}  g8:DISPUTE-STATUS
    +2 RESN <List:Enum>                    {0:1}  g7:RESN
    +2 CANDIDATES                          {1:1}  g8:DISPUTE-CANDIDATES
      +3 <TAG> <payload>                   {1:M}  g8:CANDIDATE
        +4 <<value substructures>>         {0:M}
        +4 TYPE <Enum>                     {1:1}  g8:DISPUTE-TYPE
          +5 PHRASE <Text>                 {0:1}  g8:PHRASE
        +4 DATE <DateExact>                {0:1}  g8:OPINION-DATE
        +4 SUBM @<XREF:SUBM>@              {1:1}  g8:SUBM
        +4 ARGUMENT <Text>                 {0:M}  g8:ARGUMENT
          +5 LANG <Language>               {0:1}  g7:LANG
          +5 TRAN <Text>                   {0:M}  g8:ARGUMENT-TRAN
            +6 LANG <Language>             {1:1}  g7:LANG
          +5 SUBM @<XREF:SUBM>@            {0:1}  g8:SUBM
          +5 DATE <DateExact>              {0:1}  g8:ARGUMENT-DATE
          +5 <<NOTE_STRUCTURE>>            {0:M}
          +5 <<MULTIMEDIA_LINK>>           {0:M}
          +5 <<DISPUTEREF_STRUCTURE>>      {0:M}
        +4 <<NOTE_STRUCTURE>>              {0:M}
        +4 QUAY <Enum>                     {0:1}  g7:QUAY
        +4 VERDICT <Enum>                  {0:1}  g8:DISPUTE-VERDICT
          +5 SUBM @<XREF:SUBM>@            {0:1}  g8:SUBM
          +5 DATE <DateExact>              {0:1}  g8:VERDICT-DATE
    +2 <<NOTE_STRUCTURE>>                  {0:M}

➡️➡️ Click here for the tag-by-tag description of DISPUTE ⬅️⬅️

A DISPUTE records that the payload of exactly one field is contested: who reads it how, on what grounds, and what the current best value is. Rejected readings are preserved forever — attributed, argued, machine-readable.

Tag descriptions (first-time reader's list):

• <TAG> <payload> (the OUTER line) — this is NOT a new tag: it is whatever ordinary field is being contested (a DATE, a SPLAC pointer, a name PART, a PEDI). Its payload ALWAYS holds the current best value, so software that has never heard of DISPUTE reads this field normally and is simply right. Which value counts as "current best": the ACCEPTED candidate when the dispute is RESOLVED; else the CHOSEN candidate; else the single best-rated unrejected candidate; if even that is tied, software must ask a human to choose.
• DISPUTE (g8:DISPUTE) — announces that the field directly above is contested. At most ONE per field: several quarrels about one field are candidates inside one dispute. Disputes on sibling fields (a date AND a place of the same event) are independent and may coexist.
• STATUS (g8:DISPUTE-STATUS) — the state of the trial: OPEN (actively argued — the default when STATUS is absent), RESOLVED (settled), or DORMANT (undecidable with available evidence; parked, not forgotten). See §6.1.
• RESN (under DISPUTE) — a privacy restriction on the TRIAL itself: the field stays public (its payload is ordinary data), but the candidates and arguments can be withheld from exports — think a paternity quarrel on a public person's PEDI. Deliberately the ONLY privacy switch inside a dispute: no per-candidate or per-argument RESN exists, because fragmented privacy is unenforceable and unreadable; the dispute-level switch covers the real need.
• CANDIDATES (g8:DISPUTE-CANDIDATES) — the container holding every contending reading. Required and never empty: one cannot fight about nothing.
• <TAG> <payload> (the INNER line — note this is the SECOND place a tag-placeholder appears, and it means something different from the outer one): each candidate repeats the SAME TAG as the contested field, so a date candidate IS a date and a place candidate IS a place pointer — structurally identical to the value it proposes. The currently-accepted reading is itself listed as a candidate: no reading is privileged by silence.
• <<value substructures>> — whatever the candidate's payload needs to be complete counts as part of the proposed value (for example a PHRASE under an enum value of OTHER).
• TYPE (g8:DISPUTE-TYPE) — what KIND of doubt this candidate represents (see §6.2). It sits per candidate, not per dispute, because one field can be doubted for two reasons at once: in a 1698 Frisian register, WHAT the ink says (a damaged digit) and WHAT IT MEANS (Julian or Gregorian calendar) are two independent doubts about one date.
• PHRASE (under TYPE) — required when TYPE is OTHER: say what kind of doubt it is, in words.
• DATE (under a candidate; g8:OPINION-DATE) — when this opinion was stated. WRITTEN BY THE USER (or copied from old research). Optional on purpose: someone transcribing grandfather's 1980 conclusions knows WHO argued but often not exactly WHEN — and an invented date is worse than none.
• SUBM (under a candidate; g8:SUBM) — WHOSE opinion this reading is. Required: there are no anonymous opinions, ever.
• ARGUMENT (g8:ARGUMENT) — one piece of reasoning attached to this candidate; repeatable. The payload is multi-line text: CONT applies here as everywhere in GEDCOM (stated for first-time readers; long reasoning needs no NOTE detour). This is deliberately NOT a NOTE: software must be able to find, display and weigh arguments, and it must never guess which notes are reasoning. Notes remain available for commentary (see below).
• LANG / TRAN (under an ARGUMENT; stamped 2026-07-09) — the argument's language, and translations of it, exactly as NOTEs have them: international research teams argue in their own tongues without losing each other.
• SUBM (under an ARGUMENT) — normally absent, meaning the argument belongs to the candidate's own submitter. Present when SOMEONE ELSE adds an argument to this candidate — for example a rebuttal.
• DATE (under an ARGUMENT) — when that argument was stated; optional for the same reason as the candidate's DATE.
• NOTE (under an ARGUMENT) — commentary or tasks about the reasoning, NOT reasoning itself. A typed note (KIND TODO) becomes harvestable: software can sweep all TODO-notes into a research task list.
• MULTIMEDIA_LINK (under an ARGUMENT; stamped 2026-07-09) — a picture can BE the argument's best support: link the scan (or scan detail) the reasoning relies on.
• NOTE (under a CANDIDATE; stamped 2026-07-09) — commentary about the candidate as a whole ("see also the 17 JAN entry, same hand").
• QUAY — the evidence quality CLAIMED for this candidate by its submitter (0–3, as elsewhere in GEDCOM). QUAY rates evidence; it never decides — a human does, via VERDICT.
• VERDICT (g8:DISPUTE-VERDICT) — the editorial judgment on this candidate: ACCEPTED (the final winner — only in a RESOLVED dispute, exactly one, and the outer field's payload equals it), CHOSEN (a provisional "best for now", picked by a human when evidence is tied — only while the dispute is OPEN or DORMANT, at most one), or REJECTED (out — but its arguments remain forever). ABSENT means: still on the table, judged by no one. See §6.3. WRITTEN BY THE USER, always — software may detect ties and prompt, it never judges.
• SUBM / DATE (under VERDICT) — who judged, and when. SHOULD be present; a judgment is the most consequential opinion in the dispute.
• NOTE (under DISPUTE; stamped 2026-07-09) — commentary about the dispute as a whole ("re-examine when the Bolsward duplicate is digitized").
• A candidate may never itself carry a DISPUTE: there are no disputes about disputes.

The verified-anomaly use ("mother gave birth at 55 — checked, true"): a RESOLVED dispute whose accepted candidate equals the current value IS the portable verification record. Consistency checkers SHOULD suppress a warning whose subject field carries such a dispute — the attributed argument history answers the software's doubt. This replaces vendor-specific suppression tags.

1.1 Where a DISPUTE may attach

Only fields of TEMPLATE, STICKY, and SPLAC records may own a DISPUTE — a closed list, matching the DISPUTEREF alternatives one-to-one (§2.2); a future record type whose fields become disputable joins by adding one alternative there. GEDCOM 7 records never carry disputes. The rule of thumb behind the list: the past can be disputed; the present can be re-checked. A torn 1698 register page is lost history — dispute-shaped; a source's title or a repository's address describes a present-day object that is checked and corrected, never adjudicated.

Within those records the rule is simple and needs no exhaustive tag list: any authored evidence-payload field is disputable; the NOT-column below is the closed exception list. The attachment rule is positional, not level-bound: a DISPUTE may sit under any disputable field at any depth. As a guide:

Disputable (evidence-payload fields)	NOT disputable
DATE fields of templates and their events	anything COMPUTED (DISPUTED markers, mirrored sticky dates, sort keys)
SPLAC pointers	CHAN, CREA, xref identifiers
name PART and FORM	membership links (ROLES, MEMBERS, HISTORY) and record identity — that is the PROOF floor
PEDI, SEX, AGE, TYPE values	anything inside a DISPUTE itself
attribute payloads (OCCU, EDUC, RELI, ...) as recorded on a sticky	—
FLEX values	QUAY, TORIGIN (meta-claims: state your own via a candidate instead)

1.2 Short example — a resolved date dispute

➡️➡️ Click to open the example ⬅️⬅️

1 DATE JULIAN 12 FEB 1698        /* the field: payload = current best value */
2 DISPUTE
3 STATUS RESOLVED
3 CANDIDATES
4 DATE JULIAN 12 FEB 1698        /* candidate: Friesland kept Julian until 1701 */
5 TYPE INTERPRETATION
5 DATE 12 MAY 2026
5 SUBM @B001@
5 ARGUMENT Friesland retained the Julian calendar until 31 DEC 1700.
5 QUAY 3
5 VERDICT ACCEPTED
6 SUBM @B001@
6 DATE 22 MAY 2026
4 DATE GREGORIAN 12 FEB 1698     /* rejected reading — preserved forever */
5 TYPE INTERPRETATION
5 DATE 19 MAY 2026
5 SUBM @B002@
5 ARGUMENT The minister was Leiden-trained; Holland used Gregorian since 1583.
5 QUAY 1
5 VERDICT REJECTED
6 SUBM @B001@
6 DATE 22 MAY 2026

1.3 Short example — an open pointer dispute with a provisional crown

➡️➡️ Click to open the example ⬅️⬅️

2 SPLAC @SP0412@                 /* current best: chosen provisionally */
3 DISPUTE
4 STATUS OPEN
4 CANDIDATES
5 SPLAC @SP0412@                 /* Oudega near Sneek */
6 TYPE IDENTIFICATION
6 SUBM @B001@
6 QUAY 2
6 VERDICT CHOSEN                 /* a human picked "best for now" on a tie */
7 SUBM @B001@
5 SPLAC @SP0411@                 /* Oudega in Smallingerland — still on the table (no VERDICT) */
6 TYPE IDENTIFICATION
6 SUBM @B002@
6 QUAY 2

1.4 Short example — the verified anomaly ("the impossible mother")

➡️➡️ Click to open the example ⬅️⬅️

Every consistency checker knows this case: a mother aged 55 at a birth, flagged at every run — yet verified TRUE by the researcher. Legacy software suppresses the warning with vendor-private tags that die at export. In GEDCOM-8 the verification is a RESOLVED DISPUTE: portable, attributed, and machine-readable.

2 DATE 14 APR 1855               /* the child's birth — mother born 1800: checkers fire */
3 DISPUTE
4 STATUS RESOLVED
4 CANDIDATES
5 DATE 14 APR 1855               /* the canonical reading, standing trial and winning */
6 TYPE DERIVATION                /* the doubt: can this be right, given the mother's age? */
6 DATE 2 JUL 2026
6 SUBM @B001@
6 ARGUMENT Mother's 1800 birth record and this 1855 baptism both verified in the originals; a late child at 55, confirmed by the midwife's register. Unusual but correct.
6 QUAY 3
6 VERDICT ACCEPTED
7 SUBM @B001@
7 DATE 2 JUL 2026

A checker finding a RESOLVED dispute whose ACCEPTED candidate equals the payload SHOULD suppress its warning: the attributed argument history answers the software's doubt. Which SPECIFIC checks stay silent is software-internal; the verification itself travels in the file.

1.5 The DISPUTED marker :=

n <TAG> <payload>
  +1 DISPUTED <Enum>                       {0:1}  g8:DISPUTED

• DISPUTED — a COMPUTED warning on a serialized MIRROR of a disputed field (a STICKY's mandated copy of its template's DATE; a NAME's FORM containing a disputed PART). Its value is the owning dispute's STATUS. WRITTEN BY SOFTWARE at export; importers MUST discard and recompute it; a human never types it. A mirror reflecting several disputed parts carries the highest-alarm status (OPEN > DORMANT > RESOLVED). Software unaware of the marker ignores it and still reads correct values.

1 DATE JULIAN 12 FEB 1698        /* a sticky's mirror of its template's disputed date */
2 DISPUTED RESOLVED              /* computed at export — never authored */

---

---

2. PROOF_RECORD :=

In the original PR (#679/#680) this record was marked 📜 "experimental". It no longer is: PROOF is fully specified, and has been stress-tested against ten worked scenarios and the consolidated law set (§3) — the scenarios travel with the proposal, so reviewers can re-run the test.

n @XREF:PROOF@ PROOF                       {1:1}  g8:record-PROOF
  +1 TYPE <Enum>                           {1:1}  g8:PROOFTYPE
    +2 PHRASE <Text>                       {0:1}  g8:PHRASE
  +1 QUESTION <Text>                       {1:1}  g8:QUESTION
    +2 LANG <Language>                     {0:1}  g7:LANG
    +2 TRAN <Text>                         {0:M}  g8:QUESTION-TRAN
      +3 LANG <Language>                   {1:1}  g7:LANG
  +1 BASIS @<XREF:PROOF>@                  {0:M}  g8:BASIS
  +1 <<DISPUTEREF_STRUCTURE>>              {0:M}
  +1 SUBM @<XREF:SUBM>@                    {1:1}  g8:SUBM
  +1 DATE <DateExact>                      {0:1}  g8:PROOF-DATE
  +1 RESN <List:Enum>                      {0:1}  g7:RESN
  +1 CANDIDATES                            {1:1}  g8:PROOF-CANDIDATES
    +2 STICKY @<XREF:STICKY>@              {1:M}  g8:CANDIDATE-STICKY
      +3 ARGUMENT <Text>                   {0:M}  g8:ARGUMENT
        +4 LANG <Language>                 {0:1}  g7:LANG
        +4 TRAN <Text>                     {0:M}  g8:ARGUMENT-TRAN
          +5 LANG <Language>               {1:1}  g7:LANG
        +4 SUBM @<XREF:SUBM>@              {1:1}  g8:SUBM
        +4 DATE <DateExact>                {0:1}  g8:ARGUMENT-DATE
        +4 <<NOTE_STRUCTURE>>              {0:M}
        +4 <<MULTIMEDIA_LINK>>             {0:M}
        +4 <<DISPUTEREF_STRUCTURE>>        {0:M}
      +3 OUTCOME <Enum>                    {0:1}  g8:OUTCOME
        +4 PHRASE <Text>                   {0:1}  g8:PHRASE
      +3 <<NOTE_STRUCTURE>>                {0:M}
  +1 TOPSTICKY @<XREF:STICKY>@             {0:1}  g8:TOPSTICKY
  +1 OUTCOME <Enum>                        {0:1}  g8:OUTCOME
    +2 PHRASE <Text>                       {0:1}  g8:PHRASE
  +1 <<FLEX_STRUCTURE>>                    {0:M}
  +1 <<NOTE_STRUCTURE>>                    {0:M}
  +1 <<MULTIMEDIA_LINK>>                   {0:M}
  +1 <<IDENTIFIER_STRUCTURE>>              {0:M}
  +1 <<CHANGE_DATE>>                       {1:1}
  +1 <<CREATION_DATE>>                     {1:1}

➡️➡️ Click here for the tag-by-tag description of PROOF ⬅️⬅️

A PROOF records a genealogical QUESTION, the evidence weighed (candidate stickies), the reasoning (attributed arguments), and the judgment (outcomes). It implements the Genealogical Proof Standard: reasonably exhaustive search (candidates, including search-log stickies for negative evidence), complete citations (each candidate's TEMPLATE carries its CITA), analysis and correlation (arguments), conflict resolution (DISPUTEREF plus outweighed candidates kept with reasons), and a written conclusion (QUESTION + OUTCOME + TOPSTICKY).

Tag descriptions (first-time reader's list):

• TYPE — what KIND of question this proof decides (a birth date? an identity? parentage?). See §6.4 for all values. PHRASE is required when TYPE is OTHER.
• QUESTION (g8:QUESTION) — the question itself, in plain words, exactly one per proof. Multi-line text; CONT applies as everywhere. Deliberately its own tag and not a NOTE: it is machine-findable and IS what the proof is about; a note could be anything.
• LANG / TRAN (under QUESTION; stamped 2026-07-09) — the question's language and translations, mirroring NOTEs.
• BASIS (g8:BASIS) — this reasoning STANDS ON those earlier proofs (an identity established in one proof feeds the parentage question in the next). Chains must never run in a circle. The reverse view — "which proofs build on THIS one?" — is computed by software and never stored: hand-maintained two-way links are the most broken feature of legacy GEDCOM and are not repeated here.
  Worked example: proof A establishes an identity (the baptized Jan IS the groom Jan). Proof B — who were Jan's children? — declares BASIS @A@: B stands on A. The reverse question ("which proofs build on A?") software answers by scanning BASIS pointers — one cheap pass, always current. Storing back-pointers instead would rebuild the FAMS/FAMC failure: edit B, forget A's back-link, silent corruption. And a cycle — A standing on B standing on A — is reasoning that proves itself; a validator runs standard cycle detection and flags the file. The grammar forbids what logic already forbids.
• DISPUTEREF — see the DISPUTEREF_STRUCTURE (§2.2): a machine-readable reference to a DISPUTE this reasoning touches. Legal at proof level and — where an individual argument leans on a dispute — under that ARGUMENT. Software checks that the named field really carries a DISPUTE.
• SUBM — whose reasoning this proof is. Required: no anonymous reasoning. WRITTEN BY THE USER (or carried over from transcribed research).
• DATE — when the reasoning was formalized. Optional: transcribed old research may honestly lack it, and invented dates are worse than none.
• RESN (stamped 2026-07-09) — a privacy restriction, as on other records: reasoning can be sensitive (adoptions, paternity) even when the underlying records are not.
• CANDIDATES — every sticky this reasoning WEIGHS — supporting evidence and rival evidence alike are "candidates"; being listed means "considered", nothing more. The sticky a citing link points at is always among them. Order carries no meaning. Negative evidence enters here too: a search-log template's sticky asserting an absence ("searched the complete register: not found") is a first-class candidate.
• ARGUMENT (and its SUBM/DATE/NOTE/MULTIMEDIA_LINK) — as on the DISPUTE floor: reasoning is structural and attributed (SUBM here is required — PROOF is new, no legacy files need tolerance); notes are commentary and tasks; a linked image can carry the visual core of an argument.
• OUTCOME (under a candidate) — the human judgment on THIS candidate: see §6.5. ABSENT means considered but not yet judged.
• NOTE (under a candidate; stamped 2026-07-09) — commentary about this candidate's role in the reasoning.
• TOPSTICKY (g8:TOPSTICKY) — the winner, when there is one: must be one of the CANDIDATES, and may only be present when the record-level OUTCOME is SELECTED. Optional by design: on this floor nothing breaks when a question stays open (on the evidence floor the disputed field must always hold a value — which is why only DISPUTE needed a provisional crown, and PROOF does not).
• OUTCOME (record level) — the state of the whole question: see §6.5 and the coherence table (§4). WRITTEN BY THE USER; software validates coherence but never judges.
• FLEX / NOTE / MULTIMEDIA_LINK / IDENTIFIER — as on other records.
• CHANGE_DATE / CREATION_DATE — required on all GEDCOM-8 records.

Orphan proofs (cited by no link yet) are legal — reasoning-in-progress — but software SHOULD list them so none becomes a ghost.

2.1 Citing a PROOF from a link :=

n STICKY @<XREF:STICKY>@
  +1 PROOF @<XREF:PROOF>@                  {0:M}  g8:PROOF-LINK
    +2 OUTCOME <Enum>                      {0:1}  g8:OUTCOME

• PROOF (as a link substructure, inside the ROLES section of an INDI, the MEMBERS of a GROUP, or the HISTORY of an ASSET) — "the reasoning about this sticky's presence here." A link may cite a proof only if the linked sticky is among that proof's CANDIDATES — the proof may only be cited by those it judged. One identity-proof may legitimately be cited from several links (it judged several stickies); that is a feature.
• OUTCOME (at the link) — a COMPUTED ECHO of this sticky's candidate-OUTCOME inside the proof: written by exporters, discarded and recomputed by importers, never typed by a hand, and silent when the candidate inside carries no outcome. (Delta: was {1:1}; a mandatory echo would be forced to lie when its source is silent.)

The two doors: events in the subject's world — including post-mortem events such as probate, estate transfer, reburial — enter an INDI through ROLES. RESEARCH ACTS (searches, comparisons — things of the researcher's today) enter ONLY through the PROOF door: their stickies are never enrolled, and a search-sticky cited by no proof is flagged. Enrollment itself is human, hypothesis-capable and REVOCABLE: a researcher may enroll a sticky as "I believe this is the same man" and un-enroll it when a proof says otherwise. Conclusions move; evidence never does.

2.2 DISPUTEREF_STRUCTURE :=

[
n DISPUTEREF @<XREF:TEMPLATE>@             {1:1}  g8:DISPUTEREF-TEMPLATE
  +1 TAG <Special>                         {1:1}  g8:TAGPATH
  +1 <<NOTE_STRUCTURE>>                    {0:M}
|
n DISPUTEREF @<XREF:STICKY>@               {1:1}  g8:DISPUTEREF-STICKY
  +1 TAG <Special>                         {1:1}  g8:TAGPATH
  +1 <<NOTE_STRUCTURE>>                    {0:M}
|
n DISPUTEREF @<XREF:SPLAC>@                {1:1}  g8:DISPUTEREF-SPLAC
  +1 TAG <Special>                         {1:1}  g8:TAGPATH
  +1 <<NOTE_STRUCTURE>>                    {0:M}
]

The DISPUTEREF_STRUCTURE is a machine-readable reference to a DISPUTE. Because a dispute lives under a field and has no xref of its own, the reference names the RECORD that owns the field — one of the record types whose fields may carry disputes — and TAG names WHICH field, as a dotted path (see §7, TagPath). Software resolving the reference MUST verify that the named field exists and carries a DISPUTE.

• All three alternatives share the tag DISPUTEREF — the file stays searchable on one word; each alternative has its own URI; a future record type whose fields become disputable joins by adding an alternative, without grammar surgery elsewhere.
• Legal at PROOF level and under any ARGUMENT (both floors) — an individual argument may lean on a specific dispute.
• Each alternative may carry NOTE_STRUCTURE (commentary on the reference). Deliberately nothing more: the reference is a pointer, not a place where content lives.

2.3 The INDI summary — computed, never authored :=

n @XREF:INDI@ INDI                         a version-8 INDI (one that has ROLES/ASSETS)
  +1 NAME                            {0:1}  COMPUTED — the name projection (see below)
    +2 FORM <Text>                   {1:M}  COMPUTED — one per distinct evidenced form, preferred first
      +3 DATE <DateValue>            {0:M}  COMPUTED — the evidence dates of this form
    +2 PART <Text>                   {0:M}  COMPUTED — one per distinct evidenced part
      +3 TYPE <List:Enum>            {1:1}  COMPUTED
  +1 SEX <Enum>                      {0:1}  COMPUTED
  +1 BIRT                            {0:1}  COMPUTED — birth summary
    +2 DATE <DateValue>              {0:1}
    +2 SPLAC @<XREF:SPLAC>@          {0:1}
  +1 DEAT                            {0:1}  COMPUTED — death summary
    +2 DATE <DateValue>              {0:1}
    +2 SPLAC @<XREF:SPLAC>@          {0:1}
  +1 BAPM                            {0:1}  COMPUTED — ONLY when no BIRT is derivable
    +2 DATE <DateValue>              {0:1}
    +2 SPLAC @<XREF:SPLAC>@          {0:1}
  +1 BURI                            {0:1}  COMPUTED — ONLY when no DEAT is derivable
    +2 DATE <DateValue>              {0:1}
    +2 SPLAC @<XREF:SPLAC>@          {0:1}
  +1 PARTNER @<XREF:INDI>@           {0:M}  COMPUTED — one line per partner, any kind
    +2 KIND <Enum>                   {0:1}  vocabulary pending (§9)
    +2 DATE <DateValue>              {0:1}
  +1 OCCU <Text>                     {0:M}  COMPUTED — one per distinct evidenced occupation
    +2 DATE <DateValue>              {0:M}  COMPUTED — the evidence dates

A version-8 INDI is a binder: its facts live in the enrolled stickies. But the binder keeps an summary card — a small, fixed set of summary fields, COMPUTED by software from the enrolled stickies using the resolution order proof-SELECTED > CHOSEN > highest QUAY. This is the mirror law's fourth customer (after the sticky's DATE, the DISPUTED marker, and the link-site OUTCOME echo), and it obeys the same discipline: written by the exporting software, discarded and recomputed by importers, never authored by a hand.

Consequences, stated plainly:

• A GEDCOM-7 program reading a version-8 file sees a normal INDI whose dates, places, occupations and partner pointers read as plain values — and those values are guaranteed correct, because software computed them from the evidence instead of hoping someone remembered to update them. The NAME follows the approved version-8 name structure: its content lives one level lower, in the FORM lines, exactly as that structure defines for every version-8 record — readable by all software that implements it.
• The name projection. The card carries ONE computed NAME, built as a pure projection from the enrolled stickies: one FORM per distinct evidenced name form (deduplicated, each carrying the dates of its evidence; the preferred form first, chosen by the resolution order above, the rest chronological) and one PART per distinct evidenced name part. A researcher whose ancestor changed from Koster to Kosmis sees BOTH surnames on the card at first glance — and searches both archives. Computed card names carry no NOTE and no source citations: notes live in the stickies, citations as CITA in the template. And deliberately no payload echo: the version-8 name structure is payload-less by design, and the card does not fork that grammar.
• The file remains searchable and human-readable by name — all evidenced names, not just one — forever.
• OCCU — one computed line per distinct evidenced occupation, each with its dates, in chronological order. No picking, no ranking: the card never judges, it projects. (Other projections — RESI and friends — can be added by exactly the same recipe if the group wants them; the card stays deliberately small.)
• If foreign software edits a summary field and the file returns, the importer discards the summary as always — but the import report notices the difference: "INDI summary differed from recomputation — foreign edit preserved as a note." Nothing is silently lost; the truth never forks.
• The fallback anchors: for most pre-civil-registration research only doop and begraven exist. The card shows BIRT — or BAPM when no birth is derivable; DEAT — or BURI when no death is derivable. Never both of a pair: a baptism date must never masquerade as a birth date, and the full truth lives in the stickies.
• PARTNER — the searchable answer to "did this person have any kind of relation?": one computed line per partner, any relation kind (KIND — vocabulary parked in §9 until the committee's 7.1 work settles), with the comment carrying the human-readable name: 1 PARTNER @I0234@ /* Maria Jansen, married Sneek 1856 */. Deliberately a NEW tag: RELA exists in GEDCOM 7 under ASSO with authored semantics, and reusing it would collide (new semantics, new tag). A relation template involving more than two people simply yields one PARTNER line per partner from each INDI's view. And it cannot undermine the TEMPLATE: the template holds the truth; the PARTNER line is its computed, importer-discarded echo — the mirror law's fifth customer. (The pointer the old world lost with FAMS returns here — computed, so it can never break reciprocally again.)
• ALL other fact-tags are absent from a version-8 INDI — they live in the stickies. (AGE never appears: age is event-relative, never an index field.) When enrolled stickies disagree and no proof or dispute has ruled, software displays both values, flagged — the summary then carries the resolution order's best candidate.
• Dual-mode is untouched: an INDI without ROLES/ASSETS is a GEDCOM-7 INDI, authored as always.

2.3b The dual-INDI consequence — why computed summaries changed the whole proposal :=

The computed summary above unlocked the single largest simplification of the GEDCOM-8 proposal since its first draft (August 2025):

INDIVIDUAL_RECORD :=
[
n <<INDIVIDUAL_RECORD_7>>                  {1:1}   /* GEDCOM 7, byte-identical */
|
n <<INDIVIDUAL_RECORD_8>>                  {1:1}   /* the version-8 binder */
]

• There are now TWO individual records under the same INDI tag. The GEDCOM 7 INDI stays exactly as it always was — byte-identical to the official specification, nothing changed, nothing gated. The version-8 INDI is a new, separate, self-contained definition: a binder of evidence enrollments topped with the computed summary card (§2.3). The two are distinguished by their substructures — the sets are disjoint — never by the tag.
• Every GEDC.VERS gate construction disappears. The first draft had to thread version-conditionals through the individual record, the source and note structures, and four event-detail structures, to keep citations out of version-8 data. With two clean record definitions, all of those gates are deleted and replaced by ONE global law: inside a TEMPLATE, <<SOURCE_CITATION>> is not permitted — the TEMPLATE's CITA is the single home of source citation. Nine gates die; one sentence lives.
• Older software simply keeps reading. A pre-8 program reading a version-8 INDI sees an ordinary, lean GEDCOM 7 person — name, sex, birth, death, partners — whose values are guaranteed current because software computed them from the evidence. Unknown tags are skipped, as GEDCOM has always allowed; nothing corrupts, nothing is lost.

The compatibility story in one sentence

The version-8 model did not get more complex to coexist with
GEDCOM 7 — it got MUCH simpler, because computed summaries made
the original clumsy constructions unnecessary.

2.4 Short example — a proof and the link that cites it

➡️➡️ Click to open the example ⬅️⬅️

0 @I0723@ INDI                   /* the person, conclusion layer */
1 ROLES
2 STICKY @ST2301@                /* burial of Jan ...sen, Workum 1723 */
2 STICKY @ST2320@                /* HYPOTHESIS: Jan Willemsen, 1721 membership register */
3 PROOF @P0302@                  /* the reasoning testing that hypothesis */
4 OUTCOME STRONG                 /* computed echo of @ST2320@'s outcome below */

0 @P0302@ PROOF
1 TYPE IDENTIFIER
1 QUESTION Did Jan Willemsen (membership register Workum 1721, sticky @ST2320@) die in Workum — is he the man buried 3 MAR 1723, sticky @ST2301@?
1 DISPUTEREF @ST2301@            /* this question touches the torn-name dispute... */
2 TAG NAME.PART                  /* ...on that record's name part */
1 SUBM @B001@
1 DATE 1 JUL 2026
1 CANDIDATES
2 STICKY @ST2320@                /* the hypothesis under test */
3 ARGUMENT A member listed in 1721 who disappears from later lists fits a 1723 death.
4 SUBM @B001@
3 OUTCOME STRONG
2 STICKY @ST2301@                /* the burial itself */
3 ARGUMENT Age at burial ("about 70") fits the 1721 member's generation.
4 SUBM @B001@
3 OUTCOME STRONG
2 STICKY @ST2310@                /* NEGATIVE EVIDENCE: searched the complete register 1712-1740 — no other Jan *sen burial */
3 ARGUMENT The field of possible identities is closed.
4 SUBM @B001@
3 OUTCOME STRONG
1 OUTCOME STRONG                 /* a leaning, not a settlement: no TOPSTICKY */
1 CHAN 08 JUL 2026
1 CREA 07 JUL 2026

---

---

The laws and design principles this grammar obeys are in the previous post — one set, one numbering; the tables below refer to them by number.

4. THE COHERENCE TABLES (validator-enforced)

DISPUTE — the crown matrix. Read a candidate's row, then the column for the dispute's current STATUS. Any combination not shown as allowed is a structural violation.

Candidate's VERDICT ↓	when STATUS is RESOLVED (settled)	when STATUS is OPEN / DORMANT (active / parked)
ACCEPTED	✅ the final crown 👑 — exactly one; the field's payload equals it	❌ forbidden — no final crown while the fight is open
CHOSEN	❌ forbidden — no provisional pick in a settled fight	✅ the provisional crown 🥈 — at most one; the field's payload equals it
REJECTED	✅ allowed, multiples — out; its arguments remain, attributed, forever	✅ allowed, multiples — ruled out while the dispute lives on
(no VERDICT)	✅ allowed, multiples — still on the table, judged by no one	✅ allowed, multiples — still on the table, judged by no one

The two crowns are mirrors and can never cross: a 👑 in the file forces RESOLVED; a 🥈 forces OPEN or DORMANT. Whoever wears the crown dictates what older software reads in the field.

PROOF — the record-level OUTCOME requires:

record OUTCOME	validator requirement
SELECTED	✅ exactly ONE candidate SELECTED, and TOPSTICKY points at it 👑
DEBATED	at least two candidates with substantive arguments on opposing sides; ❌ no SELECTED; ❌ no TOPSTICKY
UNDECIDED	❌ no candidate SELECTED; ❌ no TOPSTICKY
STRONG / WEAK	interim leanings; ❌ no TOPSTICKY without SELECTED
(absent)	reasoning in progress — absence carries meaning
OTHER	PHRASE mandatory

Deliberate asymmetry: upstairs there is NO provisional crown. On the evidence floor the disputed field must always hold a value, so an open fight needs a "best for now"; on the conclusion floor nothing breaks when a question honestly stays open — so nothing is crowned until it is SELECTED (see TOPSTICKY).

---

---

5. WHO WRITES WHAT (summary)

Item	Written by
candidates, arguments, QUAY, opinion dates	the USER (or transcribed research)
VERDICT + its SUBM/DATE	the USER — software may detect ties and prompt, never judges
the disputed field's payload	the USER, via the normal correction routine when a verdict lands
DISPUTED markers	SOFTWARE at export; importers discard & recompute
proof QUESTION, arguments, OUTCOMEs, TOPSTICKY	the USER
link-site OUTCOME echo	SOFTWARE at export; importers discard & recompute
v8 INDI summary (NAME/SEX/BIRT/DEAT)	SOFTWARE at export; importers discard & recompute; foreign edits reported
reverse-BASIS views, TODO harvests, ghost lists	SOFTWARE, computed on demand

---

6. ENUMERATION SETS (complete)

6.1 g8:enumset-DISPUTE-STATUS

➡️➡️ Click to open this enumeration set ⬅️⬅️

Value	Meaning
OPEN	actively argued; the payload may change. Default when STATUS is absent.
RESOLVED	settled: exactly one ACCEPTED candidate equals the payload; the whole argument history remains.
DORMANT	contested but undecidable with the evidence available (the page is torn, the register is lost); parked until new evidence surfaces, and kept out of open-dispute work-lists so those show only what a researcher can act on.

6.2 g8:enumset-DISPUTE-TYPE

➡️➡️ Click to open this enumeration set ⬅️⬅️

Value	Meaning
TRANSCRIPTION	what does the ink say? (damage, handwriting, spelling)
INTERPRETATION	what does the undisputed ink MEAN? (calendar, year-style, units)
IDENTIFICATION	which real-world entity do the words point to? (which Oudega?)
CLASSIFICATION	which category or enum value does the evidence imply? (BIRTH or ADOPTED?)
DERIVATION	is the computation from stated evidence correct? ("aged 22" → born when?)
TRANSLATION	the glyphs are agreed; the translations differ (Latin entries, old hands)
OTHER	any other kind of doubt — PHRASE required

6.3 g8:enumset-DISPUTE-VERDICT

➡️➡️ Click to open this enumeration set ⬅️⬅️

Value	Meaning
ACCEPTED	the final winner; only in a RESOLVED dispute; the field's payload equals this candidate.
CHOSEN	the provisional "best for now", picked by a human when evidence is tied; only while OPEN or DORMANT; promises nothing about the outcome.
REJECTED	out — its arguments remain, attributed, forever; a candidate can be rejected while the dispute lives on.

(absence of VERDICT = still on the table, judged by no one.)

6.4 g8:enumset-PROOFTYPE

➡️➡️ Click to open this enumeration set ⬅️⬅️

Value	The question decided
BIRTHDATE	when was the person born?
BIRTHPLACE	where was the person born?
CHILDREN	who were the person's children?
DEATHDATE	when did the person die?
DEATHPLACE	where did the person die?
GENDER	what was the person's sex/gender as recorded?
IDENTIFIER	are these records about the SAME person/entity?
IMMIGRATION	did/when did the person migrate?
MARRIAGE	which marriage belongs to this person?
MARRIAGEDATE	when did the marriage take place?
NAME	what was the person's name?
OCCUPATION	what was the person's occupation?
PARENTS	who were the person's parents?
RELIGION	what was the person's religion?
RESIDENCE	where did the person live (when)?
OTHER	any other question — PHRASE required

6.5 g8:enumset-OUTCOME

➡️➡️ Click to open this enumeration set ⬅️⬅️

Value	Meaning
DEBATED	both sides carry real arguments; nobody has won.
SELECTED	this candidate/conclusion is the accepted one.
STRONG	supported, leaning positive; not settled.
UNDECIDED	genuinely open.
WEAK	considered and outweighed; preserved with its reasons.
OTHER	anything else — PHRASE required.

---

---

7. DATATYPE — TagPath (for DISPUTEREF.TAG)

A dotted path of standard tags naming ONE field of the referenced record, outermost first:

TagPath = Tag *("." Tag)
Tag     = stdTag        ; as defined by the base specification

Examples: DATE (the record's own date) · BIRT.SPLAC (the place of the birth event) · NAME.PART (a part of the name). Software resolving a TagPath MUST verify the named field exists and carries a DISPUTE.

---

Aligned with GEDCOM8-SPEC-DISPUTE-PROOF v1.0.10012.