Benefits Discovery¶
GiveCare maintains a 377-program caregiver benefits corpus in gc-benefits, then projects it into public wiki pages, the web benefits browser, and SMS runtime bundles.1 The corpus is moving from a flat program directory toward a normalized registry: programs remain the caregiver-facing unit, while authorities, agencies, fulfillment channels, and claim evidence explain who funds a benefit, who runs it, how a caregiver applies, and how current each claim is. When a zone is flagged, relevant benefit programs can surface through Mira.
The problem¶
Over $60 billion in benefits goes unclaimed annually2. Participation in safety net programs ranges 40-60%, with eligible non-participation rates of 16-72% depending on the program.
The gap is not a lack of programs. It is a lack of discovery, navigation, and follow-through. Most caregivers do not know they qualify. The application processes are fragmented, documentation requirements are unclear, and deadlines are easy to miss. See Benefits Landscape for the full landscape analysis.
How it works¶
flowchart TD
A["Zone flagged (score < 40)"] --> B["Filter programs by zone"]
B --> C["Check eligibility rules"]
C --> D["Surface matched programs via Mira"]
D --> E["Guide application steps"]
E --> F["Follow up on status"]- Zone flagging: When a caregiver's assessment flags a zone (score below threshold), the benefits engine activates for that zone.
- Program matching: Eligibility rules are evaluated against the caregiver's known profile (state, income bracket, care recipient condition, employment status).
- Proactive surfacing: Mira presents matched programs conversationally over SMS — not as a list dump, but one relevant program at a time with a clear next step.
- Application guidance: Step-by-step support through application processes, document requirements, and deadlines.
- Follow-up: Mira tracks application status and follows up proactively.
Program coverage¶
Federal programs¶
| Program | Zone(s) | Focus |
|---|---|---|
| NFCSP (National Family Caregiver Support Program) | P1, P4 | Respite, counseling, training, supplemental services |
| VA PCAFC (Program of Comprehensive Assistance for Family Caregivers) | P4, P2 | Stipend, health insurance, respite for veteran caregivers |
| VA PGCSS (Program of General Caregiver Support Services) | P1, P5 | Peer support, education, navigation for veteran caregivers |
| FMLA Military | P4, P5 | 26 weeks unpaid leave for military caregiver employees |
| Medicaid HCBS (Home and Community-Based Services) | P3, P4 | Home modifications, personal care, adult day services |
| SSI/SSDI | P4 | Income support for disabled care recipients |
| Lifespan Respite | P1, P2 | Respite care coordination and funding |
| Medicare GUIDE | P5, P1 | Dementia care navigation and support |
| SNAP | P4 | Nutrition assistance |
| LIHEAP | P4, P3 | Energy bill assistance |
| Medicaid | P4, P2 | Health coverage for low-income caregivers |
State-level programs¶
| Category | States/Jurisdictions | Zone(s) |
|---|---|---|
| Mandatory paid family leave | 14 jurisdictions | P4 |
| Structured Family Caregiving | 11 states | P4, P1 |
| Caregiver tax credits | 8 states | P4 |
| 7 state-specific implementations | Varies | Multiple |
Technical architecture¶
Registry and eligibility rules¶
The canonical benefit data lives in ../gc-benefits/data/programs/*.json and validates through Pydantic models in ../gc-benefits/src/benefit_engine/models.py.1 Program records carry machine-readable eligibility, coverage, verification, and freshness fields. The registry strategy adds optional edges from a program to:
- an authority such as a statute, waiver, grant, tax provision, or insurance line
- an agency that funds, administers, or serves as the front door
- a fulfillment channel for the program-by-jurisdiction transaction
- claim-level evidence for load-bearing facts such as current official name, family-payment eligibility, front door, and application URL
ETL pipeline¶
flowchart LR
A["Canonical gc-benefits JSON"] --> B["Validate + evidence audit"]
B --> C["Generate wiki benefit pages"]
C --> D["Extract resources.json"]
D --> E["Publish SMS resource bundle"]
B --> F["Export benefits runtime bundle"]
F --> G["Mira benefits screening"]
E --> G- Discover / ingest: source candidates are queued, scraped when allowed, and loaded into staged records
- Validate / audit: program JSON is checked for schema validity, source coverage, evidence gaps, freshness, and readiness
- Generate: validated corpus records refresh wiki-owned benefit pages
- Extract / publish: wiki frontmatter becomes
resources.jsonand the reduced SMS resource bundle; the benefits runtime bundle is exported directly fromgc-benefits
Impact evidence¶
- 74% of caregivers report that services enabled them to provide care longer3
- 62% indicated that without services, the care recipient would be in a nursing home3
- Average caregiver out-of-pocket cost: $7,242/year4 — benefits discovery directly reduces this burden
Code reference¶
Current v2 SMS screening logic lives in ../gc-sms/src/benefits.ts as a cautious adapter over the generated benefits bundle synced from gc-benefits. The adjacent resources tool reads ../gc-sms/data/resources.json, which is generated from this wiki's resources.json projection rather than hand-maintained. See also the Benefits Landscape for the broader policy context and Market Gap for the unclaimed benefits analysis.