Proactive entitlement alerting

A proactive entitlement alert names a person, a program, a field on a record you already hold, and a published eligibility clause that field appears to satisfy. It does not award the benefit. It does not tell the person they are enrolled. The quality bar is that dual cite: the record field and the clause. If either side is missing, the alert stays empty on that point.

People who already appear in a housing, tax, or benefits file may qualify for a second program and never apply. The temptation is to treat a model score as permission to say they are eligible. That sentence is a determination.

The notice that goes out is an invitation to apply or to confirm facts. Phrases such as "you qualify" or "your benefit is ready" convert an alert into a decision the agency has not made. Keep the model in the candidate lane even when the match looks obvious.

Before any model scores a household, load two corpora that do not substitute for each other.

Records are the fields you already store: household size, reported income on a dated return, current enrollment in another program, address, age, last recertification date. Pull them from the systems of record you already operate. Salesforce Government Cloud, Microsoft, Tyler, and Accela appear in many agencies as the case, permitting, or constituent layer. Treat them as a class of systems that hold structured fields, not as a ranked stack. You need the field name, the value as stored, the as-of date, and the source system.

Clauses are the published eligibility rules: statute, regulation, program handbook, or posted guidance a reviewer could open. Load the clause identifier, the exact condition (income at or below a stated threshold, household size, residency, non-duplication), and the version or effective date. If the handbook and the statute disagree, load both and mark the conflict. Do not resolve the conflict in the alert.

Match logic can score a record against clauses. The quality outcome does not care how confident the score is. It cares whether the alert can point at a specific field and a specific clause. A high score with no field pointer is not an alert you can send.

When a required field is absent, leave it blank. Do not backfill income from a related program. Related-program income is a different definition, a different period, and often a different household composition. Inventing that number is how an invite becomes a false promise.

The alert payload should read like a reviewer's note, not like a letter.

Every alert needs a dual cite. On the record side: which field, which value as stored, which as-of date, which source system. On the clause side: which published rule, which condition, which version.

Here is an illustrative walk-through, not a measured result. A SNAP case file shows household size 3 and monthly gross income of $2,140 as of the last recertification. The published LIHEAP handbook for the current heating season lists a household-of-3 income ceiling that $2,140 appears to fall under. The alert cites SNAP household size 3, SNAP monthly gross income 2140 (recertification dated in the file), and LIHEAP Handbook section 3.2 (income ceiling, household of 3, current heating season). It does not say the household is approved for LIHEAP. If the handbook also requires a recent energy bill and that field is empty in the case file, the bill field on the alert stays empty. A worker reviews the dual cite, sees the blank, and either requests the bill or sends an invite that asks the household to attach it. The worker, not the model, sends the invite.

Empty stays empty. A blank required field is a stop, not a prompt to guess. Any message generator should refuse to release mail until a human has chosen the template and how to handle missing data.

The human send is the control. Queue the alert for a benefits worker or outreach specialist. They choose whether to invite, to request more facts, or to drop the candidate because the clause was misread. Until that person sends, nothing has been issued. Generated is not sent. Sent is a human action against a reviewed payload.

If the person later applies, an application completeness checker can catch missing attachments. If they need the rule in plain language, a citizen-facing policy assistant can explain the clause without restating the alert as a decision. Award or denial belongs in automated eligibility determination or with a human adjudicator, not in this outbound step.

Telling someone they are approved is the first overclaim. Approval still requires identity, residency, non-duplication, and often documents the existing record does not hold. The invite should say the agency believes they may be eligible and should apply, or that a worker would like to confirm a few facts. It should not say they are approved.

Treating the alert as issued is the second. Count sent invitations with a timestamp, a sender, and a template version. Do not count model outputs, queued alerts, or draft letters. If mail merges from the case system, require the same human confirmation you would require for a paper packet.

Inventing income from a related program is the third, and the most common silent failure. Program B's income definition may exclude a deduction that program A includes. Certification periods may not overlap. Copying the number fills a blank that should have blocked the alert. Leave the field empty and route to a worker who can ask.

A further risk is translating the invite before the facts are locked. A multilingual communication generator is useful after the human has approved the source text. Translating a draft that still contains "you qualify" multiplies the error.

Proactive alerting is upstream of application and upstream of award. Determination decides yes or no against a complete file. Completeness checking decides whether the file is ready to decide. Alerting only decides whether a worker should invite someone who has not applied.

Do not pipe alerts into an auto-adjudication queue. The person has not submitted. You do not have their attestation. You may not have consent to use program A's data for program B. Check the data-sharing authority before the model even scores. If sharing is not authorized, there is no alert, however strong the match would have been.

Keep the quality outcome measurable without inventing a take-up rate. You can measure the share of alerts that include both a field cite and a clause cite, the share with a required field left blank rather than inferred, the share of queued alerts a human sent, dropped, or returned, and time from alert to human action. You cannot honestly report a take-up rate from the alert stream alone. People apply for many reasons. The invite is one input.

You do not need a new system of record. Extract fields from the case, eligibility, or constituent platform you already run, with the field dictionary and as-of dates. Store the published clauses in a versioned library the alert can point to by identifier, not only in a prompt. Log the dual cite with the alert ID so a reviewer can reconstruct why the candidate appeared.

When the worker sends, write the send event back to the case record: template, language, date, and that the message was an invitation, not a determination. That write-back stops the next overnight job from alerting the same person as if they had never been contacted, and stops a later auditor from reading a queued alert as a notice the agency issued.