Disqualifying criteria published with the posting

Every criterion the automated filter can reject on — a required acronym, a named certification, a years-of-experience threshold — is listed in the posting as a disqualifier, so a deterministic gate is legible before the application is written.

Intervention int.disqualifying_criteria_published_with_the_posting Actor: employer policy Scope: organizational Cost: low Evidence: supported

What it looks like when this intervention is in place

Composite excerpts, written to be typical rather than copied. No particular message, company or person is quoted here.

The block that goes above the requirements reconstruction

Filtered automatically. An application is not read if it lacks any of: the string "Kubernetes" or "K8s"; 5+ years dated employment in backend engineering; work authorisation in DE, PL or UA.

Everything below this line is read by a person and weighed. Nothing below it rejects on its own.

If the tooling you used is called something else, write both names. The filter matches the string, not the work.

What to notice: The filter is not being removed — it is being published. What changes is who can see it: a rule that rejects on an exact string costs nothing to state, and stating it turns a silent rejection into a decision the candidate makes before spending the hour.

What this targets

Expected effects

mech.automated_keyword_qualification_filter stops operating unseen: the rule that rejects is the rule that was published
An application withheld against a stated disqualifier costs neither side a review

What to measure

knockout_criteria_published_rate
applications_per_opening

Reached without being linked

The relations above are one step. This is what the entry reaches only by walking through them — the shape of it, since the list runs long in a registry this cross-referenced.

Bears on26: Observation8Barrier13Mechanism5

Walk it in the graph →

From each side

The same entry from inside each position that meets it: what reaches them, what it means from there, and what happens next given what they control.

Employer policy

What reaches them: The knock-out rules already configured in the ATS, written out as a list, and the count of applications each one rejected last quarter.
What it means from there: The list is a description of the filter as it actually runs, not of the role as it was imagined — and a rule nobody is willing to publish is a rule that will not survive being read.
What happens next: Publishes the knock-out list, and strikes the rules that cannot be justified once they are written next to the work.

Candidate

What reaches them: A short block naming exactly what will reject the application without a person reading it.
What it means from there: The gate is a string match, and a rejection against it says nothing about the work — it can be cleared by naming the same tool by both its names, or it cannot be cleared at all, and either way that is known now.
What happens next: Applies against a gate it can see, or does not, and stops reading a filter rejection as a verdict on the work.

ATS vendor

What reaches them: Customers asking for the configured knock-out rules to be rendered into the posting template automatically.
What it means from there: The rules are already structured data in the requisition; rendering them is a template change, not a product, and the reason they were never shown is that nothing asked.
What happens next: Renders the knock-out block from the requisition config, so the published list cannot drift from the filter that runs.