build.allanninal.dev

Part 4 of 7 · Applicant screener series ~5 min read

How a strong match reaches the hiring manager

The reader landed on a label — yes, maybe, or no. Now the router has to get the right candidates in front of the right person, in a form they can act on, without doing the one thing the system must never do: decide. A strong match should arrive with a short summary and the reasons, ready for a human to weigh. A weak one should still be reachable, not deleted. Four small guardrails sit between a score and a routed candidate.

Key takeaways

  • Routing order: dedupe the applicant, run the fairness check, write the summary, then place the card for a human.
  • A yes goes to the top of the manager’s review queue; a maybe goes lower; a no is parked but still reviewable.
  • The summary is short and job-related — the met must-haves, the gaps, and the role. No gut-feel, no ranking-by-name.
  • The screener never sends a rejection. It routes cards; the hiring manager decides on every one.
  • Every routed card is logged with the label, the reasons, and the rubric version used.

Four guardrails before a candidate is routed

Four guardrails between the score and the routed candidate card A horizontal flow diagram. On the far left, a "Score in" box: the reader produced a label for this applicant — yes, maybe, or no — with the per-must-have reasons attached. Four guardrail gates sit in a row to the right, each drawn as a vertical bar. Gate 1: Dedupe — checks whether this same person already applied for this role through another lane; if so, the two are merged so the manager sees one card, not three. Gate 2: Fairness check — confirms the score used the job-related must-haves only and that the personal fields were stripped; if anything personal leaked into the reasons, the card is held for a human instead of routed. Gate 3: Summary — writes a short, plain summary: the role, the label, which must-haves were met with their quoted lines, and which were missing. No gut-feel, no overall impression. Gate 4: Place the card — puts the card in the hiring manager's review queue, a yes at the top, a maybe lower, a no parked in a reviewable list. After all four gates pass, the card lands in the queue with advance, hold, and pass buttons for the human. A note at the bottom: the screener routes cards — it never sends a rejection and never decides; a human acts on every card. Score in yes, maybe, or no, with reasons Gate 1 Dedupe applicant same person, same role? merge to one manager sees one card Gate 2 Fairness check job criteria only? if personal leaked, hold for a human Gate 3 Summary in plain words role + label, met must-haves + the gaps, with quoted lines Gate 4 Place the card yes → top maybe → lower no → parked, still reviewable, not deleted Manager review queue — card with summary, resume, reasons, and buttons advance · hold · pass (with a reason) — a human acts on every card every routed card logged to DDB with the label, reasons, and rubric version The screener routes cards — it never sends a rejection and never decides; a human acts on every card.
Fig 4. Four guardrails between the score and the routed card. Dedupe the applicant. Run the fairness check. Write the plain summary. Place the card for a human. Then a person advances, holds, or passes — the screener never decides.

Gate 1: dedupe the applicant

People apply more than once. The same person emails a resume and fills out the careers form, or applies on two job boards you both export from. Without a check, the manager sees the same candidate three times and wonders which card to trust. Gate 1 looks for an applicant who already has a card for this same role — matching on the contact details and the resume content, not the stripped name — and merges the duplicates into one card. The manager sees a single candidate with a note that they came in through more than one lane.

Dedupe is a courtesy and a correctness fix at once. It saves the manager’s time, and it stops a candidate from accidentally getting three bites at the queue just because they applied in three places.

Gate 2: the fairness check

Before a card is routed, the system double-checks the thing it cares most about: that the score was made on job-related grounds only. It confirms the personal fields were stripped, and it scans the reasons the reader produced for anything personal that slipped through — a mention of age, a school name buried in a quoted line, a comment about a gap that reads like an assumption about someone’s life. If the reasons are clean and tied to must-haves, the card passes. If something personal leaked in, the card is held for a human to look at instead of being routed on a tainted score.

This gate is cheap and it’s the backstop. The stripping in Part 2 does the heavy lifting; this check catches the leftovers before they reach a decision. Held cards go to the same needs-human pile, and the leak is logged so the stripping rules can be tightened.

Gate 3: the short, plain summary

A manager opening a queue of candidates shouldn’t have to re-read each resume to know why it’s there. Gate 3 writes a short summary: the role, the label, the must-haves that were met (with the quoted line for each), and the must-haves that were missing. That’s it. No “strong candidate, great culture fit” — that’s the kind of vague praise that hides bias. The summary is a plain accounting of which job requirements the resume met and which it didn’t, so the manager can decide on facts.

The summary is built from the reader’s structured result, so it can’t introduce a claim the resume didn’t support. If the reader marked a must-have as missing, the summary says missing. The manager always sees the full resume too — the summary is a fast way in, not a replacement for reading the candidate when they’re worth reading.

Gate 4: place the card, never reject

The last gate decides where the card goes — not whether the candidate is in or out. A yes lands at the top of the hiring manager’s review queue, where the strong matches cluster. A maybe lands lower in the same queue. A no is parked in a reviewable list, sorted so the near-misses are easy to revisit if the role stays open. Nothing is deleted, and crucially, no rejection email is ever sent by the screener. If a candidate is to be turned down, a human does that, deliberately, from the card.

The whole queue lives behind a Function URL the manager opens in a browser — one page, the cards in order, each with the summary, the resume, the reasons, and three buttons. Every card that gets placed is written to DynamoDB with its label, its reasons, and the rubric version used, so the round is auditable. The next post covers what those three buttons do, and why every one of them is the human’s action, not the system’s.

Next post: how a hiring decision actually gets made — advance, hold, and pass, each logged, with the override that lets a human overturn any label the screener produced.

All posts