rules.md#A1 says a genuinely uncertain reading completes on the best branch and reports the doubt:
where the text's structure or a word's reading is genuinely uncertain, the parse completes on the best reading and carries an ambiguity report naming the doubt
P6's tussenvoegsel attachment (#379) creates exactly such a fork and reports nothing:
Van Johnson ambiguities=('particle-or-given',) "leading 'Van' may be a family-name particle"
Nguyen, Thi Van ambiguities=() family='Van Nguyen' -- same word, same fork
Berg, Jan vd ambiguities=() family='vd Berg', taken from suffix
rules.md#P6 now documents the uncertainty in its own Accepted: block — the ASCII spelling of a Vietnamese name is the same string as the Dutch listing — so the rule asserts the condition A1 attaches a report to, and no report is emitted.
Why it is not emitted today
nameparser/_pipeline/_assign.py:326 records a deliberate scoping:
PARTICLE_OR_GIVEN is deliberately not emitted here: after a comma the family is already fixed, so a leading given-position particle is not meaningfully ambiguous.
That reasoning was sound when written and does not cover the new fork. The comma fixes which piece is the family; it says nothing about whether the trailing particle belongs to it. P6 decides that separately, and it is genuinely uncertain.
What it would take
The fork is decided in post_rules, which today owns only {tokens} in the stage-ownership map (tests/v2/pipeline/test_state.py). Emitting from there means adding ambiguities to its ownership — consistent with the map's own stated principle, since ambiguities are "recorded by every stage that DECIDES one … a fork whose branches are taken in different stages needs an emitter in each", which is why group and assign both emit PARTICLE_OR_GIVEN already.
Scope note: only the ambiguous half of the vocabulary is a fork. A never-given particle (de, der) cannot be a name, so "Jong, Piet de" is not uncertain and should stay silent. The words that would report are the ambiguous particles and the three dual-vocabulary words (vd, mc, do).
Why it matters
A caller processing mixed Dutch and Vietnamese listings currently has no programmatic tell that family="Van Nguyen" was a coin flip. That is the one thing the ambiguity surface exists to provide, and it is the only mitigation available for a collision the parser genuinely cannot resolve — the diacritic separates the two readings when it is present ("Nguyễn, Thị Vân" parses correctly), but the ASCII transliteration is the same string in both traditions.
Found by review of #403.
rules.md#A1says a genuinely uncertain reading completes on the best branch and reports the doubt:P6's tussenvoegsel attachment (#379) creates exactly such a fork and reports nothing:
rules.md#P6now documents the uncertainty in its ownAccepted:block — the ASCII spelling of a Vietnamese name is the same string as the Dutch listing — so the rule asserts the condition A1 attaches a report to, and no report is emitted.Why it is not emitted today
nameparser/_pipeline/_assign.py:326records a deliberate scoping:That reasoning was sound when written and does not cover the new fork. The comma fixes which piece is the family; it says nothing about whether the trailing particle belongs to it. P6 decides that separately, and it is genuinely uncertain.
What it would take
The fork is decided in
post_rules, which today owns only{tokens}in the stage-ownership map (tests/v2/pipeline/test_state.py). Emitting from there means addingambiguitiesto its ownership — consistent with the map's own stated principle, since ambiguities are "recorded by every stage that DECIDES one … a fork whose branches are taken in different stages needs an emitter in each", which is whygroupandassignboth emitPARTICLE_OR_GIVENalready.Scope note: only the ambiguous half of the vocabulary is a fork. A never-given particle (
de,der) cannot be a name, so"Jong, Piet de"is not uncertain and should stay silent. The words that would report are the ambiguous particles and the three dual-vocabulary words (vd,mc,do).Why it matters
A caller processing mixed Dutch and Vietnamese listings currently has no programmatic tell that
family="Van Nguyen"was a coin flip. That is the one thing the ambiguity surface exists to provide, and it is the only mitigation available for a collision the parser genuinely cannot resolve — the diacritic separates the two readings when it is present ("Nguyễn, Thị Vân"parses correctly), but the ASCII transliteration is the same string in both traditions.Found by review of #403.