Automated eligibility determination

A determination is ready only when it cites both the rule clause and the submitted field that met it. A yes with a clause and no field is not a decision you can defend. A no that names a threshold but cannot point to the income, household size, or residency value in the packet is the same failure in the other direction. If a required field is missing, the determination stays empty. Do not fill the gap. Do not infer eligibility from a nearby document the applicant uploaded for a different purpose.

You still issue the decision on cases the rulebook does not cover in a mechanical way. You still own the appeal. Automation on a standardized benefit program is a quality check: the same clauses, the same fields, the same dual cite every time. It is not a substitute hearing officer.

The test at the desk is narrow. Open the rationale. You should see a numbered clause from the loaded rulebook and a named field from the application, with the values that were actually submitted. If you cannot see both, you do not stamp it.

Work starts by loading two sources together: the program rulebook that is in force for this filing date, and the application as submitted. The rulebook is the version your agency published, with clause identifiers that match what hearings and quality review already use. The application is the structured packet: fields, attachments already mapped to those fields, and nothing the applicant did not provide.

Do not load last year's income table against this year's application. Do not load a policy memo that has not been encoded as a numbered clause. The model can only cite what you loaded. If the clause is not in the loaded rulebook, it cannot appear in the rationale.

Case systems from vendors such as Salesforce Government Cloud, Microsoft, Tyler, and Accela already hold the application and the case chronology. Treat those platforms as a class: the system of record for the packet, the issue path, and who signed. The rule-inference step sits beside them. It reads the loaded rulebook and the loaded fields. It does not replace your case file.

Before you ask for a determination, run the packet through an application completeness checker. Completeness is not eligibility. A complete packet can still fail a clause. An incomplete packet should never receive a yes or a no that pretends the missing value was known.

Applicants will keep asking what they might qualify for. A citizen-facing policy assistant can explain published rules in plain language. That assistant does not determine this case. Keep those jobs apart so a chat explanation never becomes a hidden eligibility decision.

When a required field is blank, the correct output is a blank determination plus a list of which fields blocked the run. The model does not estimate income from a bank screenshot, a tax return uploaded as "other," or a number mentioned in a case note. Filling a missing income field is the failure that looks helpful and wrecks the audit.

If you let the model complete income, you have created a value the applicant did not submit and that no clause can honestly cite. Quality review will ask where the number came from. The answer cannot be that the model thought a nearby attachment was close enough.

The same rule applies to household size, residency, disability status, and any other gated field in the program. Dual cite means both sides exist. No field, no cite. No cite, no determination.

One path through a heating-assistance packet: household size is 3, the wage field shows 2,140 for the month, and residency is a checked county field already mapped to a utility bill in the packet. The model returns eligible, citing clause 4.2.1 (income at or below the published table for a household of three) against the wage field as submitted, and citing clause 2.1 (residency in the service county) against the county field. You can issue that. If the wage field is empty and a PDF pay stub sits in attachments unmapped, the model returns empty on the income test. You do not type 2,140 into the field because the stub looks like that amount. You send it back so the applicant or a clerk maps the field, or you work the case as a non-standard review if the program lets an officer read the stub under a different, named clause.

On a standardized program, once dual cites are present, you issue. Issuing is still your act. The rationale is the draft you accept. If the rationale is wrong, you reject it and record why, in the same clause language the hearing will use.

Non-standard cases do not get a stretched rule. You already know the shapes: mixed households the table does not describe, seasonal or self-employed income with no matching field, overlapping programs with an exception memo that was never encoded, a pending immigration document, a protective-order address the public rulebook does not discuss. Route those. Put them on your desk or a specialist queue. The model should say it could not determine, and name the clause it could not apply, rather than force a yes or a no.

A yes with no cited field is the other failure you stop in review. It often arrives as a confident paragraph that "meets income requirements" with no pointer to the earned-income field or to the table cell. Do not issue that. Send it back as an incomplete rationale. If your shop cannot show the field, you do not have a quality determination.

After a clean issue, other entitlements may be in play. Proactive entitlement alerting is a separate job that starts from a determination you already own, not a second hidden eligibility engine running on a looser packet.

The model is not the appeal. A claimant who disputes the finding is disputing your agency's decision. The hearing packet needs the dual cites, the loaded rulebook version, and the submitted fields as they stood on the determination date. It does not need a transcript of model confidence.

If staff treat the model's text as the appeal decision, you end up with two records: the official one you signed, and an unofficial one that quality review cannot reconcile. Stop that at the first review. The officer of record issues, amends, or reverses. Automation can assemble the file. An audit trail auto-documenter is the right place to freeze what was loaded, what was cited, and who issued, so the hearing is looking at the same objects you used.

When you reverse on appeal, you reverse in the case system. You do not argue with the model. You record the clause and the field, or the missing field, that the hearing relied on, and you keep the original dual-cite rationale in the file so the change is visible.

Daily practice stays narrow. Load this year's rulebook with this packet. Determine only with dual cites. Leave blanks when a required field is missing. Issue the standard case or route the rest. Own the appeal. That is the quality bar.