# NAME-COMPARISON-1 — v2 Word Of Clout, LLC · published under the one-ballot one-push publish (Tani ruling 2026-09-21T15:21Z msg 30772) · supersedes the v1 text formerly at this stable path · stable path: /laws/name-comparison-v1.md · sha256 (this file's bytes): see the parity receipt — LAW-SHA256 quoted there. **LAW-IS-GENERAL-1 (Tani 2026-09-21T06:31Z msg 30758):** a law states rules, never instances. The v1 text's inline example vectors are REMOVED from the law and live in the parity runner, which executes the law's stated steps and the veto implementation on the same vectors — one interpretation or fail. This v2 also states the rule set COMPLETELY: the v1 text stated the token comparison but omitted three declared compatibility steps the implementation has always carried and one side-asymmetry the implementation needs (the board side publishes a full name; the federal side publishes first/last fields). Those steps are now stated as law, so the law and the code are one interpretation. ## The Rule **A name pair whose first and last given-name tokens agree after the stated normalization steps is a formatting difference, not a conflict.** When the two published authorities disagree on a practitioner name, the disagreement is classified by THIS rule into exactly two classes: - **Substantive disagreement:** the first or last given-name token differs. This is a real discrepancy — the record must mark it CONTESTED and the finding cites the specific tokens. - **Formatting/alias difference:** the first and last given-name tokens agree after normalization. This is NOT a disagreement — it is a superficial formatting, credential, or presentation difference between the two authorities, and the licence-to-record association proceeds without a name-disagreement finding. ## Input shapes The two authorities publish names in different shapes, and the rule reads each side in its own shape: - **Board side:** one full-name string (a single published name). - **Federal side:** two fields, first name and last name. An EMPTY first name never agrees — a surname alone is never asserted as a name match. ## Normalization steps (in order, both sides) 1. **Case-fold** to uppercase (US-ASCII); trim; collapse whitespace. 2. **Strip punctuation:** periods, commas, single quotes, hyphens, and double quotation marks (straight and smart quotes). 3. **Drop title prefixes (board side, first token only):** a fixed list — DR, MR, MRS, MS, PROF — applied to the first token of the board full name only (the federal side has no title-prefix field). 4. **Drop ONE balanced parenthetical on EITHER side:** the first `(...)` substring with balanced parentheses is removed and the surrounding text rejoined. ONE, not all — a parenthetical alias is registry formatting, not a second disagreement; two parentheticals on one side are not two aliases. 5. **Drop generational suffixes and credential/legal-form tokens, both sides:** JR, SR, II, III, IV, DDS, DMD, MD, PC, INC, LLC, PLC, PA. 6. **Tokenize** the remaining string on whitespace into a token array. ## Comparison After the steps, the board name yields a token array; the federal side yields a first-name token array and a last-name token array. - **Surname:** compatible when the board's final token equals the single federal last-name token; OR, for a multi-token federal last name (compound surname), when the board's final token equals the federal last name's FINAL token and every remaining federal last-name token appears among the board's given tokens — the two authorities tokenize compound surnames differently, and that tokenization difference is formatting, not a disagreement. - **Given names:** compatible when EVERY federal first-name token matches a board given token, by exact equality OR by single-letter initial compatibility: a one-letter token on either side matches the other side's token that starts with that letter. Middle tokens and initials are formatting, never partial credit. - The pair is a **formatting difference** when surname and given names are both compatible; **substantive disagreement** otherwise. **R13-N6, resolved: this law compares STRUCTURED COMPONENTS.** The federal side's first-name and last-name fields each compare against the board's token array as components — not a flat first-and-last-token algorithm, whose limit is named here: a flat first/last-token comparison cannot see a differing middle given token, so two published readings that share their first and last tokens but differ in a middle given token would wrongly pass as formatting; under this law such a pair is a substantive disagreement (the differing token is a first-name component on the structured federal side). ## Named limit classes ### Organization-record licences The federal authority publishes some licences at the organization level (entity type 2 / organization). When an organization-level federal record disagrees on the practitioner name with the board record, the finding is ADJUDICATED as a name-disagreement but annotated with the limit: ORG_RECORD_LICENSE. This is a named limit of the federal source, not a gap in the audit's reading. ### Compound given names A multi-token first name is preserved as its full form; the rule compares the full token arrays as stated above — it does NOT split a token position on internal whitespace beyond the stated tokenization, and it does NOT require the two authorities to segment a compound given name the same way. ## Version history **v1 → v2 disclosure (a disclosure, not a quiet upgrade):** v1, as published at this stable path, stated a flat first-and-last-token comparison. The implementation that computed the prior epoch's published name-disagreement findings also carried three compatibility rules the published v1 law did not state — the board-side title-prefix drop, the single-letter initial compatibility, and the compound-surname tokenization compatibility — together with the field-wise (structured) reading of the federal first/last fields. The prior epoch's finding set was therefore computed under rules the published law did not state. v2 states them as law, so law and code are one interpretation. The gap is disclosed, not silently closed: the parity runner red-proves it — v1's stated steps alone, run on the same committed input artifacts the prior epoch cites, produce a DIFFERENT finding set (the count is reported in the run receipt) — while the prior epoch's signed findings stand as the run that produced them (the receipt is the run; no signed byte is re-graded, and the finding set published by the signed epoch is the one the record carries). ## The limit, stated plainly This law determines whether two published name readings are DIFFERENT (and therefore CONTESTED) or FORMATTING-EQUIVALENT (and therefore not a finding). It does NOT determine which reading is "correct", which authority is more reliable, or what a person's "real" name is. It is a classification rule for the published crosswalk — the audit states the disagreement, names the specific tokens, and leaves the reader to weigh the finding. The classification is re-derivable: any party applying the stated steps to the same normalized readings (published in the signed epoch record) reaches the same classification. The parity runner executes the law's stated steps and the veto implementation (kernel/name_veto.ts — the F2 veto: agreement beyond normalization permits the identifier-equal assertion; disagreement BLOCKS it and emits the finding evidence) on the SAME vectors — one interpretation or fail. The live-row leg of that proof runs against the epoch's published name-disagreement rows row-for-row. ## Parity NAME-VETO-PARITY-1: the law's stated steps and the veto implementation produce ONE interpretation on every vector — the formatting-only classes (suffix-only, credential-only, title-prefix, parenthetical-alias, compound-surname, single-letter-initial, multi-token given name) and the substantive classes (different first token, different last token). The law text carries no vectors (LAW-IS-GENERAL-1); the vectors live in the parity runner. Parity runner: `node lib/records/r14-3-name-comparison-v2-parity.test.mjs` — exit code quoted in the commit receipt. The live-row parity gate (scripts/crosswalk-name-veto-law-parity.test.mjs, 42-row row-for-row proof) continues to run unchanged.