How a match is computed, and why we show the working

Every matching tool gives you a number. Ask it why, and most of them go quiet. Ours is built the other way round: the receipt first, the number second. This article is the whole computation, in order, with the part we got wrong.

What the two sides are made of

A listing is a title and a set of requirements. Each requirement has a kind — a skill, a role, a company, a field — a canonical name, and a flag saying whether it is required or a bonus. They come out of a conversation with the person posting the role, as a list they correct before anything is published. Nobody types into a form with forty fields, and nobody is stuck with what the extraction guessed.

A person is a set of claims. Each claim is one assertion — this person knows this thing — carrying three things that matter here:

• the canonical concept it points to, in English, shared by everyone;
• the sentence it came from, in the person's own words, unchanged;
• the time it holds for, which may be unknown, because a guessed date is worse than no date.

The computation

For each requirement, in order:

1. Look for a claim pointing at the same canonical concept. If there is one, the requirement is met, and the claim's sentence is the evidence.
2. If there is none, look for a claim whose concept is close enough in meaning to count. The rule for "close enough" is the subject of how matching decides; the short version is that it weighs the vector and the names, because Postgres and PostgreSQL score almost the same as MySQL and PostgreSQL by vector alone.
3. If still none, the requirement is unmet, and it stays in the result.

The percentage is then a weighted count over that list, with required requirements counting for more than bonuses. That is all it is. It is useful for sorting a hundred candidates into an order worth reading. It is not useful for deciding, and the product never asks you to use it that way: every percentage on every screen opens into the list it was computed from.

The bug that inflated every score

The first version of the query joined requirements to claims and let the database drop the rows that did not match. It looked correct. It passed its tests. And it was quietly wrong in the most dangerous direction: a requirement with no hit deleted the whole row, so the percentage counted only what spoke in the candidate's favor.

A candidate meeting three of ten requirements scored 100%.

The fix was a LEFT JOIN LATERAL — keep the requirement, attach the best claim if there is one, attach nothing if there is not. The lesson is the one that governs the rest of this system: in hiring software the dangerous bugs are the silent ones. Nothing crashes, nothing logs an error, and a person is hired or rejected on a number that was never true. So every trap we hit goes into the project's own rulebook, with what it did and how it cannot happen again.

What you see, and what the candidate sees

The employer sees, for each candidate: the percentage, then the requirements — met, with the candidate's own sentence; unmet, listed plainly. Click one and you read the sentence the person actually wrote, in the language they wrote it.

The candidate sees the same thing about themselves, against any listing, before applying. There is no version of the comparison that one side can see and the other cannot, because a score that only the employer can read is exactly the thing the EU AI Act asks you to be able to explain.

Why unmet requirements stay

Two reasons, one practical and one ethical.

The practical one: a percentage that hides what is missing cannot be compared across candidates. If one tool shows 90% because it dropped six requirements and another shows 60% because it counted them, the numbers are not on the same scale, and neither is any decision made from them.

The ethical one: the unmet list is the only honest answer to why not. It is what lets an employer tell a candidate something better than "we went in another direction", and it is what lets a candidate turn a rejection into a plan. Our percentages are lower than some. That is the cost of counting.

---

Everything here is visible in the product without a sales call. Post a listing, or match yourself against one, and open a comparison.