Résumé → Fit: what we extract, and how we decide

STEP 1Read the JD — the yardstick

Skills, band, emphasis and depth come mostly from structured position data (competencies + weights + experience enum); one LLM pass reads the JD prose for nuance. Our example role:

STEP 2Extract the signals — what we pull, and from where

Pure extraction — nothing scored yet. ~40–50 signals from up to three sources. For each: what we pull, and a real output for our candidate.

What that produces for our candidate

STEP 3Facts → Evidence → Role relevance

Extracted facts pass through three lenses before any score — keeping them separate is what stops a keyword-matcher from mis-ranking people. Extract everything; score selectively.

The question to ask: "what uncertainty does it reduce?"

Not "how important is GitHub?" — a signal's value is how much doubt it removes for this role.

Worked comparison — a Senior Backend role

Which is why: missing ≠ negative — three kinds of signal

Absent optional evidence lowers confidence, never the score. Only real negative evidence lowers the score.

Unknown ≠ Low. When the résumé gives no evidence either way, we label the conclusion Unknown, never a low score — "Leadership: Unknown — insufficient evidence" is honest; "Leadership: 3/10" invents a negative that isn't there. And every conclusion carries its own confidence, not just the overall report: "Leadership: High · confidence Medium — mentored 4, led 2 projects" tells the recruiter both what we found and how sure we are.

STEP 4Calibrate against the stage's bar

Step 3 decided which signals count and how much the role cares. Now we grade each one against the level expected for the stage — the same evidence can be above the bar for one stage and below it for another. Ask "is this appropriate for 8 years?", never "do they have it?"

Same evidence, four different verdicts

One résumé line — "Designed & owned a payment service · set SLAs · led the migration" — graded across stages:

So we report "above expectation for a 4-yr engineer", never a bare "8/10" — the baseline is the stage, not the universe.

The bar rises with stage

Maturity flips by stage: junior → a Growth bonus (absent = fine, teachable); senior → required (absent = a real gap).

…and supporting signals fall with stage

The mirror image. For a junior these are strong independent evidence (little work history to lean on); for a senior the résumé already proves capability, so they fade to nice-to-have — and their absence is never a penalty (§3).

This is the same logic that collapses GitHub's weight from ~15% (junior) to ~1% (senior) in the Step 5 dial — a junior is carried by these; a senior is judged on production evidence instead.

Calibration traps we avoid

STEP 5Score — two views, read against the band

Each signal gets a 0–1 sub-score (rules for objective ones, LLM for fuzzy ones). The percentages below are the mid-level anchor — the default importance for a typical role — not a fixed weight used for every JD. (The dial table further down shows each one swinging down for juniors, up for seniors, around this anchor.) The Re-weighted by column says what moves each one: Stable ≈ same everywhere, JD = set by the role's subject, Band = shifts with seniority. So no two JDs use the same numbers — importance = weight, but it's never universal, and never summed into one blended score.

* Supporting signals (GitHub, portfolio…): bonus when present, never a penalty; importance shrinks with seniority (§4). Recency is a Stable modifier that feeds skill match rather than carrying its own weight.

How the dial turns — junior → mid → senior. The Mid column is the % from the table above (the typical-role anchor); junior swings it down, senior swings it up. The Band rows swing hard; the Stable rows barely move; the JD row is set by the role, not the band. Magnitudes are illustrative — they show direction and relative size, not a balanced ledger.

Read one row across: 5% for ownership isn't a fixed weight — it's the mid anchor, swinging to ~2% for a junior and ~18% for a senior. A junior is carried by GitHub + fundamentals + learning velocity; a senior by ownership, relevant years and scale — their missing GitHub weightless. Same table, re-weighted.

Risk indicators are a gate, not a dimension — résumé stuffing, unstable tenure / heavy job-hopping, large unexplained gaps, contradictory timelines, dead/faked GitHub, skill inflation → cap the score and surface as concerns (only on real negative evidence; §3).

Some extracted signals feed these dimensions rather than standing alone: recency → skill match · quantified impact → evidence strength · engineering maturity → ownership. Stability & gaps → risk indicators (above). Education / certs → count only when the JD values them.

Two independent scores (0–100)

Each view sums the signals tagged for it above (re-weighted for its question), plus a few derived signals of its own:

Read both against the band → a bucket

No single blended number. The pass bar moves with the band — a senior needs high Readiness; a junior isn't expected to be day-one ready, so their Readiness bar is low but their Growth bar is high.

Ranking within a bucket goes by the band's primary score — seniors by Readiness, juniors by Growth (the other breaks ties). No fake precision from a blended number.

STEP 6The report — one minute to decide

Every line is backed by evidence, and labelled by source. This is what the recruiter reads.

Evidence rule: never "AWS 9.1/10" — always "AWS across 4 production projects over 5 years, incl. infra for 15M req/day." Evidence is what makes every line explainable and defensible.

The same two metrics, judged against each band's bar — two different applicants:

Sample reports — good & bad hires

Six candidates, spanning the range — chosen to surface as many signals as possible (each concern/plus is tagged). Watch how the band re-weights the signals (§ dial table above) and how the missing-vs-negative rule changes each verdict — the same fact carries a different weight for a junior vs a senior.