Benefits Discovery¶
GiveCare maintains one benefits registry and publishes reviewed records through Hound owner projections. The projected program directory is the current public inventory. Mira can retrieve cautious candidates when the caregiver's current need and stated location support a lookup.
The problem¶
Over $60 billion in benefits goes unclaimed annually1. 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["Current need + caregiver-stated state"] --> B["Search the reviewed runtime bundle"]
B --> C["Filter by jurisdiction and relevance"]
C --> D["Return candidates worth checking"]
D --> E["Cite the source and preserve uncertainty"]
E --> F["Offer one useful next move"]- Need and location: Mira uses the current need, bounded known facts, and a caregiver-stated state. Without a state, it asks for that missing fact.
- Candidate retrieval: The runtime ranks reviewed records and filters out state-specific programs that do not cover the stated jurisdiction.
- Uncertainty: A result is a program worth checking, not an eligibility, approval, payment, or legal determination.
- Grounded reply: Any named program or application detail must come from the tool evidence for that turn and carry its source reference.
- Next move: Mira offers one proportionate next action. A later check-in is scheduled only with explicit caregiver consent; the runtime does not claim to track an external application's status.
Program coverage¶
The owner projection changes as programs and evidence change. GiveCare does not copy a count or a state list into this page. Use the program directory for the current set, domain tags, jurisdictions, evidence dates, and official links.
Technical architecture¶
Owner contract¶
Each projected program carries the public fields needed for cautious discovery: eligibility notes, jurisdiction, services, source URLs, evidence dates, and freshness. The Benefits owner validates those fields before Hound creates an immutable artifact reference. Wiki and SMS consumers accept that artifact or stop. They do not read the owner's working files.
ETL pipeline¶
flowchart LR
A["Benefits owner data"] --> B["Validate + evidence audit"]
B --> C["Hound corpus.project"]
C --> D["Verified Wiki page artifact"]
C --> E["Verified SMS artifact"]
D --> F["Wiki Hound runtime projection"]
E --> G["Mira benefits screening"]
F --> 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
- Project: Hound creates the complete Wiki-page and SMS artifacts and their immutable references
- Consume: each consumer verifies one exact owner run before replacing its complete local projection
- Reproject: Wiki Hound validates the synced pages before it emits Wiki-owned resource, strategy, and guidance contracts
Impact evidence¶
- 74% of caregivers report that services enabled them to provide care longer2
- 62% indicated that without services, the care recipient would be in a nursing home2
- Average caregiver out-of-pocket cost: $7,242/year3 — benefits discovery directly reduces this burden
Projection boundary¶
Hound is the only cross-repository knowledge boundary. A consumer receives an exact verified owner artifact. It does not inspect source files, copy mutable working data, or maintain a second registry. See also the Benefits Landscape for the broader policy context and Market Gap for the unclaimed benefits analysis.