Why a name is never enough

People-search products fail in a predictable way. They take two public records that share a name, treat the overlap as identity, and produce one confident profile. Sometimes that profile is about nobody. Sometimes it is about the wrong person who does exist.

That is the failure we designed around. A name is a search clue. It is not proof that two records describe the same person.

The collision is ordinary

In any large population, many people share a first and last name. The Consumer Financial Protection Bureau has put a number on how ordinary that is: thousands, and in some cases tens of thousands, of people may share one particular combination. The 2010 Census surname file is the public dataset underneath that warning: we read it in 2.4 million Americans share the surname Smith.

The same statement notes that the risk is not evenly distributed. Name-only matching is more likely to mix people in Hispanic, Black, and Asian communities, because those populations have less surname diversity than the non-Hispanic white population. A product that merges on name is not a neutral shortcut. It is a bias amplifier.

We are not a consumer reporting agency, and this is not a post about credit files. The reason the finding matters here is simpler. If matching on a name alone is too weak for a regulated report, it is too weak for a public-web profile as well.

A mixed identity looks finished

The dangerous result is not an empty page. It is a full-looking one.

One person's job title, city, photograph, or court record gets attached to someone else. The card has a face, a timeline, and a handful of sources. It reads as a person. Completeness is what makes the error hard to see. A thin, correctly labeled "possible match" can be checked. A fused profile asks the reader to believe a person who is actually two people.

US regulators have already documented the harm in a different market. In 2021 the CFPB issued an advisory opinion that a consumer reporting agency matching information to a person based solely on an identical or similar name is not using reasonable procedures to assure maximum possible accuracy under the Fair Credit Reporting Act. The accompanying statement is blunt about the consequence: people lose housing and work because a screener assigned them someone else's record.

DeepSearch must not be used for those decisions. That line is in our terms, and it is the subject of a separate legal explainer. The matching problem does not disappear just because the use is ordinary research. A public webpage can be wrong about who it is describing in exactly the same way.

What we refuse to treat as proof

The rule is short, and it is a constraint rather than a preference:

• a name alone never establishes a match
• a single overlapping detail is a hypothesis, not a conclusion
• confidence rises only when independent sources agree
• results are ranked so you choose a person, rather than being handed one

Independent means a separate evidence path. Two directories that copied the same listing are one source, repeated. A LinkedIn URL that appears on a personal site, plus the same uncommon handle on a second platform, plus a matching employer on a third page, is the beginning of a case. The common-names guide is the practical version of that worksheet.

A conflict stops the merge. Different cities in the same year, two ages that cannot both be true, a photo history that belongs to someone else: those are not details to average away. They are the reason to keep the records apart and say so.

A score is not a verdict

The product shows a confidence score so that several possible people can be compared. Our terms say what that number is: an estimate, not a certainty. It ranks candidates. It does not mean every field on the selected card is true, and it does not mean the person you had in mind is the person on the page.

The AI layer that writes the summary is under the same limit. It can describe the evidence that was collected. It cannot invent the missing link that would make two namesakes into one person. If the sources do not support a merge, the honest output is "possible match" or "no public record ties these together" — not a fluent biography.

How to check a specific claim is in How to verify a DeepSearch result using its sources.

Why we will sometimes return less

A competitor can produce a richer card by assuming that same-name records belong together. That looks like a better product in a screenshot. It is a worse product in the only case that matters: when the records do not.

We would rather show an incomplete result, several candidates, or no confident match than ship a detailed profile assembled from the wrong people. The earlier transparency note called this the intended trade. It still is.

The cost is real. You may have to add a city, an employer, a username, or a date before the right person rises. That is not the product failing to understand the name. It is the product refusing to guess.

If you are in a result

If a page mixes you with someone else, that is a correction, not a debate about whether the other person exists. Send the result URL, the field that is wrong, and the source it cites. The route is on the contact page, and the steps are in How to correct or remove information from DeepSearch.

If you want the public page taken down, Remove my info is the request form. We think a company that surfaces information about people should make that path easier to find than the profile.

Why publish this

Because the failure mode is the category's reputation, and because the constraint is easy to check. You can see whether we return several people instead of one, whether a claim links to a page, and whether the language hedges when the evidence is thin.

If you find us merging on a name, or speaking more confidently than the sources allow, the contact page reaches us. We would like to hear about it.