Talent SummonerHow 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.
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 field | What to record | Example only |
|---|---|---|
| Assumption | One statement about where relevant work may be found | API-reliability ownership may surface outside the platform-engineer title |
| Route and scope | Approved source, geography or other search boundary | Public professional sources; Hong Kong or remote APAC |
| Expected signal | Wording or work artifact a reviewer can inspect | Described ownership of production reliability or on-call systems |
| Evidence threshold | The minimum that counts as support for this search | At least 4 of the first 10 reviewed records show the signal; fictional rule, not a benchmark |
| Falsification check | The observation that weakens or contradicts the claim | Fewer than 2 show job-related ownership, or the signal is title-only |
| Decision owner | Person who can accept, revise or retire the claim | Role owner with a technical reviewer |
| Next action | One action for the resulting state | Verify, revise the work definition or retire the route |
| Review record | Date, source trace and unresolved questions | 2 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 signal | Likely problem with the hypothesis | Next action |
|---|---|---|
| Titles match but work does not | The claim describes labels, not the required work | Rewrite the expected signal and re-review a bounded set |
| Signal appears only once and is vague | The threshold or evidence definition is too generous | Mark it inconclusive and have the role owner clarify the evidence rule |
| Reviewers disagree repeatedly | The signal is not operationally defined | Record the disagreement, calibrate the wording and rerun the test |
| Many records look relevant but violate a hard boundary | Discovery may be working while the boundary is unresolved | Escalate the constraint to the role owner; do not infer a market conclusion |
| Sources repeat the same profiles | The observation is not independent coverage | Deduplicate, record the limitation and decide whether another approved route is justified |
Keep AI output inside the test boundary
Talent Summoner is our product. Its current candidate-sourcing workflow, checked 2 September 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.
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.
