What should Parser.suggest do with a list mixing -ovich and oʻgʻli patronymics, or a family-first list of them? (Karimov Rustam Anvarovich beside Aliyev Farrukh is forced given-first) #1356

Two limits of the group suggester's patronymic decision, both recorded in decisions/group-suggestion's 2026-11-10 TURKIC entry as "left open" and listed on that file's Open: line as items of the closed tracking issue #1308 with "no issue yet". That Open: line should be given this issue's link.

1. One patronymic decision for a mixed list. Where a list holds Russified -ovich/-ovna patronymics and Turkic marker patronymics (oʻgʻli, qizi), the larger set wins, and the other names are read by a rule that does not know them. Kazakh -uly patronymics are no signal at all.
2. A decided East Slavic rule forces GIVEN_FIRST. rules/O1's rotation needs a given-first order, so the suggestion sets it, on a family-first base too. On a list written family first, the names with a patronymic are then rotated right, and the names without one (two words) are read family-last.

Measured on master 670b349, 2026-11-12, composed names:

names = ["Karimov Rustam Anvarovich", "Yusupova Dilnoza Bahodirovna", "Rahimov Sardor Ilhomovich",
         "Nazarova Gulnora Shavkatovna", "Ismoilov Botir Erkinovich", "Hamidov Otabek Rashidovich",
         "Sobirova Nodira Tohirovna", "Ergashev Aziz Komilovich", "Qodirov Bekzod Zafarovich",
         "Tursunov Jasur Olim o‘g‘li", "Aliyev Farrukh"]
Parser(policy=Policy(name_order=FAMILY_FIRST)).suggest(names)
  name_order  GIVEN_FIRST  no evidence
      the East Slavic rule reorders each name; it needs a given-first order
  patronymic_rules  east-slavic  9 for, 1 against, 1 no evidence
  disagreeing (1): Tursunov Jasur Olim o‘g‘li

The same list under the default base gets the same patch less the order (it is given-first already), and the same two names wrong. With fewer -ovich names the list decides nothing: five -ovich, two Turkic and one two-word name give "0 for, 7 against", both rules unchanged. A Kazakh-style list (five -ovich/-ovna, two -uly, one two-word name) on a family-first base decides East Slavic and GIVEN_FIRST, and reads the two -uly names and the two-word name family-last.

How often: uv run python tools/differential/suggest_measure.py (2026-11-12), its TURKIC table over the opensanctions-parliaments cache, family right of the scored names. The cache on this machine is the 2026-11-08 fetch of 17 datasets; the tool reads its raw.jsonl directly, and the two senate lists are in it.

Both lists are suggested GIVEN_FIRST with east-slavic under either base, with no order vote at all (0/0/0/48, 0/0/0/59). So a caller who had already declared FAMILY_FIRST, which reads every name of both lists right, is moved to a setting that reads 7 of each wrong. ua_rada (1,589 names, Cyrillic, written family first) is decided the same way.

The rows are scored against each list's own convention (the end the list writes the family at, read by eye off its first twelve names), not against a per-name truth, as the TURKIC entry says.

Options, for the forced order:

• (A) Never move a declared family-first base to given-first for the rule's sake.
  • When: the East Slavic rule is decided and the base's order is family-first.
  • Then: the suggestion leaves the order and the rule alone, and says why in its note.
  • Because: FAMILY_FIRST alone already reads a family-first patronymic list right (48/48, 59/59); the rule adds the patronymic view at the cost of the names that have none.
  • Accepted: the patronymic stays in middle for those lists.
• (B) Decide the order from the patronymic's position. A patronymic ending the name in most voters says the list is written family first (Karimov Rustam Anvarovich) or given first with the family last absent; one in the middle (Rustam Anvarovich Karimov) says given-first. The rule and the order would then be suggested together only where they agree. This needs rules/O1 to read under a family-first order, which it does not today.
• (C) Leave it and document it: the suggestion's disagreeing list already names the two-word names in one of the two cases.

Options, for the mixed list:

• (D) Suggest both rules where each has votes and neither set contradicts the other's reading ({EAST_SLAVIC, TURKIC} reads uz_senate 54/59 against 52/59).
• (E) Add the -uly/-kyzy endings as a Turkic signal. That is a vocabulary and rules/O2 question first; the suggester should not read what the pipeline's rule does not (AGENTS.md, the suggester paragraph).
• (F) Leave it: the larger set wins, as recorded.

Open:

1. (A), (B) or (C) for the order? (A) is the smallest change and repairs both senate lists under a family-first base.
2. Under the default base the same lists read 0/48 and 0/59 before and 41/48 and 52/59 after, so the forced order is a gain there. Is the remaining loss (the two-word names) acceptable, or should those lists be suggested FAMILY_FIRST without the rule?
3. (D) and (E): worth a measurement, or out of scope until a caller asks?
4. The opensanctions-parliaments cache should be re-fetched before these rows are quoted in the decisions file again; the tool now lists 23 datasets.

🤖 Generated with Claude Code