Man with same name as US Sen. Dan Sullivan is eligible for Alaska's primary ballot, judge rules - AP News

When two people share the same name, algorithms don't know who to trust - and that's exactly why Alaska's ballot battle matters for every system that relies on identity.

In June 2024, a U. S judge ruled that a man named Dan Sullivan - who shares the exact name as the incumbent Republican U. S. Senator from Alaska, Dan Sullivan - is eligible to appear on the state's primary ballot. The decision reverses an earlier state-level ruling that had disqualified the candidate on the grounds that his name would cause "voter confusion. " The challenger, a Democrat also named Dan Sullivan, argued that his name is his legal identity, not a political trick. The case has been covered widely by outlets including AP News, The Washington Post, The New York Times.

While the story appears to be purely a political oddity, it raises a deeply technical question that software engineers, data architects, and platform builders confront daily: How do you disambiguate people when the only identifier you have is a name that collides? This is the same collision problem that plagues everything from database primary keys to social media verification to healthcare record linkage. The Sullivan-Sullivan case is, in essence, a production-bug report from the real world, and we should treat it as such.

Why Name Collisions Are a Pervasive Engineering Problem

In computer science, a collision occurs when two distinct inputs produce the same output in a hash function. In identity systems, the "hash function" is often a simple one-to-one mapping from legal name to voter record. When two people share the same full name, the system experiences a logical collision: the same key now points to two different entities. This isn't a bug - it's a fundamental limitation of names as identifiers.

Most databases mitigate collisions through unique identifiers (UUIDs, voter IDs, Social Security numbers). But the election system in Alaska, like many state-level systems, initially relied heavily on name matching. The Alaska Division of Elections used an algorithm that flagged the candidate Dan Sullivan as potentially fraudulent, arguing that the similarity with the incumbent's name could "confuse" voters. This algorithmic decision was overturned by a human judge, exposing the gap between machine heuristics and legal reality.

From an engineering standpoint, the moral is clear: if you're building a system where identity matters, names aren't enough. The workaround - adding suffixes (Sullivan, Dan Sr.; Sullivan, Dan Jr. ) - is fragile and culturally biased. In the wild, you face John Smith, María García. And the thousands of other names that appear hundreds of times in any moderately sized dataset. The Sullivan case is just one high-profile example of a pattern that repeats in every CRM, every voting roll. And every social platform.

How Election Systems Are Still Using Flawed Name-Matching Algorithms

Election databases are often built on legacy infrastructure. Many states use voter registration systems designed in the 1990s or early 2000s, with name-matching algorithms that rely on exact string comparison or at most on Soundex-style phonetic encoding. And soundex, invented in 1918 for the US. Census, maps names to a four-character code based on consonants. It works tolerably for Anglo-Saxon names but breaks down for many other languages.

Alaska's election division appears to have used a combination of exact match and a "substantially similar" rule. When the challenger Dan Sullivan filed, the system detected that his name was identical to the senator's. The algorithm then applied a rule: "same name + same state + same office" equals high risk of confusion. But that rule did not account for the real-world fact that two different people can legally have the same name. The algorithm lacked a proper entity resolution step - no cross-referencing of addresses, dates of birth, or party affiliations.

Compare this to modern identity resolution systems used by financial institutions. These systems use multi-attribute fuzzy matching: name + DOB + address + phone number + government ID. They compute a probabilistic score and flag only near-duplicates that exceed a threshold. Alaska's system, by contrast, appears to have used a rudimentary deterministic rule. Which the judge correctly identified as overly broad.

Four Lessons for Software Developers from the Sullivan-Sullivan Case

This case offers concrete takeaways for engineers who design identity systems, especially those in regulated or high-stakes environments.

• Never use names as primary keys, Always assign a system-generated unique identifierHuman-readable names should be attributes, not keys. The moment you build a unique index on a name column, you have created a time bomb.
• add fuzzy matching with context. When resolving identities, aggregate multiple signals: geographic, demographic, temporal. An exact name match should only trigger a review if there's low entropy in other dimensions.
• Build a human-in-the-loop review process for algorithmic decisions, The Alaska judge overruled the machineThat should be a design pattern, not an exception. Every automated decision that can disenfranchise a citizen should be appealable with a clear path.
• Audit trail and explainability matter. Why did the algorithm flag Dan Sullivan? The system likely couldn't explain its reasoning in a way a court could evaluate. Engineers must ensure that identity systems produce interpretable outputs, especially when used in government.

These lessons aren't theoretical. In production systems for patient matching at hospitals, a collision rate of just 0. 5% can lead to thousands of duplicate records per year. In voter registration, a collision that blocks a legitimate candidate can make national news - and undermine trust in the electoral process.

Identity Verification Beyond Names: What Biometrics and Multi-Factor Can Teach Elections

It is tempting to propose biometrics as the solution: fingerprint scanning at polling places or facial recognition for voter registration. But biometric systems come with their own set of problems: accuracy disparities across demographic groups (as documented in NIST studies), privacy concerns. And the risk of large-scale surveillance. India's Aadhaar system - for example, processes over a billion biometric identities but has faced criticism for exclusion errors and surveillance creep.

A more pragmatic approach is multi-factor identity proofing, similar to how financial institutions verify users. A voter could verify possession of a government ID (factor 1), knowledge of a personal detail such as last four digits of SSN (factor 2). And proof of residency (factor 3). This three-factor approach drastically reduces collision risk without requiring biometric data. For election officials, this means linking a voter ID number to the name rather than relying on the name alone.

The Sullivan case highlights that the current system doesn't even use the voter ID field as the authoritative key. If the challenger had been assigned a unique voter registration number at registration, the name collision would have been irrelevant to ballot access. The state could then have displayed his full legal name alongside a suffix or middle initial to avoid visual confusion that's a software change, not a legal one.

How Social Media Platforms Handle the Duplicate Name Problem

Social networks have faced similar name collision issues for years and have developed a range of strategies. Twitter (now X) allows users to append numbers to their display name - effectively creating a unique handle (@realDanSullivanAK). Facebook, after public controversy over its "real name" policy that harmed transgender users and indigenous people, shifted to a more flexible approach allowing multiple identity documents.

However, these platforms enjoy the advantage of scale: they can create synthetic unique identifiers (user IDs) that are invisible to the end user but guarantee uniqueness in the database. Elections can't do that in the same way because the voter roll must be publicly auditable by name. But they can separate the internal identifier (voter ID) from the public-facing name and even allow candidates to clarify their identity with a suffix or party label.

The key insight from social platforms is that context matters for disambiguation. On Twitter, two users named Dan Sullivan might be distinguished by their avatar, bio, follower count. And past tweets. In elections, context could be party affiliation, residence address, and incumbent status. The judge's ruling implicitly recognized that voters are capable of using context - even if the algorithm is not.

Building a Better Ballot: Technical Recommendations for Election Systems

Based on this case, I propose several concrete technical changes that election jurisdictions could adopt today without new legislation:

• Adopt a hybrid key system: Use a randomly generated voter ID as the primary key in all internal databases, but allow the human-readable name to be displayed with disambiguation hints (e g., "Dan Sullivan (incumbent)" vs "Dan Sullivan (challenger)").
• add a probabilistic deduplication engine: Instead of exact name match, use tools like Dedupe or Python's fuzzywuzzy to flag plausible duplicates and then route them to human review. Thresholds should be set to minimize false positives for rare collisions.
• Provide a robust appeals API: When a candidate is flagged, the system should automatically generate a human-readable explanation and allow the candidate to submit documents (election affidavit, ID) via a secure portal. The judge's ruling essentially invented this process after the fact - it should exist by design.
• Run collision simulations annually: Use public voter roll data to simulate name matches and assess the false positive rate. If the model flags a candidate named "John Smith" too often, the threshold needs adjustment.

The Broader Implications for AI and Identity at Scale

The Sullivan-Sullivan case is a microcosm of a much larger challenge facing AI systems that process identity. Large language models, for example, struggle with entity disambiguation in training data. When a model sees "Dan Sullivan" in a context window, it can't reliably know whether the senator or the challenger is being referenced. This leads to hallucinated facts and conflated biographies, a problem that entity linking research aims to solve.

Similarly, recommendation algorithms and ad-targeting systems often deduplicate users by name or email. When a collision occurs, the system may merge two users' histories, causing privacy violations or targeting errors. The engineering standard for these systems - probabilistic record linkage using multiple variables - is exactly what election systems need to adopt.

There is also a human-rights dimension: name collisions disproportionately affect people with common last names or those from cultures where patronymics are used (e g, and, Iceland)An algorithm that blocks all "Dan Sullivan" types is inherently biased against non-unique names. Engineers must recognize that identity isn't a single string but a rich, multi-dimensional object.

Frequently Asked Questions

Conclusion: The Name on the Ballot isn't the Problem, the Algorithm Is

The Alaska judge's ruling was correct: a person can't be disqualified from running for office simply because they happen to share a famous name. But the underlying system failure deserves more scrutiny. The election division's algorithm treated a common name as