Evidence-first candidate matching

Why does Emoti show evidence before a score?

A score on its own can't be checked, and a ranking that can't be checked gets either ignored or trusted too much. Emoti's rule is that no candidate's score appears without the evidence behind each part of it.

Ranking decides who a recruiter reads first and who they never reach. That is a real decision, even when nobody is rejected. So the matcher is built to be read: every criterion is named, every result has a state and a line of evidence from the profile, and the score is a fixed formula over those states. The same profile and the same criteria always produce the same score.

A language model can help read the recruiter's brief into criteria. It never scores people. Scoring is done by the same deterministic rules in every case, which is what makes each number explainable.

How does a brief become criteria?

Emoti reads the brief into a short, ordered list of criteria, each marked as a must-have or a nice-to-have, and shows them as editable chips above the results.

The order is role, location, experience, skills, industry, then other signals. Two readers can produce the list:

• The model reader. When a model is configured, Emoti's model gateway runs the request on whichever model the workspace admin assigned to parsing, with fallbacks in order, and the model is asked for three to eight criteria in that order, using only the matcher's own vocabulary for roles, places, skills and industries. Emoti then drops anything the matcher can't check, and any duplicates. If nothing usable survives, or the call fails or is declined, the rules reader runs instead.
• The rules reader. Without a model, Emoti matches the brief against fixed word lists: eight role families, seniority words such as senior, staff and lead, a list of cities, countries and regions, the word remote, a pattern for years of experience, a dictionary of skills and their aliases (k8s becomes Kubernetes), a list of industries, and phrases such as "led a team".

The page always says which reader produced the criteria: "Criteria read by the AI model" or "Criteria read by Emoti's built-in rules."

Defaults and editing

The rules reader, and the instructions given to the model, follow the same defaults. The role, a stated location and a minimum number of years start as must-haves. Skills, industry and signals start as nice-to-haves. If the brief allows remote work, location becomes a nice-to-have.

A recruiter can switch any criterion between must-have and nice-to-have, remove it, add a new one in plain words, or edit the brief and rebuild the list. Shortlist decisions survive a rebuild.

Look-alike searches

A look-alike search builds its criteria from one person's profile instead of a brief, then ranks the pool with the same scorer. "People like this one" becomes a set of named, editable criteria rather than a hidden similarity score. From the chosen profile Emoti takes:

1. The same role family, as a must-have.
2. The same region, as a nice-to-have.
3. At least their years of experience minus two, with a floor of two years, as a must-have.
4. The first four skills listed on their profile, each as a nice-to-have.
5. The first industry on their profile, as a nice-to-have.

Nothing else is copied: not the person's name, school or employer. The criteria appear as chips like any other search, so a recruiter can remove a skill that was incidental or add one that matters.

What are the four evidence states?

Each criterion gets one of four states, and each state has a fixed value: met is worth 1, partly met 0.5, not enough information 0.25 and missing 0.

Partly met has specific triggers. A role in an adjacent discipline counts as partial, for example data engineering when the brief asks for machine learning. So does a candidate at mid level when the brief asks for senior, a person in another city in the same region (with "open to relocating" added when their summary says so), someone one year short of the minimum, and a related skill, such as TensorFlow for PyTorch or Rust for Go.

The evidence line is written from the profile itself: the title and employer, the city, the number of years, the employer where a skill was used, or the substitute skill found. It is short on purpose. It says what the matcher saw, not what it concluded about the person.

How is the score calculated?

Must-haves count double, the values are added up and divided by the most a person could score, and then two caps apply.

Each criterion has a weight of 2 if it is a must-have and 1 if not. The score is 100 times the sum of each state's value multiplied by its weight, divided by the sum of the weights, rounded to a whole number. Then:

• If any must-have is missing, the score is capped at 54.
• Otherwise, if any must-have is only partly met, the score is capped at 74.

Scores are shown with a word: 80 and above is a strong fit, 60 to 79 a good fit, 40 to 59 a partial fit and below 40 a weak fit. A missing must-have therefore keeps a person in the partial band at best, and a partly met must-have keeps them out of the strong band.

A worked example

The caps exist because a weighted average alone lets several nice-to-haves outweigh a missing must-have. Take a search with three must-haves (role, location, years) and three nice-to-haves (two skills and an industry), so the most a person can score is a weight of 9.

Candidate B ranks above candidate D, even though D meets every must-have and B does not. The caps keep near misses out of the higher bands; they do not guarantee that everyone who meets every must-have ranks above every near miss. To make that visible, the results page states how many people meet every must-have, and the strip shows which must-have each person misses. Ties are broken by an internal identifier, an order that is stable but arbitrary.

The one-sentence explanation

Each result also carries one or two plain sentences built from the same results as the score: what the person does now, in their profile's own words, then how many criteria they meet, then up to two gaps. When nothing is missing, it names up to two partly met criteria instead.

At Example Co.: owns the pricing models used in every quote. Meets 5 of 6 criteria. Missing Experience in logistics.

The sentence is assembled from the results, not written by a model, so it can't add a fact the strip doesn't show. Its weakness is the same as its strength: it is only as good as the profile text it quotes.

Where does the evidence appear?

In three places: the fit strip on every result, the "How they match" list in each profile, and a coverage panel that shows how many people in the pool meet each criterion.

The fit strip has one segment per criterion, in criterion order. A met criterion is a solid segment, partly met is half filled, missing is hollow and not enough information is pale. The fill level carries the meaning, so the strip reads without relying on color. Hovering a segment shows the criterion, its state and its evidence line. For screen readers the strip is announced as a tally, such as "Meets 4 of 6 criteria".

The profile repeats the same results as a list, with an icon for each state and the evidence under each criterion. The coverage panel shows, for each criterion, the share of the pool that meets it. When fewer than 8 percent of people meet a must-have, it says so and suggests making that criterion a nice-to-have.

Results arrive in batches of ten. Shortlisting or passing on a person moves them out of the list to review. In version 1.0 these decisions do not change the criteria or the weights. The ranking changes only when the criteria change, which keeps every change visible.

Limitations

The method is simple on purpose, and its weaknesses come from the same choices.

• Evidence is keyword evidence. A skill counts as met when it appears in the profile's skill list, and as "used at" an employer when the first word of the skill appears in that role's description. Listing a skill is not proof of depth, and a skill described in plain words without its name is missed.
• The vocabulary is closed. There are eight role families, a fixed list of places, and fixed lists of skills and industries. A brief for a role outside those families, such as a recruiter, gets no role criterion at all. The model reader is held to the same vocabulary so that both readers can be scored the same way.
• The rules reader misreads ordinary words. In a test brief saying a backend engineer would "lead the payments pipeline and help us go live in March, London", the rules reader produced a "Lead backend engineer" title, a Go skill from "go live", and North America as an allowed region from the word "us". The chips show these mistakes, but only to someone who reads them.
• Either-or requirements can't be expressed. "Go or Rust" becomes two separate skill criteria. Making both must-haves would demand both.
• Unknown is not missing, but version 1.0 often treats it as missing. Only signal criteria can be marked "not enough information". A skill, industry or place that the profile doesn't mention is marked missing, even though the person may simply not have listed it. The evidence line says "No PyTorch in profile", which is accurate, but the score treats silence as a gap.
• Profiles undersell some people. People who write short profiles, describe their work without product names, change careers or have gaps look weaker to any matcher that reads profiles. Years of experience is a rough proxy for ability and can count against capable people with shorter or interrupted careers.
• Profiles carry bias in what they contain. Titles, employers, conference talks and open-source work reflect access and visibility as well as ability. Signals such as "conference speaker" favor people with the time and networks to speak in public. The matcher doesn't read names, photos, age or gender, and it builds no criteria from schools, but that doesn't remove bias carried in the fields it does read. Look-alike search can reproduce the profile of an existing team, including its blind spots.
• The caps don't guarantee order. As the worked example shows, a person who meets every must-have but few nice-to-haves can rank below a near miss. With three must-haves and six nice-to-haves, meeting only the must-haves scores 50, below the 54 cap of someone who misses one must-have and meets everything else.
• Partial rules are coarse. One year short is partial and two years short is missing. Adjacent disciplines come from a fixed table.

What we have not measured yet

We have not measured whether the method finds the right people. Specifically, we have not yet measured:

• How closely the ranking agrees with experienced recruiters who judge the same profiles independently.
• Whether people ranked highly go on to pass screens, receive offers or do well in the job.
• Whether shortlist rates differ by sex, race or ethnicity. Checking this needs demographic data that Emoti doesn't collect, compared with a method such as the four-fifths guideline in the US Uniform Guidelines on Employee Selection Procedures (29 CFR 1607.4(D)).
• How often the model reader and the rules reader produce different criteria from the same brief, and which version recruiters keep.
• How often "used at" evidence reflects real use of a skill rather than a word match.
• Whether recruiters would decide differently if people who meet every must-have were always sorted first.

Until those are measured, the fit strip is a way to read profiles faster and more consistently. It is not evidence that the people at the top are the best candidates.