How to Define a Candidate Discovery Hypothesis

Turn a vague sourcing assumption into a testable candidate discovery hypothesis with evidence thresholds, falsification checks and a clear next action.

How to Define a Candidate Discovery Hypothesis

When a search produces the wrong kind of candidates, changing the channel or adding keywords can hide the real problem: an untested assumption about where relevant people will appear and what their public evidence will look like.

A candidate discovery hypothesis is a narrow, testable claim about a search. It states the route, expected background, job-related supporting signal and observation that would weaken it. It is a test, not a candidate quota or hiring forecast.

Separate the claim from the evidence

Start with the assumption in plain language: "People who have done this type of work may be found through this route." Remove words that cannot be checked. "Great operators", "culture fit" and "top talent" are preferences until the role owner defines an observable, job-related signal.

Use this sentence pattern:

If we search [defined route] for [work background] in [approved scope], we expect [observable signal] to appear often enough to meet [team-set threshold]. The claim is weakened if [falsification check] occurs. We will then [next action].

The threshold belongs to the hiring team. It is a decision rule for this search, not a market benchmark. Set it before reviewing results so a plausible profile does not change the standard.

Define the test in six moves

1. Name one assumption

Choose one proposition, such as "reliability engineers with customer-facing API ownership may be discoverable without the exact title 'platform engineer'." Do not combine title, location, seniority and compensation assumptions. A claim that can fail for four reasons cannot tell you what to fix.

2. Describe the expected work signal

Write what a reviewer could point to: ownership of an on-call system, a documented migration, a shipped service or a responsibility stated in a professional profile. A keyword, employer prestige or title can be a lead, but is not automatically evidence of the work claimed.

3. Set evidence thresholds

Use explicit levels rather than an opaque pass/fail label:

  • Supported: the pre-set minimum number of reviewed records shows the defined signal, with no unresolved hard constraint.
  • Weakened: the signal appears, but below the minimum or only in an ambiguous form.
  • Inconclusive: the available sources do not show enough job-related detail to test the claim.
  • Contradicted: a defined disconfirming pattern appears, such as the route consistently producing a different kind of work.

"Inconclusive" matters. Missing public evidence is not proof that a person lacks the capability; it is a reason to verify, change the question or stop relying on that signal.

4. Predeclare the falsification check

Write down what would make you stop defending the idea: repeated records whose titles match but whose work does not, a hard location boundary the route cannot satisfy, or reviewers unable to agree whether the signal is present. A check should be observable and tied to one decision, not "the results feel weak".

5. Run a traceable review

Capture the route, review date, source, observed wording, interpretation, unknowns and decision. Keep duplicates together. Ask a subject-matter reviewer to examine borderline cases when the evidence rule is consequential. The purpose is to test the claim, not build a flattering list.

6. Choose the next action

If supported, keep the claim as an approved route and state what needs human verification. If weakened, revise one part and record why. If inconclusive, ask whether a person can verify the missing fact through a legitimate process. If contradicted, retire the claim and write the replacement question.

Candidate discovery hypothesis worksheet

Copy this table into the role record. Thresholds and names are for the team to set.

Worksheet fieldWhat to recordExample only
AssumptionOne statement about where relevant work may be foundAPI-reliability ownership may surface outside the platform-engineer title
Route and scopeApproved source, geography or other search boundaryPublic professional sources; Hong Kong or remote APAC
Expected signalWording or work artifact a reviewer can inspectDescribed ownership of production reliability or on-call systems
Evidence thresholdThe minimum that counts as support for this searchAt least 4 of the first 10 reviewed records show the signal; fictional rule, not a benchmark
Falsification checkThe observation that weakens or contradicts the claimFewer than 2 show job-related ownership, or the signal is title-only
Decision ownerPerson who can accept, revise or retire the claimRole owner with a technical reviewer
Next actionOne action for the resulting stateVerify, revise the work definition or retire the route
Review recordDate, source trace and unresolved questions2 September 2026; retain links and unknowns

Example: diagnose the failed assumption

Example only: suppose the team expects strong infrastructure candidates to use a familiar title. The first review set contains matching titles, but most descriptions list ticket handling rather than production ownership. The title assumption is weakened; adding title variations is not the immediate answer. Test the work signal, retain uncertain records for verification and ask whether production ownership is essential.

If relevant ownership appears under several titles, the claim is supported for this search. That does not establish interest, availability, authorship or job performance. It only says the discovery assumption is worth retaining while people responsible for contact and assessment do their work.

Failure analysis: what the result is telling you

Failure signalLikely problem with the hypothesisNext action
Titles match but work does notThe claim describes labels, not the required workRewrite the expected signal and re-review a bounded set
Signal appears only once and is vagueThe threshold or evidence definition is too generousMark it inconclusive and have the role owner clarify the evidence rule
Reviewers disagree repeatedlyThe signal is not operationally definedRecord the disagreement, calibrate the wording and rerun the test
Many records look relevant but violate a hard boundaryDiscovery may be working while the boundary is unresolvedEscalate the constraint to the role owner; do not infer a market conclusion
Sources repeat the same profilesThe observation is not independent coverageDeduplicate, record the limitation and decide whether another approved route is justified

Keep AI output inside the test boundary

Talent Summoner is our product for AI candidate sourcing, CV ranking and outreach you confirm before it sends. Its current candidate-sourcing workflow, checked 3 October 2026, starts with a role description, searches LinkedIn, GitHub and other public professional sources across 200M+ profiles, and returns ranked candidates against must-haves and nice-to-haves with plain-English reasoning. Use that output as a review set, but a rank is not evidence that the claim is true. People still inspect sources, verify material facts, contact candidates, interview and decide.

If you already have CVs, candidate ranking addresses a different question: how supplied documents compare with a job description. Keep it separate from a discovery test so a well-ranked pile is not mistaken for evidence about where new candidates can be found.

The ICO's recruitment-AI guidance, published 6 November 2024 and checked 2 September 2026, tells organisations to consider a DPIA, lawful basis, documented responsibilities, fairness and accuracy monitoring, transparency and minimum necessary personal information. This is general information, not legal advice; apply the rules for the organisation and jurisdiction. NIST describes its AI Risk Management Framework as voluntary guidance for incorporating trustworthiness into AI design, development, use and evaluation. Neither source turns a sourcing hypothesis into a hiring standard.

Next step

Write one assumption, observable signal, team-set threshold and falsification check in the worksheet. Name the decision owner, then start a candidate sourcing search or test existing material with candidate ranking. Record the result before changing the brief.

FAQ

What is a candidate discovery hypothesis?

A candidate discovery hypothesis is a testable claim about where a relevant background may appear and what job-related evidence should be visible. It is not a promise of candidate supply or a hiring result.

How many candidates should I review?

There is no universal number. Choose a reviewable set and a threshold the role owner can defend before the search starts. Any numeric worksheet rule should be treated as a local example, not a market benchmark.

What counts as evidence?

Evidence is a job-related statement or work signal that a reviewer can inspect and record. A title or keyword may guide discovery, but it does not by itself prove ownership, capability, interest or availability. Missing information remains unknown.

How do I falsify the hypothesis?

State the disconfirming pattern in advance, review the records consistently and compare the observation with the threshold. If the check occurs, weaken or retire the claim and write the next question instead of defending the original wording.

Can Talent Summoner validate my hypothesis?

No. Talent Summoner is our sourcing and ranking product. It can provide a role-based discovery set or organise supplied CVs, while people remain responsible for evidence review, verification, communication, interviews and the hiring decision. It is not an ATS or an automatic rejection system.


Talent Summoner product facts read from our live candidate sourcing and candidate ranking pages, verified 3 October 2026. We re-verify this page quarterly — tell us if something changed.

All Posts