Repository navigation
A particle chain lands in the given or middle name under the family-first orders #368
Description
Activity
Framing refined on #367 and it applies here too: the defect is that a particle chain — a multi-word surname assembled by
Lexicon.particles— is being placed as though it were an ordinary single name. On #367 a given-name title treats the chain as "the single name after me"; hereassignhands it whatever positionname_ordergives that piece. Same category error, two different rules making it.- added a commit that references this issue
on Aug 16, 2026 Reversed by the order-precedence keystone in #386 — shipped behavior is correct.
The recorded decision here ("the particle wins: a chain becomes the family name, whatever order was declared") was made before the grouping/assignment split was stated, and it doesn't survive it. Grouping is vocabulary's job and is order-independent; assignment is
name_order's job.Juan de la Vegagroups[Juan][de la Vega], and underFAMILY_FIRSTthe first group is the family — sofamily='Juan',given='de la Vega'is the declared order being honored, not a defect.What
NON_GIVEN_NAME_PARTICLESguarantees is that the bare word never reads as a given name — not that no name part may begin with one.The asymmetry with the leading case (
rules.md#P1, where the fold does override the declared order) is P4's and predates this: a leading particle chains nothing, so without the fold pure position makes the bare particle the given name. Measurable today on the ambiguous half, where no fold fires —van Mesnil Juan→given='van',middle='Mesnil',family='Juan'.given='de'is exactly the reading the vocabulary exists to forbid.The
deviates: #368marker is removed fromrules.md#P1in #386. Full reasoning:decisions.md#P1, 2026-08-16 entries.- added a commit that references this issue
on Aug 22, 2026
A particle chain is a surname by construction —
Lexicon.particleschains onto the following piece to build a family name. Under the family-first orders the chain is handed whatever positionname_orderassigns, so it can land ingivenor inmiddle:FAMILY_FIRST_GIVEN_LASTbehaves asFAMILY_FIRSTdoes. The grouping is identical in every case —[Juan][de la Vega]— so the chain is built the same way and only its placement differs.Decision
The particle wins: a chain becomes the family name, whatever order was declared. Particles do not join given names; only titles join to given names.
Mechanism
The chain is built in the grouping stage, before roles exist.
assignthen hands positions out by_effective_order, and nothing consults the fact that a piece is a particle chain — so under family-first the trailing piece is the given position and the chain goes there.Scope and verification
Family-first only. The default-order corpus is untouched, so
tools/differentialshould come back with 0 diffs at all three baselines, the same clean result as #361 — that is the property to verify, not a ledger entry.Related
Dr. Van Johnsonreads as one surname #367 is the same principle violated through given-name titles instead of throughname_order(Sir de Mesnil→given='de Mesnil', no surname). That half does move the default-order corpus and needs ledger entries, which is why the two are split.de Mesnil Juanbe all surname, or familyde Mesnilplus givenJuan? #364 andMesnil Garcia destrands the particle under FAMILY_FIRST but folds it under FAMILY_FIRST_GIVEN_LAST #365 are not consequences of this:de Mesnil JuanandMesnil Garcia dehave no chain at all, because a leading particle deliberately never chains and a trailing one has nothing to chain onto.Juan de la Vega→given='de la Vega'underFAMILY_FIRST"working as intended". Keep a never-given particle attached under any name_order (#359) #361's code comments describe that row as what the fold's guard mechanically tests rather than as a blessed output, so they stay true either way.