Automated Application Expiration Timeout

The ATS is configured to reject in bulk every application still pending after 45 or 60 days.

Mechanism mech.automated_application_expiration_timeout Exogenous (no agency) Actor: systemNature: ruleVisibility: opaqueAgency zone: noneEvidence: proven

📐 On the canonical path

Machine work stays mechanical — Automation deduplicates, extracts and orders. It does not decide. Where a rule does end an application, the rule is stated and it is one a person would defend out loud.

This entry is one of the ways that commitment stops being kept.

⏳ What made this ordinary

A fixed number of seats (2024–2026) — The conditions that made hiring expensive were reversed; the number of positions was not. The contraction now runs through the hiring channel rather than the separation channel, which is why it is competition for a fixed and shrinking number of seats rather than a shortage of qualified people.

What it looks like

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

Bulk expiry, as logged · one batch, 312 applications reconstruction

02:00 Scheduled job: expire_stale_applications
02:00 Selecting applications with status=submitted and age>60d — 312 matched
02:00 Human review recorded on 0 of 312
02:01 Status set to Rejected — 312 notification emails queued

What to notice: The rejection email is real and the review it implies never happened. Timing is the tell: everyone in the batch is notified in the same minute.

Barriers where this mechanism operates

Observations this mechanism emits

What this does NOT establish

A bulk timeout rejection carries no assessment of the profile at all.

Causal relations

mech.stale_or_orphaned_job_requisition Stale or Orphaned Job Requisition masks

Interventions targeting this mechanism

int.distinct_closure_status_for_unreviewed_applications Distinct Closure Status for Unreviewed Applications Give the ATS a terminal status for an application closed without a human opening it, distinct from the one used for a reviewed decline, bind it into the notification template, and count it on the requisition.

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 on14: entity.artifact1Barrier12Mechanism1
Borne on by7: Mechanism2Pattern1Intervention4

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.

ATS vendor

What reaches them: A scheduled job, the records matching status and age, and a count of notifications queued. Review activity is a stored field, and the threshold does not consult it.
What it means from there: Records past the threshold are stale queue state. Nothing in the schema separates an application nobody opened from one that was assessed and declined.
What happens next: Runs the job at the customer's configured threshold and sends the configured template. The setting ships enabled, and switching it off is a customer action.

Recruiter

What reaches them: The queue depth on the requisition drops overnight, and applications the recruiter never opened now carry the status Rejected.
What it means from there: The backlog cleared at the threshold rather than through screening. The binding constraint was never a decision, but how many applications fit into the week.
What happens next: Works the current inbound, which is what time-to-fill is measured against. The expired batch is not itemised anywhere the recruiter is asked to account for it.

Candidate

What reaches them: A rejection weeks after applying, in the same wording used for a rejection after an interview.
What it means from there: A decision about the application. Nothing in the message separates a person's decision from a scheduled status change, and nothing says whether the role was live.
What happens next: Records the date and stops following up. Whether to apply to this employer again is decided on a message that carries no reason.

Public policy and industry standards

What reaches them: The class of practice rather than the batch: an application status changed by rule, in jurisdictions where automated decision-making carries disclosure or explanation duties.
What it means from there: A scheduled expiry is a decision only where the framing counts it as one. Where the rule lives on a configuration screen with a default, no filing records that a decision was made.
What happens next: The available lever is a rule written for a class of systems — disclosure, explainability, a right to human review — and it arrives on a cycle longer than the threshold it would govern.