Verify a people-research claim

A claim is not a fact yet

People-research goes wrong in the last thirty seconds: you saw a sentence, you trusted the snippet, you said it in the room. Verification is the habit of opening the original URL, checking that the page is about the person you confirmed, and reading the date before the claim becomes part of your first-call brief. AI can organize what you found. It cannot replace the click. OneSearch puts the link next to the sentence so the click is cheap. The method still requires you to use it when the fact has to hold up.

A claim has four parts, whether you write them down or not: who, what, when, and where (the URL). “Alex Chen is a VP” is not four parts. It is a what with an implied who and no when and no where. Until you can fill the rest, it stays parked. Parked claims do not get spoken. They do not get pasted into a hiring packet. They do not get upgraded by confidence.

This guide is not legal advice and it is not a substitute for a consumer report. Opening public pages does not make a brief FCRA-compliant. If the use is eligibility — hire, tenant, credit, insurance — stop and use a CRA. The statute is on the FTC Fair Credit Reporting Act page. The product boundary is on FCRA and legal use. Verification here means “can I defend this sentence as public-web context for a conversation?”

Where claims live in a brief

Every section of a brief is a bundle of claims. Click through the parts and ask which sentences are load-bearing.

Confirm is itself a claim: this card is the person you meant. If that is wrong, verifying the sentences below is verifying a stranger. Summary sentences should each have a URL. Work sentences should carry a date when the source has one. Ask-questions are not claims about the person; they are claims about what the sources can support. If you cannot point a question at a page, it does not belong in the brief as research. It belongs in the conversation as a blank.

The anatomy also tells you what not to verify. Tone (“seems collaborative”) is not a public-web claim. A phone number from a directory is not a public-web claim for this product. A household field is not a public-web claim. If you cannot attach it to an open page about the confirmed person, it should not be in the brief, and there is nothing to verify — only something to delete.

Which source layer you opened

Not every URL is the same kind of evidence. Walk the stack so you know what you are holding.

Company sites and team pages are first-party for role, when they are current and when they name the person clearly. Talks, podcasts, and bylines are first-party for how someone described their work on a date. Public social and code can confirm a handle or a stack; they are weak as title evidence and easy to collide. Press is secondary. It can date a launch or a quote. It is also where reporters merge common names. Verify press last, and never let it overwrite a missing first-party page.

If the stack is empty after a real search, you do not have a verification problem. You have a quiet web. Write thin. Do not verify a sentence you invented to fill the gap.

The verification checklist

Run this on every load-bearing sentence before the call. If any item fails, the sentence is parked or deleted.

1. Open the URL. Not the search snippet. Not a screenshot in Slack. The live page, or a dated archive if the live page is gone and you are explicit about that.
2. Match the person. Company, city, talk, photo, or another unique artifact agrees with your confirm line. A matching name is not enough. See common-name collisions.
3. Read the date. Page date, program year, byline timestamp, or “undated.” Undated role claims are weaker than dated ones. Old dates stay old.
4. Quote the scope. Write the claim in the source’s words. “Spoke on latency” does not become “leads infrastructure.” “Contributor” does not become “founded.”
5. Check the layer. First-party beats press. Press about a launch does not prove a current title. A social bio does not prove a company still exists.
6. One URL per load-bearing clause. If two facts are in one sentence, you need two links or you need to split the sentence.
7. Reject the merge. If the page might be a namesake, park it. Do not split the difference.

You can run the checklist in a notes column: URL | date | identity match (yes/no) | claim in source words | use in brief (yes / park / drop). That column is the difference between a sourced page and a tab pile. How OneSearch works is the same idea automated after you confirm a card: sources stay attached so you can repeat this pass.

Identity, date, scope

Most failed verifications fail one of three ways. Identity: the article is about another Alex Chen. Date: the team page is from a previous employer and you read it as current. Scope: the page says “speaker” and you said “head of.” Train yourself to name which of the three is weak before you keep the sentence.

Identity is a collision problem first. If you never confirmed the card, you are verifying in the dark. If two cards still fit, stop — do not verify a blend. Date is a calendar problem. Write the year in the brief even when it makes the sentence uglier. “Staff engineer as of a 2023 talk” is usable. “Staff engineer” is a guess if the only page is 2023. Scope is a verb problem. Copy the verb from the page. Then stop.

Secondary sources fail all three at once. A roundup post that says “VPs like Alex Chen in Austin” may have the wrong person, no date that applies to your Alex, and a title the person never held. That URL can stay in parked. It cannot stay in the summary.

Operators help you find the first-party page that would settle the claim. They do not verify it. After you land on a URL with search operators, you still open it and run the list above. Google’s snippet is a hint, not a source. Compare the jobs on OneSearch vs Google if you need that split explained to a teammate who thinks “I Googled them” means “I verified them.”

Worked example: “Alex Chen is VP at the payments company”

You are preparing a sales call. A teammate’s Slack says “Alex Chen, VP, payments.” You have a conference talk on latency from an Alex Chen at that company, titled staff engineer, 2025. You have no team page that says VP.

Open the Slack claim’s implied source — there isn’t one. That is already a fail on item 1. Open the talk program. Identity: SF, payments, latency — matches the confirm line you should have written, and rejects the New York quant and the Austin founder. Date: 2025. Scope: staff engineer, speaker. The VP claim has no URL. It does not enter the brief. The talk claim does: “Spoke on payment-latency tail cases, 2025 program, listed as staff engineer.”

If you later find a press clip that says “VP Alex Chen,” run identity again. Different city? Different company? No photo? Park it. Same company, same face, dated last month? You may write “press dated [month] uses VP; 2025 program uses staff engineer — title conflict, ask in the room.” That sentence is verified. “He’s the VP” is not.

What you say on the call: “Your 2025 talk treated p99 as a product problem — is that still the frame?” What you do not say: “Congrats on the VP role.” Verification changed the opener. That is the entire point of the checklist.

Worked example: attributing a campus talk to Maria Garcia

A PDF program lists Maria Garcia, departmental affiliation, 2019. A teammate wants to write “Maria Garcia is a frequent campus speaker on this topic.” Checklist.

Open the PDF. Identity: you need the same department the referrer meant. If you cannot get that breadcrumb, you may have the wrong Maria — collision, stop. Date: 2019. Scope: listed on one program. “Frequent speaker” fails scope. You may write “Listed on the 2019 [campus] program with [department].” You may not write a series.

Search for later programs with the same talk title. If you find none, the public trail is one PDF and maybe a bio. That is quiet, not a speaking career. The verified brief stays short. The invented brief grows adjectives.

If a 2023 byline appears for a Maria Garcia in a nearby field, that URL is parked until identity matches. Do not use the byline to “confirm she’s still active.” Activity of a namesake is not activity of your person.

Homonyms in press

Press is useful and dangerous. It is useful when it dates a launch and names a company that already sits on your confirm line. It is dangerous when the reporter used a common name once and your brain filled in the card you already like.

Checks that catch press merges: does the article include a company, a title, a city, or a photo that matches your artifact? Does the dateline predate your person’s public trail? Is the quote something your person said on a first-party page you can also open? If you cannot answer yes to identity, the clip is a namesake until proven otherwise.

Do not verify press by counting how many outlets repeated the sentence. Copies of a wire note are one source, not five. Open the earliest page you can, then look for a first-party page that agrees. If only the wire exists, write “press-only, [date], identity markers: [list].” That is honest. “Widely reported” is how a maybe becomes a myth.

People directories and data-broker pages are not press and are not first-party. They often show age, relatives, and phones. That is a different product class — see OneSearch vs people directories — and it is the wrong stack for a conversation brief. You cannot “verify” a household field into public-web research. You can only decide you are no longer doing this job.

Stale pages

A true sentence can still be the wrong sentence for Tuesday’s call. Team pages lag. Speaker bios linger after someone leaves. Podcasts stay up forever. Verification includes asking “is this still the page I should speak from?”

Rule: put the date in the brief whenever the source has one. If the only dated page is old, say “last dated public page: [year].” That is a verified status, not a failure. Rule: do not silently refresh a 2019 title to the present tense. Rule: if two dated pages disagree, write the conflict. Do not average them.

When a URL 404s, do not keep the claim because you remember it. Either drop it, or use an archive and label it as archived. Memory is not a source. Slack is not a source. Your previous brief is not a source unless you re-open the links. The morning-of pass exists for this: two minutes over the URLs, not a reread of your own adjectives.

How to annotate

Annotations are how a brief stays honest when handed to someone else. Use three labels only.

Confirmed. You opened the URL, identity matched, date read, scope not upgraded. The sentence can be spoken.

Parked. The URL exists but identity, date, or scope failed. The sentence cannot be spoken. It can be a question: “I found a 2023 byline that might be you — is that yours?”

Absent. You looked at the stack and the open web does not support the claim. Write that absence. Do not fill it.

Avoid a fourth label called “pretty sure.” Pretty sure is how parked becomes confirmed under calendar pressure. If you need more certainty, you need another URL or a question in the room — not a warmer adjective.

Share without laundering

Laundering is what happens when a parked claim loses its URL and its label in the next paste. Slack strips links. A CRM field strips dates. A hiring doc strips “not a background check.” Your job is to keep the citation attached or to drop the sentence.

When you share, include the confirm line, the URLs, and the labels. “Alex Chen, SF payments, 2025 latency talk [URL], title on program: staff engineer. VP claim: no first-party URL.” A teammate can take that call. “Alex is the VP, solid guy” is a different document and a different risk.

Do not share a public-web brief as if it were screening. Do not drop it into a packet that will be used for hire/no-hire. Verification of a talk is not a consumer report. If your organization needs a regulated file, they need a CRA and their own counsel — not a tighter checklist on this page. People search is not a background check is the companion essay.

OneSearch keeps citations on the page and follow-ups on the same person so sharing is less likely to strip the links. The method still applies if you export notes. The product page is people search.

Stop line

Stop speaking a sentence that failed the checklist. Stop merging a namesake to make verification easier. Stop using directory attributes to “complete” a quiet stack. Stop the whole workflow if someone is using the brief for eligibility.

Next reads: write the brief with only confirmed sentences, sit with quiet when the stack is empty, and refuse the wrong card in common-name collisions. For the product flow that attaches sources after confirm, see how it works.