A particle chain lands in the given or middle name under the family-first orders

[derek73]

A particle chain is a surname by construction — Lexicon.particles chains onto the following piece to build a family name. Under the family-first orders the chain is handed whatever position name_order assigns, so it can land in given or in middle:

                     default                        FAMILY_FIRST
Juan de la Vega      family='de la Vega'            given='de la Vega'
Juan Q. de la Vega   middle='Q.', family='de la Vega'   middle='de la Vega'

FAMILY_FIRST_GIVEN_LAST behaves as FAMILY_FIRST does. 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. assign then 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/differential should 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

• A title displaces a particle out of leading position, so Dr. Van Johnson reads as one surname #367 is the same principle violated through given-name titles instead of through name_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.
• Should de Mesnil Juan be all surname, or family de Mesnil plus given Juan? #364 and Mesnil Garcia de strands the particle under FAMILY_FIRST but folds it under FAMILY_FIRST_GIVEN_LAST #365 are not consequences of this: de Mesnil Juan and Mesnil Garcia de have no chain at all, because a leading particle deliberately never chains and a trailing one has nothing to chain onto.
• Supersedes the sentence in particles_ambiguous has no effect on the parse under name_order=FAMILY_FIRST #359 that called Juan de la Vega → given='de la Vega' under FAMILY_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.

[derek73]

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"; here assign hands it whatever position name_order gives that piece. Same category error, two different rules making it.

[derek73]

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 Vega groups [Juan][de la Vega], and under FAMILY_FIRST the first group is the family — so family='Juan', given='de la Vega' is the declared order being honored, not a defect.

What NON_GIVEN_NAME_PARTICLES guarantees 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: #368 marker is removed from rules.md#P1 in #386. Full reasoning: decisions.md#P1, 2026-08-16 entries.