What DeepSearch searches—and what it cannot see

DeepSearch is a search and synthesis layer. It can organize information returned by public or explicitly identified licensed sources, but it does not create access to private accounts, private communications, or a person's device. The most useful way to read a result is therefore: this is what the available sources connected to this input, not a complete or official file about a person.

Start with the product surface

DeepSearch has several lookup modes and a broader research assistant. They do not all accept the same input or call the same sources.

• A name or username search looks for public identity candidates and public profiles.
• An email search can examine public web connections, domain information, public account signals, and the names of known exposure incidents. It cannot open an inbox or reveal stolen credentials.
• A phone search can decode the number and may return carrier, line-type, allocation-region, caller-label, public-web, or licensed association signals. Coverage differs by country and provider.
• A reverse-image search looks for the same or visually similar image on public pages. It is not facial recognition.
• Photo intelligence examines available metadata and visual geography cues. It is an estimate about the image, not live access to a device.
• Company and VIN searches use entity- or vehicle-specific public and licensed sources rather than treating the input as a person.
• The Deep Search research mode can combine several tools around a question. Its answer still depends on the tools and sources available to that surface.

This distinction matters. For example, the public MPP research specification expressly documents a different input and capability set from the consumer lookup form. Do not assume that a result available in one surface exists in every other one.

What the sources can contain

The current DeepSearch transparency statement describes the main evidence categories. A particular search may use only a subset.

| Source category | What it can support | What it does not prove | | --- | --- | --- | | Public webpages and published articles | A page made a statement, displayed a profile, or associated an identifier | That the statement is current, accurate, or about the right namesake | | Public social profiles | A visible account, handle, bio, link, post, or platform label | That every same-name or same-handle account has the same owner | | Public records and directories | The fact a record or listing exists and the fields it publishes | A complete present-day biography or permission for every downstream use | | Telecom and numbering data | Number validity, country, carrier, line type, allocation region, and in limited cases a caller label | Message contents, live location, or a universally verified subscriber identity | | Public breach-notification indexes | The name of a known incident associated with an address | A password, breached-record contents, or proof that the current account is compromised | | Licensed people-data services on a surface that names them | Records or associations the provider returned | An official fact; aggregated identity links can be stale, mixed, or wrong | | Image-search providers | Public pages containing the same or a similar image | The identity of a face or the truth of the caption attached to it |

The source category is part of the claim. A carrier label, a public profile, and a broker association should not be presented as if they were equally strong forms of identity evidence.

What DeepSearch cannot legitimately see

The privacy policy and terms set the boundary. DeepSearch does not provide:

• access to private or follower-only accounts
• private inboxes, direct messages, call audio, text-message contents, or call history
• passwords, hashes, authentication codes, or the contents of leaked records
• private carrier subscriber files
• a person's live or precise device location
• identity from a face
• a guaranteed, complete, or permanently current profile
• a consumer report for employment, credit, housing, tenancy, or insurance decisions

If a page or summary appears to cross one of these lines, do not treat the output as permission to use it. Preserve the result URL and source, then report the issue through DeepSearch support.

Why a result can be empty

An empty result does not mean the subject does not exist. It can mean:

• the input was wrong or incomplete
• the person keeps the identifier private
• the relevant page is not public or not discoverable
• a provider has no coverage for the country or record type
• a source timed out or was unavailable
• matching rules kept an ambiguous candidate separate
• the information was removed or suppressed

The reverse is also important: a full-looking result is not proof of completeness. Public pages can repeat the same original error, and several fields can come from one underlying dataset.

Read every result as an evidence map

For each important field, ask four questions:

1. What source produced this field? Open the source rather than relying on the summary alone.
2. What exactly does that source assert? A number allocation, public bio, and identity association are different claims.
3. Does it identify the same subject? Compare stable anchors such as an exact handle, official domain, employer, location, or cross-linked account.
4. How current is it? Look for publication, profile-update, filing, or retrieval dates.

A match score helps rank candidates; the terms make clear that it is an estimate, not certainty. Verify consequential facts independently before acting.

Continue with how to verify a DeepSearch result using its sources. If the first input is still unclear, use the lookup-type decision guide.