Write the job as requirements before you read anyone
Most shortlists are indefensible for a boring reason: nobody agreed what the job needed until after they started reading applications.
A job description is a marketing document. It is written to attract applicants, it is full of hedges, and it usually contains a list of ten things where three are genuine requirements and seven are wishes somebody added in a meeting.
Assessing candidates against that document produces mush. Assessing them against three weighted requirements produces a shortlist you can explain.
Separating the must from the nice
The exercise takes about twenty minutes and it is mostly argument. Which of these would you decline an otherwise excellent candidate for lacking? That question tends to collapse a list of ten into a list of three or four, and the collapse is the useful part.
The remaining items are not discarded. They become differentiators — things that separate two candidates who both clear the bar, rather than things that keep people off the list.
Making a requirement checkable
A requirement is checkable when you can say what evidence would satisfy it. "Strong communicator" is not checkable. "Has written documentation or specifications that other teams worked from" is: either the application shows that or it does not.
This is also what makes an evidence-led assessment possible at all. YoHe can find the passage that satisfies a checkable requirement. It cannot find the passage that satisfies a vibe, and when a requirement is vague the honest output is that the evidence is inconclusive.
Versioning matters more than it sounds
Requirements change mid-process, and that is fine as long as it is visible. What is not fine is a shortlist assessed against three different versions of the job with no record of which applied when. Every YoHe assessment is stamped with the requirement set that produced it.