AI candidate matching
Define match criteria, run matching, and work the ranked shortlist — with per-criterion evidence for every candidate.
Kepler builds a ranked shortlist for each job from your existing candidate database, scored against criteria you control. It lives on the job's Matching tab.
Match criteria — the rubric
Matching is criteria-first: the job carries a rubric of requirements, and every candidate is judged against each one.
- Click Criteria on the Matching tab (the button also shows the number of criteria when a rubric exists). On first run, Kepler generates criteria automatically from the job brief — review and edit them before trusting the results.
- Each criterion is a plain-language requirement (e.g. "5+ years building backend services in Rust") marked Must-have or Nice-to-have. Manage Search keywords separately below the rubric; these short terms widen the pool of candidates retrieved for scoring.
- Add, edit or remove criteria any time — the next run scores against your edited rubric.
Running matching
Click Run matching (Re-run once results exist). Kepler retrieves a candidate pool using semantic and keyword search over profiles and CVs, then an AI judge assesses each candidate against your criteria across skills, seniority and domain. The run continues in the background with a progress banner; when it completes, review the results.
Running matching and editing the criteria need permission to edit the job. Anyone who can add candidates to a pipeline can accept a suggestion.
Reading the results
Results are grouped into Suggested, Accepted and Rejected sub-tabs, viewable as a board (columns Strong → Good → Weak → Off spec) or a full list.
| Where | What it shows |
|---|---|
| Match column | The percentage score and the judge's verdict: Strong, Good, Weak or Off spec. |
| AI assessment column | The judge's written reasoning for this candidate. It's hidden by default: add it as a column, or open the candidate to read it in full. |
| The candidate's evidence card | Click a candidate to open it beside the list: the Assessment and each criterion marked Met, Partial, Missing or Not stated, with the evidence behind each verdict. |
Match strength is set by the AI judge and can't be dragged between columns — you act on it instead: in the evidence card, Accept to pipeline adds the candidate to the job's pipeline, and Reject… declines the suggestion (with optional reasons such as Too junior or Location). Re-run matching to re-score after the brief or criteria change.
How must-haves affect the score
Must-haves are enforced, not just weighed:
- A candidate with any must-have marked Missing is rated Weak at best, with a score under 50%.
- A candidate with any must-have marked Partial is rated Good at best, with a score under 75%.
- A must-have marked Not stated doesn't lower the score — a profile that doesn't mention something isn't proof the candidate lacks it. The Match column flags how many must-haves weren't confirmed, so you know what to check before you submit.
Nice-to-haves inform the score, but a missing nice-to-have never caps it.
After changing the criteria
Criteria edited since this run means the results were scored before your latest rubric changes. Review the criteria, save your edits and click Re-run to assess the candidate pool again. Re-running preserves your Accepted and Rejected decisions; it does not move reviewed suggestions back into Suggested. Scores and evidence can refresh for candidates assessed again.
Improving match quality
- Edit the criteria. The rubric is the single biggest lever — make must-haves genuinely non-negotiable and move preferences to nice-to-have.
- Keep CVs current. A candidate's assessment reflects their parsed profile — upload their latest CV and re-parse.
- Complete the job brief. Criteria generation and retrieval both read the description and details; thin briefs produce generic rubrics.
Matching never moves candidates or contacts anyone — it only ranks and explains. You decide who enters the pipeline.