SCOUT — Recruiting Pipeline

Schedule AI screen

Date & time Timezone

Scoring glossary

How each score in Scout is calculated, and what weight every factor carries.

1 · Candidate fit score 0–100

Shown on the score card in the Chrome extension. Computed server-side by POST /api/scout/score so every browser gets the same number.

score = Σ ( weight_i / Σ active weights ) × fill_i × 100 → clamped to 5–99

Five weighted buckets. A bucket only counts when the job description actually states that requirement — the remaining weights are renormalized to 100, so an unstated clearance never silently penalizes a candidate.

Bucket	Weight	Counts when	Fill (0–1)
Required Skills	35	Always (a JD with no extractable required skills returns a flat 50 / Fair Fit)	Prominence-weighted share of required skills matched — a skill repeated often in the JD counts more than one mentioned once
Preferred Skills	15	JD lists nice-to-have skills	Plain share of preferred skills matched
Clearance	20	JD states a required clearance level	1.0 meets or exceeds (or holds an unspecified clearance) · 0.5 holds a lower level · 0 none
Education	15	JD states a degree requirement	1.0 meets or exceeds · 0.5 lower degree · 0 none
Location / Commute	15	JD is remote, or both the JD state and the candidate state are known	1.0 remote or same state · 0 different state. Unknown on either side and not remote → bucket drops out entirely

Skill matching — a required skill counts as matched when any of these hold:

Exact match after normalization and alias folding (k8s → kubernetes, nodejs → node.js, postgres → postgresql, …).
Token subset — one skill's words fully contain the other's (react ↔ react native developer).
Semantic — MiniLM (all-MiniLM-L6-v2) cosine similarity ≥ 0.58 (0.55 threshold + a 0.03 margin). Borderline pairs below that margin fall back to the deterministic rules above, so scores stay stable.

Labels — Excellent Fit ≥ 80 Good Fit 65–79 Fair Fit 45–64 Poor Fit < 45

2 · AI screening-call score 0–100

Produced after a Vapi screening call completes. Scored by our own LLM pass (agents/scout/scoring.py) against the JD — not by Vapi's built-in analysis — and stored as fit_score / fit_reason on the call.

This score is holistic, not a weighted sum: the model reads the job description alongside the call transcript and summary and returns a single 0–100 fit rating, a one-or-two-sentence reason, and an advance recommendation. There are no fixed per-category percentages — the rubric instead tells the model what to weight:

Factor	Effect on the score
Hard eligibility gates work authorization · clearance · required years · must-have skills · location / onsite	Weighted heavily. Failing any gate the JD states outright forces a low score even when the rest of the screen is strong.
Evidence from the call only	Anything the screen didn't cover is never assumed in the candidate's favour — it is called out in the reason instead.
Determinism	Run at `temperature 0.2` with a strict JSON response, so repeat scores on the same transcript barely move.

Auto-advance threshold — 70 (override with the SCOUT_AUTOADVANCE_THRESHOLD env var). At or above it, Scout moves the applicant to Present screen to Hiring Manager in JazzHR and emails the candidate a booking invite; below it the call is left for a recruiter to review.

3 · Panel interview scorecard 6–30

The “Evaluate” action on a candidate row. Navitas's standard interview-feedback form, filled in from the interview transcript.

total = Σ six trait ratings (each 1–5, max 30)

All six traits carry equal weight — there is no weighting between them: Job Knowledge · Relevant Experience · Communication Ability · Interest in Position and Organization · Initiative · Skill Level.

Rating scale — 1 Unsatisfactory · 2 Some Insufficiency · 3 Satisfactory · 4 Above Average · 5 Outstanding. The model picks a rating and a short note per trait; the total, the descriptors and the hire recommendation (Yes / Maybe / No) are assembled deterministically, and any evaluation failure falls back to a neutral 3 across the board.

4 · Talent Bank match 0–100

The Navitas Talent Bank search (public/scout/talent-bank.html). A recruiter types a phrase or pastes a whole job description; Scout reads the intent, ranks the résumé corpus, and shows one calibrated match % per candidate. Served by POST /api/scout/talent/match in backend/talent_endpoint.py.

What we built — step by step. The design goal was an AI-native search (Juicebox / hireEZ style): no keyword boxes, one smart bar, and every match backed by evidence rather than a raw similarity number.

Understand the query. The phrase or pasted JD is sent to gpt-4o in JSON mode (understand_query(), temperature 0) and parsed into an editable intent: required_skills[], preferred_skills[], location, years_min, title, domain, plus a clean search_text. If the LLM is unavailable it falls back to the deterministic keyword extractor (find_keywords / canonical_skill).
Show it as editable chips. The parsed intent renders as the “Understood as” chip bar — Must-have / Nice-to-have skills, location, years, domain, title. Removing any chip re-runs the search with that intent passed back as explicit filters, which skips the LLM re-parse so the recruiter's refinement is honoured verbatim.
Vector recall. search_text is embedded with text-embedding-3-small and used to over-fetch the nearest ~30–45 résumés by pgvector cosine distance (ORDER BY embedding <=> query_vector) from the resume_index table. Recall is deliberately not hard-filtered, so strong near-misses still surface (with their gaps shown) instead of being dropped.
Rubric rerank. Each recalled résumé is re-scored with the same weighted rubric as the Candidate fit score above (§1, compute_score) — Required 35 / Preferred 15 / Clearance 20 / Education 15 / Location 15, renormalized to whichever buckets the query actually states, clamped 5–99. The final ordering is this calibrated score, with cosine as the tie-breaker — not raw similarity.
Evidence pills. Every card carries the rubric's own matched / missing detail as ✓ met and ⚠ gap pills — e.g. “✓ React”, “⚠ needs AWS”, “⚠ 3 yrs (<5 needed)”. This is why a match % is defensible: you can see exactly what earned or cost each point.

Labels reuse the same bands as the Candidate fit score — Excellent ≥ 80 Good 65–79 Fair 45–64 Poor < 45. Note: location scoring in the shared rubric is US-centric (states / “remote”); for non-US queries (e.g. “Bangalore”) the Talent Bank adds its own location met/gap pill so the signal still shows.

Jobs

Schedule AI screen

Scoring glossary

1 · Candidate fit score 0–100

2 · AI screening-call score 0–100

3 · Panel interview scorecard 6–30

4 · Talent Bank match 0–100

New internal job

Add candidate

Job description

Candidate