Common-name collisions

Alex Chen is not one person

People search fails most often at the first noun. You were given a name. You treated it as a primary key. The public web does not. Alex Chen is a staff engineer in San Francisco, a principal in New York, a founder in Austin, and dozens of other indexed identities. Maria Garcia collides across US and LATAM pages. Wei Zhang collides across academic pages — a Chicago lab and a Toronto climate group can share the name and still be two people. John Smith is too many to brief blindly. A first-call note that starts from the name alone is already a merge waiting to happen.

Collision is normal. It is not a data-quality bug and it is not a reason to buy a consumer file. It is a reason to confirm before you write. OneSearch shows candidate cards — role, city, a public snippet — and refuses to generate a brief until you pick. You can copy that gate in a notes doc. The companion method is confirm the right person. This page is the collision lab: why the pile exists, how to add one breadcrumb, and when to stop instead of blending two lives.

Wrong-person briefs are not a small embarrassment. You open a sales call with a talk the person never gave. You send recruiting outreach about a repo they do not own. You quote a byline from a namesake in a research note. The other side notices immediately. Confirm-first is faster than an apology. It is also how you stay on the public web instead of reaching for directories that pretend a name plus a city is a consumer identity. That is a different product, and closer to a report than a brief. See people directories and FCRA and legal use.

Name collision lab

Type a name. This widget is a teaching tool, not a live search. It shows how you should think before a brief exists.

Try Alex Chen, Maria Garcia, Wei Zhang, and John Smith. Then try a name you actually have on the calendar. The default stance is the same: treat every full name as a collision until proven otherwise. Proven means a card you can defend, not a feeling that the first hit “looks right.”

What the lab will not do is tell you how many people exist in the world with that name. That number is not a useful statistic and we will not invent one. What matters is operational: can you pick one public identity with the breadcrumb you already have, or do you still have two cards that fit? If you still have two, you do not have a count problem. You have a stop.

Disambiguation tree

Walk the tree in order. Do not skip to “I’ll know them when I see the LinkedIn.”

Start: full name only → expect collisions. A name in a search box is a request for a pile. If you brief from the pile, you will brief a blend.

Add company or city → still N cards? Use a breadcrumb you already had: the employer on the inbound form, the city on the badge, the title in the email signature. Do not add a city you inferred from a namesake and then treat the smaller pile as confirmation. That is circular.

Need one unique public artifact. A talk, a repo, a byline, a slide deck, a program PDF. Artifacts cut through names. Titles do not — there are many staff engineers named Alex Chen.

If two cards still fit → stop. Do not merge people. This is the whole guide in one line. Go back to the referrer. Write a question, not a brief. A confident merge is a professional error.

Google will happily show you more cards. That is its job — find a page. It will not tell you which page is your person. OneSearch vs Google is the split between a result list and a confirm-first brief. LinkedIn will show you a graph inside LinkedIn; it will also collide. Use it to message after you know who you mean, not as a silent primary key. OneSearch vs LinkedIn covers that job split.

Breadcrumbs you already have

A breadcrumb is a fact that arrived with the name, before you searched. Inbound form: company. Conference badge: city. Referral Slack: “spoke on latency last year.” Email footer: title. Calendar invite: org. Those are legal inputs to disambiguation because they are independent of the results list. A breadcrumb you picked from result #3 and then used to justify result #3 is not a breadcrumb. It is a loop.

Rank breadcrumbs by how unique they are. Talk title plus year beats “engineer.” Company domain beats industry. City helps only after company or artifact; many people named Maria Garcia have lived in a large city. Middle initial helps when it appears on an open PDF. It does not help when you guessed it.

If you have no breadcrumb, you do not start a brief. You send one question: “Which Alex Chen — company, city, or a talk I can search?” That email is the work. Searching harder without a breadcrumb produces more collisions, not more certainty. Operators can make the next pass faster once you have the breadcrumb — documented operators — but they cannot invent the constraint.

Write the breadcrumb at the top of the note before you open tabs. If you cannot write it, you are not ready. This is the same discipline as the confirm line in a first-call brief.

Pick the person you meant

Practice on a fixed prompt. You were told: “Alex Chen, the SF engineer who spoke on latency last year.”

The correct card agrees on talk plus city plus role. The New York quant has a faculty PDF and a different middle initial. The Austin founder has a recent podcast and a different face. A brief on either wrong card can be internally consistent and still be about the wrong human. Consistency is not confirmation.

When you pick, pick once. Then freeze the card. Do not keep a “backup Alex” in the notes and borrow a GitHub from them when your person is quiet. That is a merge. If your person is quiet after a real pass, write a thin brief — when the public web is quiet — on the card you picked, not a collage.

OneSearch’s product behavior matches this widget: candidate cards, then a brief, never the reverse. If you skip the cards in manual research because you are late, you are choosing the failure mode the gate exists to prevent. How it works is name → confirm → sources → brief → ask. Confirm is labeled “no brief yet” for a reason.

One unique public artifact

An artifact is a public object that is unlikely to belong to two people at once: a named conference talk, a repo under an org, a byline on a specific article, a slide deck with a face and a company. “Works in tech” is not an artifact. “Staff engineer” is not an artifact. “Based in California” is not an artifact.

How to use one: search the artifact first, then match the name on that page. Program PDF → name + affiliation. Talk video → face + title slide. Repo → org + commit name that also appears on a company page. This order avoids the namesake who happens to share a first name in the same industry.

How not to use one: take a podcast titled with a common name and assume it is your person because the topic is adjacent. Adjacent is how Austin’s founder lands in your SF engineer brief. Open the artifact. Check the face, the company, the year. If you cannot check, park the URL. Source verification is the next method once a card is chosen; this section is about using artifacts to choose.

If no unique artifact exists on the open web, you may still confirm with a strong company-plus-role match on a first-party team page — if and only if that page would not also fit the other cards. If the team page is a list of first names, it is not enough. If two companies list an Alex Chen in similar roles, you are still on the tree’s last node: stop.

Worked example: Alex Chen, SF engineer

Input: “Alex Chen, the SF engineer who spoke on latency last year.” Breadcrumb: city, role family, artifact type (talk), recency. That is a good input. It is still not a brief.

Pass one, name only: a pile. You do not write. Pass two, name + “latency” + year: a conference program and a company engineering post. Pass three, open the program: San Francisco, payments company, staff engineer, talk title matches. Pass four, reject cards: New York quant (faculty PDF, different middle initial), Austin founder (podcast, different face, logistics company). Confirm line: “Alex Chen — staff engineer, payments, SF. Unique artifact: [year] latency talk, program URL.”

Now — and only now — a brief is allowed. Work and summary come from pages that sit on this card. Follow-up questions stay on this person’s sources. If the engineering blog has one post and the web is otherwise thin, the brief is thin. You do not borrow the Austin founder’s press to make the page look senior.

Failure version of the same hour: you liked the Austin podcast, the energy was good, you wrote “Alex Chen, founder energy, logistics → payments crossover?” and you walked into a discovery call with an engineer who has never run a startup. That meeting is how collision debt gets paid.

Worked example: Maria Garcia, stale referral

Input: “Maria Garcia, research-adjacent, campus talk around 2019, might be Austin.” Breadcrumbs are weak. Year is stale. City is hedged. Name is high-collision. This is the dangerous case because you will be tempted to complete it.

Lab stance: high collision across US and LATAM public pages. Title + city beats a middle initial. If two cards still fit, stop. You search campus + 2019 and find a departmental bio and a program PDF. You search Austin + the topic and find a 2023 byline for a Maria Garcia in a nearby field. Two cards. Both could be “research- adjacent.” Neither is confirmed as the other.

Correct output: an email to the referrer with two lines and two URLs. “Which Maria — 2019 [campus] program, or 2023 byline at [publication]?” Incorrect output: one brief that uses the bio for education and the byline for “still active,” plus Austin as current city because the referral said “might be.” That document is two people. It will read as competent to a teammate who does not open the links.

If the referrer says “the 2019 campus one” and has nothing later, you write a thin brief on that card. Current employer: not confirmed. Last dated page: 2019. Questions about now, not about a 2024 title. If they say “I’m not sure,” you do not guess. You cancel or you take the meeting without a biography. Both are better than a merge.

Worked example: Wei Zhang, two academics

Input: “Wei Zhang, the Chicago machine-learning researcher who had a workshop paper on evaluation last year.” Breadcrumbs: city, field, artifact type (workshop paper), recency. High-collision name across US and Chinese academic pages. Two strong cards will appear. That is the point of this example.

Card A: a Chicago lab site lists Wei Zhang with a 2025 workshop PDF on evaluation metrics, same face as a talk video. Card B: a Toronto climate group lists a Wei Zhang with a 2024 working paper on downscaling, different face, different affiliation. Pass one, name only: a pile. Pass two, name + “evaluation” + Chicago: the workshop PDF. Pass three: reject Toronto (different artifact, different face). Confirm line: “Wei Zhang — researcher, Chicago lab. Unique artifact: 2025 evaluation workshop PDF. Breadcrumb: Chicago, evaluation, last year. Rejected: Toronto climate Wei Zhang (working paper, different face).”

Failure version: you liked the climate paper’s citations, you wrote “Wei Zhang, ML plus climate-adjacent evaluation,” and you walked into a methods conversation with a person who has never written about the atmosphere. Adjacent topics are how two academics become one brief. If the referrer cannot say “Chicago, evaluation workshop,” you send both URLs and stop.

What merging looks like

Merging is easy to spot after the fact and hard to feel in the moment. Signs while you work: you have two employer timelines that do not meet; you have two faces; you are using “probably also” ; you deleted a middle initial that was inconvenient; you took a city from one page and a title from another; you are arguing with a teammate about which link is “more them.”

Signs in the brief: one summary paragraph that would require the person to have been in two cities in the same month; a GitHub org that does not appear on any first-party page for the confirmed employer; a press clip whose photo does not match the talk video; a family or age field that never appeared on an open page about this card.

The fix is not a better blend. The fix is to split the note into Card A and Card B, label both parked, and refuse to write a shared summary. If you already sent the blended brief, send the split. “I mixed two Maria Garcias. Use this URL only.” That correction is part of the method.

Merging is also how teams slide toward directory thinking: smash records until one dossier remains. OneSearch will not do that smash. A quiet card stays quiet. A second card stays a second card. If your workflow needs a single consumer identity for eligibility, you are in the wrong product and possibly in the wrong statute. People search is not a background check.

Write a confirm line

The confirm line is the only paragraph that must exist before sources and summary. Format:

[Name as on the page] — [role as on the page], [company or org], [city if sourced]. Unique artifact: [talk / repo / byline], [date], [URL]. Breadcrumb used: [what arrived with the name]. Rejected: [one-line other cards]. If rejected is “still two cards,” the confirm line is not done and the brief does not start.

Example, Alex: “Alex Chen — staff engineer, payments company, San Francisco. Unique artifact: 2025 latency talk, program URL. Breadcrumb: AE said SF engineer, latency talk last year. Rejected: NY quant (faculty PDF, different middle initial); Austin founder (podcast, different company).”

Example, Maria, thin: “Maria Garcia — 2019 departmental bio and campus program PDF. Current employer not confirmed. Breadcrumb: referral, campus ~2019. Rejected: 2023 byline parked, identity not matched. Brief is thin; do not invent a 2024 title.”

Example, Wei: “Wei Zhang — researcher, Chicago lab. Unique artifact: 2025 evaluation workshop PDF. Breadcrumb: Chicago, evaluation workshop last year. Rejected: Toronto climate Wei Zhang (2024 working paper, different face).”

Hand the confirm line to anyone who will take the call. If they cannot see why the rejected cards lost, the line is not specific enough. Add the artifact, not a vibe. Then collect sources and verify each load-bearing sentence on that card only.

Stop line

Stop when two cards still fit. Stop when you have no breadcrumb and no artifact. Stop when you are borrowing pages across cards. Stop when the remaining move is a consumer file or a regulated screen — that is not disambiguation, that is a different legal job.

After a clean confirm, write the first-call brief, verify the URLs, and accept quiet if the card is thin. To run the same gate in the product — name, confirm, sourced page, follow-ups — start at people search.