HireOS
Blog

Method

Write the rubric before you read the first CV

The single change that makes AI screening defensible is deciding what counts before you see who applied. It is also the change most tools skip.

HireOS · · 5 min read

A grid of blank sticky notes on a wall, one being placed by hand

There is a version of AI screening that sounds impressive in a demo and falls apart in an audit: paste in the CVs, paste in the job description, ask a model who is best. It produces a ranked list. It even produces reasons. And it cannot tell you, three months later, why candidate forty-one was rejected — because the standard it applied existed only inside a single model call that nobody kept.

The fix is unglamorous and it is the whole thing: decide what counts before you look at who applied.

What a rubric actually is

Not a keyword list, and not a scoring formula. A rubric is the job description turned into a finite set of requirements, each one written so a person could check it, each one weighted, each one marked as essential or desirable.

For a senior backend role that might be:

RequirementWeightLevel
5+ years commercial Java25Essential
Production experience with Kafka or equivalent streaming20Essential
Cloud deployment, AWS preferred15Essential
Financial services domain15Desirable
Led or mentored engineers15Desirable
Degree or equivalent evidence of fundamentals10Desirable

Six lines. Ten minutes of thought. It is not sophisticated — and that is the point, because it is the thing you can put in front of a client, a candidate, or a tribunal and defend.

Why the order matters more than the content

Write the rubric after you have read fifty CVs and you have not written a rubric. You have written a description of the fifty CVs.

This happens quietly and it happens to everyone. You see that hardly anyone has Kafka, so Kafka becomes "desirable". You see three strong people from one competitor, so that background becomes a criterion nobody ever asked for. By the end you have a standard that was fitted to the applicant pool rather than to the role, and the client's actual requirement has quietly been negotiated away by the market.

Writing it first is what makes the rest of it honest. Everything after that is measurement.

The three properties that make it hold up

Once the rubric exists, three things have to be true of how it is applied, or you are back where you started with extra steps.

Every verdict carries its evidence. A requirement is not "met" because a model felt it was. It is met because a specific line in the CV says so, and that line is stored next to the verdict. This is the difference between a score you check in five seconds and a score you either trust blindly or ignore entirely. Most people ignore it, which is the correct response to an unsourced number.

Nobody is removed. The rubric ranks; it does not reject. The whole list stays visible in order, because the failure mode of automated screening is not a bad ranking — a bad ranking is obvious and recoverable. It is a good candidate who was deleted before a person saw them, which is invisible and permanent.

The same rubric applies to every candidate on the role. Including the ones uploaded three weeks later, including the one the client forwarded directly, including the one you are re-checking after editing the brief. If the standard moves, everyone gets re-measured against the new one, and you can see that it moved.

What this buys you that speed does not

Speed is what sells screening. Consistency is what makes it survivable.

The question that eventually arrives — from a client wondering why a candidate they liked never appeared, from a candidate asking why they were not put forward, or in a regulated sector from someone with a statutory right to ask — is always the same. On what basis?

"The system ranked them" is not an answer. "Against these six written requirements, agreed before applications opened, and here is the line in their CV that failed the essential one" is an answer. It is also, usefully, the truth.

The UK and EU are both converging on the same expectation for automated decisions in hiring: a person makes the call, the criteria are stated in advance, and the reasoning can be produced on request. A rubric written before the first CV, applied consistently, with evidence stored per verdict, satisfies all three without anyone having to build a compliance feature. It just falls out of doing it in the right order.

Doing it without a tool

None of this requires software. If you want to test whether it works on your desk, the manual version takes ten minutes:

  1. Before opening the applications, write the six to eight things that actually decide this role. Weight them to a hundred.
  2. Mark which are genuinely essential. Be strict — most briefs have two, not six.
  3. Score each CV against that list, and write down the line that justified each verdict.
  4. When you are tempted to change a weight halfway through, stop and ask whether the role changed or the applicant pool did.

You will find step four happens on nearly every role, and noticing it is most of the benefit.

Software makes this fast enough to do on all eighty CVs instead of the first fifteen. It does not make it right — the order does.


The screening in HireOS works exactly this way: the job description becomes a weighted rubric before any CV is read, every requirement verdict carries the quote from the CV behind it, and nobody is auto-rejected. If you want to see what your own brief turns into, that is the twenty-minute version of this article.

Keep reading

The offer

See it on a role you are working today.

Twenty minutes, your own job description, your own CVs. You judge it on the shortlist it produces.

Book a callNo card. Nothing to install.
  1. 1Twenty minutesYou bring one live role. We look at it together — no deck, no discovery questionnaire.
  2. 2Set up on the callYour job description becomes a rubric while you watch, and your own CVs go through it.
  3. 3Then 7 days aloneYou run it on real work and judge it on the shortlist, not on anything we said.