Eligibility Criteria¶

Eligibility policy document — instantiates Domain–Codomain Delimitation

Codifies, as a published rule set, exactly who or what qualifies as a valid input to a policy, service, or program — turning a fuzzy "who is this for" into a decidable membership test.

Eligibility Criteria define the input domain of an institutional function — a benefit, program, service, or policy pathway — by publishing the rules that decide who or what qualifies. What makes it this mechanism is that it is a standing, written, defensible membership specification, not a runtime check or a type: it lives as a document that applicants can read, caseworkers can apply consistently, and appeals can be argued against. It is purely input-side and purely about membership — it says who may enter, on what thresholds and conditions, but nothing about what the program outputs or how out-of-domain cases are handled. Its whole value is converting "we help people in need" into "a household qualifies if and only if it meets these enumerated conditions."

Example¶

A rental-assistance program must decide which applicants it serves. Its Eligibility Criteria fix the domain in checkable terms: household gross income at or below a set fraction of the area median (illustratively ≈130% of the federal poverty line), residence within the jurisdiction, and a documented rent burden above some threshold. An applicant at ≈128% with proof of residence is in the domain; one at ≈140% is out, decidably and identically no matter which caseworker reviews the file. Because the criteria are written and public, the applicant at 140% can see exactly why they don't qualify — and, if a rule was misapplied, has something concrete to appeal. The criteria have done the archetype's job: made "who this program is for" a membership test rather than a discretionary read.

How it works¶

The criteria decompose eligibility into enumerated conditions — thresholds (income, age, residency), categorical requirements (status, documentation), and combining logic (all-of, any-of, exceptions) — each stated precisely enough that two reviewers reach the same verdict on the same file. Published as policy, they are simultaneously the domain definition, the fairness instrument (like cases treated alike), and the artifact a decision can be justified or contested against. The emphasis throughout is decidability: a criterion a caseworker has to interpret is a criterion that lets the domain drift case by case.

Tuning parameters¶

Threshold placement — where each cutoff sits (income line, age, residency length). Moving a threshold trades reach against cost and against sharp-edge unfairness at the margin.
Bright-line vs. discretionary — whether criteria are hard rules or leave room for caseworker judgment. Bright lines are consistent and appealable; discretion fits hard cases but reopens the door to drift and bias.
Documentation burden — how much proof an applicant must supply to demonstrate membership. Heavier proof reduces error and fraud but excludes qualifying people who can't easily produce it.
Exception structure — whether hardship or edge cases route to a carve-out or are simply excluded. Exceptions add fairness but complexity and inconsistency.

When it helps, and when it misleads¶

Its strength is consistent, transparent, contestable membership decisions: everyone can see the rule, and like cases are treated alike. Its failure modes cluster at the edges. Sharp thresholds create a cliff effect — an applicant just over the line loses everything an applicant just under gets, a discontinuity that can invert the incentive the program intended.^[1] Heavy documentation requirements quietly shrink the effective domain below the stated one, excluding people who qualify on paper but can't prove it. And criteria age: a threshold pegged to stale figures slowly drifts out of alignment with the population it was meant to serve. The disciplines are to soften cliffs with tapering where feasible, to distinguish the stated domain from the effective one by watching who is filtered out at the proof step, and to hand hard cases to a defined exception path rather than absorbing them into vague discretion.

How it implements the components¶

input_domain — the criteria are the definition of who or what validly enters the program: the population it is for.
membership_criteria — the enumerated thresholds, categories, and combining logic that make membership a decidable, defensible test rather than a judgment.

It defines input membership only; it does not declare what the program delivers or refuses (Service Scope Statement, on the output/deliverable side), enforce the check at intake (Input Validation Gate), route the ineligible to alternatives (Unsupported Case Triage Workflow), or revise itself over time (Scope Change Review).

Instantiates: Domain–Codomain Delimitation — Eligibility Criteria are the published input-domain rule for an institutional function.
Sibling mechanisms: Input Validation Gate · Unsupported Case Triage Workflow · Service Scope Statement · Clinical Indication Criteria · Type Signature · Output Schema · Output Validation · Contract Test Suite · Model Applicability Card · Scope Change Review

Notes¶

Eligibility Criteria are the rule; the intake step that applies them to a specific applicant, gathers documentation, and issues a decision is the Input Validation Gate. Keeping the two apart matters: the criteria can be revised (a threshold updated) without rebuilding the intake process, and the intake process can be improved (less friction, better proof-collection) without reopening the policy. Confusing the two is how a program ends up with the effective domain — set by intake friction — silently diverging from the stated domain in the policy.

References¶

[1] The cliff effect (benefits cliff) — a sharp eligibility threshold at which a small increase in, say, income causes a large, discontinuous loss of benefit. It is a real, well-documented consequence of bright-line input boundaries and a standard argument for tapering benefits across the boundary rather than switching them off at a point. ↩