Confirm the right person when names collide

OneSearch research desk · Last reviewed 2026-09-20

How to disambiguate common names before you write a brief or a message. Confirm one person, or stop.

A full name is not an identity. Alex Chen is usually dozens of public people. Maria Garcia collides across US and LATAM pages. Jordan Okonkwo can be a Lagos payments PM and a London journalist. John Smith is too many to brief blindly. If you write a note, a message, or a first-call brief before you can point to one unique public artifact, you are guessing. This method is the guess-prevention step. You can run it in Google, on LinkedIn, or in OneSearch candidate cards. The rule does not change: confirm or stop. Do not merge people.

Confirmation is also the gate that keeps people search from turning into a sloppy screen. You are preparing a conversation, not deciding hire, tenant, credit, or insurance eligibility. OneSearch is not a CRA. If the job is eligibility, leave this page and read FCRA and legal use. This is not legal advice.

Start assuming collision

Treat every first-plus-last name as a collision until one artifact kills the other candidates. That sounds pessimistic. It is cheaper than the alternative: quoting the Austin founder to the SF engineer, or emailing the Madrid journalist as if she ran a Miami warehouse. Common names are not a special case. They are the default. Unusual names still collide — junior/senior, married names, transliteration, a mid-career spelling change.

Write down the breadcrumbs you already have before you search. Company, city, title, a talk title, a repo, a mutual, a publication. One breadcrumb is a filter. Zero breadcrumbs is a list of strangers. If you only have a first name, you do not have a research problem yet. You have a missing field. Ask the organizer. The collision lab below is a teaching tool, not a live search. Type a name to see how you should think before a brief exists.

Name collision lab

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

Usually dozens of public identities

Add company or city before you brief anyone. Confirm on a card, do not take the first hit.

What the lab is telling you: adding a company or a city is the first move, not reading the first hit. Title plus city beats a middle initial. If two cards still fit after that, you need a unique public artifact or you should not proceed. For why common names fail in bulk, see common-name collisions.

What counts as a confirm

A confirm is a public artifact that ties the name on your invite to one living identity and excludes the lookalikes you can already see. It has to be unique enough that a reasonable colleague would not apply it to the other cards. It has to be open — no login you are not entitled to, no ATS, no CRM, no leaked PDF. If you cannot send the URL to a colleague without violating access rules, it is not a confirm.

Artifacts that usually work: a company team page with a photo that matches a talk recording; a speaker bio PDF whose talk title matches the invite; a dated byline on a publication the introducer named; a public repository under the employer org; show notes that list the company and a face you can match to a badge photo. Artifacts that usually fail: a LinkedIn headline that only says the company (headlines are edited and reused); a city plus a generic title ("engineer, San Francisco"); a middle initial that appears on one PDF and nowhere else; a people-directory age; a mutual friend's memory with no page behind it.

Write the confirm line before you extract any other fact: "Same person because [artifact] on [URL] dated [year], which does not fit [lookalike]." If you cannot name the lookalike you excluded, you have not looked hard enough to know you are safe. LinkedIn is a candidate card, not a confirm, unless something else unique sits on that public profile — a talk link, a publication, a photo you can match. For the job split, see OneSearch vs LinkedIn.

The disambiguation tree

Run the tree in order. Do not skip a level because you are late. Lateness is how the wrong Alex gets the brief.

Disambiguation tree
  • Start: full name only → expect collisions
  • Add company or city → still N cards?
  • Need one unique public artifact (talk, repo, byline)
  • If two cards still fit → stop. Do not merge people.
  1. Full name only. Expect collisions. Do not brief. Do not message. List the distinct public identities you can see in one minute: role, city, one hint.
  2. Add company or city— whichever the invite already gave you. If that produces one card that still has a unique artifact, confirm. If you still have N cards, do not pick the first one because it "looks senior."
  3. Need one unique public artifact (talk, repo, byline, team-page photo match). Add the artifact as a query term. You are not fishing for gossip. You are looking for a handle that only one of the cards can hold.
  4. If two cards still fit, stop.Do not merge. Do not write "probably the SF one." Ask the organizer for a profile URL, a team name, or a talk title. Walk in and ask which team they are on. Thin is allowed. A merged person is not.

Researchers booking a source use the same tree. The cost of quoting the wrong Maria Garcia is a correction and a burned relationship. See sourced people research for the citation habit after you confirm.

Pick the card you meant

Candidate cards are how you keep the tree honest. Each card is one public identity: name, a role/city line, and one hint. You pick before any narrative is written. The exercise below is the Alex Chen collision you will meet in the worked example. You were told: "Alex Chen, the SF engineer who spoke on latency last year." Pick the card. A confident brief on the wrong one is a professional error.

Pick the person you meant

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

Notice what the correct card has that the others do not: city, role, and the talk topic all agree. The NYC card has a faculty page and a different middle initial on a PDF — that is a different person, not "more context." The Austin card has a recent podcast and a different face. Face mismatch is a hard stop even when the topic is adjacent (logistics vs payments). Adjacent topics are how people merge.

Worked example: Alex Chen

Invite: "Alex Chen, Stripe, 30 min — payments latency." Introducer: Priya, who remembers a hallway conversation after a latency talk last year. Breadcrumbs you write down before search: Alex Chen, Stripe, San Francisco implied by the company, talk about latency, Priya as mutual. Exclusion: you will not open directories for age or relatives; you will not use this as a hiring screen.

Level 1 — name only. You will see, among others: a staff engineer at a payments company in San Francisco with a conference talk on tail latency and GitHub org commits; a principal at a quantitative shop in New York with a faculty page and a different middle initial on a PDF; a founder of a logistics startup in Austin who was on a podcast last month. Three cards. No brief.

Level 2 — add company. "Alex Chen" Stripe and "Alex Chen" site:stripe.com collapse most of the NYC and Austin noise. You still check that Stripe did not also employ a different Alex Chen. Company plus name is a filter, not a confirm, when the company is large.

Level 3 — unique artifact. The 2025 talk on p99 latency: recording shows a face that matches the team-page photo; slides are a PDF with the same employer. GitHub org commits sit under that employer. Confirm line: same person because team page + talk + org commits agree, and they do not fit the NYC faculty page or the Austin podcast face.

What you refuse: the NYC PDF's middle initial as "maybe they dropped it." The Austin podcast as "also interesting, similar name in tech." A LinkedIn profile that says payments but shows a different face. You now have permission to write a meeting note. You do not have permission to write a biography. Three facts and a question. The rest of the method is research someone before a meeting.

If Priya had said only "Alex Chen who works in payments" with no city and no talk, level 2 still leaves two payments people on some years. You stop. You ask Priya for the talk title or a LinkedIn URL. You do not pick the one with more GitHub stars. Stars are not identity.

Worked example: Maria Garcia

Intro email: Maria Garcia, former VP of operations at a Miami logistics company, trade podcast last quarter on port delays. You are booking her as a possible advisor. Breadcrumbs: Maria Garcia, VP ops, Miami, logistics, podcast, port delays. High collision — US plus LATAM public pages. Title plus city beats a middle initial.

Level 1 — name only. A journalist in Madrid who writes about supply chains. A school-board member in Texas. An operations leader in Miami. A nonprofit director in Los Angeles. Four cards in the first minute if you are looking. Topics overlap (supply chains, operations, civic logistics). Overlap is the trap. You do not brief a topic. You brief a person.

Level 2 — add city and company. "Maria Garcia" logistics Miami drops Madrid and Texas for most results. The LA nonprofit may still appear if she spoke at a port-adjacent event. Still N cards.

Level 3 — unique artifact. Podcast show notes list the Miami company and a photo. A conference badge photo from the same season matches. A speaker bio PDF, if it exists, should carry the same company and the episode title. Confirm line: same person because show notes + badge photo + company name agree, and they do not fit the Madrid byline photo or the Texas district site.

Failure inside this example: you treat "Garcia on supply chains" as a confirm. The journalist also talks about ports. You email her a warehouse question. She is not your advisor candidate. You have now briefed the wrong person and burned a cold outreach that looked like homework. The other failure: the podcast is real but the photo matches nobody else. That is a possible artifact. You write to the organizer: "I heard episode N attributed to Maria Garcia, Miami logistics — is that the person on the invite?" Asking is confirmation work. Merging the journalist "just in case" is not.

If two Miami operations leaders named Maria Garcia appear — same city, same industry, overlapping years — you are at the stop node. You need a talk title, a team name, a middle name, or a profile URL. You do not average them. You do not write "Maria Garcia (ops, Miami)" as if that were one human.

Worked example: Jordan Okonkwo

Invite: "Jordan Okonkwo, payments, 25 min." Introducer Slack: product, Lagos, talked about settlement rails at a regional meetup last year. Breadcrumbs: Jordan Okonkwo, payments, Lagos, product, settlement-rails talk. Exclusion: you will not open a directory for age or relatives; this is not a hiring screen.

Level 1 — name only. You will see, among others: a product manager at a Lagos payments company with a meetup talk on settlement rails and a company blog byline; a London football journalist with match-report bylines and a different face; a Houston pastor whose livestream titles include the same first name. Three cards. No brief.

Level 2 — add city and field. "Jordan Okonkwo" Lagos payments drops London sports and Houston for most results. Company-plus-name is still a filter. Large payments companies employ more than one Jordan.

Level 3 — unique artifact. The meetup talk: recording or speaker card shows a face that matches the company blog byline photo; the talk title includes settlement rails. Confirm line: same person because meetup speaker card + company byline agree, and they do not fit the London byline photo or the Houston livestream.

If the introducer had said only "Jordan in payments" with no city and no talk, you stop. You ask for the meetup title or a profile URL. You do not pick the journalist because they publish more. Rank is not identity.

When two cards still fit

Stop is a complete outcome. It means: you will not write a brief, you will not send a personalized message that depends on a fact, and you will not tell a colleague "I looked them up" as if the work were done. What you can do:

  • Ask the organizer for one more breadcrumb.
  • Ask the person, in the room, which team or which talk they mean.
  • Walk in with the inventory sentence only: you know the name on the invite and the company as written.
  • If you use OneSearch, you still do not generate a brief against a guessed card. No brief yet is the product behaving correctly.

What you cannot do: pick the card with the nicer photo; pick the one who went to a school you respect; merge the two timelines into a single career; treat the quieter card as "the same person, less online." Two public identities that both fit your breadcrumbs are two people until an artifact says otherwise. Time pressure does not change the set.

If a colleague says "just go with the first one," your answer is the confirm line they cannot finish. If they wanted a screen, that is a different refusal — people search is not a background check.

What you must not merge

Merging is the specific error this guide exists to prevent. It looks like one paragraph with two people's facts.

  • Face vs topic.Same talk topic, different face — two people. Do not write "has spoken on latency / also does logistics podcasts."
  • Middle initial. A PDF with a different middle initial is a lookalike until a unique artifact overrides it. Do not drop the initial to make the career continuous.
  • Shared employer, different years and cities. Large companies employ many Alex Chens. A 2018 New York intern is not the 2025 SF staff engineer because the logo matches.
  • Relatives and directories.A directory that lists "related to" is not a family tree you may use, and it is not a confirm. Leave it.
  • Transliteration and nicknames. Alex / Alec / Alexander can be one person or three. You need the artifact, not a naming theory.
  • Old bylines after a name change. Possible, but you confirm with a page that says the names are the same person. You do not infer it to fill a gap.

If you already wrote a merged paragraph, split it. Every sentence goes back to one URL. Sentences that need two URLs from two identities are deleted. Then you run the tree again. A corrected thin note is usable. A confident chimera is not.

Failure modes

  • First-hit bias. Google ranked a different Alex Chen first because that person publishes more. Rank is not identity. Fix: list three cards before you open the first.
  • Headline matching. The LinkedIn title matches the invite, the face does not. Fix: photo or talk, then title.
  • Over-filtering with operators. You add so many terms that only one page survives — the wrong one that happens to contain all the words. Fix: add one breadcrumb at a time; if the set collapses too fast, widen and look at faces.
  • Using a screen as a confirm. A CRA report identifies a person with authorized identifiers. You do not have that here, and you should not. Fix: stay in prep; confirm with public artifacts only.
  • Messaging before confirm.A "personalized" note that cites the wrong talk is worse than a generic note. Fix: if unconfirmed, do not cite.
  • Unauthorized pages as the tie-break. An internal wiki, a resume in an ATS, a document you should not have opened. Close it. It cannot be your artifact. Ask for a public URL instead.

After you confirm

The brief is allowed now — and only now. Extract a few dated facts from pages that belong to the card you picked. Keep the confirm line at the top of the note so a colleague can challenge it. If a new page appears that fits a lookalike better than your card, you reopen the tree. Confirmation is not a lifetime certificate. It is a claim about the pages you have today.

Follow-up questions stay attached to that person. You do not start a second search that quietly includes the Austin founder because a result was interesting. If you use OneSearch, this is the confirm step before the sourced page. You should not write the paragraph until you pick a card, in tabs either.

If you cannot confirm, walk in thin or ask. Those are complete. The incomplete move is a paragraph that pretends one Maria Garcia is all of them.

Try this on a real name

Confirm the person before a brief is written. Public pages only. They are not notified.

Next read