Why work authorization should be a hard filter, not a preference

What is the difference between a filter and a preference?

A filter removes candidates from consideration before anything else runs. A preference adjusts their score. The distinction sounds academic until you look at what a scoring system does with a strong candidate who fails one criterion: it ranks them below perfect matches and above weak ones, which on a thin requirement means position two.

Position two gets submitted. That is the entire failure mode, and it does not require anyone to make a mistake — the system did exactly what a weighted ranking is supposed to do.

A hard filter has no such behaviour. A candidate whose authorization does not satisfy the requirement is not scored at all, does not appear in the shortlist, and cannot be recovered by strength elsewhere.

Why do people build it as a preference anyway?

Because the data is messy and a filter is unforgiving. Work-authorization fields are frequently blank, stale, or free-text — "GC EAD", "H1 transfer ok", "USC/GC only" — and a strict filter on messy data removes candidates who would actually have qualified. Scoring feels like the tolerant, pragmatic choice.

It is the wrong response to a real problem. The answer to ambiguous data is to fix the extraction and to treat "unknown" as exclusion, not to soften the gate. Excluding an eligible candidate because their record is incomplete costs you a submission. Including an ineligible one costs you a vendor relationship.

The second reason is demo pressure. A hard filter makes shortlists shorter, and a shorter shortlist looks worse in a product demonstration than a longer one. That is a bad reason to build anything.

What does getting it wrong actually cost?

It is asymmetric in a way that makes the decision easy. A false exclusion costs one submission on one role. A false inclusion costs the vendor’s time, the consultant’s time, your credibility with a prime you may have spent years cultivating, and — on a layered chain — often the candidate’s eligibility for that role entirely.

There is also a compliance dimension. Submitting a candidate whose authorization does not match a requirement generates a record of having done so. That record is discoverable, and "our ranking model weighted it at 0.7" is not a defence anyone wants to offer.

Where in the pipeline should the gate run?

Everywhere a candidate could move forward, not once at the start. In practice that means four distinct places, and skipping any of them reopens the hole.

• Shortlist construction — ineligible candidates never enter the candidate set.
• Scoring — the filter runs before ranking, never as a ranking input.
• Outreach — no ineligible candidate is contacted about a requirement they cannot take.
• Submission packaging — a final gate immediately before anything leaves the system.

How should unknown or ambiguous authorization be handled?

As exclusion, with a visible reason. A candidate whose authorization field is blank, unparseable, or expired is not eligible until someone establishes otherwise, and the shortlist should say so rather than silently dropping them.

The distinction matters operationally: "excluded — authorization unknown" is a work item a recruiter can clear in two minutes, while a silent drop is invisible and permanent. The gate should generate work, not hide candidates.

Expiry deserves specific attention. An EAD or OPT status with a date attached becomes wrong on a known day, and a system that checks status without checking validity will happily submit someone whose eligibility lapsed last month.

Should there be an override for edge cases?

No, and this is the part that generates the most pushback. Every override mechanism gets used, then gets used routinely, then becomes the path of least resistance under time pressure. A gate with an override is a preference with extra steps.

The legitimate edge cases — a consultant whose status is changing, a requirement whose stated authorization is negotiable — are real, and they should be handled by changing the data, not by bypassing the check. If a requirement genuinely accepts H1B transfers, that belongs in the requirement record where every subsequent decision can see it. If a consultant’s status has changed, update the consultant.

That is slower in the moment and correct every time afterwards, which is the trade a hard filter is making.

How do you prove the gate held?

By writing every exclusion to an immutable log alongside the submissions. An audit trail that records only what was sent answers the wrong question; the useful record is what was blocked, when, and on which criterion.

Hash-chaining that log matters more here than elsewhere. The value of a compliance record is entirely in its resistance to being edited after the fact, and a chained log makes a retrospective change detectable rather than merely discouraged.

Candidate PII should stay out of both logs and URLs while this happens, which is a constraint on how the record is written rather than an argument against writing it.

What does this demand of requirement parsing?

That work authorization is a first-class structured field with a confidence score, not a substring search over a job description. A parser returning "H1B" with low confidence from a mangled email should escalate that field to a larger model rather than proceeding, because the gate downstream is only as good as the value it is comparing against.

This is one of the clearest cases for per-field confidence rather than a single document-level score. A requirement can be perfectly clear about skills and ambiguous about authorization, and the correct response is to re-run the ambiguous part, not the whole document.

What are the reasonable objections?

The strongest one is that requirements lie. A posting says "USC/GC only" because the vendor copied a template, and the end client would in fact take an H1B transfer. A hard filter applied to a wrong requirement excludes eligible candidates for a role they could have taken, and nobody ever finds out.

That objection is correct and it does not argue for a softer gate. It argues for treating the requirement’s stated authorization as a field that can be corrected — by a recruiter who has confirmed it with the vendor, recorded with who confirmed it and when. The gate then runs against corrected data and stays hard.

The second objection is speed. Checking with a vendor takes a day, and a hard filter means that day is spent before the shortlist exists. In practice the standing shortlist absorbs most of this: candidates are pre-filtered against each authorization status independently, so a corrected requirement re-resolves against an existing set rather than triggering a fresh search.

The third is that shortlists get shorter and shorter shortlists look worse. They do look worse. They are also entirely submittable, which is the only property of a shortlist that matters, and a recruiter who trusts every row moves faster than one who checks every row.