The Saved-Search Port Playbook: Boolean String to Proven Plain-English Query

This playbook moves your saved Boolean strings and X-ray templates onto plain-English search one string at a time, and it proves each move before anything gets deleted. It is for sourcers, sourcing leads and founders whose saved searches have started returning less now that LinkedIn and the web search engines use semantic retrieval. Every string ends with a dated verdict backed by two numbers a hiring manager can check: recall against a gold set of known-right people, and precision on the top 25.

Why do saved Boolean strings fail without telling you?

Saved strings rarely break with an error. The engines drop operators, parameters and search modes without telling anyone, so the string keeps running and returns fewer or different people. The only reliable alarm is to check the results against people you already know it should find.

The web search engines have a long record of this:

• Google removed the + operator and told users to put quotation marks around a single word instead.
• The &num=100 parameter stopped working with no notice. A Google spokesperson said it was "not formally supported." Templates that relied on it now return 10 results.
• The cache: operator is gone, but sources disagree on when it was removed.
• Google's "Refine web searches" page documents only six operators: exact-match quotes, site:, the minus sign, before:, after: and filetype:. Everything else in common use is undocumented, including inurl:, intitle:, intext:, ext: and the numeric range. AROUND(n) was never documented and is widely described as unreliable. Sources disagree on whether OR counts as documented.

LinkedIn has moved too:

• Recruiter's AI-Assisted Search is now the default for English-speaking Recruiter customers.
• Member people search has moved to AI search in the US, starting with Premium users.
• LinkedIn says it is gradually retiring its classic job search.
• Some Boolean still works, with limits:
  • LinkedIn says the + and - operators are not officially supported.
  • Stop words are ignored in the Keywords field.
  • The Recruiter Project filter does not support Boolean at all.
  • Sales Navigator caps a search at 15 operators. Recruiter has no cap.

So when people complain that Boolean search is not working on LinkedIn's semantic search, they are usually wrong about the cause. The search is working, but it is answering a different question from the one your string was written for. The easy mistake is to translate each retired operator into an AI prompt and assume the two are equivalent. That keeps the same false confidence: a string or a prompt that returns fewer people without an error looks fine until you check who is missing.

A saved string that returns fewer people without an error has not survived. It is failing quietly.

How to sort a saved string: platform-dependent or portable

A platform-dependent string runs inside one product's syntax, such as LinkedIn Recruiter, Sales Navigator or a Project filter. That is the kind that needs a plain-English rewrite. A portable string runs on Google, Bing or GitHub, and it can often stay Boolean once you remove its dead syntax.

Sorting takes about 5 minutes per string. Record each string's type and list every operator it uses. Then spend about 10 minutes giving it one of three labels:

• Valid: every operator is documented and behaves as written.
• Degraded: the string runs but depends on something undocumented or unsupported, so part of its logic may be ignored.
• Broken: the string depends on something that has been removed, so it returns less than it was built to.

I did not check Bing's operators for this guide. If your library runs on Bing, test each operator against a page you know exists before you label the string.

Three syntax faults fail without any message:

1. Lowercase operators.
2. Smart quotes pasted in from a document.
3. Stop words in LinkedIn's Keywords field.

Quoting matters more than it looks. In one published test, the unquoted phrase tech recruiter returned 395,000 LinkedIn results, against 73,000 with quotes. Before labelling any string, paste it into a plain-text editor, then compare result counts with and without the element you suspect.

No public, dated list shows which LinkedIn profile fields have been removed from search-engine indexes. What LinkedIn does document is member control. Members can switch their public profile visibility off and can hide individual sections. LinkedIn also notes that some search engines can take several weeks to remove old profiles or show new information. So the only honest way to find which X-ray operators still work against LinkedIn profiles is to test locally. Open a gold-set member's public profile while logged out and confirm that the field your template targets is actually visible.

How to build a gold set for one saved search

A gold set is 20 to 30 people that you and the hiring manager agree the search must find. Draw them from past hires and finalists for the role the string serves, and give each one a confirmed profile URL and a written reason they were right. Budget 1 to 2 hours. This is the step that turns a matter of taste into a measurement.

The size is my working choice, not a published standard. Research benchmarks run much larger:

• The Mira-Embeddings paper tested 300 job descriptions with about 200 candidates each.
• RecruitBench's test split holds 470 resume-job pairs across 18 jobs.
• Another paper used 12 to 22 jobs and flagged its own sample as small.

By those standards, 20 to 30 people per string is small. It is enough to catch a person who dropped out and name the reason. It is not enough to claim that a small percentage difference is real. With 25 people, each person is worth 4 points of recall, which keeps the arithmetic easy to check.

Record these fields for each person:

• Name and confirmed profile URL.
• Hire or finalist, and the date.
• A one-line reason they were right, in the hiring manager's words.
• How they were originally found: this saved string, another string, a referral, inbound, or another tool.
• Whether their public profile is visible when you are logged out.

The "how found" field guards against gold-set leakage. If most finalists were originally found by the old string, the test favours Boolean, because the gold set is a picture of what that string could already see. Aim for a mix of sources, and report the split alongside the verdict.

How to convert a Boolean string to a natural-language search

Keep at most two hard requirements and rewrite every other AND clause as a stated preference. Put location and seniority into structured filters instead of prose, and when a title is shared with another profession, name the wrong profession explicitly. The rewrite takes about 15 minutes and is done when the hard requirements and the preferences are listed separately.

The two-requirement cap comes from first-run data. In one sourcing platform's published data, searches that opened with more hard requirements came back empty far more often, and with much smaller pools. The vendor did not publish its method, so treat the size of the effect as a pointer, not an exact figure.

From those figures, the higher-requirement searches were 2.9 times as likely to return nothing, and their median pool was 7.7 times smaller. They were also 1.6 times as likely to need three or more refinements. In the same data, hard-requiring one skill returned zero results 14.8% of the time, against 6.8% with no hard gates, and requiring a degree returned zero 17.1% of the time.

The gates recruiters remove when they refine a search are also telling. School filters were dropped in 32.7% of refinements, and degree requirements in 21.5%. The gates people add first are often the ones they abandon first.

What a hard gate costs, measured

Refolk's index shows how this works. A gate only matches people who filled in that field, so recall falls with how complete profiles are, not with who is qualified.

The size of the market makes this worse. The US title pool in Refolk's index is 11.7 times the UK pool of 421, so the same gate applied in the UK far more often leaves a pool too small to rank. If a gate has to stay, check that every gold-set person actually shows the gated field.

Titles carry their ambiguity into plain English

Semantic search widens synonyms, so a title shared by two professions brings in both. "Sourcing Specialist" is a recruiting title and also a procurement title. In Refolk's UK sample of 25, four people were off-target: a Procurement Specialist, a Billing Administrator, a Professional Services Category Lead and a CEO. That gives 84% precision. The fix is to say what you do not want in the sentence itself, then check that it worked by reading employer names. Nobody has publicly counted how often semantic engines ignore a quoted phrase or read NOT as a keyword, so verify each exclusion yourself.

STRING ID:
ORIGINAL STRING (pasted from a plain-text editor):
TYPE: platform-dependent / portable
SYNTAX LABEL: valid / degraded / broken
OPERATORS USED:

HARD REQUIREMENTS (no more than 2):
1.
2.
PREFERENCES (everything else that used to be AND):
-
-
STRUCTURED FILTERS:
Location:
Seniority:
EXCLUDE (profession that shares the title):

PLAIN-ENGLISH QUERY:
Example: Talent sourcers in London who recruit software engineers, not procurement or buying roles

This is where Refolk saves a step. You type the plain-English sentence, exclusion clause included, and that sentence is the search. It runs across GitHub, LinkedIn and the open web, so you can test the platform version and the portable version of a string against the same gold set from one sentence.

The port procedure, string by string

The procedure has eight steps, run in order. The first string for a role takes roughly three to four hours because it includes building the gold set. Each further string for the same role reuses that gold set and takes under two hours.

These rules keep the steps honest:

• Same day, same seat, same mode for both queries. Results move over time, so a test spread across days measures drift, not the queries.
• Save the full result count as well as the top 25. A count that collapses is your early warning of a gate fault or a syntax fault.
• Run the new query twice. The same plain-English phrase can return slightly different results across sessions.
• Log any automatic widening as a separate query. In one published benchmark of AI sourcing tools, LinkedIn's "Enhance" button was clicked up to three times when a search returned nothing. A result produced after enhancement comes from a different query.

How to score recall and precision for an AI sourcing search

Recall is the number of gold-set people found divided by the size of the gold set. Precision is the number of relevant results in the top 25 divided by 25. Score the old and new queries the same way on the same day, and judge relevance from a pooled, blind list. Budget about 45 minutes.

These are the standard measures from retrieval research, as defined in the Mira-Embeddings paper. Recall@K is the share of known-right candidates that appear in the top K results. Precision@K is that overlap divided by K. Recall comes first, because "the cost of a false negative (missing a qualified candidate) outweighs the cost of a false positive." A noisy top 25 costs a few minutes of reading. A missed finalist can cost you the hire.

Before you test, set how deep counts as "found": the number of results you would actually work through for this role. Use the same depth for both queries and write it in the log. A gold-set person sitting at result 400 is not found if nobody reads past 100.

To judge precision fairly, judge both lists together:

1. Merge the two top 25s and remove duplicates.
2. Strip any label showing which query found whom, and shuffle the list.
3. Have the hiring manager or a second sourcer mark each person relevant or not.
4. Reveal which query found whom only after the marks are in.

Pooling matters because judging only one tool's results tilts the numbers. On the TREC-COVID benchmark, 30.6% of the semantic retriever DPR's top-10 results had never been judged, against 6.4% for the keyword method BM25. Results nobody judged get counted as misses or quietly ignored, and either way the comparison skews.

A worked precision read from Refolk's index

The same title query shows how precision and recall pull against each other. One caution first: these samples of 25 were not ranked by relevance, so they show what a slice of the pool looks like, not a true top-25 precision.

The skill gate also changed who came back:

Without the gate, the US sample included at least a Senior Buyer and a Head of Cyber Exercises. With the gate, Meta (4) and NVIDIA (2) became the top employers, and the sample looks clean. But that same gate kept only 13.5% of the pool. A query can look excellent on precision while losing most of the people you would hire, so you need both numbers, scored against a gold set.

How a port test goes wrong

Most bad verdicts come from eight repeatable errors, and each one has a cheap check. For each, here is what it looks like and how to catch it before it reaches the verdict log.

1. Ambiguous titles. A title shared by two professions brings in the wrong one. "Sourcing Specialist" matches procurement roles, which is how the UK sample lost 16 points of precision. Looks like: plausible titles at unfamiliar employers. Check: read the employer names. A name like Bloom Procurement Services settles it.
2. Hard gates hide real people. The Recruiting skill gate cut 86.5% of the pool, including real sourcers who never listed that skill. Looks like: high precision with a small pool. Check: confirm every gold-set person actually shows the gated field. If one does not, the gate is costing you recall.
3. Treating absence as proof. A bare site: search will not list every page, and a gold-set person may have switched public visibility off. Looks like: the same person missed by both queries. Check: open their public URL while logged out. If you cannot see the profile, the miss belongs to visibility, not to either query.
4. Results that cannot be repeated. AI results change from session to session. Looks like: a person found once and gone on the re-run. Check: run the new query twice and score only the people who appear in both runs.
5. Pooling bias. Judging only one tool's top 25 inflates its precision, which is what the TREC-COVID judgement gaps show. Looks like: the tool you built the judgements around always wins. Check: pool both top 25s and judge them blind.
6. Silent syntax failure. Lowercase operators, smart quotes and stop words all fail with no error. Looks like: an old string whose count fell with no change in the market. Check: paste the string into a plain-text editor, retype the quotes, uppercase the operators and compare result counts.
7. Dead parameters. Templates that still use &num=100 return 10 results. Looks like: an X-ray template that always stops at the same small number. Check: count the results actually returned.
8. Gold-set leakage. If the finalists were originally found by the old string, the test favours Boolean. Looks like: the old string scoring perfect recall. Check: label each gold-set person by how they were found, and report the old string's recall on the people it did not originally find.

Two gaps in the public evidence are worth stating plainly. Nobody has published how often semantic engines ignore quotes or read NOT as a keyword. LinkedIn's character caps are unofficial too, and sources disagree on them. Test both on your own seat and don't rely on a number you read somewhere.

Logging the verdict and keeping it current

Every string ends with one of three dated verdicts: retire it, run both, or keep it as Boolean for the open web. Each verdict records both scores, the seat, the search mode and a re-test trigger. Re-test whenever the platform changes its search.

My rules for the three verdicts:

• Retire: the new query finds every gold-set person the old one found, or each difference traces to a cause outside the query, such as visibility switched off. Pooled precision is no worse.
• Run both: the new query misses someone the old one found, for a reason inside the query that one more rewrite cannot fix. This often happens with niche titles.
• Keep as Boolean for the open web: the string is portable (X-ray or GitHub), it is labelled valid after cleanup, and the people it serves mostly live outside the platforms that have gone semantic.

Practitioner sources disagree on the order of work. One says to run AI search first and check it with Boolean afterwards. Another says to keep Boolean in reserve for niche titles. The gold set settles this for each string, which is why the verdict belongs to the string and not to the team. For strings you keep as Boolean, Refolk can run the plain-English version across the public GitHub graph and the open web as a second check against the same gold set.

STRING ID:
DATE TESTED:
SEAT AND SEARCH MODE:
PLATFORM:
RESULT DEPTH COUNTED AS FOUND:

GOLD SET: __ people (hires __, finalists __, originally found by this string __)

OLD QUERY:  recall __ / __   precision __ / 25   full result count __
NEW QUERY (people in both runs only):  recall __ / __   precision __ / 25   full result count __

MISSES (one cause each: ambiguous title, hard gate, not visible, unstable result, silent syntax, dead parameter, pooling, leakage):
- name, URL :: cause :: evidence

VERDICT: RETIRE / RUN BOTH / KEEP AS BOOLEAN FOR THE OPEN WEB
RE-TEST TRIGGER:
SIGNED OFF BY (hiring manager):

An audit of saved Boolean searches is never finished, because the engines keep changing. Re-test a string when any of these happens:

• The platform announces a change to search, or the seat's default search mode changes.
• A string's full result count moves sharply with no market reason.
• The role gains new hires or finalists, which means the gold set should grow.
• The role moves to a smaller market, where the same gate is more likely to leave a pool too small to rank.