Direct answer
An AI-generated Boolean string is almost always syntactically valid and frequently semantically wrong. Valid syntax is the easy part; a language model will reliably balance your parentheses and quote your phrases. What it will not reliably do is know which of your terms are ambiguous on the platform you are about to run this on, which constraints cannot be expressed in a query at all, and which operators your target platform actually supports. Check those three things and you catch most of the damage.
Failure one: ambiguous tokens the model did not disambiguate
The canonical example in cleared recruiting is TS/SCI being treated as a technology token and pulled toward TypeScript, which silently poisons the entire result set. The same class of error covers Go, R, Spark, Beam, Flink, Storm, Rust and Swift. Scan the generated string for any term that is also a common word or a different technology, and confirm each one is paired with something that disambiguates it. If it is sitting alone in an OR group, it is doing harm.
Operating notes
- Valid syntax is not evidence the query searches for the right thing.
- Delete unretrievable constraints; they narrow without filtering.
- Confirm the dialect before judging the results.
- Beyond four AND groups, the rarest term is running your search.
- Read every exclusion and ask if a qualified person could have written it.
Failure two: unretrievable constraints rendered as query terms
Models will happily encode "7+ years experience", "currently open to new roles", "active clearance" or "willing to relocate" as query clauses. None of these are retrievable properties; they are at best strings somebody might have typed. Their presence narrows your result set to people who happened to use that phrasing, which is not the population you wanted. Delete them from the query and move them to screening.
Failure three: operators the target platform does not support
Boolean dialects differ substantially. A string written for one platform can fail silently on another, returning results that look plausible while the unsupported operator is ignored rather than raising an error. Proximity operators, wildcards, field prefixes and nesting depth all vary. Confirm the dialect before you judge the results, because a query that was silently rewritten is not the query you evaluated.
Failure four: over-constraint by AND stacking
The most common structural failure is a long chain of AND groups, each individually reasonable, which together describe a person who does not exist. Count the AND groups. Beyond four, assume the result set is being determined by the rarest term rather than by your actual requirement. Test by removing one group at a time and watching which removal changes the count most; that group is the one carrying your search.
Failure five: exclusions that remove the target
Generated exclusion lists are often copied from generic templates and include terms that appear in the profiles you want. Excluding "recruiter" is sensible until you are sourcing recruiting operations staff. Excluding "student" removes working professionals who mention mentoring students. Read every negative term and ask whether a qualified person could plausibly have written it.
Failure six: invented syntax and plausible nonsense
Models occasionally produce operators that do not exist on any platform, or field prefixes that look right and are not. These are easy to miss because they read as authoritative. If you do not recognise an operator, verify it in the platform documentation rather than assuming it is a feature you had not learned.
Failure seven: the string that was never the problem
Sometimes the generated query is fine and the search still fails, because the requirement cannot be met from the sources being searched. Regenerating the string cannot fix a source coverage problem. If three structurally different queries all return the same thin set, the constraint is the source, not the syntax, and the next move is to add a lane on a different surface.
A one-minute check you can run every time
Read the string aloud in plain English as a description of a person. If the sentence describes someone implausible, the query is over-constrained. Then scan for ambiguous tokens, unretrievable constraints, unfamiliar operators, and exclusions that could hit your target. Four passes, under a minute, and it catches the failures that silently waste an afternoon.
SourcingOS workflow
Boolean Doctor audits an existing string for these failure modes directly, including over-constraint and terms doing no work. BooleanOS generates platform-specific dialects with capability provenance, so you can see which operators are actually supported rather than discovering it from empty results. It also handles the ambiguous surface forms, including the TS/SCI collision, through an explicit lexicon rather than tokenisation guesswork.
Copy-paste starting strings
(TS/SCI OR "TS SCI" OR "Top Secret") AND (polygraph OR "full scope" OR CI) -TypeScript -"type script" -tutorial
("Go" OR Golang) AND (goroutine OR "go.mod" OR gRPC) -"go to market" -"on the go"(R OR "R programming") AND (CRAN OR ggplot OR tidyverse OR RStudio)
FAQ
Should I stop using AI to write Boolean?
No. Generation is genuinely faster than writing strings by hand. The check is what makes it safe, and the check takes far less time than the generation saves.
What is the single most damaging failure mode?
Ambiguous tokens left undisambiguated, because the query still runs and still returns results. Nothing signals that the result set is wrong, so the failure is invisible until someone notices the people are unrelated.
How do I know if a query is over-constrained or the market is thin?
Remove one AND group at a time and watch the result count. If a single removal changes it dramatically, the query was over-constrained. If nothing changes much, you are looking at a source coverage problem instead.
Keep reading in Boolean & queries
Query construction, operators, X-Ray patterns, and diagnosing a search that is returning the wrong people.