Intake Filter¶

Intake workflow — instantiates Boundary Permeability Control

A front-door screen that sorts incoming requests, cases, or applications and routes each to the right queue, defers it, or redirects it before it consumes a service's capacity.

An Intake Filter is the general-purpose front door to a service, queue, program, or team. What makes it this mechanism is that it screens heterogeneous incoming requests — cases, applications, leads, tickets, patients-as-clients — for fit, eligibility, and priority, and routes each to where it belongs before it draws down scarce capacity: accept into a queue, defer to a waitlist, redirect out, or escalate the edge case. Unlike Clinical Screening, which is a specialized clinical assessment, the intake filter is the operational screen that any overloaded service puts at its entrance to protect throughput and get each requester to the right place.

Example¶

A legal-aid clinic can't take every case that walks in, so intake comes first. A caseworker screens each applicant for eligibility — income limits, case type, jurisdiction — and urgency. A qualifying eviction case with a hearing this week is fast-tracked into the priority queue; a matter outside the clinic's scope is redirected to a partner referral rather than simply refused; a borderline-eligibility applicant is escalated to a supervising attorney instead of being auto-rejected by the rule. When demand exceeds capacity, overflow goes to a managed waitlist rather than a slammed door. The boundary into the clinic's scarce attorney hours is thus tuned so the right cases cross, the wrong ones land somewhere useful, and the uncertain ones get a human look.

How it works¶

Screen against fit criteria. Each request is checked for eligibility, scope fit, and priority before it may enter.
Route the outcome. The decision is graded: admit to a queue, defer to a waitlist, redirect elsewhere, or escalate.
Keep a safe alternative. Deferrals and redirects give rejected requesters a real next step instead of a dead end.
Escalate edge cases. Borderline requests go to a human authority rather than being forced through a rigid rule.

Tuning parameters¶

Eligibility strictness — how tightly the fit criteria are drawn. Tighter criteria protect capacity but reject more genuine need at the margin.
Priority weighting — urgency versus first-come-first-served versus impact. Sets whose request crosses first when capacity is scarce.
Capacity cap and waitlist policy — where the overflow line sits and what happens past it, trading throughput protection against wait times.
Escalation threshold — how much ambiguity triggers a human review rather than an automatic decision.
Redirect-network breadth — how many external destinations exist for out-of-scope requests; a thin network turns "redirect" into "abandon."

When it helps, and when it misleads¶

Its strength is protecting a scarce service from overload while getting each requester to the right place quickly, so capacity lands on the requests that fit.

Its failure modes are the temptations of a gate with discretion over who gets served. Creaming — selecting the easy, cheap cases and shedding the hard ones — flatters throughput metrics while abandoning exactly the people a service exists for;^[1] false rejection turns away genuine need at the criteria's edge; and eligibility rules ossify as the real case mix drifts away from the one they were written for. The classic misuse is tuning intake to hit throughput or success-rate targets rather than to serve need, using eligibility rules as cover for creaming. The discipline that guards against this is auditing who gets rejected rather than only who gets served, keeping a real redirect path, and revisiting the criteria as demand changes.

How it implements the components¶

Intake Filter fills the screen-and-route components:

admission_control — it accepts, routes, defers, or redirects each incoming request: the intake decision.
filtering_rule — it screens by eligibility, scope fit, priority, and capacity.
safe_rejection_or_deferral_path — waitlists and partner redirects keep rejected requesters from being stranded.
exception_review_path — it escalates borderline cases to a human authority instead of auto-rejecting.

It performs no deep clinical or condition assessment — that's Clinical Screening — and no structural validation or transformation of the item itself, which is Data Import Validator.

Instantiates: Boundary Permeability Control — the intake filter is the general operational screen at a service's front door.
Sibling mechanisms: Clinical Screening · Content Moderation Gate · Semipermeable Membrane · Firewall · API Gateway · Border Checkpoint · Customs Process · Cleanroom or Airlock · Data Import Validator · Data Loss Prevention · Quarantine Process

References¶

[1] Creaming (or cream-skimming) — selectively serving the easiest, lowest-cost cases to improve measured performance while shedding harder ones. It is the characteristic pathology of discretionary intake, and the reason auditing rejections matters as much as auditing outcomes. ↩