How people search finds and orders results

Signed in? Ask Lovelio this question inside the app - it answers from this same page.

How do I turn search learning on or off?

Search learning is how Lovelio improves search across agencies. It does not change how your own searches rank today. Lovelio tests changes before it uses them and rolls back any that make search worse.

Go to Settings > Workspace > Search learning. Only a System Admin can read or change it. Others see an error.
Tick or untick "Contribute to shared search improvements". It is on by default.
Click Save changes. The page says "Search learning settings saved."

What stays private: your searches, your candidate records and their evidence stay in your region. Only grouped performance measures contribute. Background checks use your existing AI spending limits. Turning it off removes your learning history and shared contributions. Your normal search and your saved candidate evidence still work. Shared title knowledge only covers exact matches to public vocabulary entries, and needs independent agencies to agree before release.

Jev search and shared learning

When Jev is connected, eligible people searches use reusable evidence checks through the same search engine. New searches use the standard interpreter unless an approved Jev interpretation is already cached for that agency. Every natural-language search entry point can reuse that cache without another interpretation call. Refinements and longer briefs keep their standard interpretation path. The private comparison can try a single-call Jev interpreter on uncached common queries. Code checks the complete interpretation; ambiguous, unsupported or failed attempts fall back to the standard interpreter. A wider rollout needs measured gains. If Jev cannot read a CV (for example while its provider is out of action), people searches read that CV with the standard reader instead, so the search still answers.

Roles, locations, dates and numerical constraints retain database rules. Candidate evidence and sourced employer knowledge can establish a sector relationship only within the same employment. A company name or using a SaaS tool does not establish SaaS sales. Degrees and professional qualifications require completion evidence. Count-only checks, potential searches and saved-evidence checks keep their existing execution paths.

New requirements can take longer on their first search. Checks save their source evidence and refresh when the CV, employment or employer knowledge changes. Lovelio checks CVs only while a search runs; it does not check them ahead of time in the background. Uncertain or unread evidence remains distinguishable from confirmed matches. Candidate-authored documents remain unchanged. Both paths retain the shared deterministic ranking formula and existing ranking providers.

Settings > Workspace > Search learning lets a System Admin control participation. Private searches, candidate records and evidence stay in the agency region. Grouped performance measures help test improvements across agencies. Shared title knowledge only covers exact matches to supported public vocabulary entries. Private titles and queries do not become a shared dictionary. Public title classifications need independent agency and regional agreement before release. Search changes need independent agency checks, later searches and labelled examples before wider use; regressions trigger rollback. Turning participation off removes private learning history and shared contributions. Jev model weights do not retrain themselves.

The private comparison at /candidates/lightning remains available to the pilot owner. Each column interprets the same query and searches the same authorized records. It shows interpretation time, search time, AI cost, evidence, uncertainty and result differences. Different interpretations are labelled and cannot qualify as speed or cost wins. Measurements from an older parser remain visible, but do not establish that the current parser meets its targets. Initial preparation and refresh costs appear separately in AI usage. The platform Search learning report at /admin/usage/search-learning shows evaluations, release decisions and regional worker health. Daily summaries cover the previous complete UTC day after 06:00 UTC. Weekly engineering briefs compare seven complete days with the preceding seven. Lovelio proposes investigations and code changes from aggregate evidence; Jev checks whether their explanations match the cited findings. Every proposal needs human assessment. Admins can copy a prompt for Codex or Claude Code, and the platform owner can generate a weekly brief on demand. Review spending is capped at $1 total per UTC day, with at most one paid attempt per day; refresh does not buy inference. Pauses, failed reviews, missing evidence and unknown costs are shown explicitly. This feature does not create projects, change code or prove precision and recall. Counts include only participating agency/day cohorts with at least five logged searches or learning observations, and search logs do not cover every entry point. Sub-second searches, lower total costs and improved accuracy remain unproven acceptance targets. The limited synthetic parser trials do not establish those outcomes on production searches.

How people search finds and orders results

Every search does the same four things, whether the user types a sentence or presses match on a job:

Understand. The interpreter reads the sentence and turns it into search chips. Separate evidence checks can read CVs against those requirements. The AI never decides the order; a fixed formula does.
Filter. Must-have chips work like a strict door. Only candidates who pass every must-have get in. The count shows confirmed matches. When a requirement needs CV reading, the reading budget limits that count; the search also reports unread candidates.
Rank. Everyone through the door is scored out of 100 by a fixed formula. The same search gives the same order every time - no randomness, and no AI writes the score.
Explain. Every result shows its working: the score, its breakdown, and where each match was found. The reasons on screen are the real reasons.

The one rule that answers most questions: must-haves decide who is IN the list. Everything else only decides the ORDER.

A longer brief reads back before it runs

Type a proper brief instead of a short search - several sentences, or open language like "ideally", "a generalist, not a specialist", "even if they have not done it" - and Lovelio reads it back before running anything: one or two plain sentences saying what it understood, then a single Search button. Nothing runs until that button is clicked, so nothing is wasted on a misread. A short, filter-shaped search ("consultants at Bain in Sydney") skips this and runs straight away, same as always.

The readback is not a summary of the chips - it says the same thing the chips say, in a sentence, so a wrong reading is obvious before it costs a search. Editing a chip while the readback is showing updates the reading in place; it does not run anything either. Only pressing Search runs it.

Potential asks: "who could grow into this", not "who has done it"

Some asks are not filters. "People who might be a good fit for a D365 consulting role, even if they do not have that experience" or "someone to train into a go-to-market role; they do not need a GTM role but must have done the right things before it" are asks about potential. The tells are "even if", "does not have to have", "could be trained", "would make a good", "might be a good fit".

Lovelio reads these differently. Instead of chips that filter, it writes a checklist: 4 to 8 things a strong candidate for that role would have done or shown (has led enterprise accounts, has sold to CIOs, has launched a product, worked in robotics). The readback says so in plain words - "Nobody has to have done D365 consulting. I will look for people who have shown these things and rank by how many they have." - and lists the checklist under the ask, one item per line. Click an item to change or remove it, then press Search.

Nobody is excluded for missing an item. The order is how many items each person has shown and how strongly: a match in their record counts more than a matching CV line. Lovelio also reads the 200 likeliest CVs against the checklist, so a result card can say "has led enterprise accounts (CV line), has sold to CIOs, no robotics" for each person. The target role itself is never a requirement - it is what they have not done yet.

People like these: search from several people at once

"Here are three people who did well at my client, find me the twenty closest in our database" is one search. Lovelio builds it from the people you give it, three ways that all land in the same place: pick people already in Lovelio (select them on the People page and choose Find people like these, or open "similar to" from any record), paste the text of each profile into the search box (Lovelio splits a paste into its people and reads each one), or capture people with the Chrome extension and then pick them. Up to 10 people at a time.

Lovelio never opens LinkedIn or any other website. Paste a LinkedIn address with no profile text and it says so and asks for the text or the people. The extension only reads the page you are looking at; nothing in Lovelio fetches a profile.

Before anything runs, the search reads back: "These three have in common: consulting, senior, Sydney. I will rank everyone by closeness to that." Each thing they share is an underlined phrase you can click to change or drop, the people are listed with a way to add or remove one, and the number to show (20 by default, up to 100) is a box in the sentence. Nothing runs until Search.

What the people share is worked out on paper: the same reader that turns one profile into chips reads each person, and only what EVERY person has survives (a title family, an industry, a level, a skill, a degree, an employer, a place). Shared facts are always nice-to-have: they lift people up the order and never filter anyone out, so a shared city does not hide the perfect person one suburb over. Make one a must-have yourself if it is a deal-breaker. Then everyone is ranked by a fixed formula built around closeness to the people you gave: closeness of profile 50%, shared facts hit 20%, role fit 6%, doing it now 4%, distance 5%, quality of proof 5%, freshness 4%, ready to move 3%, likely to move 3%. No AI orders the list. The people you gave are left out of their own results. A person with no readable profile yet still counts for the shared facts; the closeness part uses whoever could be read.

Chip strengths

Must have blocks people out. Skills, roles and locations the user names become must-haves. Fail one and you do not appear.
Nice to have moves people up. Words like "ideally", "preferably", "bonus" make a chip nice-to-have. Missing it never removes anyone.
Must not removes people we can PROVE match. "Not in Sydney" keeps someone with no location on record, because we cannot prove they are in Sydney.
No data yet (grey chip): asked for something Lovelio does not hold (age, gender, email replies). It does nothing and says so.

Each chip also carries a small tag naming WHAT it checks - COMPANY (employer name, whole-word), COMPANY NOW (current employer only), INDUSTRY, ROLE, EXACT TITLE (see below), SKILL, LOCATION, TEXT MATCH (raw CV text), and so on. If the AI misread the sentence, the tag makes it obvious: a chip tagged COMPANY that is not actually a company name is a misread - click its x and it is gone. Search terms check skills, titles, employers, locations, the CV and the profile - never a person's name or email, so searching the skill "Amber" does not return people named Amber. A person's name is its own chip, tagged NAME, and names come first: "John Smith" finds the people called John Smith, never everyone whose CV mentions a John or a Smith, and never a referee or an old manager named in a CV. It reads the name on the record only: every word you type starts a word of their name, in any order ("smith john" works, so does "jean-luc"), a common nickname finds the full name and back ("Bob" finds Robert, "Liz" finds Elizabeth, "James" finds Jim, but "Bob" never finds Roberta), or it is a close spelling ("Jon Smyth"). Accents never matter: "zoe" finds Zoë and "soren" finds Søren. The exact name ranks first, then names starting with what you typed, then nicknames, then close spellings. When a common name matches more people than search can rank at once, the closest names are ranked and, within each, the people you were most recently in touch with come first, then people with a current employer; Heads up says so. A name mixes with anything else: "Priya the Java developer in Sydney" is a NAME chip plus a skill and a place, and "Sarah from Atlassian" is a NAME chip plus an employer. "named Baker" or "called Baker" is always a name. A single word that could be a name or something else ("Baker", "Sydney") is read from the rest of the sentence; on its own, search answers the job, skill or place and shows "Also 4 people named Baker" above the results (on the People page, in Ask Lovelio and in the API). Click it to switch to the name; search never quietly picks one reading. An email address is its own chip, tagged EMAIL: "brettiredale@gmail.com", "whose email contains smith" or "anyone on a gmail.com address" checks the email field on the record, whole or in part. A phone number is its own chip too, tagged PHONE: paste "+64 22 160 5274", "022 160 5274" or "whose phone ends in 605274" and it checks the phone on the record, ignoring spaces, dashes and the country code.

Searching a specific tool is exact by design: "Salesforce consultants" hard-filters to people with real Salesforce evidence. It never widens to other CRMs (Oracle, HubSpot, Zoho). The only stretch is known nicknames from the dictionary, like SFDC for Salesforce - and when a nickname made the match, the result says so ("via alias SFDC"). The dictionary can link a new word to an existing skill; it can never invent an equivalence.

Roles: which titles count, and when

A role chip answers two questions: which jobs count, and which titles count. Its tag tells you both: ROLE LAST 5 JOBS, ROLE NOW, ROLE EVER, and the same three for EXACT TITLE. The Showing: line under the count says it in words, one pill per fact: "Current or last 5 jobs", "Business Development Manager or equivalent", "Within 25km of Sydney".

Which jobs: a bare title reads their last 5 jobs, the current one included. "Business development managers in Sydney" finds people who are a BDM now or were one in any of their last 5 jobs, so a BDM who moved into an Account Director role last year is still found. On a real agency book that search found 14 people reading today's title only and 58 reading just the last 3 jobs. When someone matched through a past job, the results show it in grey under their current job ("Business Development Manager, 2021 to 2024"). Say "currently" or "now" for today's title only ("consultants currently at Bain"), and say so to reach the whole career: "has been a BDM", "was a Sales Manager", "ex-consultants" and "used to be a nurse" count every title they have ever held.

A discipline ask means the people who do the work. "SEO specialists", "Salesforce consultants", "PPC people", "SAP experts" are asks about a skill, not a title, so the skill is the requirement and the title is a preference. "SEO specialists in Sydney" finds everyone in Sydney who does search engine optimisation, whatever they are called - a Growth Marketing Manager who runs SEO every day is in. People with SEO in their current title rank first, because the title is the second weighting, never the gate. Common acronyms are read as what they stand for (SEO, PPC, SFDC, CPA), and UK and US spellings are one skill: "optimisation" and "optimization" find the same people. If you really do want only the title, say so: "people titled SEO specialist". A function word keeps the title as a requirement: "Python developers" are developers who know Python, "marketing managers" are marketing managers.

"Or" means or. "VP of Sales or Chief Revenue Officer in Australia" is one role chip that matches either title, and "product marketing managers in Australia or New Zealand" is one location chip that matches either country. The chip reads "A or B" and the search sentence names every alternative. Only the words you typed filter; an equivalent Lovelio adds on its own can lift someone up the list but never adds or removes anyone. A place typed with its region or country is one place: "Perth, Australia" and "Perth, WA" both mean Perth. "Sydney, Melbourne" and "Australia, New Zealand" are two places.

Which titles: the title or equivalent. Lovelio reads every title as a function, a level and sometimes a specialism, and keeps that reading in one shared list. "Account executives" is a sales role at executive level, so Business Development Managers and Account Managers count: same function, same level. Sales Managers do not - they run a team, which is a level up, and levels are a wall, not a range. A title Lovelio has not read with confidence only orders the results and never decides who is in; nobody is asked to confirm it. Rank words on their own ("Director", "Partner", "Consultant") are recorded as having no single function, and those people are read from their employer, skills and history instead. The term itself still matches anywhere in a title, so "consultant" finds Senior Consultants and Management Consultants too. A role checks their job titles and their listed skills - never the body of the CV, and never the occupation dictionaries that once turned "demand generation manager" into "power plant manager".

Sometimes you want the title and nothing broader. Say so in the search and the chip tightens: "titled exactly Consultant", "only Consultant", "just Consultant", ="Consultant". Now only people whose whole job title IS Consultant match - Senior Consultant and Associate Consultant are out, and so are the equivalents that would normally count. "Exactly" also means the title they hold today, when you type it: "titled exactly Sales Manager in Australia" is the 17 people who are Sales Managers now, not the 13 who were one years ago. Reach into the past by saying so, as with any role: "was exactly a Consultant at Bain" is exact and ever.

The two are independent. "Consultants at Bain" is or-equivalent and the last 5 jobs. "Titled exactly Consultant at Bain" is exact and now. "Anyone who has been exactly a Consultant" is exact and ever. The chip tag and the Showing line always say which combination is running.

The search sentence is the control. Click the result count and the sentence you typed appears with every load-bearing phrase underlined. Click a role phrase and it offers two groups. Which jobs count: "Their current job only", "Current or last 5 jobs" (the default) or "Any job they have ever held". Which titles count: "Business Development Manager or equivalent" or "Only Business Development Manager". Each row shows how many people it would find, and the ones running are ticked; picking one group keeps your choice in the other. Then "Drop this requirement". Below those sits every alternative you typed ("VP of Sales or Chief Revenue Officer") and every equivalent Lovelio added on its own ("also counts: CRO"), each with its own line to take it off. Taking off an alternative you typed changes who is found and shows the new count; taking off an added equivalent only changes the order, because an added equivalent never filters.

You never have to remember the wording. When a search's results contain longer titles carrying your role word, a + only exactly X button appears in the Refine row under the count. One click tightens the chip you already have. On a real agency book, "consultants currently at Bain" went from 62 people to the 28 actually titled Consultant.

"Currently at X" is stricter than it looks, and the Refine row says by how much

Saying "currently at Woolworths" means Woolworths is their job today, not that they have Woolworths on their CV. That is usually what you want and it is always fewer people than you expect. On a real agency book: 96 people have Woolworths as their current job, 193 worked there at some point, and 220 mention it somewhere in a CV.

So whenever a search carries a "currently at X" requirement and dropping the word would find more people, a + ever at X (51) button appears in the Refine row. The number on it is a real count, run against the same filters - not an estimate - so you can see what "currently" is costing you before you decide. One click swaps the chip from "Currently at X" to "Worked at X" and re-runs. Nothing is re-interpreted: you get exactly the number the button showed.

A title that finds nobody offers the people who do the work

"SEO specialists" means the people who do SEO, not only the people titled for it, so it normally runs as the skill SEO (required) plus the title as a preference: people titled SEO specialist rank first, and someone titled Growth Marketer who does search engine optimisation every day is still in. When a search does carry the title as a hard requirement ("titled SEO specialists", or a search saved before this rule) and that title finds nobody, the empty page says so in plain words: Nobody has an SEO specialist title right now. Did you mean: and offers People who do SEO with the real count (164) against the rest of your search. One click makes the switch: SEO becomes a required skill, with its spelled-out forms, and the title stays as a preference so titled people still rank first. It is only offered when the work reading actually finds someone. A title with no discipline in front of a generic word (developer, theatre nurse, SEO copywriter) is a job, not a discipline, and never gets the switch.

This is the usual reason a Lovelio count looks smaller than a keyword search elsewhere. A keyword tool matches the word "Woolworths" anywhere on the record, so it counts people who left in 2019 and people whose CV only mentions the company. Lovelio holds you to the question you asked, and puts the wider question next to it as a button.

Running it again, or starting fresh

On the candidates page your search shows as the sentence you typed, with the load-bearing phrases underlined. Click one to change it: a place offers wider and tighter distances, a role shows which job titles it matched, and every requirement can be softened to a preference ("preferred, instead of required") or dropped. Each option shows how many people it would find, so you can see what a change costs before you make it - those counts appear a moment after the options do. Anything the sentence did not name but the search still used is added to the end in grey, so the sentence always describes the whole search.

To run something different, type over the box. To re-run the same search against candidates added since, edit any requirement and put it back, or just search again - there is no separate refresh button, because editing anything re-runs the search on the spot. On the job-match panel the requirements still show as chips.

Lovelio reads your search while you type

On the People page Lovelio starts reading your search as soon as you pause typing, so the results arrive sooner after you press Enter. Nothing runs and nothing on screen changes until you press Enter. A follow-up typed on top of a search is read together with the requirements already on screen.

What a search can filter on

Skill, role, seniority (the level of their current job title: senior, head of, director, VP; the CV text is never read for this, so "senior" finds people who are senior today, not everyone who once wrote the word), location (a place, or a named country group: Commonwealth countries, APAC, the EU, English-speaking countries, and the others in the search guide, each a fixed list), employer (current vs past are different asks; "2+ years at McKinsey" checks time at that company from real employment dates, and company names match whole-word so "BCG" finds "BCG X (Boston Consulting Group)"), industry (checked against employer knowledge and, for eligible Jev searches, original CV evidence tied to the relevant employment: "worked at a SaaS company" is any job at a company Lovelio places in SaaS, "currently in fintech" is their job today; "5 years in fintech" adds up the dated jobs in that industry, counting overlapping jobs once, and a job with no start date never counts toward it; words around the industry that say which part of it a company plays are read too, so "commercial insurance broking" and "insurance brokers" both mean insurance, while a word Lovelio does not know keeps the phrase to its exact words, so "insurance software" is not the insurance industry; every industry you type in a list ("from property, cars or logistics") filters, never only the first; space is its own industry (rockets, satellites, launch), never office space or "the fintech space"; car dealers are automotive, never retail; named groups like Big 4, magic circle, ASX 200 and FAANG work the same way; "companies like Technology One" means the same industry, about the same size and the same home country, with the companies that counted listed so you can take one out with "but not X"; a company name or a passing CV mention alone does not prove industry experience), years of experience (only dated jobs count), time in current role, salary expectation, notice period or available-from date, work rights, open to work, the 1-5 star rating ("5 star candidates", "rated 4 and up" - unrated candidates never match), stated preferences (work types like "open to contract", wanted roles like "wants a Head of Sales role", wanted locations like "wants to move to Sydney", open to relocation), contact history (contacted / emailed / called), process history (interviewed / submitted / placed / in process), history with a NAMED client ("sales people we have not sent to Acme yet", "who have we placed at Meridian Group" - who you SENT them to, which is a different question from where they have worked), talent pool, tags (say tag or label: "consultants tagged ex-McKinsey"), source, the person's name ("John Smith", "Priya the Java developer"), email address (whole or part: "brettiredale@gmail.com", "anyone on a gmail.com address"), when they were added, and what they have DONE in a job ("people who have run teams", "who has managed a P&L", "account managers who have handled accounts over $1m") - read from what each job description on the CV says they did, stored as short claims with the CV line behind each one, never from a title or a skills list, so "run a team" does not match everyone whose CV contains the word team, and what they have STUDIED ("a business degree", "degree qualified", "MBA", "PhD in chemistry", "diploma or higher") - read from the education section of the CV into a parsed degree ledger, a level floor (a degree means bachelor or higher) with an optional field, never a skills list or a professional certification. Classic boolean strings work verbatim: "account executive" AND (Salesforce OR HubSpot) NOT agency - capitals required, quotes mean exact words anywhere in the CV, never a job title: "business development manager" in quotes finds everyone whose CV says those words in that order, including people who reported to one, and the line under the sentence says so and offers "Search it as a job title instead" (the same role search typing the title without quotes gives you). Or means or in plain English too: "Salesforce or HubSpot" is one chip that finds people with either, never only the first. When an ask has no field and no claim behind it (worked in a regulated environment, presented to a board), Lovelio reads the CV itself: every CV in the search, up to 1,000, keeping only the people whose CV shows it and quoting the line that does. It reads up to 150 CVs at once, each one whole in a single pass. While it reads, the "My database" heading says "Searching..." and the list grows as people are confirmed, best match first. People their records already prove (a job Lovelio has placed in that industry, a CV read from an earlier search) show before the first CV comes back, and the rest join as they are read; when the word goes the count is everyone confirmed: nobody is left unchecked. CVs already read are remembered, so searching again or paging is instant. The same ask in other words reuses those reads too: "has presented to a board of directors" after "comfortable presenting to boards" reads no CV twice. Only the same need counts, so "managed 100+ people" never reuses what "managed 10+ people" read. Lovelio keeps every CV as short passages it can look through in a moment, so a search wider than 1,000 reads the 1,000 whose CV has a line closest to the ask, and someone outside the newest 3,000 is still found when a line of their CV says it. The "Heads up" box in the search panel says when a search was wider than 1,000; add a must-have to narrow it.

Salary chips understand day and hourly rates as their own thing: "on under $800/day" checks recorded day rates and never compares a rate against an annual figure (or the other way round). Currency words never change the number - "£80k" and "80k" filter the same. If an amount cannot be read, the chip says "couldn't read the amount" and honestly filters nothing.

Limits: 8 chips per search. If a long job spec asks for more, the extras are dropped AND named in Heads up - never silently. Time windows cap at 10 years (a year for notice periods); a capped window says so in Heads up. Do-not-approach candidates never appear unless searched for on purpose.

A search on screen always offers Clear search in the search bar. It throws the results and requirements away and puts you back on the empty search page with the cursor in the box. That is the way to start a different search, because typing into the bar while results are up sends a follow-up about those results instead.

There is no chat history above the results: the sentence is the record of what ran, and only Lovelio's latest reply shows, when it has something to say (an answer, a question back, or a credits notice). For a user's first 10 searches a pink "Click to refine" note points at the sentence.

Follow-up messages edit the requirements ("make Salesforce a nice-to-have", "drop Sydney"), and the underlined phrases can be clicked to change or remove. Edits are precise: a chip the message does not mention keeps every detail it had - its years, amounts, distance and nicknames - so refining never quietly rewrites the rest of the search. A refined search always returns exactly what typing the whole thing fresh would. That includes short searches: "sales people" builds chips just like the full sentence, so "in New Zealand" typed after it works on the same footing. A person's name is a chip too, so "John Smith" then "in Sydney" finds the John Smiths in Sydney.

What gets searched, and what does not

Three things per candidate: the structured facts on their record, the short summary Lovelio writes about them, and the full CV text (first 200,000 characters). Notes, emails and interview feedback are NOT searched - if a fit only lives in a note, it must be put on the record. Missing data is never guessed: no dated jobs means no years number (shown as no data, never zero), and a salary chip only matches people who gave a number. Missing information ranks as neutral - nobody drops for what we do not know.

The summary Lovelio writes has two halves, and it matters which is which. The industries, role categories, seniority, geography, company types and education come from Lovelio's own records - the same place lookup search uses, the same job-title dictionary, the same employment dates - so they say what the record says. Where a record cannot answer, the line is left out rather than filled in: an employer nobody recognises gets no industry, because a guessed industry would make that person answer searches they have nothing to do with. The rest of the summary - related skills, roles they could move into, soft skills, keywords - is written by AI from what is on the record, and it is the part to read as a suggestion rather than a fact.

"Mentioned in CVs" - the extra list under a company search

Search for a company ("ex McKinsey, Bain or BCG") and under the results there can be a second, smaller list headed "N people mention this in their CV". The count stays separate: the strip reads "19 candidates, 12 more mentioned in CVs", never one number.

These people did not match. Their CV names the company somewhere; their work history does not say they worked there. Measured on a real 9,378-candidate book, a McKinsey/Bain/BCG search finds 1,735 people through work history and 195 more through CV text alone, and about half of those 195 never worked at any of the three. The real ones are people whose employment dates were never captured. The rest are lines like "founded by ex-McKinsey partners", "in direct competition with McKinsey, BCG and Bain", or "Bain Capital's bid" (a different firm from Bain & Company).

Half right can be useful to read but is never worth mixing in, so it is a labelled list and each row shows the actual line from the CV. Reading that line is how you tell the two apart in a second.

Three things it deliberately does not do:

It never changes the results, the count, or the order. Nothing in that list can push a real match down.
It only happens for companies, and only for "worked at" style asks - not "currently at", not "2+ years at", and never for a NOT chip. A company name is a rare word in prose; a job title is not. 262 people on that same book have "accountant" somewhere in their CV and none of them hold the title, which is why role chips only ever match job titles, never CV text and never the skills list.
It never turns a job match into a maybe. Matching candidates to a job, and every background check of "does this person meet the requirements", ignores mentions completely.

Locations

Every place name is looked up on a real map and a circle is drawn around it, sized to the place: 50 km for big cities (1M+), 30 km for large cities, 20 km for towns, 10 km for suburbs. "Greater X" widens to 80/60/40 km by city size, "X CBD" tightens to 5 km, and a named distance always wins (up to 500 km). States and countries work with no circles. The agency's home country settles ambiguous names ("Perth" = WA for an Australian agency), unless the home place is a tiny village next to a famous city abroad: a UK agency's "Melbourne" is Melbourne, Australia, and "Perth" stays Perth, Scotland. Distance also shapes rank: full marks at the centre of the circle, half at the edge.

An area that is not one place, like "Western suburbs Victoria" or "North Shore Sydney", becomes the real suburbs inside it, each checked on the map, and a candidate near any of them matches. The first search for a new area takes a few seconds longer while Lovelio works the suburbs out; after that it is instant for every agency. The web tab searches the same suburbs.

The ranking formula - eleven parts, fixed sizes

Everyone who passes the filters gets one score out of 100 from a fixed, tested formula. No AI writes this number. The parts: quality of proof 23% (a checked skill on the record scores 1.0, a fact on the record 0.75, a word in the CV 0.5 - checked facts beat keyword luck), overall fit 18%, nice-to-haves hit 16%, meaning match 8%, distance 8%, role fit 7% (how close their job title's meaning is to the role asked for - and if they matched through a PAST role, it is that past title that gets scored, not their unrelated current one), experience fit 4%, freshness 4%, ready to move 4%, likely to move 3%. The last two (availability and movement) can be switched off. Parts the search did not ask about (no nice-to-haves, no location) drop out for everyone and the rest scale up - but a part the search DID ask about applies to every result: missing it scores 0, it never quietly disappears for one person. Missing DATA is different from a missed requirement: a candidate with no AI profile yet scores the middle of the pack on the AI-similarity parts, never the bottom. Ties go to the newest record. Match bands: Strong = every chip covered, Good = about two thirds, Partial = the rest (a search with no chips at all takes its bands from the same score that orders the list). Only the newest 3,000 people who pass the filters get ordered, plus anyone an ask only the CV answers finds by a line in their CV (the count still shows the true total), and when that happens the search says so in Heads up - add a requirement to rank everyone.

Matching against a job

Find candidates on a job opens the People search for that job and runs the exact same engine - the chips come from the job. The job's location and the role itself become must-haves (fully remote jobs get no location rule), the two clearest essential skills become must-haves, and desirable skills, seniority, industry, a written minimum-years number, and the job's work type (a contract job ranks up candidates open to contract work) become nice-to-haves. The job's salary never filters or ranks (pay data is too patchy) - add a salary chip manually if it is a deal-breaker. Every automatic candidate suggestion anywhere in Lovelio must pass the job's must-haves first; an AI opinion can never beat a hard job requirement.

One engine, every door

Every place that finds or ranks candidates uses this same engine, so the same ask gives the same people everywhere: the search page, the Cmd+K command bar and Slack ("find senior developers in Melbourne"), the public API's candidate search, a job's Find candidates (Your database and On the web), the People page's On the web tab (the same search, run on the web, with the same order), the People page's LinkedIn tab (the same search limited to people who came from LinkedIn), talent pool suggestions on a job, the "Suggested for open jobs" panel on a pool page (skill overlap raises the idea, but the job's must-haves decide who may be suggested), the marketplace's Fits Your Market, the CV-import role match, and "people like these" (which ranks by closeness to the people you gave). Deleted and do-not-approach candidates are excluded from all of them.

Who search covers

Search covers your candidates AND your client contacts - a hiring manager is a future candidate, and a third of a typical agency's placements are already on file as someone's contact. Narrow by role with the "Who it searches" control in the search panel (Everyone / Candidates only / Contacts only), or just type it: "accountants, candidates only", "contacts only". "Candidates only" restores the pre-contacts view; "Contacts only" shows people holding a live contact role at one of your clients, including people who are also candidates. A person who exists only as a contact usually carries just a name and their client role, so they surface on name searches rather than skill searches until a CV is added. Searchability changes nothing about emailing: approach email to a client contact still holds at the outbound gate, and automation can never override it.

On the rare occasion the engine itself fails mid-search, the search bar falls back to a plain keyword match and SAYS SO - a banner explains that must-have requirements were not applied as filters, so a degraded list is never dressed up as the real thing. Search again to retry the full engine.

The "How do I search?" card only teaches searches your book can answer

The card on the landing search bar shows what the search understands, with an example under each heading. The pay, notice, work rights, star rating and open-to-work examples show only when at least one candidate in the workspace holds that field. A book where nobody has a salary, a notice period, a rating or an open-to-work flag never sees "AEs on under 120k" or "5 star candidates", because on that book they return nobody. Those searches still run if typed; the card just stops promising them. Fill the fields in (a CV that states them, an interview call, or a consultant edit) and the examples appear.

When a search finds nobody

The empty page asks one question and answers it with real counts. The headline names what found nobody in your own words ("Nobody has a sales title right now."), then "Did you mean:" and up to three buttons, each a nearer reading of the same search with the number it would find: anyone who has ever held that title, the people who do that work, anyone who ever worked at that employer, the title one word wider ("Any electrician" for an automation electrician), the same search in the wider state or country ("Anyone in Australia" when nobody is in Sydney), anyone with the words on their CV or skills, or the same search without the requirement that emptied it. Closest reading first. A click runs exactly the search the number was counted against; nothing is re-interpreted. Below the buttons: type a different search, clear it, or open Search settings to change who it searches (everyone, candidates only, contacts only), what ranks first, and the view. The panel does not open on its own any more. The same diagnosis runs on the Your database tab of a job's Find candidates.

When a requirement needs CVs read (an industry, a skill, "has done") and the people were found but their CVs were not all read, the page never says nobody matches. It says what happened instead: "Nobody confirmed yet. 7 CVs could not be read just now." with a Try again button. When some results did come back and a few reads failed, the count says "3 CVs could not be read just now" with Try again beside it. If the main CV reader is out of action, the standard reader reads those CVs instead, so "could not be read" only shows when neither reader got to them in time. Some people are confirmed without a CV read at all, from their work history: for "worked in insurance", anyone who has worked at an employer Lovelio knows is in insurance, or in a job Lovelio has placed in insurance itself when it knows nothing about the employer; with a job title as well ("account managers in insurance"), that title on that same job (for example an Account Manager at a known insurance broker). These people count straight away and are never read: the reads go to the people their work history cannot prove. The count shows one number, everyone confirmed either way.

The "Explain this search" panel

On the candidates page the result count is a button: click it to open the search panel, headed Your search: "...". On the job-match panel the same rows sit behind Explain this search next to the chips (Requirements and Heads up only, since the settings belong to the candidates page). Every line is filled in by the engine itself - no AI writes it, so it cannot drift from what actually ran:

Requirements. One row per requirement: its label, what kind of check it is (role now, skill, location), and a real count from your database of how many people are left once that row is added to the ones above it, so the numbers shrink down to your result count. A row that empties the search says "Finds nobody." and how it was checked. Every row has a Remove that takes it off and re-runs. The counts are worked out when the panel opens, so results never wait for them.
Search settings. Three rows: Search (Everyone, Candidates only, Contacts only), Rank first (two switches, Open to work and Likely to move, which change the order and never who is in the list), and View (Table or Cards).
Heads up. Anything the search could not do properly - an AI ranking signal offline, an exclusion that could not apply, a check that fell back to a wider match, or more than 3,000 matches to rank. An amber dot on the trigger means this section has something in it. A silent shortcut is never allowed: if the search could not do exactly what the chips say, it appears here. What you will never see here is a warning that your results might be short: however many people match, every one of them is filtered and counted in the database, so the count is the true count.

Asking the follow-up box "why did this get no results?" is answered from the same engine numbers - the funnel and the diagnosis - never from a guess.

Answering "why is my perfect candidate missing?"

Work down this list, it is almost always one of the first three: (1) a must-have blocked them - check each pink chip against their record, commonly a location circle or a skill worded in a way the dictionary has not linked yet; (2) the search filtered on data their record does not hold - salary, notice and work-rights chips only match recorded answers; (3) their record is thin - no CV and no skills means almost nothing to match on; (4) they are flagged do-not-approach; (5) the search matched more than 3,000 people. Fastest diagnosis: flip pink chips to nice-to-have one at a time until the person appears.

Answering "why is this person ranked here?"

Result rows carry a Match column, and the number in it is that row's score out of 100 - the same score the engine ranked on, so the column reads in the order the list is sorted and you can see where the good people stop. The Match heading wears a down arrow to say so: the whole result, every page, is already sorted by match, best first, and there is no separate sort to switch on. Sorting by Name, Location or Added reorders the rows; clicking Match puts them back in match order. Hover the score to preview the "Why this match" card; click it to keep the card open while scrolling (close with the x, Escape, or a click anywhere else). The card lists every part with the fact behind it ("2 of 3 nice-to-haves", "8 km from Sydney") and the full score breakdown. The tile view prints the same number in the card footer. A row with evidence but no score - a CV mention, which is not a match - says "Why" instead of a number, on purpose. What the cell does NOT carry is a band word, a coverage fraction, or a colour: on a faceted search the band is coverage and every row on screen matched every must-have, so the word and the fraction were identical down the whole column and separated nobody, and colouring by that same band paints every row one shade. Colouring by fixed score thresholds is worse, because the score renormalises per search: a top result is routinely in the 70s, so an "85 is green" rule would call the best person on the list mediocre. Read the order rather than the absolute figure, and never compare a 72 in one search with a 72 in another. Result rows carry no email or phone column - both were too long to read at that width, and you need a number after picking someone, so they live on the record and inside every action. A surprising high ranker usually hit more nice-to-haves or has checked-fact proof (the biggest score part). A keyword match ranking below a checked-fact match is on purpose. Proof chips labelled "inferred" matched only in the Lovelio-written summary - the trust order is record facts, then CV quotes, then summary lines, and a quote is never invented.

Seeing past the first 50

Results show 50 at a time, with page controls under the grid whenever more matched. Every ranked candidate is reachable - "1,240 candidates" means you can page through 1,240 (up to the 3,000-ranked ceiling, which Heads up calls out when it applies). Paging keeps the exact same order; it never re-shuffles.

Results paint fast and settle fast: the grid shows the ranked list as soon as the requirements are filtered, with a brief "Refining order" note while the last AI ranking signal finishes - the same people, the same count, only the order settles. It usually takes a second or two.

Same search, same answer for 24 hours. Over weeks results change because the data changed, not the formula.

How we know search is working (Analytics > Search quality)

Two numbers, side by side, because they answer different questions.

Your searches. Of your candidate searches in the last 8 weeks that returned results, how many had someone open or act on one of the top 3. A search counts once however many results were acted on - this asks whether the right person came out near the top, not how many clicks a search got. Opening a candidate, adding them to a job, emailing them, or adding them to a talent pool all count, from anywhere you can do it: the results grid, the candidate record, the job match panel, talent pool suggestions, and clicking a name in a Lovelio answer. Searches that came back empty are left out, and so are questions and commands - neither has a list of people to act on, and counting them would blame the ranking for something else. When nobody has acted on a result yet the page says so rather than showing 0%.

Our ranking tests. A fixed set of searches with the right answers marked by hand, replayed against the ranking on every change: how close the top 10 is to the ideal order, how many of the right people appear at all, and how many searches that should have found someone came back empty. These are the same for every customer - they catch a ranking regression before it reaches you, but they cannot tell you whether your own team is finding people. That is what the first number is for.