Rationale
mechanisms.md#LEDGER-RULE-SEPARATION's original contract said ledger rules are separated by fields subsets and matching predicates, never by file order. Review of the rules documentation (PR #381) falsified that against the live 1.4 ledger, and the corrected contract now admits the within-tier case — but admitting it and being happy with it are different things, and nothing tracks the question.
Current state
fix(cjk-comma-honorific-peel)'s fields {given, suffix} are a strict subset of fix(cjk-comma-compound)'s {family, given, middle, suffix, title}. Both carry a name_regex, so they share a tier, and both admit a {given, suffix} diff on 김, 민준씨 — file order alone decides which rule is classifier-of-record. The ledger comment concedes this in as many words: "Written above it anyway, so the narrower rule is also the earlier one and the tie never has to be reasoned about."
Measurement (from #375)
Moving the peel rule after the compound rule is a pure reorder — no regex change, no fields change — and it reattributes 7 names. _CROSS_RULE_WINNERS fails; nothing else in 3218 tests notices. So the current separation is real but held up by exactly one pin at exactly the right granularity.
Options
- Give the peel rule a predicate the compound rule fails (narrow its
name_regex to the honorific-bearing shapes). Intended effect: the pair becomes order-independent and the original contract holds again. Cost: the regex hand-copies more vocabulary, growing the sync-roster surface (_HONORIFIC_SOURCES).
- Accept the within-tier convention (narrower rule written first,
_CROSS_RULE_WINNERS as the enforcement). Intended effect: no ledger change; the corrected contract in mechanisms.md#LEDGER-RULE-SEPARATION is already worded for this. Cost: file order stays load-bearing in one place, and every future same-tier overlap inherits the convention silently.
- Mechanical check: same-tier fields-subset pairs must be ordered narrow-first, enforced in
validate_rules. Intended effect: option 2's convention becomes unrepresentable-wrong instead of documented. Cost: a new validator with its own edge cases (what counts as "narrower" when fields are disjoint-but-overlapping).
Open
Whether _CROSS_RULE_WINNERS alone is sufficient enforcement is the crux: it pins today's winners, but a new same-tier overlapping rule added tomorrow gets no narrow-first check until someone hand-adds its contested names to the roster.
Rationale
mechanisms.md#LEDGER-RULE-SEPARATION's original contract said ledger rules are separated by fields subsets and matching predicates, never by file order. Review of the rules documentation (PR #381) falsified that against the live 1.4 ledger, and the corrected contract now admits the within-tier case — but admitting it and being happy with it are different things, and nothing tracks the question.Current state
fix(cjk-comma-honorific-peel)'s fields{given, suffix}are a strict subset offix(cjk-comma-compound)'s{family, given, middle, suffix, title}. Both carry aname_regex, so they share a tier, and both admit a{given, suffix}diff on김, 민준씨— file order alone decides which rule is classifier-of-record. The ledger comment concedes this in as many words: "Written above it anyway, so the narrower rule is also the earlier one and the tie never has to be reasoned about."Measurement (from #375)
Moving the peel rule after the compound rule is a pure reorder — no regex change, no fields change — and it reattributes 7 names.
_CROSS_RULE_WINNERSfails; nothing else in 3218 tests notices. So the current separation is real but held up by exactly one pin at exactly the right granularity.Options
name_regexto the honorific-bearing shapes). Intended effect: the pair becomes order-independent and the original contract holds again. Cost: the regex hand-copies more vocabulary, growing the sync-roster surface (_HONORIFIC_SOURCES)._CROSS_RULE_WINNERSas the enforcement). Intended effect: no ledger change; the corrected contract inmechanisms.md#LEDGER-RULE-SEPARATIONis already worded for this. Cost: file order stays load-bearing in one place, and every future same-tier overlap inherits the convention silently.validate_rules. Intended effect: option 2's convention becomes unrepresentable-wrong instead of documented. Cost: a new validator with its own edge cases (what counts as "narrower" when fields are disjoint-but-overlapping).Open
Whether
_CROSS_RULE_WINNERSalone is sufficient enforcement is the crux: it pins today's winners, but a new same-tier overlapping rule added tomorrow gets no narrow-first check until someone hand-adds its contested names to the roster.