Eligibility systems in public programs have a design constraint most commercial systems do not: every determination can be appealed by the person it affects, and at that hearing the agency has to explain how the rule applied to the facts. That single requirement rules out a large class of otherwise reasonable architectures.
The hearing is the specification
It is worth writing the requirement in the form it will actually take. A claimant sits across from a hearing officer and asks why they were denied. The agency representative must state which rule applied, which facts were used, where those facts came from, and how the rule produced the outcome.
Any system that cannot produce those four things on demand, for any determination, in language the claimant can follow, is not deployable regardless of its accuracy. This is not a preference. It is the operating environment.
Accuracy is what the model optimizes. Explicability is what the program requires.
What this means architecturally
Eligibility rules are written in policy and should be encoded as rules, deterministically, with the policy citation attached. That part should not be learned, because the requirement is to apply the rule as written rather than to approximate how it has historically been applied.
- Rules encoded explicitly, each carrying its policy citation and effective dates
- Facts entering the determination with their source document and date of receipt
- The determination recorded as a trace: rule, facts, comparison, outcome
- Effective-dated rule versions, so a past determination is evaluated under the rule in force then
- Notices generated from the trace, never from free-form summarization
Where models are genuinely useful here
Not in the determination. In everything around it, where the workload actually is.
Reading submitted documentation and proposing structured facts — income figures, household composition, dates — with span links, for caseworker confirmation. That is the largest time sink in most programs and it is well suited to extraction with human confirmation.
Drafting the notice from the determination trace in plain language at a readable grade level, which is both a legal requirement in many programs and something agencies struggle to do consistently. Constrained to the trace, this is safe and it measurably improves comprehension.
Where a benefits program's time actually goes
Relative weighting from delivery practice, not a measured statistic — shown to rank where attention belongs.
The equity dimension is a data question
Programs are rightly asked whether automation produces disparate outcomes. That question can only be answered if determinations are recorded as traces, because the analysis needs to distinguish a difference in outcomes caused by the rule from one caused by which facts were successfully extracted.
A system that records only outcomes can report a disparity and cannot locate its cause. A system that records traces can show whether the gap came from the policy, from documentation burden, or from an extraction step that performs worse on certain document types — and only the last of those is an engineering fix.
The determination trace, concretely
A trace is not a log. It is a structured record designed so that a person who was not present can reconstruct the decision completely.
| Trace element | Example | Why it is needed at hearing |
|---|---|---|
| Rule and version | Income test, policy version effective a stated date | Establishes the standard actually applied |
| Fact and source | A monthly income figure from a named document received on a date | Lets the claimant contest the fact rather than the outcome |
| Derivation | How countable income was computed from gross | Most disputes live here, not in the threshold |
| Comparison | Computed value against the applicable limit | The mechanical step, shown rather than asserted |
| Exclusions considered | Which disregards were evaluated and their outcome | A missed disregard is a frequent reversal ground |
| Actor | Automated, or a named worker with an override rationale | Determines who explains the decision |
The exclusions row is the one most often missing. A system that records only the criteria that failed cannot show that the disregards were evaluated at all, and "we considered it" without a record is not an answer at a hearing.
Effective dating is not optional
Policy changes. A determination made in March under the rules in force in March may be reviewed in November after two amendments. If the system evaluates the appeal under current rules, it produces a different answer and the agency cannot explain the original one.
Effective-dated rules solve this and require discipline: every rule carries the dates it was in force, determinations record which version applied, and re-running a historical determination uses the historical rule set by default. A "what would happen today" comparison is available separately and clearly labeled as such.
This also produces something agencies rarely have and consistently want — the ability to answer what a policy change did. Re-running a historical caseload under a proposed rule gives an impact estimate grounded in actual cases rather than modeled populations.
Where the workload really is
Eligibility determination itself is fast once the facts are known. The program's cost sits in getting the facts: chasing documentation, reading what arrives, keying it, and following up on what is missing or illegible.
This is the automation target, and it is both higher-value and lower-risk than the determination.
- Document classification — what did this person send, so it routes correctly
- Fact extraction with spans — income figures, dates, household members, proposed for worker confirmation
- Completeness checking — what is still missing for this application type, generated from the rule set rather than a static checklist
- Legibility triage — flagging submissions that cannot be read before they sit in a queue for two weeks
- Notice drafting — plain-language output generated from the trace at a controlled reading level
None of these change a determination. All of them shorten the time between application and decision, which is the outcome claimants experience and the one most programs are actually judged on.
Notices are where plain language earns its keep
Program notices are frequently written at a reading level well above the population receiving them, assembled from fragments, and structured around the agency's process rather than the recipient's question. The result is appeals filed because the notice was not understood, and appeals not filed for the same reason.
Generating the notice from the determination trace, in plain language, at a controlled reading level, is a genuinely good use of a language model — the content is fully specified, the transformation is linguistic, and the quality improvement is measurable.
The constraints are the familiar ones. The generator receives the trace, not the case file. Every fact in the notice maps to a trace element. Required legal language is inserted verbatim rather than paraphrased, and the paraphrasable portion is bounded explicitly. Translations are generated from the same trace rather than from the English notice, so a translation error cannot compound a drafting error.
Answering the equity question with evidence
Programs are asked whether automation produces disparate outcomes, and the honest answer requires the trace layer to exist.
With traces, the analysis can separate three distinct causes. The rule itself may produce different outcomes across groups, which is a policy question and not an engineering one. The documentation burden may fall unevenly, which shows up as differential rates of missing-information denials. Or the extraction step may perform worse on certain document types — handwritten forms, non-English documents, photographs rather than scans — which is an engineering problem with an engineering fix.
Only the third is something the technical team can fix, and without traces all three are indistinguishable from one another. That is the strongest practical argument for building the trace layer even in programs where no hearing is likely.
Surge is the operating condition, not the exception
Public programs do not experience steady demand. Enrollment periods, policy changes, disasters, and economic shifts produce volume that arrives faster than staffing can respond, and the backlog created in a surge takes months to clear.
This shapes what automation is worth. Capability that scales with volume — classification, extraction, completeness checking — delivers most of its value precisely when the program is under the most pressure. Capability that requires the same human review per case regardless of volume delivers least value exactly then.
It also argues for building the extraction path before the determination path, because extraction is the step whose cost scales linearly with applications and whose quality degrades most under time pressure when done by hand.
Caseworker adoption decides the outcome
Eligibility staff have generally seen systems arrive with promises and leave with workarounds, and their skepticism is earned rather than obstructive.
What changes it is not training. It is whether the system makes their accountability easier or harder. A caseworker is answerable for the determination; a tool that proposes facts they can verify in one click reduces their exposure, and a tool that produces conclusions they cannot inspect increases it. Adoption follows that calculation almost perfectly.
Practically: show the source document alongside every extracted fact, make confirmation one action and correction two, never auto-advance a case past a human, and surface what the system was unsure about rather than hiding it behind a confidence score nobody was taught to read.
The notice is the program's public face
Most citizens experience the program through a single document, and its quality determines whether they understand a decision, comply with a request, or file an appeal they did not need to file.
Improving notices is unusually high-leverage and unusually neglected, partly because the required legal language is inflexible and teams assume the whole document is. It is not. The explanatory portion — what this means, what you must do, by when, and how to contest it — is fully within the program's control and is where comprehension is won or lost.
Generated from the determination trace at a controlled reading level, in the recipient's language, that portion improves measurably. It is the rare change that reduces cost and improves outcomes at once, because a notice that is understood produces fewer calls, fewer unnecessary appeals, and fewer avoidable terminations.
Frequently asked questions
Because historical determinations include errors and inconsistencies, and a learned model would reproduce them while making them harder to correct. Where policy is written down, encode the policy.
They should see a plain-language version of it in the notice. The full trace is what the agency brings to the hearing.