Skip to content

Benefits Automation: From Rules as Code to Caregiver Discovery

Over $60 billion in public benefits goes unclaimed annually5. Participation in safety net programs ranges 40-60%, with eligible non-participation rates of 16-72% depending on the program5. The gap is not lack of programs. It is lack of discovery, navigation, and follow-through.

This page synthesizes the research on automating benefits eligibility — from Rules as Code to knowledge graphs to neuro-symbolic verification — and identifies the gap that GiveCare's approach fills: no prior system combines caregiver-specific SDOH assessment with benefits eligibility determination and AI-guided discovery.

Rules as Code: Translating policy into executable logic

The Beeck Center experiments

The Beeck Center at Georgetown University documented 4 LLM experiments translating SNAP and Medicaid policy into executable rules across 7 states1. The experiments validated that LLMs can parse the complex conditional logic embedded in policy documents — nested eligibility criteria, state-specific exceptions, categorical exclusions, and income calculation methodologies.

Key findings relevant to GiveCare:

  1. Feasibility is proven. LLMs can translate natural-language policy into structured eligibility rules with sufficient accuracy for screening (not final determination).
  2. Cross-state variation is the primary challenge. The same federal program (e.g., SNAP) has different eligibility rules in every state. Asset limits, income disregards, categorical eligibility expansions, and application procedures vary by jurisdiction. GiveCare's state-specific configuration architecture addresses this directly.
  3. Structured validation is required. LLMs catch the main logic but miss edge cases. The Beeck Center recommends pairing LLM translation with human policy-expert review — a workflow GiveCare implements through its human-in-the-loop validation for eligibility rules.
  4. Rules-as-code reduces errors. Compared to caseworker-only processes, automated rule translation produces fewer eligibility determination errors. The benefit is not replacing caseworkers but giving them — and users — a structured starting point.

What Rules as Code does not solve

Rules as Code translates individual program rules into executable logic. It does not:

  • Model interactions between programs (how enrolling in one affects eligibility for another)
  • Represent caregiver-specific eligibility pathways (most rules are written for the benefit recipient, not their caregiver)
  • Handle benefit cliffs (where small income changes trigger large benefit losses)
  • Connect eligibility to discovery (knowing someone qualifies is useless if they do not know the program exists)

These gaps require additional infrastructure.

Knowledge graphs: Modeling program interdependencies

IBM Research demonstrated how knowledge graphs can model the complex relationships between health and social programs2. Where Rules as Code handles individual program logic, knowledge graphs represent the connections between programs.

Key capabilities:

Cross-program reasoning. Knowledge graphs enable reasoning about how enrolling in one program affects eligibility for others. Medicaid enrollment may automatically qualify a caregiver for certain HCBS waiver services. SNAP enrollment may satisfy categorical eligibility for other programs. These interactions are invisible in flat rule systems but explicit in graph representations.

Entity resolution. Programs have different names across jurisdictions. The same service may be called "consumer-directed personal assistance" in New York, "self-directed services" in Colorado, and "participant-directed care" in Oregon. Knowledge graph entity resolution handles this variation, enabling GiveCare's cross-state service matching.

Cliff detection. Graph-based representations can model income thresholds where benefits drop off across multiple programs simultaneously. A caregiver earning $1,200/month who gets a $100 raise may lose benefits worth $400/month across three programs. Cliff detection requires seeing the full program graph, not individual program rules.

Fraud and integrity. The IBM work focused on program integrity (preventing fraud), but the same graph infrastructure supports the inverse problem: ensuring eligible people actually receive benefits. The structural representation is the same; the query direction is different.

Neuro-symbolic eligibility: The best of both approaches

The neuro-symbolic framework applied to CalFresh (SNAP) eligibility3 demonstrates the architecture that combines LLM flexibility with rule verification:

Stage 1 — Neural interpretation. The LLM interprets user input. A caregiver who says "I work part-time at Walmart and my mom gets Social Security" provides information that needs to be mapped to structured eligibility fields: employment status, income source, household composition, and program enrollment.

Stage 2 — Symbolic verification. The interpreted input is checked against formal eligibility rules. This stage is deterministic — given the structured inputs, the eligibility determination follows the rules exactly. No hallucination, no approximation.

The separation matters for accountability:

  • Every eligibility determination traces to specific rules and specific input facts
  • The system can explain why someone qualifies or does not qualify, in terms a user can understand
  • Errors are diagnosable: was the input misinterpreted (neural error) or was the rule misapplied (symbolic error)?

The CalFresh application showed that this neuro-symbolic approach achieves higher accuracy than either pure-LLM or pure-rule-based systems on complex eligibility scenarios with exceptions and edge cases3.

HCBS Taxonomy: The classification standard

The CMS Home and Community-Based Services taxonomy defines 18 service categories and 60+ subcategories4 — the standard classification for services delivered to Medicaid beneficiaries in home and community settings.

Before this taxonomy, no consistent language existed for HCBS services across states. The same service had different names, different descriptions, and different scopes in every state Medicaid program. The taxonomy solved this for the system. GiveCare extends it to the user.

The taxonomy's hierarchical design allows GiveCare to present services at appropriate levels of detail:

  • Discovery level: "You may qualify for home-based care services" (top category)
  • Navigation level: "Specifically, personal care attendant services and home modifications" (subcategory)
  • Action level: "In your state, this is called [program name] and you apply at [specific URL/phone]" (state-specific mapping)

The taxonomy maps to specific waiver authorities and funding streams, which is why GiveCare's benefit-program linkage logic uses it as the classification backbone.

The gap: $60B unclaimed, and why

The numbers

  • $60 billion+ in benefits goes unclaimed annually5
  • Safety net program participation: 40-60%5
  • Eligible non-participation rates: 16-72% depending on program5
  • 22% of benefit recipients take negative actions (declining raises, reducing hours) specifically to avoid losing benefits6
  • 62% report feeling stuck in their current economic situation due to benefit-cliff fears6

Why the gap persists

The $60 billion gap exists because three problems compound:

  1. Discovery failure. People do not know programs exist. 98 federal and state programs serve caregivers. Most caregivers do not know they qualify for any of them. No single source maps all programs. Discovery requires knowing what to search for, which requires knowing the system — a circular dependency.

  2. Navigation failure. Even when a program is discovered, applying requires navigating bureaucratic processes optimized for the system, not the user. Documentation requirements, application forms, interview scheduling, and verification procedures are designed for administrative efficiency, not user accessibility.

  3. Cliff avoidance. The 22% who take negative actions to avoid benefit cliffs6 are making rational decisions given the information available to them. Without visibility into how income changes affect the full portfolio of benefits, avoiding the cliff is safer than risking a gain that triggers a larger loss.

What no prior system combines

Individual components of the solution exist:

Component Exists in Gap
Rules as Code Beeck Center experiments1 Program-by-program, not cross-program
Knowledge graphs IBM Research2 Enterprise/government context, not user-facing
Neuro-symbolic eligibility CalFresh application3 Single program, not portfolio
Service taxonomy CMS HCBS4 Classification, not discovery or navigation
Participation data Code for America5 Documents the gap, does not close it
Cliff analysis AEI6 Policy analysis, not user-facing tool

No prior system combines:

  • Caregiver SDOH assessment (understanding the caregiver's situation across all six zones)
  • Cross-program eligibility determination (checking 98 programs simultaneously)
  • Cliff-aware portfolio analysis (modeling how changes affect the full benefit portfolio)
  • AI-guided discovery and navigation (presenting programs one at a time with clear next steps via SMS)

GiveCare's 98-program database, zone-based screening, and benefits discovery fill this gap. The SDOH assessment identifies which zones are pressured. The eligibility engine checks all applicable programs. Mira presents one program at a time, with the specific next step, over SMS — the channel that reaches the 40% of the target population who will not install an app (see SMS Accessibility).

Implications for GiveCare's architecture

The research points to a specific architecture:

  1. Rules as Code for individual program eligibility (Beeck Center validated approach)
  2. Knowledge graph for cross-program interactions and cliff detection (IBM validated approach)
  3. Neuro-symbolic pipeline for user input interpretation + rule verification (CalFresh validated approach)
  4. HCBS taxonomy for service classification and cross-state mapping (CMS standard)
  5. Caregiver SDOH as the input layer that no other system provides (see SDOH in Caregiving)

The research validates each component individually. GiveCare's contribution is the integration — and the delivery via SMS to a population that existing systems do not reach.

  1. Beeck Center at Georgetown University. "AI-Powered Rules as Code." 2025. Source → ↩↩

  2. IBM Research. "Knowledge Graphs for Social Good: Protecting Vital Health and Social Programs." 2021. Source → ↩↩

  3. "A Neuro-Symbolic Framework for Accountability in Algorithmic Decision-Making." arXiv:2512.12109, 2025. Source → ↩↩↩

  4. Peebles, V. & Bohl, A. "The HCBS Taxonomy: A New Language for Classifying Home- and Community-Based Services." 2014. Source → ↩↩

  5. Code for America. "Benefits Enrollment Field Guide 2024." Source → ↩↩↩↩↩↩

  6. American Enterprise Institute. "Stranded by the Safety Net: How to Fix the Benefit Cliff Problem." 2024. Source → ↩↩↩↩