Direct answer
Most sourcing write-ups show the polished result. This one shows the working, including the parts that did not resolve. The role used throughout is illustrative and constructed for this article; the profiles, names and result counts are invented to demonstrate the method. Nothing here came from a real customer search or a real candidate.
The requirement, as received
The intake said: Senior Linux Systems Administrator, RHEL 8/9, Ansible automation, Annapolis Junction, active TS/SCI with polygraph, seven years experience. That is five constraints of very different kinds, and treating them as one filter is the first mistake available. Two of them are retrievable from public text, two are partially retrievable, and one is not retrievable at all.
Operating notes
- Sort requirements by retrievability before writing any query.
- Run separate lanes so you can see who only one lane finds.
- Record what each source can support, not one blended confidence.
- Unknown stays unknown; it is not a soft negative.
- Name the requirements that move to screening, in writing.
Sorting requirements by what can be retrieved
Before writing a query, sort every requirement into three buckets. Retrievable: RHEL and Ansible appear in public technical text often enough to search on. Partially retrievable: location appears, but as a self-reported label that may be stale or metro-level. Not retrievable: clearance status and years of experience. Clearance language appears in public text constantly, but its presence tells you someone wrote it, not that it is current or accurate, and it cannot be confirmed from any public source. Years of experience is a derived number that public profiles state inconsistently and often round generously.
Lane one: evidence-led retrieval
The first lane ignored titles entirely and searched the work. Terms that only appear when someone has actually administered Red Hat at scale: kickstart, satellite, systemd, SELinux, subscription-manager, yum and dnf repository management, kernel tuning. Paired with Ansible specifics such as playbook, inventory and role rather than the bare product name, which appears in every skills list. This lane produced a small, dense set. Illustratively, of twenty results, fourteen were plausibly the right kind of person.
Lane two: title-led retrieval
The second lane ran the title family, because evidence-led retrieval misses people who do the work but publish nothing about it. Systems Administrator, Systems Engineer, Infrastructure Engineer, Site Reliability Engineer, Platform Engineer, and Linux Administrator. This lane produced a much larger and much noisier set. The useful comparison is not which lane is better; it is which people appear in one lane and not the other, because those are the people a single-query search would have missed entirely.
Lane three: employer-led retrieval
The third lane searched the employers rather than the people. In a cleared market, the set of firms holding work at a given facility is small and largely public through contract award data. Sourcing against that employer list surfaces people whose public profiles say almost nothing technical, because their employer name is the strongest available signal. This lane produces the lowest evidence density and the highest strategic value.
What each source could actually prove
A public code host can show that someone wrote configuration in a given tool, with dates. A conference talk can show they explained a system publicly. An employer page can show a current affiliation as of the page date. A professional profile can show a self-asserted history that nobody verified. None of these prove tenure, seniority, clearance status, current availability, or willingness to move. Recording what each source can support, rather than collapsing everything into one confidence level, is the difference between a shortlist and a list.
Where the evidence ran out
For the illustrative shortlist, six people had strong technical evidence from at least two independent sources. Three of those six had no public location signal more precise than a metro label, which matters because the work is on-site at a specific facility. None of the six had clearance status that could be established from public text; several had clearance language on a profile, which is a discovery breadcrumb and nothing more. Two had no evidence of Ansible specifically, only of configuration management generally, which is an open question rather than a disqualification.
How the shortlist was assembled
The shortlist recorded, per person, which requirements were supported by evidence, which were contradicted, which were unknown, and what the strongest source was for each. Unknown stayed unknown; it was not downgraded into a soft negative. The contradictions stayed visible rather than being resolved silently in favour of the more convenient reading. The output handed to the hiring manager said explicitly which requirements were being carried into the screening conversation because no public source could settle them.
The calibration conversation this produces
A shortlist built this way changes what you can say in calibration. Instead of "the market is thin", you can say: this many people show the core technical evidence, this many are within the geography we can confirm, clearance is unverifiable from here for all of them, and the requirement that collapsed the pool fastest was the facility-level location constraint. That is a tradeoff conversation rather than a status update.
SourcingOS workflow
The JD Strategy Tool separates requirements into retrievable and non-retrievable before any query is written. BooleanOS builds the separate lanes so you can compare their yield rather than editing one string. Candidate Search keeps retrieval terms and candidate evidence structurally separate, so a term you searched for can never be recorded as something a candidate claimed.
Copy-paste starting strings
(kickstart OR satellite OR SELinux OR "subscription-manager") AND (ansible OR playbook) -tutorial -course
("Systems Engineer" OR "Infrastructure Engineer" OR "Site Reliability") AND (RHEL OR "Red Hat") AND (Odenton OR "Annapolis Junction" OR Hanover)site:*.com ("careers" OR "join our team") AND ("Annapolis Junction" OR "Fort Meade") AND (RHEL OR Linux)FAQ
Are the numbers in this walkthrough real?
No. The role, the profiles and every result count are constructed to demonstrate the method. They did not come from a real customer search, and presenting invented figures as customer outcomes is exactly what this article argues against.
Why run three lanes instead of one good query?
Because a single query cannot tell you what it missed. Running lanes that retrieve on different fields makes the people who appear in only one lane visible, and those are the people a single-string search silently loses.
What do I do about requirements that cannot be retrieved?
Move them to the screening conversation and say so explicitly in calibration. A requirement that no public source can settle is not a search problem to solve; it is a verification step to schedule.
Keep reading in Search strategy
Turning a req into lanes, titles, donor companies, and a plan you can defend in calibration.